La lliçó anterior et va donar el marc que diu com hauria d'estar feta una arquitectura. Aquesta cobreix l'altra meitat de l'ofici, que s'aprèn molt més a poc a poc i gairebé sempre pagant: com es fan malament. No amb exemples abstractes, sinó amb el catàleg concret d'errors que apareixen una vegada i una altra en organitzacions de totes les mides, explicats amb el seu símptoma, amb el que costa corregir-los quan ja estan instal·lats i amb la prevenció que els hauria evitat per una fracció d'aquest preu.

Hi ha una asimetria que justifica la lliçó sencera: gairebé tots aquests errors costen poc de prevenir i molt d'arreglar. Etiquetar des del primer dia és gratis; retroetiquetar dos-cents recursos són setmanes de feina. Treure un secret a Key Vault abans d'escriure la primera línia és mitja hora; fer-ho després que hagi estat sis mesos a l'historial del repositori implica rotar-lo, auditar accessos i no poder demostrar que ningú no el va fer servir.

La lliçó recorre sis famílies —cost, seguretat, arquitectura, operació, governança i dades—, dedica un apartat als quatre errors que l'equip de Contoso sí que va cometre durant el curs i com els va detectar, i tanca amb els senyals d'alarma que anticipen cada família abans que el problema sigui visible a la factura o en un incident.

Recordatori: les xifres en euros són orientatives i fictícies, i il·lustren ordres de magnitud, no preus reals.

1. Per què un catàleg d'errors
2. Errors de cost
3. Errors de seguretat
4. Errors d'arquitectura
5. Errors d'operació
6. Errors de governança i organització
7. Errors amb les dades
8. Els quatre errors que Contoso sí que va cometre
9. Senyals d'alarma
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió

Tres raons per les quals aquests errors es repeteixen en organitzacions que ja coneixen la teoria:

• El núvol castiga tard. Crear una màquina sobredimensionada no falla: funciona perfectament i la factura arriba trenta dies després. El que no dona error immediat no es corregeix.
• L'urgent desplaça l'important. Ningú no planeja deixar un secret al codi: es deixa «només per a la demostració de dijous» i no es torna a mirar.
• El cost de l'error creix de manera no lineal. Una convenció de noms és trivial amb deu recursos, incòmoda amb cent i inassumible amb cinc-cents.
• Ningú no veu l'error des de dins. L'equip que va construir el sistema n'ha normalitzat les raresses; per això les revisions creuades i els catàlegs com aquest troben coses que porten anys a la vista de tothom.

Per això el patró de les taules següents és sempre el mateix: error → símptoma → cost d'arreglar-ho tard → prevenció. La columna que més convé llegir és la tercera.

El multiplicador depèn gairebé completament del moment en què es detecta:

La conclusió operativa no és «cal ser més curós», que no és accionable: és moure la detecció cap amunt a la taula amb mecanismes automàtics —directives, plantilles, anàlisi a la canalització, llistes de comprovació de disseny—.

El més car de la llista no és cap en concret: és no tenir pressupost amb alerta, perquè converteix qualsevol dels anteriors en un problema que es descobreix un trimestre tard.

Val la pena veure l'asimetria amb números orientatius. Un disc de 512 GB orfe costa de l'ordre de 40 €/mes: passa desapercebut. Vint discos orfes acumulats durant dos anys de migracions són uns 19.000 € gastats en no res, i en aquell moment ningú no sap ja de qui era cadascun, així que esborrar-los exigeix una investigació que costa més hores que el mateix estalvi del primer mes. L'error no va ser el disc: va ser no tenir etiqueta de propietari i no mirar mai. La prevenció hauria costat una directiva i una consulta mensual de deu línies.

Un matís sobre el primer, que és el més freqüent: treure el secret del codi no l'elimina de l'historial. Si va estar publicat, cal considerar-lo compromès i rotar-lo, encara que el commit que el va esborrar sembli resoldre el problema.

I un matís sobre el sisè, que és el que produeix els incidents més greus amb menys sofisticació: els ports d'administració exposats no els troba un atacant, els troba un escàner automàtic. No cal ser un objectiu interessant ni tenir dades valuoses; n'hi ha prou amb tenir una adreça IP pública amb el port 3389 o el 22 oberts. Per això la mitigació correcta mai no és «posar una contrasenya més llarga», sinó eliminar l'exposició: accés mitjançant Bastion, accés just a temps o xarxa privada, de manera que el port simplement no existeixi des d'internet.

