Aquesta és l'última lliçó del curs. Les tres anteriors et van donar el fonament (què llegir), el context (on és la gent) i el catàleg (quines eines existeixen i quan). Falta la pregunta que cap de les tres no respon i que només pots contestar tu: cap on vas?

La lliçó té una part incòmoda i convé començar per aquí: un inventari honest del que saps fer i del que no. Els cursos solen acabar felicitant l'alumne, i aquesta felicitació és el pitjor regal possible, perquè produeix gent que creu saber més del que sap i descobreix el buit davant d'un sistema en producció. Aquí farem el contrari: anomenar el buit amb precisió, perquè un buit anomenat és un itinerari i un buit ignorat és un incident.

Després: quatre direccions en què aprofundir, un pla de 90 dies verificable, certificacions avaluades sense promoció, com demostrar competència sense certificats, com es veu una entrevista d'aquests perfils, i com mantenir-se al dia sense cremar-se.

1. On ets ara: l'inventari honest
2. Les quatre direccions
3. Un pla de 90 dies
4. Certificacions amb criteri
5. Com demostrar competència sense certificats
6. Com es veu una entrevista d'aquests perfils
7. Mantenir-se al dia sense cremar-se
8. El que no canvia
9. Errors Comuns i Consells
10. Exercicis
11. Conclusió

No és poc, i convé reconèixer-ho amb la mateixa precisió amb què després reconeixerem el que falta. Després del mòdul 7 saps:

• Dissenyar i escriure un pipeline de CI complet: build reproduïble, tres capes de proves, qualitat estàtica amb porta, memòries cau, matriu i sharding.
• Produir un artefacte immutable, versionar-lo automàticament, identificar-lo per digest i promocionar-lo entre entorns sense reconstruir-lo — que és la disciplina que més pipelines trenca a la pràctica.
• Automatitzar un desplegament amb portes explícites, autenticació sense credencials de llarga durada (OIDC), smoke test posterior i idempotència.
• Triar una estratègia de desplegament entre sis, argumentant el compromís, i executar un rollback en minuts per digest, fins i tot automàtic per mètriques.
• Instrumentar el sistema amb les quatre senyals d'or, definir un SLO amb pressupost d'error i alertar per símptoma en comptes de per causa.
• Enfortir la cadena de subministrament: secrets, SAST, SCA, escaneig d'imatges i IaC, SBOM, signatura i procedència.
• Mesurar el lliurament amb les quatre mètriques DORA calculades automàticament, i fer-les servir per argumentar.
• Triar eina amb criteri en lloc de per moda, i —el més important— verificar pel costat negatiu: provocar la fallada que una porta ha d'aturar abans de donar-la per bona.

I una capacitat transversal que s'aprèn sense adonar-se'n: saber justificar per escrit una decisió tècnica amb la seva alternativa descartada i la seva condició de revisió. El PIPELINE.md de la 07-06 és aquesta habilitat feta artefacte, i és més rara al mercat del que sembla.

Amb la mateixa honestedat. Res d'això no cabia en un curs, i tot apareix tan bon punt el context creix.

Escala real. Tot el que has construït opera un servei amb trànsit modest. No has tocat: pipelines amb centenars de repositoris i flotes de runners que cal dimensionar i aïllar, monorepos on l'execució selectiva és un graf de dependencies i no un paths: al YAML, temps de build que es mesuren en hores, sistemes de memòria cau distribuïda, o el problema —molt real— que la factura del CI es converteixi en una partida pressupostària discutida en comitè.

Multiregió i dades distribuïdes. Desplegar en una regió és un problema resolt. Desplegar en cinc amb dades replicades introdueix classes senceres de problema que aquest curs no ha fregat: coherència eventual, latència de replicació, failover regional, desplegaments per onades geogràfiques, i el fet que una migració d'esquema com les de la 04-06 es torna molt més difícil quan hi ha rèpliques de lectura en un altre continent.

Compliment normatiu. Segregació de funcions, evidències d'auditoria, entorns amb dades regulades, retenció de logs, aprovacions formals traçables, marcs com SOC 2 o ISO 27001, i el fet incòmode que el compliment de vegades contradiu les pràctiques d'aquest curs: hi ha auditors que exigeixen que qui aprova no sigui qui desenvolupa, cosa que xoca de ple amb el desplegament continu. Reconciliar això és un ofici en si mateix.

Organitzacions grans. L'obstacle del desplegament continu en una empresa de 500 persones gairebé mai no és tècnic. És que hi ha vuit equips amb calendaris diferents, un comitè de canvis que es reuneix els dimarts, un departament de seguretat que no confia en desenvolupament, i una base de codi amb vint anys de decisions alienes. La 05-04 ho va fregar; viure-ho és una altra cosa.

Bases de dades a fons. Saps fer migracions segures. No saps ajustar un pla d'execució, diagnosticar contenció de bloquejos sota càrrega real, dimensionar connexions ni operar una rèplica. I una part desproporcionada dels incidents greus de producció són, al capdavall, de base de dades.

Estar de guàrdia. La diferència entre saber de fiabilitat i ser-ne responsable. Res no ensenya tant com que et desperti una alerta a les 3 de la matinada, i res no es pot simular.

