Presentación del módulo: resolviste el incidente. Ahora aprende de él.

Por qué este módulo, ahora

El módulo 5 te dio el mecanismo para responder cuando algo se rompe: rollbackDecision(), el runbook, la severidad, el kill switch del módulo 2 activado en segundos. Aplicado al caso que arrastra toda esta guía, ese mecanismo ya hizo su trabajo — el guardrail de latencia se rompió en la etapa de 10% del rollout de recommendations (p95Latency en 910ms, contra un techo de 800ms), el equipo declaró el incidente, activó el kill switch, y confirmó que la exposición volvió a 0%. El incidente, en el sentido estricto de "algo activo que hay que contener ahora mismo", está resuelto.

Es tentador leer "resuelto" como "terminado", cerrar la ventana del chat de incidente, y pasar a la siguiente prioridad. Este módulo existe porque ese salto es exactamente el error que deja el mayor valor sobre la mesa sin cobrar. Un incidente resuelto sin más es una oportunidad de aprendizaje que se evapora: el sistema mostró, con evidencia real y medida, exactamente dónde estaba su punto débil — y esa evidencia solo vale algo si alguien la convierte en un postmortem que explica qué pasó sin buscar culpables, en action items concretos que arreglan la causa, y en una decisión explícita de si vale la pena iterar sobre el ganador que causó el problema, en vez de abandonarlo.

Ese es el arco completo de este módulo: de "resuelto" a "aprendido", y de "aprendido" a "relanzado y medido de nuevo". El lanzamiento de recommendations no termina cuando el flag se enciende — ahí es, literalmente, donde empieza la parte que este módulo enseña.

Conexión con el módulo 5. Ese módulo se detuvo exactamente en el momento de la decisión: guardrail roto, rollbackDecision() devuelve rollback, exposición vuelve a 0%. Este módulo retoma justo ahí, con el incidente ya contenido, y hace dos cosas que el módulo 5 dejó explícitamente pendientes: documentar qué pasó de una forma que enseñe algo al resto de la organización (el postmortem), y decidir qué sigue con el producto en sí — no con el incidente.

Una analogía: la caja negra del avión, y la cocina que prueba antes de servir

Cuando un avión tiene un incidente en pleno vuelo —una turbulencia severa, una alerta de sistema, un aterrizaje de emergencia—, la industria de aviación no se pregunta primero "¿qué piloto lo causó?". Recupera la caja negra: la grabadora de datos de vuelo y la de voces de cabina, reconstruye segundo a segundo qué pasó, en qué orden, y qué condiciones del sistema —no del piloto individual— permitieron que pasara. La pregunta central nunca es "¿quién falló?"; es "¿qué en el diseño, el entrenamiento o el procedimiento permitió que esto pasara, y qué cambia para que no vuelva a pasar?". Esa disciplina —investigar el sistema, no cazar a la persona— es, casi palabra por palabra, lo que la lección 2 de este módulo llama postmortem blameless.

La segunda mitad de este módulo tiene una analogía distinta, más cotidiana: cocinar no termina cuando el plato sale del fuego. Un cocinero que de verdad le importa el resultado prueba la comida, ajusta la sal, prueba de nuevo — nunca sirve un plato una sola vez y se olvida de si a la gente le gustó. El loop ship → measure → learn de la lección 5 es exactamente esa disciplina aplicada al lanzamiento: encender el flag no es el final de la receta, es el momento en el que empiezas a probar el plato.

Ejemplo trabajado: dónde nos dejó el módulo 5

Antes de construir nada nuevo, vale la pena dejar explícito, en código, el estado exacto que este módulo recibe como punto de partida — no hay lógica nueva todavía, solo los datos del handoff:

// Recapitulacion: exactamente donde nos dejo el modulo 5 (rollback e
// incident response). No hay logica nueva todavia -- solo el estado final
// que este modulo 6 recibe como punto de partida.
const handoff = {
  feature: 'recommendations',
  stage: 'rollout 10%',
  guardrailBroken: { metric: 'checkoutLatencyP95Ms', measured: 910, ceiling: 800 },
  decision: 'rollback',
  flagState: { enabled: false, rolloutPercent: 0 },
  incidentStatus: 'resuelto -- exposicion confirmada en 0%',
};

console.log('=== Donde nos dejo el modulo 5 ===\n');
console.log('feature: ' + handoff.feature + ' | etapa: ' + handoff.stage);
console.log('guardrail roto: ' + handoff.guardrailBroken.metric + '=' + handoff.guardrailBroken.measured +
  'ms (techo ' + handoff.guardrailBroken.ceiling + 'ms)');
