Módulo 8: Capstone The Andes Cargo Reliability Package

6. Lo que esta guía dejó representativo, honestidad final

Descripción

Cada módulo de esta guía, en el momento exacto en que apareció una pieza que no corrió de verdad en este entorno, lo marcó con precisión: representativo, con la razón técnica exacta, nunca inventado. Esta lección reúne esas cinco piezas —X-Ray, CloudWatch Application Signals, AWS Systems Manager Incident Manager, PagerDuty/Opsgenie, y el resultado real del intento de backup de DynamoDB— en un solo lugar, no para repetir lo que cada lección ya explicó, sino para que quien termine esta guía tenga, en un vistazo, el mapa completo de qué es la columna vertebral ejecutada y qué es el contraste honesto con lo que un equipo real, con presupuesto real, adoptaría en su lugar.

Conexión con el módulo

Esta lección no descubre ninguna limitación nueva —cada una de las cinco piezas de abajo ya se declaró, con su fuente citada, en el módulo donde apareció por primera vez—. Su valor es de otro tipo: la misma honestidad que DISENO.md exigió desde el primer párrafo de esta guía ("nada se simula en prosa [...] los casos representativos [...] se etiquetan explícitamente en el momento exacto en que aparecen") se confirma aquí, una vez más, como una propiedad de la guía completa, no solo de cada lección aislada.

La columna vertebral, para contraste: lo que sí corrió de verdad

Antes de las cinco piezas representativas, vale la pena recordar, en una sola tabla, cuánto de esta guía no está en esta lista — la proporción real, no una impresión:

Pieza	Corrió de verdad, en este entorno
`scripts/error_budget_calculator.py`, `scripts/burn_rate_evaluator.py`	Sí — Python puro, sin ninguna dependencia externa
Prometheus `v3.13.2`, Grafana `13.1.3`, Alertmanager `v0.33.1`	Sí — `docker pull`, `docker compose up`, `/-/ready`, consultas PromQL reales
Jaeger v2 `v2.20.0` (`jaegertracing/jaeger`, no `all-in-one`)	Sí — UI y endpoint OTLP confirmados con `200`
`oncall/schedule.py`	Sí — determinista, verificado en dos corridas idénticas
`terraform validate`/`terraform plan` sobre `observability.tf`	Sí — sin errores de esquema, `Plan: 2 to add` confirmado
CloudWatch (Logs, métricas, alarmas) como servicio	Sí, confirmado en el plan Hobby de LocalStack — la limitación de esta guía es de entorno de escritura (sin `LOCALSTACK_AUTH_TOKEN`), no de cobertura del servicio
Los dos incidentes sintéticos/reales de los Módulos 6-8	Sí — la máquina completa, corrida dos veces, con evidencia literal en cada capa

Con eso como referencia, las cinco piezas que siguen son la minoría deliberada, no la regla.

1. AWS X-Ray — ausente del plan Hobby

Dónde apareció: Módulo 3, lección 5 (trazas con OpenTelemetry y Jaeger).

Razón técnica exacta: la documentación oficial de LocalStack es explícita — "Included in Plans: Ultimate" — X-Ray no está en el plan gratuito Hobby que esta guía usa en todo su laboratorio $0. La alternativa que esta guía construyó en su lugar, OpenTelemetry + Jaeger v2 local, enseña el mismo concepto (una traza distribuida, con spans que atraviesan upload → Lambda → DynamoDB) con una herramienta que sí corre de punta a punta, verificada en este entorno.

Qué le faltaría a un equipo real que eligiera X-Ray en vez de Jaeger: integración nativa con el resto de servicios AWS sin ningún exportador propio que mantener, y el contraste ya nombrado en el Módulo 3: incluso en el tier de pago, X-Ray no ofrece correlación completa de trace_id a través de todos los servicios.

2. CloudWatch Application Signals — SLO Recommendations, sin ejecutar

Dónde apareció: Módulo 4, lección 6.

Razón técnica exacta: lanzado en marzo de 2026, con capacidades que automatizan buena parte de lo que los Módulos 2 y 4 de esta guía construyeron a mano —recomendaciones de SLO basadas en 30 días de latencia P99 y tasa de error, alertas nativas de burn rate—. Nunca se ejecutó en esta guía porque depende de infraestructura de tipo APM (el mismo tipo de instrumentación de traza continua que X-Ray provee), sin ninguna confirmación de cobertura en ningún tier de LocalStack.

