En 08-02 el sistema de TechCorp quedó completo como código: seis servicios, un gateway, una librería y sus pruebas. Esta lección lo lleva a un clúster y lo opera. La primera mitad responde a "¿cómo levanto todo esto desde cero?": el repositorio techcorp/plataforma completo, el compose.yaml local con los seis servicios y toda la infraestructura, el orden de arranque en un clúster nuevo, el script que lo aplica, los Job de migración y la prueba de humo con un token de Keycloak. La segunda mitad responde a "¿y qué hago cada día?": un despliegue normal de servicio-pedidos de punta a punta, la campaña de Black Friday, un incidente en una DLQ paso a paso, la rotación de un secreto, la actualización de Node y una evolución de contrato aplicada a todo el sistema, más una tabla de operaciones frecuentes y el coste mensual aproximado.

No reexplicamos ningún YAML de 05-02 ni ningún código: cuando aparezca un Deployment, un ServiceMonitor o un ExternalSecret, remitiremos a la lección donde se escribió y mostraremos solo lo que cambia al pasar de un servicio a seis.

1. El repositorio techcorp/plataforma completo
2. compose.yaml: el sistema entero en un portátil
3. Orden de arranque en un clúster nuevo
4. scripts/desplegar-todo.sh y los Job de migración
5. Verificación y prueba de humo
6. Operación: un despliegue normal de servicio-pedidos
7. Operación: la campaña de Black Friday
8. Operación: un incidente en pagos.stock.dlq, paso a paso
9. Operación: rotar un secreto, actualizar Node y evolucionar un contrato
10. Runbook rápido de operaciones frecuentes
11. Coste mensual aproximado y cómo reducirlo

Es el repositorio del equipo de Plataforma y la fuente de verdad de producción (Argo CD lo lee, 05-03 §6). Todo lo que hemos ido dejando en él a lo largo del curso, ordenado:

Dos decisiones que sostienen el árbol: una base por servicio, un overlay por entorno (05-02 §12: la base de Inventario es la de Pedidos con nombres, puerto 3006 y su ScaledObject en lugar de HPA), y los terceros por Helm con values versionados aquí, nunca instalados a mano. Cuando el equipo de Pagos necesita un Secret nuevo, abre un PR contra este repositorio; nadie ejecuta kubectl create secret en producción.

El compose.yaml de 05-01 §8 tenía PostgreSQL, MongoDB, RabbitMQ, la semilla, las migraciones de Pedidos, Catálogo, Pedidos, el stub de Clientes y el gateway. Las adiciones para el sistema completo, resumidas (los servicios nuevos siguen exactamente el patrón de servicio-pedidos en 05-01: image + build, variables de la tabla de config.js de 08-02, depends_on con condiciones, stop_grace_period: 15s):

Con esto, docker compose up -d --wait levanta unos veinte contenedores (diecisiete en ejecución más las tareas de un solo uso) en unos 90 segundos en un portátil normal, y las cuatro E2E de 08-02 §9 pasan contra http://localhost:8080 con un token obtenido de http://localhost:8180. Es el entorno con el que el alumno puede reproducir todo el curso (08-04).

Sea un clúster kind (plataforma/local/kind.yaml, 05-02 §4) o uno gestionado, el orden importa: cada capa depende de la anterior, y varias piezas (ESO, cert-manager, KEDA, el operador de Prometheus) instalan CRDs que los manifiestos posteriores usan.

Sobre el paso 8: el orden "por la saga" no es estrictamente necesario —los servicios arrancan aunque falte un colaborador (/health/ready no comprueba a Catálogo ni a Clientes, 04-04 §9) y las colas duraderas guardan mensajes— pero desplegar primero los consumidores y al final Pedidos y el gateway evita que los primeros pedidos de la prueba de humo esperen a que alguien declare inventario.pedidos.

En dev y en un clúster de pruebas se aplica todo con un script; en producción los pasos 8-9 los hace Argo CD (app-of-apps.yaml), y el script solo se usa para la infraestructura de los pasos 1-7 (o Terraform/Helmfile, si Plataforma prefiere).

