Módulo 8: Capstone The Andes Cargo Reliability Package

1. Introducción al capstone

Descripción

Siete módulos construyeron, uno a la vez, cada pieza de una máquina completa de confiabilidad: una definición real de SLI (Módulo 2), medida con datos reales del Lambda heredado (Módulo 3), vigilada por una alerta que dispara por la razón correcta —consumo acelerado del error budget, no un umbral suelto— en tres motores distintos (Módulo 4), operada con un marco de ciclo de vida, severidad, roles y guardia (Módulo 5), aplicada de punta a punta contra el incidente Claude Code real (Módulo 6), y cerrada con un postmortem sin culpa y el primer runbook operativo de Andes Cargo (Módulo 7). Cada módulo, hasta ahora, probó su propia pieza por separado.

Este módulo no agrega una pieza nueva. Corre la máquina completa, una vez más, contra un caso que ninguna lección anterior construyó a propósito para que funcionara bien. Un incidente sintético nuevo —determinista, nunca aleatorio, tan verificable como cualquier dataset de esta guía— entra por el mismo punto que cualquier tráfico real entraría: una secuencia de manifiestos subida al bucket real. Desde ahí, sin ningún cambio de código ni de configuración en ninguna de las siete piezas ya construidas, la máquina completa tiene que hacer, por sí sola, todo lo que prometió: medir, alertar, declarar, mitigar, y cerrar con un documento sin culpa. Si el capstone de esta guía tiene una sola pregunta, es esa: ¿la máquina que construiste funciona en un caso que no viste venir?

Conexión con el módulo

Cada pieza que este módulo usa ya existe, construida y verificada en los siete módulos anteriores: SLO.md (Módulo 2), scripts/error_budget_calculator.py y scripts/burn_rate_evaluator.py (Módulos 2 y 4), observability/ completo —Prometheus, Grafana, Alertmanager, Jaeger, el exportador de burn rate— (Módulos 3 y 4), observability.tf con la alarma real de CloudWatch (Módulo 4), INCIDENT-RESPONSE-PLAN.md con el ciclo de vida, la matriz de severidad, los roles y la rotación de guardia (Módulo 5), el precedente completo de operar un incidente real de principio a fin (Módulo 6), y el primer runbook operativo de Andes Cargo junto con la plantilla de postmortem sin culpa (Módulo 7). Este módulo no declara ningún recurso HCL de negocio nuevo, no introduce ninguna herramienta que las siete guías anteriores no hayan usado ya — su único trabajo genuinamente nuevo es un segundo escenario de datos, tan fijo y determinista como cualquier otro de esta guía, y el documento final de portafolio que reúne todo.

La analogía: el simulacro de emergencia de punta a punta

Cada módulo anterior de esta guía entrenó una pieza aislada del mismo protocolo: cómo medir si algo anda mal (Módulo 2), cómo conseguir el dato real que esa medición necesita (Módulo 3), cómo hacer sonar la alarma correcta en el momento correcto (Módulo 4), quién responde y con qué reglas (Módulo 5). Practicar cada pieza por separado es necesario, pero no es lo mismo que un simulacro real de punta a punta: la alarma suena de verdad, sin que nadie sepa de antemano exactamente cuándo ni con qué textura exacta va a sonar; el equipo completo —no un solo rol practicando en aislamiento— tiene que coordinarse bajo la misma presión de tiempo relativo que un incidente real impondría; el fuego se apaga con las mismas herramientas que ya existían, no con una improvisada para la ocasión; y al final, alguien tiene que escribir el reporte, con la misma disciplina sin culpa de siempre, para que el protocolo mismo mejore la próxima vez.