Què significa això. No que el curs es quedi curt: que has acabat el tram que es pot aprendre amb material i comença el que s'aprèn amb sistemes i amb anys. La bona notícia és que el buit és conegut i amb nom, que és exactament el que cal per decidir cap on anar.

No hi ha un itinerari únic després d'això. Hi ha quatre direccions raonables, i l'elecció importa menys del que sembla: totes quatre comparteixen fonament i es pot canviar. El que no funciona és intentar les quatre alhora.

Què és. Construir i operar la infraestructura i les eines que fan servir altres equips de desenvolupament. El teu client no és l'usuari final: són els teus companys. El producte és el camí que va del commit a producció.

Què aprendre, en ordre:

1. Kubernetes de debò — no només desplegar-hi: xarxes, RBAC, controladors d'admissió, operadors, dimensionament de recursos, per què un pod es queda en Pending.
2. IaC avançada — mòduls reutilitzables, gestió d'estat a escala, entorns generats, proves d'infraestructura, polítiques com a codi (08-03).
3. Gestió de flotes de runners — autoescalat, aïllament entre treballs, cost per minut, runners efímers. És el problema d'escala que la 04-04 només va poder esbossar.
4. GitOps i lliurament progressiu — Argo CD o Flux, Rollouts o Flagger, per desplegar desenes de serveis sense tocar-los un a un.
5. Backstage i golden paths — i, més que l'eina, la mentalitat de producte: entrevistar els teus usuaris interns, mesurar adopció, tractar la plataforma com una cosa que cal fer desitjable, no obligatòria.

Senyals que és el teu camí: t'interessa més el sistema que la funcionalitat; gaudeixes quan un altre equip desplega gràcies a alguna cosa que vas muntar; et frustra la feina repetida i penses a abstreure-la; et sents còmode sent suport d'altres.

Senyals que no ho és: necessites veure l'impacte en l'usuari final; t'esgota que la teva feina sigui invisible quan funciona; no toleres les interrupcions constants, que en plataforma són la feina, no una distracció.

El risc del perfil: construir plataforma que ningú no demana. L'advertiment de Backstage a la 08-03 és el símptoma general d'aquesta direcció.

Què és. Aplicar enginyeria a l'operació: que el sistema estigui disponible, sigui observable i es recuperi ràpid, amb la fiabilitat tractada com a objectiu negociable i mesurat en lloc de com a aspiració.

Què aprendre, en ordre:

1. SLO avançats — elecció d'SLI que representin l'experiència real, finestres múltiples, taxes de consum (burn rate) i alertes basades en elles. L'SRE Workbook de la 08-01 és la font.
2. Gestió d'incidents — comandament d'incidents, rols, comunicació durant la crisi, post-mortems que produeixin canvis reals i no un document arxivat.
3. Teoria de cues i rendiment — la llei de Little, saturació, per què la latència es dispara de manera no lineal en acostar-se a la capacitat. És el que converteix «el sistema va lent» en un diagnòstic.
4. Capacity planning — projecció de creixement, proves de càrrega (k6), dimensionament i cost.
5. Enginyeria del caos — injecció deliberada de fallades en producció amb hipòtesi prèvia i radi d'impacte acotat. És verificar pel costat negatiu portat a la infraestructura: el mateix costum del mòdul 7, a una altra escala.
6. I el menys tècnic i més important: eliminació de toil, guàrdies sostenibles, i la disciplina de no acceptar que la feina repetitiva sigui normal.

Senyals que és el teu camí: els incidents et resulten interessants en comptes de només estressants; t'agrada la feina detectivesca de correlacionar senyals; t'importa l'experiència real de l'usuari més que l'elegància interna; gaudeixes mesurant.

Senyals que no ho és: les guàrdies et resulten intolerables (legítim, i convé saber-ho abans); prefereixes construir a diagnosticar; l'ambigüitat sota pressió et bloqueja.

El risc del perfil: convertir-se en l'equip que diu que no, o en suport de luxe. Un SRE que només apaga focs ha fracassat; la feina és eliminar la classe de foc.

Què és. Garantir que el que arriba a producció és el que es creu, ve d'on es creu i no conté el que no hauria. És la direcció de més creixement recent, empesa per incidents públics de gran impacte i per regulació creixent.

Què aprendre, en ordre:

1. SLSA a fons — els nivells, què exigeix cadascun i què es pot demostrar de debò. Ja vas començar a la 07-05.
2. Signatura, procedència i verificació — Sigstore, atestacions, polítiques d'admissió que rebutgin artefactes no signats per la identitat esperada. La 08-03 hi insistia: verificar identitat, no només existència de signatura.
3. SBOM i inventari — CycloneDX i SPDX, Dependency-Track, i la capacitat de respondre en minuts a «on és aquesta llibreria?».
4. Threat modeling del pipeline — que és l'exercici més formatiu d'aquesta branca: què pot fer algú que compromet una acció de tercers? I un mantenidor d'una dependència? I un desenvolupador amb accés d'escriptura? I el mateix proveïdor de CI? Modelar el pipeline com a superfície d'atac canvia com el dissenyes.
5. Compliment normatiu — traduir controls tècnics a evidències que un auditor accepti, sense destruir la velocitat de lliurament.

Senyals que és el teu camí: penses espontàniament en com es trencaria alguna cosa; t'agrada el detall rigorós; toleres bé la feina que consisteix a convèncer altres d'acceptar fricció.