El contraste que vale la pena llevarse: un equipo con presupuesto de AWS real, hoy, tendría la opción legítima de no construir scripts/burn_rate_evaluator.py ni las reglas de alert_rules.yml a mano — Application Signals ya calcula SLO recomendados y burn rate de forma nativa. Esta guía construyó la versión manual a propósito: entender la matemática de Google SRE línea por línea es lo que hace que, más adelante, adoptar la versión gestionada sea una decisión informada, no una caja negra que nadie en el equipo sabría depurar si algo saliera mal.

3. AWS Systems Manager Incident Manager — cerrado a cuentas nuevas

Dónde apareció: nombrado en el Módulo 5, con la marca de servicio en declive activo.

Razón técnica exacta, citada textual: "AWS Systems Manager Incident Manager is no longer open to new customers. Existing customers can continue to use the service as normal." — cerrado a cuentas nuevas desde noviembre de 2025. No es una limitación de LocalStack ni una decisión de esta guía — es un hecho verificado sobre el propio servicio de AWS: un alumno que empieza en 2026 no podría adoptarlo aunque quisiera, sin importar el presupuesto.

Por qué esta guía construyó INCIDENT-RESPONSE-PLAN.md a mano en vez de asumir un servicio gestionado: el ciclo de vida, la matriz de severidad, los roles y la rotación de guardia de esta guía no dependen de ningún producto específico de AWS — son un marco de proceso, no una pieza de infraestructura. Esa independencia es, precisamente, lo que le da valor: funciona sin importar qué herramienta de gestión de incidentes adopte un equipo real, sea Incident Manager (mientras existió abierto), PagerDuty, Opsgenie, o ninguna.

4. PagerDuty / Opsgenie — SaaS, sin capa $0

Dónde aparecieron: Módulo 4, lección 7 (enrutamiento de alertas) y Módulo 5, lección 6 (el costo real del on-call).

Razón técnica exacta: ambos son productos comerciales, sin ningún nivel gratuito equivalente al resto del laboratorio de esta guía. Esta guía construyó el equivalente $0 en su lugar —un aws_sns_topic real (Módulo 4) y una rotación determinista en Python puro (oncall/schedule.py, Módulo 5)— y fue honesta, en ambos módulos, sobre qué le falta a ese equivalente: escalamiento automático entre niveles de guardia, aplicación móvil, integración nativa de chat.

La cita que vale la pena recordar aquí, otra vez: Hacker News, jamiemallers (Módulo 5, lección 6), sobre tratar el enrutamiento de on-call como una capa portable: "switching costs are higher than almost any other category". La decisión de esta guía de construir schedule.py en formato simple, exportable a JSON, no fue solo una limitación de presupuesto — fue, explícitamente, evitar ese encierro desde el primer día, incluso antes de que el equipo tuviera el presupuesto para pagar cualquiera de estas dos herramientas.

5. Backup/restore de DynamoDB — el resultado real, sin promesas

Dónde apareció: Módulo 7, lección 7, el action item #4 del postmortem del incidente Claude Code.

El resultado exacto, sin suavizar: una verificación de red directa confirmó, sin ambigüedad, la causa raíz de por qué awslocal dynamodb create-backup/restore-table-from-backup no completaron en este entorno de escritura específico —ningún proceso escuchando en el puerto 4566, el mismo límite de todo este ecosistema sin LOCALSTACK_AUTH_TOKEN—. Lo que esa lección no pudo confirmar, a diferencia del precedente de CloudTrail en cloud-security-and-guardrails-guide, es si la API específica de backup de DynamoDB tiene cobertura textualmente confirmada en el plan Hobby de LocalStack — el propio servicio DynamoDB sí está confirmado; las operaciones específicas de backup no tienen la misma claridad documental.

