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

1. Introducción a la guía: de "funciona, es seguro, cabe en el presupuesto" a "es confiable"

Descripción

Si completaste aws-core-services-guide, aws-serverless-and-containers-guide, terraform-and-iac-guide, cicd-and-gitops-on-aws-guide, cloud-security-and-guardrails-guide y finops-and-cost-guardrails-guide, tienes algo que muy pocos portafolios de aprendizaje pueden mostrar: la infraestructura completa de Andes Cargo —un bucket S3, dos roles IAM, una función Lambda, una tabla DynamoDB— declarada en Terraform dentro de andes-cargo-infra/, desplegada a través de un pipeline de GitHub Actions que corriste con act contra LocalStack, endurecida con un security gate real (conftest, Trivy, cosign) y, encima de eso, con un segundo gate que nunca dice "esto es inseguro" sino "esto es caro" (Infracost, un umbral de costo, tags de asignación). El plan sale limpio. El pipeline queda en verde, dos veces: seguro y sostenible. Y sin embargo, ninguna de las seis guías anteriores contestó todavía la pregunta que abre esta: ¿un sistema que pasa todos esos gates puede seguir fallando en producción?

La respuesta, que ya conoces si prestaste atención a los cinco casos de este mismo ecosistema que mencionan el incidente Claude Code destroy, es sí — y de la forma más costosa posible. Un plan limpio no midió nunca cuánto tiempo de indisponibilidad puede tolerar Andes Cargo antes de que sus clientes lo noten. Un pipeline seguro no midió nunca qué tan rápido se detecta que algo se rompió. Un presupuesto respetado no midió nunca si alguien sabe qué hacer a las 3 AM cuando Shipments deja de responder. Esta guía —SRE y Respuesta a Incidentes— parte de una idea central que vas a instalar en esta primera lección y vas a usar en las siete que siguen: "confiable" no es un estado que un sistema alcanza y conserva. Es una medición, con un número, una ventana de tiempo, y un presupuesto que se gasta.

Conexión con el módulo

Este Módulo 1 no construye ninguna calculadora todavía —eso empieza en el Módulo 2, con scripts/error_budget_calculator.py—. Su trabajo es el mismo tipo de trabajo que cloud-security-and-guardrails-guide y finops-and-cost-guardrails-guide ya hicieron en sus propios Módulos 1, antes de tocar una sola herramienta: instalar el vocabulario, hacer el primer inventario, y presentar el caso central de la guía con el ángulo específico que le corresponde a esta capa. Las lecciones 2 y 3 dan el marco conceptual —qué es SRE, y por qué el 100% de disponibilidad casi nunca es el objetivo correcto—. La lección 4 aplica ese marco al inventario real de Andes Cargo, leído por primera vez con ojos de SRE, no de seguridad ni de costo. Las lecciones 5 y 6 traen el caso central de esta guía —el incidente Claude Code destroy— con la primera medición real de esta capa: un cálculo manual de cuánto error budget se comió. La lección 7 formaliza el vocabulario completo. La lección 8 cierra con el primer entregable real: RELIABILITY-CHARTER.md.

Qué asume esta guía (y qué no vuelve a explicar)

Esta guía no es un punto de entrada al ecosistema de AWS de Andes Cargo. Asume, sin volver a explicarlo:

De las seis guías anteriores, completas: andes-cargo-infra/ desplegado tal como quedó al cierre de finops-and-cost-guardrails-guide —bucket andes-cargo-shipment-docs, tabla Shipments (partition key shipmentId, PAY_PER_REQUEST), función process-shipment-manifest (Python 3.13, rol LambdaManifestProcessorRole), roles IAM de mínimo privilegio— con su pipeline .github/workflows/ci.yml corriendo dos gates en paralelo: el de seguridad (policy-check/iac-scan/verify-artifact) y el de costo (cost-estimate/cost-check/cost-tags). Ninguna lección de esta guía vuelve a explicar qué es un resource de Terraform, un job de GitHub Actions, una política Rego, o cómo se estima un costo con Infracost.
docker-essentials-guide (transitivo): docker compose up, puertos, volúmenes — usado sin re-explicarse para levantar Prometheus, Grafana, Alertmanager y Jaeger en el Módulo 3.
Terminal y shell básicos, Python básico (transitivo): la calculadora de error budget y el evaluador de burn rate son scripts Python cortos, con la librería estándar — no se enseña Python desde cero.

