El postmortem blameless: investiga el sistema, no a la persona

Descripción

Un postmortem es, en su forma más simple, un registro escrito de un incidente: qué pasó, qué impacto tuvo, qué se hizo para mitigarlo, cuál fue la causa raíz, y qué acciones de seguimiento evitan que vuelva a pasar. Nada de eso, todavía, dice nada sobre culpa. La palabra que convierte un postmortem cualquiera en la práctica que enseña esta lección es blameless: la disciplina de investigar el sistema —el proceso, el criterio, la herramienta, el diseño— que permitió que el incidente ocurriera, en vez de buscar a la persona que "lo causó".

Vale la pena ser preciso desde el principio sobre lo que no significa blameless, porque es la confusión más común: blameless no es "sin consecuencias" ni "nadie es responsable de nada". Un postmortem blameless sigue exigiendo que alguien arregle la causa raíz, sigue produciendo action items con dueños concretos, y sigue tomándose en serio el impacto del incidente. Lo que cambia es dónde apunta la investigación: no a "¿quién lo hizo?", sino a "¿qué en el sistema hizo que la decisión de esa persona, con la información que tenía en ese momento, pareciera razonable?".

Conexión con el módulo. Esta lección instala el marco conceptual que las lecciones 3 y 4 van a convertir en mecánica concreta: la lección 3 construye buildPostmortem(), la función que estructura un incidente completo en timeline, factores contribuyentes y action items, y que verifica automáticamente si el resultado es blameless. La lección 4 profundiza en por qué el lenguaje —no solo la intención— es lo que determina si un postmortem termina siendo blameless de verdad o solo de nombre.

Una analogía: la caja negra del avión

Cuando un avión comercial tiene un incidente serio —una alerta de sistema, una maniobra evasiva, un aterrizaje forzoso—, los investigadores de aviación no empiezan preguntando "¿qué piloto se equivocó?". Recuperan la caja negra —la grabadora de datos de vuelo y la de voces de cabina— y reconstruyen, segundo a segundo, exactamente qué información tenía la tripulación, en qué orden, y qué la llevó a tomar cada decisión. La pregunta central de toda la investigación es sistémica: "¿qué en el diseño de la cabina, el entrenamiento, o el procedimiento permitió que esta secuencia de decisiones, cada una razonable en su momento, terminara en un incidente?".

Esta disciplina no es blandura ni falta de rigor. Es, de hecho, más rigurosa que "encontrar al culpable": culpar a un piloto cierra la investigación en cuanto se identifica a una persona, sin preguntar por qué el sistema permitió que esa persona, entrenada y calificada, tomara esa decisión. Investigar el sistema exige seguir preguntando "¿y por qué?" varias capas más profundo, hasta encontrar la causa que, si se arregla, protege a cualquier piloto futuro en la misma situación — no solo al que estaba volando ese día.

El postmortem blameless de un incidente de software funciona exactamente igual. El equipo de recommendations no investiga "¿quién aprobó el avance a la etapa de 10% sin la prueba de carga adecuada?" — investiga "¿qué en el criterio de avance de la rampa permitió que se avanzara sin esa prueba, y qué cambia para que ningún avance futuro, de nadie, tenga el mismo hueco?".

Ejemplo trabajado: checkBlameless(), el chequeo mínimo

Antes de construir el postmortem completo (eso es la lección 3), vale la pena ver el chequeo central en su forma más simple: dada una frase que describe una causa, ¿nombra a una persona específica, o señala algo del sistema?

// checkBlameless: version minima del chequeo que blindara buildPostmortem
// (leccion 3): busca si una frase de "causa" nombra a una PERSONA especifica
// en vez de un sistema o proceso. Nombres de ejemplo del equipo de Mercado.
function checkBlameless(statement) {
  const namedPeople = ['Ana', 'Bruno', 'Carla', 'Diego', 'Elena'];
  const redFlag = namedPeople.some((name) => statement.includes(name));
  return { statement, redFlag, verdict: redFlag ? 'BLAMES A PERSON' : 'blameless' };
}

