La 07-06 acabava amb una instrucció concreta: llegeix-ho amb el pipeline al davant. Aquesta lliçó és on això es posa a prova. No és una bibliografia —una bibliografia és una llista de deures que ningú no fa— sinó un mapa de què llegir, en quin ordre, per resoldre què, i amb quin escepticisme.

La diferència entre llegir aquests llibres abans del curs i llegir-los ara és enorme, i convé entendre per què. Abans, Continuous Delivery era un manual d'instruccions sobre un món que no havies vist: llegies «l'artefacte s'ha de construir una sola vegada i promocionar-se entre entorns» i assenties sense que la frase et costés res. Ara has construït aquest artefacte, l'has identificat per digest, has vist què passa quan algú reconstrueix la imatge al pas de producció i has escrit al teu PIPELINE.md per què això està prohibit. La mateixa frase ja no és informació: és una confirmació o una discrepància, i totes dues coses t'ensenyen.

Aquest mòdul sencer descansa en una idea: l'objectiu de llegir tècnic no és acumular, és decidir millor. I només es pot decidir millor sobre un sistema que existeix.

1. Com llegir tècnic quan ja tens un sistema
2. Els quatre fonamentals
3. Per temes: proves i disseny
4. Per temes: resiliència i operació
5. Per temes: arquitectura i desplegament
6. Per temes: infraestructura
7. Per temes: organització i equips
8. Per temes: escala i enginyeria
9. Fonts vives: el que envelleix millor que els llibres
10. Taula mestra: recurs → problema → quan
11. Un pla de lectura de 12 mesos
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

Hi ha dues maneres de llegir un llibre tècnic i només una funciona a hores d'ara.

Llegir per acumular és la manera escolar: comences per la pàgina 1, subratlles, acabes, et sents bé i al cap de tres mesos recordes el títol i poca cosa més. És la manera que produeix la sensació —molt comuna i molt enganyosa— que «cal llegir més». No cal llegir més: cal llegir amb una pregunta.

Llegir per decidir funciona així: arribes al llibre amb un problema obert del teu sistema, busques a l'índex el capítol que el toca, el llegeixes sencer, i canvies alguna cosa o escrius per què no la canvies. La resta del llibre queda per quan aparegui el problema següent. Un llibre tècnic no és una novel·la; és documentació amb narrativa, i es consulta.

Algunes regles pràctiques que fan que això funcioni:

• Obre el llibre amb una pregunta escrita. Literalment escrita, en una nota. «Hauríem de posar canary a Mini-Reservalia o el rolling amb health checks ja ens basta?» és una pregunta. «Vull aprendre desplegament» no ho és.
• Llegeix l'índex sencer abans que res. Et dóna el mapa mental de l'autor i et diu a quin capítol tornar d'aquí a sis mesos. És el 5 % del temps i el 40 % del valor.
• Anota discrepàncies, no coincidències. Quan el llibre diu el que ja fas, no aprens res. Quan diu alguna cosa que contradiu el teu pipeline, tens or: o el llibre està desactualitzat, o el teu context és diferent, o estàs equivocat. Les tres conclusions són útils i totes tres exigeixen que escriguis el raonament.
• Converteix cada lectura en un canvi verificable o en una entrada del PIPELINE.md. Si un llibre no produeix cap de les dues coses, o el vas llegir sense pregunta o no era el llibre.
• Tingues en compte la data. Un llibre del 2010 sobre lliurament continu encerta en principis i falla en eines. Un del 2021 sobre Kubernetes pot fallar en totes dues. La regla gruixuda: com més a prop del maquinari i de l'API concreta, abans caduca; com més a prop de les persones i del flux de treball, més dura.

Són quatre perquè són els que sostenen la bastida de tot el que has fet en set mòduls. Si només llegeixes quatre llibres a la teva carrera sobre això, que siguin aquests.

Què defensa. Que el programari ha d'estar sempre en un estat desplegable, i que el camí per aconseguir-ho és una deployment pipeline: una seqüència automatitzada d'etapes que va augmentant la confiança sobre un mateix artefacte fins que desplegar-lo deixa de ser un esdeveniment. És el llibre que va posar nom i estructura a gairebé tot el que aquest curs t'ha fet construir.