Senyals que no ho és: t'esgota ser qui posa límits; et frustra que l'èxit sigui invisible (no ha passat res) i el fracàs molt visible.

El risc del perfil: tornar-se el departament del no. La seguretat que bloqueja el lliurament acaba envoltada, i un control envoltat no protegeix res. La 04-03 ho deia: la seguretat ha d'anar dins del pipeline, no a sobre.

Què és. Quedar-te en producte, escrivint programari, i ser la persona que eleva la pràctica de lliurament del teu equip des de dins. No hi ha cap títol cridaner associat —de vegades «senior», de vegades «tech lead»— i és l'opció menys glamurosa i la més demandada.

Per què és la més demandada. La immensa majoria de les empreses del món no tenen ni equip de plataforma ni SRE ni especialista en cadena de subministrament. Tenen entre cinc i trenta desenvolupadors i un producte. El que necessiten no és un especialista: és algú que escrigui bon codi de producte i que a més sàpiga per què el pipeline fa el que fa, sàpiga arreglar-lo quan es trenca i sàpiga argumentar per què val la pena mantenir-lo. Aquest perfil és escàs perquè la gent que aprèn això tendeix a anar-se'n als perfils amb nom més atractiu.

Què aprendre, en ordre:

1. Disseny i proves — Feathers, Freeman i Pryce, Fowler (08-01). El teu avantatge competitiu és escriure codi que es pot lliurar amb freqüència: desacoblat, amb costures, cobert per proves que verifiquen de debò.
2. Bases de dades — el buit més rendible de l'apartat 1.2. Migracions, índexs, plans d'execució, contenció. És on hi ha els incidents cars.
3. Arquitectura per al lliurament — compatibilitat cap enrere, feature flags com a pràctica de disseny (03-05), expand and contract (04-06), i quan no trossejar (05-03).
4. Comunicació i influència — l'habilitat decisiva d'aquesta branca. Convèncer en Diego amb números i no amb principis. The Phoenix Project perquè altres el llegeixin; Accelerate per tenir les dades.
5. Mantenir el pipeline de l'equip — sense equip de plataforma, algú ho ha de fer bé. Aquest ets tu, i ja en saps.

Senyals que és el teu camí: t'agrada escriure producte i veure'n l'impacte; gaudeixes ensenyant companys; et motiva que l'equip sencer millori més que ser tu l'expert.

Senyals que no ho és: necessites especialització profunda; et frustra que la teva contribució de lliurament no tingui reconeixement formal —i sovint no en té—.

Consell per a qui dubti: comença aquí. És la direcció amb menys risc, la que millor conserva les opcions obertes i la que dóna el context de producte que fa millors els altres tres perfils. Gairebé tots els bons enginyers de plataforma i SRE que coneixeràs vénen d'haver escrit producte primer.

Consolidar el que s'ha après importa més que començar alguna cosa nova. En dotze setmanes, sense deixar la teva feina, amb lliurables verificables: si no es pot ensenyar a algú, no compta.

Objectiu: que el del mòdul 7 quedi sòlid i aplicat a alguna cosa real.

Per què la setmana 3 importa més del que sembla. Sense línia base, d'aquí a tres mesos no podràs demostrar res. I definir què comptes exactament com a «desplegament» i com a «fallada» és la meitat del valor de l'exercici.

Objectiu: triar una de les quatre direccions i avançar de debò, no en quatre alhora.

Exemples concrets de lliurable de la setmana 6-7 segons la direcció: plataforma → un workflow reutilitzable fet servir per dos repositoris; SRE → un SLO amb alerta de burn rate que s'ha disparat almenys una vegada de debò; cadena de subministrament → verificació de signatura amb identitat que bloqueja el desplegament d'una imatge no signada; producte → una migració amb expand and contract desplegada sense finestra de manteniment.

Objectiu: convertir el que s'ha après en evidència visible, que és el que ho fa útil professionalment.

La setmana 11 és la que més gent es salta i la que més rendeix. Explicar alguna cosa obliga a entendre-la, i produeix visibilitat. Una xerrada interna de 20 minuts sobre «com vam muntar el pipeline i què vam aprendre» canvia com et veu la teva organització més que qualsevol certificat.

Si vas endarrerit, no acceleris: retalla l'abast. Un pipeline petit acabat, mesurat i documentat val més que un d'ambiciós a mitges. És la mateixa regla que la 08-01 donava per llegir.

Tres funcions legítimes, i cap no és «demostrar que en saps»:

1. Filtre de recursos humans. En processos amb molts candidats i cribratge automàtic, un certificat passa filtres. És la seva funció més real i la menys noble. Importa més com més gran i burocràtica és l'organització, i a consultores, on de vegades són requisit contractual amb el client.
2. Itinerari d'estudi estructurat. El temari oficial és un índex raonable del que cal saber, i la data de l'examen és un compromís que combat la procrastinació. Aquest benefici és real fins i tot si no t'hi presentes.
3. Senyal en mercats concrets. En alguns països, sectors i per a feina amb administració pública, pesen de debò.

El que no són: prova de competència. Tothom al sector sap que hi ha gent certificada que no sap operar res, i gent sense ni un sol certificat que sosté sistemes crítics. Un entrevistador competent no et contracta pel certificat; com a màxim, et dóna una conversa.