Lo que esta guía sí enseña, y que ninguna de las seis anteriores cubrió: qué es un SLI y por qué la fórmula de Google SRE (eventos buenos ÷ eventos válidos) es más rigurosa que "¿está arriba o no?"; cómo elegir un SLO que signifique algo; qué es un error budget y cómo se calcula en minutos reales; observabilidad vista específicamente como la fuente de datos que alimenta un SLI; alerting basado en tasa de consumo del error budget (burn rate), no en un umbral estático; el ciclo de vida completo de un incidente, con roles y severidades; on-call, con honestidad sobre su costo real; y, al centro de la guía, operar de punta a punta el incidente Claude Code destroy —ya conocido de tres guías anteriores— a través de ese ciclo de vida completo, hasta el postmortem sin culpa y los runbooks que quedan como resultado.

El mapa completo: los 8 módulos de esta guía

   SRE Y RESPUESTA A INCIDENTES — LOS 8 MÓDULOS

   M1  Qué es SRE y confiabilidad como feature    ← estás aquí: vocabulario + el caso, medido por primera vez
   M2  SLIs, SLOs y el error budget                       la calculadora real, sobre datos fijos
   M3  Observabilidad como insumo del SLI                  datos reales del Lambda heredado, no simulados
   M4  Alerting sobre burn rate del error budget            dispara por la razón correcta, no por umbral
   M5  El ciclo de vida del incidente                       el marco —roles, severidad, on-call— antes del caso
   M6  Operando el incidente Claude Code                     el módulo central: se opera, no se narra una vez más
   M7  Postmortems sin culpa y runbooks                      el aprendizaje sistémico, sin buscar culpables
   M8  Capstone: el paquete de confiabilidad de Andes Cargo   un incidente nuevo, la máquina completa, de punta a punta

#	Módulo	Qué construye	Pieza nueva en `andes-cargo-infra/`
1	Qué es SRE y confiabilidad como feature	El vocabulario y el primer entregable real	`RELIABILITY-CHARTER.md`
2	SLIs, SLOs y el error budget	La calculadora real de error budget	`SLO.md`, `scripts/error_budget_calculator.py`
3	Observabilidad como insumo del SLI	Métricas/logs/trazas reales que alimentan el SLI	`observability/docker-compose.yml`, `observability/instrument_manifest_flow.py`
4	Alerting sobre burn rate del error budget	Una alerta que dispara por la razón correcta	`scripts/burn_rate_evaluator.py`, `observability.tf`
5	El ciclo de vida del incidente	El marco de roles, severidad y on-call	`INCIDENT-RESPONSE-PLAN.md`, `oncall/schedule.py`
6	Operando el incidente Claude Code	El caso real, operado con el marco del M5	`incidents/2026-02-26-claude-code-destroy/TIMELINE.md`
7	Postmortems sin culpa y runbooks	El aprendizaje sistémico y el primer runbook real	`.../POSTMORTEM.md`, `runbooks/manifest-processor-error-rate.md`
8	Capstone: el paquete de confiabilidad de Andes Cargo	La máquina completa, contra un incidente sintético nuevo	El repositorio completo, como pieza de portfolio

Fíjate en la progresión: primero instalas el vocabulario y mides el caso una vez, a mano (M1), después construyes la herramienta que formaliza esa medición (M2), después le das a esa herramienta datos reales en vez de un dataset de ejemplo (M3), después conviertes esos datos en una alerta que dispara por la razón correcta (M4), después construyes el marco de respuesta —roles, severidad, on-call— antes de necesitarlo (M5), después usas ese marco completo para operar el caso central de la guía, no volver a narrarlo (M6), después conviertes lo que aprendiste en un postmortem sin culpa y en el primer runbook real de Andes Cargo (M7), y cierras corriendo la máquina completa contra un incidente nuevo que nadie vio venir línea por línea (M8).

El mapa de este módulo: las 8 lecciones

#	Lección	Qué practicas
1	Introducción (esta)	El mapa completo, qué se hereda de las seis guías anteriores, la tesis de la guía
2	Qué es SRE (y qué no es)	La definición de Ben Treynor, citada; SRE frente a DevOps frente a operaciones tradicionales
3	Confiabilidad como feature, no como accidente	Por qué el 100% casi nunca es el objetivo correcto; el error budget como negociación
4	Manos a la obra: leyendo Andes Cargo como lo leería un SRE	Representativo: inventario `awslocal` reformulado como "qué puede fallar aquí"
5	Dos incidentes reales, dos preguntas distintas	El incidente Claude Code, ángulo nuevo; el outage de `us-east-1`, citado
6	Manos a la obra: el error budget que el incidente Claude Code se comió	Ejecutado: el primer cálculo real de la guía, a mano
7	El vocabulario que vas a usar toda la guía	SLI/SLO/SLA/error budget/toil/radio de explosión/on-call/postmortem, citados
8	Proyecto: la carta de confiabilidad de Andes Cargo	Ejecutado (el documento): `RELIABILITY-CHARTER.md`