Quin capítol importa més ara. El de la deployment pipeline i el de gestió de configuració i entorns. Allà hi ha, amb molt més detall del que cabia a la 02-06 i la 03-01, la justificació de dues regles que aquí van ser gairebé dogma: construir una vegada i promocionar el mateix binari, i separar configuració d'artefacte. Si en algun moment del curs et va semblar excessiu l'èmfasi en el digest, aquest capítol és la raó llarga.

Què ha envellit. Les eines concretes i bona part del vocabulari operatiu: el llibre és anterior a la normalització de contenidors, als runners efímers, als entorns com a codi al núvol i als registres d'imatges. Hi trobaràs pàgines sobre gestió de màquines de compilació que avui resol un runner de GitHub Actions en una línia de YAML. També assumeix un món on desplegar és més car del que ho és avui.

Què li falta. Tot el que va venir després: seguretat de la cadena de subministrament (mòdul 4), observabilitat moderna i SLO (03-06), feature flags com a pràctica central (03-05) i el marc DORA com a validació empírica —que va arribar just amb el llibre següent.

Quan llegir-lo. Ara, i en mode consulta. És el llibre de referència al qual es torna, no el que es llegeix d'una tirada.

Què defensa. Que les pràctiques de lliurament continu no són ideologia, són mesurables, i que hi ha una correlació forta entre capacitats tècniques (automatització, trunk-based, arquitectura desacoblada, monitoratge) i resultats de negoci. És la font de les quatre mètriques DORA que vas definir a la 01-05 i amb les quals vas mesurar el teu progrés a la 07-04.

Quin capítol importa més ara. El de les capacitats tècniques i el d'arquitectura. I, molt especialment, la part metodològica: com es va construir l'enquesta, què significa «correlació» aquí i què no significa. Aquest és el capítol que la majoria es salta i l'únic que et protegeix d'utilitzar el llibre com a martell.

Què ha envellit. Els números concrets de rendiment de cada categoria. Els llindars d'«elit» s'han mogut a les edicions successives de l'informe DORA i continuaran movent-se; fer servir els del llibre com a objectiu avui és ancorar-se a una foto vella. Fes servir l'informe anual per als números i el llibre per al raonament.

Què li falta. Honestedat sobre les seves pròpies limitacions metodològiques més enllà del que el capítol tècnic reconeix: és una enquesta d'autoinforme, amb biaix de selecció cap a organitzacions que ja s'interessen pel tema, i correlació no és causalitat per molt que el model d'equacions estructurals suggereixi direcció. Això no l'invalida —és la millor evidència que tenim— però convé citar-lo amb aquesta cautela, sobretot davant d'algú com en Diego, que preguntarà exactament això.

Quan llegir-lo. Ara, i sobretot abans de la conversa en què hagis de justificar inversió en pipeline. És el llibre que converteix «jo crec que això és millor» en «hi ha dades que apunten a això».

