4 min lectura • Guide 772 of 877
Planificación de Recuperación de Desastres
Espera lo mejor, planifica para lo peor. GitScrum ayuda a los equipos a documentar procedimientos de recuperación, trackear pruebas de DR, y asegurar continuidad del negocio.
Fundamentos de DR
Objetivos de Recuperación
DEFINIENDO OBJETIVOS DE RECUPERACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TÉRMINOS CLAVE: │
│ │
│ RTO (Recovery Time Objective): │
│ Downtime máximo aceptable │
│ "Debemos estar online dentro de X horas" │
│ │
│ RPO (Recovery Point Objective): │
│ Pérdida de datos máxima aceptable │
│ "Podemos perder máximo X horas de datos" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CLASIFICACIÓN DE SERVICIOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Servicio Tier RTO RPO ││
│ │ ─────────────── ──── ────── ────── ││
│ │ API de Pagos 1 15 min 0 (ninguna) ││
│ │ BD de Usuarios 1 30 min 5 min ││
│ │ App Principal 1 1 hora 1 hora ││
│ │ Analytics 2 4 horas 24 horas ││
│ │ Ambiente Dev 3 24 horas 1 semana ││
│ │ Almacen Archivo 3 48 horas N/A ││
│ │ ││
│ │ Tier 1: Crítico (prioridad inmediata) ││
│ │ Tier 2: Importante (restaurar después de Tier 1) ││
│ │ Tier 3: No-crítico (puede esperar) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COSTO vs RTO: │
│ RTO más corto = Infraestructura más cara │
│ Balancear necesidades del negocio con presupuesto │
└─────────────────────────────────────────────────────────────┘
Escenarios de Desastre
PLANIFICACIÓN DE ESCENARIOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESCENARIOS COMUNES DE DESASTRE: │
│ │
│ INFRAESTRUCTURA: │
│ • Caída de región cloud │
│ • Fallo de servidor de BD │
│ • Pérdida de conectividad de red │
│ • Fallo de DNS │
│ │
│ DATOS: │
│ • Corrupción de base de datos │
│ • Encriptación por ransomware │
│ • Eliminación accidental de datos │
│ • Fallo de backup │
│ │
│ APLICACIÓN: │
│ • Deployment malo │
│ • Error de configuración │
│ • Fallo de dependencia │
│ • Agotamiento de recursos │
│ │
│ SEGURIDAD: │
│ • Compromiso de cuenta │
│ • Ataque DDoS │
│ • Brecha de datos │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PARA CADA ESCENARIO: │
│ • Detección: ¿Cómo sabremos? │
│ • Respuesta: ¿Qué hacemos inmediatamente? │
│ • Recuperación: ¿Cómo restauramos servicio? │
│ • Comunicación: ¿A quién notificamos? │
│ • Post-incidente: ¿Cómo prevenimos recurrencia? │
└─────────────────────────────────────────────────────────────┘
Documentación DR
Runbooks de Recuperación
ESTRUCTURA DE RUNBOOK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RUNBOOK DE RECUPERACIÓN DE BASE DE DATOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DR-RUN-001: Recuperación de BD Primaria ││
│ │ ││
│ │ ESCENARIO: ││
│ │ Servidor de BD primaria no disponible ││
│ │ ││
│ │ DETECCIÓN: ││
│ │ • Alerta de monitoreo: fallos de conexión DB ││
│ │ • Spike de errores de aplicación ││
│ │ • Fallos de health check ││
│ │ ││
│ │ ACCIONES INMEDIATAS (< 5 min): ││
│ │ 1. Verificar que DB realmente está caída ││
│ │ 2. Revisar página de estado del cloud ││
│ │ 3. Declarar incidente, iniciar comunicación ││
│ │ ││
│ │ OPCIONES DE RECUPERACIÓN: ││
│ │ ││
│ │ OPCIÓN A: Failover a réplica (RTO: 15 min) ││
│ │ 1. Promover réplica a primaria ││
│ │ 2. Actualizar connection strings ││
│ │ 3. Verificar integridad de datos ││
│ │ ││
│ │ OPCIÓN B: Restaurar de backup (RTO: 1 hora) ││
│ │ 1. Provisionar nuevo servidor ││
│ │ 2. Restaurar último backup ││
│ │ 3. Aplicar transaction logs ││
│ │ 4. Actualizar connection strings ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