Consultoría TI

Físico: máximo rendimiento y control, pero inflexible. Virtual en tu propia infraestructura (ESXi, Proxmox): buen balance si ya tenés hardware. Cloud (AWS EC2, GCP, Azure): elasticidad y sin CAPEX inicial, ideal para cargas variables. Lo evaluamos según tu caso, presupuesto y necesidades de disponibilidad. Muchas veces la respuesta es híbrido.

Para servidores de producción en PYMES, Ubuntu LTS es el más común por balance entre modernidad y soporte. Debian para estabilidad máxima. RHEL/Rocky cuando hay requisitos empresariales o integración con productos Red Hat. La diferencia real en operación diaria es mínima — elegimos según afinidad de tu equipo y soporte necesario.

Sí. Además de la documentación en texto (parámetros, rutas, servicios, contraseñas en gestor de secretos), entregamos la configuración versionada en Git con playbooks Ansible o scripts. Si mañana hay que recrear el servidor, es reproducible en minutos. Tu equipo puede leer, modificar y mantener la configuración sin depender de nosotros.

El SLA depende de la arquitectura: un único servidor sin redundancia físicamente no puede garantizar 99.99% de uptime. Para SLAs exigentes, diseñamos alta disponibilidad (redundancia, balanceo, failover). Lo que sí garantizamos siempre es el tiempo de respuesta a incidentes según plan contratado — desde "siguiente día hábil" hasta "15 minutos en guardia 24/7".

Preferimos acceso con privilegios elevables (sudo con MFA) en lugar de root permanente. Todos los accesos quedan registrados en logs de auditoría. En entornos más sensibles, trabajamos con bastion host dedicado o acceso Just-in-Time con aprobación. Lo que mejor encaje con tus controles internos.

Con planes de guardia 24/7, las alertas críticas disparan llamadas a on-call que responde en minutos. Planes estándar atienden críticos en horario ampliado (6 AM - 10 PM) y no-críticos en horario laboral regular. Definimos con claridad qué cuenta como "crítico" desde el día uno para que no haya sorpresas.

AWS es el más maduro y con mayor ecosistema, ideal para casi cualquier caso. Azure se integra naturalmente si ya usás Microsoft 365, Active Directory o productos Microsoft. GCP destaca en analytics, big data y ML. Lo evaluamos según tu stack actual, equipo, y dónde hay mejor relación costo/beneficio para tus workloads. A veces la respuesta es multi-cloud.

Depende de la arquitectura. Lift-and-shift típicamente cuesta similar o más que on-premise. El ahorro real aparece cuando usás servicios cloud-native (serverless, managed databases, auto-scaling) y optimizás con reserved instances o savings plans. Hacemos análisis TCO (total cost of ownership) con tus datos reales antes de migrar para que vayas con expectativas realistas.

Para aplicaciones sin estado (stateless) o con datos replicables, el downtime puede ser de minutos (cutover de DNS). Para bases de datos grandes con mucho tráfico, las estrategias de replicación previa y cutover permiten ventanas de 1-4 horas. Para casos críticos que no pueden tener downtime, arquitecturas dual-write o multi-region, pero el costo sube. Lo definimos según criticidad.

Separamos dos cosas: el costo del VPS (que se paga directo al proveedor cloud y queda a tu nombre) y nuestra tarifa de administración mensual. Eso te da transparencia y control: si un día decidís cambiar de proveedor o asumir la gestión internamente, no tenés que renegociar nada.

Para planes con guardia 24/7 activada, el monitoreo dispara alertas a un on-call rotativo. Para planes estándar, los incidentes críticos (sitio caído, brecha de seguridad) se atienden de inmediato aunque sea fin de semana; los no-críticos entran a la cola del siguiente día hábil.

En la mayoría de casos sí. Preparamos el nuevo entorno en paralelo, sincronizamos datos, hacemos un cutover con DNS bajo y mantenemos ambos activos hasta validar. Los pocos casos donde hay downtime son por dependencias del proveedor anterior que no lo permiten; en esos escenarios coordinamos una ventana mínima.

RPO (Recovery Point Objective): cuánto dato podés perder aceptablemente, medido en tiempo. Si hacés backup cada 4 horas, tu RPO es 4 horas — esa es la información que podés perder en el peor caso. RTO (Recovery Time Objective): cuánto tiempo podés estar caído antes de retomar operación. Ambos definen cuán caro y elaborado debe ser tu DRP.

Las dos cosas. Backup local (NAS, tape, otro servidor) da restauración rápida en caso de fallas comunes. Backup en la nube (S3, Glacier, Backblaze B2) protege ante desastres físicos (incendio, robo, ransomware que cifra también los backups locales). La estrategia 3-2-1 combina ambos mundos — es el estándar recomendado.

Restauramos a un entorno aislado (sandbox, VM temporal) y validamos que la data esté íntegra y que los servicios levanten correctamente. Ningún dato productivo se toca. Documentamos cada prueba: qué se restauró, cuánto tardó, qué problemas aparecieron. Ese registro sirve para auditorías y para calibrar RTO reales vs. teóricos.

Nivel 1 atiende incidentes rutinarios (restablecer contraseñas, problemas básicos de uso, instalaciones simples). Nivel 2 diagnostica problemas técnicos más complejos (fallas de aplicación, configuraciones de red, problemas de rendimiento). Nivel 3 son especialistas para incidentes críticos (incidentes de seguridad, fallas de infraestructura, arquitectura). Cada nivel resuelve lo que puede y escala al siguiente si hace falta.

Ofrecemos los tres modelos. Facturación mensual fija da previsibilidad (ideal para empresas con volumen constante). Bolsa de horas funciona bien si el volumen es variable (comprás un bloque de horas y se consume según necesidad). Por ticket es útil para incidentes ocasionales. Recomendamos uno según tu patrón de uso en la propuesta inicial.

Por defecto, horario laboral ampliado (lunes a viernes de 7:00 a 17:00 GMT-6). Para planes con guardia 24/7, incidentes críticos se atienden cualquier día y hora. Definimos contigo qué cuenta como crítico (servicio caído, brecha de seguridad, imposibilidad de operar) para que no haya ambigüedad al momento del incidente.

Un técnico tercerizado responde cuando le llamás — reactivo, sin visibilidad proactiva. Un MSP opera con herramientas de monitoreo continuo, procesos documentados, métricas objetivas y responsabilidad sobre el ambiente completo. En MSP, nosotros somos responsables del uptime, no solo de atender llamadas. Es un cambio de modelo, no solo de proveedor.

Los planes se diseñan con límites razonables ("usuarios soportados", "servidores gestionados", "horas de proyecto incluidas"). Incidentes dentro del scope no tienen costo adicional — es la esencia del MSP. Proyectos mayores (ej. migrar una app a la nube) se cotizan aparte porque están fuera del alcance de operación diaria. Lo definimos claramente en el contrato para evitar ambigüedades.

Durante el contrato, mantenemos documentación completa, procedimientos escritos y configuraciones versionadas. Si en algún momento decidís internalizar la función, el traspaso es ordenado: inventario, accesos, runbooks, lecciones aprendidas. Apoyamos la transición durante un período acordado. Nuestro interés es que la relación funcione por resultados, no por lock-in.