Claude Simulacros de Resiliencia Caótica

Referencias oficiales: Best Practices · Hooks · Security · GitHub Actions

Por qué los simulacros son obligatorios en madurez avanzada

Un runbook no ejercitado sigue siendo solo documentación.

Los simulacros convierten política escrita en comportamiento operativo verificable.

Modelo de tiers de simulacro

Paquete de diseño previo

Antes de cada simulacro prepara:

• declaración de escenario
• firma esperada del fallo
• límite de radio de impacto
• condición de parada
• observadores y owner de score

Sin paquete de diseño no hay comparabilidad entre simulacros.

División por lanes

• Lane de inyección de fallo: activa el escenario de forma segura
• Lane de respuesta: ejecuta contención y mitigación
• Lane de verificación: corre checks y captura evidencia
• Lane de comunicación: actualiza timeline y avisos de escalación

Asigna un owner por lane y un comandante global de simulacro.

Scorecard de resiliencia

Puntúa cada simulacro con 0/1 por fila:

• detección dentro de ventana objetivo
• handoff de ownership explícito
• decisión de mitigación reversible
• evidencia de verificación fresca
• owner de seguimiento asignado

Si el score es < 4/5, repite con alcance más acotado.

Protocolo de checkpoints de decisión

En cada checkpoint fuerza una opción explícita:

1. continuar mitigación
2. rollback a estado estable
3. escalar y pausar rollout

Decisiones implícitas son riesgo oculto.

Regla de manejo de desvíos

Si la ejecución diverge del escenario:

• detener simulación
• registrar desvío
• convertir desvío en input del siguiente simulacro

Nunca maquilles comportamiento inesperado.

Programa trimestral de resiliencia

Cada trimestre:

• ejecutar al menos un simulacro completo
• rotar rol de comandante
• revisar dimensiones con score bajo recurrente
• retirar controles que no mejoran confiabilidad

La resiliencia mejora por calidad de iteración, no por cantidad de simulacros.

Anti-patrones avanzados

Simulacro como teatro de performance

Si se optimiza para apariencia, la señal de resiliencia colapsa.

Repetir siempre el mismo escenario

El equipo memoriza una ruta en vez de ganar adaptabilidad.

Seguimiento sin owners

Acciones sin owner se convierten en deuda de confiabilidad.

Checklist rápido

Antes de cerrar un ciclo de simulacro:

• scorecard registrado
• checkpoints de decisión logueados
• owners de seguimiento asignados
• próximo escenario borrador listo

Claude puede acelerar la respuesta. Los simulacros prueban que la respuesta sea correcta.

Catálogo de escenarios de simulacro

Rota escenarios para evitar respuestas memorizadas.

Set de confiabilidad

1. Tormenta de timeout en dependencia — latencia API principal fuera de SLO.
2. Release con drift de configuración — un entorno usa flags desactualizados.
3. Saturación de backlog de colas — retraso de procesamiento en cascada.
4. Apagón de observabilidad — panel crítico cae durante incidente.
5. Owner no disponible — on-call principal ausente en primer checkpoint.

Combina 1 fallo técnico + 1 fallo de coordinación por ciclo.

Paquete de scoring para observadores

Evalúa comportamiento, no carisma.

Incluye enlaces de evidencia por score.

Plantilla de timeline (45 min)

• 00:00–05:00 briefing + criterios de éxito
• 05:00–15:00 primera señal + decisión de triage
• 15:00–30:00 ejecución de mitigación
• 30:00–40:00 verificación de estabilidad
• 40:00–45:00 debrief + asignación de seguimiento

Si se excede tiempo, registra causa como deuda de proceso.

Scripts de comunicación bajo presión

Update de primeros 5 minutos

Incident drill started at <time>
Observed signal: <summary>
Current branch: triage/mitigate/rollback
Next checkpoint: <time>
Commander: <name>

Update de checkpoint de escalación

