Gemini Playbook de Recuperación de Incidentes

Referencias oficiales: Get Started · CLI Commands · Sub-agents · Skills

Por qué existe este playbook

Los incidentes en producción castigan a los equipos que no separan velocidad de control.

Este playbook define cómo un equipo de Gemini CLI se recupera rápido sin perder trazabilidad.

Matriz de severidad

Estándar de los primeros 15 minutos

• asignar owner del incidente y suplente
• congelar merges riesgosos del dominio afectado
• capturar evidencia base (comando fallido, logs, radio de impacto)
• abrir tracker de lanes con campos de next-owner

Si faltan campos next-owner, la calidad de escalación cae rápidamente.

Estructura de incidente en 4 lanes

• Lane de triage: clasificar impacto y nivel de confianza
• Lane de mitigación: preparar feature flag / hotfix / rollback
• Lane de verificación: reruns reproducibles y checks de seguridad
• Lane de comunicación: cadencia de updates internos/externos

Mantén scopes de escritura separados entre lanes siempre que sea posible.

Política de decisión

Prioriza la opción más reversible que restaure primero la seguridad del usuario.

Orden de decisión:

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

Paquete de evidencia del incidente

En cada checkpoint relevante guarda:

• severidad, owner, timestamp
• sistemas/usuarios afectados
• comandos ejecutados y salida
• riesgos residuales
• hora del siguiente checkpoint

Bucle de hardening post-incidente

Dentro de 24 horas:

• publicar línea temporal con pivotes de decisión
• agregar al menos una automatización de guardrail
• agregar una prueba de regresión para la clase de causa raíz
• asignar owner y fecha de seguimiento

Sin tarea de hardening, el incidente tiende a repetirse.

Anti-patrones avanzados

Ediciones paralelas en archivos compartidos sin mapa de ownership

Esto aumenta presión de merge justo cuando más importa la velocidad.

Declarar “resuelto” solo por intuición

Usa evidencia de rerun, no lenguaje de confianza.

Comunicar solo al cierre del incidente

Los stakeholders necesitan cadencia, no un único resumen final.

Checklist rápido

Antes de cerrar:

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

Gemini acelera la respuesta. Este playbook mantiene la respuesta 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.