Playbooks

Incident Response

Salir

Niveles de severidad

Clasificar correctamente un incidente determina quién responde, qué tan rápido y quién necesita saber. En la duda, escalá para arriba.

🔴 P1 Crítico
El sistema está caído o unusable para todos los usuarios. Impacto directo en ingresos o datos.
Criterios
  • Site completamente caído (5xx para todas las rutas)
  • Pérdida o corrupción de datos de usuario
  • Brecha de seguridad con datos expuestos
  • Funcionalidad core inaccesible (login, pago, checkout)
Respuesta
Todo el equipo para lo que está haciendo. War room inmediata.
SLA
Respuesta en 5 min. Resolución objetivo: 1 hora.
🟠 P2 Alto
Funcionalidad importante degradada pero con workaround. Afecta a un subconjunto de usuarios.
Criterios
  • Feature importante lenta o con errores intermitentes
  • Página secundaria caída (blog, docs, settings no críticas)
  • Emails o notificaciones no se envían
  • Integración externa rota con impacto parcial
Respuesta
Equipo responsable prioriza sobre trabajo planeado.
SLA
Respuesta en 15 min. Resolución objetivo: 4 horas.
🟡 P3 Medio
Bug no crítico. No afecta la operación pero degrada la experiencia.
Criterios
  • Bug visual sin impacto funcional
  • Feature secundaria con error reproducible
  • Problema de performance sin impacto en core
  • Error en ambiente de staging solamente
Respuesta
Se planifica en el sprint actual o siguiente.
SLA
Respuesta en 1 hora. Resolución objetivo: próximo release.

Checklist: primeros 15 minutos

Los primeros 15 minutos definen si un incidente se resuelve en 30 minutos o en 4 horas. Seguí esta lista — no improvises bajo presión.

00:00
Detectás o te reportan el incidente
  • No entres en pánico. Respirá. Un cerebro en calma resuelve 10× más rápido.
  • Anotá la hora exacta. Parece obvio, pero en retrospectiva nunca te acordás.
  • Si el incidente viene de un usuario o alerta, copiá el mensaje textual en el thread.
00:01
Confirmá que es real
  • Reproducí el error desde otra sesión, browser o dispositivo.
  • Verificá si es un problema de una sola persona o generalizado.
  • Revisá si hay cambios recientes deployados en las últimas 2 horas.
00:03
Abrí el canal de comunicación
  • Posteá en #alerts: "INCIDENT: [descripción breve]. Investigando. Voy a actualizar en este hilo cada 10 min."
  • Si es P1, iniciá una call en el canal de voz. La comunicación escrita es muy lenta para P1.
  • Asigná un rol de comunicador si hay más de 2 personas. Uno resuelve, el otro informa.
00:05
Diagnóstico inicial
  • Abrí el dashboard de monitoreo. Mirá errores, latencia, throughput.
  • Revisá los logs recientes filtrando por ERROR y el timestamp del incidente.
  • Si hay deploy reciente, ese es tu primer sospechoso. Siempre.
  • Identificá el alcance: ¿afecta a todos los usuarios? ¿Una región? ¿Un endpoint?
00:10
Decidí: ¿rollback o fix forward?
  • Si el incidente empezó después de un deploy → rollback inmediato. No pierdas tiempo debuggeando.
  • Si no hay deploy reciente → investigá la causa raíz. ¿Pico de tráfico? ¿Dependencia externa caída? ¿DB lenta?
  • Documentá tu hipótesis en el thread. Aunque sea equivocada, muestra tu línea de pensamiento.
00:15
Actualizá al equipo
  • Posteá en #alerts: "UPDATE [15 min]: Esto es lo que sabemos, esto es lo que estamos haciendo, este es el ETA."
  • Si no hay avance, escalá. Mejor pedir ayuda a los 15 min que a las 2 horas.
  • Si el incidente es P1 y no hay resolución a la vista, notificá al liderazgo.

Canales y templates

Una comunicación pobre durante un incidente genera más caos que el incidente mismo. Copiá, pegá, adaptá.

Canales

# #alerts Slack
Canal dedicado para incidentes. Todo el equipo debe tener notificaciones activas.
# War room Google Meet / Zoom
Call de voz para P1. Más rápida que Slack. Quien resuelve comparte pantalla.
# #general Slack
Anuncio post-resolución para que todo el equipo sepa qué pasó.
# Status page status.fundamental.lat
Comunicación externa. Actualizar apenas se confirma el incidente y al resolver.
# PagerDuty / OpsGenie On-call
Escalamiento automático si nadie responde en 5 min (P1) o 15 min (P2).

Templates de mensajes

#alerts Inicio del incidente 
🚨 INCIDENT: [Título descriptivo]
Severidad: P1 / P2 / P3
Scope: [% de usuarios / endpoint / región]
Inicio: [HH:MM UTC]
Estado: Investigando

