Crear un plan de DR: Identificar servicios críticos y puntos de fallo
Un plan de Recuperación ante Desastres (DR) comienza centrándose en los servicios para el usuario final. El objetivo es minimizar el tiempo de inactividad de los procesos de negocio, no solo de componentes individuales de infraestructura. Los usuarios notan las interrupciones a nivel de servicio: sin acceso al correo electrónico o al sistema ERP, no un disco fallido en un servidor.
Primero, lista tus servicios TI críticos —las herramientas sin las cuales el negocio pierde ingresos o eficiencia:
- Correo electrónico
- Sistemas telefónicos corporativos
- Planificación de recursos empresariales (ERP, como 1C)
- Plataformas de colaboración de documentos
- Impresión en red
- Acceso a internet
- CRM corporativo y bases de datos
Excluye elementos no críticos como servidores de juegos: no afectan las operaciones diarias.
Encontrar puntos de fallo en la infraestructura
Para cada servicio, identifica todos los puntos de fallo potenciales —componentes de infraestructura cuya interrupción hace que el servicio quede inaccesible. Un punto de fallo es cualquier unidad donde el diagnóstico se detiene en "está caído".
En dispositivos modulares (como routers), considera módulos individuales y chasis por separado. Si puedes aislar y reemplazar subcomponentes, cada uno es un punto de fallo propio.
Ejemplo para el servicio "Correo electrónico":
- SO del servidor (Linux/Windows Server)
- Software de correo (Postfix, Exchange)
- Switch de red principal
- Sistemas de alimentación (SAI, PDU)
- Servidores DNS externos
- Filtros de listas negras (RBL)
- Control climático de la sala de servidores
- Almacenamiento de datos (SAN/NAS)
No pases por alto el equipo "fiable": incluso un array de almacenamiento con RAID y replicación necesitará un plan de recuperación si falla.
Analizar dependencias entre puntos de fallo
Los puntos de fallo forman un grafo de dependencias: una interrupción puede desencadenar una cascada en otros. Por ejemplo, un fallo en el SAI apaga los servidores, y al reiniciar el hipervisor, las MV podrían no arrancar correctamente. Un switch del lado del cliente, sin embargo, es independiente.
Para "Correo electrónico", las dependencias forman una cadena: alimentación → servidores → aplicaciones → red → servicios externos. Extiende este modelo a todos los servicios críticos con un diagrama de influencias.
Esta visión es clave para la priorización: dicta el orden de diagnóstico, objetivos RTO/RPO y riesgos. Secciones posteriores cubrirán procedimientos de recuperación y métricas.
Lecciones clave
- Céntrate en servicios visibles para el usuario, no en hardware: las empresas miden el tiempo de inactividad en minutos de herramientas clave perdidas.
- Lista cada punto de fallo, sin saltarte equipo "a prueba de balas" —la Ley de Murphy ataca de todos modos.
- Los grafos de dependencias revelan fallos en cascada y aceleran el MTTR (Tiempo Medio de Recuperación).
- Un plan de DR convierte la extinción reactiva de incendios en estrategias proactivas con presupuestos y SLAs.
- Integra con CMDB o ITSM para descubrimiento automatizado.
— Editorial Team
Aún no hay comentarios.