Què defensa. És el manual operatiu de la cultura DevOps, organitzat en «els tres camins»: flux (de desenvolupament a operacions), retroalimentació (d'operacions a desenvolupament) i aprenentatge continu. On Continuous Delivery és tècnic i Accelerate és empíric, aquest és organitzatiu: com s'implanta això en una empresa on hi ha gent, política i por.

Quin capítol importa més ara. El segon camí, la retroalimentació: telemetria, revisió per parells, «stop the line» i cultura de seguretat psicològica. És el fonament de la 02-01 (la línia de muntatge que s'atura) i de la 03-05 (post-mortem sense culpables). I el capítol d'aprenentatge: per què un post-mortem amb culpable garanteix que el següent incident s'amagui.

Què ha envellit. El repertori de casos d'estudi, molt centrat en l'onada 2010-2016 i en empreses grans. I un cert to de manifest que era necessari quan calia convèncer i avui sona a predicar a conversos.

Què li falta. El llibre és llarg i dispers; en pots treure el 80 % llegint els capítols que et toquen i saltant la resta sense remordiment. No està pensat per llegir-se linealment tot i que ho sembli.

Quan llegir-lo. Quan el teu problema deixi de ser tècnic i passi a ser humà. És a dir: tan bon punt intentis implantar alguna cosa d'aquest curs en un equip que no ho ha demanat.

Són dos llibres de Google i convé tractar-los com una parella. El primer, Site Reliability Engineering, defineix la disciplina: SLI, SLO, pressupost d'error, toil, guàrdies, gestió d'incidents. El segon, The Site Reliability Workbook, és el que aterra aquestes idees amb exemples concrets, plantilles i contraexemples.

Què defensen. Que la fiabilitat és un objectiu negociable i mesurable, no una aspiració infinita; que el 100 % és l'objectiu equivocat; i que el pressupost d'error és el mecanisme que converteix una discussió d'opinions («despleguem avui?») en una decisió de dades.

Quin capítol importa més ara. Del Workbook, el d'implantació d'SLO i el d'alertes sobre SLO. Són la continuació natural i molt més profunda del que la 03-06 va deixar en el mínim imprescindible: allà vas definir un SLO de disponibilitat i un pressupost d'error, i vas alertar per símptoma en comptes de per causa. El Workbook explica com es trien els SLI quan el servei no és un simple GET /health, com es fan finestres múltiples i taxes de consum (burn rate), i què fer quan el pressupost s'esgota de debò.

Què ha envellit. Poc en els principis. Bastant en l'escala implícita: els llibres descriuen l'operació de Google, amb equips dedicats, eines internes i volums que no s'assemblen a Reservalia ni de bon tros. El Workbook n'és conscient i per això és el més útil dels dos per a tu.

Què li falta —i és l'error més comú—. No és un manual per a equips de tres persones. Aplicar SRE literalment en un equip petit produeix un munt de cerimònia sense ningú que la sostingui. El que sí que escala cap avall: SLI/SLO, pressupost d'error, alerta per símptoma, post-mortem sense culpables i la idea de toil. El que no: guàrdies formals per rotació, equips SRE separats, revisions de producció com a porta.

Quan llegir-lo. El Workbook, ara. L'SRE Book, quan la fiabilitat sigui la teva feina i no una part de la teva feina.

Què no esperar d'aquest grup. Cap no parla de pipelines. Parlen del que fa que un pipeline verd signifiqui alguna cosa. Si el teu problema és «la meva suite triga 40 minuts», aquest grup no t'ajuda: això és 04-04.

Sobre Release It!. És el llibre que més canvia la manera de mirar el codi de producció de tots els d'aquesta llista, i el més subestimat. La seva tesi implícita: el programari falla de maneres que el disseny no va contemplar, i hi ha un catàleg finit d'aquestes maneres. Si a la 03-05 et va semblar que el rollback automàtic per mètriques era una xarxa suficient, aquest llibre t'ensenyarà quantes fallades no produeixen una mètrica clara abans de tombar-te el servei. Ha envellit en els exemples de plataforma (Java empresarial de mitjans dels 2000) i gens en absolut en els patrons.

L'avís important. Newman és notablement honest sobre els costos dels microserveis —dedica pàgines a dir que probablement no els necessites— però el gènere en general no ho és. Si llegeixes aquests llibres amb ganes de trossejar Reservalia, recorda la conclusió de la 05-03: el cost dels microserveis es paga al pipeline i a l'operació, i un equip de tres persones paga aquest cost sencer sense rebre'n el benefici, que és l'autonomia d'equips que no té.

Infrastructure as Code — Kief Morris.* És el llibre llarg del que la 03-03 va deixar en una lliçó. Aporta el vocabulari i els patrons: servidors immutables enfront de mutables, com estructurar el codi d'infraestructura perquè es pugui provar, gestió d'estat, entorns com a codi, i el problema —molt real i molt poc tractat— de com es prova la infraestructura.

• Què il·lumina del curs: per què a la 03-03 s'insisteix que l'estat de Terraform és l'actiu més fràgil del sistema, i per què els entorns han de sortir del mateix codi amb variables diferents.
• Quan llegir-lo: quan el teu Terraform passi d'un directori a diversos mòduls i aparegui la pregunta «com organitzo això?». Abans d'aquest moment és teoria sense ancoratge.
• Què no esperar: receptes d'un núvol concret. És deliberadament agnòstic, i això vol dir que la sintaxi exacta la continues havent de buscar a la documentació oficial.

Team Topologies — Matthew Skelton i Manuel Pais.* Proposa quatre tipus d'equip (alineat al flux, plataforma, capacitació, subsistema complicat) i tres modes d'interacció, i sobretot introdueix la càrrega cognitiva com a criteri de disseny organitzatiu. És el llibre que explica per què «muntem un equip DevOps» acostuma a produir un coll d'ampolla nou amb nom modern.

• Enllaç: la 08-04 parla d'enginyeria de plataforma com a direcció de carrera; aquest llibre és el marc conceptual de per què aquesta funció existeix i quan té sentit crear-la. També explica, a posteriori, per què a Reservalia el pipeline el manté el mateix equip que escriu el producte: amb tres persones, qualsevol altra topologia és sobredisseny.
• Quan llegir-lo: quan tinguis influència sobre com s'organitza la gent, o quan pateixis una organització mal dissenyada i vulguis el vocabulari per anomenar el problema.
• Què no esperar: un pla de reorganització. És un llenguatge, no un procediment, i se n'ha abusat bastant com a etiqueta de PowerPoint.

The Phoenix Project — Kim, Behr, Spafford.* Novel·la. Un responsable de TI hereta un desastre i va descobrint, amb l'ajuda d'un mentor socràtic, els principis de flux, els colls d'ampolla i la feina no planificada.

• Per a què serveix de debò: no per aprendre-ho tu —els conceptes estan més ben explicats al DevOps Handbook—, sinó perquè el llegeixi una altra persona. És el llibre que dónes al cap de producte, a la direcció o al company escèptic, perquè es llegeix en un cap de setmana i produeix la conversa que tu fa mesos que intentes tenir. Com a eina de persuasió organitzativa val més que els tres fonamentals junts.
• Què no esperar: rigor. És una paràbola, amb antagonistes de cartró i una resolució massa neta. La seva seqüela, The Unicorn Project, explica el mateix des del punt de vista de desenvolupament i té els mateixos vicis i virtuts.

Software Engineering at Google — Titus Winters, Tom Manshreck i Hyrum Wright.* La tesi del llibre cap en una frase: l'enginyeria de programari és programació integrada en el temps. El que funciona per a un programa que viu una setmana no funciona per a un que viu una dècada amb cent persones tocant-lo.

• Què il·lumina: els capítols de proves (grans, mitjanes i petites, i per què la classificació per mida és millor que per tipus), el de CI i el de dependencies. Especialment el de dependencies: és la millor explicació que existeix de per què la 04-02 insistia tant en el lockfile i en la disciplina d'actualització, i del concepte que dependre d'alguna cosa és contreure una obligació futura.
• Quan llegir-lo: per capítols, quan el problema aparegui. És un llibre de 600 pàgines escrit per moltes mans i amb qualitat desigual.
• Què no esperar: aplicabilitat directa. Google té un monorepo, eines pròpies i una escala que fa que algunes de les seves solucions siguin absurdes fora d'allà. Llegeix el raonament, ignora la implementació.

Els llibres donen fonament; les fonts vives donen actualitat. Un professional seriós consumeix totes dues i sap per a què serveix cadascuna.

Què és. Un informe anual, basat en una enquesta a desenes de milers de professionals, que mesura les capacitats de lliurament de programari i els seus resultats. És la continuació de la feina d'Accelerate i la font dels llindars actuals de les quatre mètriques que vas fer servir a la 01-05 i la 07-04. Està publicat lliurement a dora.dev.

Com llegir-lo amb escepticisme estadístic —això és l'important—:

1. És autoinforme. Ningú no mesura el lead time de ningú: la gent l'estima. Els biaixos d'optimisme són enormes, sobretot a la pregunta de temps de restauració.
2. Hi ha biaix de selecció. Respon qui s'assabenta de l'enquesta, i qui se n'assabenta és qui ja és en aquesta conversa. La població no és «el programari mundial».
3. Els clústers canvien d'any en any. El nombre de categories de rendiment, els seus noms i els seus llindars s'han mogut entre edicions. Comparar la teva «elit» d'enguany amb l'«elit» de fa tres anys és comparar dues coses diferents.
4. Correlació amb direcció suggerida no és causalitat demostrada. L'informe hi és curós; els seus lectors no sempre.
5. El més valuós no són els llindars, són els temes de l'any. Cada edició explora capacitats concretes —documentació, plataformes internes, IA, seguretat de la cadena de subministrament— i aquí és on hi ha el contingut que no trobaràs en cap altre lloc.

Com fer-lo servir bé: per orientar-te i per argumentar, mai com a objectiu. El teu objectiu és la tendència de les teves pròpies quatre mètriques, com vas fer amb Reservalia (d'1,5 desplegaments per setmana i 68 hores de lead time a 12 i 3,5 hores). Comparar-te amb tu mateix fa sis mesos és una mesura honesta; comparar-te amb un percentil d'una enquesta global és teatre.

El lloc de Martin Fowler és, probablement, la millor font gratuïta de vocabulari precís sobre aquests temes. Els articles sobre lliurament continu, feature toggles, branques i patrons de desplegament són referències canòniques: quan algú discuteix amb tu si «això és CI de debò», el que està citant —ho sàpiga o no— sol venir d'allà. L'article llarg sobre feature toggles és la millor ampliació de la 03-05 que existeix en obert, amb la taxonomia completa (release, experiment, ops, permission) i el cicle de vida d'un flag.

Què esperar: definicions netes i argumentades, amb les contrapartides explícites. Què no: neutralitat total. Hi ha una postura clara —trunk-based, proves primer, simplicitat— que aquest curs comparteix, però que convé reconèixer com a postura.

Aquest és el canvi d'hàbit amb millor relació esforç/benefici de tota la lliçó. La majoria de la gent tracta la documentació oficial com a últim recurs: prova primer un tutorial d'un blog, després una resposta de fòrum, i només quan res no funciona obre la documentació. Inverteix l'ordre.

La documentació de GitHub Actions (docs.github.com), de Terraform, de Docker, de Kubernetes (kubernetes.io) o de Prometheus és avui d'una qualitat que no tenia fa deu anys, inclou la semàntica exacta que un blog resumeix malament, i —crucialment— està actualitzada. La meitat dels problemes de la 06-06 amb contextos, permisos i workflow_run es resolen a la pàgina de referència corresponent, i cap resposta de fòrum del 2021 no et dirà que aquell comportament va canviar.

Llegeix-la com es llegeix un llibre, almenys una vegada per eina central: la pàgina de referència completa de la sintaxi del workflow, no només el fragment que buscaves. Dues hores invertides allà estalvien setmanes de conjectures.

Algunes empreses publiquen anàlisis detallades dels seus incidents greus. Són, per a l'operació, el que les autòpsies són per a la medicina: l'única manera d'estudiar com es trenquen els sistemes de debò, amb noms, temps i decisions equivocades incloses.

Què buscar-hi, amb la plantilla de la 03-05 a la mà:

• La cadena causal completa, no la «causa arrel» única. Gairebé sempre hi ha entre tres i set condicions que van haver de coincidir.
• Quant van trigar a detectar enfront de quant a arreglar. És habitual que el temps de detecció sigui més gran que el de reparació, cosa que diu molt sobre on invertir.
• Quin automatisme va empitjorar les coses. És un patró recurrent i una vacuna contra l'excés de confiança en el rollback automàtic de la 03-05.
• El to. Els bons post-mortems públics no tenen culpables, i es nota en com estan escrits.

Hi ha reculls comunitaris de post-mortems públics a GitHub; busca'ls per «postmortems» i veuràs anys de material. Llegir-ne un al mes durant un any ensenya més sobre operació que qualsevol curs.

Llegir l'especificació en lloc del resum és un d'aquells costums que separen qui sap de qui repeteix. Gairebé totes són curtes.

La regla: quan una eina t'obligui a triar entre dues opcions que no entens (CycloneDX o SPDX?), l'especificació t'ho resol en vint minuts i per sempre.

Realista significa: entre 30 i 45 minuts, tres dies per setmana. No més. Un pla que exigeix dues hores diàries s'abandona a la tercera setmana i produeix culpa en comptes de coneixement.

Mesos 1-2 — Continuous Delivery, en mode consulta. No el llegeixis sencer. Llegeix el capítol de la deployment pipeline, el de gestió de configuració i el d'estratègies de desplegament, i després de cadascun torna al teu PIPELINE.md i anota una discrepància. Lliurable: tres entrades noves en aquest document.

Mes 3 — Accelerate, complet. És curt. Llegeix-lo sencer, inclosa la part metodològica. Lliurable: una pàgina amb els arguments que faries servir davant d'algú com en Diego, amb les limitacions de l'estudi incloses i anticipades.

Mesos 4-5 — The Site Reliability Workbook, capítols d'SLO i alertes. Lliurable: revisar l'SLO que vas definir a la 07-04 i decidir si l'SLI triat mesura de debò el que li importa a l'usuari. Probablement no.

Mesos 6-7 — Release It!, complet. És el llibre que més gaudiràs amb producció ja en marxa. Lliurable: identificar al teu sistema almenys dos dels antipatrons del catàleg, i decidir si val la pena mitigar-los.

Mesos 8-9 — Tria branca segons cap on vagis (la 08-04 t'ajudarà a decidir): Feathers si treballes amb legacy, Newman si hi ha pressió per trossejar, Morris si la infraestructura creix, Team Topologies si et mous cap a la coordinació.

Mesos 10-12 — The DevOps Handbook per capítols + l'informe DORA de l'any. A aquestes altures ja tindràs experiència d'implantació real i el llibre deixarà de semblar obvi.

En paral·lel, tot l'any: un post-mortem públic al mes i la documentació oficial completa de les dues eines que més facis servir.

Si en algun moment vas endarrerit, no acceleris: salta. Un llibre llegit a fons amb el pipeline al davant val més que tres llegits per sobre.

• Col·leccionar llibres en lloc de llegir-los. Comprar-ne cinc alhora és una manera de posposar. Un d'obert, amb una pregunta escrita, i fins que no produeixi un canvi no arriba el següent.
• Llegir de cap a cap el que és material de consulta. Continuous Delivery, l'SRE Book i Software Engineering at Google estan dissenyats per saltar. Tractar-los com a novel·les és la manera més eficient d'abandonar-los.
• Confondre la data del llibre amb la seva validesa. Un llibre del 2010 pot ser exacte en principis i obsolet en eines. Separa sempre les dues capes en llegir: «això és una idea o una instrucció?».
• Fer servir Accelerate com a martell. Citar «els equips d'elit despleguen sota demanda» en una reunió no convenç ningú i t'exposa a la pregunta metodològica, que és legítima. Cita el mecanisme (lots petits, menys risc per desplegament) i dóna-hi suport amb les teves mètriques, no amb les d'una enquesta.
• Ignorar la documentació oficial perquè sembla avorrida. És la font amb millor relació senyal/soroll que existeix i l'única garantida al dia. Comença-hi.
• Buscar el llibre que et digui què fer. No existeix. Els llibres donen models; la decisió continua sent teva i depèn d'un context que cap autor no coneix. Un llibre que et diu exactament què fer sense conèixer el teu context t'està venent alguna cosa.
• Consell: escriu ressenyes d'una pàgina per a tu. Tres apartats: què defensa, què vaig canviar per haver-lo llegit, què no em va convèncer. D'aquí a dos anys aquesta pàgina valdrà més que el llibre rellegit.
• Consell: llegeix almenys un llibre amb el qual no estiguis d'acord. El pensament en aquesta disciplina té modes fortes, i aquest curs té una postura. Llegir una defensa seriosa de branques de llarga durada o de desplegaments programats t'obligarà a saber per què fas el que fas.

Tria dos llibres i una font viva per a cadascun d'aquests tres perfils, i justifica en cada cas quin problema concret resol l'elecció i què has descartat i per què:

a) Nuria, frontend/QA a Reservalia. Escriu proves E2E amb Playwright, la suite triga 25 minuts i té tres tests en quarantena des de fa un mes. Vol que les proves deixin de ser un impost.

b) Diego, backend, escèptic amb els costos. Accepta el pipeline però qüestiona cada minut de runner. Haurà de defensar el pressupost d'infraestructura davant de direcció el mes que ve.

c) Un desenvolupador júnior que s'incorpora a Reservalia, sap programar bé però no ha desplegat mai res a producció ni ha estat de guàrdia.

Un company acaba aquest mateix curs i et diu: «m'he comprat els quatre fonamentals, els llegiré seguits en tres mesos». Escriu la resposta que li donaries: què està malament en el pla, què li proposes en el seu lloc, i una pregunta concreta que hauria de portar escrita al primer llibre perquè la lectura li serveixi d'alguna cosa.

Tria un capítol de Continuous Delivery o de l'SRE Workbook que toqui una decisió que vas prendre al mòdul 7. Escriu mitja pàgina en el format: què diu el llibre / què vaig fer jo / per què difereixen / què faria diferent. La resposta vàlida pot ser «no canviaria res», però només si el motiu està escrit.

Solució 1

No hi ha una única combinació correcta; el que s'avalua és si l'elecció ataca el problema declarat i si el descart està raonat.

a) Nuria. Growing Object-Oriented Software, Guided by Tests i Software Engineering at Google (capítols de proves), més la documentació oficial de Playwright llegida sencera.

