Módulo 5: The Incident Lifecycle
3. Niveles de severidad, con ejemplos reales de Andes Cargo
Descripción
Un incidente declarado (lección 2) todavía no dice qué tan grave es. "Declarado" es binario —sí o no—; la gravedad no lo es. Esta lección instala el vocabulario que resuelve esa segunda pregunta: cuatro niveles de severidad, SEV1 a SEV4, un patrón usado en toda la industria —esta lección cita la documentación pública de PagerDuty como referencia concreta— y cada uno ilustrado con un ejemplo narrativo de Andes Cargo, del más leve (un envío que tarda dos segundos más) al más grave (Shipments que deja de responder por completo). La lección 5 de este módulo toma estos mismos cuatro niveles y los ata, número por número, a los umbrales de burn rate que ALERTING-POLICY.md ya construyó — aquí todavía es concepto, no aritmética.
Conexión con el módulo
Sin un vocabulario compartido de severidad, dos personas mirando el mismo problema pueden discrepar sobre si merece despertar a alguien a las 3 AM o esperar hasta el lunes — y esa discrepancia, bajo presión real, cuesta minutos que un sistema en degradación no siempre tiene. Esta lección construye ese vocabulario compartido; la lección 4 construye quién lo aplica.
La analogía: el triaje de una sala de urgencias
En una sala de urgencias real, no todo paciente que entra recibe la misma atención inmediata, y esa diferencia no es arbitraria — un enfermero de triaje evalúa a cada persona que llega y le asigna una prioridad, antes de que un médico la vea. Un paro cardíaco entra directo a atención inmediata, sin esperar turno. Un esguince de tobillo espera, razonablemente, mientras el paro cardíaco se atiende primero. Ninguno de los dos casos es "falso" ni "innecesario" — son, sencillamente, urgencias de una magnitud completamente distinta, y tratarlas con la misma urgencia sería un desperdicio de la atención que el paro cardíaco sí necesita con desesperación.
La severidad de un incidente funciona exactamente así. No todo lo que sale mal en process-shipment-manifest es un paro cardíaco. Confundir un tobillo torcido con un paro cardíaco —tratando cada anomalía menor como una emergencia de 3 AM— agota al equipo de guardia tan rápido como confundir un paro cardíaco con un tobillo torcido pone en riesgo real al sistema. Cuatro niveles, del más leve al más grave, existen para que esa distinción se haga con un criterio compartido, no con el juicio individual de quien esté de guardia esa semana.
Los cuatro niveles, citados de la práctica real de la industria
Google SRE, la fuente que esta guía cita para el ciclo de vida y los roles, no define niveles numerados de severidad — es una omisión real, no un descuido de esta guía (verificado directamente contra la fuente). El patrón SEV1-SEV4, en cambio, es una convención ampliamente adoptada en la industria, documentada públicamente por PagerDuty en su guía de respuesta a incidentes:
SEV-1: "Critical issue that warrants public notification and liaison with executive teams." SEV-3: "Stability or minor customer-impacting issues that require immediate attention from service owners." SEV-4: "Minor issues requiring action, but not affecting customer ability to use the product."
Y un principio explícito, sobre qué hacer frente a la duda:
"If you are unsure which level an incident is [...] treat it as the higher one."
Esta guía adapta ese patrón —cuatro niveles, no cinco, y sin el requisito de notificación pública de PagerDuty, que asume una empresa con clientes externos pagando— a Andes Cargo, un sistema interno sin SLA (RELIABILITY-CHARTER.md, Módulo 1, ya lo estableció). El principio "ante la duda, la severidad más alta" sí se conserva sin cambios: corregir una severidad hacia abajo, con más información, cuesta mucho menos que corregirla hacia arriba después de minutos de silencio.
SEV4 — Bajo/cosmético: ruido, no incidente
El nivel más bajo no siempre merece siquiera un ticket. Ejemplo de Andes Cargo: el manifiesto del envío 4471 (Perú → Chile) tarda dos segundos más de lo normal en procesarse, por una demora breve al leer el archivo desde andes-cargo-shipment-docs. El procesamiento completo termina en cuatro segundos — muy por debajo del Timeout de diez segundos configurado en process-shipment-manifest, sin ninguna excepción, sin ningún reintento. Nadie recibe una notificación. Si el patrón nunca se repite, no queda ningún registro más allá de un log rutinario.
SEV3 — Menor: hay un problema, pero el sistema ya se está encargando
Un pico de tráfico breve satura momentáneamente ReservedConcurrentExecutions: 5 — el límite de concurrencia que aws-serverless-and-containers-guide ya configuró para process-shipment-manifest—, y algunas invocaciones se retrasan mientras esperan turno. Todas terminan procesándose correctamente después del reintento automático, en cuestión de segundos. Nadie recibe una llamada a las 3 AM; alguien revisa un ticket generado automáticamente el siguiente día hábil, para confirmar que el patrón no se está volviendo más frecuente.
SEV2 — Mayor: un problema real, con impacto visible, pero sin pérdida irreversible
Un despliegue con un error de validación hace que una porción real de los manifiestos de envío agoten sus dos reintentos automáticos y se descarten silenciosamente — el mismo patrón que el dataset BAD_WEEK del Módulo 2 ya modeló con números reales. Los clientes de Andes Cargo empiezan a notar que el estado de sus envíos no se actualiza. No es una caída total —la mayoría de los envíos sigue procesándose sin problema—, pero es lo suficientemente grave como para que alguien de guardia lo atienda dentro del mismo turno, no al día siguiente.
SEV1 — Crítico: el sistema no responde, o los datos están en riesgo real
Shipments, la tabla de DynamoDB que sostiene todo el sistema de rastreo de Andes Cargo, deja de responder por completo. Ninguna invocación de process-shipment-manifest logra escribir un registro — cero envíos se procesan, para nadie, hasta que alguien intervenga. Este nivel no está reservado solo para "el sistema está caído": también cubre pérdida de datos irreversible sin intervención de soporte externo, incluso si el sistema técnicamente sigue respondiendo a otras solicitudes — la distinción exacta, no casual, que el Módulo 6 de esta guía va a aplicar al clasificar el incidente Claude Code real.
Los cuatro niveles, de un vistazo
SEV4 SEV3 SEV2 SEV1
──── ──── ──── ────
2s de mas, Throttling Retries agotados, Shipments no
dentro del absorbido por impacto real de responde --
timeout, cuenta el retry clientes visible cero envios
como evento BUENO automatico se procesan
Sin ticket, Ticket, revisado Pagina a guardia, Pagina inmediata,
sin pagina siguiente dia responde en el Incident Commander
habil mismo turno asignadoErrores comunes
Asignar SEV1 a cualquier cosa que se sienta urgente en el momento (de confundir "me preocupa" con "es crítico"). Qué pasa: alguien, ansioso frente a cualquier anomalía, declara SEV1 sin comparar contra los ejemplos concretos de esta lección. Cómo detectarlo: si tu criterio para SEV1 es "se siente grave", en vez de "el sistema no responde en absoluto, o hay pérdida de datos irreversible". Cómo corregirlo: la lección 5 de este módulo va a atar cada nivel a un número exacto de burn rate, precisamente para sacar el "se siente grave" de la ecuación — hasta entonces, compara contra los cuatro ejemplos narrativos de esta lección: ¿el sistema dejó de responder, o solo se sintió incómodo verlo fallar un poco?
Minimizar un SEV1 real porque "seguramente se resuelve solo" (el error simétrico opuesto). Qué pasa: alguien ve que Shipments no responde, pero decide esperar unos minutos "a ver si se arregla", sin declarar el incidente ni avisar a nadie. Cómo detectarlo: si tu respuesta a un sistema completamente caído es "vamos a monitorear un rato más" en vez de declarar de inmediato. Cómo corregirlo: la cita de esta lección es explícita — ante la duda, la severidad más alta, nunca la más baja. Un SEV1 que resulta ser más leve de lo que parecía se corrige hacia abajo en minutos, sin costo real; un SEV1 real tratado como ruido por diez minutos de "esperemos a ver" puede significar diez minutos completos de presupuesto de error consumido sin que nadie responda.
Tratar los cuatro niveles como una escala continua de "qué tan molesto es", en vez de un criterio de umbral discreto (de perder la precisión del patrón). Qué pasa: alguien clasifica un incidente como "entre SEV2 y SEV3", sin decidirse por uno de los dos. Cómo detectarlo: si tu clasificación de severidad usa palabras como "más o menos" o "casi". Cómo corregirlo: la lección 5 de este módulo existe exactamente para eliminar esa ambigüedad — cada nivel se ata a un umbral numérico exacto de burn rate, sin zona intermedia. Un incidente cruza un umbral o no lo cruza; no hay "SEV2.5".
Ejercicios
Ejercicio 1 — Clasifica el siguiente escenario usando los cuatro niveles de esta lección: durante una hora, el 0,3% de las invocaciones de process-shipment-manifest fallan con un error transitorio, se reintentan automáticamente, y todas terminan procesándose correctamente. Ningún cliente reporta ningún problema.
Ver solución
SEV3. El escenario tiene un problema real y medible (0,3% de fallas transitorias) — no es tan trivial como el ejemplo de SEV4 (dos segundos de más, sin ningún error real registrado)—, pero el sistema se está encargando solo, sin impacto visible para ningún cliente, exactamente como el ejemplo de SEV3 de esta lección (el throttling absorbido por el reintento automático). No hay ninguna señal de que amerite una página inmediata a guardia — sí amerita un ticket, para confirmar que el patrón no empeora.
Ejercicio 2 — Un colega propone eliminar SEV3 y SEV4, argumentando que "si no es lo suficientemente grave para pagar a alguien, no vale la pena ni siquiera registrarlo". Usando la cita de PagerDuty de esta lección, explica por qué eso sería un error.
Ver solución
La propia definición citada de SEV-4 en esta lección es explícita: son "minor issues requiring action" (problemas menores que requieren acción) — la palabra clave es "acción", no "ninguna acción". Eliminar SEV3 y SEV4 no elimina esos problemas; solo elimina el registro de que ocurrieron, lo que hace invisible cualquier patrón que se esté formando lentamente (por ejemplo, un throttling de SEV3 que ocurre cada vez con más frecuencia, sin que nadie lo note porque nunca quedó registrado). El punto de tener cuatro niveles, no solo dos, es precisamente capturar la señal de bajo impacto sin gastar el mismo esfuerzo de respuesta que un SEV1 — nunca ignorarla por completo.
Ejercicio 3 — Explica, usando el ejemplo de SEV1 de esta lección, por qué "el sistema no responde" y "hay pérdida de datos irreversible" están en el mismo nivel, en vez de en dos niveles distintos.
Ver solución
Ambos casos comparten la misma característica que define a SEV1: una vez que ocurren, esperar no mejora la situación — cada minuto que pasa sin una respuesta activa empeora el resultado (más envíos sin procesar, o datos cada vez más difíciles de recuperar), y ninguno de los dos se resuelve por sí solo con el tiempo. Un Shipments que no responde en absoluto es, en la práctica, indistinguible en urgencia de una pérdida real de datos: en ambos casos, la respuesta correcta es la misma (página inmediata, Incident Commander asignado, todas las manos disponibles), aunque la causa técnica exacta sea distinta. Separarlos en dos niveles distintos no cambiaría en nada la respuesta que cada uno necesita — y un nivel de severidad que no cambia la respuesta asociada no está agregando ninguna información útil.
Resumen y siguiente paso
Esta lección instaló los cuatro niveles de severidad —SEV1 (crítico) a SEV4 (bajo/cosmético)—, citados de la práctica real de la industria (PagerDuty), con un ejemplo narrativo de Andes Cargo por nivel: de un envío que tarda dos segundos más (SEV4, ni siquiera cuenta como evento malo) a Shipments completamente caído (SEV1, página inmediata). El principio central, citado directamente: ante la duda, la severidad más alta, nunca la más baja.
Antes de avanzar deberías poder: describir, en una frase, la diferencia entre cada uno de los cuatro niveles; explicar por qué SEV1 cubre tanto "caída total" como "pérdida de datos irreversible"; y defender por qué SEV3 y SEV4 siguen mereciendo un registro, aunque nunca ameriten una página.
La lección 4 responde la siguiente pregunta: una vez que un incidente tiene una severidad asignada, ¿quién responde, y con qué rol específico? Incident commander, comunicación, operaciones — citado, con la misma disciplina, de Google SRE.
Recursos
- PagerDuty — Incident Response: Severity Levels — la fuente citada de los niveles SEV1-SEV4 y el principio de "ante la duda, la severidad más alta".
- Este mismo repositorio, Módulo 4, lección 8 (
08-project-andes-cargos-alerting-policy.md) —ALERTING-POLICY.md, cuyos umbrales de burn rate la lección 5 de este módulo ata a estos mismos cuatro niveles. - Este mismo repositorio, Módulo 1, lección 8 (
08-project-andes-cargos-reliability-charter.md) —RELIABILITY-CHARTER.md, la decisión de que Andes Cargo no tiene SLA externo, la razón por la que esta lección no adopta el requisito de notificación pública de PagerDuty.