Módulo 1: What Is Sre And Reliability As A Feature

8. Proyecto: la carta de confiabilidad de Andes Cargo

Siguiente →

Descripción

Siete lecciones te dieron el vocabulario (SRE, error budget, SLI/SLO/SLA, toil, on-call, postmortem), un inventario real de riesgo, y el primer cálculo ejecutado de esta guía —33,3x el presupuesto mensual, en el incidente Claude Code—. Este proyecto final del módulo reúne todo eso en el primer documento formal de esta guía: un ADR (Architecture Decision Record), el mismo formato que THREAT-MODEL.md/RISK-MAP.md ya usaron en cloud-security-and-guardrails-guide y que COST-PROFILE.md/COST-MAP.md ya usaron en finops-and-cost-guardrails-guide. El resultado es RELIABILITY-CHARTER.md: qué significa "confiable" para este sistema específico, y el mapa completo de los 8 módulos que esta guía va a atravesar para construirlo.

Conexión con el módulo

Este es el cierre del Módulo 1, y el documento que gobierna, literalmente, la secuencia de lecciones que vas a atravesar en M2 a M8 — el mismo rol que COST-MAP.md cumple en finops-and-cost-guardrails-guide. A diferencia de ese documento, cuyas siete filas eran drivers independientes que podían resolverse en distinto orden, cada fila de RELIABILITY-CHARTER.md depende directamente de la anterior: el SLO del Módulo 2 es lo que el Módulo 3 mide, lo que el Módulo 4 usa para alertar, lo que el Módulo 6 usa para medir el incidente real. Vas a volver a este documento en cada proyecto de módulo, para marcar una fila como resuelta.

Paso 1 — Por qué este documento no elige un SLO todavía

La tentación más fuerte al escribir este documento es poner un número real —"el SLO de Andes Cargo es 99,9%"— porque se siente como el cierre correcto de un módulo sobre confiabilidad. Este documento resiste esa tentación a propósito: elegir un SLO sin las cuatro señales doradas (Módulo 2, lección 2) ni un dataset real (Módulo 2, lección 4) sería exactamente el error más común que ya nombraste en la lección 3 de este módulo —"elegir el SLO más alto posible porque suena mejor"—, solo que esta vez disfrazado de "elegir un SLO razonable porque suena responsable". RELIABILITY-CHARTER.md fija la filosofía —cómo se va a decidir la confiabilidad de este sistema— y deja el número real, con su evidencia, para el Módulo 2.

Paso 2 — El documento completo

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

# RELIABILITY-CHARTER.md — What "Reliable" Means for Andes Cargo

**Status:** Accepted · **Date:** this module's close · **Supersedes:** none
**Governs:** Modules 1 through 8 of `sre-and-incident-response-guide`
**Source:** Module 1, lessons 2-7 (SRE vocabulary, the error-budget math on the Claude Code incident,
the SRE-lens inventory of `andes-cargo-infra/`)

## Context

Six guides built and hardened `andes-cargo-infra/`: four core services (`aws-core-services-guide`),
a production-grade Lambda with concurrency limits and retries (`aws-serverless-and-containers-guide`),
the whole stack declared in Terraform (`terraform-and-iac-guide`), a CI/CD pipeline running two green
gates (`cicd-and-gitops-on-aws-guide`, `cloud-security-and-guardrails-guide`, `finops-and-cost-
guardrails-guide`). None of the three questions those gates answer — is this secure, does this deploy
cleanly, does this fit the budget — measures whether the system stays up in production. Module 1 of
this guide established, with a real incident and real arithmetic, why that gap matters: a hypothetical
99.9% monthly SLO gives `process-shipment-manifest` 43.2 minutes of allowed downtime a month: a single
24-hour recovery, the kind DataTalks.Club lived through in February 2026, burns 33.3x that budget in
one event. No SLA exists for Andes Cargo (an internal tracking system, no paying external customer),
so the number that matters here is an SLO, not an SLA, and it does not exist yet.

## Decision

**"Reliable" means measured, not promised — the same distinction Module 1, lesson 2 drew from Ben
Treynor's definition of SRE.** For Andes Cargo specifically, this charter commits to five concrete
positions, ahead of Module 2's real numbers:

1. **No SLO is chosen in this document.** Picking a number without the four golden signals (Module 2,
   lesson 2) or a real dataset (Module 2, lesson 4) would be exactly the "100% because it sounds
   responsible" mistake Module 1, lesson 3 named as this guide's most common error. The SLO is decided
   with evidence, in Module 2, not guessed here to make this charter feel more complete.