const draftA = 'Diego aprobo el avance a la etapa de 10% sin confirmar la prueba de carga.';
const draftB = 'El proceso de aprobacion para avanzar de etapa no exigia confirmar una prueba de carga equivalente al volumen de la siguiente etapa.';

console.log('=== checkBlameless: dos formas de describir la misma causa ===\n');
console.log('Draft A (culpa a una persona):');
console.log(checkBlameless(draftA));
console.log('\nDraft B (senala el proceso):');
console.log(checkBlameless(draftB));

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== checkBlameless: dos formas de describir la misma causa ===

Draft A (culpa a una persona):
{
  statement: 'Diego aprobo el avance a la etapa de 10% sin confirmar la prueba de carga.',
  redFlag: true,
  verdict: 'BLAMES A PERSON'
}

Draft B (senala el proceso):
{
  statement: 'El proceso de aprobacion para avanzar de etapa no exigia confirmar una prueba de carga equivalente al volumen de la siguiente etapa.',
  redFlag: false,
  verdict: 'blameless'
}

Fíjate en algo importante: las dos frases describen, en el fondo, la misma causa raíz — nadie confirmó que hubiera una prueba de carga adecuada antes de avanzar de etapa. El draftA y el draftB no discrepan sobre los hechos. Discrepan sobre dónde ponen el foco: draftA pone el foco en Diego, como si el problema fuera que Diego, específicamente, cometió un error que otra persona no habría cometido. draftB pone el foco en el proceso de aprobación, como si el problema fuera que el propio criterio de avance, sin importar quién lo ejecutara, no exigía esa confirmación. checkBlameless() es un chequeo simple —busca nombres propios—, pero el chequeo simple ya alcanza para exponer una diferencia real: redFlag: true contra redFlag: false, sobre la misma causa técnica de fondo.

Profundización: blameless no es lo mismo que "sin accountability"

Vale la pena volver sobre el malentendido más común, porque cuesta caro cuando aparece: alguien escucha "postmortem blameless" y concluye que nadie tiene que responder por nada — que si el postmortem no señala a una persona, entonces el incidente "no fue culpa de nadie" y ahí termina la conversación. Eso es exactamente lo contrario de lo que un postmortem blameless bien hecho produce.

Un postmortem blameless sigue produciendo accountability real — solo que la pone en el lugar correcto. En el ejemplo de arriba, draftB no dice "nadie es responsable de arreglar esto". Dice, implícitamente, "el equipo dueño del criterio de avance de la rampa es responsable de agregar la prueba de carga que faltaba" — y esa responsabilidad se convierte, en la lección 3, en un action item concreto con un dueño y una fecha. La diferencia con draftA no es que uno tenga consecuencias y el otro no: es que draftA pone la responsabilidad de "no repetir el error" sobre la memoria y el buen juicio de una persona individual la próxima vez, mientras que draftB la pone sobre un cambio al sistema que protege a cualquier persona, incluida Diego, la próxima vez que alguien tenga que decidir si avanzar una etapa.

Esta distinción tiene una consecuencia práctica que va más allá de un incidente puntual: los equipos que saben que su postmortem va a buscar a quién culpar aprenden, con el tiempo, a esconder información, minimizar su propio rol, o evitar reportar incidentes menores antes de que escalen. Los equipos que saben que el postmortem va a investigar el sistema tienden a ser mucho más honestos sobre qué pasó exactamente — porque contar la verdad completa no los pone en riesgo personal. Esa honestidad es, literalmente, el insumo que un postmortem necesita para encontrar la causa raíz real, en vez de la primera explicación superficial que no incomoda a nadie.

Errores comunes

