Módulo 5: The Incident Lifecycle

1. Introducción: el marco antes del caso

Descripción

El Módulo 4 terminó con ALERTING-POLICY.md probado con un simulacro forzado: la "mala semana" dispara las tres severidades de la Tabla 5-8 de Google SRE, el escenario normal no dispara ninguna. La máquina de medición está completa —SLI (Módulo 2) → dato real (Módulo 3) → alerta de burn rate (Módulo 4)—, y funciona. Pero cuando esa alerta suena de verdad, a las 3 AM o a mitad de una reunión, ALERTING-POLICY.md no contesta ni una sola de las preguntas que de verdad importan en ese momento: ¿a quién se le avisa? ¿Qué tan grave es, en términos que alguien pueda decidir con eso? ¿Quién decide qué hacer, y quién lo ejecuta, y son la misma persona? Este módulo construye esas respuestas —ciclo de vida, severidades, roles, rotación de guardia— antes de que el Módulo 6 opere el incidente Claude Code real, para que ese módulo aplique un marco ya decidido, en vez de improvisarlo mientras el reloj corre.

Conexión con el módulo

Este es exactamente el renglón que RELIABILITY-CHARTER.md (Módulo 1, lección 8) dejó abierto para el Módulo 5 en su mapa: "¿Quién hace qué, con qué severidad, con qué guardia?". Al cierre de este módulo, esa fila pasa de Open a Resolved, con INCIDENT-RESPONSE-PLAN.md como evidencia. Nada de lo que sigue es nuevo en el sentido de "matemática nueva" —las severidades de este módulo se atan, número por número, a los mismos tres niveles de burn rate que ALERTING-POLICY.md ya construyó y probó (14,4x, 6x, 1x)—; lo nuevo es la capa humana encima de esa matemática: quién responde, y con qué urgencia exacta.

Por qué este marco se construye antes del incendio, no durante

Piensa en un simulacro de evacuación. Nadie diseña las rutas de salida, asigna quién cuenta a las personas en el punto de encuentro, ni decide quién tiene autoridad para llamar a los bomberos, mientras el edificio ya se está llenando de humo. Esas decisiones se toman en una tarde tranquila, sin presión, precisamente porque la calidad de una decisión tomada bajo presión real es mucho peor que la misma decisión tomada con tiempo de sobra —y porque, una vez que el humo aparece, ya no queda tiempo para diseñar nada: solo queda ejecutar lo que ya estaba decidido.

Este módulo es ese simulacro, para Andes Cargo. El incidente Claude Code que el Módulo 6 va a operar ya pasó —los hechos, verificados por tres guías hermanas, no van a cambiar—, así que la tentación real es saltar directo a narrarlo con el vocabulario ya aprendido. Esta guía resiste esa tentación a propósito, por la misma razón que un equipo de SRE real jamás diseñaría sus roles de incidente el mismo día que un sistema se cae: improvisar el marco durante la presión real es, casi siempre, la forma en que un incidente manejable se convierte en un incidente caótico —no por falta de habilidad técnica, sino por falta de una estructura ya acordada de antemano sobre quién decide y quién ejecuta.

   DOS ORDENES POSIBLES, UN SOLO RESULTADO DESEABLE

   ORDEN A (el que sigue esta guia)          ORDEN B (el que esta guia evita)
   ─────────────────────────────────         ─────────────────────────────────
   Modulo 5: se construye el marco           Modulo 6: el incidente ya esta
   completo -- ciclo de vida, severidad,     en curso -- alguien pregunta
   roles, guardia -- SIN presion real         "¿quien decide aca?" por primera
        │                                     vez, en vivo, bajo presion
        ▼                                          │
   Modulo 6: el incidente Claude Code               ▼
   se opera APLICANDO un marco ya                Cada persona improvisa su
   decidido -- cada rol, cada severidad,          propio rol, nadie sabe si
   ya tenia una respuesta antes de que             ya se declaro un incidente
   el primer dato del incidente llegara            formalmente o no

