Módulo 5: The Incident Lifecycle
2. El ciclo de vida de un incidente
Descripción
Esta lección contesta la primera pregunta de todo el módulo: cuando algo se rompe, ¿qué pasa, en qué orden, y quién decide en cuál etapa está el sistema en cada momento? La respuesta no se inventa aquí — se cita, directamente, de la guía de gestión de incidentes de Google SRE y del capítulo del SRE Book sobre manejo de incidentes, las dos fuentes oficiales que esta lección contrasta y sintetiza en cinco etapas concretas: detección → declaración → respuesta → mitigación → resolución.
Conexión con el módulo
Cada una de estas cinco etapas reaparece, con un nombre propio, en un momento específico del Módulo 6: la detección es lo que la alerta de ALERTING-POLICY.md ya sabe hacer (Módulo 4); la declaración es el mensaje formal que el Módulo 6, lección 4 va a escribir; la respuesta necesita los roles que la lección 4 de este módulo define; la mitigación es el árbol de decisión que el Módulo 6, lección 6 va a reconstruir; la resolución cierra con el timeline que el Módulo 6, lección 8 entrega. Esta lección es el mapa completo; el Módulo 6 lo recorre, paso por paso, con el incidente real.
Las cinco etapas, citadas y definidas
1. Detección
No todo lo que se ve mal es, automáticamente, un incidente. La fuente citada da un criterio explícito, no una intuición:
"[...] if any of the following is true, the event is an incident: Do you need to involve a second team in fixing the problem? Is the outage visible to customers? Is the issue unsolved even after an hour's concentrated analysis?"
Tres preguntas, no una sola señal técnica: ¿hace falta un segundo equipo para arreglarlo? ¿Es visible para los clientes? ¿Sigue sin resolverse después de una hora de análisis concentrado? Si la respuesta a cualquiera de las tres es "sí", ya es un incidente — no importa qué tan pequeño se sienta al principio. Detectar, en el vocabulario de esta guía, es el momento en que una alerta de ALERTING-POLICY.md dispara (el dato técnico ya existe), pero detectar no es lo mismo que declarar — esa distinción es exactamente la siguiente etapa.
2. Declaración
Declarar un incidente es el acto formal de decir, en voz alta y por escrito, "esto es un incidente, y a partir de ahora se maneja como tal". Es un paso que a menudo se salta por accidente: alguien ve la alerta, empieza a investigar por su cuenta, y nunca comunica formalmente que el sistema está en modo incidente. La guía de gestión de incidentes de Google SRE enmarca la preparación para este momento como una fase completa y separada:
"Prepare for incidents [...]: Establishing alerting mechanisms and on-call processes before outages occur"
La preparación —tener ya listos los mecanismos de alerta y los procesos de guardia, exactamente lo que el Módulo 4 y las lecciones 6-7 de este módulo construyen— es lo que hace posible declarar un incidente en segundos, en vez de minutos perdidos decidiendo si "esto cuenta" o no. Declarar es el punto exacto donde termina la ambigüedad y empiezan los roles formales.
3. Respuesta
Con el incidente declarado, entra en juego la coordinación activa: alguien asume el rol de Incident Commander, alguien más se enfoca en mitigar, alguien más comunica. La fuente lo resume como la fase de:
"Respond and manage incidents [...]: Active coordination and mitigation during the event"
Esta guía trata "respuesta" como el momento en que los roles de la lección 4 de este módulo entran en acción — todavía no es el arreglo técnico en sí, es la coordinación que hace posible que el arreglo técnico ocurra sin que dos personas apliquen cambios contradictorios al mismo tiempo.
4. Mitigación
Mitigar no es lo mismo que resolver por completo — es limitar el daño mientras la causa real se entiende o se corrige:
"[...] limiting the disruption caused by an incident and restoring normal business operations as quickly as possible."
Un ejemplo concreto, sobre process-shipment-manifest: si una versión desplegada empieza a fallar la mitad de las invocaciones, mitigar podría significar revertir al despliegue anterior — el sistema vuelve a funcionar, pero la causa raíz de por qué la nueva versión falló todavía no se investigó a fondo. Eso llega en el postmortem del Módulo 7, no en esta etapa.
5. Resolución
Un incidente se cierra cuando la condición que lo disparó ya no está activa — no cuando "ya nadie está mirando la alerta":
"[...] incidents are closed once mitigated."
Cerrar formalmente el incidente es también el punto donde arranca la siguiente disciplina completa de esta guía, todavía fuera del alcance de este módulo: el aprendizaje sistémico. La misma fuente lo llama la fase de "Remediate and learn from incidents" — la resolución no es el final de la historia, es la transición hacia el postmortem sin culpa que el Módulo 7 construye.
Las cinco etapas, en un diagrama
EL CICLO DE VIDA DE UN INCIDENTE — CINCO ETAPAS
DETECCION DECLARACION RESPUESTA
────────── ─────────── ─────────
La alerta de Alguien dice, Los roles de la
burn rate dispara formalmente: leccion 4 entran
(ALERTING-POLICY.md "esto es un en accion:
ya construido) incidente" IC, Ops, Comms
│ │ │
└──────────┬──────────┴──────────┬──────────┘
▼ ▼
MITIGACION RESOLUCION
────────── ──────────
Se limita el daño, La condicion que
se restaura el disparo el incidente
servicio -- la causa ya no esta activa --
raiz aun no esta el incidente se cierra
completamente resuelta formalmente
│ │
└──────────┬──────────┘
▼
APRENDIZAJE (Modulo 7)
────────────────────
Fuera del alcance de este
modulo -- el postmortem sin
culpa, construido despuesLas cinco etapas no son opcionales, y saltarse una tiene un costo real: saltar la declaración deja a un equipo respondiendo informalmente, sin nadie que sepa con certeza si el incidente "ya es oficial"; confundir mitigación con resolución cierra un incidente antes de que el sistema realmente esté sano, dejando la condición real sin resolver hasta que vuelve a disparar la misma alerta.
Errores comunes
Confundir "detección" con "declaración" (de asumir que la alerta ya es el incidente). Qué pasa: alguien ve que ALERTING-POLICY.md disparó una alerta y asume que eso, por sí solo, ya es un incidente formalmente en curso. Cómo detectarlo: si nadie en tu escenario dijo, en voz alta o por escrito, "esto es un incidente" antes de empezar a trabajar en el problema. Cómo corregirlo: una alerta que dispara es la señal de que podría ser un incidente — las tres preguntas de la cita de esta lección (¿necesita un segundo equipo?, ¿es visible para clientes?, ¿sigue sin resolverse tras una hora?) son el criterio real para decidir si cruza a declaración formal. No toda alerta se convierte en un incidente declarado; toda alerta sí merece esas tres preguntas.
Tratar "mitigación" como sinónimo de "resolución" (de cerrar demasiado pronto). Qué pasa: alguien revierte un despliegue roto, el sistema vuelve a responder normalmente, y da el incidente por cerrado sin investigar la causa raíz. Cómo detectarlo: si tu incidente se cierra sin ningún plan de por qué pasó lo que pasó. Cómo corregirlo: la definición citada de esta lección es explícita —mitigar es "restaurar las operaciones normales lo más rápido posible", no encontrar la causa raíz—. Resolver significa que la condición que disparó el incidente dejó de estar activa de verdad, no solo que el síntoma inmediato desapareció; el Módulo 7 de esta guía es, precisamente, donde vive el trabajo de encontrar la causa raíz completa, después de que la resolución ya cerró el incidente activo.
Saltarse la etapa de "preparación" por completo, tratando el ciclo de vida como si empezara en la detección (de ignorar la primera mitad de la fuente citada). Qué pasa: alguien lee las cinco etapas de esta lección y concluye que la disciplina de incidentes empieza cuando algo se rompe. Cómo detectarlo: si tu plan de respuesta a incidentes no menciona nada que exista antes de que ocurra el primer incidente. Cómo corregirlo: la fuente citada de esta lección es explícita en que "preparar" —tener ya listos los mecanismos de alerta y los procesos de guardia— es una fase propia, anterior a la detección. Este módulo completo, de hecho, es esa fase de preparación para Andes Cargo: ALERTING-POLICY.md (Módulo 4) ya construyó los mecanismos de alerta; las lecciones 6-7 de este módulo construyen el proceso de guardia. El ciclo de vida de cinco etapas describe lo que pasa una vez que algo se rompe — pero solo funciona bien si la preparación ya existía.
Ejercicios
Ejercicio 1 — Usando las tres preguntas de la cita sobre detección, decide si el siguiente escenario cruza a "incidente": un ingeniero de Andes Cargo nota, por su cuenta, que un solo envío de prueba tardó tres segundos más de lo normal en procesarse, sin ningún error, y lo corrige revisando la conexión de su propia laptop en cinco minutos.
Ver solución
No cruza a "incidente". Las tres preguntas: ¿necesitó involucrar a un segundo equipo? No. ¿Fue visible para clientes? No —fue un envío de prueba, ni siquiera un evento válido según la definición de SLI de SLO.md—. ¿Siguió sin resolverse tras una hora de análisis concentrado? No, se resolvió en cinco minutos, y la causa fue local a la laptop del propio ingeniero, no al sistema. Ninguna de las tres condiciones se cumple, así que este escenario nunca necesita pasar por declaración, respuesta, mitigación o resolución formales — es exactamente el tipo de ruido de bajo nivel que un ciclo de vida de incidentes bien definido existe para no escalar innecesariamente.
Ejercicio 2 — Explica por qué la fuente de esta lección coloca "declaración" como un paso separado de "detección", en vez de fusionarlos en uno solo. ¿Qué se pierde si un equipo trata ambos como el mismo momento?
Ver solución
Fusionar detección y declaración asumiría que toda señal técnica de que algo está mal merece automáticamente el peso completo de un incidente formal —roles asignados, comunicación activa, un documento de seguimiento—, sin ningún filtro de criterio humano en medio. Separarlos permite que la detección ocurra con mucha más frecuencia y sensibilidad (cualquier alerta, cualquier anomalía) que la declaración, que exige cruzar un criterio más alto (las tres preguntas de esta lección). Sin esa separación, un equipo real terminaría declarando incidentes formales por cada pico menor, agotando exactamente el mismo tipo de "fatiga de alerta" que el Módulo 4, lección 1 de esta guía ya identificó como el problema central de un umbral mal diseñado — solo que aplicado ahora a personas, no a un sistema de alerta.
Ejercicio 3 — Un compañero argumenta que la etapa de "resolución" es innecesaria, porque una vez que la mitigación restaura el servicio, "ya terminó el trabajo real". ¿Cómo responderías, usando la definición citada de esta lección?
Ver solución
La definición citada de "resolución" —cerrar el incidente solo "once mitigated" (una vez mitigado), no antes— asume, implícitamente, que mitigación y resolución son eventos distintos que pueden ocurrir en momentos distintos: el servicio puede volver a responder (mitigado) mientras la condición subyacente que lo rompió sigue presente, solo oculta detrás de la mitigación temporal (por ejemplo, un despliegue revertido, pero el bug que causó la falla original sigue en el código, esperando el próximo despliegue). Tratar la mitigación como el final del trabajo real deja esa condición subyacente sin ningún cierre formal, con el riesgo real de que el mismo incidente se repita en cuanto la mitigación temporal deje de estar en su lugar. La etapa de resolución existe, precisamente, para forzar la pregunta "¿la causa real ya no está activa, o solo escondimos el síntoma?" antes de dar el incidente por cerrado.
Resumen y siguiente paso
Esta lección definió las cinco etapas del ciclo de vida de un incidente —detección, declaración, respuesta, mitigación, resolución—, cada una citada directamente de la guía de gestión de incidentes de Google SRE y del SRE Book, con la distinción precisa entre las que suelen confundirse: detección no es declaración, mitigación no es resolución. El diagrama de esta lección conecta las cinco etapas en secuencia, con el aprendizaje sistémico (Módulo 7) como la etapa que viene después, fuera del alcance de este módulo.
Antes de avanzar deberías poder: nombrar las cinco etapas en orden, sin mirar el diagrama; aplicar las tres preguntas de detección a un escenario nuevo; y explicar, con la fuente citada, por qué mitigación y resolución no son lo mismo.
La lección 3 toma la segunda pregunta central de este módulo: cuando un incidente sí se declara, ¿qué tan grave es? Los niveles de severidad —SEV1 a SEV4— con ejemplos concretos de Andes Cargo.
Recursos
- Google SRE — Incident Management Guide — las tres fases (preparar, responder, aprender) y la fuente principal de esta lección.
- Google SRE Book — Managing Incidents — el criterio de las tres preguntas para detección, y las definiciones de mitigación y resolución citadas.
- Este mismo repositorio, Módulo 4, lección 8 (
08-project-andes-cargos-alerting-policy.md) —ALERTING-POLICY.md, el mecanismo de detección que esta lección da por construido. - Este mismo repositorio, Módulo 6 — el módulo que recorre estas cinco etapas, en orden, con el incidente Claude Code real.