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

Roles durante un incidente

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

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

En un equipo de hasta 5 personas se suelen separar el IC y el Technical lead, y el IC asume los demás roles.

Niveles de severity

Define 3-4 niveles de gravedad por adelantado:

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

Procedimiento SEV1: los primeros 15 minutos

1. 00:00 - Detección. La 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 un canal de comunicación dedicado (Slack #incident-N o Discord) y se llama al Technical lead.
3. 00:05 - Primer status update. En la status page pública: "Investigating reports of [problema]." Email a las personas internas que deberían saberlo.
4. 00:10 - Initial diagnostics. Comprueba los deploys recientes, los gráficos de monitoring y los error logs. ¿Qué cambió en los últimos 30-60 min?
5. 00:15 - Decisión: ¿rollback, hotfix o workaround? Si no es inmediatamente claro, el IC escala o llama a más ingenieros.

Comunicación: la regla "5 + 30"

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

El primer update debe producirse dentro de los 5 minutos posteriores a la detección, independientemente de si ya conoces la causa.

Rollback por defecto

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

El rollback requiere tener:

• Versionado de despliegue (Docker tags, Git tags, artefacto de deployment)
• Database migrations backwards compatible (si la nueva versión elimina una columna, la antigua no la 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 un documento con esta estructura:

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

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

Rotación on-call

Para un equipo con producto 24/7:

• Las rotaciones semanales son el punto óptimo - las más cortas queman, las más largas sobrecargan al on-call primario
• Mantén siempre un on-call primario + secundario. El secundario toma el relevo cuando el primario no reacciona en 5 min.
• Compensa el paging nocturno y de fin de semana (pago extra o tiempo libre)
• Implanta un "on-call review" mensual - a quién despertaron más a menudo y 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 rentabilizan en la primera caída mayor - menos caos, MTTR más corto, mejor comunicación con los clientes y un equipo que sabe qué hacer.

Empieza con detección automática

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

Iniciar monitorización →