Simulaciones de incidentes

1) Por qué realizar simulaciones

• reducen el MTTD/MTTA/MTTR, aumentan la confianza en retrocesos y feilover;
• identifican brechas en los procesos (escalamiento, comunicaciones) y debilidades arquitectónicas;
• sirven de entrada a la RCA→CAPA y mejoran la documentación (runbook/SOP);
• confirman la preparación para los requisitos de SLA/reguladores/auditorías.

2) Formatos de simulación

Tabletop (escritorio) es un script coloquial en el tablero/chat: barato, rápido, excelente para practicar roles y comunicaciones.
Game Day (ejercicios en stage/venta con restricciones) - pasos prácticos para los playbooks; en venta: sólo acciones seguras y reversibles con gates claras.
Chaos Engineering - Fallas gestionadas (desactivación de dependencias/redes/nodos) para comprobar la estabilidad y las puertas de SLO.
Ejercicios de DR (Disaster Recovery) - Falla de AZ/región, recuperación de backups, conmutación de proveedores.
Comms-drill - puramente comunicaciones: status page, plantillas de mensajes, PR/Legal.

3) Funciones y responsabilidad

Incident Commander (IC) - Toma decisiones, lidera el plan, la desescalada.
Tech Lead (TL) - diagnósticos, «injertos» técnicos e hipótesis.
Comms Lead (CL) - apdates internos/externos, página de estado.
Scribe - protocolo (tiempo en línea, acciones, soluciones, artefactos).
Observers/Assessors: fijan las métricas y el cumplimiento de los procedimientos.
Equipo Rojo (opcional): introduce «inyecciones» imprevistas.

4) Métricas del éxito de las simulaciones

MTTD/MTTA/MTTR sobre un incidente sintético.
Comm SLA: puntualidad y calidad de los apdates.
SLO-guardrails: respuesta correcta a burn-rate, quórum de muestras externas.
Fidelidad de Runbook:% de pasos realizados por documento, sin improvisación.
Escalation latency: velocidad de conexión del rol/proveedor deseado.
Checklists pass-rate: cumplimiento de «listo/aceptado/cerrado».
Noise & Fatigue: alertas extra, sobrecorriente on-call.
CAPA completion: proporción de acciones realizadas después de la simulación.

5) Preparación: lo que se necesita antes del comienzo

Objetivo e hipótesis: lo que comprobamos (procesos, arquitectura, personas).
Guión e «injertos»: secuencia de síntomas/eventos con temporizaciones.
Restricciones de seguridad: prohibición de cambios irreversibles; puntos de cancelación.
Datos y stands: tráfico sintético, banderas de degradación, llaves seguras.
Documentos: enlaces a runbook/SOP, escalada, lista de contactos de proveedores.
Observabilidad: dashboards/alertas previamente marcadas, test canarios.
Logística: tiempo/duración, miembros, canal de guerra-sala, grabación.

6) Realización de la simulación: etapas

1. Brief (5-10 min): IC se asemeja a los objetivos, roles, reglas de seguridad, criterios de finalización.
2. T0 - Influjo de síntomas: alerta (s), caída de SLI de negocios, estado externo del proveedor.
3. Triaje y escalamiento: asignación de SEV, liberación libre, conexión de los roles deseados.
4. Diagnóstico: hipótesis, verificación de DNS/TLS/CDN/BD/caché/bus, anotaciones de lanzamientos.
5. Acciones mitigadoras: otkat/kanareyka↓, banderas de degradación de fichas, proveedor de fallas, límites/retraídas.
6. Comunicaciones: actualizaciones regulares (formato: Impakt→Diagnostika→Deystviya→Sled. apdate).
7. Recuperación y verificación: sintética externa + SLI en la zona verde N de intervalos.
8. Debrief (AAR): 15-30 min - hechos, conclusiones, CAPA.

7) Ejemplos de scripts (directorio)

Caída del éxito de los pagos: el proveedor A se degrada en un país; acciones esperadas: redistribución del tráfico, habilitación de UX simplificado, comunicación.
Error DNS: error de escritura/TTL, parte de los usuarios no resuelven el dominio; los pasos esperados son fixs/folback, limpieza CDN, status update.
Certificado TLS caducado: el apretón de manos se rompe para los clientes antiguos; se espera una extensión de emergencia y una verificación de la cadena.
Kafka lag: aumento del retraso en los eventos KYC/AML; expectativas - escalar los consumidores, limitar los productores.
BD p99 ↑ y crecimiento 5xx: índices estrechos, límite de connects; expectativas - banderas de fichas, límites, hotfix/retroceso.
Fallo regional: deshabilitar AZ/PoP; espera - GSLB/Anycast conmutación, validación de datos y SLO.
Drill Comunication: todo es «verde», pero verificamos patrones, intervalos y alineación con Legal/PR.

8) Plantilla de «injecto» (tarjeta)

