Esta es la última lección del curso. Las tres anteriores te dieron el fundamento (qué leer), el contexto (dónde está la gente) y el catálogo (qué herramientas existen y cuándo). Falta la pregunta que ninguna de las tres responde y que solo puedes contestar tú: ¿hacia dónde vas?

La lección tiene una parte incómoda y conviene empezar por ella: un inventario honesto de lo que sabes hacer y de lo que no. Los cursos suelen terminar felicitando al alumno, y esa felicitación es el peor regalo posible, porque produce gente que cree saber más de lo que sabe y descubre el hueco delante de un sistema en producción. Aquí vamos a hacer lo contrario: nombrar el hueco con precisión, porque un hueco nombrado es una ruta y un hueco ignorado es un incidente.

Después: cuatro direcciones en las que profundizar, un plan de 90 días verificable, certificaciones evaluadas sin promoción, cómo demostrar competencia sin certificados, cómo se ve una entrevista de estos perfiles, y cómo mantenerse al día sin quemarse.

1. Dónde estás ahora: el inventario honesto
2. Las cuatro direcciones
3. Un plan de 90 días
4. Certificaciones con criterio
5. Cómo demostrar competencia sin certificados
6. Cómo se ve una entrevista de estos perfiles
7. Mantenerse al día sin quemarse
8. Lo que no cambia
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

No es poco, y conviene reconocerlo con la misma precisión con la que luego reconoceremos lo que falta. Después del módulo 7 sabes:

• Diseñar y escribir un pipeline de CI completo: build reproducible, tres capas de pruebas, calidad estática con puerta, cachés, matriz y sharding.
• Producir un artefacto inmutable, versionarlo automáticamente, identificarlo por digest y promocionarlo entre entornos sin reconstruirlo — que es la disciplina que más pipelines rompe en la práctica.
• Automatizar un despliegue con puertas explícitas, autenticación sin credenciales de larga duración (OIDC), smoke test posterior e idempotencia.
• Elegir una estrategia de despliegue entre seis, argumentando el compromiso, y ejecutar un rollback en minutos por digest, incluso automático por métricas.
• Instrumentar el sistema con las cuatro señales de oro, definir un SLO con presupuesto de error y alertar por síntoma en vez de por causa.
• Endurecer la cadena de suministro: secretos, SAST, SCA, escaneo de imágenes e IaC, SBOM, firma y procedencia.
• Medir la entrega con las cuatro métricas DORA calculadas automáticamente, y usarlas para argumentar.
• Elegir herramienta con criterio en lugar de por moda, y —lo más importante— verificar por el lado negativo: provocar el fallo que una puerta debe detener antes de darla por buena.

Y una capacidad transversal que se aprende sin darse cuenta: saber justificar por escrito una decisión técnica con su alternativa descartada y su condición de revisión. El PIPELINE.md de la 07-06 es esa habilidad hecha artefacto, y es más rara en el mercado de lo que parece.

Con la misma honestidad. Nada de esto cabía en un curso, y todo aparece en cuanto el contexto crece.

Escala real. Todo lo que has construido opera un servicio con tráfico modesto. No has tocado: pipelines con cientos de repositorios y flotas de runners que hay que dimensionar y aislar, monorepos donde la ejecución selectiva es un grafo de dependencias y no un paths: en el YAML, tiempos de build que se miden en horas, sistemas de caché distribuida, o el problema —muy real— de que la factura del CI se convierta en una partida presupuestaria discutida en comité.

Multi-región y datos distribuidos. Desplegar en una región es un problema resuelto. Desplegar en cinco con datos replicados introduce clases enteras de problema que este curso no ha rozado: coherencia eventual, latencia de replicación, failover regional, despliegues por oleadas geográficas, y el hecho de que una migración de esquema como las de la 04-06 se vuelve mucho más difícil cuando hay réplicas de lectura en otro continente.

Cumplimiento normativo. Segregación de funciones, evidencias de auditoría, entornos con datos regulados, retención de logs, aprobaciones formales trazables, marcos como SOC 2 o ISO 27001, y el hecho incómodo de que el cumplimiento a veces contradice las prácticas de este curso: hay auditores que exigen que quien aprueba no sea quien desarrolla, lo que choca de frente con el despliegue continuo. Reconciliar eso es un oficio en sí mismo.

Organizaciones grandes. El obstáculo del despliegue continuo en una empresa de 500 personas casi nunca es técnico. Es que hay ocho equipos con calendarios distintos, un comité de cambios que se reúne los martes, un departamento de seguridad que no confía en desarrollo, y una base de código con veinte años de decisiones ajenas. La 05-04 rozó esto; vivirlo es otra cosa.

Bases de datos a fondo. Sabes hacer migraciones seguras. No sabes ajustar un plan de ejecución, diagnosticar contención de bloqueos bajo carga real, dimensionar conexiones ni operar una réplica. Y una parte desproporcionada de los incidentes graves de producción son, en el fondo, de base de datos.

Estar de guardia. La diferencia entre saber de fiabilidad y ser responsable de ella. Nada enseña tanto como que te despierte una alerta a las 3 de la madrugada, y nada se puede simular.