2. **`process-shipment-manifest` is not a payments system or a life-support system.** It is an
   asynchronous manifest processor for a cargo-tracking product. This charter explicitly rejects
   chasing 99.99%+ reliability for it — the cost of that pursuit (Module 1, lesson 3: each additional
   nine can cost 100x more than the last) is not justified by what a few extra minutes of delayed
   processing would cost the business.
3. **Single-region (`us-east-1`) is accepted, with the risk named, not hidden.** Module 1, lesson 4
   found no cross-region failover anywhere in `andes-cargo-infra/`; lesson 5 named the `us-east-1`
   outage of October 2025 as the concrete shape that risk takes. This guide's $0, single-region scope
   (declared in its own design) means multi-region DR is out of scope — this charter records that as a
   known, accepted gap, not an oversight discovered later.
4. **An error budget is a measurement and negotiation tool, never a preventive control.** Module 1,
   lesson 5 drew this line explicitly against the Claude Code incident: `conftest` and `prevent_destroy`
   (built in `cloud-security-and-guardrails-guide`) are this system's preventive layer. Nothing in this
   guide replaces them; this guide's tools quantify damage and inform decisions after the fact.
5. **Every incident this guide operates gets a blameless postmortem.** Following Module 1, lesson 7's
   citation of Google SRE's postmortem culture: identifying contributing causes with full precision,
   never indicting an individual or team for acting in good faith with the information they had.

## The map

| # | Module | Central question | Deliverable | Status |
|--:|---|---|---|---|
| 1 | What Is SRE and Reliability as a Feature | What does "reliable" mean, measurably, for this system? | `RELIABILITY-CHARTER.md` (this document) | In progress |
| 2 | SLIs, SLOs, and the Error Budget | What SLI and SLO make sense for `process-shipment-manifest`, with evidence? | `SLO.md`, `scripts/error_budget_calculator.py` | Open |
| 3 | Observability as SLI Input | Where does the SLI's real data come from, and how is it read? | `observability/docker-compose.yml`, `observability/instrument_manifest_flow.py` | Open |
| 4 | Alerting on Error Budget Burn Rate | When does an alert fire, and why that threshold and not a static one? | `scripts/burn_rate_evaluator.py`, `observability.tf` | Open |
| 5 | The Incident Lifecycle | Who does what, at what severity, on what on-call schedule? | `INCIDENT-RESPONSE-PLAN.md`, `oncall/schedule.py` | Open |
| 6 | Operating the Claude Code Incident | How does a real incident run through the machine this guide built? | `incidents/2026-02-26-claude-code-destroy/TIMELINE.md` | Open |
| 7 | Blameless Postmortems and Runbooks | What did the system teach us, and what do we do differently next time? | `.../POSTMORTEM.md`, `runbooks/manifest-processor-error-rate.md` | Open |
| 8 | Capstone: The Andes Cargo Reliability Package | Does the whole machine work end-to-end, on an incident nobody saw coming? | Full repository, portfolio-ready | Open |

## Consequences

Every row's `Status` column moves from `Open` to `Resolved` — noting the closing lesson — as each
module completes. Unlike `COST-MAP.md` in `finops-and-cost-guardrails-guide`, this charter's rows are
not independent drivers that could theoretically resolve out of order: each module's deliverable is a
direct input to the next (the SLO of M2 is what M3 measures, what M4 alerts on, what M6 measures the
incident against), so this map is read top to bottom, not reordered.

## Alternatives considered

**Pick a placeholder SLO now (e.g., 99.9%) so this document feels complete on day one.** Rejected:
Module 1, lesson 3 already showed why an SLO chosen without evidence is this guide's most common
mistake. A placeholder number, even labeled as such, tends to calcify into the real one by the time
Module 2 arrives — better an honest `Open` in this table than a number nobody actually chose with
data.

**Commit to a multi-region reliability target, matching what a real production system would need.**
Rejected: explicitly out of this guide's declared $0, single-region scope. Naming the gap honestly
(Decision, point 3) serves a learner better than a target this guide cannot build toward.

**Treat the security gate and cost gate as sufficient evidence of reliability, and skip this charter.**
Rejected: this is the exact premise Module 1 spent seven lessons dismantling — green and secure and
affordable measured three different questions, none of them "does this stay up, and for how long can
it not."

Paso 3 — Verificando el documento

wc -l RELIABILITY-CHARTER.md
grep -c '^| [1-8] ' RELIABILITY-CHARTER.md

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

86
8

Ochenta y seis líneas, ocho filas numeradas en la tabla — una por módulo, ninguna faltante, ninguna duplicada. La fila 1 es la única con Status: In progress, exactamente lo que corresponde: este documento es, él mismo, el entregable de la fila que describe.

