Módulo 8: Capstone The Andes Cargo Reliability Package

8. Proyecto final: el paquete de confiabilidad de Andes Cargo como entregable

Descripción

Ocho módulos construyeron, uno a la vez, una máquina completa de confiabilidad, y este módulo acaba de correrla dos veces —contra un incidente real y contra uno sintético— con el mismo resultado correcto ambas veces. Este proyecto final no escribe ningún cálculo nuevo, ninguna alerta nueva, ningún documento de incidente nuevo — reúne todo lo que existe en andes-cargo-infra/ en RELIABILITY-PACKAGE.md, el índice completo de portafolio de toda la guía, con la misma disciplina de ensamblaje sin invención que cada proyecto de cada módulo ya aplicó por separado.

Conexión con el módulo

Este documento hace, por la guía completa, lo que RELIABILITY-POSTMORTEM-PACKAGE.md (Módulo 7) hizo por sus cuatro artefactos: cita rutas y resultados, nunca repite contenido. Es el último documento que esta guía produce — el que un entrevistador, un revisor técnico, o tú mismo, seis meses después, abrirían primero para entender qué construiste y cómo se conecta todo entre sí.

Paso 1 — El inventario final, verificado

find andes-cargo-infra -type f \
  \( -name "*.md" -o -name "*.py" -o -name "*.tf" -o -name "*.yml" -o -name "*.json" \) \
  | sort

Qué esperar (literal — veintitrés archivos: los veintiuno que el Módulo 8, lección 2 ya confirmó, más los dos que este módulo agregó):

andes-cargo-infra/ALERTING-POLICY.md
andes-cargo-infra/INCIDENT-RESPONSE-PLAN.md
andes-cargo-infra/RELIABILITY-CHARTER.md
andes-cargo-infra/RELIABILITY-POSTMORTEM-PACKAGE.md
andes-cargo-infra/SLO.md
andes-cargo-infra/incidents/2026-02-26-claude-code-destroy/POSTMORTEM.md
andes-cargo-infra/incidents/2026-02-26-claude-code-destroy/TIMELINE.md
andes-cargo-infra/incidents/2026-03-17-manifest-schema-regression/POSTMORTEM.md
andes-cargo-infra/observability.tf
andes-cargo-infra/observability/alert_rules.yml
andes-cargo-infra/observability/alert_webhook_receiver.py
andes-cargo-infra/observability/alertmanager.yml
andes-cargo-infra/observability/burn_rate_exporter.py
andes-cargo-infra/observability/docker-compose.yml
andes-cargo-infra/observability/instrument_manifest_flow.py
andes-cargo-infra/observability/manifest-log-events.json
andes-cargo-infra/observability/prometheus.yml
andes-cargo-infra/observability/synthetic-incident-log-events.json
andes-cargo-infra/observability/upload_manifest_batch.py
andes-cargo-infra/observability/upload_synthetic_incident_batch.py
andes-cargo-infra/oncall/schedule.py
andes-cargo-infra/runbooks/manifest-processor-error-rate.md
andes-cargo-infra/scripts/burn_rate_evaluator.py
andes-cargo-infra/scripts/error_budget_calculator.py

Veinticuatro archivos, con RELIABILITY-PACKAGE.md de esta lección como el vigésimo quinto. incidents/ ahora tiene dos subdirectorios —la prueba física de que la máquina se corrió dos veces, no una—; observability/ tiene dos batches de invocaciones (upload_manifest_batch.py del Módulo 3, upload_synthetic_incident_batch.py de este módulo) y dos archivos de log guardados, uno por cada caso que un runbook diagnosticó de verdad.

Paso 2 — El documento final de portafolio

En la raíz de andes-cargo-infra/, crea RELIABILITY-PACKAGE.md:

# RELIABILITY-PACKAGE.md — Andes Cargo's Complete Reliability Machine

**Status:** Final · **Closes:** `sre-and-incident-response-guide`, all 8 modules
**Built on:** every document and script this guide produced — this index cites each one by
path, it does not repeat any of their content.

## What "reliable" means for this system, and how it's measured

`RELIABILITY-CHARTER.md` (Module 1) names what reliability means for `process-shipment-manifest`
and maps the 8-module plan. `SLO.md` (Module 2) defines the SLI (good events / valid events),
the SLO (99.9% monthly), and the error budget (43.2 minutes) in an executable calculator,
`scripts/error_budget_calculator.py` — not just a formula in prose.

## Where the data comes from