El mapa de este módulo: las 8 lecciones

   MODULO 5 — EL CICLO DE VIDA DEL INCIDENTE
   el marco humano, construido antes del caso que el Modulo 6 va a operar

   M5.1  Introduccion (esta leccion)              por que el marco va antes del caso
   M5.2  El ciclo de vida de un incidente          citado de Google SRE, diagrama ASCII
   M5.3  Niveles de severidad                       SEV1-4, ejemplos narrativos de Andes Cargo
   M5.4  Roles durante un incidente                 IC / Ops Lead / Comms Lead, citado
   M5.5  Manos a la obra: la matriz de severidad     EJECUTADO: SEV atado a burn rate real
   M5.6  On-call, con honestidad sobre su costo      cita HN completa, que si y que no resuelve
   M5.7  Manos a la obra: rotacion determinista       EJECUTADO: oncall/schedule.py, salida real
   M5.8  Proyecto: INCIDENT-RESPONSE-PLAN.md            EJECUTADO: el documento completo

#	Lección	Qué construye
1	Introducción (esta)	Por qué el marco se construye antes del caso, no después
2	El ciclo de vida de un incidente	Detección → declaración → respuesta → mitigación → resolución, citado de Google SRE
3	Niveles de severidad, con ejemplos reales de Andes Cargo	SEV1-4, de "dos segundos más" a "`Shipments` no responde", narrativo
4	Roles durante un incidente	Incident commander, comunicación, operaciones — citado de Google SRE
5	Manos a la obra: la matriz de severidad de Andes Cargo	Ejecutado: cada SEV atado, número por número, a un nivel de burn rate de `ALERTING-POLICY.md`
6	On-call, con honestidad sobre su costo	La cita completa de HN sobre el costo real de cambiar de herramienta
7	Manos a la obra: una rotación de on-call determinista	Ejecutado: `oncall/schedule.py`, salida literal, dos corridas idénticas
8	Proyecto: `INCIDENT-RESPONSE-PLAN.md` de Andes Cargo	Ejecutado: el documento completo — ciclo de vida, severidad, roles, rotación

El hilo de este módulo: nada de matemática nueva, toda la capa humana

A diferencia del Módulo 4 —donde cada lección construía un motor de alerta distinto sobre la misma matemática—, este módulo no calcula ningún número nuevo de burn rate. Reutiliza, sin modificarlos, los tres umbrales que ALERTING-POLICY.md ya dejó probados: Page (fast) a 14,4x, Page (slow) a 6x, Ticket a 1x. Lo que este módulo construye es la capa que le da sentido humano a esos tres números: qué severidad le corresponde a cada uno (lección 3, formalizada en la 5), quién responde cuando cruzan el umbral (lección 4), y quién está de guardia esa semana específica para responder (lecciones 6 y 7).

Honestidad de este módulo: qué corre de verdad, qué es documento razonado

Pieza	Estado en este módulo	Razón técnica exacta
Ciclo de vida (lección 2)	Citado, con diagrama propio	Fuente oficial de Google SRE, sin infraestructura que ejecutar — es un marco conceptual, no un cálculo.
Severidades narrativas (lección 3)	Citado + narrativo	Ejemplos de Andes Cargo en prosa, todavía sin la aritmética formal —esa llega en la lección 5—.
Roles (lección 4)	Citado, con diagrama propio	Misma naturaleza que la lección 2: marco conceptual de la fuente oficial.
Matriz de severidad (lección 5)	Ejecutado (aritmética manual, sin script)	Mismo patrón que el Módulo 1, lección 6: cálculo real a mano, verificable línea por línea, sin necesitar infraestructura.
Cita de on-call (lección 6)	Citado, verificado contra la fuente	Hacker News, comentario real de `jamiemallers`, verificado para esta lección.
`oncall/schedule.py` (lección 7)	Ejecutado, real	Python puro, sin dependencias externas, corrido con `python3` para escribir esta lección.
`INCIDENT-RESPONSE-PLAN.md` (lección 8)	Ejecutado, real	El documento completo, verificado con `wc -l`/`grep -c`, igual que `SLO.md` y `ALERTING-POLICY.md`.

