Playbook de respuesta a incidentes para equipos pequeños y medianos

En resumen: Cuando el viernes a las 23:30 cae el servidor de producción, no es momento de inventar el procedimiento desde cero. Un playbook de respuesta a incidentes es un documento que define roles, comunicación y procedimientos antes de necesitarlos. Aquí un playbook mínimo adecuado para un equipo de 5-20 personas.

Roles durante un incidente

Roles claros eliminan el caos. Incluso un equipo pequeño necesita al menos:

• Incident Commander (IC) - gestiona el incidente, toma decisiones, escala. No escribe código.
• Technical lead - la persona que conoce el área problemática. Escribe el fix.
• Communications lead - actualiza status page, clientes, management. Para equipo pequeño puede ser el mismo que IC.
• Scribe - escribe timeline, quién hace qué, cuándo. Clave para post-mortem.

En equipo hasta 5 personas típicamente IC + Technical lead = 2 roles divididos, otros los toma IC.

Niveles de severity

Define 3-4 niveles de gravedad por adelantado:

• SEV1 (Critical) - servicio principal completamente no disponible. Se reacciona inmediatamente, paging incluso de noche.
• SEV2 (Major) - degradación significativa (parte de features, algunos usuarios). Reacción en 30 min durante horas laborales, en 1 h fuera.
• SEV3 (Minor) - pequeño impacto, workaround existe. Reacción al siguiente día laboral.
• SEV4 (Cosmetic) - sin impacto user-facing, va a queue normal.

Procedimiento SEV1: los primeros 15 minutos

1. 00:00 - Detección. Alerta llega del monitoring o de un cliente. Alguien en rotación on-call confirma que el problema es real.
2. 00:02 - Activación IC. Se abre canal de comunicación dedicado (Slack #incident-N o Discord). Se llama al Technical lead.
3. 00:05 - Primer status update. En status page pública: "Investigating reports of [problema]." Email a personas internas que deberían saber.
4. 00:10 - Initial diagnostics. Comprueba deploys recientes, gráficos de monitoring, error logs. ¿Qué cambió en los últimos 30-60 min?
5. 00:15 - Decisión: ¿rollback, hotfix o workaround? Si no es inmediatamente claro, IC escala o llama a más ingenieros.

Comunicación: la regla "5 + 30"

Actualización de status page al menos cada 30 minutos durante SEV1, aunque no tengas información nueva. "Seguimos investigando, ETA aún desconocido" es mejor update que silencio - los clientes al menos saben que alguien está trabajando en el problema.

El primer update debe ser dentro de 5 minutos de la detección. Independientemente de si conoces la causa.

Rollback como default

Para SEV1 que empezó poco después de un deploy, el rollback es la primera elección, no hotfix. Hotfix bajo presión de noche es fuente de más bugs. El rollback restaura un estado conocido bueno y da tiempo para diagnóstico calmado por la mañana.

Para rollback hay que tener:

• Versionado de despliegue (Docker tags, Git tags, artefacto de deployment)
• Database migrations backwards compatible (si la nueva versión drop-ea una columna, la antigua no se recupera)
• Procedimiento de rollback documentado (comandos, cuánto tarda, quién puede ejecutarlo)

Post-mortem en 48 horas

Después de cada incidente SEV1/SEV2 escribe documento con estructura:

1. Summary - 2-3 frases qué pasó, cuánto duró, a quién afectó
2. Timeline - tiempos exactos de detección, acciones clave, resolución
3. Root cause - por qué pasó (razón técnica + razón procedural)
4. Impact - número de clientes afectados, impacto business
5. What went well - lo que hicimos bien (apreciar al equipo)
6. What went wrong - donde perdimos tiempo
7. Action items - tareas concretas con owner y deadline (no "testar mejor" - mejor "añadir test de integración para payment flow en 14 días, owner: X")

Regla blameless post-mortem: No buscas culpable, buscas debilidad sistémica. "John desplegó mala versión" es conclusión incorrecta - la correcta es "el proceso de deploy no incluía fase canary que cogería el bug antes del rollout completo".

Rotación on-call

Para equipo con producto 24/7:

• Rotaciones semanales - más corto quema, más largo significa continuidad del contexto
• Siempre primario + secundario on-call. Secundario toma el relevo cuando primario no reacciona en 5 min.
• Compensación (pago extra, time-off) por paging nocturno y de fin de semana
• "On-call review" mensual - quién fue despertado a menudo, qué se puede automatizar

Herramientas

• Monitoring (ePulz.io, Datadog, New Relic) - detección + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - escalation, rotación, SMS/voz
• Status page (propia, ePulz.io, StatusPage.io) - comunicación externa
• Hosting runbook (Notion, GitHub Wiki, internal docs) - playbooks y runbooks
• Template postmortem (Confluence, Notion template) - estandarización

Conclusión

La respuesta a incidentes no se puede improvisar bajo presión. 30 minutos invertidos en escribir un playbook se devuelven en la primera caída mayor - menos caos, MTTR más corto, mejor comunicación con clientes y equipo que sabe qué hacer.

Empieza con detección automática

ePulz.io resuelve los primeros minutos de respuesta a incidente: detección + alerting por e-mail, Telegram y webhook a Slack / Discord / PagerDuty.

Iniciar monitorización →