`observability/` — Prometheus `v3.13.2`, Grafana `13.1.3`, Alertmanager `v0.33.1`, Jaeger v2
(`jaegertracing/jaeger`, never `all-in-one`), all verified running in this environment (Module 3).
`observability/upload_manifest_batch.py` generates real, deterministic traffic through the real
S3 trigger path — never a manual `lambda invoke` — feeding CloudWatch's native `Invocations`/
`Errors` metrics for `process-shipment-manifest`.

## When it alerts, and why

`ALERTING-POLICY.md` (Module 4) is the burn-rate policy — never a static threshold — implemented
three times over: `scripts/burn_rate_evaluator.py` (the Python prototype), `observability/
alert_rules.yml` (real Prometheus/Alertmanager rules, `and ignoring(window)` for the two-window
confirmation), and `observability.tf` (a real CloudWatch alarm with metric math). All three agree
on every scenario tested against them — `bad_week`, `normal`, and `synthetic_incident` (Module 8).

## Who responds, and how

`INCIDENT-RESPONSE-PLAN.md` (Module 5) is the response framework — five-stage lifecycle, a
severity matrix mapped directly onto `ALERTING-POLICY.md`'s burn-rate tiers, three roles (IC/OL/CL)
that never merge decision and execution in a SEV1/SEV2, and `oncall/schedule.py`, a deterministic
rotation with no SaaS and no randomness.

## Two incidents, the same framework, unchanged

| Incident | Path | Severity criterion | Postmortem |
|---|---|---|---|
| Claude Code `destroy` (real, external, DataTalks.Club) | `incidents/2026-02-26-claude-code-destroy/` | SEV1 via the independent data-loss criterion — no burn rate was measurable | `POSTMORTEM.md`, 171 lines, 4 root causes (Module 7) |
| Manifest schema regression (synthetic, Module 8) | `incidents/2026-03-17-manifest-schema-regression/` | SEV1 via the primary burn-rate criterion (400.00x short window, 25.00x long window) | `POSTMORTEM.md`, 67 lines, 1 root cause (Module 8) |

One incident this framework did not design itself to handle; one it did. Same lifecycle, same
severity matrix, same roles, same runbook — `runbooks/manifest-processor-error-rate.md` resolved
the second one on its first real use of Branch A, the branch its original worked example never
demonstrated.

## What this package does not do

It does not re-verify any individual artifact's own content — `SLO.md`, `ALERTING-POLICY.md`,
`INCIDENT-RESPONSE-PLAN.md`, and `RELIABILITY-POSTMORTEM-PACKAGE.md` each already passed their
own module's verification (line counts, section counts, forced drills), cited here, not repeated.
It does not claim this machine is complete for every kind of system — Module 8, lesson 7 named,
with precision, the three directions (EKS, AI systems, deep observability) where the same
vocabulary needs a different guide and a different set of signals. It does not replace the
preventive controls `cloud-security-and-guardrails-guide` already built — this package measures
and responds; it does not gate a deploy or protect a resource from deletion.

## What a reader should be able to answer from this package alone

**What does "reliable" mean here, with a number, not a feeling?** (`SLO.md`, cited above.)
**What data feeds that number, and is it real?** ("Where the data comes from", Module 3's stack,
verified running.) **When does this system alert, and why is that the right moment?**
(`ALERTING-POLICY.md`, three engines, proven to agree.) **Who responds, in what order, with what
authority?** (`INCIDENT-RESPONSE-PLAN.md`, cited above.) **Does the framework actually work, or
only on the one case it was built to explain?** (the two-incident table — one case built the
framework, one case tested it against something new.)

## Consequences

This is the last document `sre-and-incident-response-guide` produces. Module 8, lesson 7's map
(`kubernetes-and-eks-in-production-guide`, `genai-on-aws-production-guide`,
`monitoring-observability-guide`) names where this same vocabulary goes next, with different
systems behind it — not built here, by design.

Paso 3 — Verificando el paquete final

wc -l RELIABILITY-PACKAGE.md
grep -c '^## ' RELIABILITY-PACKAGE.md
grep -c '^|' RELIABILITY-PACKAGE.md

Qué esperar (literal — el contenido lo ensamblaste tú, la forma es determinista):

55
7
5

Cincuenta y cinco líneas, siete secciones, cinco líneas de tabla (dos filas de datos más tres de encabezado/separador en la tabla de los dos incidentes) — el documento más corto de todo el portafolio de esta guía, exactamente como corresponde a un índice de índices: cada afirmación de este documento remite a un artefacto que ya se verificó, línea por línea, en su propio módulo.

Paso 4 — Defendiendo el proyecto completo en una entrevista