Lo que esto significa. No que el curso se quede corto: que has terminado el tramo que se puede aprender con material y empieza el que se aprende con sistemas y con años. La buena noticia es que el hueco es conocido y con nombre, que es exactamente lo que hace falta para decidir hacia dónde ir.

No hay una ruta única después de esto. Hay cuatro direcciones razonables, y la elección importa menos de lo que parece: las cuatro comparten fundamento y se puede cambiar. Lo que no funciona es intentar las cuatro a la vez.

Qué es. Construir y operar la infraestructura y las herramientas que usan otros equipos de desarrollo. Tu cliente no es el usuario final: son tus compañeros. El producto es el camino que va del commit a producción.

Qué aprender, en orden:

1. Kubernetes de verdad — no solo desplegar en él: redes, RBAC, controladores de admisión, operadores, dimensionado de recursos, por qué un pod se queda en Pending.
2. IaC avanzada — módulos reutilizables, gestión de estado a escala, entornos generados, pruebas de infraestructura, políticas como código (08-03).
3. Gestión de flotas de runners — autoescalado, aislamiento entre trabajos, coste por minuto, runners efímeros. Es el problema de escala que la 04-04 solo pudo esbozar.
4. GitOps y entrega progresiva — Argo CD o Flux, Rollouts o Flagger, para desplegar decenas de servicios sin tocarlos uno a uno.
5. Backstage y golden paths — y, más que la herramienta, la mentalidad de producto: entrevistar a tus usuarios internos, medir adopción, tratar la plataforma como algo que hay que hacer deseable, no obligatorio.

Señales de que es tu camino: te interesa más el sistema que la funcionalidad; disfrutas cuando otro equipo despliega gracias a algo que montaste; te frustra el trabajo repetido y piensas en abstraerlo; te sientes cómodo siendo soporte de otros.

Señales de que no lo es: necesitas ver el impacto en el usuario final; te agota que tu trabajo sea invisible cuando funciona; no toleras las interrupciones constantes, que en plataforma son el trabajo, no una distracción.

El riesgo del perfil: construir plataforma que nadie pide. La advertencia de Backstage en la 08-03 es el sintoma general de esta dirección.

Qué es. Aplicar ingeniería a la operación: que el sistema esté disponible, sea observable y se recupere rápido, con la fiabilidad tratada como objetivo negociable y medido en lugar de como aspiración.

Qué aprender, en orden:

1. SLO avanzados — elección de SLI que representen la experiencia real, ventanas múltiples, tasas de consumo (burn rate) y alertas basadas en ellas. El SRE Workbook de la 08-01 es la fuente.
2. Gestión de incidentes — mando de incidentes, roles, comunicación durante la crisis, post-mortems que produzcan cambios reales y no un documento archivado.
3. Teoría de colas y rendimiento — la ley de Little, saturación, por qué la latencia se dispara de forma no lineal al acercarse a la capacidad. Es lo que convierte "el sistema va lento" en un diagnóstico.
4. Capacity planning — proyección de crecimiento, pruebas de carga (k6), dimensionado y coste.
5. Ingeniería del caos — inyección deliberada de fallos en producción con hipótesis previa y radio de impacto acotado. Es verificar por el lado negativo llevado a la infraestructura: la misma costumbre del módulo 7, a otra escala.
6. Y lo menos técnico y más importante: eliminación de toil, guardias sostenibles, y la disciplina de no aceptar que el trabajo repetitivo sea normal.

Señales de que es tu camino: los incidentes te resultan interesantes en vez de solo estresantes; te gusta el trabajo detectivesco de correlacionar señales; te importa la experiencia real del usuario más que la elegancia interna; disfrutas midiendo.

Señales de que no lo es: las guardias te resultan intolerables (legítimo, y conviene saberlo antes); prefieres construir a diagnosticar; la ambigüedad bajo presión te bloquea.

El riesgo del perfil: convertirse en el equipo que dice que no, o en soporte de lujo. Un SRE que solo apaga fuegos ha fracasado; el trabajo es eliminar la clase de fuego.

Qué es. Garantizar que lo que llega a producción es lo que se cree, viene de donde se cree y no contiene lo que no debería. Es la dirección de mayor crecimiento reciente, empujada por incidentes públicos de gran impacto y por regulación creciente.

Qué aprender, en orden:

1. SLSA a fondo — los niveles, qué exige cada uno y qué se puede demostrar de verdad. Ya empezaste en la 07-05.
2. Firma, procedencia y verificación — Sigstore, atestaciones, políticas de admisión que rechacen artefactos no firmados por la identidad esperada. La 08-03 insistía: verificar identidad, no solo existencia de firma.
3. SBOM e inventario — CycloneDX y SPDX, Dependency-Track, y la capacidad de responder en minutos a "¿dónde está esta librería?".
4. Threat modeling del pipeline — que es el ejercicio más formativo de esta rama: ¿qué puede hacer alguien que compromete una acción de terceros? ¿un mantenedor de una dependencia? ¿un desarrollador con acceso de escritura? ¿el propio proveedor de CI? Modelar el pipeline como superficie de ataque cambia cómo lo diseñas.
5. Cumplimiento — traducir controles técnicos a evidencias que un auditor acepte, sin destruir la velocidad de entrega.