Lo genuinamente nuevo de esta guía

Ningún módulo de esta guía declara un solo recurso HCL de negocio nuevo, ni modifica una sola política de seguridad o de costo ya escrita. El bucket sigue siendo andes-cargo-shipment-docs, la tabla sigue siendo Shipments, la función sigue siendo process-shipment-manifest. Lo nuevo, siempre en la capa de confiabilidad, nunca de negocio, siempre en inglés como convención de este ecosistema:

RELIABILITY-CHARTER.md (Módulo 1, esta lección) y SLO.md (Módulo 2) — los dos primeros documentos, el mismo rol estructural que THREAT-MODEL.md tuvo en cloud-security-and-guardrails-guide y COST-PROFILE.md en finops-and-cost-guardrails-guide.
scripts/error_budget_calculator.py y scripts/burn_rate_evaluator.py — los dos scripts $0 del Módulo 2 y el Módulo 4, reutilizados con datos reales en el Módulo 3 y en el capstone del Módulo 8.
observability/docker-compose.yml — Prometheus, Grafana, Alertmanager y Jaeger, construido en el Módulo 3.
observability/instrument_manifest_flow.py — el script de instrumentación OpenTelemetry del Módulo 3, que envía trazas del flujo upload → Lambda → DynamoDB a Jaeger.
observability.tf — nuevo, hermano de finops.tf (que ya declara su propia alarma de billing, sin tocarla), con una alarma real de CloudWatch sobre AWS/Lambda/Errors.
INCIDENT-RESPONSE-PLAN.md y oncall/schedule.py — el marco del Módulo 5: roles, severidad, y una rotación de on-call determinista, sin PagerDuty.
incidents/2026-02-26-claude-code-destroy/TIMELINE.md y .../POSTMORTEM.md — los dos entregables centrales de los Módulos 6 y 7: el incidente real, operado con el vocabulario y las herramientas de esta guía.
runbooks/manifest-processor-error-rate.md — el primer runbook real del Módulo 7, cada paso verificado contra LocalStack antes de escribirse.
.github/workflows/ci.yml sin cambios: esta guía no agrega un job de CI. Sus artefactos son operativos —SLO, on-call, postmortem, runbooks—, no de build/deploy, y por eso no hay un tercer carril que encadenar al pipeline. Es la diferencia honesta con cloud-security-and-guardrails-guide y finops-and-cost-guardrails-guide, declarada aquí desde el principio para que no esperes, al llegar al Módulo 8, un cambio al pipeline que esta guía no tiene razón de construir.

El compromiso de $0, y la honestidad exacta sobre qué corre de verdad

SRE es, por naturaleza, una disciplina que en el mundo real corre sobre tráfico de producción, facturas de PagerDuty y meses de datos históricos — ninguna de esas tres cosas existe en un laboratorio $0. Esta guía resuelve eso con la misma disciplina que las seis anteriores: nada se simula en prosa; si un comando aparece en una lección, corrió para escribirla, y todo lo que no corrió de verdad queda etiquetado en el momento exacto en que aparece, con su razón técnica.

Lo que corre de verdad, de punta a punta: la calculadora de error budget —100% Python, 100% determinista, sin ninguna herramienta externa—; Prometheus v3.13.2, Grafana OSS 13.1.3, Alertmanager 0.33.1 y Jaeger v2 v2.20.0 (nunca all-in-one, descontinuada desde el fin de vida de Jaeger v1 el 31 de diciembre de 2025), los cuatro probados de punta a punta en este entorno; y CloudWatch Logs, métricas y alarmas, confirmados en el plan Hobby de LocalStack —con las dos métricas nativas de Lambda (Invocations, Errors) que esta guía necesita para medir un SLI real.

Lo que queda representativo, con su razón exacta, siempre declarada al momento de aparecer: AWS X-Ray (ausente del plan Hobby, Ultimate-only); Amazon CloudWatch Application Signals (SLO Recommendations nativas, lanzadas en marzo de 2026, nombradas por contraste); AWS Systems Manager Incident Manager (cerrado a cuentas nuevas desde noviembre de 2025); PagerDuty/Opsgenie (SaaS sin capa $0). Un caso queda con resultado abierto, documentado tal cual salga: el intento de backup/restore de DynamoDB del Módulo 7, en el espíritu del mecanismo real que salvó los datos del incidente Claude Code.