Els dos últims semblen oposats i són el mateix error: no ajustar l'arquitectura al problema real. Un peca per defecte i l'altre per excés, i tots dos es detecten amb la mateixa pregunta —quin problema concret i mesurat resol aquesta peça?—.

L'acoblament síncron mereix un dibuix, perquè és l'error d'arquitectura que més incidents causa i el més fàcil de no veure en un diagrama mal fet:

A la versió acoblada, un servei de correu lent bloqueja la venda: el client veu un error en comprar per culpa d'un component que ni tan sols necessitava resposta. És exactament la raó per la qual Contoso va posar sb-contoso-pro entre la confirmació de la reserva i tot el que passa després. La regla és senzilla i s'aplica al disseny, no després: si qui truca no necessita la resposta per contestar a l'usuari, no l'ha d'esperar.

De tots ells, el segon és el més traïdor perquè sembla diligència. Un equip que alerta de tot creu que està sent curós, però l'efecte real és el contrari: quan arriben dos-cents avisos al dia, el cervell humà aprèn a ignorar-los, i el dia que arriba l'avís important ja ningú no el llegeix. La fatiga d'alertes no es corregeix explicant a la gent que miri més: es corregeix esborrant alertes. Un criteri útil per decidir quines sobreviuen: una alerta ha de descriure un símptoma que l'usuari nota i portar associada una acció concreta que algú pugui executar a les tres de la matinada. Si no compleix les dues coses, és un tauler, no una alerta.

Un segon criteri, sobre el desplegament del divendres: el problema no és el dia, és l'asimetria entre la probabilitat de fallada i la disponibilitat de qui la pot arreglar. Amb reversió provada en segons —una ranura, un desplegament progressiu— desplegar un divendres deixa de ser perillós. La prohibició del divendres és una tireta; el pla de reversió és la cura.

Els dos últims estan connectats i expliquen per què la governança falla fins i tot quan existeix. Si crear un recurs legítim requereix obrir un tiquet i esperar cinc dies, la gent troba la manera de saltar-s'ho: fa servir la subscripció de proves, demana permisos temporals que ningú no retira o crea a mà el que hauria d'anar a la plantilla. La governança que només prohibeix genera evasió; la que funciona prohibeix el que és perillós i facilita el que és correcte, amb plantilles Bicep que ja porten les etiquetes, la xarxa i els diagnòstics posats. Dit d'una altra manera: si el camí correcte no és també el camí fàcil, la directiva perdrà contra el calendari del projecte.

Dos d'aquests errors tenen una propietat que no comparteixen els altres: són irreversibles a la pràctica. Canviar la clau de partició d'un contenidor de Cosmos DB no és una operació de configuració, és crear un contenidor nou i migrar les dades amb l'aplicació en marxa; i triar el motor equivocat es corregeix amb una migració de dades a producció, que és el tipus de projecte que consumeix trimestres. Tota la resta d'aquesta lliçó s'arregla amb diners i temps; aquests dos s'arreglen amb un projecte. Per això són les dues decisions que més mereixen una revisió de disseny formal abans d'escriure la primera línia, amb la pregunta concreta sobre la taula: quina serà la consulta més freqüent d'aquí a dos anys, i aquest disseny la serveix bé?

Advertiment important: el tractament de dades personals està subjecte al RGPD i a normativa sectorial. Res del que apareix en aquest curs no constitueix assessorament legal: qualsevol decisió sobre exportació, retenció, anonimització o transferència de dades personals l'ha de revisar l'equip legal o de compliment de l'organització abans d'implementar-se.

Cap equip no aprèn això llegint-ho. Contoso tampoc: aquests són els errors reals de la plataforma que has construït, amb com es van detectar.

Convé afegir-hi un cinquè que no va arribar a ser un problema perquè es va detectar a temps, i que il·lustra com funciona la prevenció quan funciona: en preparar la primera compra de compromisos, algú va proposar reservar tres anys sobre el dimensionament vigent. La Nuria va demanar esperar a tenir tres mesos d'ús estable, i l'optimització posterior va reduir la plataforma de 17.800 € a 12.550 €/mes. Reservar abans hauria congelat durant tres anys una mida que va resultar estar un 29 % per sobre de la necessària. L'única raó per la qual no va ser un error és que existia una regla escrita —optimitzar abans de comprometre's— i algú amb autoritat per invocar-la.

