Playbook de Recuperación de Incidentes en Codex — Respuesta Determinista Bajo Presión

Official References: Best Practices · Review · Worktrees · Automations

Por qué existe este playbook

En incidentes, los fallos suelen ser primero de proceso y después de tecnología:

• ownership ambiguo
• snapshots de evidencia débiles
• decisiones de rollback tardías

Este playbook mantiene la respuesta con Codex en modo determinista sin perder velocidad de recuperación.

Matriz de severidad

Declara severidad al inicio y ajústala solo con evidencia.

Protocolo de los primeros 15 minutos

• asignar owner del incidente y suplente
• congelar merges no relacionados en la superficie afectada
• capturar evidencia base (comandos fallidos, logs, radio de impacto)
• abrir tracker de lanes con next owner explícito por lane

Sin next owner no hay continuidad confiable.

Modelo de recuperación en 4 lanes

Ejecuta en paralelo con fronteras claras:

• Lane de triage: clasificar severidad y confianza
• Lane de mitigación: preparar desactivación por flag / hotfix / rollback
• Lane de verificación: reruns reproducibles y checks de seguridad
• Lane de comunicación: cadencia de updates para stakeholders

Si varios lanes tocan los mismos archivos, define un merge owner de inmediato.

Escalera de decisión reversible

Elige primero la opción más segura y reversible:

1. desactivar ruta riesgosa por flag/config
2. aplicar patch acotado y verificable
3. rollback completo a la última revisión estable

Registra por qué descartas alternativas, no solo la opción elegida.

Estándar de paquete de evidencia

Cada checkpoint mayor debe incluir:

• severidad actual + owner + timestamp
• sistemas/usuarios afectados
• comandos ejecutados y salida
• riesgos residuales
• siguiente checkpoint + owner

Este paquete es la fuente de verdad para handoffs.

Gate de cierre de recuperación

Cierra solo cuando todo sea verdadero:

• mitigación aplicada
• rerun fresco en verde
• riesgos residuales documentados
• tarea de hardening asignada con owner/fecha

"Parece estable" no es criterio de cierre.

Bucle de hardening post-incidente

Dentro de 24 horas:

• publicar timeline con decisiones clave
• añadir al menos una automatización de guardrail
• añadir una prueba de regresión para la clase de causa raíz
• asignar owner y fecha para seguimiento

Los incidentes cuestan caro. Conviértelos en controles duraderos.

Anti-patrones avanzados

Modo héroe en un solo lane

Rápido al inicio, frágil en handoffs y ventanas de fatiga.

Mitigación sin cadencia de comunicación

Se despliega código, pero el equipo opera con supuestos desactualizados.

Cierre sin evidencia de rerun

El lenguaje de confianza no reemplaza evidencia de comandos.

Checklist rápido

Antes de declarar resuelto:

• severidad y ownership registrados
• ruta de mitigación justificada
• evidencia fresca de rerun adjunta
• seguimiento de hardening asignado

Codex acelera la recuperación. Este playbook mantiene la recuperación gobernable.

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.