• Examen exclusivament tipus test sobre memoritzar noms de serveis. Mesura capacitat de memorització a curt termini. Les pràctiques (CKA, CKS) valen molt més perquè no es poden aprovar sense saber fer.
• Certifica una eina que només fa servir qui la ven. El seu valor està lligat a la salut comercial d'un producte.
• No la demana ningú a les ofertes del teu mercat. Comprovació de deu minuts: busca 30 ofertes del lloc que vols i compta quantes l'esmenten. Si és zero, ja tens la resposta.
• Caduca en un any i renovar-la costa com treure-la. Subscripció disfressada de credencial.
• És d'una plataforma de cursos, no de qui fabrica la tecnologia. Els «certificats de finalització» de cursos en línia no són certificacions i en un currículum ocupen lloc sense aportar senyal. (Inclòs el d'aquest curs: el que val és el repositori que has construït, no el diploma.)
• La treus per evitar la part difícil. Si estudies una certificació perquè estudiar és més còmode que ficar el teu pipeline en producció i patir-lo, estàs substituint aprenentatge per la seva aparença. És la fallada més comuna i la més cara.

Regla pràctica de decisió: una certificació val la pena si (a) el seu temari coincideix amb el que anaves a estudiar de totes maneres, (b) l'examen és pràctic o almenys aplicat, i (c) apareix a les ofertes del teu mercat real. Si compleix les tres, endavant. Si compleix només (a), estudia el temari i no paguis l'examen.

El que un bon entrevistador vol veure és evidència de decisions, no de coneixements. I aquí tens avantatge, perquè el mòdul 7 et va deixar exactament això.

1. El repositori del projecte final. Públic, amb un README que expliqui què és i com executar-lo. Un pipeline complet, funcionant, amb historial de commits reals. Val més que qualsevol llista de tecnologies, perquè és verificable en cinc minuts.

2. El PIPELINE.md. És el teu millor actiu i el més rar. Un document que diu, decisió per decisió: què es va triar, què es va descartar, per què, i quina condició obligaria a revisar-ho. Gairebé ningú no té una cosa així, i demostra l'habilitat que separa un sènior d'un júnior: raonar sobre compromisos amb restriccions. Si en una entrevista només pots ensenyar una cosa, ensenya això.

3. El POSTMORTEM.md. Demostra que el teu sistema va fallar i va aguantar. Qualsevol ensenya un pipeline en verd; ensenyar-ne un que es va posar en vermell pel motiu correcte i es va recuperar en minuts és una altra categoria. I demostra el costum de verificar pel costat negatiu.

4. Els números. «Vam passar d'1,5 desplegaments per setmana a 12, i de 68 hores de lead time a 3,5» és una frase que canvia una entrevista. No perquè els números siguin espectaculars, sinó perquè demostra que mesures, que és el que gairebé ningú no fa.

5. Contribucions públiques. Encara que siguin petites (08-02). Un PR de documentació acceptat en un projecte conegut demostra que saps treballar amb el procés d'altres: llegir un CONTRIBUTING.md, acceptar revisió, iterar.

6. Xerrades i articles. Una xerrada interna compta. Un article tècnic en castellà, on hi ha molt menys contingut de qualitat, té un abast desproporcionat.

7. Com parles dels teus fracassos. L'indicador més fiable de tots. Qui pot explicar amb precisió què va sortir malament, per què, què va aprendre i què va canviar després, ha operat sistemes de debò. Qui només té èxits, o no ha operat res o no està sent sincer.

Poques vegades són d'algorismes. Solen tenir tres parts: conversa tècnica sobre experiència, disseny d'un sistema o pipeline, i de vegades un exercici pràctic o de depuració. El que s'avalua no és si saps la resposta, sinó com raones quan falta informació.

Vuit preguntes reals i què busca l'entrevistador:

1. «Explica'm com va un canvi des que algú l'escriu fins que és en producció, al teu últim projecte.»

Busca: si coneixes el flux complet o només el teu tros, i si esmentes espontàniament les portes i els seus motius. Una bona resposta esmenta què passa quan alguna cosa falla a cada etapa. És la 04-01 sencera.

2. «Per què no hauries de reconstruir la imatge en promocionar de staging a producció?»

Busca: si entens la immutabilitat de l'artefacte o repeteixes una regla. La resposta completa inclou que una reconstrucció pot resoldre dependencies diferents, que el digest ja no és el verificat i que perds la traçabilitat entre el que s'ha provat i el que s'ha desplegat. És la 02-06.

3. «Tens 200 desplegaments al mes i un 15 % de taxa de fallada de canvis. Per on comences?»

Busca: si comences per diagnosticar o per proposar solucions. La bona resposta comença preguntant: quin tipus de fallada?, en quina etapa es detecta?, quant es triga a revertir? Si el rollback és ràpid, un 15 % fa menys mal que si és lent. Qui respon «afegiria més proves» sense preguntar res, falla.

4. «Com desplegaries un canvi que trenca la compatibilitat de l'esquema de base de dades, sense finestra de manteniment?»