El que tenen en comú els quatre: cap no va ser una mala elecció tècnica. Cosmos, SQL, App Service i Service Bus eren les peces correctes. El que va fallar va ser l'ordre i l'absència d'un mecanisme que avisés aviat: pressupost, informe mensual, directiva, plantilla. És la lliçó més transferible d'aquest mòdul.

I una consulta que convé tenir a mà, la que la Marta executa cada mes perquè el tercer error no torni:

Cada família d'errors emet senyals abans de convertir-se en incident o en factura. Aquests són els que convé vigilar:

Hi ha a més tres senyals transversals, que no pertanyen a cap família i que solen precedir problemes de diverses alhora:

• La por de desplegar. Si l'equip posposa els desplegaments o els agrupa en lliuraments grans «per no arriscar», la causa real és que no hi ha reversió fiable. Prediu incidents llargs.
• La persona imprescindible. Si hi ha una tasca que només sap fer una persona, aquesta tasca no està automatitzada ni documentada. Prediu problemes d'operació tan bon punt hi hagi vacances o una baixa.
• La resposta «això ho revisem després». Repetida tres vegades sobre el mateix assumpte, descriu una decisió presa per omissió. Prediu deute al pilar que s'estigui posposant, sigui quin sigui.

Regla general que resumeix les sis: quan la resposta a «per què està això així?» és «no ho sé» o «sempre ha estat així», hi ha deute. No sempre urgent, però sempre real, i sempre més barat de pagar avui que d'aquí a un any.

Sobre l'ús d'aquest catàleg, que també té la seva manera de sortir malament:

• Fer servir la llista per assenyalar culpables. Un catàleg d'errors serveix per prevenir, no per auditar persones; tan bon punt es converteix en arma, ningú no torna a reconèixer un problema.
• Intentar corregir-ho tot alhora. Prioritza per conseqüència i per cost de correcció: primer el que és catastròfic i barat d'arreglar.
• Confondre un error amb un compromís. No tenir multiregió actiu-actiu no és un error si està escrit i decidit; sí que ho és si ningú no hi ha pensat mai.
• Corregir el cas i no la causa. Esborrar el disc orfe no evita el següent; la consulta mensual i l'etiqueta obligatòria, sí.
• Prevenir només amb documentació. El que es pot impedir amb una directiva o una plantilla no hauria de dependre que algú recordi llegir una guia.
• Consell: quan alguna cosa falli, pregunta «quin mecanisme ho hauria detectat abans?» en lloc de «qui ho ha fet?». La primera pregunta produeix millores; la segona, silenci.
• Consell: mantén un registre d'incidents i errors propis amb la correcció aplicada. És més útil per a la teva organització que qualsevol llista general, inclosa aquesta.
• Consell: revisa aquest catàleg sencer una vegada l'any amb l'equip, marcant cada fila en verd, ambre o vermell. Sol sortir alguna sorpresa.
• Consell: quan entris en una organització nova, comença per quatre comprovacions que caben en un matí i detecten la major part del deute greu: s'ha restaurat alguna còpia?, hi ha secrets als repositoris?, qui té propietari permanent?, existeix pressupost amb alerta? Les respostes dibuixen la resta del mapa.

Exercici 1. Una empresa et contracta per revisar la seva plataforma a Azure i hi trobes: una subscripció única amb producció i proves, tres persones amb paper de propietari permanent, secrets a la configuració de les aplicacions, sense etiquetes, sense pressupost, còpies configurades però mai restaurades, RDP obert en dues màquines d'administració i una factura de 9.000 €/mes que ningú no sap explicar. Prioritza les intervencions: ordena els problemes per conseqüència potencial dividida pel cost de correcció, justifica l'ordre i defineix què faries la primera setmana, el primer mes i el primer trimestre.

Exercici 2. Analitza els quatre errors que va cometre Contoso i respon: per a cadascun, quin mecanisme concret —directiva, alerta, plantilla, revisió o consulta— l'hauria detectat la primera setmana en lloc de mesos després? Després, generalitza: proposa el conjunt mínim de cinc mecanismes que instal·laries el primer dia de qualsevol plataforma nova perquè aquests errors no puguin durar.