La regla que gobierna toda esta guía se mantiene: si un número aparece en una lección, es trazable hasta un cálculo real o una fuente citada — nunca una cifra inventada para que el ejemplo se vea completo.

Errores comunes

Tratar este módulo como "solo papeleo", sin la misma exigencia de precisión que el Módulo 2 o el Módulo 4 (de subestimar un módulo sin script central). Qué pasa: alguien, al ver que este módulo no construye ningún nuevo scripts/*.py central hasta la lección 7, asume que el contenido es opinión sin verificación posible. Cómo detectarlo: si tratas la matriz de severidad de la lección 5 como una lista de preferencias, en vez de una tabla donde cada fila se deriva de un umbral de burn rate ya calculado y probado en el Módulo 4. Cómo corregirlo: cada severidad de este módulo tiene un número exacto detrás —14,4x, 6x, 1x, los mismos tres de ALERTING-POLICY.md— y la rotación de la lección 7 sí es un script real, corrido de verdad. "Poco código" no significa "sin rigor": este módulo es marco y documentos, con la misma disciplina determinista del resto de la guía.

Asumir que "construir el marco antes" significa que nunca va a cambiar una vez escrito (de leer INCIDENT-RESPONSE-PLAN.md como un documento congelado). Qué pasa: alguien concluye que, una vez que este módulo cierre, la severidad y los roles de Andes Cargo quedan fijos para siempre, sin posibilidad de ajuste. Cómo detectarlo: si tu lectura de este módulo es "esto ya no se vuelve a tocar". Cómo corregirlo: el Módulo 8 explícitamente corre un incidente sintético nuevo contra este mismo marco para confirmar que sigue funcionando — un marco de respuesta a incidentes real se revisa después de cada incidente real (el Módulo 7 construye exactamente ese mecanismo, con los action items del postmortem), no se escribe una vez y se abandona.

Esperar que este módulo ya narre el incidente Claude Code (de anticipar el Módulo 6 antes de tiempo). Qué pasa: alguien, al ver "Claude Code" mencionado en los ejemplos de este módulo, espera que la lección 3 o la 5 ya clasifiquen ese incidente específico con severidad y roles asignados. Cómo detectarlo: si buscas, en las lecciones de este módulo, una fecha o un timeline del incidente real. Cómo corregirlo: este módulo construye el marco genérico, con ejemplos hipotéticos de Andes Cargo (envíos de ejemplo, escenarios de latencia) — nunca el caso real. El Módulo 6 es, específicamente, el que toma este marco ya terminado y lo aplica, por primera vez, al incidente Claude Code con sus fechas y cifras reales.

Ejercicios

Ejercicio 1 — Explica, con tus propias palabras y sin usar la palabra "papeleo", por qué construir este marco en el Módulo 5 (antes del Módulo 6) produce una mejor operación del incidente real que construirlo dentro del propio Módulo 6.

Ver solución

Construir el marco antes separa dos tipos de decisión que, mezcladas bajo presión, se interfieren entre sí: decidir qué severidad usar, quién es el Incident Commander, y cómo se arma una rotación de guardia son decisiones de diseño, que se benefician de tiempo, comparación de alternativas, y ausencia de presión de tiempo real. Aplicar esas decisiones ya tomadas a un incidente específico —leer los hechos, clasificarlos contra la matriz ya existente, asignar los roles ya definidos a personas concretas— es un tipo de trabajo completamente distinto, mucho más rápido y con menos margen de error, porque no exige inventar la estructura al mismo tiempo que se responde a la emergencia. El Módulo 6 va a ser más rápido y más confiable, no a pesar de este módulo, sino gracias a él.

Ejercicio 2 — El mapa de este módulo dice que las severidades de la lección 5 se atan "número por número" a los umbrales de ALERTING-POLICY.md. Sin haber leído todavía la lección 2 del Módulo 4, ¿qué tres números esperarías encontrar reutilizados en este módulo?

Ver solución

14,4x (Page (fast)), 6x (Page (slow)), y 1x (Ticket) — los tres umbrales de la Tabla 5-8 de Google SRE que el Módulo 4, lección 2 citó completa, y que el Módulo 4, lección 3 (burn_rate_evaluator.py) implementó y corrió de verdad sobre los dos escenarios fijos del Módulo 2. Este módulo no inventa un cuarto umbral ni cambia ninguno de los tres — los hereda exactamente como ALERTING-POLICY.md los dejó, y solo agrega la pregunta "¿y entonces quién responde, y qué tan rápido?" encima de cada uno.

Ejercicio 3 — Un compañero argumenta que, ya que Andes Cargo es un proyecto de aprendizaje sin tráfico real ni clientes reales, construir un INCIDENT-RESPONSE-PLAN.md completo es un ejercicio inútil. ¿Cómo responderías, usando la razón de ser de este módulo?

Ver solución

El valor de este módulo no depende de que Andes Cargo tenga tráfico de producción real — depende de que la disciplina de construir el marco antes del caso, con roles y severidades trazables a números reales, es exactamente la misma disciplina que un entrevistador técnico, o un equipo real, esperaría ver aplicada en cualquier sistema, grande o pequeño. Además, el Módulo 6 sí va a aplicar este marco a un incidente con datos completamente reales y verificados —el de DataTalks.Club—, y el Módulo 8 lo va a probar contra un incidente sintético determinista. INCIDENT-RESPONSE-PLAN.md no es un ejercicio de imaginación aislado: es la pieza de portafolio que demuestra que quien lo escribió sabe diseñar un marco de respuesta a incidentes desde cero, con evidencia, no solo citarlo de memoria.

Resumen y siguiente paso

Esta lección instaló la razón de ser de todo el módulo: el marco de respuesta a incidentes —ciclo de vida, severidad, roles, guardia— se construye antes de operar el incidente Claude Code real, exactamente como un simulacro de evacuación se diseña antes de que aparezca el humo, nunca durante. Viste el mapa completo de las 8 lecciones, el hilo que las conecta —ninguna matemática nueva, toda la capa humana encima de los tres umbrales de burn rate que ALERTING-POLICY.md ya dejó probados—, y la tabla de honestidad de este módulo.

Antes de avanzar deberías poder: explicar por qué construir este marco antes produce una mejor respuesta que improvisarlo durante el incidente; nombrar los tres umbrales de burn rate que este módulo va a reutilizar sin cambiarlos; y defender, frente a una objeción real, por qué este marco vale la pena aunque Andes Cargo no tenga tráfico de producción real.

La lección 2 abre el marco con su primera pieza: el ciclo de vida completo de un incidente, citado directamente de la guía de gestión de incidentes de Google SRE.

Recursos

Este mismo repositorio, Módulo 4, lección 8 (08-project-andes-cargos-alerting-policy.md) — ALERTING-POLICY.md, los tres umbrales de burn rate que este módulo reutiliza sin cambiarlos.
Este mismo repositorio, Módulo 1, lección 8 (08-project-andes-cargos-reliability-charter.md) — RELIABILITY-CHARTER.md, la fila del mapa que este módulo resuelve.
Google SRE — Incident Management Guide — la fuente que la lección 2 de este módulo cita completa.
Google SRE Book — Managing Incidents — profundidad adicional sobre roles y separación de responsabilidades, citada en la lección 4.

← Anterior8. Proyecto: la política de *alerting* de Andes Cargo Siguiente →2. El ciclo de vida de un incidente