Resiliencia Operativa

Chaos engineering, disaster recovery, backups, runbooks y prácticas para mantener el sistema funcionando ante fallos.

¿Qué es la resiliencia operativa?

La resiliencia operativa es la capacidad de un sistema para continuar funcionando (o recuperarse rápidamente) ante fallos, errores y situaciones inesperadas. No se trata de evitar los fallos — en sistemas distribuidos, los fallos son inevitables — sino de diseñar el sistema para que los tolere.

La resiliencia operativa abarca:

• Prevención de fallos mediante diseño robusto
• Detección rápida de problemas
• Recuperación automática o asistida
• Aprendizaje continuo de los incidentes

Chaos engineering

El chaos engineering es la práctica de inyectar fallos deliberadamente en el sistema para verificar que puede manejarlos. La premisa es simple: si no probás los fallos en un entorno controlado, los vas a descubrir en producción.

Principios

1. Definir el estado estable: ¿cómo se ve el sistema cuando funciona bien? (métricas, latencia, error rate)
2. Formular una hipótesis: “Si falla el servicio X, el sistema debería degradarse gracefully”
3. Inyectar el fallo: simular la condición de fallo
4. Observar el impacto: ¿el sistema se comportó como esperábamos?
5. Aprender y mejorar: documentar hallazgos y corregir debilidades

Tipos de experimentos

• Terminar instancias: ¿qué pasa si un pod muere repentinamente?
• Inyectar latencia: ¿qué pasa si un servicio downstream responde lento?
• Simular errores de red: ¿qué pasa si se pierde la conexión entre servicios?
• Llenar el disco: ¿qué pasa si el almacenamiento se agota?
• Saturar CPU/memoria: ¿qué pasa bajo presión extrema de recursos?

Herramientas

• Chaos Monkey (Netflix): termina instancias aleatoriamente en producción
• Litmus Chaos: framework de chaos engineering para Kubernetes
• Gremlin: plataforma comercial de chaos engineering
• Chaos Mesh: herramienta open source para Kubernetes
• Toxiproxy: proxy para simular condiciones de red adversas

Buenas prácticas

• Empezar en entornos de staging antes de producción
• Comenzar con experimentos pequeños y controlados
• Tener siempre un plan de rollback
• Involucrar al equipo — el chaos engineering es un ejercicio de equipo
• Documentar cada experimento y sus resultados

Disaster recovery

El disaster recovery (DR) es el plan para recuperar el sistema ante un fallo catastrófico: pérdida de un datacenter, corrupción masiva de datos, o un ataque de seguridad.

Métricas clave

• RTO (Recovery Time Objective): tiempo máximo aceptable para restaurar el servicio
• RPO (Recovery Point Objective): cantidad máxima de datos que se pueden perder (medido en tiempo)

Plan de disaster recovery

1. Identificar sistemas críticos: ¿qué servicios son esenciales para el negocio?
2. Definir RTO y RPO: para cada sistema crítico
3. Diseñar la estrategia: backups, replicación, multi-región
4. Documentar el proceso: paso a paso para la recuperación
5. Probar regularmente: un plan no probado es un plan que no funciona
6. Actualizar el plan: cada cambio en la arquitectura puede afectar el DR

Backups

Los backups son la última línea de defensa contra la pérdida de datos.

Tipos de backup

• Full backup: copia completa de todos los datos
• Incremental backup: solo los datos que cambiaron desde el último backup
• Differential backup: los datos que cambiaron desde el último full backup

Regla 3-2-1

• 3 copias de los datos
• 2 tipos de almacenamiento diferentes
• 1 copia offsite (en otra ubicación geográfica)

Buenas prácticas

• Automatizar: los backups manuales se olvidan
• Verificar: probar regularmente que los backups se pueden restaurar
• Encriptar: los backups contienen datos sensibles
• Retención: definir políticas claras de cuánto tiempo se conservan
• Monitorear: alertar si un backup falla

Ejemplo de política de backups

Base de datos principal:
- Full backup: diario a las 02:00 UTC
- Incremental: cada 1 hora
- Retención: 30 días para diarios, 7 días para incrementales
- Almacenamiento: S3 con replicación cross-region
- Verificación: restauración automática semanal en entorno de test

Runbooks

Un runbook es un documento que describe paso a paso cómo responder a un incidente o realizar una operación. Es la diferencia entre una respuesta caótica y una respuesta ordenada.

Estructura de un runbook

1. Título y descripción: qué incidente o operación cubre
2. Síntomas: cómo se detecta el problema (alertas, métricas, logs)
3. Impacto: qué se ve afectado y qué tan grave es
4. Diagnóstico: pasos para confirmar la causa raíz
5. Resolución: pasos exactos para resolver el problema
6. Verificación: cómo confirmar que el problema se resolvió
7. Post-mortem: qué documentar después del incidente

Ejemplo: runbook para alta latencia en API

## Alta latencia en API Gateway

### Síntomas
- Alerta: p99 latencia > 2s durante 5 minutos
- Dashboard: gráfico de latencia en rojo

### Diagnóstico
1. Verificar métricas de CPU/memoria de los pods
2. Revisar logs de errores recientes
3. Verificar latencia de servicios downstream
4. Verificar conexiones a base de datos

### Resolución
Si CPU > 90%:
  → Escalar horizontalmente: kubectl scale deployment api --replicas=X

Si DB connections saturadas:
  → Verificar connection pool settings
  → Reiniciar pods si hay connection leaks

Si servicio downstream lento:
  → Verificar health del servicio
  → Activar circuit breaker si es necesario

### Verificación
- Confirmar que p99 latencia < 500ms
- Verificar que error rate < 0.1%
- Monitorear durante 15 minutos

Incident management

Proceso de respuesta a incidentes

1. Detección: alertas automáticas o reporte manual
2. Triaje: evaluar severidad e impacto
3. Comunicación: notificar a los stakeholders
4. Investigación: diagnosticar la causa raíz
5. Mitigación: restaurar el servicio lo antes posible
6. Resolución: aplicar la corrección definitiva
7. Post-mortem: documentar qué pasó, por qué y cómo prevenirlo

Niveles de severidad

Post-mortem blameless

Después de cada incidente significativo, realizar un post-mortem sin culpas:

• Qué pasó: cronología detallada del incidente
• Por qué pasó: análisis de causa raíz (5 whys)
• Qué hicimos bien: qué funcionó en la respuesta
• Qué podemos mejorar: acciones concretas para prevenir recurrencia
• Action items: tareas asignadas con responsables y fechas

Resumen

La resiliencia operativa no es opcional en sistemas distribuidos. El chaos engineering valida que el sistema tolera fallos, el disaster recovery prepara para lo peor, los backups protegen los datos, los runbooks guían la respuesta a incidentes y el incident management organiza la recuperación. La clave es practicar, documentar y mejorar continuamente.