Señales de que es tu camino: piensas espontáneamente en cómo se rompería algo; te gusta el detalle riguroso; toleras bien el trabajo que consiste en convencer a otros de aceptar fricción.

Señales de que no lo es: te agota ser quien pone límites; te frustra que el éxito sea invisible (nada pasó) y el fracaso muy visible.

El riesgo del perfil: volverse el departamento del no. La seguridad que bloquea la entrega acaba rodeada, y un control rodeado no protege nada. La 04-03 lo decía: la seguridad tiene que ir dentro del pipeline, no encima.

Qué es. Quedarte en producto, escribiendo software, y ser la persona que eleva la práctica de entrega de tu equipo desde dentro. No hay título llamativo asociado —a veces "senior", a veces "tech lead"— y es la opción menos glamurosa y la más demandada.

Por qué es la más demandada. La inmensa mayoría de las empresas del mundo no tienen ni equipo de plataforma ni SRE ni especialista en cadena de suministro. Tienen entre cinco y treinta desarrolladores y un producto. Lo que necesitan no es un especialista: es alguien que escriba buen código de producto y además sepa por qué el pipeline hace lo que hace, sepa arreglarlo cuando se rompe y sepa argumentar por qué merece la pena mantenerlo. Ese perfil es escaso porque la gente que aprende esto tiende a irse a los perfiles con nombre más atractivo.

Qué aprender, en orden:

1. Diseño y pruebas — Feathers, Freeman y Pryce, Fowler (08-01). Tu ventaja competitiva es escribir código que se puede entregar con frecuencia: desacoplado, con costuras, cubierto por pruebas que verifican de verdad.
2. Bases de datos — el hueco más rentable del apartado 1.2. Migraciones, índices, planes de ejecución, contención. Es donde están los incidentes caros.
3. Arquitectura para la entrega — compatibilidad hacia atrás, feature flags como práctica de diseño (03-05), expand and contract (04-06), y cuándo no trocear (05-03).
4. Comunicación e influencia — la habilidad decisiva de esta rama. Convencer a Diego con números y no con principios. The Phoenix Project para que otros lo lean; Accelerate para tener los datos.
5. Mantener el pipeline del equipo — sin equipo de plataforma, alguien tiene que hacerlo bien. Ese eres tú, y ya sabes.

Señales de que es tu camino: te gusta escribir producto y ver el impacto; disfrutas enseñando a compañeros; te motiva que el equipo entero mejore más que ser tú el experto.

Señales de que no lo es: necesitas especialización profunda; te frustra que tu contribución de entrega no tenga reconocimiento formal —y a menudo no lo tiene—.

Consejo para quien dude: empieza aquí. Es la dirección con menos riesgo, la que mejor conserva las opciones abiertas y la que da el contexto de producto que hace mejores a los otros tres perfiles. Casi todos los buenos ingenieros de plataforma y SRE que conocerás vienen de haber escrito producto primero.

Consolidar lo aprendido importa más que empezar algo nuevo. En doce semanas, sin dejar tu trabajo, con entregables verificables: si no se puede enseñar a alguien, no cuenta.

Objetivo: que lo del módulo 7 quede sólido y aplicado a algo real.

Por qué la semana 3 importa más de lo que parece. Sin línea base, dentro de tres meses no podrás demostrar nada. Y definir qué cuentas exactamente como "despliegue" y como "fallo" es la mitad del valor del ejercicio.

Objetivo: elegir una de las cuatro direcciones y avanzar de verdad, no en cuatro a la vez.

Ejemplos concretos de entregable de la semana 6-7 según dirección: plataforma → un workflow reutilizable usado por dos repositorios; SRE → un SLO con alerta de burn rate que se ha disparado al menos una vez de verdad; cadena de suministro → verificación de firma con identidad que bloquea el despliegue de una imagen no firmada; producto → una migración con expand and contract desplegada sin ventana de mantenimiento.

Objetivo: convertir lo aprendido en evidencia visible, que es lo que lo hace útil profesionalmente.

La semana 11 es la que más gente se salta y la que más rinde. Explicar algo obliga a entenderlo, y produce visibilidad. Una charla interna de 20 minutos sobre "cómo montamos el pipeline y qué aprendimos" cambia cómo te ve tu organización más que cualquier certificado.

Si vas retrasado, no aceleres: recorta el alcance. Un pipeline pequeño terminado, medido y documentado vale más que uno ambicioso a medias. Es la misma regla que la 08-01 daba para leer.

Tres funciones legítimas, y ninguna es "demostrar que sabes":

1. Filtro de recursos humanos. En procesos con muchos candidatos y cribado automático, un certificado pasa filtros. Es su función más real y la menos noble. Importa más cuanto más grande y burocrática es la organización, y en consultoras, donde a veces son requisito contractual con el cliente.
2. Ruta de estudio estructurada. El temario oficial es un índice razonable de lo que hay que saber, y la fecha del examen es un compromiso que combate la procrastinación. Este beneficio es real incluso si no te presentas.
3. Señal en mercados concretos. En algunos países, sectores y para trabajo con administración pública, pesan de verdad.

Lo que no son: prueba de competencia. Todo el mundo en el sector sabe que hay gente certificada que no sabe operar nada, y gente sin un solo certificado que sostiene sistemas críticos. Un entrevistador competente no te contrata por el certificado; como mucho, te da una conversación.

