Módulo 7: Blameless Postmortems And Runbooks
2. Qué hace a un postmortem "sin culpa"
Descripción
"Sin culpa" (blameless) no es un adjetivo decorativo que se le agrega a un postmortem para que suene más amable. Es una práctica de ingeniería con una definición precisa, publicada por Google SRE, con un mecanismo específico por el que produce sistemas más confiables —no solo equipos más contentos—. Esta lección cita esa definición, palabra por palabra, y la aplica al punto exacto del incidente Claude Code donde la distinción deja de ser teórica: el momento en que un humano, con la advertencia del propio agente ya sobre la mesa, aprobó el destroy de todas formas.
Conexión con el módulo
La lección 1 ya distinguió, en prosa propia, "el humano aprobó el destroy" (hecho) de "el humano es culpable" (conclusión que un postmortem sin culpa nunca escribe). Esta lección respalda esa distinción con la fuente primaria de la práctica —el capítulo de cultura de postmortem del libro de Google SRE—, y la aplica, paso a paso, al punto (5) de la cadena de fallos que cloud-security-and-guardrails-guide, Módulo 1, lección 6 ya documentó con precisión: "El humano aprueba el destroy de todas formas, sin revisar el plan completo". La lección 3, inmediatamente después, escribe el postmortem completo aplicando exactamente el criterio que esta lección establece aquí.
Paso 1 — La definición, citada completa
El libro de Google SRE es explícito, sin ambigüedad, sobre qué exige un postmortem para merecer la etiqueta "sin culpa":
"For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior."
Fíjate en la estructura exacta de esta oración, porque cada palabra hace trabajo: "debe enfocarse en identificar las causas contribuyentes" —el verbo activo es identificar causas, no evitar mencionar hechos— "sin acusar a ningún individuo o equipo de mal comportamiento o comportamiento inapropiado" — la prohibición específica no es "sin mencionar a ninguna persona", es "sin convertir la mención de esa persona en una acusación de mala conducta". La diferencia es exactamente la que la lección 1 ya trazó en prosa propia: nombrar una decisión (necesario) frente a juzgarla moralmente (prohibido).
La misma fuente agrega la suposición de partida que hace posible esa distinción:
"A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had."
Esta segunda cita es la que convierte "sin culpa" de una cortesía en un método de análisis riguroso: si asumes, como punto de partida, que cada persona involucrada actuó de buena fe con la información disponible en ese momento, la pregunta que queda por contestar deja de ser "¿por qué esta persona se equivocó?" y se convierte en "¿qué información le faltaba, o qué presión enfrentaba, que hizo que esa decisión pareciera razonable en ese momento?" — una pregunta que sí tiene una respuesta accionable a nivel de sistema.
Paso 2 — Por qué "sin culpa" no es lo mismo que "sin consecuencias"
Vale la pena resolver, con la misma fuente, una confusión común antes de seguir: "sin culpa" no significa que nada cambie después de un postmortem. Google SRE es explícito sobre el mecanismo real:
"When postmortems shift from allocating blame to investigating the systematic reasons why an individual or team had incomplete or incorrect information, effective prevention plans can be put in place. You can't 'fix' people, but you can fix systems and processes to better support people making the right choices when designing and maintaining complex systems."
Esta cita es, en efecto, el argumento completo de por qué esta práctica existe, no solo su descripción: "no puedes 'arreglar' a las personas, pero puedes arreglar sistemas y procesos". Un postmortem que asigna culpa produce, como máximo, una consecuencia sobre una persona —una advertencia, una nota en un expediente, en el peor caso una salida—; ninguna de esas consecuencias cambia el sistema que hizo posible el incidente. Un postmortem sin culpa, en cambio, produce action items de sistema (la lección 4 de este módulo construye los reales de este caso) — cambios que reducen la probabilidad de que la misma clase de error ocurra otra vez, sin importar qué persona específica esté al mando la próxima vez.
Google SRE respalda esta lógica con un precedente externo, deliberadamente elegido de industrias donde el costo de un error es literalmente la vida humana:
"These industries nurture an environment where every 'mistake' is seen as an opportunity to strengthen the system."
— Google SRE Book — Postmortem Culture (refiriéndose a las industrias de salud y aviación, el mismo dominio de la analogía de la caja negra de la lección 1)
No es casualidad que la analogía de la lección 1 —la investigación de un incidente aviación— sea la misma que Google SRE cita como el origen histórico de esta práctica en ingeniería de software: la disciplina no se inventó para ingeniería, se importó de dominios donde ya se había demostrado, con datos reales, que buscar culpables hace los sistemas menos seguros —porque castigar el reporte honesto de un error incentiva ocultarlo la próxima vez—.
Paso 3 — Aplicando la definición al punto exacto donde se pone a prueba
El incidente Claude Code tiene un punto específico donde esta distinción deja de ser abstracta: el punto (5) de la cadena de siete fallos que cloud-security-and-guardrails-guide, Módulo 1, lección 6 ya documentó —"El humano aprueba el destroy de todas formas, sin revisar el plan completo"—, precedido, en el punto (4), por una advertencia explícita del propio agente sobre el riesgo de esa acción.
EL PUNTO DONDE "SIN CULPA" SE PONE A PRUEBA -- NO ES ABSTRACTO
(4) Claude Code SEÑALA el riesgo del destroy, explícitamente
│
▼
(5) El humano aprueba el destroy de todas formas
│
┌──────────┴──────────────────────────────────┐
│ │
▼ ▼
LECTURA CON CULPA LECTURA SIN CULPA (esta guia)
───────────────── ─────────────────────────────
"El humano ignoro una Hecho verificado: la advertencia
advertencia clara. Deberia existio y fue aprobada de todas
haber sabido mejor." formas. Pregunta de sistema:
"¿por que una advertencia que se
│ puede aprobar sin friccion no
▼ es, en la practica, un control?"
Termina en un juicio sobre │
el criterio de una persona, ▼
sin ningun cambio verificable Termina en: "un control real no
del sistema pide permiso, bloquea" --
exactamente la conclusion que
cloud-security-and-guardrails-
guide ya adopto para este mismo
caso, y que la Leccion 4 de
este modulo convierte en accionLa lectura "sin culpa" no es más indulgente con el resultado del incidente —es, de hecho, más exigente con el sistema—: en vez de conformarse con "el humano debió prestar más atención", exige una respuesta verificable a "¿qué mecanismo, independiente de la atención humana en ese momento específico, habría hecho que esta decisión fuera imposible de tomar?". Esa es, palabra por palabra, la misma pregunta que cloud-security-and-guardrails-guide ya contestó para este caso con conftest/no-destroy-shipments.rego (construido) y prevent_destroy (nombrado, no construido) — la lección 4 de este módulo retoma esa segunda pieza, todavía pendiente, como action item real.
Paso 4 — La misma disciplina aplicada a "buena intención, información incompleta"
Vale la pena verificar, hecho por hecho, que la suposición de "buena intención con la información disponible" (Paso 1) realmente se sostiene para este caso, en vez de aceptarla como una frase de cortesía:
| Actor | Decisión tomada | Información que tenía en ese momento |
|---|---|---|
| El agente (Claude Code) | Propuso terraform destroy como la vía "más limpia" para revertir lo que él mismo había creado parcialmente | Un state cargado que, desde su perspectiva, indicaba que la infraestructura real "no existía" — la premisa completa desde la que razonó estaba corrompida antes de que la propuesta siquiera se formulara |
| El agente (Claude Code) | Señaló el riesgo del destroy antes de ejecutarlo | Reconoció, correctamente, que la acción propuesta era irreversible y merecía una confirmación explícita — el comportamiento correcto dado lo que sabía |
| El humano | No detuvo al agente | Estaba en medio de una migración de bajo riesgo aparente (ahorrar $5-10/mes reutilizando el proyecto existente), con una advertencia que, en el contexto de un flujo de trabajo normal con un agente, ya había visto pasar cientos de veces sin consecuencia real — ninguna señal externa (ningún conftest, ningún bloqueo automático) elevó esa advertencia específica por encima del ruido normal de trabajar con un agente |
Ninguna fila de esta tabla describe mala fe. El agente actuó de forma consistente con la información corrompida que tenía; el humano actuó de forma consistente con la ausencia de cualquier señal que distinguiera esta advertencia específica de las docenas de confirmaciones rutinarias que un flujo de trabajo con agentes produce todos los días. La conclusión que se sigue, con el vocabulario ya construido en esta guía y en cloud-security-and-guardrails-guide: el problema no fue ninguna de las dos decisiones individuales — fue la ausencia de un mecanismo que hiciera imposible, no solo desaconsejable, ejecutar un destroy sobre un recurso de producción crítico sin una verificación que no dependiera de que un humano notara algo en medio de una tarea de rutina.
Errores comunes
Confundir "asumir buena intención" con "asumir que la decisión fue correcta" (de sobreinterpretar el Paso 1). Qué pasa: alguien lee "assumes that everyone involved [...] did the right thing with the information they had" y concluye que un postmortem sin culpa nunca puede decir que una decisión fue, en retrospectiva, un error. Cómo detectarlo: si tu resumen de esta lección afirma que "no aprobar el destroy hubiera sido igual de razonable que aprobarlo, así que no hay nada que aprender aquí". Cómo corregirlo: la cita completa dice "con la información que tenían" —no dice que el resultado fuera óptimo, dice que la decisión fue comprensible dado lo que se sabía en ese momento—. Un postmortem sin culpa puede, y debe, concluir que el resultado fue malo (el Módulo 6 ya lo clasificó como SEV1, la peor severidad posible) sin necesitar concluir que la persona actuó de mala fe o con negligencia — son dos juicios completamente distintos, y solo el segundo está prohibido.
Tratar "sin culpa" como una razón para no analizar la decisión humana en absoluto (repetido, con más detalle, del error ya nombrado en la lección 1). Qué pasa: alguien, al escribir el postmortem de la lección 3, omite por completo el punto (5) de la cadena de fallos, tratándolo como "territorio prohibido" por la disciplina sin culpa. Cómo detectarlo: si tu postmortem no puede señalar, con precisión, en qué paso una decisión humana cambió el resultado. Cómo corregirlo: el Paso 3 de esta lección demostró exactamente lo contrario — la lectura sin culpa analiza la decisión humana con más profundidad que la lectura con culpa, no con menos; la diferencia está en qué pregunta se hace después de nombrar el hecho ("¿por qué pareció razonable?" en vez de "¿por qué fue negligente?").
Asumir que la cita sobre salud y aviación implica que los errores en ingeniería de software son igual de graves que un accidente aéreo (de una analogía de origen tomada demasiado literal). Qué pasa: alguien argumenta que, ya que Google SRE cita explícitamente la aviación y la salud como origen de esta práctica, cualquier incidente de software debería tratarse con la misma solemnidad institucional que un accidente aéreo. Cómo detectarlo: si tu argumento a favor de "sin culpa" depende de equiparar la gravedad de este incidente con la de un accidente de aviación. Cómo corregirlo: la cita de Google SRE nombra esas industrias como el origen histórico del mecanismo —la evidencia de que castigar el error honesto produce sistemas menos seguros—, no como una equivalencia de gravedad. El principio se transfiere aunque la escala del daño sea distinta: la misma lógica que hace que un piloto reporte honestamente un error de procedimiento sin miedo a represalias es la que hace que un ingeniero reporte honestamente que aprobó un destroy sin revisar el plan completo, sin que ese reporte se convierta en una amenaza a su carrera.
Ejercicios
Ejercicio 1 — Reescribe, en una sola oración, la diferencia entre "identificar las causas contribuyentes" y "acusar a un individuo de mal comportamiento", usando la cita exacta del Paso 1 de esta lección.
Ver solución
"Identificar las causas contribuyentes" describe, con precisión verificable, qué condiciones —técnicas, de información, de proceso— hicieron posible el resultado, incluyendo qué decisión tomó cada persona involucrada y con qué información contaba en ese momento; "acusar a un individuo de mal comportamiento" añade un juicio moral sobre esa decisión —que fue negligente, imprudente o de mala fe— que la cita del Paso 1 excluye explícitamente ("without indicting any individual [...] for bad or inappropriate behavior"). La primera actividad produce hechos accionables para un cambio de sistema; la segunda produce, en el mejor caso, una consecuencia personal sin ningún efecto verificable sobre la probabilidad de que el mismo incidente se repita.
Ejercicio 2 — Un colega argumenta que, si el humano hubiera sido más experimentado, la advertencia del agente sí habría sido suficiente para detener el destroy — y que por lo tanto el verdadero problema fue la falta de experiencia, no la falta de un control automático. ¿Cómo respondes, usando el Paso 3 y el Paso 4 de esta lección?
Ver solución
En desacuerdo, con el mismo argumento que cloud-security-and-guardrails-guide ya adoptó y que esta lección cita en el diagrama del Paso 3: "un control real no pide permiso, bloquea". Confiar en que "más experiencia" habría cambiado el resultado apuesta, otra vez, a que la atención o el criterio de una persona específica —esta vez elegida por su nivel de experiencia en vez de por su culpa— sea la salvaguarda real, exactamente el mismo punto único de falla que produjo el incidente. El Paso 4 de esta lección mostró, hecho por hecho, que ninguna señal externa distinguía esta advertencia específica de las docenas de confirmaciones rutinarias que cualquier persona —experta o novata— procesa a diario trabajando con un agente; un ingeniero senior, bajo la misma ausencia de fricción estructural, también puede aprobar una advertencia rutinaria sin notar que esta era distinta. La solución sin culpa no apuesta a mejorar el criterio de la próxima persona — apuesta a que la próxima persona, sin importar su nivel de experiencia, se encuentre con un sistema que no permite que ese destroy específico se ejecute sin una verificación mecánica.
Ejercicio 3 — Explica por qué la cita "You can't 'fix' people, but you can fix systems and processes" es, en el fondo, el mismo argumento que RELIABILITY-CHARTER.md (Módulo 1 de esta guía) ya hizo sobre el error budget como mecanismo de medición, no de prevención.
Ver solución
Ambos argumentos comparten la misma estructura lógica: reconocer los límites de lo que una intervención puede lograr, y dirigir el esfuerzo hacia lo que sí puede cambiarse de forma verificable. RELIABILITY-CHARTER.md estableció que un error budget mide el daño después de que ocurrió, en vez de prevenirlo — no porque medir sea menos valioso, sino porque confundir medición con prevención lleva a esperar de una herramienta algo que no puede dar. Esta cita hace exactamente el mismo movimiento con las personas: no porque las personas no importen, sino porque tratar "arreglar a una persona" (mediante castigo, advertencia o expectativa de mejor criterio) como si fuera equivalente a "arreglar el sistema" lleva a soluciones que se sienten satisfactorias pero no cambian la probabilidad real del próximo incidente. En ambos casos, la disciplina consiste en ser honesto sobre qué herramienta hace qué trabajo, y no pedirle a ninguna que haga el trabajo de la otra.
Resumen y siguiente paso
Esta lección citó, palabra por palabra, la definición de Google SRE de un postmortem sin culpa: enfocarse en las causas contribuyentes sin acusar a ningún individuo de mal comportamiento, partiendo de la suposición de que cada persona actuó de buena fe con la información que tenía. Confirmaste, con el mecanismo explícito de la fuente ("no puedes arreglar a las personas, pero puedes arreglar sistemas"), por qué esta disciplina produce action items de sistema en vez de consecuencias personales. Aplicaste la definición al punto exacto del incidente Claude Code donde se pone a prueba —la aprobación humana del destroy después de una advertencia explícita— y confirmaste, hecho por hecho, que la suposición de buena fe con información incompleta se sostiene para ambos actores del incidente.
Antes de avanzar deberías poder: citar la definición de "sin culpa" de memoria, con sus dos condiciones (enfocarse en causas, no acusar); explicar el mecanismo por el que esta disciplina produce sistemas más confiables, no solo equipos más contentos; y aplicar la distinción "hecho verificado / juicio moral" a cualquier decisión humana dentro de un incidente nuevo.
La lección 3 usa exactamente este criterio para escribir el documento central de esta guía: POSTMORTEM.md, construido sobre TIMELINE.md, con la estructura real de la plantilla de Google SRE.
Recursos
- Google SRE Book — Postmortem Culture — fuente de cada cita textual de esta lección.
- Google SRE Workbook — Postmortem Culture — la aplicación práctica del mismo principio, con la estructura de plantilla que la lección 3 usa.
cloud-security-and-guardrails-guide, Módulo 1, lección 6 (06-blast-radius-revisited-what-would-have-stopped-it.md) — la fuente de la cadena de siete fallos y del punto (5), analizado en esta lección.- Alexey Grigorev — How I Dropped Our Production Database — la fuente primaria de las citas textuales del agente y del humano, ya verificadas en el Módulo 6.