Cómo leer este documento, seis meses después

Igual que su equivalente en finops-and-cost-guardrails-guide, la prueba real de este ADR no es su forma el día que se escribe — es si sigue siendo útil cuando nadie recuerda el contexto completo de memoria. Frente a este documento, un lector nuevo debería poder contestar, sin preguntarle a nadie: ¿qué significa "confiable" aquí? (sección Decision, cinco posiciones concretas, ninguna un número inventado); ¿qué falta construir, y en qué orden? (la tabla, leída de arriba hacia abajo, nunca reordenada); ¿por qué no hay un SLO todavía? (Alternatives considered, primera entrada); y ¿qué riesgo se aceptó a propósito, en vez de ignorarse por accidente? (Decision, punto 3 — una sola región, con la razón nombrada). Si alguna de esas cuatro preguntas exige releer una lección completa, el documento no cumplió su función.

El cierre del Módulo 1

Con RELIABILITY-CHARTER.md escrito, este módulo entrega exactamente lo que prometió en la lección 1: no una calculadora construida —esa llega en el Módulo 2— sino el vocabulario completo, un inventario real de riesgo, el primer número real de esta guía (33,3x), y el documento que gobierna, con honestidad, qué falta y en qué orden. Entras al Módulo 2 con una filosofía de confiabilidad ya decidida y un mapa trazable, en vez de una sensación general de "hay que ser más confiables".

Errores comunes

Completar la fila 1 de la tabla como Resolved al terminar esta lección (de expectativa sobre el propio documento). Qué pasa: alguien, al terminar de escribir RELIABILITY-CHARTER.md, marca su propia fila como resuelta. Cómo detectarlo: si el Status de la fila 1 dice Resolved en vez de In progress. Cómo corregirlo: este documento nunca termina de "resolverse" a sí mismo del todo — sigue vigente, gobernando el resto de la guía, hasta que el Módulo 8 cierre el capstone. In progress es el estado honesto mientras el propio charter sigue siendo la referencia activa de todos los módulos que faltan.

Agregar un SLO numérico a este documento "para no dejarlo incompleto" (el mismo error de la lección 3, reaparecido aquí). Qué pasa: alguien, incómodo con que un documento de confiabilidad no tenga ningún número de SLO, agrega uno de todas formas, citando esta misma lección como si ya lo permitiera. Cómo detectarlo: si tu versión de RELIABILITY-CHARTER.md tiene un porcentaje de disponibilidad en algún lado. Cómo corregirlo: la sección Alternatives considered de este documento explica, con la misma lógica que la lección 3 de este módulo, por qué un SLO sin evidencia es peor que ningún SLO — vuelve a leer esa sección antes de agregar cualquier número. El Módulo 2 es, literalmente, el lugar diseñado para esa decisión.

Tratar la ausencia de un SLA como un descuido, en vez de una decisión deliberada (de lectura incompleta). Qué pasa: alguien nota que este documento no menciona ningún SLA y asume que es una pieza faltante que se agregará después. Cómo detectarlo: si buscas, en módulos posteriores, dónde se define el SLA de Andes Cargo. Cómo corregirlo: el Contexto de este documento es explícito — Andes Cargo es un sistema interno, sin cliente externo pagando por un contrato de disponibilidad con consecuencias financieras. Un SLA no es una pieza pendiente de esta guía; es, correctamente, una pieza que este sistema específico no necesita, exactamente la distinción que la lección 7 de este módulo estableció entre SLO y SLA.

Ejercicios

Ejercicio 1 — Actualiza RELIABILITY-CHARTER.md a mano, prediciendo el cierre del Módulo 2. Sin haber hecho todavía el Módulo 2 de esta guía, escribe cómo quedaría la fila 2 de la tabla una vez que ese módulo termine, incluida la columna Status y una nota breve de qué evidencia la respaldaría.

Ver solución

Una actualización razonable: Status: Resolved (M2.8), con una nota del estilo "SLI defined as successful invocations over valid invocations for process-shipment-manifest; SLO chosen and justified against the four golden signals (M2.2) and a real 30-day sample dataset (M2.4); SLO.md committed with the number and its reasoning; scripts/error_budget_calculator.py running against that dataset, producing a literal error-budget figure in minutes." El punto del ejercicio no es adivinar el número exacto del SLO —eso depende del criterio real que se aplique en el Módulo 2—, sino practicar que cada actualización de Status venga acompañada de qué evidencia concreta la respalda, nunca solo la palabra "Resolved".