• Examen exclusivamente tipo test sobre memorizar nombres de servicios. Mide capacidad de memorización a corto plazo. Las prácticas (CKA, CKS) valen mucho más porque no se pueden aprobar sin saber hacer.
• Certifica una herramienta que solo usa quien la vende. Su valor está atado a la salud comercial de un producto.
• No la pide nadie en las ofertas de tu mercado. Comprobación de diez minutos: busca 30 ofertas del puesto que quieres y cuenta cuántas la mencionan. Si es cero, tienes tu respuesta.
• Caduca en un año y renovarla cuesta como sacarla. Suscripción disfrazada de credencial.
• Es de una plataforma de cursos, no de quien fabrica la tecnología. Los "certificados de finalización" de cursos online no son certificaciones y en un currículum ocupan sitio sin aportar señal. (Incluido el de este curso: lo que vale es el repositorio que has construido, no el diploma.)
• La sacas para evitar la parte difícil. Si estudias una certificación porque estudiar es más cómodo que meter tu pipeline en producción y sufrirlo, estás sustituyendo aprendizaje por su apariencia. Es el fallo más común y el más caro.

Regla práctica de decisión: una certificación merece la pena si (a) su temario coincide con lo que ibas a estudiar de todos modos, (b) el examen es práctico o al menos aplicado, y (c) aparece en las ofertas de tu mercado real. Si cumple las tres, adelante. Si cumple solo (a), estudia el temario y no pagues el examen.

Lo que un buen entrevistador quiere ver es evidencia de decisiones, no de conocimientos. Y ahí tienes ventaja, porque el módulo 7 te dejó exactamente eso.

1. El repositorio del proyecto final. Público, con un README que explique qué es y cómo ejecutarlo. Un pipeline completo, funcionando, con historial de commits reales. Vale más que cualquier lista de tecnologías, porque es verificable en cinco minutos.

2. El PIPELINE.md. Es tu mejor activo y el más raro. Un documento que dice, decisión por decisión: qué se eligió, qué se descartó, por qué, y qué condición obligaría a revisarlo. Casi nadie tiene algo así, y demuestra la habilidad que separa a un senior de un junior: razonar sobre compromisos con restricciones. Si en una entrevista solo puedes enseñar una cosa, enseña esto.

3. El POSTMORTEM.md. Demuestra que tu sistema falló y aguantó. Cualquiera enseña un pipeline en verde; enseñar uno que se puso en rojo por el motivo correcto y se recuperó en minutos es otra categoría. Y demuestra la costumbre de verificar por el lado negativo.

4. Los números. "Pasamos de 1,5 despliegues por semana a 12, y de 68 horas de lead time a 3,5" es una frase que cambia una entrevista. No porque los números sean espectaculares, sino porque demuestra que mides, que es lo que casi nadie hace.

5. Contribuciones públicas. Aunque sean pequeñas (08-02). Un PR de documentación aceptado en un proyecto conocido demuestra que sabes trabajar con el proceso de otros: leer un CONTRIBUTING.md, aceptar revisión, iterar.

6. Charlas y artículos. Una charla interna cuenta. Un artículo técnico en español, donde hay mucho menos contenido de calidad, tiene alcance desproporcionado.

7. Cómo hablas de tus fracasos. El indicador más fiable de todos. Quien puede contar con precisión qué salió mal, por qué, qué aprendió y qué cambió después, ha operado sistemas de verdad. Quien solo tiene éxitos, o no ha operado nada o no está siendo sincero.

Rara vez son de algoritmos. Suelen tener tres partes: conversación técnica sobre experiencia, diseño de un sistema o pipeline, y a veces un ejercicio práctico o de depuración. Lo que se evalúa no es si sabes la respuesta, sino cómo razonas cuando falta información.

Ocho preguntas reales y qué busca el entrevistador:

1. "Cuéntame cómo va un cambio desde que alguien lo escribe hasta que está en producción, en tu último proyecto."

Busca: si conoces el flujo completo o solo tu trozo, y si mencionas espontáneamente las puertas y sus motivos. Una buena respuesta menciona qué pasa cuando algo falla en cada etapa. Es la 04-01 entera.

2. "¿Por qué no deberías reconstruir la imagen al promocionar de staging a producción?"

Busca: si entiendes la inmutabilidad del artefacto o repites una regla. La respuesta completa incluye que una reconstrucción puede resolver dependencias distintas, que el digest ya no es el verificado y que pierdes la trazabilidad entre lo probado y lo desplegado. Es la 02-06.

3. "Tienes 200 despliegues al mes y un 15 % de tasa de fallo de cambios. ¿Por dónde empiezas?"

Busca: si empiezas por diagnosticar o por proponer soluciones. La buena respuesta empieza preguntando: ¿qué tipo de fallo?, ¿en qué etapa se detecta?, ¿cuánto se tarda en revertir? Si el rollback es rápido, un 15 % duele menos que si es lento. Quien responde "añadiría más pruebas" sin preguntar nada, falla.

4. "¿Cómo desplegarías un cambio que rompe la compatibilidad del esquema de base de datos, sin ventana de mantenimiento?"