Cada servicio con base de datos lleva su Job de migraciones en la base/ (05-02 §6) con argocd.argoproj.io/hook: PreSync para producción (05-03 §6): servicio-pedidos-migraciones, servicio-inventario-migraciones, servicio-pagos-migraciones, servicio-notificaciones-migraciones, servicio-clientes-migraciones (Catálogo tiene servicio-catalogo-semilla solo en dev; Notificaciones sí tiene BD para envios). Todos ejecutan node scripts/migrar.js desde la imagen del servicio y son idempotentes, por eso el delete + apply es seguro. Y todos son expand-only (05-04 §3): el script nunca necesita "esperar a que ningún pod viejo quede" para aplicar una migración.

La prueba de humo es la E2E de 04-05 hecha a mano a través del Ingress, con un token de verdad. scripts/token-keycloak.sh obtiene uno para la usuaria de pruebas con password grant (activado solo en el cliente pruebas-e2e del realm de dev/staging; en producción no existe ese cliente, 07-01 ej. 1):

Y las tres comprobaciones de observabilidad, que son la razón de haber montado los módulos 6 y 7: (1) en Jaeger (kubectl -n observabilidad port-forward svc/jaeger-query 16686), buscar servicio=gateway, etiqueta pedidoId=$PED: una traza con los spans del gateway, Pedidos, Clientes, Catálogo, PostgreSQL, y —enlazados por links desde el traceparent del outbox (06-02 §6)— Inventario, Pagos (con el span de la pasarela) y Notificaciones; (2) en Grafana, panel "Saga de pedidos": pedidos_creados_total +1, saga_duracion_segundos con una observación de ~3 s, outbox_pendientes a 0 en los cuatro servicios con outbox; (3) en Loki, {namespace="techcorp"} | json | pedidoId="ped-…" devuelve las líneas de los seis servicios ordenadas por tiempo, con el mismo requestId en la parte síncrona.

Si el estado se queda en STOCK_RESERVADO, la tabla del apartado 10 dice dónde mirar (casi siempre: pagos.stock sin consumidor, o PASARELA_URL mal en el ConfigMap de Pagos).

Luis fusiona un PR que añade la cancelación por el cliente (ejercicio 1 de 08-02). Lo que ocurre, con cada pieza en su lección:

Total: unos 50 minutos de reloj, de los cuales unos 12 son máquina; el resto es la revisión humana y la observación del canary, y son deliberados. Frente al jueves noche de 01-05 (dos horas de despliegue, cuatro reversiones de doce), esto ocurre a las 11 de la mañana de un martes, once veces al día en el conjunto de servicios, y si el burn rate sube durante el canary, canary-weight: 0 deja el 100 % en la estable en segundos: MTTR de minutos sin que nadie haya escrito un kubectl a mano.

La campaña se prepara con una lista que Plataforma y los cuatro equipos repasan tres semanas antes (la primera versión se escribió para el Black Friday de 2025, 08-01 §3; hoy es un issue con plantilla en plataforma):

Lo que se ve el día D en un buen año (como 2025): Catálogo entre 6 y 16 réplicas siguiendo la curva de navegación; Inventario a 4-7 por longitud de inventario.pedidos; saga_duracion_segundos p95 en 4 s (la pasarela también va más lenta); presupuesto de error consumido en el día: 6 % del mensual. Y lo que la lista impide: un kubectl scale manual que Argo CD revierta a los tres minutos (05-03 §6, selfHeal: true), por eso el escalado de campaña también va por PR.

Un martes de septiembre de 2026, 15:20. Distinto de INC-2031 (mensaje venenoso por un bug): esta vez la causa es externa y las herramientas de 06-03/06-05 ya existen. Sigue la cronología como si fueras la persona de guardia:

1. 15:31 — Alerta DlqConMensajes{cola="pagos.stock.dlq"} (warning: 10 min con mensajes, 06-05 §12) llega al canal del equipo de Pagos; no despierta a nadie (no es critical), pero es horario laboral y la guardia la reconoce y abre #inc-2047-pagos-dlq.
2. 15:33 — Runbook comun/dlq: "¿cuántos, desde cuándo, qué tipo?". kubectl -n infra exec rabbitmq-0 -- rabbitmqctl list_queues name messages | grep dlq → pagos.stock.dlq 14. En la consola de RabbitMQ, los 14 son stock.reservado con x-intentos: 5: agotaron los reintentos, no son venenosos.
3. 15:36 — Loki: {app="servicio-pagos"} | json | nivel="error" | line_format "{{.eventoId}} {{.err.codigo}} {{.mensaje}}" → DEPENDENCIA_NO_DISPONIBLE pasarela: timeout desde las 15:12; CircuitoAbierto{dependencia="pasarela"} está también en warning desde las 15:15 (06-03 §4). Jaeger: el span POST pasarela/cobros con error=true y 5.000 ms exactos: la pasarela no responde, no rechaza.
4. 15:38 — Impacto: panel "Saga de pedidos": 41 pedidos en STOCK_RESERVADO con más de 5 minutos; el vigilante empezará a cancelarlos por TIMEOUT_PAGO a los 10 (06-03 §9). Severidad SEV2 (parte del flujo roto, sin workaround para el cliente); se avisa en #estado-plataforma: "desde las 15:12 los cobros no se completan por un problema del proveedor de pagos; los pedidos se están reteniendo; siguiente actualización 16:00".
5. 15:40 — Estabilizar antes que entender: la página de estado de la pasarela confirma incidente. Decisión de Pagos: subir temporalmente el límite del vigilante de 10 a 30 minutos (ConfigMap VIGILANTE_LIMITE_MIN de Pedidos + rollout restart; PR exprés en plataforma con la etiqueta incidente, para que Argo no lo revierta) y así no cancelar 41 pedidos con stock reservado por una caída de 20 minutos ajena. Las reservas caducan a los 15 min por expira_en… salvo que se suba también RESERVA_TTL_S; se sube a 2.400 s del mismo modo. Dos cambios de configuración, cero código.
6. 15:52 — La pasarela se recupera. El breaker pasa a semiabierto y cierra; los mensajes de pagos.stock.reintento (los que aún tenían intentos) se cobran solos en 2 minutos. Quedan los 14 de la DLQ.
7. 15:55 — Reprocesar: kubectl -n techcorp run reprocesar --rm -it --image=ghcr.io/techcorp/servicio-pagos:1.4.2 --env-from=secret/pagos-rabbitmq -- node scripts/reprocesarDlq.js --cola pagos.stock --max 50 (06-03 §8): 14 mensajes vuelven a la cola con x-intentos: 0 y x-reproceso; cobrarPedido los encuentra EN_CURSO (paso 1 de 08-02 §4) y consulta por clave de idempotencia antes de cobrar: 3 ya se habían cobrado en el primer intento (la pasarela cobró y el timeout llegó antes de la respuesta) y se marcan CAPTURADO sin cobrar dos veces; 11 se cobran ahora. pago.confirmado ×14, sagas cerradas.
8. 16:02 — Panel: 0 pedidos en STOCK_RESERVADO antiguos; se revierten los dos cambios de configuración (PR de vuelta); se cierra el incidente. Duración: 50 min desde el primer fallo, 31 desde la alerta; 0 pedidos cancelados, 0 cobros duplicados.
9. Postmortem breve (SEV2, 06-05 §10): causa externa; funcionó todo lo diseñado (reintentos, breaker, DLQ, alerta, runbook, idempotencia de la pasarela); acciones: (a) la alerta DlqConMensajes tardó 10 min por diseño, pero CircuitoAbierto saltó a los 3: añadir al runbook de CircuitoAbierto{pasarela} el paso "subir el vigilante"; (b) hacer VIGILANTE_LIMITE_MIN y RESERVA_TTL_S flags recargables en caliente (04-03 §7) para no reiniciar; (c) preguntar a la pasarela por su SLA. Y la pregunta fija: "¿qué alerta lo habría detectado antes?" —CircuitoAbierto ya lo hizo; lo que faltaba era el enlace entre esa alerta y la acción.

Compara con INC-2031 (40 min, 61 pedidos afectados, 38 cancelados): mismo síntoma ("la saga no avanza"), la mitad de impacto y ninguna acción destructiva, porque el sistema tenía ya reintentos diferidos, DLQ, alertas por síntoma, runbook y un script. Es exactamente para lo que se escribió 06-05.