Ejercicio 2 — Defiende la posición 3 del Decision frente a una objeción real. Un entrevistador técnico, revisando este documento, pregunta: "¿por qué aceptar el riesgo de una sola región en vez de, al menos, documentar un plan de migración a multi-región?" ¿Cómo responderías, usando el propio documento como referencia?

Ver solución

Una respuesta completa: "El documento no ignora el riesgo — lo nombra explícitamente, con el outage de us-east-1 de octubre de 2025 como el caso concreto que ese riesgo representa. La decisión de no construir ni siquiera un plan de migración no es negligencia: es honestidad sobre el alcance de esta guía, declarado desde su diseño, de $0 y una sola región. Un plan de migración a multi-región que nunca se va a ejecutar, escrito solo para que este documento se vea más completo, sería peor que la honestidad actual — prometería algo que esta guía no tiene intención de construir. La alternativa correcta, si Andes Cargo alguna vez necesitara resolver este riesgo de verdad, es una guía o un proyecto distinto, con su propio presupuesto de ingeniería, no una sección adicional de este documento." Reconocer el riesgo con precisión, sin fingir una mitigación que no existe, es exactamente la misma disciplina que esta guía completa ya practicó con cada caso representativo.

Ejercicio 3 — Explica por qué las filas de este mapa no pueden resolverse fuera de orden, a diferencia de COST-MAP.md. Un compañero, familiarizado con finops-and-cost-guardrails-guide, pregunta por qué no podría, por ejemplo, construir primero el runbook (Módulo 7) y después definir el SLO (Módulo 2), ya que en COST-MAP.md el orden de los drivers era una decisión de secuencia pedagógica, no una dependencia técnica dura.

Ver solución

Porque, a diferencia de los siete drivers de costo de COST-MAP.md —que eran, en los hechos, bastante independientes entre sí—, cada entregable de esta guía es un insumo directo del siguiente: un runbook (Módulo 7) describe qué hacer cuando una alerta de burn rate dispara, pero esa alerta (Módulo 4) no puede existir sin datos reales de observabilidad (Módulo 3), que a su vez no tienen ningún SLI/SLO contra el cual medirse sin el Módulo 2. Intentar escribir el runbook del Módulo 7 antes de que exista un SLO real significaría escribir instrucciones para responder a una alerta que, técnicamente, todavía no puede dispararse por nada medible. La sección Consequences de este documento es explícita sobre esta diferencia: las filas de este mapa se leen de arriba hacia abajo, no se reordenan.

Resumen y siguiente paso

En este proyecto final del módulo escribiste RELIABILITY-CHARTER.md, el primer documento de portafolio de esta guía: cinco posiciones concretas sobre qué significa "confiable" para Andes Cargo (medido, no prometido; sin perseguir nueves innecesarios; una sola región con el riesgo nombrado; error budget como medición, no como control preventivo; todo incidente con postmortem sin culpa), y el mapa completo de los 8 módulos, con su pregunta central y su entregable, leído en orden estricto de dependencia. Verificaste el documento con la misma disciplina determinista de todo este ecosistema: 86 líneas, 8 filas, ninguna resuelta todavía, honestamente marcadas.

Antes de cerrar este módulo deberías poder: recitar las cinco posiciones de la sección Decision sin mirar el documento; explicar por qué ninguna fila de este mapa puede resolverse fuera de orden; y defender, frente a una objeción real, por qué este documento no elige un SLO todavía.

Con esto, el Módulo 1 de sre-and-incident-response-guide queda completo: el vocabulario de SRE aprendido y citado de la fuente oficial, un inventario real de riesgo sobre andes-cargo-infra/, el primer número ejecutado de esta guía (33,3x el presupuesto mensual), y un documento de portafolio defendible frente a cualquier pregunta técnica. El Módulo 2 abre la primera fila de este mapa: la calculadora real de error budget, corriendo por primera vez sobre un dataset committeado.

Recursos

  1. AWS Prescriptive Guidance — Architecture decision records — la referencia oficial de AWS sobre el formato ADR que RELIABILITY-CHARTER.md sigue.
  2. Este módulo, lecciones 2 a 7 — la fuente directa de cada posición de la sección Decision de este documento.
  3. finops-and-cost-guardrails-guide, Módulo 1, lección 8 (08-project-andes-cargos-cost-profile-and-roadmap.md) — la lección hermana cuyo formato de ADR esta lección adapta al dominio de confiabilidad.
  4. cloud-security-and-guardrails-guide, Módulo 1, lección 8 — el mismo patrón de mapa de riesgos/roadmap, aplicado por primera vez en este ecosistema.
← Anterior7. El vocabulario que vas a usar toda la guíaSiguiente →1. Introducción: del vocabulario a la matemática