El problema real de la Nuria no és «escriure més proves»: és que les seves proves són lentes i fràgils, que són dos símptomes del mateix disseny. Tres tests en quarantena durant un mes és exactament el que la 02-04 descrivia com a deute de proves normalitzat. Freeman i Pryce ataquen la fragilitat des de l'arrel —com l'ús indiscriminat de dobles acobla el test a la implementació— i el capítol de proves de Google li dóna un marc de mides que li permetrà justificar moure feina d'E2E cap a nivells més barats, que és l'única manera real de baixar de 25 minuts. La documentació de Playwright, sencera, perquè gairebé tota suite E2E lenta ho és per no fer servir bé les esperes, l'aïllament i la paral·lelització que l'eina ja ofereix.

Descartat: Release It! — llibre excel·lent, però el seu problema és la producció, no la suite. Descartat: Accelerate — li donaria arguments, no solucions.

b) Diego. Accelerate complet i Software Engineering at Google (capítol de dependencies), més l'informe DORA de l'any en curs.

En Diego necessita munició per a una conversa amb direcció, i aquesta conversa no es guanya amb arguments tècnics sinó amb evidència i amb llenguatge de negoci. Accelerate és literalment el llibre escrit per a això, i la part metodològica li serveix doblement: com a escèptic, serà qui detecti els forats de l'estudi, i és molt millor que els detecti ell abans que el seu interlocutor. L'informe de l'any li dóna els números actuals en comptes dels del llibre. El capítol de dependencies de Google encaixa amb la seva preocupació pel cost perquè explica el cost acumulat en el temps de decisions que avui semblen gratis, que és l'argument més difícil de fer i el que més falta li fa.

