Módulo 5: The Incident Lifecycle

5. Manos a la obra: la matriz de severidad de Andes Cargo

Descripción

La lección 3 dio los cuatro niveles de severidad, con ejemplos narrativos. Esta lección los convierte en algo que ya no depende de "se siente grave" — una matriz donde cada SEV se ata, con aritmética real y verificable, a un umbral exacto de burn rate que ALERTING-POLICY.md (Módulo 4) ya construyó y probó. Es la primera pieza real de INCIDENT-RESPONSE-PLAN.md: no una tabla de opiniones, una tabla donde cada fila se deriva, con una sola fórmula, de los mismos tres umbrales de la Tabla 5-8 de Google SRE que este proyecto entero ya usa desde el Módulo 4.

Conexión con el módulo

Esta lección no introduce ningún dato nuevo de burn rate — reutiliza, sin cambiarlos, los tres umbrales que scripts/burn_rate_evaluator.py (Módulo 4, lección 3) ya implementó: Page (fast) a 14,4x, Page (slow) a 6x, Ticket a 1x. Lo único genuinamente nuevo aquí es la fórmula que conecta un burn rate con una tasa de error observable, y la tabla resultante — la pieza exacta que la lección 8 (proyecto de este módulo) va a copiar, sin cambios, a la sección "Severity matrix" de INCIDENT-RESPONSE-PLAN.md.

Paso 1 — La fórmula que falta: de umbral de burn rate a tasa de error real

ALERTING-POLICY.md ya define el SLO de Andes Cargo: 99,9% mensual, lo que significa una tasa de error permitida de 0,1% (1 − 0,999). Burn rate, tal como el Módulo 4, lección 2 ya lo citó de Google SRE, es la tasa de error observada, dividida entre la tasa de error permitida:

burn_rate = tasa_de_error_observada / tasa_de_error_permitida
tasa_de_error_permitida = 0.001  (0,1%, fijo, de SLO.md)

Despejando la tasa de error observada que corresponde a cada umbral ya conocido:

tasa_de_error_observada = burn_rate x tasa_de_error_permitida

Umbral de `ALERTING-POLICY.md`	Cálculo	Tasa de error observada
`Ticket` — 1,0x	1,0 × 0,001	0,10%
`Page (slow)` — 6,0x	6,0 × 0,001	0,60%
`Page (fast)` — 14,4x	14,4 × 0,001	1,44%

Esta tabla es la pieza que faltaba: no hace falta inventar ningún límite nuevo de "cuándo es SEV2 y cuándo es SEV1" — los tres umbrales de burn rate ya construidos y probados en el Módulo 4 son, literalmente, los tres límites que separan SEV4 de SEV3, SEV3 de SEV2, y SEV2 de SEV1.

Paso 2 — El caso extremo, verificado con la misma cita del Módulo 4

El ejemplo de SEV1 más concreto de la lección 3 —Shipments no responde en absoluto— tiene una tasa de error observada de 100% (cada invocación válida falla, ninguna se completa). Aplicando la misma fórmula:

burn_rate = 1.0 / 0.001 = 1000

Un burn rate de 1.000x. El Módulo 4, lección 2 ya citó, textualmente, qué significa ese número exacto:

"A 1,000x burn rate (100% errors) depletes budget in 43 minutes."

— Google SRE Workbook — Alerting on SLOs

Verificando con la fórmula ya usada en esa misma lección (tiempo hasta agotar el presupuesto = ventana del SLO ÷ burn rate):

tiempo_hasta_agotar = 43200 minutos / 1000 = 43.2 minutos

Cuarenta y tres coma dos minutos — el mismo número, exactamente, que el presupuesto mensual completo de error de Andes Cargo (43,2 minutos, de SLO.md). No es una coincidencia de diseño de esta lección: a burn rate 1.000x, por definición, el presupuesto completo de 30 días se consume 1.000 veces más rápido, así que el tiempo que tardaría en agotarse es la ventana completa (43.200 minutos) dividida entre 1.000 — que da, aritméticamente, el mismo número que el propio presupuesto total en minutos. Es la confirmación numérica más directa posible de por qué Shipments sin responder es, sin ambigüedad, SEV1: a ese ritmo, el margen completo de todo un mes desaparece antes de que termine una reunión de una hora.

Paso 3 — La matriz completa, con la aritmética a la vista