Exercici 3. Un equip proposa migrar la seva aplicació a AKS perquè «així estem preparats per escalar». L'aplicació és un monòlit amb estat en sessió, 300 usuaris interns, sense pics, desplegat avui en dues màquines virtuals. Identifica tots els errors d'aquesta lliçó que la proposta conté o provocaria, formula les preguntes que faries a l'equip i proposa l'alternativa que defensaries, amb la seva justificació per pilars.

Solució 1: el criteri d'ordre és conseqüència potencial dividida pel cost de correcció, no gravetat teòrica. Primera setmana —catastròfic i barat—: (1) restaurar una còpia en un entorn a part, perquè «còpies mai provades» equival a no tenir còpies i la comprovació costa hores; (2) tancar RDP a les dues màquines i substituir-lo per Bastion o accés just a temps, perquè un port d'administració exposat s'explota de manera automatitzada i el tancament és immediat; (3) crear un pressupost amb alertes sobre la factura de 9.000 €, que es fa en deu minuts i atura el creixement a cegues; (4) activar MFA si no ho estigués. Primer mes —alt impacte, esforç mitjà—: (5) treure els secrets a Key Vault amb identitats administrades, començant pels de producció, amb rotació posterior perquè s'han de considerar compromesos; (6) reduir els propietaris permanents a un d'emergència i passar la resta a papers mínims amb PIM; (7) implantar etiquetes obligatòries per directiva i etiquetar el que ja existeix, sense la qual cosa no es pot començar a explicar la factura; (8) revisar les cinc partides més grans de la factura i buscar orfes i infrautilització amb Advisor i Resource Graph. Primer trimestre —estructural—: (9) separar producció i no producció en dues subscripcions sota grups d'administració, amb la iniciativa de governança assignada; (10) canalització de desplegament amb reversió; (11) alertes i tauler mínim d'observabilitat; (12) documentar el plànol i les decisions. Justificació de l'ordre: el de la primera setmana evita pèrdues irreversibles —dades, compromís d'identitat— amb cost gairebé nul; el del mes elimina les exposicions més probables; el del trimestre corregeix l'estructura, que és el que és car i el que exigeix coordinació.

Solució 2: mecanismes que haurien detectat cada error en dies. Factura duplicada: un pressupost amb alerta al 80 % sobre l'estimació de 8.500 € hauria disparat un avís les primeres setmanes, més la detecció d'anomalies de Cost Management; el problema no va ser estimar malament —estimar malament és normal—, va ser no tenir un mecanisme que comparés estimació amb realitat de manera contínua. VM sobredimensionada: una revisió mensual d'Advisor amb propietari assignat, o una alerta de mètrica sobre CPU mitjana per sota d'un llindar durant 14 dies; també hauria bastat una data de caducitat per etiqueta als recursos creats com a prova. Manca d'etiquetes: una directiva en mode denegar sobre centro-coste i propietario al grup d'administració arrel, més la consulta mensual de Resource Graph de l'apartat 8; la clau és que la directiva actua en el moment de la creació, quan corregir costa zero. Ordre invertit: un bloqueig de creació manual a producció —permisos d'escriptura només per a la connexió de servei de la canalització— converteix l'error en impossible en lloc de en detectable. Conjunt mínim de cinc mecanismes per al primer dia de qualsevol plataforma: (1) jerarquia de subscripcions amb una iniciativa de directives que exigeixi etiquetes, restringeixi regions, prohibeixi blobs públics i obligui a HTTPS; (2) pressupost amb alertes i detecció d'anomalies; (3) identitats administrades i magatzem de secrets com a norma, amb anàlisi de secrets a la canalització; (4) infraestructura com a codi amb desplegament exclusiu per canalització, sense permisos d'escriptura manuals a producció; (5) observabilitat mínima amb còpies provades: una àrea de Log Analytics, tres alertes accionables i una restauració de prova agendada. Amb aquests cinc, cap dels quatre errors de Contoso no pot durar més d'una setmana.