Descartat: The Phoenix Project — és el llibre per donar a direcció, no per llegir en Diego, que ja està convençut de la part tècnica. Tot i que una resposta igualment vàlida seria recomanar-li que el regali al seu interlocutor.

c) El júnior. The Phoenix Project i Release It!, més un post-mortem públic al mes.

Aquí el criteri s'inverteix: el júnior no té context, així que necessita narrativa abans que tècnica. The Phoenix Project li dóna en un cap de setmana el mapa de per què existeix tot això, que és just el que a un bon programador sense experiència de producció li falta. Release It! li ensenya que el codi correcte i el sistema estable són coses diferents —la lliçó més cara d'aprendre per experiència—. I els post-mortems públics són el substitut més eficient de les guàrdies que encara no ha fet.

Descartat: Continuous Delivery — sense haver patit un desplegament manual, els seus arguments li semblaran obvis i no aprendrà res. Descartat: Accelerate — necessita entendre el problema abans que les dades sobre el problema.

Solució 2

Què està malament. Tres coses.

1. Ritme irreal. Els quatre sumen més de 1.500 pàgines denses. Tres mesos són unes 13 setmanes: 115 pàgines tècniques per setmana sostingudes. S'abandona a la quarta.
2. Mode equivocat. Almenys dos dels quatre (Continuous Delivery i l'SRE Workbook) són material de consulta. Llegir-los linealment maximitza l'esforç i minimitza la retenció.
3. I l'error de fons: no hi ha pregunta. Llegir «els quatre fonamentals» és un objectiu d'acumulació. Res en aquest pla no produeix un canvi en cap sistema, així que al cap de sis mesos tindrà quatre títols a la prestatgeria i cap criteri nou.

Què li proposes. Un llibre cada dos mesos, amb ordre segons el seu problema actual: si acaba de muntar un pipeline, Continuous Delivery per capítols; si ha de justificar la inversió, Accelerate primer; si ja opera alguna cosa en producció, el Workbook. I una regla dura: no passa al capítol següent sense haver escrit una entrada al seu PIPELINE.md, sigui un canvi o un descart raonat.

La pregunta escrita. Ha de ser específica i del seu sistema. Per exemple: «El meu pas de promoció a producció reconstrueix alguna cosa, o desplega exactament el mateix digest que es va verificar a staging? Si reconstrueix, què m'hi estic jugant?». Amb aquesta pregunta, el capítol de la deployment pipeline es llegeix en 40 minuts i produeix una decisió. Sense ella, es llegeix en quatre hores i produeix la sensació d'haver llegit alguna cosa.

Solució 3

Exemple de resposta vàlida, sobre el capítol d'estratègies de desplegament enfront de la decisió presa a Mini-Reservalia:

Què diu el llibre. Continuous Delivery defensa blue-green com a estratègia per defecte per a serveis amb estat, per la reversibilitat gairebé instantània i perquè permet verificar l'entorn nou amb trànsit real abans de commutar.

Què vaig fer jo. A Mini-Reservalia vaig fer servir rolling amb health checks i un rollback.yml manual per digest, amb un temps de recuperació mesurat d'uns 4 minuts.

Per què difereixen. Blue-green duplica la infraestructura durant la finestra de commutació, i la restricció de cost de Mini-Reservalia (pressupost zero) ho fa inviable. A més, el llibre és anterior als orquestradors moderns: parteix que un rolling manual és arriscat, mentre que avui el health check i el reemplaçament gradual són primitives del mateix orquestrador, no una cosa que jo hagi de construir. El risc que blue-green mitiga està parcialment cobert.

Què faria diferent. Res avui, però amb una condició escrita: si l'SLO comença a consumir pressupost d'error per fallades detectades els primers minuts després del desplegament —és a dir, si el rolling deixa passar problemes que un blue-green hauria contingut—, la decisió es revisa. Això passa al PIPELINE.md com a decisió amb data i condició de revisió, que és el format que la 07-06 exigia.

El que fa vàlida aquesta resposta no és la conclusió, sinó que la discrepància estigui anomenada, explicada pel context i amb una condició que la reobri.

Ara tens dues coses que no tenies fa set mòduls: un sistema real sobre el qual provar idees i el vocabulari per entendre el que els llibres diuen sobre ell. Aquesta combinació és el que converteix una bibliografia en una eina.

Recapitulant l'essencial:

• Es llegeix per decidir, no per acumular. Pregunta escrita abans d'obrir el llibre, i canvi o descart raonat després de tancar-lo.
• Els quatre fonamentals cobreixen el fonament tècnic (Continuous Delivery), l'evidència empírica (Accelerate), la implantació organitzativa (The DevOps Handbook) i l'operació mesurable (The Site Reliability Workbook). Cap no és un manual; tots quatre tenen parts envellides i saber quines forma part de llegir-los bé.
• Els llibres per temes s'obren quan el problema apareix, no abans: Feathers quan arribi el legacy, Newman quan arribi la pressió de trossejar, Morris quan la infraestructura creixi.
• Les fonts vives —l'informe DORA llegit amb escepticisme estadístic, martinfowler.com, la documentació oficial com a primera parada i no com a última, els post-mortems públics, les especificacions curtes— envelleixen molt millor que els llibres i costen menys temps.
• Un pla de 12 mesos realista són 30-45 minuts tres dies per setmana, amb lliurables verificables. Si vas endarrerit, saltes; no acceleres.

Els llibres donen el fonament i les especificacions donen la precisió, però hi ha una classe de coneixement que cap dels dos no conté: el que depèn del context. Per què a la teva empresa concreta, amb el teu núvol concret i la teva versió concreta d'una eina, alguna cosa que hauria de funcionar no funciona. Això no està escrit enlloc perquè canvia massa ràpid perquè valgui la pena escriure-ho, i viu únicament al cap de gent que ja hi ha topat.

Trobar aquesta gent, saber preguntar-los i tornar-los alguna cosa a canvi és la lliçó següent: 08-02, Comunitats i Fòrums.