También en este entorno específico de escritura —sin LOCALSTACK_AUTH_TOKEN exportado— el contenedor de LocalStack no arranca, el mismo límite que ya viste en las guías anteriores. La lección 4 de este módulo retoma esa misma honestidad para los comandos awslocal de inventario: la salida que vas a leer ahí es la que produciría cada comando contra la infraestructura ya aplicada, reconstruida campo por campo a partir de lo que las guías anteriores ya confirmaron corriendo de verdad — nunca inventada, siempre etiquetada.

Una regla dura que no comparten las guías hermanas: prohibido random/datetime.now() en cualquier bloque "Qué esperar" de esta guía, sin excepción declarada. Toda métrica que alimenta un SLI viene de una secuencia de invocaciones fija, escrita en el propio script.

Errores comunes

Asumir que este módulo ya construye la calculadora de error budget (de expectativa). Qué pasa: alguien termina la lección 8, con RELIABILITY-CHARTER.md escrito, y espera que ya exista un script Python corriendo, o un archivo SLO.md con números formales. Cómo detectarlo: si buscas en este módulo un archivo .py ejecutable. Cómo corregirlo: este módulo instala vocabulario y hace un cálculo manual, a mano, en la lección 6 —deliberadamente antes de la herramienta, no en vez de ella—, para que cuando la calculadora del Módulo 2 exista, entiendas exactamente qué automatiza. SLO.md y error_budget_calculator.py son del Módulo 2, no de este.

Confundir "confiable" con "nunca falla" (de intuición equivocada, la más común de toda esta guía). Qué pasa: alguien, al leer el título de esta lección, asume que el objetivo de esta guía es enseñar a construir un sistema que no falle nunca. Cómo detectarlo: si tu definición mental de "sistema confiable" no tiene ningún número asociado —ni un porcentaje, ni una ventana de tiempo—. Cómo corregirlo: la lección 3 desarrolla esto a fondo con la fuente exacta de Google SRE, pero el adelanto que vale la pena instalar ya: un sistema perfecto (100% de disponibilidad, para siempre) no es el objetivo de ningún equipo de SRE serio — es, literalmente, más caro de lo que vale, y esta guía te va a mostrar por qué con un número, no con una opinión.

Tratar el incidente Claude Code destroy como una anécdota que ya escuchaste tres veces y por eso puedes saltarte (de fatiga del caso). Qué pasa: alguien, al ver el nombre del incidente en el mapa de la lección 5, asume que esta guía lo vuelve a narrar de la misma forma que terraform-and-iac-guide o cloud-security-and-guardrails-guide ya lo hicieron, y decide saltarse esas dos lecciones. Cómo detectarlo: si tu plan es "ya sé cómo termina esta historia, no hace falta leerla de nuevo". Cómo corregirlo: ninguna de las tres guías anteriores midió el incidente con un error budget, ni lo operó a través de un ciclo de vida completo de respuesta con roles, severidad y postmortem. La lección 6 de este módulo es la primera vez, en todo el ecosistema, que ese incidente se convierte en un número: cuántas veces el presupuesto mensual completo se gastó en un solo evento.

Ejercicios

Ejercicio 1 — Explica, en tus propias palabras, la tesis central de esta guía. Sin usar todavía los términos técnicos que vas a formalizar en la lección 7 (SLI, SLO, error budget), describe en dos o tres frases por qué la infraestructura de Andes Cargo, ya segura y ya sostenible financieramente desde hace dos guías completas, podría de todas formas no ser confiable.

Ver solución

Una respuesta completa suena, más o menos, así: "Un pipeline seguro confirma que un cambio no abre el bucket al público ni borra Shipments sin control. Un pipeline sostenible confirma que ese cambio cabe en el presupuesto mensual. Ninguna de las dos garantías dice nada sobre qué tan rápido se entera alguien de que el sistema dejó de funcionar, cuánto tiempo de indisponibilidad es aceptable antes de que un cliente lo note, o qué hace el equipo cuando algo falla a las 3 AM. 'Seguro' y 'sostenible' son dos preguntas que ya se contestaron; 'confiable' es una tercera, medible con un número, que ninguna de las seis guías anteriores contestó todavía." La pieza clave: cada guardrail anterior midió una cosa distinta, y ninguna midió la confiabilidad operativa del sistema en producción.

Ejercicio 2 — Ubica los ocho entregables de esta guía, sin mirar hacia atrás. De memoria, nombra los ocho artefactos nuevos que esta guía completa va a agregar a andes-cargo-infra/, y en qué módulo aparece cada uno.

Ver solución