Rotar pedidos-db. Es el procedimiento de 07-04 §4, ejecutado el primer lunes de cada semestre por Plataforma con el equipo dueño: (1) nueva contraseña de svc_pedidos en Vault (techcorp/prod/pedidos/db), con el usuario svc_pedidos_b para tener las dos válidas; (2) kubectl -n techcorp annotate externalsecret pedidos-db force-sync=$(date +%s) → el Secret cambia; (3) kubectl -n techcorp rollout restart deploy/servicio-pedidos (rolling maxUnavailable: 0, 05-04) y rollout status; (4) pedidos-migraciones no hace falta; (5) revocar la antigua y vigilar password authentication failed en Loki durante una hora. Quince minutos, sin ventana de mantenimiento; se repite para *-db y *-rabbitmq de los seis servicios en la misma mañana con un bucle en scripts/rotar-secretos.sh. La auditoria de quién rotó qué es el git log del PR y el audit log de Vault.

Node 20 → 22. Node 20 termina su mantenimiento en abril de 2026; la actualización se hace una vez en la plantilla y se propaga por la regla de Luis: (1) plantilla-servicio-node: FROM node:22-alpine en las dos etapas del Dockerfile (05-01 §3), engines.node: ">=22", @types/lint; (2) servicio-node-ci.yml@v2: actions/setup-node con node-version: 22 y una matriz temporal [20, 22] para que cada servicio compruebe ambas antes de cambiar; (3) @techcorp/comun-http se publica y prueba en 22 (05-03 §10); (4) cada equipo, cuando quiere dentro de un plazo (un mes), abre un PR en su servicio con dos líneas: uses: …/servicio-node-ci.yml@v2 y el FROM; CI, Testcontainers, pactos y staging validan; producción con la estrategia habitual (canary en Pedidos y Pagos, rolling en el resto); (5) al mes, @v1 se retira. Seis PRs de dos líneas en lugar de una migración coordinada; y si Notificaciones se retrasa una semana, nadie más espera.

v2 de productos con precio: { importe, moneda }. Es el cambio incompatible de 03-06 §10, ahora ejecutado de punta a punta:

Ningún paso corta nada: en cada momento conviven dos versiones del contrato, del evento y del esquema, y cada equipo despliega cuando quiere dentro del plazo. Es la misma disciplina que en el apartado 6, aplicada a un cambio que en el monolito habría sido "buscar precio en todo el repositorio y cruzar los dedos el jueves".

Cifras ficticias, orientativas, para un clúster gestionado de producción con 3.000 pedidos/día (sin campaña), redondeadas al alza. Sirven para tener orden de magnitud y para el argumento de FinOps de 08-04:

Frente al monolito (tres servidores grandes + PostgreSQL + diez servidores durante un mes al año ≈ 1.900 €/mes de media), es un 45 % más caro en infraestructura pura… y un 30 % más barato en campaña, y no incluye lo que se ahorra en horas de despliegue e incidentes (08-01 §10). Cómo reducirlo, por orden de retorno: (1) requests reales medidos con Prometheus (06-04 §4) y right-sizing de nodos: la mayoría de servicios de TechCorp piden 250 m de CPU y usan 60 m; (2) apagar staging fuera de horario (ya se hace) y usar minReplicaCount: 0 de KEDA para consumidores esporádicos como analítica; (3) muestreo de trazas al 10 % y retención de logs de 30 días (ya), sample_limit y revisión trimestral de cardinalidad (08-01 §11); (4) reservar capacidad de nodos base a un año (−30 %); (5) revisar si Redis, con la carga real, compensa frente a la caché HTTP del gateway; (6) no ahorrar en copias de seguridad, TLS ni réplicas de las bases de datos de Pedidos y Pagos.

• Instalar la infraestructura a mano y los servicios por GitOps. A los tres meses nadie sabe qué versión de RabbitMQ hay ni con qué values. Todo en k8s/infra/ y aplicado por script o por Argo, aunque sea Helm.
• Saltarse el orden de CRDs. Un ExternalSecret aplicado antes que ESO o un ServiceMonitor antes que el operador fallan con "no matches for kind": el script espera con --wait a cada operador antes de seguir.
• Prueba de humo sin token o con el token de admin. Debe usar un usuario con rol cliente y su clienteId: es la única forma de comprobar la regla del propietario y el 404 del pedido ajeno.
• Escalar a mano en producción con Argo CD en selfHeal. Lo revierte en minutos y, peor, en mitad de una campaña. Por PR, siempre.
• Reprocesar la DLQ antes de entender la causa. Si el mensaje es venenoso, vuelve a la DLQ y consume cinco reintentos; si la dependencia sigue caída, igual. Primero Loki/Jaeger, después el script.
• Rotar un secreto sin rollout restart y creer que ha funcionado porque kubectl get secret muestra el nuevo. Los pods viejos siguen con la contraseña antigua hasta que reinician (o hasta que se lee como fichero).
• Consejo: ejecuta desplegar-todo.sh dev en un clúster kind limpio una vez al mes. Si tarda más de 15 minutos o falla en algún paso, algo del árbol de plataforma se ha desactualizado; mejor descubrirlo un martes que en la recuperación ante desastre.