Busca: expand and contract (04-06). I sobretot, si esmentes que el desplegament va en diverses fases i en diversos dies, que el codi nou ha de tolerar l'esquema vell, i què fas amb el backfill i amb els bloquejos en una taula gran. És la pregunta que més separa nivells.

5. «Quina és la diferència entre lliurament continu i desplegament continu, i quin recomanaries aquí?»

Busca: precisió conceptual (03-01) i, sobretot, que no donis una resposta automàtica. La bona comença amb «depèn de què hi hagi a l'altre costat»: un producte amb clients empresarials i finestres contractuals no és un SaaS intern. Respondre «desplegament continu sempre» és el senyal d'alarma de la 08-02 aplicat a tu.

6. «El teu pipeline triga 40 minuts i l'equip es queixa. Què fas?»

Busca: mètode abans que solucions. Primer mesurar on se'n va el temps, després separar camí crític de la resta, i només llavors memòries cau, paral·lelització, sharding o execució selectiva (04-04). La resposta incompleta més freqüent és proposar optimitzacions sense mesurar. L'excel·lent hi afegeix: «i comprovaria que no estem traient verificacions per anar més ràpid» — el verd fals.

7. «Com gestiones els secrets al pipeline?»

Busca: si esmentes no tenir secrets (OIDC, rols) abans de parlar d'on desar-los. Després: mínim privilegi, rotació, emmascarat als logs i què fas si un es filtra —rotar primer, esborrar després (04-03, 08-02)—. Esmentar OIDC sense que t'ho preguntin és un senyal molt positiu.

8. «Explica'm un incident de producció del qual fossis responsable.»

Busca: honestedat, cadena causal en comptes de culpable únic, i què va canviar després. La millor resposta inclou el que es va intentar i no va funcionar, i acaba amb una millora concreta i verificable. Qui diu «no he tingut mai cap incident» perd la pregunta: o no ha operat res, o no se'n va assabentar.

El transversal. En totes, l'entrevistador avalua el mateix: si distingeixes el que saps del que suposes, si preguntes pel context abans de respondre, i si esmentes contrapartides sense que te les demanin. Són exactament els marcadors del bon consell de la 08-02. Ara els apliques tu.

El cicle del hype. Tota tecnologia nova recorre el mateix arc: aparició, entusiasme desproporcionat, desil·lusió quan es descobreixen les arestes, i —si sobreviu— productivitat estable amb documentació decent. La major part del contingut que veuràs correspon a la fase d'entusiasme, escrit per gent que fa tres setmanes que té l'eina i cap en producció.

La conseqüència pràctica: arribar tard a una eina bona costa molt poc. L'aprendràs quan tingui millor documentació, més exemples i menys arestes. Arribar aviat a una de dolenta costa una migració, i les migracions es paguen en anys.

Què seguir:

• La documentació i les notes de versió del que fas servir en producció. No negociable.
• Els avisos de seguretat de les teves dependencies directes.
• Una font de profunditat setmanal (el pla de la 08-01).
• Un espai de comunitat on participis de debò (08-02).

Què ignorar:

• Anuncis d'eines que resolen problemes que no tens.
• Comparatives escrites per qui ven una de les opcions.
• Contingut que promet que «X ha mort». X no ha mort; hi ha bancs executant COBOL.
• Qualsevol cosa que produeixi ansietat sense produir una acció concreta.

La regla del descart: si fa sis mesos que veus un nom i mai no t'ha resolt un problema, esborra'l del radar. Si importa de debò, tornarà.

I la idea central: els fonaments duren i les eines no. El que has après en aquest curs sobre lots petits, retroalimentació ràpida, artefactes immutables, compatibilitat cap enrere, pressupost d'error i verificar pel costat negatiu continuarà sent cert quan GitHub Actions es digui d'una altra manera. Jenkins, Travis, CircleCI, GitLab, Actions: cinc eines per a les mateixes sis pràctiques de la 02-01. Qui va aprendre les pràctiques va canviar d'eina en dues setmanes. Qui va aprendre només l'eina va començar de zero cada vegada.

Inverteix en fonaments a raó de deu a un enfront d'eines. I quan dubtis de si una cosa és fonament o moda, aplica el filtre del temps: això era cert fa deu anys i ho serà d'aquí a deu?

Els principis invariants del curs, en una llista que pots rellegir d'aquí a cinc anys amb qualsevol eina:

1. Integra aviat i en lots petits. La mida del lot és la variable que més influeix en el risc. Tota la resta és conseqüència.
2. Si el pipeline està vermell, arreglar-lo és la prioritat. Un pipeline trencat que es tolera deixa de ser un pipeline i passa a ser decoració.
3. Construeix l'artefacte una vegada i promociona aquest mateix artefacte. Si reconstrueixes, no has provat el que desplegues.
4. Automatitza el que és repetitiu; deixa el judici a les persones. Les portes automàtiques per al que és verificable, les aprovacions per al que exigeix context.
5. La retroalimentació ràpida val més que l'exhaustiva. Una prova en 2 minuts que detecta el 80 % supera una de 2 hores que detecta el 95 %.
6. Poder revertir importa més que no equivocar-se. L'objectiu no és el desplegament perfecte: és que la fallada sigui barata.
7. Mesura el que vols millorar, i mesura la teva pròpia tendència, no la d'una enquesta.
8. La fiabilitat és un objectiu negociable. El 100 % és el número equivocat; el pressupost d'error converteix una discussió d'opinions en una decisió.
9. La seguretat va dins del pipeline, no a sobre. Un control que fa nosa s'envolta, i un control envoltat no protegeix.
10. Documenta el perquè, no el com. El codi diu què fa; només tu pots dir què vas descartar i sota quina condició es revisa.
11. Les fallades són de sistema, no de persones. Un post-mortem amb culpable garanteix que el següent incident s'amagui.
12. Verifica pel costat negatiu. Qualsevol comprova que una porta deixa passar el que és bo; comprovar que atura el que és dolent exigeix fabricar el que és dolent.