Con RELIABILITY-PACKAGE.md terminado, tienes el resumen de una hora de conversación técnica reducido a un documento de cincuenta y cinco líneas, con cada afirmación respaldada por un artefacto ejecutado de verdad. Un recorrido razonable, si un entrevistador te pidiera "camina conmigo por tu proyecto de SRE":

  1. "¿Qué es confiabilidad aquí, en números?" — abre SLO.md, muestra python3 scripts/error_budget_calculator.py, y la salida literal: 99,9098% de SLI medido, 4,23 minutos de presupuesto restantes de 43,2.
  2. "¿Cómo sabes que ese número es real, no inventado?" — observability/upload_manifest_batch.py, el trigger real de S3, awslocal cloudwatch get-metric-statistics leyendo Invocations/Errors reales.
  3. "¿Cuándo suena la alarma, y por qué en ese momento y no antes?" — ALERTING-POLICY.md, el patrón multi-window, multi-burn-rate de Google SRE, los tres motores coincidiendo en el mismo veredicto sobre los mismos datos.
  4. "¿Qué pasa cuando de verdad suena?" — INCIDENT-RESPONSE-PLAN.md, y el incidente Claude Code operado de punta a punta con esa estructura.
  5. "¿Cómo sabes que ese marco no está hecho a la medida de un solo caso?" — el incidente sintético del Módulo 8: mismo marco, sin ningún cambio, contra un caso que nadie ajustó para que funcionara bien.

Cinco preguntas, cinco artefactos, ninguna respuesta improvisada — cada una es, literalmente, el resultado de un comando que corriste.

Errores comunes

Presentar RELIABILITY-PACKAGE.md como el documento que "contiene" el proyecto completo, en vez de como el índice que apunta hacia él (de perder, en el último documento de la guía, la disciplina de ensamblaje que gobernó todos los anteriores). Qué pasa: alguien, al preparar este proyecto para una entrevista o un portafolio, solo comparte RELIABILITY-PACKAGE.md, sin los veinticuatro archivos que indexa. Cómo detectarlo: si tu entrega de este proyecto es un solo archivo de cincuenta y cinco líneas, sin ningún enlace ni acceso a los documentos que cita. Cómo corregirlo: este documento es, deliberadamente, un mapa — su valor completo depende de que cada ruta que cita exista y sea consultable; compartirlo aislado, sin el repositorio completo detrás, es como entregar solo el índice de un libro y decir que es el libro.

Tratar la tabla de "Dos incidentes" como si ambos tuvieran el mismo peso narrativo, sin distinguir cuál es real y cuál es sintético (repetido, en el documento final, del mismo cuidado que el Módulo 8, lección 1 y lección 5 ya exigieron por separado). Qué pasa: alguien, al resumir este proyecto, describe los dos incidentes de la tabla como si ambos le hubieran ocurrido a una empresa real. Cómo detectarlo: si tu descripción de "los dos incidentes que maneja este proyecto" no distingue cuál tiene una fuente primaria externa verificable y cuál es una construcción interna de este módulo. Cómo corregirlo: la tabla del Paso 2 ya lo etiqueta con precisión —"real, external, DataTalks.Club" frente a "synthetic, Module 8"—; esa distinción, ya establecida en cada lección donde apareció, sigue aplicando en el documento final tanto como en la primera vez que se declaró.

Considerar el proyecto "terminado" sin haber corrido, al menos una vez, los comandos de verificación del Paso 3 sobre tu propia copia (repetido, por última vez en esta guía, del mismo error que cada proyecto anterior ya advirtió). Qué pasa: alguien copia RELIABILITY-PACKAGE.md del Paso 2 y da el proyecto por completo sin confirmar que su propio find del Paso 1 devuelve los mismos veinticuatro archivos. Cómo detectarlo: si no puedes reproducir, en tu propia copia del repositorio, el inventario exacto del Paso 1. Cómo corregirlo: la disciplina de verificación determinista de esta guía —wc -l, grep -c, un comando cuya salida no admite ambigüedad— no se relaja en el último documento; si tu inventario difiere del Paso 1, hay una lección de este módulo, o de uno anterior, que quedó sin completar.

Ejercicios

Ejercicio 1 — Verifica el Paso 3 sobre tu propia copia de RELIABILITY-PACKAGE.md y confirma que obtienes exactamente 55, 7 y 5.

Ver solución