Este módulo es ese simulacro completo. La diferencia con un simulacro genérico —la misma que el Módulo 6 ya estableció al operar el incidente Claude Code contra hechos reales, no inventados— es que aquí ni siquiera hace falta inventar el escenario final de prueba: el Módulo 8.3 construye una secuencia fija y determinista de invocaciones malformadas, nueva, nunca ejecutada antes en esta guía, y todo lo demás —la alerta, la declaración, el runbook, el postmortem— tiene que reaccionar sin que ninguna lección anterior le haya dado un empujón de ventaja.

   SIETE MODULOS, UNA PIEZA CADA UNO          ESTE MODULO -- LA MAQUINA COMPLETA
   ──────────────────────────────────          ─────────────────────────────────
   M2: como medir (SLI/SLO/budget)              Un incidente sintetico NUEVO entra
   M3: de donde sale el dato real                por el mismo punto que trafico real
   M4: como suena la alarma correcta                          |
   M5: quien responde, con que reglas                         v
   M6: el protocolo corrido una vez,             M2-M4 lo miden y lo alertan SIN
       contra un caso ya conocido                cambios -- nunca antes vieron
   M7: como se cierra sin culpa                  estos numeros especificos
        │                                                     |
        ▼                                                     v
   Cada pieza probada por separado               M5-M7 lo operan y lo cierran
                                                  con el MISMO marco, sin ajustes
                                                  hechos a la medida de este caso

Qué vas a entregar en este módulo

Ocho lecciones, cada una un paso del mismo recorrido de cierre:

#	Lección	Qué produce
1	Esta introducción	El mapa completo del capstone, y por qué "correr la máquina completa" es distinto de "repasar cada pieza"
2	Repaso de arquitectura	El diagrama completo de la máquina de confiabilidad, superpuesto sobre `andes-cargo-infra/` como existe hoy, con las siete piezas heredadas nombradas por su ruta exacta
3	Introduciendo un incidente sintético determinista	`observability/upload_synthetic_incident_batch.py` — una secuencia fija de 25 manifiestos, 10 malformados por la misma razón, nunca vista antes en esta guía
4	La alerta dispara, el incidente se declara	Los tres motores del Módulo 4, sin ningún cambio de código, disparando sobre el incidente nuevo; la declaración formal con roles de una semana distinta de la rotación
5	El runbook mitiga, el postmortem cierra	El runbook del Módulo 7 ejecutado paso a paso contra este caso; un segundo `POSTMORTEM.md`, más corto, que prueba que el proceso —no solo el ejemplo original— funciona
6	Lo que esta guía dejó representativo	Un solo lugar, con la razón técnica exacta de cada pieza no ejecutada: X-Ray, Application Signals, Incident Manager, PagerDuty/Opsgenie, y el resultado real del intento de backup del Módulo 7
7	Lo que Andes Cargo todavía necesita	El mapa hacia el resto del ecosistema: EKS y su propia disciplina SRE, SRE de sistemas de IA, observabilidad a fondo como disciplina independiente
8	Proyecto final: el paquete de confiabilidad completo	`RELIABILITY-PACKAGE.md` — el índice de todo lo que esta guía construyó, como pieza de portafolio

Una honestidad que hay que dejar clara desde esta primera lección

El incidente sintético de este módulo (lecciones 3 a 5) es distinto, en un punto importante, del incidente Claude Code que el Módulo 6 operó: no le pasó a nadie, real ni ficticio, fuera de esta guía. No tiene una fuente primaria externa que verificar, porque no hace falta una — su único trabajo es ser determinista y nuevo: una secuencia fija, escrita en un script, que ninguna de las siete piezas anteriores de esta guía vio nunca durante su propia construcción. Esa es, de hecho, la prueba que este módulo necesita: si la alerta del Módulo 4, el marco del Módulo 5, y el runbook del Módulo 7 solo funcionaran sobre los datos exactos con los que se construyeron y probaron —BAD_WEEK, el batch de 20 manifiestos del Módulo 3, el incidente Claude Code—, no demostrarían nada sobre si la máquina generaliza. Un caso genuinamente nuevo, aunque inventado a propósito para este módulo, es la única forma honesta de probar esa generalización.

La misma regla dura de siempre sigue aplicando sin ninguna excepción: nunca random, nunca datetime.now(). El incidente sintético de la lección 3 es tan fijo, tan committeado, tan reproducible dígito por dígito como TRAFFIC_30_DAYS o BAD_WEEK del Módulo 2 — la única diferencia es que nadie, en ningún módulo anterior, ajustó ninguna pieza de la máquina para que este caso específico funcionara bien.