Confundir "blameless" con "no hace falta que nadie arregle nada". Qué pasa: al escribir el postmortem, alguien concluye que como no se va a señalar a ninguna persona, tampoco hace falta ser específico sobre qué cambia en el sistema — el postmortem termina en una frase vaga como "hubo una falla de comunicación" sin ningún action item concreto. Por qué pasa: es fácil confundir "no culpar a alguien" con "no comprometerse con nada", cuando en realidad son dos ejes completamente distintos. Cómo detectarlo: si el postmortem no tiene ningún action item con dueño y fecha, no importa qué tan cuidadoso haya sido el lenguaje sobre no culpar a nadie — el postmortem no cumplió su función. Cómo corregirlo: blameless describe cómo se investiga la causa, no si el resultado tiene consecuencias. Los action items de la lección 3, con dueño y fecha, son tan obligatorios en un postmortem blameless como en cualquier otro.

Buscar al culpable con lenguaje disfrazado de sistémico. Qué pasa: el postmortem evita nombrar a una persona directamente, pero usa frases que igual apuntan a un individuo específico e identificable para cualquiera que conozca el equipo —"el ingeniero de guardia no siguió el runbook", cuando solo una persona estuvo de guardia esa noche—. Por qué pasa: quitar el nombre propio se siente como haber cumplido con "ser blameless", sin notar que el señalamiento sigue siendo perfectamente identificable para todos los presentes. Cómo detectarlo: si cualquiera en la sala puede decir en voz alta "eso es sobre Fulano" al leer un factor contribuyente, el chequeo automático de nombres propios no capturó el problema real — el lenguaje sigue apuntando a una persona, solo que sin decir su nombre. Cómo corregirlo: la pregunta correctora no es "¿mencioné un nombre?", es "¿esta frase seguiría siendo cierta si cualquier otra persona calificada hubiera estado en esa posición, con la misma información?". Si la respuesta es sí, el factor es sistémico de verdad.

Saltarse el postmortem porque el incidente "no fue tan grave". Qué pasa: el equipo decide que como el incidente se contuvo rápido y el impacto real fue chico —pocos usuarios expuestos, el kill switch funcionó en segundos—, no vale la pena el tiempo de escribir un postmortem completo. Por qué pasa: un postmortem se siente como trabajo proporcional al tamaño del desastre, y un incidente bien contenido se siente, por definición, como uno chico. Cómo detectarlo: si la razón para no escribir el postmortem es "salió bien al final", en vez de "no hay nada nuevo que aprender", la decisión está mirando el resultado en vez del proceso. Cómo corregirlo: el valor de un postmortem no depende de qué tan grave fue el incidente — depende de si el sistema reveló algo que no se sabía antes. Un guardrail que se rompió y se contuvo rápido gracias al rollout gradual (módulo 3) y al monitoreo en vivo (módulo 4) sigue siendo evidencia real de un punto débil del sistema —la llamada bloqueante al motor de recomendaciones—, que va a volver a aparecer si nadie lo documenta y lo arregla.

Ejercicios

Ejercicio 1 — Reescribe la frase. La siguiente frase describe una causa real, pero de forma que no es blameless: "Bruno desplegó el cambio del motor de recomendaciones un viernes por la tarde, sin que nadie más revisara el impacto en la latencia." Reescríbela como un factor sistémico, sin nombrar a Bruno, que describa el mismo hecho de fondo.

Ver solución

Una reescritura razonable: "El proceso de despliegue no requería una revisión adicional de impacto en latencia antes de un cambio al motor de recomendaciones, ni restringía los despliegues de esa naturaleza a ventanas de menor riesgo." Fíjate en qué se conserva y qué cambia: el hecho de fondo —un cambio se desplegó sin revisión adicional de latencia— sigue exactamente igual. Lo que cambia es que la frase ya no depende de que fuera Bruno, específicamente, quien lo hiciera un viernes — describe una falta del proceso que cualquier persona, cualquier día, podría haber repetido bajo el mismo sistema.