Busca: expand and contract (04-06). Y sobre todo, si mencionas que el despliegue va en varias fases y en varios días, que el código nuevo debe tolerar el esquema viejo, y qué haces con el backfill y con los bloqueos en una tabla grande. Es la pregunta que más separa niveles.

5. "¿Cuál es la diferencia entre entrega continua y despliegue continuo, y cuál recomendarías aquí?"

Busca: precisión conceptual (03-01) y, sobre todo, que no des una respuesta automática. La buena empieza con "depende de qué haya al otro lado": un producto con clientes empresariales y ventanas contractuales no es un SaaS interno. Responder "despliegue continuo siempre" es la señal de alarma de la 08-02 aplicada a ti.

6. "Tu pipeline tarda 40 minutos y el equipo se queja. ¿Qué haces?"

Busca: método antes que soluciones. Primero medir dónde se va el tiempo, después separar camino crítico de lo demás, y solo entonces cachés, paralelización, sharding o ejecución selectiva (04-04). La respuesta incompleta más frecuente es proponer optimizaciones sin medir. La excelente añade: "y comprobaría que no estamos quitando verificaciones para ir más rápido" — el verde falso.

7. "¿Cómo gestionas los secretos en el pipeline?"

Busca: si mencionas no tener secretos (OIDC, roles) antes de hablar de dónde guardarlos. Después: mínimo privilegio, rotación, enmascarado en logs y qué haces si uno se filtra —rotar primero, borrar después (04-03, 08-02)—. Mencionar OIDC sin que te lo pregunten es una señal muy positiva.

8. "Cuéntame un incidente de producción del que fueras responsable."

Busca: honestidad, cadena causal en vez de culpable único, y qué cambió después. La mejor respuesta incluye lo que se intentó y no funcionó, y termina con una mejora concreta y verificable. Quien dice "nunca he tenido incidentes" pierde la pregunta: o no ha operado nada, o no se enteró.

Lo transversal. En todas, el entrevistador evalúa lo mismo: si distingues lo que sabes de lo que supones, si preguntas por el contexto antes de responder, y si mencionas contrapartidas sin que te las pidan. Son exactamente los marcadores del buen consejo de la 08-02. Ahora los aplicas tú.

El ciclo del hype. Toda tecnología nueva recorre el mismo arco: aparición, entusiasmo desproporcionado, desilusión cuando se descubren las aristas, y —si sobrevive— productividad estable con documentación decente. La mayor parte del contenido que verás corresponde a la fase de entusiasmo, escrito por gente que lleva tres semanas con la herramienta y ninguna en producción.

La consecuencia práctica: llegar tarde a una herramienta buena cuesta muy poco. La aprenderás cuando tenga mejor documentación, más ejemplos y menos aristas. Llegar pronto a una mala cuesta una migración, y las migraciones se pagan en años.

Qué seguir:

• La documentación y las notas de versión de lo que usas en producción. No negociable.
• Los avisos de seguridad de tus dependencias directas.
• Una fuente de profundidad semanal (el plan de la 08-01).
• Un espacio de comunidad donde participes de verdad (08-02).

Qué ignorar:

• Anuncios de herramientas que resuelven problemas que no tienes.
• Comparativas escritas por quien vende una de las opciones.
• Contenido que promete que "X ha muerto". X no ha muerto; hay bancos ejecutando COBOL.
• Cualquier cosa que produzca ansiedad sin producir una acción concreta.

La regla del descarte: si llevas seis meses viendo un nombre y nunca ha resuelto un problema tuyo, bórralo del radar. Si importa de verdad, volverá.

Y la idea central: los fundamentos duran y las herramientas no. Lo que has aprendido en este curso sobre lotes pequeños, retroalimentación rápida, artefactos inmutables, compatibilidad hacia atrás, presupuesto de error y verificar por el lado negativo seguirá siendo cierto cuando GitHub Actions se llame de otra forma. Jenkins, Travis, CircleCI, GitLab, Actions: cinco herramientas para las mismas seis prácticas de la 02-01. Quien aprendió las prácticas cambió de herramienta en dos semanas. Quien aprendió solo la herramienta empezó de cero cada vez.

Invierte en fundamentos a razón de diez a uno frente a herramientas. Y cuando dudes de si algo es fundamento o moda, aplica el filtro del tiempo: ¿esto era verdad hace diez años y lo será dentro de diez?

Los principios invariantes del curso, en una lista que puedes releer dentro de cinco años con cualquier herramienta:

1. Integra pronto y en lotes pequeños. El tamaño del lote es la variable que más influye en el riesgo. Todo lo demás es consecuencia.
2. Si el pipeline está rojo, arreglarlo es la prioridad. Un pipeline roto que se tolera deja de ser un pipeline y pasa a ser decoración.
3. Construye el artefacto una vez y promociona ese mismo artefacto. Si reconstruyes, no has probado lo que despliegas.
4. Automatiza lo repetitivo; deja el juicio a las personas. Las puertas automáticas para lo verificable, las aprobaciones para lo que exige contexto.
5. La retroalimentación rápida vale más que la exhaustiva. Una prueba en 2 minutos que detecta el 80 % supera a una de 2 horas que detecta el 95 %.
6. Poder revertir importa más que no equivocarse. El objetivo no es el despliegue perfecto: es que el fallo sea barato.
7. Mide lo que quieres mejorar, y mide tu propia tendencia, no la de una encuesta.
8. La fiabilidad es un objetivo negociable. El 100 % es el número equivocado; el presupuesto de error convierte una discusión de opiniones en una decisión.
9. La seguridad va dentro del pipeline, no encima. Un control que estorba se rodea, y un control rodeado no protege.
10. Documenta el porqué, no el cómo. El código dice qué hace; solo tú puedes decir qué descartaste y bajo qué condición se revisa.
11. Los fallos son de sistema, no de personas. Un post-mortem con culpable garantiza que el siguiente incidente se oculte.
12. Verifica por el lado negativo. Cualquiera comprueba que una puerta deja pasar lo bueno; comprobar que detiene lo malo exige fabricar lo malo.

Ninguno de estos doce menciona una herramienta. Ninguno caducará antes que tu carrera.

• Elegir dirección por el salario o por el prestigio del título. Las cuatro pagan bien y la diferencia entre ellas es menor que la diferencia entre hacerlo bien y hacerlo mal. Elige por las señales del apartado 2, que describen qué te va a resultar sostenible durante años.
• Intentar las cuatro a la vez. Produce conocimiento superficial en todas. Elige una para 6-12 meses; las otras siguen ahí y el fundamento es común.
• Coleccionar certificaciones como sustituto de la experiencia. Se detecta en una entrevista en dos preguntas. Es la forma cómoda de evitar la parte difícil, que es meter algo en producción y sufrirlo.
• Saltarse la línea base. Sin medir el punto de partida no podrás demostrar mejora, y demostrar mejora es lo que te da margen para seguir invirtiendo.
• Esperar a "estar preparado" para dar una charla o escribir. Nadie se siente preparado. El nivel adecuado es el de alguien que resolvió el problema hace tres meses: recuerdas dónde estaban las dificultades, cosa que el experto ya olvidó.
• No pedir la responsabilidad. Si quieres operar sistemas, pide entrar en la rotación de guardias. Si quieres plataforma, ofrécete a mantener el pipeline del equipo. La experiencia rara vez se ofrece sola; se pide.
• Consejo: escribe el plan y ponle fechas. Un plan sin fecha es un deseo. Revísalo cada tres meses y permítete cambiarlo con motivo escrito.
• Consejo: enseña lo que acabas de aprender. Es el multiplicador más barato: fija el conocimiento, expone los huecos y te hace visible.
• Consejo: guarda tu propio registro de decisiones profesionales, con el mismo formato del PIPELINE.md: qué elegiste, qué descartaste, qué condición te haría cambiar. Sirve igual para una carrera que para un pipeline.

Escribe tu propia decisión de dirección, en una página, con esta estructura:

1. Qué me ha resultado más interesante del curso, con lecciones concretas (no "el módulo 3", sino "la parte de la 03-06 sobre por qué alertar por síntoma").
2. Qué me ha resultado tedioso o me ha costado, con la misma concreción.
3. La dirección elegida y las tres señales del apartado 2 que reconozco en mí.
4. La señal de alarma: qué de esa dirección me preocupa y cómo lo comprobaría antes de comprometerme un año.
5. El primer paso concreto, esta semana.

Si trabajas mejor con un caso ajeno, hazlo para Nuria (frontend/QA en Reservalia, se ocupó de las pruebas E2E y del panel de Grafana de la 07-04, disfrutó midiendo, le agotan las tareas de infraestructura).

Un compañero con dos años de experiencia, que acaba este curso, te escribe:

"He decidido sacarme CKA, Terraform Associate y AWS DevOps Professional este año. Con las tres seguro que me sale algo mejor. Empiezo por AWS que es la más valorada, ¿no?"

Escribe tu respuesta. Debe incluir: qué está bien de su planteamiento, qué está mal, qué le propones concretamente (con orden y motivo), y qué haría más por su carrera que las tres certificaciones juntas. Justifica con el criterio del apartado 4, no con opinión.

Elige tres de las ocho preguntas del apartado 6 y escribe tu respuesta real, como si estuvieras en la entrevista, basada en lo que has construido en el módulo 7. Después, para cada una, anota qué le falta a tu respuesta y qué tendrías que haber vivido para poder darla completa. Ese segundo apartado es el ejercicio de verdad: es tu plan de aprendizaje en forma de huecos concretos.

Solución 1

No hay respuesta correcta; hay respuestas honestas y respuestas complacientes. Ejemplo, para Nuria:

1. Lo más interesante. La 03-06, en concreto la idea de alertar por síntoma y no por causa: fue el momento en que entendió por qué su equipo tenía 40 alertas que nadie miraba. Y la 07-04, montar el panel y ver el SLO consumirse en tiempo real: la primera vez que una métrica le contó una historia.

2. Lo tedioso. La 03-03, Terraform. Entendió el concepto, ejecutó los pasos, y no disfrutó ni un minuto. También el dimensionado de infraestructura de la 04-04: le resultó ajeno.

3. Dirección: SRE / fiabilidad. Tres señales del apartado 2 que reconoce: los incidentes le resultan interesantes en vez de solo estresantes (en el laboratorio de la 07-04, romper el endpoint y perseguir el efecto en las métricas fue lo que más disfrutó); le importa la experiencia real del usuario, que es de donde viene su perfil de QA; disfruta midiendo.