Cap d'aquests dotze no esmenta cap eina. Cap no caducarà abans que la teva carrera.

• Triar direcció pel salari o pel prestigi del títol. Les quatre paguen bé i la diferència entre elles és menor que la diferència entre fer-ho bé i fer-ho malament. Tria per les senyals de l'apartat 2, que descriuen què et resultarà sostenible durant anys.
• Intentar les quatre alhora. Produeix coneixement superficial en totes. Tria'n una per a 6-12 mesos; les altres continuen allà i el fonament és comú.
• Col·leccionar certificacions com a substitut de l'experiència. Es detecta en una entrevista en dues preguntes. És la manera còmoda d'evitar la part difícil, que és ficar alguna cosa en producció i patir-la.
• Saltar-se la línia base. Sense mesurar el punt de partida no podràs demostrar millora, i demostrar millora és el que et dóna marge per continuar invertint.
• Esperar a «estar preparat» per fer una xerrada o escriure. Ningú no se sent preparat. El nivell adequat és el d'algú que va resoldre el problema fa tres mesos: recordes on eren les dificultats, cosa que l'expert ja ha oblidat.
• No demanar la responsabilitat. Si vols operar sistemes, demana entrar a la rotació de guàrdies. Si vols plataforma, ofereix-te a mantenir el pipeline de l'equip. L'experiència poques vegades s'ofereix sola; es demana.
• Consell: escriu el pla i posa-hi dates. Un pla sense data és un desig. Revisa'l cada tres mesos i permet-te canviar-lo amb motiu escrit.
• Consell: ensenya el que acabes d'aprendre. És el multiplicador més barat: fixa el coneixement, exposa els buits i et fa visible.
• Consell: guarda el teu propi registre de decisions professionals, amb el mateix format del PIPELINE.md: què vas triar, què vas descartar, quina condició et faria canviar. Serveix igual per a una carrera que per a un pipeline.

Escriu la teva pròpia decisió de direcció, en una pàgina, amb aquesta estructura:

1. Què m'ha resultat més interessant del curs, amb lliçons concretes (no «el mòdul 3», sinó «la part de la 03-06 sobre per què alertar per símptoma»).
2. Què m'ha resultat tediós o m'ha costat, amb la mateixa concreció.
3. La direcció triada i les tres senyals de l'apartat 2 que reconec en mi.
4. El senyal d'alarma: què d'aquesta direcció em preocupa i com ho comprovaria abans de comprometre'm un any.
5. El primer pas concret, aquesta setmana.

Si treballes millor amb un cas aliè, fes-ho per a la Nuria (frontend/QA a Reservalia, es va ocupar de les proves E2E i del panell de Grafana de la 07-04, va gaudir mesurant, l'esgoten les tasques d'infraestructura).

Un company amb dos anys d'experiència, que acaba aquest curs, t'escriu:

«He decidit treure'm CKA, Terraform Associate i AWS DevOps Professional aquest any. Amb les tres segur que em surt alguna cosa millor. Començo per AWS que és la més valorada, oi?»

Escriu la teva resposta. Ha d'incloure: què està bé del seu plantejament, què està malament, què li proposes concretament (amb ordre i motiu), i què faria més per la seva carrera que les tres certificacions juntes. Justifica-ho amb el criteri de l'apartat 4, no amb opinió.

Tria tres de les vuit preguntes de l'apartat 6 i escriu la teva resposta real, com si fossis a l'entrevista, basada en el que has construït al mòdul 7. Després, per a cadascuna, anota què li falta a la teva resposta i què hauries d'haver viscut per poder-la donar completa. Aquest segon apartat és l'exercici de debò: és el teu pla d'aprenentatge en forma de buits concrets.

Solució 1

No hi ha resposta correcta; hi ha respostes honestes i respostes complaents. Exemple, per a la Nuria:

1. El més interessant. La 03-06, en concret la idea d'alertar per símptoma i no per causa: va ser el moment en què va entendre per què el seu equip tenia 40 alertes que ningú no mirava. I la 07-04, muntar el panell i veure l'SLO consumir-se en temps real: la primera vegada que una mètrica li va explicar una història.

2. El tediós. La 03-03, Terraform. Va entendre el concepte, va executar els passos, i no va gaudir ni un minut. També el dimensionament d'infraestructura de la 04-04: li va resultar aliè.

3. Direcció: SRE / fiabilitat. Tres senyals de l'apartat 2 que hi reconeix: els incidents li resulten interessants en comptes de només estressants (al laboratori de la 07-04, trencar l'endpoint i perseguir-ne l'efecte a les mètriques va ser el que més va gaudir); li importa l'experiència real de l'usuari, que és d'on ve el seu perfil de QA; gaudeix mesurant.

