Un lunes cualquiera, 09:13 de la mañana. Estás revisando tu correo mientras te tomas el primer café. De repente, un mensaje en Slack:
“¿Alguien más ve errores 500 en producción?”
Respiras hondo. La alerta de Grafana o de Datadog o similar confirma tus peores sospechas. El servidor está ardiendo. Bienvenido al maravilloso mundo de las incidencias en producción.
¿Qué haces cuando todo se rompe?
El primer instinto suele ser lanzarse a mirar logs, tocar código o reiniciar servidores. Pero si algo he aprendido, es que el verdadero caos no se combate con prisas: se combate con procesos.
Leer más: El servidor está ardiendo, ¿y ahora qué? 🔥En mi equipo seguimos un acuerdo de trabajo claro para incidentes técnicos. Nada loco ni corporativo, simplemente una guía para no perder la cabeza cuando más falta hace.
🕵️♂️ Detección: que no te lo cuente el cliente
Todo empieza por ahí. Cuanto antes detectes que algo va mal, menos daño hará. Para eso usamos herramientas de monitoreo automático: errores, latencia, disponibilidad, etc. Pero también aplicamos una norma no escrita:
Si ves algo raro, dilo. Todos somos responsables de detectar incidentes.
Sí, todos. No es solo cosa del SRE o del backend. Si algo falla, lo importante es que alguien lo vea y lo diga.
En nuestro caso tenemos un canal de slack que es #tech-incidents donde escribimos cuando vemos algo raro o cuando tenemos que organizarnos: el enlace para ir a la «war-room» (no me gusta ese nombre, es más un espacio para que cualquiera pueda venir a echar un cable si se necesita).
🚨 Respuesta: no estás solo
Cuando se detecta un problema, lo primero no es solucionarlo. Lo primero es organizar la respuesta:
- Se avisa al equipo por Slack: para eso el canal de #tech-incidents, intentamos no tener nada de contenido en ese canal, para que cuando haya actividad sea relacionada con que «hay fuego» .
- Se crea una sala de incidentes (Google Meet, Zoom, lo que sea).
- Se nombra un Incident Commander (IC): una persona que lidera la respuesta.
El IC no tiene por qué ser el más senior. Solo tiene que ser alguien que pueda coordinar, priorizar y, sobre todo, mantener la calma.
🧯 Resolución: foco en restaurar el servicio
El objetivo no es entender por qué ha fallado. Eso vendrá después.
El objetivo es recuperar el servicio lo antes posible. Para eso:
- Se documentan todas las acciones en tiempo real (Slack, un Google Doc, lo que sea).
- Se prioriza lo urgente: si hace falta, aplicamos un workaround temporal.
- Se comunica claramente lo que se sabe, lo que se intenta y lo que está pendiente: es lo más importante, tener transparencia y «dar tranquilidad», en el sentido de «sabemos que algo esta mal y lo estamos viendo».
Y sobre todo: no se improvisa más de la cuenta. Sin comunicación, una buena solución puede empeorar el problema. Si se está tardando en encontrar la solución, se va comunicando el estado, o lo que se está haciendo porque eso ayuda a todas las personas involucradas: si algún cliente avisa es fácil contestar que está pasando y que estamos trabajando en ello.
Dependiendo de tu empresa o del producto, quizás sea interesante tener una status page
🧠 Postmortem: aprender sin culpas
Una vez el fuego está apagado, toca aprender. En las siguientes 48h hacemos un postmortem con estas reglas:
- Se documenta todo: qué pasó, qué causó el problema, qué funcionó, qué no.
- Se buscan mejoras: cómo prevenirlo, cómo detectarlo antes, cómo actuar mejor.
- No se busca culpables.
Esto último es clave. Si alguien tiene miedo de hablar, el proceso falla.
🔁 Mejora continua: los incendios enseñan
Cada incidente es una oportunidad de mejorar: herramientas, alertas, procesos… incluso la cultura del equipo.
Y como en todo, lo importante no es evitar todos los errores (spoiler: imposible). Lo importante es que cada vez que algo se rompe, salgamos un poco mejores.
Cierre: ¿tienes plan para cuando arda tu servidor?
Si estás leyendo esto y no tienes un protocolo claro para incidentes, no esperes al próximo fuego. Aunque sea simple, define algo. Es lo que marca la diferencia entre un caos manejado y un caos total.
En nuestro equipo, este sistema nos ha salvado más de una vez. Y lo mejor: nos ha hecho crecer.
Porque al final, los buenos equipos no son los que nunca fallan. Son los que saben levantarse rápido cuando fallan.
Jesús L.C. - Apuntes de un aprendiz 
Replica a Postmortem: no se trata de culpas, se trata de aprender – Jesús L.C. – Apuntes de un aprendiz Cancelar la respuesta