4. La señal de alarma: las guardias. Nunca ha estado de guardia y no sabe cómo lleva que la despierten. Es el factor que más gente subestima al elegir esta dirección, y el más difícil de revertir una vez comprometida. Cómo lo comprueba antes de comprometerse un año: pide entrar como segunda persona en la rotación de guardias durante dos meses —acompañando, sin ser responsable—. Es la prueba más barata y directa posible, y la información que da no se puede obtener leyendo.

5. Primer paso esta semana. Revisar el SLO que definió en la 07-04 y preguntarse si el SLI mide de verdad la experiencia del usuario o solo si el servidor responde. Y empezar el capítulo de SLO del SRE Workbook (08-01) con esa pregunta escrita.

Lo que hace buena esta respuesta: que el punto 2 sea sincero. Quien escribe "todo me pareció interesante" no ha hecho el ejercicio. Y que el punto 4 tenga una comprobación barata y reversible en lugar de una decisión irreversible.

Solución 2

Qué está bien. Tiene iniciativa, ha elegido tres certificaciones legítimas de tecnologías reales y no de productos marginales, y se ha puesto un plazo. Eso ya lo distingue de la mayoría.

Qué está mal, y son cuatro cosas:

1. El orden está invertido. Empezar por AWS DevOps Professional con dos años de experiencia es la peor decisión del plan. Los exámenes professional asumen experiencia operativa amplia; sin ella, la única vía de aprobar es la memorización masiva, que se olvida en meses y no deja capacidad. El orden razonable es Terraform Associate (3-6 semanas, transversal, asequible, y le da IaC que sirve en las cuatro direcciones), luego CKA si de verdad va a tocar Kubernetes, y AWS Professional más adelante o nunca, según su trabajo real.
2. "Con las tres seguro que me sale algo mejor" es una hipótesis sin comprobar, y comprobarla cuesta diez minutos: que busque 30 ofertas del puesto que quiere en su mercado y cuente cuántas piden cada una. Probablemente descubra que Terraform y Kubernetes aparecen mucho, y AWS Professional bastante menos de lo que cree.
3. "La más valorada" es una afirmación sin contexto, la señal de alarma de la 08-02. ¿Valorada por quién? En consultoras AWS partner, mucho; en producto, bastante menos que enseñar un sistema que funciona.
4. Y el problema de fondo: tres certificaciones en un año son entre seis y nueve meses de estudio. Eso es casi todo su tiempo de aprendizaje del año dedicado a temarios en vez de a sistemas. Con dos años de experiencia, lo que le falta no es temario: es haber operado cosas.

Qué le propongo. Una certificación este año: Terraform Associate, porque su temario coincide con lo que le conviene estudiar de todos modos, es asequible en tiempo y es transversal a las cuatro direcciones. Y después decidir CKA con un dato en la mano: si en seis meses ha tocado Kubernetes en el trabajo, adelante; si no, es un certificado sobre algo que no usa y se le olvidará.

Qué haría más por su carrera que las tres juntas. El plan de 90 días del apartado 3: aplicar el pipeline a un proyecto real, medir la línea base DORA, escribir el PIPELINE.md, romper algo a propósito, documentar el post-mortem, volver a medir y contarlo en una charla interna. Eso son doce semanas, no nueve meses, y produce algo que puede enseñar. En una entrevista, "aquí está el repositorio, este es el documento de decisiones y estos son los números de antes y después" abre una conversación que un certificado no abre. El certificado, como mucho, le consigue la entrevista; lo otro se la gana.

Y un matiz honesto: si trabaja o quiere trabajar en una consultora donde las certificaciones son requisito contractual con clientes, el cálculo cambia y AWS Professional puede tener sentido antes. Que compruebe eso primero, porque es el único caso en que su plan original sería defendible.

Solución 3

Ejemplo con dos de las ocho preguntas.

Pregunta 4 — migración que rompe compatibilidad, sin ventana de mantenimiento.

Respuesta basada en el módulo 7: "En tres fases separadas en el tiempo, con el patrón expand and contract. Fase de expansión: añado la columna nueva permitiendo nulos, sin tocar la antigua, y despliego código que escribe en ambas y lee de la antigua. Migración de datos: backfill por lotes, con pausas, para no bloquear la tabla ni saturar la base de datos. Fase de contracción, días después y en un despliegue distinto: el código pasa a leer de la nueva, y solo cuando llevo tiempo estable elimino la columna antigua. La clave es que en ningún momento hay una versión del código incompatible con el esquema vigente, porque durante el despliegue rolling conviven versiones."

Qué le falta. No he hecho esto sobre una tabla de millones de filas con tráfico real. No sé cuánto tarda un backfill así, ni cómo se comporta el bloqueo de un ALTER TABLE bajo carga en PostgreSQL, ni cómo se coordina si hay réplicas de lectura con retraso. Tampoco he tenido que revertir a mitad de una migración, que es el caso difícil.

Qué tendría que vivir. Una migración real sobre una tabla grande en producción, con métricas delante. Y probarla antes sobre una copia de datos de volumen realista, que es lo que la 04-06 recomendaba y en el laboratorio no llegué a hacer con volumen de verdad.