4. El senyal d'alarma: les guàrdies. No ha estat mai de guàrdia i no sap com porta que la despertin. És el factor que més gent subestima en triar aquesta direcció, i el més difícil de revertir un cop compromesa. Com ho comprova abans de comprometre's un any: demana entrar com a segona persona a la rotació de guàrdies durant dos mesos —acompanyant, sense ser-ne responsable—. És la prova més barata i directa possible, i la informació que dóna no es pot obtenir llegint.

5. Primer pas aquesta setmana. Revisar l'SLO que va definir a la 07-04 i preguntar-se si l'SLI mesura de debò l'experiència de l'usuari o només si el servidor respon. I començar el capítol d'SLO de l'SRE Workbook (08-01) amb aquesta pregunta escrita.

El que fa bona aquesta resposta: que el punt 2 sigui sincer. Qui escriu «tot em va semblar interessant» no ha fet l'exercici. I que el punt 4 tingui una comprovació barata i reversible en lloc d'una decisió irreversible.

Solució 2

Què està bé. Té iniciativa, ha triat tres certificacions legítimes de tecnologies reals i no de productes marginals, i s'ha posat un termini. Això ja el distingeix de la majoria.

Què està malament, i són quatre coses:

1. L'ordre està invertit. Començar per AWS DevOps Professional amb dos anys d'experiència és la pitjor decisió del pla. Els exàmens professional assumeixen experiència operativa àmplia; sense ella, l'única via d'aprovar és la memorització massiva, que s'oblida en mesos i no deixa capacitat. L'ordre raonable és Terraform Associate (3-6 setmanes, transversal, assequible, i li dóna IaC que serveix en les quatre direccions), després CKA si de debò ha de tocar Kubernetes, i AWS Professional més endavant o mai, segons la seva feina real.
2. «Amb les tres segur que em surt alguna cosa millor» és una hipòtesi sense comprovar, i comprovar-la costa deu minuts: que busqui 30 ofertes del lloc que vol al seu mercat i compti quantes en demanen cadascuna. Probablement descobrirà que Terraform i Kubernetes apareixen molt, i AWS Professional bastant menys del que es pensa.
3. «La més valorada» és una afirmació sense context, el senyal d'alarma de la 08-02. Valorada per qui? A consultores AWS partner, molt; a producte, bastant menys que ensenyar un sistema que funciona.
4. I el problema de fons: tres certificacions en un any són entre sis i nou mesos d'estudi. Això és gairebé tot el seu temps d'aprenentatge de l'any dedicat a temaris en comptes de a sistemes. Amb dos anys d'experiència, el que li falta no és temari: és haver operat coses.

Què li proposo. Una certificació aquest any: Terraform Associate, perquè el seu temari coincideix amb el que li convé estudiar de totes maneres, és assequible en temps i és transversal a les quatre direccions. I després decidir CKA amb una dada a la mà: si en sis mesos ha tocat Kubernetes a la feina, endavant; si no, és un certificat sobre una cosa que no fa servir i se li oblidarà.

Què faria més per la seva carrera que les tres juntes. El pla de 90 dies de l'apartat 3: aplicar el pipeline a un projecte real, mesurar la línia base DORA, escriure el PIPELINE.md, trencar alguna cosa expressament, documentar el post-mortem, tornar a mesurar i explicar-ho en una xerrada interna. Això són dotze setmanes, no nou mesos, i produeix alguna cosa que pot ensenyar. En una entrevista, «aquí hi ha el repositori, aquest és el document de decisions i aquests són els números d'abans i després» obre una conversa que un certificat no obre. El certificat, com a màxim, li aconsegueix l'entrevista; l'altre se la guanya.

I un matís honest: si treballa o vol treballar en una consultora on les certificacions són requisit contractual amb clients, el càlcul canvia i AWS Professional pot tenir sentit abans. Que comprovi això primer, perquè és l'únic cas en què el seu pla original seria defensable.

Solució 3

Exemple amb dues de les vuit preguntes.

Pregunta 4 — migració que trenca compatibilitat, sense finestra de manteniment.

Resposta basada en el mòdul 7: «En tres fases separades en el temps, amb el patró expand and contract. Fase d'expansió: afegeixo la columna nova permetent nuls, sense tocar l'antiga, i desplego codi que escriu a totes dues i llegeix de l'antiga. Migració de dades: backfill per lots, amb pauses, per no bloquejar la taula ni saturar la base de dades. Fase de contracció, dies després i en un desplegament diferent: el codi passa a llegir de la nova, i només quan porto temps estable elimino la columna antiga. La clau és que en cap moment no hi ha una versió del codi incompatible amb l'esquema vigent, perquè durant el desplegament rolling hi conviuen versions.»

Què li falta. No he fet això sobre una taula de milions de files amb trànsit real. No sé quant triga un backfill així, ni com es comporta el bloqueig d'un ALTER TABLE sota càrrega a PostgreSQL, ni com es coordina si hi ha rèpliques de lectura amb retard. Tampoc no he hagut de revertir a mitja migració, que és el cas difícil.