El clúster de producción se pierde por completo (región caída). Con el repositorio plataforma, las copias de las bases de datos gestionadas y las imágenes en ghcr.io, escribe la secuencia de recuperación en un clúster nuevo en otra región, indicando qué pasos del apartado 3 cambian, qué hay que restaurar antes de qué, qué datos podrían perderse (piensa en el outbox y las colas) y una estimación de tiempo. ¿Qué habría que tener preparado de antemano para que fuera de una hora en vez de un día?

Durante el canary al 10 % de servicio-pedidos 1.6.0 el burn rate está perfecto, pero al pasar al 100 % saga_duracion_segundos p95 sube de 3 a 40 s. Explica qué tipo de fallo no detecta un canary por peso de tráfico HTTP en un servicio que además consume eventos, cómo lo habrías detectado durante el canary (métricas y etiquetas concretas), y qué cambiarías en el procedimiento del apartado 6.

Marta pide bajar la factura mensual un 25 % sin tocar la disponibilidad de Pedidos ni de Pagos. Con la tabla del apartado 11, propón una lista concreta de medidas con su ahorro estimado y su riesgo, y di cuáles no aceptarías aunque ahorren.

Ejercicio 1. Secuencia: pasos 1-2 iguales (namespaces, operadores) en el clúster nuevo; paso 3 cambia: restaurar las bases de datos gestionadas desde copia (PostgreSQL de Pedidos y Pagos primero, con point-in-time recovery al instante más cercano; MongoDB del catálogo; RabbitMQ no se restaura: se crea vacío con definitions.json, y los mensajes en vuelo se pierden); paso 4 Keycloak desde su BD restaurada; 5-6 iguales; 7 los ExternalSecret apuntan al mismo Vault (que debe estar fuera de la región o replicado); 8-9 iguales, cambiando DNS de api.techcorp.example al nuevo balanceador y esperando el certificado. Datos en riesgo: los eventos que estaban en RabbitMQ sin consumir (colas duraderas de un clúster perdido) y los segundos entre la última copia y la caída. El outbox es la salvación parcial: al arrancar, los relays de los cuatro servicios republican todo lo que tenga publicado_en IS NULL, así que los eventos generados y no publicados se recuperan; los ya publicados y no consumidos se pierden → los pedidos en STOCK_RESERVADO o PENDIENTE sin avanzar los cierra el vigilante (TIMEOUT_PAGO) y la reconciliación de reservas (06-03 §9), y cobrarPedido consulta a la pasarela antes de cobrar (EN_CURSO), así que no hay cobros dobles. Tiempo: con todo a mano y probado, 2-4 horas; sin práctica, un día. Para una hora: clúster secundario "caliente" con la infraestructura de los pasos 1-7 ya aplicada y Argo CD apuntando al mismo repositorio (solo cambiar el destino), réplicas de las BD gestionadas en la otra región, Vault multirregión, y un ejercicio de recuperación trimestral (el consejo del apartado anterior).