Pregunta 8 — un incidente del que fueras responsable.

Respuesta basada en el módulo 7: "En el laboratorio de la 07-04 provoqué un fallo a propósito: introduje una regresión de latencia en el endpoint de disponibilidad y observé cómo el SLO empezaba a consumir presupuesto de error. La alerta por síntoma se disparó a los pocos minutos —no por CPU, sino porque la latencia p95 se salió del objetivo—, ejecuté el rollback.yml por digest y el servicio se recuperó en unos minutos. Lo documenté con la plantilla de post-mortem sin culpables, y la conclusión fue que la alerta funcionó pero llegó tarde para el presupuesto de error que teníamos definido."

Qué le falta —y esto hay que decirlo en la entrevista, no ocultarlo—. Que fue un fallo provocado por mí, en un entorno controlado, sin usuarios reales afectados, sin nadie preguntando por qué no funciona y sin la presión de decidir con información incompleta a las 3 de la madrugada. Es un ensayo, no un incidente.

Qué tendría que vivir. Estar en la rotación de guardias de un sistema con usuarios. La diferencia no es técnica: es que en un incidente real no sabes qué ha cambiado, hay varias hipótesis a la vez, alguien te está preguntando cuánto falta, y la decisión de revertir se toma con datos incompletos.

Por qué esta forma de responder funciona en una entrevista. Un entrevistador competente valora más "lo hice en un entorno controlado y esto es lo que le falta a mi experiencia" que una respuesta inflada. Distinguir lo que sabes de lo que supones es exactamente el marcador que el apartado 6 señalaba como transversal, y decirlo tú antes de que te lo detecten juega a tu favor.

En la 01-04 conociste a Marta, Diego y Nuria, y a un equipo que desplegaba 1,5 veces por semana, tardaba 68 horas desde que un cambio estaba escrito hasta que llegaba a producción, rompía producción en el 6,5 % de los despliegues y tardaba 68 minutos en recuperarse cuando eso pasaba. Los viernes no se desplegaba. Nadie recordaba qué versión estaba antes. Y desplegar era, para todo el mundo, un acontecimiento que se preparaba con antelación y se vivía con la tensión de quien espera que algo salga mal.

Cuatro módulos después, ese mismo equipo desplegaba 12 veces por semana, con 3,5 horas de lead time, un 3,8 % de fallo y 9 minutos de recuperación. Los mismos tres, el mismo producto, la misma nube. Lo que cambió no fue la gente ni la tecnología: fue cómo estaba organizado el camino a producción.

Y Marta lo había dicho al principio, cuando todavía sonaba a provocación: "prefiero desplegar diez veces al día y que cada despliegue sea aburrido".

Ahora ya sabes que no era una frase ingeniosa. Era una tesis técnica completa, y todo el curso ha sido su demostración. Un despliegue aburrido es un despliegue pequeño —porque el lote es pequeño, hay poco que pueda salir mal—. Es un despliegue verificado —porque las puertas ya comprobaron lo comprobable, y alguien se aseguró de que detienen lo malo provocándolo—. Es un despliegue reversible —porque el artefacto es inmutable, está identificado por su contenido y volver atrás es una operación de minutos, no una reconstrucción—. Y es un despliegue observado —porque si algo se degrada, lo dirá una alerta sobre un síntoma que le importa a un usuario, no un humano mirando gráficas por si acaso—.

Hacer aburrido lo que daba miedo no es quitarle importancia. Es lo contrario: es haberle dedicado tanta ingeniería que ya no requiere heroísmo. El miedo al despliegue nunca fue irracional —desplegar a mano, sin pruebas, sin poder volver atrás y sin saber si funcionó debería dar miedo—. Lo que has aprendido es a eliminar las condiciones que lo justificaban.

Queda una última cosa, y es la que devuelve la responsabilidad a quien corresponde.

El pipeline no es el objetivo. Es fácil olvidarlo después de siete módulos construyéndolo. Nadie ha pagado nunca por un pipeline. Los usuarios de Reservalia no saben que existe y no les importaría si lo supieran: lo que les importa es poder reservar una cita, que el sistema no se caiga un sábado por la mañana y que sus datos estén a salvo. Todo lo que has construido —las tres capas de pruebas, el digest, la firma, el SLO, el rollback en cuatro minutos— existe para una sola cosa: entregar valor con seguridad y sin heroísmos.

Cuando dentro de un tiempo te enfrentes a la decisión de si añadir otra puerta, otra herramienta o otra fase, la pregunta no será "¿es esto una buena práctica?". Será la del apartado 12 de la 08-03: ¿qué problema medido resuelve, y para quién? Si la respuesta es "para nadie, pero queda mejor", ya sabes qué hacer.

Tienes el fundamento para leer con criterio, la comunidad para preguntar cuando el problema sea de contexto, el catálogo para reconocer qué existe y qué te va a costar, y una dirección para los próximos meses. Tienes también, y esto importa más, un repositorio con un sistema que funciona, un documento que explica por qué es así, y la prueba de que falló y aguantó.

Lo que hagas con todo eso ya no depende del curso.

Que tus despliegues sean aburridos.