Módulo 4: Escribir documentos técnicos en lenguaje llano
7. Postmortems y escritura de incidentes
Descripción
Algo se rompió en producción. El pago falló para un grupo de usuarios, la API estuvo caída veinte minutos, un deploy tumbó el login. Pasa en todos los equipos, todo el tiempo, incluso en los mejores. Lo que separa a un equipo que crece de uno que vive apagando incendios no es la ausencia de incidentes: es lo que escriben después. Y ahí es donde entra un documento que probablemente ya oíste nombrar en inglés y te sonó intimidante: el postmortem. Quiero que salgas de esta lección viéndolo como lo que en realidad es, que no es un tribunal ni un examen de inglés, sino una de las piezas de escritura más aprendibles, más plantilladas y más generosas con quien todavía duda de su idioma.
Un postmortem es el informe que un equipo escribe después de un incidente para entender qué pasó, por qué, y qué van a cambiar para que no vuelva a pasar. La palabra viene de la medicina —literalmente "después de la muerte", el análisis que se hace de un cuerpo para saber la causa— y en tecnología significa exactamente eso trasladado a un sistema: se abre el caso con calma, cuando ya no hay fuego, y se estudia sin apuntar con el dedo a nadie. Esa última parte tiene nombre propio en inglés, blameless (sin culpa), y no es un adorno moral: es una decisión de redacción que cambia por completo si el equipo aprende de verdad o si cada persona escribe a la defensiva para cubrirse. Vas a ver que gran parte de escribir un buen postmortem es una cuestión de cómo se redacta, no de cuánto inglés dominas.
En esta lección separamos dos escrituras que la gente confunde y que tienen reglas opuestas: la comunicación durante el incidente —los mensajes cortos que mandas mientras el fuego arde, en tiempo presente y con información parcial— y el informe posterior —el documento sereno que escribes al día siguiente con toda la historia ya conocida. Te doy el vocabulario inglés de incidentes que se repite en cualquier empresa (degraded, partial outage, mitigated, root cause, contributing factor), la diferencia real entre causa raíz y factor contribuyente, la estructura completa del documento con su ejemplo en inglés, y las frases que convierten una redacción que culpa en una que enseña.
Conexión con el módulo: Este es el último tipo de documento del módulo y el que más lectores tiene: un postmortem lo leen tu equipo, tu manager, a veces toda la empresa. Usa todo lo que ya construiste: el lenguaje llano de la lección 2 (aquí es obligatorio, porque un incidente lo lee gente estresada y no técnica), la anatomía por secciones del design doc (lección 3), y el rastro de decisiones del ADR (lección 5) — de hecho, las acciones correctivas de un postmortem muchas veces derivan en un ADR nuevo. Es la escalada final de la escritura técnica: máxima exposición, máxima necesidad de claridad, y la mejor prueba de que sabes comunicar bajo presión sin perder el tono profesional.
Antes de empezar: qué asume esta lección y qué no
Esta guía no enseña inglés desde cero, y esta lección tampoco. Asumo que ya lees inglés técnico con soltura razonable (nivel B1 de lectura: entiendes un mensaje de incidente sin traducir palabra por palabra, aunque a veces busques un término). No necesitas hablar bien todavía: el postmortem, igual que el PR de la lección anterior, es 100% escrito y asíncrono. Escribes con red — revisas, borras, comparas con una plantilla y corriges antes de que nadie lo lea. Nadie mide tu acento en un documento.
Si al leer un informe de incidente en inglés te pierdes por completo, no es que "no sirvas para esto": es que todavía te falta piso de lectura, y lo honesto es reforzar el módulo 2 (fundamentos de inglés técnico) antes de seguir. No hay atajo que valga la pena. Pero si ya entiendes lo que lees aunque escribir bajo la sombra de un incidente te ponga nervioso, estás justo en el punto para el que se escribió esta lección — y la presión del idioma baja muchísimo cuando descubres cuántas de estas frases son fijas y repetibles.
Parte 1 — Qué es un postmortem y por qué "blameless"
Qué es y por qué importa
Piensa en el postmortem como la caja negra de un avión. Cuando algo sale mal, nadie corre a preguntar de quién fue la culpa: se recupera la caja negra, se reconstruye minuto a minuto lo que pasó, y el resultado se comparte para que toda la industria vuele más seguro. El objetivo no es castigar al piloto — es que el próximo vuelo no repita el fallo. Un postmortem hace lo mismo con un sistema de software: reconstruye el incidente con datos, encuentra la causa, y produce cambios concretos.
Un incidente resuelto sin postmortem es una lección tirada a la basura. El sistema volvió a funcionar, sí, pero el equipo no capturó por qué falló ni cómo evitar que vuelva. La escritura es la que convierte un mal rato en conocimiento que queda.
Qué significa "blameless" y por qué la redacción lo decide todo
Blameless significa "sin culpa": el documento describe qué falló en el sistema y en el proceso, nunca quién es la persona mala. No es que se ignore quién ejecutó el comando — es que se asume, de entrada, que ninguna persona razonable rompe producción a propósito, y que si un solo error humano pudo tumbar el sistema, el problema real es que el sistema permitía ese error sin ninguna barrera.
Esto no es amabilidad. Es la diferencia entre un equipo que aprende y uno que se esconde. Míralo así:
| Si el postmortem culpa a personas... | Si el postmortem es blameless... |
|---|---|
| La gente escribe a la defensiva, para cubrirse | La gente escribe la verdad completa, sin miedo |
| Se ocultan detalles que darían "mala imagen" | Salen a la luz los detalles que revelan la causa real |
| La próxima vez, nadie reporta a tiempo por miedo | La próxima vez, se reporta rápido y se contiene antes |
| Se "arregla" a la persona (un regaño) | Se arregla el sistema (una barrera nueva) |
Y aquí está el punto que te libera como hispanohablante: escribir blameless es, en el fondo, un truco de redacción concreto y copiable, no un dominio sutil del idioma. Se reduce casi siempre a mover el sujeto de la persona al sistema. Es la misma regla que viste al recibir code review en la lección anterior — el enemigo es "you" apuntando a la persona; el amigo es hablar del comportamiento del sistema.
| ❌ Culpa a la persona | ✅ Blameless (describe el sistema) |
|---|---|
| "Carlos deployed a broken config." | "A config change was deployed without a validation step to catch the error." |
| "The engineer forgot to run the migration." | "The deploy process did not enforce running pending migrations." |
| "Someone deleted the wrong table." | "The admin tool allowed deleting a production table without a confirmation step." |
| "QA missed this bug." | "There was no automated test covering the empty-cart case." |
Fíjate: la información técnica es idéntica. Nadie está mintiendo ni tapando lo que pasó. Solo cambió dónde apunta la frase — y con ese cambio, el documento pasa de "buscar culpable" a "buscar barrera que falta". En inglés esto se logra sobre todo con voz pasiva selectiva ("a config change was deployed") y con el sistema como sujeto ("the deploy process did not enforce..."). Es uno de los poquísimos lugares donde la voz pasiva, que en la lección 2 te dije que evitaras, es exactamente la herramienta correcta.
Parte 2 — El inglés de los incidentes (el vocabulario que se repite)
Los incidentes tienen un vocabulario propio, corto y universal. Aparece igual en una startup y en Google. Aprenderlo es como aprender las señales de tránsito: son pocas y siempre significan lo mismo. Esta es la tabla que más vas a consultar de la lección.
Estados y severidad
| Término en inglés | Qué significa | Cómo se usa |
|---|---|---|
| Outage | El servicio está caído, no funciona | "We had a 15-minute outage." |
| Partial outage | Parte del servicio está caído; el resto funciona | "Checkout was down, but browsing worked — a partial outage." |
| Degraded / degraded performance | Funciona, pero lento o con errores intermitentes | "The API was degraded: ~20% of requests timed out." |
| Elevated error rate | Suben los errores por encima de lo normal | "We saw an elevated error rate on the login endpoint." |
| Down | Caído (informal, muy usado) | "The database was down for 8 minutes." |
| Impact | A quién y a qué afectó | "Impact: ~3,000 users could not log in." |
| Blast radius | El alcance del daño (qué tan lejos llegó) | "The blast radius was limited to the EU region." |
El ciclo de vida del incidente
| Término en inglés | Qué significa |
|---|---|
| Detected | El momento en que alguien o algo notó el problema |
| Investigating | Se está buscando la causa; aún no se sabe |
| Identified | Ya se sabe qué lo causa |
| Mitigated | El daño se detuvo (los usuarios ya no lo sufren), pero la causa de fondo puede seguir ahí |
| Resolved | Cerrado del todo: causa arreglada y servicio normal |
La distinción entre mitigated y resolved es de las más útiles y de las que más se malentienden. Mitigado es "paré la hemorragia" — por ejemplo, reiniciaste el servidor y los usuarios ya pueden entrar. Resuelto es "curé la herida" — encontraste por qué se llenaba la memoria y lo corregiste para que no vuelva. Un reinicio mitiga; casi nunca resuelve. Confundirlos hace que un equipo cante victoria antes de tiempo y el incidente regrese esa misma noche.
Causa raíz vs. factor contribuyente
Estos dos términos son el corazón técnico de un postmortem, y confundirlos es el error de análisis más común. Vale la pena separarlos bien.
- Root cause (causa raíz): el fallo de fondo que, si no hubiera existido, el incidente no habría ocurrido. Es la raíz del árbol.
- Contributing factor (factor contribuyente): algo que empeoró el incidente, lo hizo más largo o más difícil de detectar, pero que por sí solo no lo habría causado. Son las ramas.
Un ejemplo hace la diferencia obvia:
Root cause: "A database connection pool was configured with a maximum of 10 connections. Under peak traffic, all connections were held, and new requests waited until they timed out."
Contributing factor 1: "The alert for connection-pool saturation was set to 95%, so it fired only after the outage had already started."
Contributing factor 2: "The on-call runbook did not mention the connection pool, so the responder spent 12 minutes looking in the wrong place."
La causa raíz explica por qué se rompió; los factores contribuyentes explican por qué tardamos tanto en verlo y arreglarlo. Un buen postmortem casi siempre tiene una causa raíz y varios factores contribuyentes — y con frecuencia las mejoras más valiosas salen de los factores, no de la raíz (una mejor alerta, un runbook actualizado). La honestidad aquí importa: forzar todo a una sola causa raíz simplista ("fue un error humano") tapa justo los factores del sistema que sí puedes arreglar.
Parte 3 — La comunicación DURANTE el incidente
Hay dos escrituras totalmente distintas alrededor de un incidente, y mezclarlas es un error clásico. Empecemos por la que ocurre mientras el fuego arde: los mensajes cortos que mandas en el canal de incidentes (Slack, Teams) o publicas en una status page para usuarios.
Qué es y qué reglas la gobiernan
Un status update durante el incidente es un mensaje breve, en tiempo presente, con la información que tienes en este minuto — que casi siempre es incompleta. Su trabajo no es explicar la causa (todavía no la sabes); es decirle a la gente que estás encima, qué se sabe, y cuándo será la próxima actualización. El silencio es el peor enemigo aquí: si un usuario no ve señales de vida, asume que nadie está mirando.
Tres reglas de oro para este momento:
- Presente y factual. Di lo que sabes, no lo que crees. "We are investigating." No "It's probably the database." si aún no lo confirmas.
- No prometas tiempos que no controlas. Nunca "fixed in 10 minutes." Sí "next update in 15 minutes." — prometes tu próximo mensaje, no la solución.
- Sin culpa y sin jerga. Los lee gente estresada, a veces no técnica. Lenguaje llano, cero nombres propios.
Plantillas por fase (copiar y adaptar)
Casi todos los proveedores del mundo usan estas mismas cuatro fases. Reconócelas y tienes el 90% del vocabulario:
Investigating (acabamos de detectar, no sabemos la causa): "We are investigating reports of errors when logging in. We'll share an update in 15 minutes." (Investigando reportes de errores al iniciar sesión. Próxima actualización en 15 minutos.)
Identified (ya sabemos la causa): "We have identified the cause — a configuration change is being rolled back now. Next update in 15 minutes." (Identificamos la causa; estamos revirtiendo un cambio de configuración.)
Monitoring (aplicamos el arreglo, vigilando que aguante): "A fix has been applied and login is working again. We are monitoring to confirm full recovery." (Aplicamos un arreglo y el login funciona; monitoreando para confirmar la recuperación total.)
Resolved (cerrado): "This incident is resolved. Login has been fully operational since 14:30 UTC. A postmortem will follow." (Incidente resuelto; el login opera con normalidad desde las 14:30 UTC. Publicaremos un postmortem.)
Nota cómo cada mensaje termina apuntando al siguiente: "next update in 15 minutes" o "a postmortem will follow." Ese cierre mantiene la confianza — la gente tolera un incidente sorprendentemente bien si siente que alguien lo está comunicando con orden.
Qué esperar: la primera vez que te toque escribir en vivo con la adrenalina alta, vas a querer escribir párrafos largos explicándolo todo. Resiste. En pleno incidente, menos es más: una línea clara cada 15 minutos vale más que un ensayo. Y como estas cuatro plantillas son fijas, puedes tenerlas pegadas en una nota y rellenar el hueco — el inglés deja de ser el problema justo cuando más lo agradeces.
Parte 4 — El informe POSTERIOR: el postmortem escrito
Cuando el incidente ya cerró y todos durmieron, viene la segunda escritura, la opuesta a la anterior: serena, en pasado, con toda la historia conocida. Aquí no hay prisa. Aquí armas el documento que el equipo va a leer para aprender. Tiene una estructura estándar; una vez que la tienes, escribir el postmortem es rellenar secciones, no inventar de cero.
La estructura estándar
| Sección (en inglés) | Qué responde | Cuidado especial |
|---|---|---|
| Summary | En 2-3 líneas: qué pasó y cuánto duró | Lo primero que se lee; que se entienda solo |
| Impact | A quién afectó, cuánto, en números | Cuantifica: usuarios, %, dinero, tiempo |
| Timeline (UTC) | Qué pasó minuto a minuto | Siempre en UTC; horas absolutas |
| Detection | Cómo y cuándo lo notamos | ¿Lo vio una alerta o un usuario? |
| Root cause | El fallo de fondo | Uno solo, bien explicado |
| Contributing factors | Qué lo empeoró o alargó | Varios; aquí sale el oro |
| Resolution / Mitigation | Cómo se detuvo y cómo se cerró | Separa mitigación de resolución |
| Action items | Qué vamos a cambiar | Con dueño y fecha, siempre |
Por qué la cronología va en UTC
UTC (Coordinated Universal Time) es la hora de referencia mundial, la misma para todos sin importar el país. En un equipo distribuido —tú en México, un colega en India, otro en Alemania— si cada quien escribe su hora local, la cronología se vuelve un rompecabezas imposible de reconstruir. UTC es el acuerdo neutral: todas las horas del postmortem, siempre, en UTC. Se escribe así: 14:32 UTC. Es un detalle pequeño que grita "sé cómo se trabaja en equipos internacionales".
Un postmortem real, en inglés
Aquí tienes uno completo y breve. Léelo entero: es tu plantilla.
# Postmortem: Login outage on 2026-03-14
## Summary
On 2026-03-14, the login service was unavailable for 22 minutes
(14:08–14:30 UTC). Users could not sign in. Browsing and checkout
were not affected (partial outage).
## Impact
- ~3,200 users were unable to log in during the window.
- ~180 checkout sessions were abandoned (users could not re-authenticate).
- No data was lost.
## Timeline (UTC)
- 14:05 — A configuration change was deployed to the auth service.
- 14:08 — Error rate on POST /login rose from <1% to ~85%.
- 14:11 — PagerDuty alerted the on-call engineer.
- 14:14 — On-call began investigating; posted "Investigating" status.
- 14:22 — The bad config change was identified as the cause.
- 14:26 — The change was rolled back.
- 14:30 — Error rate returned to normal. Incident mitigated.
- 15:10 — A validation check was added to the deploy pipeline. Resolved.
## Detection
The incident was detected automatically by the error-rate alert,
3 minutes after impact began. No users had to report it first.
## Root cause
A configuration change set the auth token expiry to 0 seconds. Every
issued token was considered expired immediately, so all login attempts
were rejected. The change passed review because the value looked valid
in isolation and there was no test for token expiry > 0.
## Contributing factors
- The deploy pipeline had no validation step for config values, so an
invalid setting reached production unblocked.
- The on-call runbook did not cover auth-config rollbacks, adding
~4 minutes to the response.
## Resolution and mitigation
- Mitigation (14:26): rolled back the config change; login recovered.
- Resolution (15:10): added a pipeline check that rejects a token
expiry of 0 before deploy.
## Action items
| Action | Owner | Due |
|---|---|---|
| Add config validation to the deploy pipeline | @maria | 2026-03-21 |
| Add a test for token expiry > 0 | @dev-team | 2026-03-19 |
| Add auth-config rollback steps to the runbook | @luis | 2026-03-18 |Las action items: el detalle que casi todos hacen mal
La sección más importante y la más descuidada. Una acción correctiva sin dueño y sin fecha no es una acción: es un buen deseo que nadie va a hacer. La regla es dura y simple:
Cada action item lleva un nombre (owner) y una fecha (due date). Sin excepción.
| ❌ Acción vaga (no pasa nada) | ✅ Acción real (alguien la hace) |
|---|---|
| "We should add better validation." | "Add config validation to the deploy pipeline — @maria, due 2026-03-21." |
| "Improve monitoring." | "Add an alert for token-expiry misconfig — @luis, due 2026-03-25." |
| "Update the docs." | "Add auth rollback steps to the runbook — @ana, due 2026-03-18." |
Fíjate también en el verbo: empieza con imperativo en inglés (Add, Improve mejor como "Add..." concreto), igual que las instrucciones ejecutables del README de la lección anterior. Una action item se lee como una orden clara para el sistema, no como una reflexión.
Parte 5 — La redacción blameless en la práctica
Ya viste el principio en la Parte 1. Ahora los movimientos finos, porque es donde el hispanohablante nervioso más se traiciona sin querer — normalmente por escribir a la defensiva o por traducir literal una disculpa que en el original no hacía falta.
Habla de acciones y sistemas, no de personas
El patrón es el mismo de todo el módulo: mueve el foco de "quién" a "qué". En un timeline puedes nombrar roles (the on-call engineer, the reviewer) porque es necesario para la cronología, pero nunca en tono de acusación, y jamás cuelgas la causa raíz de una persona.
| ❌ Enfoque en la persona | ✅ Enfoque en el sistema |
|---|---|
| "The reviewer approved a bad change." | "The change passed review because there was no test covering this case." |
| "He didn't check the logs." | "The runbook didn't point to the relevant logs, so they weren't checked early." |
| "They pushed on a Friday." | "The change was deployed with no automated rollback available." |
No conviertas el postmortem en una disculpa
Un incidente no es una falta moral. El tono es analítico y neutro, no arrepentido. Escribir "we are so sorry, this was a terrible failure on our part" por todo el documento no aporta nada técnico y proyecta inseguridad. Un breve reconocimiento del impacto al usuario está bien; el resto es análisis frío.
| ❌ Tono de disculpa/vergüenza | ✅ Tono analítico |
|---|---|
| "We deeply apologize for this embarrassing mistake." | "This incident affected ~3,200 users. Here is what happened and what we're changing." |
| "This should never have happened." | "This was possible because the pipeline had no config validation. That gap is now closed." |
| "I feel terrible about this." | "The root cause is understood and the fix is deployed." |
El vocabulario que suena profesional bajo presión
Un puñado de frases hechas que aparecen en casi todos los postmortems y que puedes reusar tal cual:
- "The incident was detected automatically by..." (Se detectó de forma automática por...)
- "Impact was limited to..." (El impacto se limitó a...)
- "As an immediate mitigation, we..." (Como mitigación inmediata...)
- "The root cause was..." / "Contributing factors included..."
- "To prevent recurrence, we will..." (Para prevenir que vuelva a ocurrir...)
- "No data was lost." / "No customer data was exposed." (Cuando aplica: dilo, tranquiliza.)
Qué esperar: los primeros postmortems te van a costar más por el reflejo de escribir a la defensiva que por el inglés. Vas a querer explicar por qué no fue tu culpa. Suéltalo. El equipo blameless ya sabe que no fue tu culpa — asumen que ninguna persona rompió nada a propósito. Cuando dejas de defenderte y describes el sistema con calma, dos cosas pasan a la vez: el documento mejora y tu inglés fluye mejor, porque las frases de sistema son mucho más fáciles y más plantilladas que las emocionales.
Cierre: por qué esto sí lo puedes
Un incidente da miedo. Escribir sobre él en inglés, más. Pero mira lo que en realidad tienes en las manos al terminar esta lección: no "escribir inglés bien" —eso es un océano— sino un puñado de piezas finitas y copiables. Cuatro plantillas de status (investigating / identified / monitoring / resolved). Una tabla de vocabulario que se repite en toda la industria (outage, degraded, mitigated, root cause, contributing factor). Una estructura de informe de ocho secciones que se rellena, no se inventa. Y un truco de redacción, el blameless, que a nivel de idioma se reduce a mover el sujeto de la persona al sistema. Se cuentan con los dedos. Se pegan en un archivo. Se reusan en cada incidente de tu carrera.
Y como el PR de la lección anterior, el postmortem juega a tu favor por ser escrito y sin prisa: lo redactas al día siguiente, con calma, comparándolo con este ejemplo, corrigiendo antes de que nadie lo lea. El incidente fue el momento de presión; el documento no lo es. Que un desarrollador hispanohablante escriba un postmortem claro, blameless y en inglés llano es, para cualquier equipo internacional, una de las señales de madurez más fuertes que existen — y acabas de ver que está hecho de partes que puedes tener listas de antemano.
En la última lección del módulo juntas todo: escribirás un design doc completo en inglés llano sobre un sistema propio, con su ADR y su README. El postmortem que aprendiste hoy es la otra cara de esa moneda — el design doc dice cómo esperas que algo funcione; el postmortem, qué aprendiste cuando no funcionó. Ambos son la misma escritura clara, y ambos son evidencia de seniority que puedes producir sin permiso de nadie.
Recapitulación en una tabla
| Situación | La frase o pieza que te salva |
|---|---|
| Avisar que investigas | "We are investigating... Next update in 15 minutes." |
| Confirmar la causa | "We have identified the cause..." |
| Cerrar el incidente en vivo | "This incident is resolved. A postmortem will follow." |
| Describir el estado del servicio | outage / partial outage / degraded / mitigated / resolved |
| Separar el "por qué" del "por qué tardamos" | root cause (uno) vs. contributing factors (varios) |
| Redactar sin culpar | Mueve el sujeto: "A change was deployed...", no "Carlos deployed..." |
| Escribir una acción real | "[Verbo] ... — @owner, due YYYY-MM-DD." |
| Cerrar con calma | "To prevent recurrence, we will... No data was lost." |
Ejercicios
Estos ejercicios entrenan las cuatro destrezas de la lección: redactar sin culpar, distinguir causa raíz de factor contribuyente, elegir la frase de la fase correcta durante el incidente, y convertir una acción vaga en una acción real. Resuélvelos por escrito antes de abrir la solución.
Ejercicio 1 — Reescribe sin culpa. Este fragmento culpa a una persona:
"Ana forgot to add a timeout to the payment API call, and that's why checkout hung for 12 minutes."
Reescríbelo en inglés siguiendo el patrón blameless: el sujeto debe ser el sistema o el proceso, no la persona, sin perder ni un dato técnico.
Ver solución
"The payment API call had no timeout configured, so checkout hung for 12 minutes when the downstream service stopped responding."
Por qué funciona: la información técnica es idéntica —falta un timeout, checkout se colgó 12 minutos— pero el sujeto de la frase pasó de "Ana" a "the payment API call". Nadie tapa nada; solo se apunta a la barrera que falta, no a quien no la puso.
Ejercicio 2 — Causa raíz o factor contribuyente. Un ingeniero rotó manualmente una API key a las 03:00 y olvidó actualizarla en la configuración del servicio de pagos; durante dos horas fallaron todas las llamadas de webhook. Clasifica cada afirmación como root cause o contributing factor:
a) "The payments service was configured with the old API key, which had been rotated and was no longer valid at the provider." b) "There was no automated alert for authentication failures on webhook calls, so the team only noticed after customers complained." c) "The runbook for key rotation did not include a step to update the payments service config."
Ver solución
- a) Root cause. Es el fallo de fondo: si la key no se hubiera quedado desactualizada en esa config, el incidente no habría ocurrido.
- b) Contributing factor. No causó el fallo, pero alargó cuánto tardó el equipo en enterarse.
- c) Contributing factor. Tampoco causó el fallo, pero explica por qué el paso de actualizar la config se saltó — es la barrera de proceso que faltaba.
Por qué funciona: la pregunta que separa a los dos tipos es "¿esto por sí solo habría causado el incidente?". Solo (a) responde que sí; (b) y (c) son ramas que empeoraron o alargaron el problema, no la raíz.
Ejercicio 3 — Escribe el mensaje de la fase correcta. El error rate de tu API subió a 10%. Hace un minuto tu equipo confirmó que la causa es un deploy reciente, y ahora mismo se está revirtiendo — todavía no saben si el rollback ya arregló todo. ¿En qué fase del ciclo de vida estás (investigating / identified / monitoring / resolved) y qué mensaje escribes para el canal de estado?
Ver solución
Fase: identified. Ya se sabe la causa, pero el arreglo todavía no se confirmó como exitoso (eso sería monitoring) y el incidente no está cerrado (eso sería resolved).
Mensaje: "We have identified the cause — a recent deployment is being rolled back now. Next update in 15 minutes."
Por qué funciona: la fase se decide por lo que sabes con certeza en este minuto, no por lo optimista que te sientas. Saber la causa no es lo mismo que haber confirmado la recuperación; adelantarte a decir resolved o monitoring antes de tiempo rompe la confianza si el problema regresa.
Ejercicio 4 — De acción vaga a acción real. Tu equipo escribió esta acción correctiva: "We should improve our alerting." Conviértela en una acción real con dueño y fecha, pensando en el incidente del Ejercicio 2 (falta de alerta para fallos de autenticación en webhooks).
Ver solución
"Add an alert for authentication failures on webhook calls — @maria, due 2026-04-10."
Por qué funciona: una acción real empieza con un verbo en imperativo, describe algo concreto que se puede marcar como hecho, y lleva un dueño y una fecha — sin esos dos datos, "improve our alerting" es un buen deseo, no un compromiso.
Resumen y siguiente paso
Antes de avanzar a la lección 8 deberías poder, sin volver a subir a mirar:
- Distinguir la comunicación durante el incidente (status update, presente, información parcial) del postmortem posterior (pasado, historia completa).
- Usar el vocabulario de estado (
outage,partial outage,degraded,mitigated,resolved) y explicar por quémitigatedno es lo mismo queresolved. - Separar
root cause(uno) decontributing factors(varios) en un incidente concreto. - Escribir un postmortem completo en inglés con sus ocho secciones (summary, impact, timeline en UTC, detection, root cause, contributing factors, resolution, action items).
- Redactar de forma blameless moviendo el sujeto de la persona al sistema, y escribir una action item con dueño y fecha.
Si alguno de esos puntos todavía te tambalea, vuelve a la parte correspondiente antes de seguir — el proyecto de la lección 8 asume que estas piezas ya son tuyas.
Puente a la lección 8. Cierra el módulo con el proyecto: un design doc completo en inglés llano sobre un sistema propio, con su ADR y su README integrados. El postmortem que acabas de aprender es la otra cara de esa misma moneda — el design doc dice cómo esperas que algo funcione; el postmortem, qué aprendiste cuando no funcionó. Ahí verás cómo las cuatro piezas del módulo (lenguaje llano, design doc, ADR, README/postmortem) se ensamblan en un solo documento de portafolio.
Recursos
- Google SRE Book — Postmortem Culture: Learning from Failure — el capítulo que originó la cultura del postmortem sin culpables en la industria; la fuente directa del enfoque blameless de esta lección.
- Atlassian — How to run a blameless postmortem — guía práctica sobre cómo facilitar la redacción y la reunión de un postmortem sin caer en la culpa individual.
- PagerDuty — Postmortems — guía abierta con plantilla, checklist y preguntas de análisis para escribir un postmortem de principio a fin.
- PagerDuty — Incident Response — documentación abierta sobre el ciclo de vida de un incidente (detección, investigación, mitigación) y cómo comunicarlo mientras ocurre.