Què hauria de viure. Una migració real sobre una taula gran en producció, amb mètriques al davant. I provar-la abans sobre una còpia de dades de volum realista, que és el que la 04-06 recomanava i al laboratori no vaig arribar a fer amb volum de debò.

Pregunta 8 — un incident del qual fossis responsable.

Resposta basada en el mòdul 7: «Al laboratori de la 07-04 vaig provocar una fallada expressament: vaig introduir una regressió de latència a l'endpoint de disponibilitat i vaig observar com l'SLO començava a consumir pressupost d'error. L'alerta per símptoma es va disparar al cap de pocs minuts —no per CPU, sinó perquè la latència p95 se'n va sortir de l'objectiu—, vaig executar el rollback.yml per digest i el servei es va recuperar en uns minuts. Ho vaig documentar amb la plantilla de post-mortem sense culpables, i la conclusió va ser que l'alerta va funcionar però va arribar tard per al pressupost d'error que teníem definit.»

Què li falta —i això s'ha de dir a l'entrevista, no amagar-ho—. Que va ser una fallada provocada per mi, en un entorn controlat, sense usuaris reals afectats, sense ningú preguntant per què no funciona i sense la pressió de decidir amb informació incompleta a les 3 de la matinada. És un assaig, no un incident.

Què hauria de viure. Estar a la rotació de guàrdies d'un sistema amb usuaris. La diferència no és tècnica: és que en un incident real no saps què ha canviat, hi ha diverses hipòtesis alhora, algú et pregunta quant falta, i la decisió de revertir es pren amb dades incompletes.

Per què aquesta manera de respondre funciona en una entrevista. Un entrevistador competent valora més «ho vaig fer en un entorn controlat i això és el que li falta a la meva experiència» que una resposta inflada. Distingir el que saps del que suposes és exactament el marcador que l'apartat 6 assenyalava com a transversal, i dir-ho tu abans que t'ho detectin juga al teu favor.

A la 01-04 vas conèixer la Marta, en Diego i la Nuria, i un equip que desplegava 1,5 vegades per setmana, trigava 68 hores des que un canvi estava escrit fins que arribava a producció, trencava producció en el 6,5 % dels desplegaments i trigava 68 minuts a recuperar-se quan això passava. Els divendres no es desplegava. Ningú no recordava quina versió hi havia abans. I desplegar era, per a tothom, un esdeveniment que es preparava amb antelació i es vivia amb la tensió de qui espera que alguna cosa surti malament.

Quatre mòduls després, aquest mateix equip desplegava 12 vegades per setmana, amb 3,5 hores de lead time, un 3,8 % de fallada i 9 minuts de recuperació. Els mateixos tres, el mateix producte, el mateix núvol. El que va canviar no va ser la gent ni la tecnologia: va ser com estava organitzat el camí a producció.

I la Marta ho havia dit al principi, quan encara sonava a provocació: «prefereixo desplegar deu vegades al dia i que cada desplegament sigui avorrit».

Ara ja saps que no era una frase enginyosa. Era una tesi tècnica completa, i tot el curs n'ha estat la demostració. Un desplegament avorrit és un desplegament petit —perquè el lot és petit, hi ha poc que pugui sortir malament—. És un desplegament verificat —perquè les portes ja van comprovar el que és comprovable, i algú es va assegurar que aturen el que és dolent provocant-ho—. És un desplegament reversible —perquè l'artefacte és immutable, està identificat pel seu contingut i tornar enrere és una operació de minuts, no una reconstrucció—. I és un desplegament observat —perquè si alguna cosa es degrada, ho dirà una alerta sobre un símptoma que li importa a un usuari, no un humà mirant gràfiques per si de cas—.

Fer avorrit el que feia por no és treure-li importància. És el contrari: és haver-hi dedicat tanta enginyeria que ja no requereix heroisme. La por al desplegament mai no va ser irracional —desplegar a mà, sense proves, sense poder tornar enrere i sense saber si va funcionar hauria de fer por—. El que has après és a eliminar les condicions que la justificaven.

Queda una última cosa, i és la que retorna la responsabilitat a qui correspon.

El pipeline no és l'objectiu. És fàcil oblidar-ho després de set mòduls construint-lo. Ningú no ha pagat mai per un pipeline. Els usuaris de Reservalia no saben que existeix i no els importaria si ho sabessin: el que els importa és poder reservar una cita, que el sistema no caigui un dissabte al matí i que les seves dades estiguin segures. Tot el que has construït —les tres capes de proves, el digest, la signatura, l'SLO, el rollback en quatre minuts— existeix per a una sola cosa: lliurar valor amb seguretat i sense heroismes.

Quan d'aquí a un temps t'enfrontis a la decisió de si afegir una altra porta, una altra eina o una altra fase, la pregunta no serà «això és una bona pràctica?». Serà la de l'apartat 12 de la 08-03: quin problema mesurat resol, i per a qui? Si la resposta és «per a ningú, però queda millor», ja saps què fer.

Tens el fonament per llegir amb criteri, la comunitat per preguntar quan el problema sigui de context, el catàleg per reconèixer què existeix i què et costarà, i una direcció per als propers mesos. Tens també, i això importa més, un repositori amb un sistema que funciona, un document que explica per què és així, i la prova que va fallar i va aguantar.

El que facis amb tot això ja no depèn del curs.

Que els teus desplegaments siguin avorrits.