El 31 de enero de 2017, ya entrada la noche, un ingeniero de GitLab intentaba arreglar un problema de replicación entre dos bases de datos PostgreSQL. La principal iba ahogada: llevaba horas recibiendo un aluvión de spam que la tenía al borde del colapso. Para rehacer la réplica, decidió vaciar un directorio de datos que parecía sobrar en el servidor secundario. Tecleó un rm -rf y pulsó intro. Un segundo después se dio cuenta de que lo había lanzado contra el servidor equivocado: el de producción.
Borró casi 300 GB de datos en vivo. Cuando consiguió cancelar el comando, quedaban 4,5 GB.
Lo que vino después fue peor y, a la vez, lo más interesante de toda la historia. Al buscar desde dónde restaurar, el equipo descubrió que sus cinco mecanismos de copia y replicación estaban rotos, mal configurados o directamente nunca se habían llegado a montar. Acabaron tirando de una copia de seguridad de seis horas antes y perdieron para siempre lo generado en ese intervalo: alrededor de 5.000 proyectos, 5.000 comentarios y 700 cuentas nuevas.
Y aquí está el giro. GitLab no escondió nada. Abrió un documento público con las notas del incidente en tiempo real, retransmitió la recuperación en directo —miles de personas mirando cómo intentaban salvar los datos— y diez días más tarde publicó un post-mortem detallado con todo lo que había fallado. Al ingeniero que tecleó el comando no lo despidieron. En la documentación interna ni siquiera aparece con su nombre: lo llaman «team-member-1».
Eso es, en una sola historia, el corazón de un post-mortem sin culpa. No es buenismo ni un detalle de relaciones públicas. Es la decisión de tratar un desastre carísimo como lo que puede llegar a ser: conocimiento que casi nadie más tiene.
Por qué fallan los post-mortems tradicionales
El problema de muchos informes de incidentes no es la falta de detalle técnico. Es que están escritos para protegerse, no para aprender. Cuando la cultura de la organización castiga los errores, el documento resultante se convierte en un ejercicio de ingeniería inversa: cómo contar lo que pasó sin que nadie quede mal. El resultado es un texto lleno de eufemismos donde «no se siguió el procedimiento establecido» significa que alguien metió la pata, pero nadie dice quién ni por qué.
John Allspaw, entonces al frente de operaciones en Etsy, describió este círculo vicioso en 2012 con una claridad que sigue vigente. Lo llamó el ciclo de nombrar, culpar y avergonzar. Un ingeniero contribuye a un fallo; se le señala, se le sanciona o se le «recicla» con más formación; baja la confianza entre quienes están en la primera línea y quienes mandan; los técnicos dejan de dar detalles por miedo y se instala la ingeniería de cubrirse las espaldas; la dirección pierde de vista cómo se trabaja de verdad; y, al no detectarse las condiciones latentes del próximo fallo, el incidente se repite. Vuelta a empezar.
La consecuencia más grave de ese ciclo es la pérdida de información. Si no se puede hablar abiertamente de que alguien ejecutó un comando en producción sin verificarlo antes, porque suena a acusación, tampoco se puede analizar por qué esa persona sintió la presión de hacerlo así, qué falló en la revisión o qué salvaguarda habría evitado el desastre. El fallo técnico queda documentado. Las causas humanas y organizativas se evaporan.
Y entonces se instala el miedo a tocar cosas. Si cada cambio puede acabar en un interrogatorio disfrazado de análisis, la gente deja de proponer mejoras, de experimentar y de decidir rápido cuando hace falta. Los sistemas se estancan y los mismos incidentes vuelven, porque nadie quiere ser el siguiente en la lista.
Qué significa «sin culpa» (y qué no)
Un post-mortem sin culpa no significa que nadie sea responsable. Significa que el foco está en entender el sistema, no en juzgar a las personas. La diferencia es sutil pero lo cambia todo. Alguien pudo ejecutar un script que borró datos en producción, y eso es un hecho. Pero la pregunta no es «¿por qué fuiste tan descuidado?», sino «¿qué condiciones permitieron que esto ocurriera?».
La clave, otra vez en palabras de Allspaw, es asumir que la acción tenía sentido para quien la tomó en el momento de tomarla; si no se lo hubiera tenido, no la habría hecho. A partir de ahí el análisis deja de buscar un culpable y empieza a buscar puntos de fragilidad. ¿Por qué ese script tenía permisos de borrado en producción? ¿Por qué no había una confirmación de seguridad? ¿Por qué la monitorización no avisó antes? ¿Qué urgencia, qué cansancio o qué documentación confusa llevó a tomar ese atajo?
Esta forma de mirar tiene raíces fuera de la informática. Viene de la seguridad aérea y de la medicina, disciplinas que llevan décadas conviviendo con errores que cuestan vidas. El investigador Sidney Dekker la resume con una imagen útil: la teoría de la manzana podrida, la idea de que basta con retirar a las pocas personas poco fiables del sistema para eliminar el error humano. Esa teoría es cómoda y casi siempre falsa. En sistemas complejos, el error no es la causa del fallo: es el síntoma de fragilidades que ya estaban dentro.
Conviene marcar el límite, porque aquí muchos equipos se confunden. «Sin culpa» no es «sin consecuencias». Si aparecen patrones de negligencia o falta de competencia, habrá que tomar decisiones sobre personas. La diferencia está en que esas decisiones no se toman en caliente, durante el análisis del incidente, sino aparte, como parte de una evaluación más amplia. Mezclar las dos cosas envenena el análisis y garantiza que la próxima vez nadie cuente la verdad.
Cómo escribir uno que sirva para aprender
Un buen post-mortem tiene estructura y propósito. No es el relato cronológico y exhaustivo de todo lo que pasó, aunque la línea temporal importe. Es un análisis de por qué falló el sistema y qué se va a cambiar para que no vuelva a fallar igual.
La sección más valiosa suele ser la de causas raíz, y es donde más documentos se quedan cortos. Decir que «se llenó el disco» no es una causa raíz útil. La pregunta es por qué no se vigilaba el espacio, por qué la rotación de logs no funcionaba, por qué nadie lo vio hasta que cayó el servicio. Cada «por qué» destapa una capa más, y ahí es donde aparecen las mejoras de verdad.
Las acciones correctivas deben ser concretas y tener responsable asignado, no como castigo sino como seguimiento. «Mejorar la monitorización» no es nada. «Configurar alertas de uso de disco al 80 % en todos los servidores de producción, responsable infraestructura, plazo dos semanas» es algo que se puede verificar y que reduce el riesgo. GitLab hizo exactamente esto: su post-mortem terminaba con una lista de medidas verificables, desde copias de seguridad probadas de forma automática hasta alertas sobre el estado de la replicación.
Y conviene incluir qué funcionó bien. Si alguien detectó el problema rápido, si la comunicación entre equipos fluyó, si el plan de recuperación respondió como se esperaba, eso merece quedar escrito. Reforzar lo que funciona es tan importante como corregir lo que no.
Los obstáculos reales y las señales de que va bien
Implantar esta cultura no es solo cuestión de redactar mejor. Si los objetivos individuales penalizan los errores, o si las promociones dependen de no haber estado cerca de ningún incidente, ningún documento bienintencionado cambiará el comportamiento.
El obstáculo más común es la presión desde arriba. Cuando dirección o negocio exigen saber «quién ha sido», el equipo técnico queda en una posición imposible. Es ahí donde el liderazgo técnico tiene que ejercer de escudo y explicar algo incómodo: señalar culpables no previene incidentes, los hace más probables, porque la gente dejará de reportar y de actuar rápido por miedo. El segundo obstáculo es el tiempo. Un buen post-mortem cuesta horas, y en equipos saturados tienta despacharlo en cuatro líneas. Pero saltarse ese paso es tirar la lección: el precio del fallo ya está pagado, desperdiciarlo es un lujo. El tercero es la repetición vacía: si se identifican mejoras y nadie comprueba que se aplican, el ejercicio se convierte en un ritual y la gente deja de creer en él.
¿Cómo se sabe que la cultura está arraigando? Por señales bastante claras. La gente reporta los sustos pequeños antes de que crezcan: un «casi la lío, me di cuenta a tiempo» sin miedo a represalias vale oro. Los post-mortems se leen y generan conversación técnica, no se quedan en el cajón de los implicados. Los mismos errores dejan de repetirse —no desaparecen los incidentes, eso es imposible, pero aparecen incidentes nuevos en lugar de los de siempre—. Y, quizá la señal más bonita, cuando alguien se incorpora al equipo puede leer los post-mortems antiguos como material de formación, porque cuentan honestamente cómo funciona el sistema de verdad, más allá de la documentación oficial.
Cuándo este enfoque tiene límites
No es una receta universal. Si alguien actúa con malicia, sabotea o ignora de forma reiterada advertencias y procedimientos de seguridad, eso no es un fallo del sistema, es un problema de conducta que pide otra intervención. La cultura sin culpa parte de la buena fe; cuando esa premisa no se sostiene, el marco deja de aplicar.
Tampoco funciona en aislamiento. En una empresa donde el resto opera buscando culpables, el equipo que intente hacerlo distinto puede acabar visto como poco riguroso. Ahí el cambio tiene que venir de arriba, o al menos contar con protección explícita de la dirección. Y hay incidentes con implicaciones legales o regulatorias donde el documento acabará revisado por abogados, lo que cambia qué se puede escribir. En esos casos tiene sentido separar: un documento para cumplimiento y otro interno para aprender de verdad.
El verdadero examen
Volvamos a GitLab. El ingeniero que borró la base de datos siguió trabajando allí. La empresa salió del episodio con más reputación, no con menos, precisamente porque enseñó las costuras en lugar de taparlas. Ese es el examen que todo equipo aprueba o suspende al día siguiente de un incidente: el desastre ya ocurrió y ya está pagado. Lo único que decides al sentarte a escribir el post-mortem es si, además de caro, va a ser inútil.
Para seguir aprendiendo
- John Allspaw, «Blameless PostMortems and a Just Culture» (Etsy, Code as Craft, 2012). El ensayo que popularizó el término y sigue siendo la mejor introducción a la idea. Disponible en https://www.etsy.com/codeascraft/blameless-postmortems.
- «Postmortem Culture: Learning from Failure», capítulo 15 del Site Reliability Engineering de Google (O’Reilly, 2016). Práctico y gratuito en https://sre.google/sre-book/postmortem-culture/.
- Sidney Dekker, The Field Guide to Understanding ‘Human Error’ (3.ª ed., Routledge, 2014; publicado originalmente por Ashgate). El marco teórico, traído de la seguridad aérea y la medicina, sobre por qué el «error humano» es casi siempre un síntoma y no una causa.
- Post-mortem oficial del incidente de GitLab del 31 de enero de 2017, un ejemplo poco habitual de transparencia radical: https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/.