console.log('decision tomada: ' + handoff.decision);
console.log('estado del flag: enabled=' + handoff.flagState.enabled + ', rolloutPercent=' + handoff.flagState.rolloutPercent);
console.log('estado del incidente: ' + handoff.incidentStatus);

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

=== Donde nos dejo el modulo 5 ===

feature: recommendations | etapa: rollout 10%
guardrail roto: checkoutLatencyP95Ms=910ms (techo 800ms)
decision tomada: rollback
estado del flag: enabled=false, rolloutPercent=0
estado del incidente: resuelto -- exposicion confirmada en 0%

Fíjate en algo importante sobre este objeto: incidentStatus dice "resuelto", pero no dice nada todavía sobre por qué rompió el guardrail, qué cambia para que no vuelva a pasar, ni si recommendations va a volver a intentarse. Esas tres preguntas —el postmortem, los action items, y la decisión de iterar— son, exactamente, las siete lecciones de tema que siguen en este módulo. rollbackDecision() del módulo 5 contestó "¿qué hacemos ahora mismo?". Este módulo contesta "¿qué aprendemos, y qué hacemos con lo que aprendimos?".

El mapa de las ocho lecciones de este módulo

Lección   Pregunta que contesta
────────  ──────────────────────────────────────────────────────────────
L1        (esta) ¿Dónde nos dejó el módulo 5, y qué falta resolver?
L2        ¿Qué es un postmortem blameless, y por qué "blameless" no es "sin consecuencias"?
L3        ¿Cómo se estructura un postmortem, en concreto: timeline, factores, action items?
L4        ¿Por qué el lenguaje que uses determina si la cultura es blameless de verdad?
L5        ¿Qué es el loop ship → measure → learn, y por qué el lanzamiento no termina en "encendido"?
L6        ¿Cómo se itera sobre un ganador, en concreto: arreglar, relanzar, medir de nuevo?
L7        ¿Cuándo un "ganador" no aguanta en producción, y cómo se detecta a tiempo?
L8        Proyecto: escribe el postmortem del incidente de recommendations y planea su iteración

La lección 2 instala la idea central del módulo con su nombre técnico correcto: un postmortem blameless no busca a la persona que "rompió" algo — investiga el sistema que permitió que se rompiera, y trata a las personas como la fuente más confiable de información sobre por qué una decisión, en su momento, pareció razonable. La lección 3 baja esa idea a una estructura concreta y reproducible: buildPostmortem(), que toma la timeline cruda de un incidente y la convierte en tres piezas ordenadas —eventos en secuencia, factores contribuyentes, action items— y que además verifica que el resultado sea blameless, marcando como red flag cualquier factor que nombre a una persona en vez de un proceso. La lección 4 profundiza en la cultura detrás de esa mecánica: por qué el lenguaje que elige un equipo —"el proceso no exigía X" contra "Fulano no hizo X"— no es un detalle de estilo, es la diferencia entre un postmortem que la gente completa con honestidad y uno que la gente aprende a evitar o a maquillar.

Con el postmortem cerrado, la lección 5 da un paso atrás y nombra el marco más grande en el que vive todo esto: el loop ship → measure → learn, la idea de que lanzar, medir el resultado, y aprender de ese resultado no son tres pasos que se hacen una vez — son un ciclo que se repite. La lección 6 aplica ese loop, en concreto, al ganador de esta guía: con los action items del postmortem ya resueltos (la causa técnica arreglada), recommendations se relanza por la misma rampa del módulo 3, y se mide de nuevo. La lección 7 cierra el arco temático con una advertencia importante: no todo lo que sube después de un lanzamiento se sostiene — el efecto novedad puede hacer que un "ganador" se desinfle solas semanas después de encendido, y esta lección enseña a detectarlo antes de declarar victoria demasiado pronto. La lección 8, el proyecto, junta las tres piezas centrales del módulo —postmortem, relanzamiento, medición de si el efecto se sostiene— sobre el caso completo de recommendations.

La frontera: qué NO entra en este módulo