Severidad	Umbral de burn rate (`ALERTING-POLICY.md`)	Tasa de error observada	% del presupuesto si se sostiene	Ejemplo de Andes Cargo (Módulo 5, lección 3)
SEV1 — Crítico	`Page (fast)`, ≥ 14,4x — O pérdida de datos irreversible, sin importar el burn rate medido	≥ 1,44% (hasta 100%)	2% en 1 hora (100% en 43,2 min a 1.000x)	`Shipments` no responde en absoluto
SEV2 — Mayor	`Page (slow)`, ≥ 6,0x y < 14,4x	0,60%–1,44%	5% en 6 horas	Retries agotados en una porción real de manifiestos, descartados silenciosamente
SEV3 — Menor	`Ticket`, ≥ 1,0x y < 6,0x	0,10%–0,60%	10% en 3 días	Throttling breve, absorbido por el reintento automático
SEV4 — Bajo/cosmético	Por debajo de `Ticket`, < 1,0x — o ni siquiera cuenta como evento malo	< 0,10%	Insignificante	Dos segundos extra dentro del `Timeout`, cuenta como evento bueno

Cuatro filas, tres números que ya existían desde el Módulo 4 (14,4x, 6x, 1x), y una sola fórmula nueva (tasa_de_error = burn_rate × 0,001) que las conecta con algo medible. Esta es, literalmente, la tabla que la lección 8 va a copiar como la sección "Severity matrix" de INCIDENT-RESPONSE-PLAN.md.

Errores comunes

Olvidar la excepción explícita de SEV1 (pérdida de datos irreversible, sin importar el burn rate medido) y tratar la matriz como si funcionara solo por aritmética de burn rate. Qué pasa: alguien asume que la única forma de clasificar SEV1 es calculando un burn rate de 14,4x o más, y no sabría qué hacer frente a un escenario donde los datos se perdieron pero el sistema, técnicamente, sigue respondiendo con normalidad a otras solicitudes. Cómo detectarlo: si tu clasificación de severidad depende, sin excepción, de tener un número de burn rate calculable en el momento. Cómo corregirlo: RELIABILITY-CHARTER.md (Módulo 1, Decision, punto 4) ya estableció que el error budget es "un mecanismo de medición, nunca un control preventivo" — y esa misma honestidad aplica aquí: el burn rate asume que el sistema sigue recibiendo tráfico medible. Un escenario como el incidente Claude Code, donde la infraestructura completa fue destruida, puede no generar ningún burn rate medible en absoluto (no hay invocaciones que fallen si no hay infraestructura para invocar) — por eso esta matriz incluye la pérdida de datos irreversible como un criterio SEV1 independiente, que no espera a que ningún número cruce ningún umbral.

Calcular el burn rate con la tasa de error permitida equivocada (usar 0,001 cuando el escenario no es sobre el SLO principal de Andes Cargo). Qué pasa: alguien reutiliza la fórmula de esta lección para un sistema distinto, o para un SLO distinto, sin ajustar la tasa de error permitida (0,001 es específico del 99,9% mensual de SLO.md). Cómo detectarlo: si tu cálculo de burn rate da un número que no coincide con ninguno de los tres umbrales conocidos para un escenario que debería, por diseño, cruzar uno de ellos exactamente. Cómo corregirlo: la fórmula burn_rate = tasa_observada / tasa_permitida es genérica, pero el 0,001 de esta lección es específico del SLO de 99,9% que SLO.md ya fijó — un sistema con un SLO distinto (por ejemplo, 99% en vez de 99,9%) tendría una tasa permitida distinta (0,01), y los mismos umbrales de burn rate (14,4x, 6x, 1x) corresponderían a tasas de error observadas completamente distintas.

Asumir que la columna "% del presupuesto si se sostiene" es lo mismo que "presupuesto ya consumido" (de confundir una velocidad con un acumulado, el mismo error que el Módulo 4, lección 1 ya nombró). Qué pasa: alguien lee "2% en 1 hora" en la fila de SEV1 y concluye que ese incidente, apenas empieza, ya consumió el 2% del presupuesto mensual. Cómo detectarlo: si tu lectura de la tabla no distingue entre "a este ritmo, en una hora sostenida se consumiría esto" y "esto ya se consumió". Cómo corregirlo: la columna describe qué pasaría si el ritmo se sostiene durante la ventana indicada — no lo que ya ocurrió. Un incidente de SEV1 que se mitiga en cinco minutos consume mucho menos del 2% real; la columna es una proyección de urgencia, no un acumulado ya gastado, exactamente la misma distinción entre velocidad y saldo que el Módulo 4 completo existe para enseñar.

Ejercicios

Ejercicio 1 — Calcula, a mano, el burn rate y la severidad correspondiente para un escenario donde la tasa de error observada de process-shipment-manifest es 0,72% sostenida. Usa la fórmula de esta lección.