Ejercicio 2 — Corre checkBlameless() mentalmente. Sin ejecutar código, ¿qué devolvería checkBlameless('El equipo de plataforma no habia agregado una prueba de carga al criterio de avance de la rampa.')? Justifica tu respuesta usando la lista namedPeople de la lección.

Ver solución

Devolvería { redFlag: false, verdict: 'blameless' }. La función solo busca coincidencias con los nombres en namedPeople (['Ana', 'Bruno', 'Carla', 'Diego', 'Elena']), y la frase no contiene ninguno de esos nombres —"el equipo de plataforma" es una referencia a un grupo/proceso, no a una persona individual—, así que statement.includes(name) da false para los cinco nombres, y redFlag queda en false.

Ejercicio 3 — Defiende blameless ante un escéptico. Un compañero dice: "Si nadie se hace responsable por sus errores, el equipo nunca va a mejorar — la gente necesita consecuencias para aprender." En 2-3 frases, explica por qué un postmortem blameless bien hecho no elimina la responsabilidad, solo la redirige.

Ver solución

Un postmortem blameless no elimina la responsabilidad — la mueve de "una persona debe recordar no volver a cometer este error" a "el equipo dueño del sistema debe cambiar el sistema para que este error sea, estructuralmente, más difícil de cometer". La primera forma de responsabilidad depende de la memoria y el juicio de un individuo bajo presión, en un momento futuro impredecible; la segunda produce un action item concreto, con dueño y fecha, que protege a cualquiera que esté en esa posición después. Lejos de ser más laxo, un postmortem blameless bien hecho suele exigir un cambio más profundo y más difícil —tocar el sistema— que simplemente pedirle a una persona que "tenga más cuidado" la próxima vez.

Resumen y siguiente paso

En esta lección instalaste el concepto central del módulo: un postmortem blameless investiga el sistema —el proceso, el criterio, el diseño— que permitió un incidente, en vez de buscar a la persona que lo "causó", pero eso no significa ausencia de responsabilidad: significa que la responsabilidad de arreglar el sistema recae en quien lo puede cambiar, con un action item concreto, no en la memoria de un individuo. Con checkBlameless() viste, en su forma más simple, cómo se detecta la diferencia entre un factor que señala a una persona y uno que señala al sistema.

Antes de avanzar deberías poder: explicar con tus propias palabras por qué "blameless" no significa "sin consecuencias"; reescribir una frase que culpa a una persona como un factor sistémico equivalente; y anticipar por qué el lenguaje que un equipo usa en sus postmortems, con el tiempo, cambia qué tan honesto es ese mismo equipo al reportar futuros incidentes.

La lección 3 toma este concepto y lo convierte en mecánica completa: buildPostmortem(), la función que estructura cualquier incidente en sus tres piezas canónicas —timeline, factores contribuyentes, action items— y verifica automáticamente si el resultado es blameless, aplicada al incidente real de latencia de recommendations.

Recursos

• Google SRE Book, Capítulo 15, "Postmortem Culture: Learning from Failure" — sre.google/sre-book/postmortem-culture. La cita de referencia del capítulo, "no puedes 'arreglar' a las personas, pero puedes arreglar sistemas y procesos", resume en una frase el argumento completo de esta lección. En inglés.
• John Allspaw, "Blameless PostMortems and a Just Culture" (Etsy, Code as Craft, 2012) — etsy.com/codeascraft/blameless-postmortems. El artículo original y más influyente sobre postmortems blameless en la industria del software; cuatro años antes de que Google lo codificara en su propio libro de SRE. En inglés.
• Atlassian, "How to run a blameless postmortem" — atlassian.com/incident-management/postmortem/blameless. Una guía práctica moderna sobre cómo estructurar la conversación del postmortem asumiendo que todos actuaron con la mejor intención posible dada la información que tenían. En inglés.