• Cómo se toma la decisión de revertir o arreglar hacia adelante, y el runbook del incidente es el módulo 5. Aquí el incidente ya está cerrado; este módulo trabaja con su resultado.
• Migrar modelos de IA con shadow mode, y el postmortem específico de un incidente de IA es el módulo 7. El postmortem que construyes aquí es general —aplica a cualquier lanzamiento de producto—; el módulo 7 aplica el mismo marco a la capa de IA, con sus propias particularidades (tasa de acuerdo, salidas de modelo).
• Ejecutar las siete piezas de la guía completa sobre recommendations, de punta a punta es el módulo 8, el capstone. Este módulo construye y ejecuta el postmortem y la iteración como su propia pieza cerrada; el capstone las integra con flags, rollout, monitoreo y rollback en un solo entregable.
• Recalcular si el lift de recommendations es estadísticamente significativo, o medir el efecto novedad con rigor estadístico (ventanas pre-registradas, intervalos de confianza) es product-metrics-and-experimentation-guide. Ese resultado —+18.75%, p=0.0114, medido sobre una ventana de 6 semanas completa, precisamente para que el efecto novedad ya se hubiera disipado— se usa aquí, no se recalcula.

Errores comunes

Tratar "el incidente está cerrado" como sinónimo de "ya aprendimos lo que había que aprender". Qué pasa: el equipo confirma que la exposición volvió a 0%, respira aliviado, y pasa a la siguiente prioridad sin escribir nunca el postmortem. Por qué pasa: el alivio de haber contenido el daño se siente como el final de la historia, y escribir un documento sobre algo que "ya se resolvió" se siente como trabajo administrativo de baja prioridad. Cómo detectarlo: si preguntas, dos semanas después del incidente, "¿por qué se rompió exactamente, y qué cambió para que no vuelva a pasar?", y nadie tiene una respuesta escrita, el aprendizaje nunca se capturó — solo se contuvo el síntoma. Cómo corregirlo: como distingue este módulo, rollbackDecision() cierra el incidente; el postmortem cierra el aprendizaje. Son dos cierres distintos, y el segundo no ocurre automáticamente solo porque el primero ya pasó.

Escribir el postmortem, pero nunca volver a lanzar la feature que causó el incidente. Qué pasa: el equipo documenta cuidadosamente qué pasó con recommendations, arregla la causa técnica en el backlog... y ahí se queda, sin que nadie relance la feature ni mida si el arreglo funcionó. Por qué pasa: el incidente dejó una asociación negativa con la feature, y es más cómodo dejarla "pausada indefinidamente" que asumir el riesgo de intentarlo de nuevo, aunque la causa raíz ya esté resuelta. Cómo detectarlo: si recommendations sigue en enabled: false semanas después de que los action items del postmortem se cerraron, sin ninguna fecha planeada de relanzamiento, la iteración se abandonó. Cómo corregirlo: el postmortem sin iteración deja el valor de negocio del ganador —+18.75% en conversión— completamente sin cobrar. La lección 6 de este módulo existe precisamente para esto: una vez arreglada la causa, relanzar por la misma rampa ya probada no es un riesgo nuevo, es la continuación natural del trabajo ya hecho.

Declarar victoria en cuanto el relanzamiento pasa el guardrail, sin medir varias semanas después. Qué pasa: recommendations se relanza, la latencia se sostiene bajo el techo en las cuatro etapas, y el equipo cierra el caso ahí mismo, sin volver a mirar el lift de conversión unas semanas después. Por qué pasa: pasar el guardrail técnico se siente como "ya funcionó", y es fácil olvidar que el guardrail mide un riesgo (la latencia), no si el beneficio (la conversión) se sostiene en el tiempo. Cómo detectarlo: si nadie puede mostrar el lift de conversión medido en la semana 4, 5 o 6 después del relanzamiento —solo el dato del día del lanzamiento—, todavía no se sabe si el "ganador" es real o era efecto novedad. Cómo corregirlo: la lección 7 de este módulo construye exactamente el chequeo que falta —noveltyCheck()— para separar un efecto que se sostiene de uno que se desinfla, antes de cerrar el caso por completo.

Ejercicios

Ejercicio 1 — Ubica la pregunta. Para cada pregunta, di si la contesta el módulo 5 (ya visto) o este módulo 6:

• (a) "El guardrail de latencia se rompió a 10%. ¿Revertimos o arreglamos hacia adelante?"
• (b) "Ya revertimos. ¿Cómo escribimos lo que pasó sin que se sienta una cacería de culpables?"
• (c) "Ya arreglamos la causa técnica. ¿Volvemos a intentar el lanzamiento, y cómo sabemos si el resultado se sostiene?"

Ver solución