ID: INJ-2025-11-01-01
Purpose: Verification of failover payments and comms SLA
Trigger T0: 30% reduction in transaction success in the TR region (alert SLI + burn rate)
Signals: 5xx growth in payment API, external status PSP-A = partial outage
Expected actions: reduction of the share on PSP-A to 30%, inclusion of degrade-payments-UX, status update 15 min
Success criteria: success of payments ≥ 98% in 30 minutes, two green SLI intervals
NOTAM (security): prohibition of direct database edits; flags/routing only

9) Seguridad y cumplimiento

Simulaciones prod: sólo reversibles: banderas de fichas, conmutación de tráfico en lotes pequeños, réplicas para leer, «tráfico de sombras».
Control de acceso/auditoría: todas las acciones a través de ChatOps/pipeline; registros en almacenamiento inmutable.
PII/secretos - no se utilizan en artefactos de entrenamiento; datos despersonalizados.
Regulación: si la simulación afecta a las comunicaciones del cliente - etiquetar «enseñanza» en canales privados; los cargos públicos no se imitan.

10) Evaluación y AAR → RCA → CAPA

AAR (After Action Review) - inmediatamente después del ejercicio: lo que esperaban/veían que funcionaba/no.
RCA - para fallas significativas (por ejemplo, una escalada no funcionó) en la plantilla RCA.
CAPA: lista de acciones con propietarios/fechas límite/métricas de efectos (cambios en playbucks, alertas, arquitectura).
Puntos de control - D + 14/D + 30: comprobación de ejecución, mini drill repetido en lugares vulnerables.

11) Documentación y artefactos

Plan de simulación: objetivos, guión, injertos, participantes, ventanas, criterios de éxito.
Timeline (UTC): T0...Tn, soluciones de IC, pasos técnicos, apdates.
Fotos de dashboards/registros, extractos de alertas y estados.
Informe final: métricas, discrepancias con playbooks, CAPA.
Actualizaciones de documentación: edición de runbook/SOP/contactos, enlaces a nuevos dashboards.

12) Frecuencia y cobertura

Tabletop: 2-4 veces al mes (por subprocesos y roles clave).
Días de juego en el estanque: 1-2 veces al mes.
Casos de chaos (prod-light): trimestralmente, estrictamente por gatitas.
Enseñanzas DR: 1-2 veces al año con cambio real.
Comms-drill: mensual para entrenar plantillas y SLA de los apdates.

13) Hojas de cheques

Antes de la simulación

• Escenario, «injertos», criterios de éxito, ventanas de seguridad.
• Los roles, los canales, el estado de las plantillas están alineados.
• Se verificó la disponibilidad de stands/banderas/dashboards.
• Se ha documentado un plan de cancelación y reversibilidad.
• Se evalúan los riesgos y el impacto en los SLO/clientes.

Durante

• SEV asignado, versiones libres (si es necesario).
• Comunicaciones por horario, formato sostenido.
• Todas las acciones a través de herramientas con auditoría.
• Scribe mantiene el protocolo, recoge los artefactos.
• Seguridad: se respetan las prohibiciones/restricciones.

Después de

• AAR realizado, informe guardado.
• RCA (cuando fallas) se inicia.
• CAPA formalizados con propietarios/plazos.
• Runbook/SOP/Contactos actualizados.
• Se ha planificado un retiro de los lugares vulnerables.

14) Anti-patrones

«Improvisación en lugar de plan» - no hay guión y criterios de éxito.
Riesgos sin gates y un plan de cancelación: los ejercicios se convierten en un incidente.
Practica sólo la técnica sin comunicaciones y escalada.
Ausencia de AAR/RCA: el equipo no aprende.
Caos prod sin observación y SLO-gardrailes.
Derechos opacos: ediciones manuales secretas en venta.

15) Mini plantillas

Agenda del Día del Juego (60-90 min)

1. Brief (5 min) → Objetivos, roles, seguridad.
2. Escenario T0 (5 min) → Presentación de síntomas.
3. Triage/Escalada (10 min).
4. Diagnóstico + acciones (30-45 min) - 1-2 «injecta».
5. Restauración y verificación (10 min).
6. AAR (15 min) - Conclusiones, CAPA.

Plantilla AAR (breve)

What was expected:
What happened:
What worked:
What didn't work:
Solutions and why:
Actions (CAPA) with deadlines:
Responsible persons:
Retest Date:

16) Resultado

Las simulaciones de incidentes son un «simulador» para personas, procesos y arquitectura. Los ejercicios regulares, seguros y medibles convierten las crisis en una rutina: el equipo reacciona más rápido, los playbooks funcionan realmente, la arquitectura es más sostenible y el regulador y los clientes ven la madurez de la función operativa. Lo principal son objetivos claros, puertas seguras, buenas métricas y AAR→RCA→CAPA obligatorio.