Por qué este resultado, incierto en un punto específico, sigue siendo un cierre válido del action item: el action item pedía "documentar el resultado real, sea cual sea" — no "confirmar que backup/restore funciona en LocalStack". La lección 7 del Módulo 7 documentó, campo por campo contra la referencia oficial de la API de AWS, la forma exacta que tendría una respuesta exitosa, sin inventar ningún ARN ni timestamp. Un resultado honesto sobre los límites de lo que se puede confirmar en este entorno específico es un resultado real, no un fracaso del ejercicio.

   LAS CINCO PIEZAS REPRESENTATIVAS -- MISMA CAUSA, DOS TIPOS DIFERENTES

   AUSENCIA DE COBERTURA GRATUITA              NATURALEZA DEL SERVICIO/PRODUCTO
   (limite tecnico de LocalStack Hobby)         (fuera del control de esta guia)
   ────────────────────────────────────         ─────────────────────────────────
   X-Ray (Ultimate-only)                        Incident Manager (cerrado a
   Application Signals (sin APM confirmada)      cuentas nuevas, decision de AWS)
   Backup/restore de DynamoDB (API sin           PagerDuty/Opsgenie (SaaS
   confirmacion textual explicita)               comercial, sin capa $0 posible)

Errores comunes

Leer esta lección como una lista de "lo que le faltó a esta guía", en vez de "lo que esta guía identificó con precisión y no fingió tener" (de confundir honestidad declarada con carencia). Qué pasa: alguien, al ver cinco piezas marcadas representativas, concluye que la guía completa es menos rigurosa de lo que aparenta. Cómo detectarlo: si tu resumen de esta guía empieza por las limitaciones en vez de por la tabla de la columna vertebral (Prometheus, Grafana, Alertmanager, Jaeger, la calculadora, la rotación, el HCL validado, los dos incidentes completos). Cómo corregirlo: la proporción real —siete piezas centrales ejecutadas de verdad frente a cinco representativas, cada una con una razón técnica citada, no inventada— es la misma disciplina de honestidad que cada guía de este ecosistema ya aplicó desde terraform-and-iac-guide. Marcar con precisión lo que no corrió es lo que hace confiable lo que sí corrió.

Asumir que todas las piezas representativas comparten la misma razón (falta de dinero) (de perder la distinción del diagrama de esta lección). Qué pasa: alguien explica las cinco piezas con una sola frase genérica ("son todas de pago, por eso no se ejecutaron"). Cómo detectarlo: si tu explicación de por qué Incident Manager está representativo menciona el costo, en vez de su cierre a cuentas nuevas. Cómo corregirlo: el diagrama de esta lección distingue dos categorías reales — piezas ausentes del plan gratuito de LocalStack (X-Ray, Application Signals, el caso incierto de DynamoDB backup) frente a piezas que son, por su propia naturaleza, imposibles de tener en una capa $0 sin importar la herramienta de laboratorio (Incident Manager está cerrado por decisión de AWS, no por LocalStack; PagerDuty/Opsgenie son SaaS comercial). Confundir las dos categorías pierde información real sobre qué cambiaría, y qué no, si esta guía tuviera un presupuesto distinto.

Tratar el resultado del backup/restore de DynamoDB como "fallido" en vez de "incierto en un punto específico, documentado con precisión" (repetido del mismo error que el Módulo 7, lección 7 ya nombró). Qué pasa: alguien resume esta guía diciendo que "el intento de backup no funcionó". Cómo detectarlo: si tu resumen de la pieza 5 usa la palabra "fracasó" o "no funcionó" sin la distinción entre "la causa de red está confirmada" y "la cobertura específica de la API no tiene confirmación textual". Cómo corregirlo: el Paso correspondiente del Módulo 7, lección 7 ya lo estableció — un resultado incierto, documentado con evidencia precisa sobre exactamente qué se puede y qué no se puede afirmar, cumple el action item tan bien como un éxito confirmado lo habría hecho.

Ejercicios

Ejercicio 1 — Clasifica cada una de las cinco piezas de esta lección en una de las dos categorías del diagrama ("ausencia de cobertura gratuita" o "naturaleza del servicio/producto"), sin mirar el diagrama.

Ver solución

Ausencia de cobertura gratuita en LocalStack: X-Ray (confirmado Ultimate-only), CloudWatch Application Signals (sin confirmación de cobertura en ningún tier), y el caso incierto de DynamoDB backup/restore (DynamoDB sí está en Hobby, la API específica de backup no tiene la misma claridad textual). Naturaleza del servicio/producto, fuera del control de LocalStack: AWS Systems Manager Incident Manager (cerrado a cuentas nuevas por decisión de AWS, no un límite de LocalStack) y PagerDuty/Opsgenie (SaaS comercial de terceros, nunca iban a tener una capa gratuita equivalente a un contenedor Docker).