• (a) Módulo 5 — rollbackDecision() contesta exactamente esta pregunta, dado el estado de los guardrails.
• (b) Este módulo 6, lecciones 2 a 4 — el postmortem blameless, su estructura y su cultura.
• (c) Este módulo 6, lecciones 5 a 7 — el loop ship → measure → learn, iterar sobre el ganador, y detectar si el resultado se sostiene o era novedad.

Ejercicio 2 — La analogía, en tus palabras. Usando la analogía de la caja negra del avión, explica en dos o tres frases por qué la industria de aviación investiga "qué permitió que esto pasara" en vez de "quién lo causó" — y por qué esa misma pregunta aplica al incidente de latencia de recommendations.

Ver solución

La industria de aviación aprendió, después de décadas de datos, que culpar a un piloto individual por un error no evita que el mismo error ocurra de nuevo con otro piloto distinto, bajo las mismas condiciones del sistema — mientras que arreglar el sistema (un procedimiento, un diseño de cabina, un protocolo de entrenamiento) sí lo evita, para cualquier piloto futuro. Aplicado a recommendations: si el postmortem concluyera "alguien aprobó mal el avance de etapa", el problema seguiría ahí para el próximo lanzamiento con otra persona en ese rol. Si en cambio concluye "el criterio de avance no exigía una prueba de carga equivalente al volumen de la siguiente etapa", arreglar ese criterio protege a cualquier lanzamiento futuro, sin importar quién esté a cargo.

Ejercicio 3 — Predicción con criterio. Sin haber leído todavía la lección 7, piensa en dos formas de medir si recommendations "funcionó" después de relanzarse: medir el lift el mismo día del lanzamiento al 100% contra medir el lift cada semana durante seis semanas después del lanzamiento. ¿Cuál de las dos formas te parece más confiable para decidir si el ganador es real, y por qué?

Ver solución

Medir cada semana durante varias semanas es la forma más confiable, aunque el número del primer día se vea, muy probablemente, más alto y más emocionante. La razón, sin necesitar todavía el vocabulario formal de "efecto novedad" que trae la lección 7: cualquier cambio visible en un producto genera curiosidad inicial —la gente lo nota, lo prueba— y esa curiosidad puede inflar el número de los primeros días sin que refleje el comportamiento sostenido de largo plazo. Medir solo el primer día corre el riesgo de reportar ese pico de curiosidad como si fuera el efecto real y permanente. Medir semana a semana, en cambio, permite ver si el número se mantiene estable con el tiempo o si cae hacia un valor más bajo una vez que la novedad se disipa — la única forma de distinguir un ganador real de uno que solo brilló al principio.

Resumen y siguiente paso

En esta lección ubicaste este módulo en el arco completo de la guía: el módulo 5 contuvo el incidente de latencia de recommendations y lo cerró con una decisión de rollback; este módulo 6 toma ese incidente ya resuelto y hace las dos cosas que faltaban — documentarlo sin buscar culpables (postmortem blameless) y decidir qué sigue con el producto (el loop ship → measure → learn). Viste el mapa completo de las ocho lecciones y la frontera con los módulos 5, 7 y 8.

Antes de avanzar deberías poder: explicar por qué "el incidente está cerrado" y "ya aprendimos lo que había que aprender" son dos afirmaciones distintas; distinguir la pregunta que contesta el módulo 5 de las que contesta este módulo 6; y anticipar, a grandes rasgos, por qué medir el resultado de un relanzamiento una sola vez no basta para confiar en él.

La lección 2 entra de lleno al primer concepto del módulo: ¿qué es, exactamente, un postmortem blameless, y por qué "blameless" no significa "sin consecuencias"?

Recursos

• Google SRE Book, Capítulo 15, "Postmortem Culture: Learning from Failure" — sre.google/sre-book/postmortem-culture. El capítulo de referencia sobre por qué un postmortem existe para aprender, no para castigar, y cómo Google institucionalizó esa cultura. Desarrollado a fondo en las lecciones 2 a 4 de este módulo. En inglés.
• Eric Ries, The Lean Startup — resumen del framework en theleanstartup.com/principles. El loop build → measure → learn original, la base conceptual del ship → measure → learn que desarrolla la lección 5 de este módulo. En inglés.
• Atlassian, "How to run a blameless postmortem" — atlassian.com/incident-management/postmortem/blameless. Una guía práctica de industria sobre la misma disciplina, con ejemplos de cómo estructurar la conversación del postmortem. En inglés.