¿Cómo se ve realmente un buen proceso de respuesta a incidentes y un postmortem sin culpa?

#Cinco etapas, y dónde fallan realmente los equipos

Un incidente es un evento no planeado que degrada o interrumpe un servicio lo suficientemente grave como para requerir una respuesta humana activa, no algo que el monitoreo absorbe silenciosamente por sí solo. El ciclo de vida tiene cinco etapas, y lo interesante para una entrevista no es tanto "nombra las etapas" sino "qué es lo que específicamente sale mal en cada una":

1. Detectar — se dispara una alerta (una alerta de burn-rate de SLO, un pico en la tasa de error, un chequeo sintético fallido) o un humano lo reporta primero (un ticket de soporte, un tuit, un mensaje de Slack de otro equipo). El tiempo entre "el problema comenzó" y "alguien con capacidad de actuar se enteró" es tu tiempo medio de detección (MTTD), y depende casi por completo de qué monitoreas y qué tan sensibles son tus alertas: un incidente que empieza con una queja de un cliente en lugar de una alerta es en sí mismo un hallazgo que vale la pena documentar, no solo una captura afortunada.
2. Triage — evaluar la severidad, decidir a quién hay que avisar, y declarar formalmente el incidente (un canal de incidente, una alerta, un incident commander asignado). Aquí es donde una escala de severidad indefinida causa daño real: sin niveles acordados, todo se trata como máximamente urgente, lo cual quema al equipo de guardia y, peor aún, hace que un incidente genuinamente crítico no se distinga de uno cosmético.
3. Mitigar — detener la hemorragia. Esto explícitamente no es lo mismo que arreglar la causa raíz: revertir un deploy problemático, hacer failover a una región sana, activar el interruptor de emergencia de un feature flag, o reiniciar un proceso colgado son todas mitigaciones que restauran la métrica de estado estable sin que nadie entienda todavía por qué se rompió. El objetivo de esta etapa es que la métrica vuelva a la normalidad; la explicación completa puede esperar.
4. Resolver — confirmar que la mitigación realmente se sostuvo, durante una ventana de observación real y contra dashboards reales, no solo "el error paró por un minuto". Comunicar la resolución a quien haya sido informado del incidente (status page, interesados), y cerrar formalmente el incidente.
5. Postmortem — un análisis escrito y sin culpa (blameless), producido mientras el recuerdo está fresco (48-72 horas es una ventana habitual), que cubre una línea de tiempo, el impacto real (usuarios afectados, duración, ingresos si aplica), los factores contribuyentes —en plural, porque los incidentes de producción casi nunca tienen una sola causa— y una lista de acciones de seguimiento, cada una con un dueño nombrado y una fecha límite.

#Los roles que evitan que las etapas 2 y 3 se conviertan en caos

Dos roles importan más allá de quien realmente arregla el problema. El incident commander coordina la respuesta —decide qué se intenta, en qué orden y quién lo hace— sin necesariamente tocar el teclado él mismo; su trabajo es evitar el modo de falla muy común de cinco ingenieros probando arreglos distintos por su cuenta al mismo tiempo, pisándose los cambios unos a otros. El líder de comunicación se encarga de actualizar a los interesados y el status page, específicamente para que los ingenieros que están diagnosticando no sean interrumpidos cada diez minutos con "¿alguna novedad?" de personas que no van a arreglar nada. En un equipo pequeño estos roles se combinan en una sola persona; el punto no es el organigrama, sino que alguien sea explícitamente responsable de la coordinación y la comunicación como trabajos separados de la solución técnica.

#Sin culpa no significa sin responsabilidad

La parte de "sin culpa" (blameless) se malinterpreta a menudo como "nadie es responsable de nada", que no es lo que significa ni por qué funciona. La afirmación real es más estrecha y más útil: el error de una persona durante un incidente casi siempre es evidencia de una brecha sistémica —una salvaguarda faltante, una prueba que debería haber atrapado esto, una alerta que debería haberse disparado antes, un paso del runbook que era ambiguo, un pipeline de despliegue que dejó que un cambio sin probar llegara al 100% del tráfico sin pasar por una etapa canary. El lenguaje enfocado en culpar ("Juan debería haber probado esto con más cuidado") detiene la investigación en el primer humano de la cadena y no produce ningún arreglo, porque no puedes desplegar un parche para "ser más cuidadoso". El lenguaje sin culpa ("el pipeline de despliegue permitió que un cambio sin probar llegara a producción sin pasar por una etapa canary") apunta a algo que sí puedes cambiar, y es también la razón por la que los postmortems sin culpa producen líneas de tiempo más precisas en la práctica: los ingenieros que no temen ser culpados están dispuestos a decir en voz alta "vi la alerta y la descarté como ruido", que es exactamente el detalle que lleva al arreglo real.

Las acciones de seguimiento siguen necesitando un dueño y una fecha límite: lo de "sin culpa" tiene que ver con hacia dónde apuntas el análisis, no con si alguien es responsable de darle seguimiento después.

#Lo que realmente sale mal, una y otra vez

• Sin escala de severidad definida — todo es "urgente", se instala la fatiga de alertas, y el equipo pierde la capacidad de distinguir un SEV1 real de un SEV3.
• Sin incident commander nombrado — varias personas arreglan cosas en paralelo sin coordinación, y se hacen cambios duplicados o contradictorios en medio del incidente.
• Postmortems que se saltan porque "ya lo arreglamos" — la mitigación atendió el síntoma; sin el postmortem, nadie busca el segundo y tercer factor contribuyente, y el mismo tipo de incidente vuelve a ocurrir de otra forma.
• Acciones de seguimiento sin dueño ni fecha límite — quedan registradas y nunca ocurren, y el siguiente postmortem descubre la misma brecha que un postmortem anterior ya había identificado.

🧠 Check your understanding
0/2 · 0/2 answered
1. Durante la etapa de mitigación de la respuesta a incidentes, ¿cuál es el objetivo principal?
Entender y documentar por completo la causa raíz del incidenteAsignar un nivel de severidad al incidenteRestaurar la métrica de estado estable lo más rápido posible, incluso sin conocer todavía la causa raízEscribir el postmortem sin culpa mientras el incidente sigue activo
2. ¿Qué significa realmente 'sin culpa' (blameless) en una cultura de postmortems blameless?
Que solo los ingenieros senior pueden escribir el postmortemQue los postmortems son opcionales si el equipo ya arregló el síntoma inmediatoQue ningún individuo es responsable de las acciones de seguimiento despuésQue el análisis apunta a las brechas sistémicas de proceso, herramientas o salvaguardas, en lugar de a la falla personal de un individuo