La primera ejercitación de continuidad operativa es un momento de verdad para cualquier organización. No es solo una prueba técnica, sino una verificación de la madurez organizacional y la resiliencia real de los sistemas. Una ejercitación bien realizada, incluso si revela criticidades inesperadas, es un éxito porque transforma desastres potenciales en lecciones aprendidas. En mi rol de Senior IT Consultant, he tenido la oportunidad de orquestar y observar de cerca estas simulaciones en entornos complejos, como el de una organización con 2.000 estaciones de trabajo y más de 300 VM VMware. El objetivo era claro: validar el plan de Disaster Recovery (DR) y Business Continuity (BC) frente a un escenario de indisponibilidad total del datacenter primario. A pesar de una planificación meticulosa, la realidad superó cualquier expectativa, poniendo de manifiesto una serie de problemas que solo una prueba práctica habría podido revelar.
Probado en: Infraestructura VMware vSphere 7.0 · Backup Veeam Backup & Replication 12 · Agosto 2026
Requisitos Previos / Entorno de Prueba
Para la ejercitación de continuidad operativa, el entorno de prueba se configuró para replicar lo más fielmente posible la infraestructura de producción. Esto incluía dos sitios geográficamente separados: un sitio primario activo y un sitio de Disaster Recovery (DR) pasivo. El sitio primario albergaba un clúster VMware vSphere con más de 300 VM, almacenamiento SAN y servicios de red complejos gestionados por Cisco y FortiGate. El sitio DR estaba equipado con hardware similar, pero con una configuración mínima, a la espera de ser activado. Los backups se gestionaban mediante Veeam Backup & Replication, con réplicas off-site. El plan de continuidad operativa incluía procedimientos detallados para el failover de servicios críticos, desde la base de datos Oracle hasta las aplicaciones enterprise, pasando por los sistemas de gestión documental. La simulación preveía la indisponibilidad total del sitio primario, forzando la activación del sitio DR y la restauración de los servicios dentro de los tiempos de Recovery Time Objective (RTO) y Recovery Point Objective (RPO) definidos. El desafío principal era coordinar los diversos equipos (administradores de sistemas, DBAs, desarrolladores de aplicaciones) y validar la documentación existente.
1. El Plan de Ejercitación: Teoría vs. Realidad
El plan de ejercitación había sido redactado con cuidado, incluyendo escenarios de failover para los servicios principales. Sin embargo, su implementación práctica reveló una serie de discrepancias. La primera fase preveía la simulación de un apagón total del datacenter primario, con el objetivo de activar los servicios críticos en el sitio DR. Este proceso debería haber seguido una secuencia bien definida, pero desde los primeros pasos surgieron las primeras dificultades. La documentación, aunque existente, no siempre estaba alineada con las configuraciones actuales de la infraestructura. Comandos y rutas de archivo habían cambiado, haciendo que los procedimientos fueran inutilizables. Esto destacó la importancia de un proceso de revisión y actualización continua de la documentación, especialmente en entornos dinámicos. Lee también: Cloud PA PSN: La Realidad de la Migración Obligatoria 2026
Un ejemplo claro fue la restauración de un servidor de aplicaciones basado en Linux. El procedimiento indicaba un comando para la configuración de la red que ya no era válido debido a una actualización del sistema operativo:
# Comando obsoleto en el plan
ip addr add 10.0.0.10/24 dev eth0
# Comando correcto para el OS actualizado
nmcli connection modify "System eth0" ipv4.addresses 10.0.0.10/24
nmcli connection up "System eth0"Este pequeño error causó un retraso significativo, ya que el equipo tuvo que diagnosticar y resolver el problema en el campo, en lugar de seguir un procedimiento probado.
2. Lagunas en los Backups e Inconsistencias de Datos
Uno de los aspectos más críticos que surgieron fue la presencia de lagunas en los backups. A pesar de un sistema de backup robusto como Veeam, algunos datasets cruciales no se habían incluido en los planes de protección o sus políticas de retención eran insuficientes. Esto afectó en particular a bases de datos Oracle pequeñas pero críticas, y a recursos compartidos de red utilizados para configuraciones de aplicaciones. El intento de restauración reveló que los datos no estaban disponibles o eran demasiado antiguos para garantizar un RPO aceptable. Lee también: Backup 2TB Sala Máquinas: Restic vs BorgBackup
Para las bases de datos Oracle, fue necesario intervenir manualmente para recuperar los datos de backups alternativos, prolongando notablemente el RTO. La verificación de los backups es fundamental, pero a menudo se limita a un control de su existencia, no de su integridad y completitud. Un comando para verificar la consistencia de un backup Veeam, por ejemplo, es:
Get-VBRJob | ForEach-Object { Get-VBRBackup -Job $_ | ForEach-Object { Start-VBRRestoreSession -Backup $_ -RestorePoint $_.GetLastRestorePoint() -RunAsync } }Este script, aunque no es una restauración real, puede ayudar a identificar problemas de consistencia a nivel de VM. Sin embargo, no sustituye una restauración completa y validación de los datos.
3. Coordinación del Equipo y Roles No Definidos
La simulación puso de manifiesto la necesidad de una coordinación más eficaz del equipo. En situaciones de estrés, la comunicación puede volverse fragmentada y los roles menos claros. Diferentes equipos (redes, virtualización, bases de datos, aplicaciones) actuaron de forma independiente, causando duplicaciones de esfuerzos y, en algunos casos, intervenciones contradictorias. La falta de un “Incident Commander” claramente designado y de un canal de comunicación unificado ralentizó el proceso de restauración. Lee también: NIS2 Artículo 21: Checklist de Notificación
Surgió la necesidad de sesiones de formación conjuntas para todos los equipos involucrados, para simular escenarios de crisis y definir claramente las responsabilidades de cada uno. Un plan de comunicación interna y externa es igualmente crucial, para informar a las partes interesadas y gestionar las expectativas.
4. Dependencias Ocultas y Tiempos de Recuperación Inesperados
Muchos servicios, aparentemente independientes, tenían dependencias ocultas que comprometieron el RTO. Por ejemplo, una aplicación web crítica dependía de un servicio de autenticación secundario que no se había restaurado a tiempo, bloqueando el acceso de los usuarios. Estas dependencias no se habían mapeado en el plan de DR, lo que provocó retrasos inesperados. La complejidad de un entorno enterprise requiere un mapeo detallado de todas las interdependencias entre servicios y aplicaciones. Utilizar herramientas de CMDB (Configuration Management Database) o soluciones de Application Dependency Mapping puede ayudar a identificar estas relaciones. Lee también: Proxmox Replica: WAN Lenta, RPO Bajo
El cálculo del RTO resultó ser excesivamente optimista. Las estimaciones iniciales no tuvieron en cuenta los tiempos de arranque de las VM, la sincronización de las bases de datos o la verificación manual de los servicios. El RTO real se extendió mucho más allá de lo esperado, destacando la necesidad de probar el proceso de principio a fin y de revisar los tiempos de forma realista.
Errores Comunes y Resolución de Problemas
Los errores más comunes encontrados durante la ejercitación fueron la documentación obsoleta, los backups incompletos y la falta de coordinación. Para abordar estos problemas, es fundamental implementar un ciclo de feedback continuo. Cada modificación de la infraestructura (actualización de software, nueva VM, cambio de configuración) debe desencadenar una revisión de la documentación de DR y, si es necesario, una prueba específica. Utilizar herramientas de automatización como Ansible para la configuración de los servidores puede ayudar a mantener la consistencia y a reducir los errores manuales. Por ejemplo, un playbook Ansible para configurar una interfaz de red garantiza que el procedimiento sea siempre el mismo y esté documentado en el código:
- name: Configure network interface
ansible.builtin.nmcli:
conn_name: "System eth0"
ifname: eth0
type: ethernet
ip4_address: 10.0.0.10/24
state: present
autoconnect: truePara los backups, es esencial no solo verificar que los trabajos se hayan completado, sino también realizar periódicamente restauraciones parciales y completas, validando la integridad de los datos. Esto incluye la restauración de bases de datos y el inicio de VM restauradas para probar su funcionalidad.
FAQ — Preguntas Frecuentes
¿Con qué frecuencia deberíamos realizar las ejercitaciones de continuidad operativa?
Las ejercitaciones completas deberían realizarse al menos una vez al año. Sin embargo, pruebas parciales o enfocadas en servicios o componentes críticos individuales pueden realizarse con mayor frecuencia, por ejemplo, trimestralmente, para validar procedimientos específicos o actualizaciones infraestructurales. La frecuencia depende de la complejidad del entorno y la velocidad de los cambios.
¿Cómo podemos garantizar que la documentación esté siempre actualizada?
Integrar la revisión de la documentación en el proceso de gestión de cambios (Change Management). Cada vez que se implementa una modificación significativa en la infraestructura o los servicios, el procedimiento de DR relacionado debería ser revisado y actualizado. El uso de herramientas de versionado para la documentación, como Git, puede ayudar a rastrear los cambios y facilitar las revisiones colaborativas.
¿Cuál es el papel de un Incident Commander durante una ejercitación?
El Incident Commander es el punto de referencia único para la gestión del incidente o la ejercitación. Es responsable de la coordinación de todos los equipos, la comunicación interna y externa, y las decisiones críticas. Su papel es garantizar que el plan se ejecute de manera eficiente y que los recursos se asignen correctamente. Esta figura debe tener autoridad y capacidad de liderazgo.
¿Cómo podemos identificar todas las dependencias entre los servicios?
La identificación de las dependencias puede ser compleja. Comenzar con un taller que involucre a todos los equipos técnicos y las partes interesadas de las aplicaciones para mapear los flujos de datos y las interconexiones. Utilizar herramientas de Application Dependency Mapping (ADM) puede automatizar parcialmente este proceso, proporcionando una visualización dinámica de las dependencias en entornos complejos. La documentación de arquitectura es un punto de partida crucial.
¿Es suficiente probar solo los servicios más críticos?
No, no es suficiente. Aunque los servicios críticos tienen prioridad, una ejercitación completa debería incluir también los servicios menos críticos que podrían tener dependencias ocultas o influir en la restauración de los servicios principales. Un enfoque por fases, partiendo de los servicios más críticos y luego extendiéndose, puede ser eficaz, pero el objetivo final es probar toda la cadena de restauración.
Conclusiones con Puntos Clave Operativos
La primera ejercitación de continuidad operativa, por muy desafiante que fuera, fue un éxito porque reveló criticidades que de otro modo habrían surgido solo durante un desastre real. Los puntos clave operativos son claros: la resiliencia no es solo una cuestión tecnológica, sino organizacional. Es fundamental invertir en la revisión continua de la documentación, la formación conjunta de los equipos y el mapeo profundo de las dependencias. La verificación de los backups debe ir más allá de la simple confirmación de finalización, incluyendo pruebas de restauración periódicas. Finalmente, la definición clara de los roles y la institución de una figura de Incident Commander son elementos no negociables para una gestión eficaz de los incidentes. Solo a través de un ciclo de pruebas, aprendizaje y mejora continua es posible construir una verdadera capacidad de resiliencia empresarial.
Fuentes
Actualizado: Agosto 2026