Solució 3: errors presents o provocats. Triar Kubernetes per moda —el motiu declarat, «estar preparats per escalar», no descriu cap problema mesurat: 300 usuaris interns i sense pics—. Monòlit amb estat que no escala: la sessió en memòria significa que l'escalat horitzontal no funciona avui, així que AKS no resoldria res; es pagaria el clúster per continuar amb una sola instància útil. Sobrearquitecturar: complexitat d'operació —actualitzacions del clúster, xarxes, quotes, RBAC de Kubernetes, observabilitat pròpia— per a una càrrega trivial. Errors d'operació derivats: ningú de l'equip no opera Kubernetes avui, de manera que s'afegeix un punt de fallada la recuperació del qual depèn d'un coneixement que no existeix. Cost: el clúster amb nodes permanents gairebé segur que costa més que les dues màquines actuals. Preguntes a l'equip: quin problema mesurat resol això —latència, indisponibilitat, cost, temps de lliurament—? Quin escalat es preveu i amb quina dada de creixement? On viu avui la sessió i qui la traurà del procés? Qui operarà el clúster, farà les actualitzacions i estarà de guàrdia? Quant costa la proposta al mes davant de la situació actual? Alternativa que defensaria: contenidoritzar l'aplicació i desplegar-la a App Service o Container Apps, després de treure l'estat de sessió a un magatzem extern. Justificació per pilars: fiabilitat, permet diverses instàncies de debò i redundància de zona sense operar res; excel·lència operativa, desplegament amb ranura i reversió immediata, sense actualitzacions de clúster; cost, una fracció del d'AKS i amb escalat a zero a Container Apps si la càrrega és interna i horària; rendiment, escalat automàtic suficient per a un creixement d'un ordre de magnitud; seguretat, menys superfície per administrar. I l'observació decisiva: la feina valuosa de la proposta —treure l'estat de la sessió— és exactament la mateixa en tots dos camins, així que convé fer-la primer i decidir el destí després, amb dades.

Ja tens el catàleg honest del que surt malament, organitzat en sis famílies i presentat sempre amb la mateixa estructura —error, símptoma, cost d'arreglar-ho tard i prevenció—, perquè la columna del cost és la que convenç una organització d'actuar abans. En cost: dimensionar pel pic, orfes, no etiquetar, reservar abans d'estabilitzar, la sortida de dades i la ingesta de registres sense control. En seguretat: secrets al codi, propietari per a tothom, blobs públics, secrets sense rotar, MFA opcional, ports d'administració oberts i el tauler de Defender que ningú no mira. En arquitectura: el lift-and-shift etern, el monòlit amb estat, el punt únic de fallada, l'acoblament síncron, Kubernetes per moda, no dissenyar per a la fallada i el seu bessó oposat, sobrearquitecturar. En operació: no monitorar, alertar de tot, no provar les còpies, no documentar, el desplegament manual del divendres i l'absència de pla de reversió. En governança: sense convencions, sense política, subscripció única, permisos temporals eterns i ningú propietari del cost. I en dades: el motor triat per costum, la clau de partició que a Cosmos DB ja no es canvia, el creixement no planificat, l'absència de cicle de vida i les dades personals tractades sense base legal —amb l'advertiment que això ho valida l'equip legal, no l'equip tècnic—.

Has vist els quatre errors que Contoso sí que va cometre —la factura duplicada de 8.500 a 17.500 €, la màquina de desenvolupament un any al 3 %, les etiquetes que van arribar tard i l'ordre invertit entre recursos i governança— amb la forma exacta en què es van detectar i el que tenen en comú: cap no va ser una mala elecció tècnica; va ser manca de mecanisme i d'ordre. I t'endus els senyals d'alarma per família, amb la regla que els resumeix: quan la resposta a «per què està això així?» és «sempre ha estat així», hi ha deute esperant.

Queda un assumpte que aquest mòdul ha anat voltant i que no és tècnic: Contoso encara té sistemes a Barcelona. La facturació heretada, el directori local i el manteniment de flota continuen en un centre de dades amb contracte a punt de vèncer, i moure'ls no és un projecte d'infraestructura: és un canvi organitzatiu. La lliçó següent aborda com es migra una organització sencera amb el Cloud Adoption Framework —estratègia, pla, preparació, adopció i governança—, amb Azure Migrate per a l'inventari, les sis estratègies de migració, les zones d'aterratge, les onades i la seva finestra de tall, la migració de les dades, la tornada enrere, la gestió del canvi i la retirada del centre de dades amb els seus costos ocults.