Errores comunes

Esperar que este módulo introduzca una herramienta nueva, un motor de alerta distinto, o un marco de incidentes alternativo (de anticipar contenido que este módulo no tiene). Qué pasa: alguien llega a este capstone esperando algo genuinamente distinto de lo que los siete módulos anteriores ya construyeron —quizás una integración nueva, un dashboard adicional, un servicio gestionado que no se había nombrado todavía—. Cómo detectarlo: si tu expectativa de este módulo es "¿qué pieza nueva de infraestructura voy a aprender aquí?". Cómo corregirlo: este módulo, deliberadamente, no agrega ninguna pieza nueva de infraestructura — corre las siete piezas ya construidas contra un caso nuevo. El valor no está en aprender algo distinto, está en confirmar, con evidencia ejecutada, que lo que ya aprendiste generaliza más allá del caso exacto con el que lo construiste.

Tratar el incidente sintético de este módulo como si tuviera el mismo peso narrativo que el incidente Claude Code, con una fuente primaria que citar (de confundir "determinista" con "verificado externamente"). Qué pasa: alguien busca, para el incidente de la lección 3, el mismo tipo de fuente independiente —Hacker News, incidentdatabase.ai, cobertura técnica— que el Módulo 6 citó para el incidente Claude Code. Cómo detectarlo: si tu resumen del incidente de este módulo intenta atribuirlo a una empresa o un caso real externo. Cómo corregirlo: el incidente sintético de este módulo no necesita, ni tiene, una fuente externa —es un dato de prueba diseñado a propósito, con la misma disciplina de fijeza y determinismo que cualquier dataset de esta guía desde el Módulo 2, pero sin ninguna pretensión de haberle ocurrido a nadie real. Su función es probar el proceso, no documentar un hecho del mundo.

Asumir que "correr la máquina completa" significa volver a escribir cada script desde cero, en vez de reutilizar exactamente lo que ya existe (de subestimar cuánto de este módulo es reutilización, no construcción). Qué pasa: alguien, al llegar a la lección 4, empieza a reescribir burn_rate_exporter.py o alert_rules.yml desde cero, en vez de extenderlos con el mínimo cambio necesario. Cómo detectarlo: si tu copia de cualquier archivo de observability/ de este módulo difiere, en más que el mínimo necesario para el nuevo escenario, de la versión que el Módulo 4 ya dejó terminada. Cómo corregirlo: la lección 4 de este módulo es explícita sobre esto — las reglas de PromQL de alert_rules.yml no cambian ni una línea; lo único que se agrega es un tercer valor de escenario en el exportador. Que la máquina funcione sin tener que tocar su propia lógica es, precisamente, la prueba que este módulo busca.

Ejercicios

Ejercicio 1 — En tus propias palabras, explica por qué un incidente sintético, diseñado a propósito para este módulo, es una prueba más honesta de la máquina completa que repetir el incidente Claude Code una segunda vez.

Ver solución

Repetir el incidente Claude Code produciría, necesariamente, el mismo resultado que el Módulo 6 ya obtuvo — los mismos números, la misma clasificación de severidad, la misma mitigación —, porque cada pieza de la máquina ya se probó exactamente contra esos hechos. Eso no demostraría nada nuevo: confirmaría que la máquina funciona sobre el caso con el que ya se sabe que funciona. Un incidente sintético nuevo, en cambio, obliga a cada pieza —el exportador de burn rate, las reglas de Alertmanager, la matriz de severidad, el runbook— a reaccionar ante números que nadie ajustó a propósito para que salieran bien. Si la máquina completa produce el resultado correcto sobre datos que nunca vio, esa es una prueba real de que el diseño generaliza, no solo de que fue calibrado para un caso específico.

Ejercicio 2 — La lección 5 va a escribir un segundo POSTMORTEM.md, más corto que el del Módulo 7. Antes de leerla, predice: ¿qué partes de la estructura de un postmortem sin culpa (Módulo 7, lección 2) esperarías que sigan siendo iguales, y cuáles esperarías que se acorten?

Ver solución