Ejercicio 2 — Un compañero argumenta que esta guía debería haber "esperado" a que LocalStack agregue cobertura de X-Ray al plan Hobby, en vez de usar Jaeger. ¿Qué se habría perdido con esa decisión?

Ver solución

Esperar habría dejado el Módulo 3 sin ninguna forma de enseñar trazas distribuidas de verdad, indefinidamente, sujeto a una decisión de producto de LocalStack que esta guía no controla. La alternativa que esta guía eligió —OpenTelemetry + Jaeger v2, verificado corriendo de punta a punta en este entorno— enseña exactamente el mismo concepto (una traza con spans correlacionados) con una herramienta open source que cualquier alumno puede levantar hoy, sin depender de ningún cambio futuro de un tercero. Además, OpenTelemetry es, en sí mismo, el estándar hacia el que la industria se mueve independientemente de qué backend de trazas se use —Jaeger, X-Ray, o cualquier otro—, así que el conocimiento no queda atado a una sola herramienta.

Ejercicio 3 — Explica por qué la sección "La columna vertebral, para contraste" abre esta lección, en vez de que la lección empiece directamente con la lista de piezas representativas.

Ver solución

Abrir con la columna vertebral establece la proporción correcta antes de que el lector vea la lista de limitaciones — sin ese contexto, cinco piezas marcadas "representativo" podrían leerse como si dominaran la guía, cuando en realidad son la minoría frente a una columna vertebral de siete categorías de piezas centrales, cada una ejecutada de verdad y verificada con evidencia literal. Es la misma disciplina de honestidad, aplicada al orden de presentación: declarar primero qué sí corrió, con la misma precisión con la que después se declara qué no, evita que la ausencia de contexto distorsione la lectura de esta lección hacia una autocrítica desproporcionada.

Resumen y siguiente paso

Esta lección reunió, en un solo lugar, las cinco piezas que esta guía dejó representativas —X-Ray, CloudWatch Application Signals, AWS Systems Manager Incident Manager, PagerDuty/Opsgenie, y el resultado real del intento de backup de DynamoDB—, cada una con su razón técnica exacta, citada desde la lección donde apareció por primera vez, nunca inventada. Confirmaste, con la tabla de la columna vertebral, que estas cinco piezas son la minoría deliberada de una guía donde Prometheus, Grafana, Alertmanager, Jaeger, la calculadora de error budget, la rotación de guardia, y los dos incidentes completos —uno real, uno sintético— corrieron de verdad, con evidencia literal en cada capa.

Antes de avanzar deberías poder: nombrar las cinco piezas representativas y su razón técnica exacta sin mirar esta lección; distinguir cuáles están ausentes por un límite de LocalStack y cuáles por la naturaleza del propio servicio o producto; y defender por qué un resultado incierto, documentado con precisión, no es lo mismo que un resultado fallido.

La lección 7 mira hacia afuera de esta guía: qué partes del ecosistema completo de Andes Cargo —EKS, sistemas de IA en producción, observabilidad a fondo como disciplina propia— todavía esperan su propia guía, y por qué esta guía, deliberadamente, no las construye.

Recursos

LocalStack Docs — X-Ray y LocalStack Docs — CloudWatch — la fuente de la distinción entre lo que está y no está en el plan Hobby.
AWS — Amazon CloudWatch Application Signals adds new SLO capabilities — el anuncio citado en la pieza 2.
AWS Docs — What Is AWS Systems Manager Incident Manager? — la cita textual sobre el cierre a cuentas nuevas.
Este mismo repositorio, Módulo 7, lección 7 (07-hands-on-the-honest-backup-restore-attempt.md) — el desarrollo completo de la pieza 5.
Este mismo repositorio, DISENO.md — la tabla de honestidad y la regla dura de "nada se simula en prosa" que gobierna cada pieza de esta lección.

← Anterior5. Recorrido end-to-end: el runbook mitiga, el postmortem cierra Siguiente →7. Lo que Andes Cargo todavía necesita