Voy a actualizar este hilo cada 10 minutos. No hacer deploy hasta nuevo aviso.
#alerts Update (cada 10-15 min) 
📡 UPDATE [HH:MM UTC] — +10 min
Lo que sabemos: [hallazgos concretos]
Lo que estamos haciendo: [acción actual]
Próximo paso: [siguiente acción]
ETA resolución: [si se conoce]

Seguimos en esto.
#alerts Resolución 
✅ RESUELTO [HH:MM UTC] — [duración total]
Causa: [una frase]
Qué hicimos: [acción concreta: rollback, hotfix, config change]
Impacto: [usuarios afectados, datos, duración]
Postmortem: [link al doc]

Gracias por la paciencia. Aprendimos algo hoy.
Email / stakeholder P1 que dura más de 30 min 
Asunto: Incident P1 — [servicio] — actualización

Hola equipo,

Estamos atendiendo un incidente P1 que afecta a [servicio/feature].
Inicio: [HH:MM UTC]
Impacto: [descripción en lenguaje no-técnico]
Acción: [qué estamos haciendo, en español simple]

Próxima actualización en 30 minutos.
—
Equipo de ingeniería

Postmortem

El postmortem no es un castigo. Es la ingeniería forense que convierte un incidente en una mejora permanente del sistema.

Template de postmortem
## Resumen
Dos o tres frases. Qué pasó, a quién afectó, cuánto duró. Lo que un ejecutivo necesita saber.
## Timeline (UTC)
Tabla con hora, evento, acción. Desde la detección hasta la resolución. Sé honesto — incluye las decisiones incorrectas.
## Causa raíz
Los 5 porqués. No te quedes en el síntoma. Si la causa raíz es "falló el servidor", preguntá por qué falló.
## Qué salió bien
Reconocé lo que funcionó: alerta temprana, rollback rápido, comunicación clara. Esto se replica.
## Qué salió mal
Sin culpables, sin eufemismos. "El alerta llegó 8 minutos tarde." "Nadie sabía cómo hacer rollback del worker."
## Action items
Lista concreta con responsable y fecha. Nada de "mejorar monitoring" — "Agregar alerta de latency > 2s en /api/checkout. @Ana, 20 mayo."
## ¿Cómo evitamos que vuelva a pasar?
No siempre se puede evitar. Pero siempre se puede detectar más rápido, responder mejor, o reducir el blast radius.

Guía de rollback

Hacé rollback sin miedo. Un rollback limpio en 2 minutos es más profesional que un hotfix en 20.

1
Identificá el último deploy bueno
# En GitHub Actions, buscá el último deploy exitoso
git log --oneline -10  # en tu repo
El 90% de los incidentes en producción vienen de un deploy. Siempre empezá por acá.
2
Ejecutá el rollback
# Opción A: revertir el commit (si es un hotfix chico)
git revert <commit-id> && git push

# Opción B: redeploy del último release bueno
# En GitHub Actions → seleccioná el workflow run anterior → Re-run
Revertir el commit es más limpio (preserva historial). Redeploy del runner es más rápido (menos pasos manuales).
3
Verificá que el rollback funcionó
# Esperá que el deploy termine
curl -s https://api.staging.fundamental.lat/health
# Revisá el dashboard de errores — deben volver a niveles normales
Un rollback no exitoso es peor que el incidente original. Verificá antes de comunicar "resuelto".
4
Si el rollback no resuelve...
  • No es un problema de código → es infraestructura, dependencia externa, o datos.
  • Revisá el dashboard de la DB: conexiones, locks, slow queries.
  • Revisá dependencias externas: ¿está caído el gateway de pago? ¿el servicio de email?
  • Si es la DB, no toques datos sin antes hacer un backup. En serio.
  • Si es una dependencia externa, activá el circuito breaker si existe. Si no, comunicá y esperá.
5
Mitigación sin rollback
  • Feature flag: desactivá la feature problemática sin deploy.
  • Rate limiting: si es sobrecarga, limitá requests por IP o endpoint.
  • Failover: si es una región, redirigí tráfico a otra.
  • Degradación elegante: desactivá features no críticas para reducir carga.
  • Escalado manual: aumentá instancias si es un pico de tráfico legítimo.

Lecciones que salvan vidas

1. El 90% de los incidentes graves vienen de un deploy. Si algo falla y deployaste hace menos de 2 horas, hacé rollback primero, preguntá después.
2. Nunca debuguees en producción. Hacé rollback, reproducí en staging, arreglá, redeployá.
3. La comunicación salva más vidas que el código. Un equipo que no sabe qué está pasando toma malas decisiones.
4. El postmortem no es para buscar culpables. Es para que el mismo incidente no pase dos veces.
5. Practicá el rollback en frío. Si la primera vez que hacés rollback es durante un P1, ya perdiste.