La creencia más extendida sobre los incidentes de producción es que lo que realmente importa es la velocidad de respuesta: cuanto más rápido reaccione el equipo, mejor será el resultado. Esta premisa suena razonable hasta que se observa lo que realmente sucede en los primeros minutos de una crisis real: personas duplicando esfuerzos, nadie coordinando la comunicación con las partes interesadas, ingenieros atropellándose unos a otros en los canales y decisiones críticas tomadas por quien gritó más fuerte. La velocidad sin estructura no resuelve las incidencias, amplifica el caos.
Por qué la mayoría de los equipos todavía improvisan
Casi todos los equipos tienen algún runbook, algún canal #incident en Slack y alguna definición vaga de gravedad. El problema es que estas piezas existen de forma aislada, sin constituir un proceso coherente. Cuando realmente ocurre el incidente, nadie sabe quién está a cargo, quién habla con el cliente, quién documenta el cronograma. Cada persona actúa según su instinto, que es diferente del instinto de todos los que le rodean.
Esto no es un defecto de carácter. Es un defecto de diseño. Un proceso de respuesta a incidentes no surge naturalmente de la buena voluntad de ingenieros competentes. Es necesario diseñarlo, documentarlo y, lo que es más importante, ponerlo en práctica deliberadamente antes de que sea realmente necesario. Los equipos que sólo prueban el proceso durante incidentes reales están aprendiendo de la forma más costosa posible.
La anatomía de un incidente bien gestionado
Un incidente estructurado comienza con claridad de gravedad. No basta con tener un SEV1, SEV2, SEV3 en papel: cada nivel debe tener criterios objetivos (impacto financiero, porcentaje de usuarios afectados, degradación del SLA) e implicaciones de respuesta claras. SEV1 despierta a todos a las tres de la mañana. SEV3 puede esperar hasta el horario comercial. Cuando estos criterios no están definidos, cada ingeniero de turno decide por su cuenta qué es lo suficientemente grave como para escalar.
A partir de la declaración de gravedad, es necesario asignar explícitamente tres roles. El Comandante del Incidente, o IC, es quien controla la escena: no necesariamente la persona más técnica de la sala, pero sí quien mantiene el proceso, delega las investigaciones, toma decisiones cuando hay un impasse y determina cuándo se resuelve el incidente. El líder tecnológico se centra exclusivamente en diagnosticar y mitigar, sin preocuparse por la comunicación o la coordinación. Comms Lead se ocupa de las partes interesadas internas y externas, alimentando páginas de estado y respondiendo a mensajes de líderes que quieren saber qué está sucediendo. Cuando estos roles no están claros, el líder técnico pierde el tiempo respondiendo en Slack mientras el sistema aún falla.
La trampa del héroe solitario de turno.
Existe una versión romantizada de respuesta a incidentes en la que aparece el ingeniero más experimentado, accede al terminal y, con una secuencia de enigmáticas órdenes, resuelve todo en veinte minutos. Este héroe existe en algunos equipos, y esa es exactamente la razón por la que estos equipos tienen un problema grave.
El héroe solitario crea dependencia, acumula agotamiento y no transfiere conocimientos. Cuando se va de vacaciones, el equipo teme cualquier aviso. Cuando renuncia (y lo hará, porque los héroes de turno no duran mucho), el equipo descubre que nadie más sabe cómo funciona la infraestructura crítica. La respuesta estructurada a incidentes es, entre otras cosas, una estrategia de distribución de conocimientos. Cuando el proceso existe y los roles rotan, más personas comprenden los sistemas, más personas se sienten capaces de responder y disminuye la dependencia de una sola persona.
Cómo construir un proceso que reduzca el MTTR sin destruir el equipo
El indicador que más importa para evaluar el estado del proceso no es el número de incidentes, sino el MTTR, el tiempo promedio de recuperación. La reducción del MTTR es una consecuencia de varias decisiones de diseño, no de presionar al equipo para que trabaje más rápido bajo estrés.
La primera palanca es la calidad de las alertas. Los equipos que tienen docenas de alertas ruidosas entrenan a los ingenieros para ignorar las notificaciones, creando un riesgo sistémico: cuando llega la alerta que realmente importa, se pierde en el ruido. Menos alertas, más precisas y con suficiente contexto para que el ingeniero comprenda de inmediato qué está mal y dónde buscar; esto reduce los primeros minutos de desorientación que cuestan mucho MTTR.
La segunda palanca es el runbook en vivo. No el documento creado una vez y olvidado, sino un recurso actualizado después de cada incidente con los diagnósticos que funcionaron, los comandos que ayudaron y los falsos positivos que se deben evitar. El runbook no reemplaza el juicio, pero elimina el tiempo dedicado a reinventar soluciones a problemas vistos anteriormente.
La tercera palanca es la práctica deliberada. Los simulacros de incendio (simulaciones de incidentes durante el horario comercial, con escenarios planificados) son la diferencia entre un equipo que conoce intelectualmente el proceso y un equipo que puede ejecutarlo bajo presión. La resistencia a ejecutar simulaciones generalmente proviene del argumento de que "tenemos trabajo real que hacer". El coste de un equipo no preparado durante un SEV1 el domingo por la noche responde claramente a este argumento.
La autopsia como sistema de aprendizaje
La parte más subestimada de la respuesta a incidentes es lo que sucede después de que el sistema regresa. La autopsia sin culpa (sin asignar culpas individuales) existe por una razón técnica, no sólo ética: los sistemas complejos fallan debido a condiciones sistémicas, no debido a un ingeniero que tomó una mala decisión a las dos de la mañana con información incompleta. Culpar a la gente es una explicación que cierra la conversación. Comprender las condiciones que hicieron posible ese fracaso es lo que previene el siguiente.
Una buena autopsia tiene una línea de tiempo fáctica del incidente, un análisis de la causa raíz que va más allá del síntoma inmediato (cinco porqués hasta llegar a la condición sistémica) y acciones correctivas con un dueño y un plazo definidos. Lo que distingue una autopsia que genera aprendizaje de una que es pura burocracia es la honestidad de las preguntas: ¿qué no detectó el sistema de seguimiento? ¿Qué decisión arquitectónica hizo que el radio de esta explosión fuera tan grande? ¿Tenía el proceso de implementación alguna puerta que pudiera haber evitado esto?
El aprendizaje acumulado en autopsias bien realizadas es uno de los activos más valiosos de un equipo de ingeniería. Es el conocimiento colectivo sobre cómo fallan los sistemas, y este conocimiento, sistematizado, es lo que nos permite construir sistemas progresivamente más resilientes.
Lea también
- SRE en la práctica: qué cambia cuando se fusionan ingeniería y operaciones
- Métricas de ingeniería de confiabilidad del sitio: definición y monitoreo de SLI, SLO y SLA
- Seguimiento de errores: Guía completa
- Seguimiento de errores: Buenas prácticas con casos reales
- Seguimiento de errores: buenas prácticas con la lista de verificación
- Ciclo de pruebas de software: Tendencias con lista de verificación