Módulo 8: Capstone The Andes Cargo Reliability Package
7. Lo que Andes Cargo todavía necesita
Descripción
Esta guía cierra el hueco de SRE que VALIDACION.md marcó CRITICA para todo el ecosistema aws-cloud-ecosystem desde el Módulo 1 — la matemática de SLI/SLO/error budget, alerting de burn rate, el ciclo de vida completo de un incidente, on-call honesto, postmortems sin culpa. Pero Andes Cargo, como cualquier sistema real, no termina aquí: hay tres direcciones concretas donde el mismo vocabulario que construiste en esta guía se vuelve a necesitar, con un sistema distinto detrás, y esta lección las nombra con precisión —qué guía las cubre, y por qué esta guía, deliberadamente, no las construye—.
Conexión con el módulo
Cada frontera de esta lección ya estaba declarada en DISENO.md antes de que se escribiera ni una lección de esta guía —esta lección no descubre nada nuevo, confirma, al cierre, que cada frontera se respetó tal como se prometió. La lección 8, el proyecto final, va a citar esta lección como parte del portafolio: no solo qué construiste, también hacia dónde apunta lo que todavía falta.
Primera dirección: EKS y su propia disciplina SRE
Andes Cargo, en todo este ecosistema, no tiene contenedores — el SLI de esta guía mide un Lambda y una API, nunca un pod. Si Andes Cargo alguna vez migrara process-shipment-manifest, o cualquier servicio nuevo, a un clúster de Kubernetes, el vocabulario de esta guía (SLI, SLO, error budget, burn rate, postmortem sin culpa) seguiría aplicando sin cambios — pero las señales que alimentan ese vocabulario serían completamente distintas:
| Concepto de esta guía | Su equivalente en un mundo con EKS |
|---|---|
AWS/Lambda/Invocations, Errors (Módulo 3) | Readiness y liveness probes por pod, tasa de reinicio del pod |
| Una alarma sobre un Lambda específico (Módulo 4) | Un PodDisruptionBudget protegiendo contra interrupciones simultáneas |
El SLO de process-shipment-manifest (Módulo 2) | Un SLO por servicio dentro del clúster, potencialmente distinto por namespace |
observability.tf sobre un solo Lambda | Observabilidad a escala de clúster completo, con decenas o cientos de pods |
kubernetes-and-eks-in-production-guide es la guía del ecosistema que construye ese sistema y su propia disciplina de SRE — esta guía no la reemplaza ni la anticipa. La razón es simple y ya se declaró desde DISENO.md: Andes Cargo, en el estado que las seis guías hermanas y esta guía completa dejan, es serverless de punta a punta — introducir EKS aquí sería agregar un sistema de negocio nuevo, exactamente lo que DISENO.md prohibió desde el primer párrafo ("esta guía no agrega un componente de negocio nuevo a Andes Cargo").
Segunda dirección: SRE de sistemas de IA en producción
El mismo vocabulario —SLI, SLO, error budget, burn rate— se vuelve a aplicar, casi palabra por palabra, a un sistema de inferencia de IA en producción. La diferencia real no está en el marco, está en qué cuenta como una señal dorada:
MISMO VOCABULARIO, SEÑALES DISTINTAS
ESTA GUIA (process-shipment-manifest) SISTEMAS DE IA EN PRODUCCION
──────────────────────────────────── ──────────────────────────
Latencia: tiempo de ejecucion del Lambda Latencia: tiempo hasta el primer
token, tiempo total de inferencia
Errores: ValueError de validacion, Errores: alucinacion detectada,
timeout, invocacion regulada respuesta rechazada por un
clasificador de seguridad
Saturacion: ReservedConcurrentExecutions Saturacion: cola de un modelo
con capacidad de GPU limitada
(nuevo, sin equivalente en esta guia) Costo por token como un SLI
propio, no solo FinOps aparte
(nuevo, sin equivalente en esta guia) Drift de modelo: el propio
modelo empeora con el tiempo,
sin que nadie cambie ningun codigoDos de estas señales —costo por token como SLI, y drift de modelo— no tienen ningún equivalente en process-shipment-manifest: son preguntas que solo tienen sentido cuando el sistema que se mide es, en sí mismo, un modelo de lenguaje o un sistema de inferencia. genai-on-aws-production-guide es la guía de este ecosistema que construye esa aplicación de SRE a un sistema de IA real. Esta guía la nombra, exactamente aquí, como el siguiente lugar donde el vocabulario que acabas de terminar de construir se vuelve a necesitar — no la construye, porque Andes Cargo, en el alcance completo de las siete guías de negocio de este ecosistema, nunca tuvo un componente de inferencia de IA en producción.
Tercera dirección: observabilidad a fondo, como disciplina propia
DISENO.md declaró esta frontera con la mayor precisión de las tres, desde el primer módulo: el Módulo 3 de esta guía instrumentó lo mínimo indispensable para tener datos reales que alimentaran un SLI —nunca los tres pilares como disciplina completa—. Cada vez que una lección de esta guía tocó métricas, logs o trazas, la pregunta que la gobernó fue siempre "¿esto me deja calcular un SLI de verdad?", nunca "¿cómo se instrumenta una aplicación en general?".
Lo que esta guía nunca enseñó, y que sigue siendo terreno de monitoring-observability-guide:
- La diferencia completa entre un contador, un gauge, un histograma y un summary — esta guía usó ambos tipos donde hacía falta (
Counterpara invocaciones acumuladas,Gaugepara burn rate), pero nunca enseñó la taxonomía completa de tipos de métrica. - Cómo instrumentar una aplicación desde cero, decidiendo qué medir antes de tener ninguna pregunta de SRE en mente.
- Dashboards de Grafana a fondo — esta guía construyó un panel mínimo (Módulo 3, lección 6) para confirmar que el pipeline de datos funcionaba, nunca una disciplina completa de diseño de dashboards.
- El stack completo de telemetría de una organización con decenas de servicios, no solo uno.
El estado real de esa guía hermana, declarado con la misma honestidad que el resto de este ecosistema: al momento de diseñar esta guía, monitoring-observability-guide no tenía DISENO.md propio, y su contenido heredado (de AI Engineering) no cubría AWS/infraestructura en absoluto — VALIDACION.md ya la marcó ⚠️ DÉBIL por esa misma razón, señalando el mismo hueco de SLI/SLO/error budget que esta guía, precisamente, cerró. La resolución que este ecosistema adoptó: el hueco de SLI/SLO no vivía en la guía de observabilidad, vivía aquí — y ahora ya está cerrado. La disciplina de instrumentación de tres pilares, completa y a fondo, sigue siendo el trabajo pendiente de esa guía hermana, no de esta.
Lo que queda fuera del mapa, nombrado sin resolver
Dos huecos más, heredados de guías anteriores del ecosistema, que esta guía tampoco resuelve — nombrados aquí por completitud, no porque esta guía tuviera alguna vez la intención de cerrarlos:
- AWS multi-cuenta, Organizations, Control Tower — heredado como faltante
ALTAsin guía asignada desdecloud-security-and-guardrails-guide. Esta guía opera dentro de una sola cuenta (000000000000), la misma de todo el ecosistema, y nunca lo tocó. - Recuperación de desastres a escala de organización — Landing Zone con DR multi-región, runbooks de failover completos entre regiones. Fuera del alcance $0 y fuera del caso Andes Cargo (una sola región,
us-east-1). El único intento de recuperación que esta guía sí hizo —restaurar una tabla DynamoDB desde un backup, Módulo 7, lección 7— es el caso mínimo que el propio incidente Claude Code hizo relevante, deliberadamente acotado, nunca DR completo.
Errores comunes
Leer esta lección como una lista de "lo que esta guía debería haber construido" (de confundir un mapa hacia otras guías con una lista de tareas pendientes de esta misma guía). Qué pasa: alguien, al terminar esta lección, concluye que esta guía quedó incompleta porque no cubre EKS, IA en producción, ni instrumentación a fondo. Cómo detectarlo: si tu evaluación de esta guía la juzga por lo que esta lección nombra, en vez de por lo que las ocho lecciones anteriores de este módulo ya demostraron con evidencia ejecutada. Cómo corregirlo: cada una de las tres direcciones de esta lección tiene una frontera declarada desde DISENO.md, antes de que se escribiera una sola lección — no son lagunas descubiertas al final, son límites de alcance decididos con la misma precisión que gobernó cada decisión de esta guía. Una guía que "lo cubre todo" sin ninguna frontera declarada sería, en la práctica, una guía sin ningún foco real.
Asumir que "mismo vocabulario, señales distintas" significa que aprender SRE para sistemas de IA es trivial una vez que terminaste esta guía (de subestimar cuánto cambia realmente). Qué pasa: alguien, al ver la tabla de la segunda dirección, concluye que aplicar SRE a un sistema de IA es "lo mismo, con nombres distintos". Cómo detectarlo: si tu lectura de esa tabla se detiene en "el marco es el mismo" sin notar las dos filas sin equivalente (costo por token, drift de modelo). Cómo corregirlo: el marco —SLI, SLO, error budget, burn rate, postmortem sin culpa— sí generaliza, y ese es el valor real de haberlo aprendido aquí primero. Pero decidir qué es un buen SLI para un sistema de inferencia, con señales que ningún Lambda tradicional produce, es un trabajo genuinamente nuevo que genai-on-aws-production-guide tiene que construir desde cero — el marco transferido no resuelve automáticamente qué medir en un dominio distinto.
Tratar los dos huecos de la sección final ("Lo que queda fuera del mapa") como si fueran responsabilidad de esta guía, solo porque se mencionan aquí (de confundir "nombrado" con "adoptado"). Qué pasa: alguien, al leer sobre multi-cuenta/Organizations o DR a escala de organización, espera que esta guía —o alguna lección futura de esta misma guía— los resuelva. Cómo detectarlo: si tu expectativa después de leer esta sección es "¿dónde en esta guía se explica esto?". Cómo corregirlo: esta lección los nombra exactamente por la misma razón que nombra las tres direcciones principales —completar el mapa del ecosistema—, sin ninguna intención de resolverlos aquí. Ambos son huecos heredados de guías anteriores, sin guía asignada todavía en este ecosistema completo, no un trabajo pendiente de esta guía específica.
Ejercicios
Ejercicio 1 — Sin mirar la tabla de la segunda dirección, nombra las dos señales de un sistema de IA en producción que no tienen ningún equivalente directo en process-shipment-manifest.
Ver solución
Costo por token como SLI propio (distinto de una medición de FinOps aparte) y drift de modelo (el propio modelo empeorando con el tiempo sin que nadie cambie el código). Ninguna de las dos tiene sentido para un Lambda que valida y procesa manifiestos de texto — no hay ningún "token" que costee por unidad, y no hay ningún modelo que pueda degradarse con el tiempo sin una intervención humana directa. Estas dos señales son, precisamente, las que hacen que "SRE de sistemas de IA" sea un dominio genuinamente nuevo, no una aplicación mecánica del mismo marco.
Ejercicio 2 — Un compañero de equipo, después de terminar esta guía, propone empezar genai-on-aws-production-guide sin haber completado kubernetes-and-eks-in-production-guide primero, argumentando que "los sistemas de IA casi siempre corren en contenedores de todas formas". ¿Este razonamiento contradice algo que esta lección estableció?
Ver solución
No necesariamente — esta lección no establece ningún orden obligatorio entre las dos guías, solo las nombra como dos direcciones distintas hacia las que el mismo vocabulario se extiende. Es cierto que muchos sistemas de inferencia de IA en producción corren sobre Kubernetes en la práctica, así que tener ya la disciplina de SRE específica de EKS (readiness probes, PodDisruptionBudget) sería útil como base antes de enfrentar la capa adicional de señales específicas de IA (costo por token, drift de modelo). Pero esta lección, deliberadamente, no impone una secuencia — cada guía tiene su propio DISEÑO con sus propios prerequisitos declarados, y la decisión de qué guía tomar primero depende de qué sistema real esté construyendo quien elige, no de una regla fija de este módulo.
Ejercicio 3 — Explica por qué esta lección afirma que el hueco de SLI/SLO/error budget "no vivía en la guía de observabilidad, vivía aquí — y ahora ya está cerrado", en vez de simplemente decir que ambas guías comparten el mismo hueco.
Ver solución
La distinción importa porque, sin ella, alguien podría concluir que monitoring-observability-guide todavía necesita construir su propia versión de SLI/SLO/error budget para estar completa — una duplicación de esfuerzo que el propio DISENO.md de esta guía descartó explícitamente al diseñar la frontera entre ambas guías. Afirmar con precisión que el hueco "vivía aquí" declara, sin ambigüedad, cuál de las dos guías tiene la responsabilidad de esa pieza específica del vocabulario de SRE — dejando a monitoring-observability-guide con un alcance más acotado y más claro: instrumentación de los tres pilares como disciplina propia, citando esta guía para la matemática de SLI/SLO/error budget en vez de reconstruirla.
Resumen y siguiente paso
Esta lección trazó el mapa hacia las tres direcciones donde el vocabulario de esta guía se vuelve a necesitar, con un sistema distinto detrás: EKS y su propia disciplina SRE (kubernetes-and-eks-in-production-guide, señales de pod en vez de Lambda), sistemas de IA en producción (genai-on-aws-production-guide, mismo marco, señales nuevas como costo por token y drift de modelo), y observabilidad a fondo como disciplina de instrumentación completa (monitoring-observability-guide, la frontera declarada desde el primer módulo de esta guía). Nombraste, sin resolverlos, dos huecos más heredados del ecosistema completo —multi-cuenta/Organizations y DR a escala de organización— que ninguna guía existente cubre todavía.
Antes de avanzar deberías poder: explicar, para cada una de las tres direcciones, qué cambia y qué se mantiene del vocabulario de esta guía; nombrar las dos señales de un sistema de IA sin equivalente directo en Andes Cargo; y defender por qué el hueco de SLI/SLO/error budget se resolvió aquí, no en la guía de observabilidad.
La lección 8, el proyecto final de esta guía, cierra con el paquete completo de confiabilidad de Andes Cargo como pieza de portafolio — el inventario final de todo lo que construiste, verificado una última vez.
Recursos
- Este mismo repositorio,
DISENO.md— la sección "Qué enseña esta guía (y qué NO)", la fuente de cada frontera nombrada en esta lección. src/paths/aws-cloud-ecosystem/VALIDACION.md— el diagnóstico ⚠️ DÉBIL demonitoring-observability-guidey el hueco de SLI/SLO que esta guía cerró en su lugar.kubernetes-and-eks-in-production-guideygenai-on-aws-production-guide— las dos guías del ecosistema donde el vocabulario de esta guía se vuelve a aplicar, con sistemas distintos.- Google SRE Book — Table of Contents — la fuente original de un marco de SRE diseñado, desde el principio, para generalizar más allá de un solo tipo de sistema.