Copiando el documento del Paso 2 exactamente como aparece, wc -l cuenta 55 líneas, grep -c '^## ' encuentra siete encabezados de sección de nivel 2, y grep -c '^|' encuentra cinco líneas que empiezan con una barra vertical —las tres líneas de la tabla de los dos incidentes (encabezado, separador, y las dos filas de datos cuentan como cuatro; si tu conteo da un número distinto, revisa que la tabla del Paso 2 no tenga ninguna línea extra o faltante—. La verificación determinista de este documento final sigue el mismo patrón exacto que cada documento anterior de esta guía.

Ejercicio 2 — Un entrevistador, después de escuchar el recorrido de cinco preguntas del Paso 4, pregunta: "de todo esto, ¿qué fue lo más difícil de construir?". Usando lo que sabes de toda la guía, ¿cómo responderías con una respuesta específica, no genérica?

Ver solución

Una respuesta específica y defendible citaría el patrón multi-ventana de burn rate (Módulo 4) como la pieza técnicamente más exigente —no por la matemática en sí (una división y una comparación), sino por entender por qué hacen falta dos ventanas a la vez, y expresar esa condición correctamente en tres sintaxis distintas (Python puro, PromQL con and ignoring(window), y la limitación honesta de que CloudWatch, en su forma más simple, no puede hacerlo con una sola alarma). Una respuesta genérica ("todo fue difícil" o "aprender Terraform") no demuestra el mismo nivel de comprensión que señalar, con precisión, el punto exacto donde la dificultad real estuvo — la misma disciplina de especificidad que cada "Errores comunes" de esta guía ya modeló, aplicada aquí a una pregunta de entrevista.

Ejercicio 3 — Explica por qué la sección "Consequences" de RELIABILITY-PACKAGE.md cita la lección 7 de este módulo (el mapa hacia otras guías) en vez de simplemente terminar el documento después de "What a reader should be able to answer".

Ver solución

Terminar sin esa sección dejaría la impresión de que el paquete de confiabilidad de Andes Cargo es un sistema cerrado y completo en sí mismo, sin ninguna dirección hacia dónde crecer — exactamente lo contrario de lo que un proyecto de portafolio real debería comunicar. Citar el mapa de la lección 7 en la sección de consecuencias cierra el documento con la misma honestidad que gobernó toda la guía: esto es lo que se construyó, verificado con evidencia, y esto es, con la misma precisión, hacia dónde el mismo vocabulario se extiende después — ni una afirmación de que el trabajo terminó para siempre, ni una lista vaga de "posibles mejoras futuras", sino tres direcciones concretas, cada una con su guía nombrada.

Resumen y siguiente paso

Este proyecto final integró los veinticuatro archivos de andes-cargo-infra/ —cinco documentos de portafolio, dos scripts de matemática de SRE, nueve piezas de observability/, un archivo de Terraform, un generador de guardia, un runbook, y dos incidentes completos, uno real y uno sintético— en RELIABILITY-PACKAGE.md, el índice final de toda la guía. Verificaste el documento con la misma disciplina determinista de cada proyecto anterior —55 líneas, 7 secciones, 5 líneas de tabla— y practicaste defenderlo en una entrevista con cinco preguntas, cada una respaldada por un comando que de verdad corriste, no por una afirmación sin evidencia.

Con esto, sre-and-incident-response-guide queda completa: el hueco CRITICA de SRE que VALIDACION.md marcó para el ecosistema aws-cloud-ecosystem completo —SLI/SLO/error budgets, on-call honesto, respuesta a incidentes, postmortem sin culpa— tiene, ahora, una máquina completa, ejecutada de verdad, probada dos veces contra dos casos distintos, y documentada con la misma disciplina de honestidad exacta que cada guía de este ecosistema ya exigió de sí misma. La capa de negocio de Andes Cargo —bucket, tabla, Lambda, pipeline, security gate, cost gate— sigue siendo exactamente la que las seis guías hermanas construyeron; esta guía nunca la reescribió, solo le agregó la disciplina de saber si sigue funcionando bien, y qué hacer cuando deja de hacerlo.

Recursos

  1. Este mismo repositorio, todos los módulos — la fuente de cada artefacto que este documento final indexa.
  2. Este mismo repositorio, Módulo 7, lección 8 (08-project-andes-cargos-postmortem-and-runbooks-package.md) — el precedente directo del patrón de documento de portafolio que este proyecto extiende a la guía completa.
  3. src/paths/aws-cloud-ecosystem/VALIDACION.md — el hueco CRITICA de SRE que esta guía completa cierra, citado desde el Módulo 1 de esta misma guía.
  4. Google SRE Book — Table of Contents y Google SRE Workbook — la fuente completa de la disciplina que esta guía implementó, de principio a fin, con evidencia ejecutada en cada módulo.
← Anterior7. Lo que Andes Cargo todavía necesita