Claude Playbook de Recuperación de Incidentes

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

Por qué existe este playbook

En incidentes, los equipos pierden tiempo cuando la propiedad y el estándar de evidencia no están claros.

Este playbook mantiene la recuperación asistida por Claude de forma determinista bajo presión.

Matriz de severidad

Protocolo de los primeros 15 minutos

• declarar severidad y owner del incidente
• congelar merges no relacionados en la superficie afectada
• capturar primer snapshot de evidencia (logs, checks fallidos, alcance)
• asignar siguiente owner por lane

Sin owner y sin snapshot no hay control confiable.

División de lanes de recuperación

Ejecuta lanes en paralelo con límites explícitos:

• Lane de investigación: hipótesis de causa raíz + reproducción
• Lane de mitigación: preparación de rollback/hotfix
• Lane de comunicación: línea temporal y actualización a stakeholders
• Lane de verificación: pruebas de regresión + seguridad de rollback

La superposición sin ownership suele producir trabajo duplicado y puntos ciegos.

Escalera de decisión

1. Desactivar feature-flag (opción más rápida y reversible)
2. Hotfix acotado (cuando el alcance es pequeño y verificable)
3. Rollback completo (si hay alta incertidumbre o superficie crítica)

Registra por qué descartaste alternativas, no solo por qué elegiste una.

Plantilla de paquete de evidencia

Cada checkpoint de decisión debe incluir:

• severidad actual + owner
• alcance impactado
• evidencia de comandos/logs
• riesgos residuales
• siguiente acción + fecha límite

Retro mínima post-incidente

Dentro de 24 horas documenta:

• disparador y brecha de detección
• qué ralentizó la mitigación
• qué aceleró la recuperación
• propuesta de cambio de guardrail
• owner + fecha objetivo

Un incidente es una lección cara. Captúrala mientras está fresca.

Anti-patrones avanzados

Modo héroe en un solo lane

Rápido al inicio, frágil después. Divide lanes temprano.

Hotfix mergeado sin cronología de comunicación

Se publica código, pero el equipo sigue con supuestos desactualizados.

Cierre del incidente sin rerun de verificación

Una afirmación "verde" sin evidencia de rerun no es cierre real.

Checklist rápido

Antes de cerrar:

• severidad + owner documentados
• decisión de mitigación registrada
• evidencia de rerun de verificación adjunta
• tarea de guardrail de seguimiento asignada

Claude ayuda con la velocidad. Este playbook preserva el control mientras avanzas rápido.

Biblioteca de escenarios (patrones de presión real)

Usa esta biblioteca para practicar el playbook con presión real, no con caminos ideales.

Escenario A — Falla de tokens de auth tras release

• Señal: pico súbito de 401/403 en un servicio.
• Riesgo: degradación de confianza + carga de soporte.
• Rama de decisión: rollback por flag vs hotfix acotado.
• Evidencia mínima: endpoints fallando, primer hash defectuoso, check de seguridad de rollback.
• Handoff: owner de investigación → owner de mitigación → owner de verificación.

Escenario B — Descuadre de estado de billing

• Señal: eventos de revenue no cuadran con ledger.
• Riesgo: exposición financiera/legal.
• Rama de decisión: freeze de escrituras vs replay selectivo.
• Evidencia mínima: tamaño de muestra, radio de impacto, frontera segura de replay.
• Handoff: doble aprobación de data owner + commander.

Escenario C — Fuga de permisos en flujo edge

• Señal: bypass de autorización de bajo volumen pero alto impacto.
• Riesgo: escalación a incidente de seguridad.
• Rama de decisión: rollback + revocación primero, parche después.
• Evidencia mínima: caso mínimo reproducible, prueba de revocación, snapshot de auditoría.

Bundle de artefactos de war-room (plantillas)

### Incident Command Snapshot
- Incident ID:
- Severity:
- Incident commander:
- Current phase: detection | containment | recovery | hardening
- Latest stable revision:
- Candidate mitigation path:
- Risk if we wait 30 minutes:
- Next checkpoint at:
- Next owner:

### Checkpoint Decision Record
- Timestamp:
- Evidence reviewed:
- Decision: continue mitigation | rollback | escalate+pause
- Why this decision now:
- Rejected alternatives:
- Owner for execution:
- Owner for verification:

Plantillas de escalación

Escalación interna de ingeniería

