Son las 2:47 de un martes cualquiera. El dashboard de error rate pasa de 0.2% a 18% en cuatro minutos y las alertas de PagerDuty empiezan a apilarse. Todavía nadie sabe qué deploy lo causó, pero alguien en el canal de incidentes ya escribió la frase que define si el resto del mes va a ser productivo o no: "a ver quién tocó qué".
Esa frase es el momento exacto donde la mayoría de los equipos arruina la respuesta a un incidente. No porque encontrar el cambio que rompió todo esté mal, eso hay que hacerlo rápido, sino porque enmarcarlo como una cacería de culpables cambia el comportamiento de la gente durante la crisis. Un ingeniero que tiene miedo de admitir "yo hice ese deploy hace veinte minutos" tarda más en decirlo, y esos veinte minutos de silencio son los que separan un incidente de quince minutos de uno de dos horas.
Qué se hace en los primeros minutos
La primera decisión no es encontrar la causa raíz, es contener el daño. Rollback si el cambio es reciente y reversible, feature flag apagado si el código nuevo está detrás de uno, tráfico redirigido a una región sana si el problema es de infraestructura. La causa raíz se investiga después, con el sistema estable. Mezclar diagnóstico con mitigación es el error más común en incidentes que se alargan: la gente se pone a leer logs en vez de apretar el botón que corta la hemorragia.
Un ejemplo real de este tipo de problema: una migración de base de datos que agrega un índice sin usar CONCURRENTLY en Postgres. Localmente corre en 200 milisegundos porque la tabla de test tiene 40 filas. En producción, con 80 millones de filas, la migración toma un lock exclusivo sobre la tabla durante 40 minutos y tira abajo cada request que necesita escribir ahí. Nadie tocó código de negocio, el bug no está en ningún pull request revisado con cuidado, está en un comando de infraestructura que nadie corrió contra un volumen de datos realista.
Por qué la cultura blameless no es sinónimo de sin consecuencias
Blameless no significa que nadie se hace cargo de nada, significa que el análisis se enfoca en el sistema que permitió el error y no en la persona que apretó el botón. Si un ingeniero pudo correr esa migración sin CONCURRENTLY contra producción, la pregunta útil no es "por qué fue tan descuidado", es "por qué nuestro pipeline de CI no bloqueó una migración riesgosa antes de que llegara a ese punto". La primera pregunta termina en una charla incómoda de recursos humanos. La segunda termina en un check automático que previene la próxima instancia del mismo problema, sin importar quién esté de guardia ese día.
El postmortem que sirve, no el que se archiva
Un postmortem útil tiene cuatro partes no negociables: una línea de tiempo con timestamps reales sacados de logs y métricas (no de memoria, la memoria durante un incidente de dos horas es pésima), el impacto medido en números concretos (usuarios afectados, minutos de downtime, revenue perdido si aplica, no "fue grave"), la causa raíz técnica sin nombres propios en la narrativa, y una lista de action items con dueño y fecha, no una lista de buenas intenciones.
La parte que más se salta es el seguimiento de esos action items. Es común ver postmortems excelentes con cinco tareas de seguimiento, de las cuales tres siguen abiertas seis meses después porque nadie las priorizó contra el roadmap de producto. Si tu proceso de incidentes no tiene un mecanismo para que esos items compitan de verdad por tiempo de ingeniería, el postmortem es teatro: documenta el problema pero no lo arregla, y el mismo tipo de incidente vuelve.
Lo que cambia en el sistema, no en la persona
Los equipos que reducen la frecuencia de incidentes graves no lo hacen contratando gente más cuidadosa, lo hacen agregando capas que hacen que el error individual sea menos costoso: canary deployments que exponen un cambio al 5% del tráfico antes que al 100%, feature flags que permiten apagar código nuevo sin un rollback completo, alertas basadas en SLOs con error budget en vez de umbrales arbitrarios, y runbooks escritos para el incidente típico en vez de improvisar cada vez. Ninguna de estas cosas evita que alguien cometa un error. Todas reducen el radio de la explosión cuando pasa, que es la única variable que en la práctica podés controlar.
Un incidente grave no es una falla moral de nadie, es información sobre dónde tu sistema es frágil que hasta ese momento no tenías. Los equipos senior no son los que nunca rompen producción, son los que tienen un proceso que convierte cada incidente en una mejora concreta al sistema, en vez de gastar la energía del equipo buscando a quién señalar mientras el reloj de MTTR sigue corriendo.