RELIABILITY-CHARTER.md (Módulo 1, este módulo); SLO.md + scripts/error_budget_calculator.py (Módulo 2); observability/docker-compose.yml + observability/instrument_manifest_flow.py (Módulo 3); scripts/burn_rate_evaluator.py + observability.tf (Módulo 4); INCIDENT-RESPONSE-PLAN.md + oncall/schedule.py (Módulo 5); incidents/2026-02-26-claude-code-destroy/TIMELINE.md (Módulo 6); .../POSTMORTEM.md + runbooks/manifest-processor-error-rate.md (Módulo 7); el repositorio completo, como pieza de portfolio (Módulo 8). Si recordaste al menos seis de los ocho sin mirar la tabla, tienes clara la progresión de la guía.

Ejercicio 3 — Explica por qué esta guía no agrega un job nuevo al pipeline de CI/CD. Un colega, familiarizado con cloud-security-and-guardrails-guide y finops-and-cost-guardrails-guide —cada una agregó su propio carril al ci.yml—, pregunta por qué esta guía, siendo la séptima del ecosistema, no hace lo mismo. Responde con la razón exacta.

Ver solución

Porque los dos gates anteriores evalúan cambios propuestos antes de que se apliquen —¿este plan es seguro?, ¿este plan cabe en el presupuesto?—, mientras que los artefactos de esta guía (SLO.md, INCIDENT-RESPONSE-PLAN.md, un postmortem, un runbook) son operativos: describen cómo el equipo mide y responde a lo que pasa después de que un cambio ya está en producción, no una condición que un pull request deba cumplir para fusionarse. No hay una regla tipo "el plan falla si el SLO no se cumple" que tenga sentido evaluar en un PR —el SLO se mide contra tráfico real, en el tiempo, no contra un archivo HCL propuesto—. Por eso esta guía no encadena un tercer carril: construye una capa distinta, que vive al lado del pipeline, no dentro de él.

Resumen y siguiente paso

En esta lección viste el mapa completo de los 8 módulos de esta guía, confirmaste qué se hereda sin repetirse de las seis guías anteriores del ecosistema (andes-cargo-infra/ completo, con su security gate y su cost gate ya encadenados), y qué es genuinamente nuevo: ocho artefactos de la capa de confiabilidad, ninguno de negocio, seguridad o costo. Instalaste la tesis central que gobierna el resto de la guía: "confiable" no es un estado, es una medición con un número, una ventana de tiempo y un presupuesto que se gasta. Y viste, de entrada, el compromiso de honestidad de esta guía: qué corre de verdad con Python/Prometheus/Grafana/Alertmanager/Jaeger/CloudWatch, y qué queda representativo con su razón técnica exacta.

Antes de avanzar deberías poder: nombrar los 8 módulos en orden y qué construye cada uno; explicar por qué este Módulo 1 no construye ninguna calculadora todavía; y explicar, en una frase, por qué "seguro" y "sostenible" no son lo mismo que "confiable".

La lección 2 arranca con el vocabulario formal: qué es SRE, citado directamente de quien lo definió por primera vez en Google, y por qué la distinción con DevOps y con las operaciones tradicionales importa más allá del marketing.

Recursos

aws-core-services-guide (NIEVA) — el prerequisito que deja los cuatro servicios core de Andes Cargo (S3, Lambda, DynamoDB, IAM) desplegados por primera vez.
aws-serverless-and-containers-guide (NIEVA) — el prerequisito que endurece process-shipment-manifest a nivel de producción (concurrencia, dead-letter queues).
terraform-and-iac-guide (NIEVA) — el prerequisito que deja andes-cargo-infra/ completo en HCL, y la fuente original, verificada, del incidente Claude Code destroy (su Módulo 8, lección 5).
cicd-and-gitops-on-aws-guide (NIEVA) — el prerequisito que deja el pipeline de GitHub Actions corriendo bajo act.
cloud-security-and-guardrails-guide (NIEVA) — el prerequisito que deja el security gate completo, y la primera lección de este ecosistema en preguntar "¿qué hubiera detenido esto?" sobre el mismo incidente (su Módulo 1, lección 6).
finops-and-cost-guardrails-guide (NIEVA) — el prerequisito que deja el cost gate completo, el punto exacto donde esta guía empieza.
Google SRE Book — Table of Contents — la fuente oficial completa que esta guía cita, lección por lección, empezando por la próxima.
src/paths/aws-cloud-ecosystem/VALIDACION.md — la auditoría de mercado que identificó el hueco CRITICA de SRE que esta guía cierra.

Siguiente →2. Qué es SRE (y qué no es)