Ejercicio 2. El canary por peso del Ingress reparte peticiones HTTP, pero las réplicas canary también consumen pedidos.saga en igualdad de condiciones con las estables (colas competidoras, 06-04 §9): al 10 % de tráfico HTTP, el canary ya procesa quizá el 33 % de los eventos (1 réplica de 3), y si su consumidor es lento (una consulta sin índice sobre pedidos añadida en 1.6.0), el efecto se diluye entre las estables y aparece "de golpe" al 100 %. Detección durante el canary: mirar métricas etiquetadas por version (la etiqueta service.version de 06-02, que las métricas de comun-http incluyen): histogram_quantile(0.95, sum by (le, version) (rate(saga_duracion_segundos_bucket[5m]))), la duración de procesarUnaVez por versión, pg_stat_statements o la latencia de las consultas del consumidor, y x-intentos/mensajes en pedidos.saga sin ack por pod. Cambio de procedimiento: añadir al apartado 6 un panel "canary vs estable" que compare también las métricas de consumidores y de base de datos por version, no solo RED HTTP; y, para servicios con consumidores, alargar el canary o hacer canary por réplica con una cola de prueba (o mesh, cuando llegue) —es una de las señales que 02-05 fijó para replantear la orquestación de la saga y que 05-05 dejó como argumento a favor del mesh.

Ejercicio 3. Medidas: (1) requests reales y nodos de 6 a 4 fuera de campaña (autoescalado sigue): −250 €, riesgo bajo si los PDB y el HPA están bien; (2) staging a 1/4 y solo en horario laboral con arranque bajo demanda: −200 €, riesgo bajo (la E2E de cd.yml tarda 5 min más si está apagado); (3) capacidad reservada un año para 4 nodos base: −180 €, riesgo de compromiso; (4) trazas al 5 % con muestreo por cola de errores al 100 %, logs de Catálogo a info (hoy debug en un overlay olvidado), 15 días de logs: −80 €, riesgo medio en depuración; (5) MongoDB a la instancia inferior con la caché de Redis (que ya absorbe el 85 %): −60 €, riesgo bajo, medir con k6; (6) KEDA a cero para analítica y bff-movil de noche: −30 €. Total ≈ −800 € (29 %). No aceptaría: quitar la réplica o las copias de PostgreSQL de Pedidos/Pagos, pasar RabbitMQ a un nodo, quitar TLS interno de RabbitMQ/BD, o reducir minReplicas de Pedidos/Pagos a 1 (un solo pod rompe el rolling sin cortes de 05-04 y el PDB): ahorran 100-200 € y ponen en juego el SLO del 99,9 % y la seguridad de 07-02.

El sistema de TechCorp ya no es solo código: vive en un clúster y se opera con procedimientos escritos. Hemos recorrido el repositorio techcorp/plataforma completo (bases y overlays por servicio, k8s/red/, k8s/infra/ con los values de Helm de RabbitMQ, PostgreSQL, MongoDB, Redis, Keycloak y la observabilidad, SLOs, Argo CD, dashboards, runbooks, pruebas E2E y de carga, el workflow reutilizable y SEGURIDAD.md), el compose.yaml que levanta los seis servicios con Keycloak, Jaeger, Prometheus, Grafana y Loki en un portátil, el orden de arranque de un clúster nuevo (namespaces → operadores y CRDs → datos y mensajería → identidad → observabilidad → red → secretos → servicios en el orden de la saga → Ingress) plasmado en desplegar-todo.sh con sus Job de migración idempotentes, y la verificación con una prueba de humo real —un token de Keycloak, un pedido a través del Ingress que llega a CONFIRMADO, su traza en Jaeger, su marca en el panel "Saga de pedidos" y sus logs en Loki—. Y hemos operado: un despliegue de servicio-pedidos de PR a 100 % pasando por CI, pactos, imagen firmada, staging, can-i-deploy, revisión humana, Argo CD y canary observado; la lista de Black Friday con overlay de campaña, KEDA, presupuesto de error y congelación; el incidente INC-2047 en pagos.stock.dlq resuelto con alerta, runbook, Loki, Jaeger, dos cambios de configuración y reprocesarDlq.js sin un cobro duplicado; la rotación de pedidos-db con ESO, la actualización a Node 22 propagada por plantilla y workflow reutilizable, y la v2 de productos con precio {importe, moneda} aplicada de punta a punta con expand/contract; más el runbook rápido y una factura mensual con sus palancas.

Con esto, la historia de TechCorp está completa: monolito, migración, implementación, despliegue y operación. Queda lo más valioso de un caso de estudio, que es destilarlo: qué hicimos, qué salió mal y qué haríamos distinto en cada dimensión, qué antipatrones aprendimos a reconocer, una lista consolidada de buenas prácticas con su lección de referencia, qué haría TechCorp en su fase 2 y cómo puedes aplicar todo esto a tu propio contexto. Es la última lección del curso.