Lo que debería seguir igual: la disciplina sin culpa completa (ningún nombre de persona como causa), la distinción entre disparador y causa raíz, y la estructura general de secciones (resumen, impacto, causa raíz, qué salió bien/mal, action items) — esa disciplina no depende de la escala del incidente. Lo que razonablemente se acortaría: el número de causas raíz (el incidente Claude Code tuvo cuatro, en distintas capas de un sistema completo destruido; un incidente de una sola alarma de errores probablemente tiene una causa más concentrada), la sección de impacto (un incidente resuelto en minutos u horas, no en 24 horas, tiene menos que narrar), y potencialmente el número de action items (menos causas raíz, menos acciones directas que derivar de ellas). La proporción correcta es "tan riguroso como haga falta, no tan largo como el ejemplo anterior" — un postmortem corto y sin culpa no es un postmortem incompleto, si el incidente en sí fue más simple.

Ejercicio 3 — INCIDENT-RESPONSE-PLAN.md (Módulo 5) termina con la frase: "Module 8's capstone runs a new synthetic incident through the same framework, unchanged, to confirm it works on a case nobody saw coming". Explica por qué la palabra "unchanged" en esa frase es la promesa central de este módulo entero.

Ver solución

"Unchanged" es la condición que hace que el ejercicio de este módulo signifique algo: si cualquier pieza de la máquina —el ciclo de vida, la matriz de severidad, los roles, la rotación, la alerta, el runbook— tuviera que modificarse para que el incidente sintético funcionara correctamente, eso demostraría que el marco original tenía un hueco que solo se descubrió al forzarlo con un caso nuevo, no que el marco generaliza. La promesa de esta palabra es que las siete piezas construidas en los Módulos 2 a 7 son, de verdad, un marco reutilizable —no una solución hecha a la medida del único caso con el que se probó—, y este módulo existe precisamente para poner esa promesa a prueba con evidencia, no con una afirmación sin verificar.

Resumen y siguiente paso

Esta lección estableció el propósito completo del capstone: correr, sin ningún cambio, la máquina de confiabilidad completa que los siete módulos anteriores construyeron —SLI, dato real, alerta de burn rate, ciclo de vida de incidentes, roles, mitigación, postmortem sin culpa— contra un incidente sintético nuevo, determinista, que ninguna pieza de esta guía vio durante su propia construcción. Viste el mapa de las ocho lecciones, y la honestidad que sostiene todo el módulo: este incidente no le pasó a nadie externo, real ni ficticio — es un dato de prueba diseñado para confirmar que el marco generaliza, con la misma disciplina de "nunca random, nunca datetime.now()" de toda esta guía.

Antes de avanzar deberías poder: explicar la diferencia entre "repetir el incidente Claude Code" y "probar la máquina con un caso nuevo"; nombrar las siete piezas heredadas que este módulo va a correr sin modificar; y anticipar, en términos generales, qué partes de un postmortem sin culpa se acortan razonablemente cuando el incidente en sí es más simple.

La lección 2 revisa, con un diagrama completo, cómo encajan las siete piezas heredadas entre sí antes de introducir el incidente nuevo — el mapa completo de andes-cargo-infra/ como existe hoy, con cada archivo en su lugar exacto.

Recursos

Este mismo repositorio, Módulo 5, lección 8 (08-project-andes-cargos-incident-response-plan.md) — INCIDENT-RESPONSE-PLAN.md, la fuente de la promesa de este módulo, citada completa en su sección "Consequences".
Este mismo repositorio, Módulo 7, lección 8 (08-project-andes-cargos-postmortem-and-runbooks-package.md) — RELIABILITY-POSTMORTEM-PACKAGE.md, el mismo patrón de documento de portafolio que este módulo va a extender en su lección 8.
Google SRE — Incident Management Guide — el marco completo que este módulo pone a prueba una segunda vez.
Google SRE Workbook — Alerting on SLOs — la matemática de burn rate que la lección 4 de este módulo corre, sin cambios, sobre datos nuevos.

← Anterior8. Proyecto: el paquete de postmortem y runbooks de Andes Cargo Siguiente →2. Repaso de arquitectura: la máquina de confiabilidad completa