Escalation reason: <threshold breach>
Decision: continue | rollback | pause
Immediate owner: <name>
Verification owner: <name>
Next update at: <time>

Matriz de decisiones de debrief

Clasifica hallazgos en:

• Fix now (alto riesgo + bajo esfuerzo)
• Next cycle (alto riesgo + esfuerzo medio)
• Observe (impacto incierto)
• Drop (sin valor medible)

No dejes hallazgos sin categoría.

Política de mutación de escenarios

Mutar al menos una variable por ciclo:

• timing del fallo
• tipo de dependencia que falla
• disponibilidad de owners
• restricción de canal de comunicación

Documenta el porqué de la mutación para interpretar cambios de score.

Gate de cierre del ciclo

Cierra ciclo solo cuando:

• scorecard + evidencia archivados
• al menos una acción con owner asignado
• próximo escenario mutado borrador listo
• comandante firma notas de calidad de decisiones

Sin gate, los simulacros se vuelven eventos aislados.

Normalización de score de simulacros

Para comparar semanas, normaliza score:

• en escenarios estilo SEV-1 pondera más detección y decisión
• en escenarios multi-stakeholder pondera más comms
• publica score crudo y score ponderado

Ponderación ejemplo

• detection quality: 30%
• decision quality: 25%
• ownership clarity: 20%
• evidence quality: 15%
• communication cadence: 10%

Si cambias pesos, documenta el motivo.

Regla del commander para simulacro estancado

Si pasan >5 minutos sin decisión:

1. detener debate adicional
2. forzar rama explícita (continue/rollback/escalate)
3. asignar owner de ejecución
4. fijar checkpoint en 5 minutos

Esto evita parálisis analítica.

Regla de conversión de debrief

Todo hallazgo debe terminar como:

• control mergeado
• control planificado con owner/fecha
• rechazo documentado con razón

No dejes hallazgos huérfanos.

Estructura de campaña trimestral

Ejecuta campañas, no eventos sueltos.

• Mes 1: foco en velocidad de respuesta (detección + decisión)
• Mes 2: foco en coordinación (handoff + integridad de comunicación)
• Mes 3: foco en calidad de recuperación (verificación + follow-up)

Así la tendencia de score se vuelve interpretable.

Modificadores de estrés

Añade uno por simulacro:

• visibilidad de señal retrasada
• disponibilidad parcial de owners
• pedidos conflictivos de stakeholders
• degradación de canal de observabilidad

Estos modificadores exponen fragilidad real.

Evidencia mínima por simulacro

Toda salida debe incluir:

• timeline con timestamps de decisión
• snippets de verificación a nivel comando
• cadena de handoffs de ownership
• updates enviados vs prometidos
• mapeo de acciones de seguimiento

Sin esto, el scorecard es solo narrativa.

Recalibración cada 3 simulacros

Después de cada tercer simulacro:

1. comparar tendencia de score ponderado
2. detectar dimensiones sobre-ponderadas
3. ajustar pesos con justificación
4. publicar rúbrica antes del siguiente ciclo

La recalibración transparente reduce gaming.

Modelo federado de simulacros multi-equipo

Para organizaciones grandes, usa federación:

• plataforma: escenarios de infraestructura compartida
• producto: escenarios de rutas de cliente
• seguridad: inyección de fallos en límites de confianza

La federación revela acoplamientos entre equipos antes del incidente real.

KPI de calidad del programa

Mide calidad del programa, no solo score puntual:

• % de simulacros con bundle de evidencia completo
• % de follow-up cerrado en fecha
• mediana de tiempo hasta primer checkpoint explícito
• tasa de recurrencia del mismo hallazgo

Si la tendencia empeora, reduce alcance y recupera rigor.

Controles de sesgo para observadores

Para reducir sesgo:

• rotar observadores cada ciclo
• exigir evidencia para scores extremos
• cuando sea posible, cegado parcial por equipo

Mejor scoring produce mejores decisiones de hardening.