[INCIDENT][SEV-X] <short summary>
Impact: <users/systems>
Current decision: <path>
Immediate ask: <approval/resource>
Next update: <time>
Owner: <name>

Update para stakeholders

Status: investigating/mitigating/recovered
Customer impact: <plain language>
Current mitigation: <plain language>
Known unknowns: <top 1-2>
Next committed update time: <time>

Criterios de cierre (gate duro)

Cerrar response solo cuando todo sea verdadero:

1. mitigación ejecutada + verificada con evidencia fresca
2. trigger de rollback + owner documentados para ventana de 24h
3. riesgos residuales explícitos
4. owners y fechas de hardening asignados
5. timeline de comunicación completo

Si falta uno, el incidente sigue activo.

Revisión de 30 minutos tras cierre

Ejecuta revisión corta inmediata:

• ¿qué señal llegó primero pero se ignoró?
• ¿qué checkpoint demoró más?
• ¿dónde se volvió ambiguo el ownership?
• ¿qué guardrail habría reducido más el tiempo de resolución?
• ¿qué métrica debemos agregar o redefinir?

Convierte respuestas en backlog antes de perder contexto.

Checklist previo por proveedor

Antes de ejecutar el playbook, fuerza estos prechecks:

• Estado del repositorio: identificar revisión estable y validar rollback ejecutable ahora.
• Grafo de ownership: commander, mitigation owner, verifier owner y comms owner nombrados.
• Canal de evidencia: un único hilo/documento para todos los checkpoints.

Set mínimo de comandos previos

git rev-parse --short HEAD
git log --oneline -n 5
# agrega tu check de salud de servicio

Adjunta salida en el primer checkpoint.

Guardrails de calidad de decisión

Cada decisión debe incluir tres frases:

1. reversibilidad — ¿qué tan rápido deshacemos esto?
2. radio de impacto — ¿qué empeora si fallamos?
3. verificación — ¿qué señal exacta confirma éxito?

Si falta una, la decisión no cumple nivel avanzado.

Test de aceptación de handoff

Antes de pasar ownership:

• límite de alcance explícito
• unknowns abiertos listados
• próximo checkpoint comprometido
• trigger de rollback inmediato escrito

Este test reduce pérdida de contexto entre lanes.

Blueprint de comando en 60 minutos

Úsalo cuando la severidad es incierta pero el impacto ya existe.

• T+00–10: validar hipótesis de severidad, congelar merges riesgosos, asignar commander+deputy.
• T+10–20: definir ramas de mitigación y comprobar rollback ejecutable.
• T+20–35: ejecutar una rama de forma decisiva, sin mitigaciones contradictorias en paralelo.
• T+35–50: correr verificación y comparar contra baseline pre-incidente.
• T+50–60: publicar nota de decisión y fijar próximo checkpoint.

No es solo velocidad; es calidad de decisión sincronizada bajo presión.

Matriz de riesgo por dependencia

Clasifica dependencias antes de elegir mitigación.

Esta matriz evita decisiones “arreglamos todo con un parche”.

Protocolo para recomendaciones en conflicto

Si dos owners recomiendan rutas distintas:

1. registrar ambas en un único decision record
2. puntuar reversibilidad y radio de impacto
3. elegir la ruta más reversible salvo evidencia contraria
4. fijar checkpoint de reevaluación rápida (<=10 min)

El conflicto es normal; el conflicto sin estructura es riesgo.

Escalera de confianza de decisión

Etiqueta cada checkpoint:

• L1 (low): evidencia incompleta, solo acciones reversibles
• L2 (medium): evidencia parcial, mitigación acotada
• L3 (high): evidencia consistente, cierre o expansión permitidos

No cierres response con decisiones en nivel L1.

Matriz de estrategia de ramas de recuperación

Selecciona estrategia de rama de forma deliberada.

No mantengas las tres ramas activas sin un owner principal.

Paquete de revisión de cierre

Antes del cierre final, entrega un paquete único:

• timeline (timestamps + decisiones)
• resumen de diff de mitigación
• bundle de comandos de verificación
• registro de riesgos residuales
• enlaces al backlog de hardening

Debe permitir que un owner nuevo entienda el caso en 10 minutos.

Plantilla de nota para liderazgo

### Incident Leadership Note
- What happened:
- Why this decision path was chosen:
- Current confidence level (L1/L2/L3):
- What remains uncertain:
- What we need from leadership:
- Owner for next 24h watch:

Notas cortas y explícitas reducen re-discusión de decisiones.