Ver solución

burn_rate = 0.0072 / 0.001 = 7.2. Un burn rate de 7,2x cae en el rango de Page (slow) (≥ 6,0x y < 14,4x) — SEV2. Verificación con la tabla: 7,2x está por encima del umbral de Ticket (1,0x) y de Page (slow) (6,0x), pero por debajo de Page (fast) (14,4x), así que la severidad correcta es la fila de SEV2, no SEV1 ni SEV3.

Ejercicio 2 — Explica, usando el Paso 2 de esta lección, por qué un burn rate de 1.000x no está simplemente "muy por encima" del umbral de SEV1 (14,4x), sino que representa una categoría de urgencia cualitativamente distinta.

Ver solución

A 14,4x, el presupuesto completo se agotaría en 43.200 / 14,4 ≈ 3.000 minutos (50 horas) si el ritmo se sostuviera exactamente en ese umbral — todavía dentro del orden de "días", tiempo real para reaccionar antes de que el mes completo de margen desaparezca. A 1.000x, el mismo presupuesto se agota en 43,2 minutos — menos de una hora. La diferencia no es solo de magnitud (1.000 es mucho más que 14,4): es la diferencia entre un incidente que da tiempo real de reacción medido en horas, y uno que agota el margen completo de un mes entero antes de que termine una sola llamada de coordinación. Ambos cruzan el umbral de SEV1, pero el segundo caso justifica, con la propia aritmética, por qué la respuesta debe ser inmediata, no solo "urgente".

Ejercicio 3 — Un compañero propone simplificar la matriz eliminando la columna "% del presupuesto si se sostiene", argumentando que la columna de burn rate ya contiene toda la información necesaria. ¿Qué se pierde al eliminarla?

Ver solución

El número de burn rate (14,4x, por ejemplo) es correcto pero abstracto — no comunica, por sí solo, qué tan rápido se agota algo concreto y medible en minutos u horas reales. La columna de porcentaje traduce ese multiplicador abstracto a una pregunta que cualquier persona, técnica o no, puede entender de inmediato: "si esto sigue así una hora completa, ¿cuánto del mes ya se gastó?". Es la misma razón por la que el Módulo 2 tradujo el error budget de un porcentaje abstracto a minutos concretos (43,2 minutos, no solo "0,1%") — un número sin unidades intuitivas es correcto, pero mucho menos útil para decidir con rapidez qué tan urgente es actuar.

Resumen y siguiente paso

Esta lección construyó la matriz de severidad completa de Andes Cargo: cuatro filas, cada una atada, con una sola fórmula (burn_rate = tasa_observada / 0,001), a los mismos tres umbrales que ALERTING-POLICY.md ya probó en el Módulo 4 — sin inventar ningún límite nuevo. Verificaste el caso extremo (Shipments sin responder, 100% de tasa de error, burn rate 1.000x) con la misma cita de Google SRE del Módulo 4, confirmando que el presupuesto mensual completo, 43,2 minutos, se agotaría en exactamente esos mismos 43,2 minutos si el ritmo se sostuviera.

Antes de avanzar deberías poder: calcular, dada cualquier tasa de error observada, el burn rate correspondiente y la severidad que le toca; explicar por qué SEV1 tiene un criterio independiente del burn rate (pérdida de datos irreversible); y distinguir "porcentaje si se sostiene" de "porcentaje ya consumido".

La lección 6 cambia de tema, hacia la pieza humana que responde a estas severidades: on-call, con una honestidad completa sobre su costo real — la cita completa de Hacker News sobre por qué tratar el on-call como una capa portable, no como una promesa de disponibilidad total.

Recursos

Este mismo repositorio, Módulo 4, lección 2 (02-multiwindow-multiburn-rate-the-real-google-sre-pattern.md) — la Tabla 5-8 completa, la fuente de los tres umbrales de esta lección.
Este mismo repositorio, Módulo 4, lección 8 (08-project-andes-cargos-alerting-policy.md) — ALERTING-POLICY.md, citado en el encabezado de la tabla de esta lección.
Este mismo repositorio, Módulo 2, lección 8 (08-project-andes-cargos-slo-md.md) — SLO.md, la fuente de la tasa de error permitida (0,1%) y el presupuesto de 43,2 minutos.
Google SRE Workbook — Alerting on SLOs — la cita del caso de 1.000x/43 minutos, verificada de nuevo en el Paso 2 de esta lección.

← Anterior4. Roles durante un incidente Siguiente →6. On-call, con honestidad sobre su costo