A la lliçó anterior vas dibuixar el plànol complet de Contoso Airlines i la taula de decisions que el sosté. Queda la pregunta incòmoda: està bé? Qualsevol pot defensar la seva pròpia arquitectura —sempre hi ha un motiu per al que un mateix va decidir—, i per això les organitzacions necessiten un llenguatge comú, aliè a l'orgull de qui va dissenyar cada peça, per discutir si una plataforma se sosté.

Aquest llenguatge és l'Azure Well-Architected Framework: cinc pilars, un conjunt de principis de disseny per pilar i, sobretot, un mètode per trobar el deute arquitectònic abans que esclati. No és una certificació ni una llista de serveis obligatoris: és un conjunt de preguntes que qualsevol pot fer a qualsevol arquitectura, inclosa la seva.

Aquesta lliçó recorre els cinc pilars auditant la plataforma de Contoso pilar per pilar —què compleix, què no compleix i què es va decidir conscientment no fer—, s'atura en el que el marc té de més valuós, que són els compromisos entre pilars, converteix la revisió en un procés amb participants, freqüència i pla d'acció, i acaba amb una llista de comprovació que et pots endur a la teva pròpia feina demà mateix.

Avís de nomenclatura: en aquest curs «WAF» ha significat fins ara tallafoc d'aplicacions web (wafcontosoglobal). El Well-Architected Framework en comparteix les sigles per accident. Per evitar confusions, en aquesta lliçó se l'anomena sempre Well-Architected o «el marc».

1. Què és el marc i per a què serveix de debò
2. Els cinc pilars d'un cop d'ull
3. Fiabilitat
4. Seguretat
5. Optimització de costos
6. Excel·lència operativa
7. Eficiència del rendiment
8. Els compromisos entre pilars
9. La revisió Well-Architected com a procés
10. Eines: l'avaluació oficial i Azure Advisor
11. Guies per a càrregues de treball específiques
12. El marc en el dia a dia
13. Llista de comprovació d'arquitectura
14. Errors Comuns i Consells
15. Exercicis
16. Conclusió

El Well-Architected Framework és una guia de Microsoft que estructura el disseny i la revisió de càrregues de treball —no de subscripcions senceres, sinó de sistemes concrets amb propietari i usuaris— al voltant de cinc pilars. Cada pilar aporta principis de disseny, llistes de comprovació, recomanacions i compromisos coneguts.

Les seves tres utilitats reals, per ordre d'importància:

1. Llenguatge comú. Quan algú diu «això és deute de fiabilitat» en lloc de «això està mal fet», la conversa deixa de ser personal. El marc converteix opinions en categories.
2. Detecció primerenca. Les preguntes del marc troben l'absència de pla de reversió, la còpia mai restaurada o el secret sense rotació abans que un incident els descobreixi a les tres de la matinada.
3. Explicitar els compromisos. Cap sistema no puntua alt en els cinc pilars alhora. El marc obliga a dir en veu alta què s'està sacrificant i a canvi de què.

I dues coses que no és, i convé saber-ho abans de començar: no és una llista de requisits que calgui complir al 100 % —una plataforma que complís tot seria caríssima i inmanejable—, i no substitueix el criteri: el marc pregunta, la resposta la posa el context de negoci.

Principis de disseny: dissenyar per a la fallada assumint que tot component caurà; definir objectius mesurables de disponibilitat, RPO i RTO acordats amb negoci; afegir redundància a la capa correcta; fer servir reintents, temps d'espera i tallacircuits; simplificar, perquè cada dependència afegeix probabilitat de fallada; i provar la recuperació, perquè una còpia no restaurada no és una còpia.

Principis de disseny: confiança zero —no confiar en la xarxa, verificar sempre—; mínim privilegi; defensa en profunditat; xifratge en trànsit i en repòs; cap credencial al codi; segmentació; i detecció amb capacitat de resposta.

Principis de disseny: adequar la despesa al valor de negoci; modelar i preveure el cost abans de construir; mesurar amb un indicador unitari; optimitzar abans de comprometre's; i fer del cost una responsabilitat compartida, no una auditoria anual.

Principis de disseny: infraestructura com a codi; automatitzar tot el que és repetitiu; desplegaments petits, freqüents i reversibles; observabilitat d'extrem a extrem; documentació viva; i cultura sense culpa amb anàlisi posterior als incidents.

Principis de disseny: escalar horitzontalment abans que verticalment; mesurar abans d'optimitzar; triar el model de dades pel patró d'accés; fer servir memòria cau on la dada ho tolera; processar de manera asíncrona el que no necessita resposta immediata; i proves de càrrega que reprodueixin el pic previst.

Aquí hi ha el veritable valor del marc. Cap decisió no millora els cinc pilars alhora; gairebé totes en milloren un i n'empitjoren un altre, i la feina de l'arquitecte és triar quin, no fingir que no passa.

Regla pràctica que convé memoritzar: un compromís només és legítim si està escrit, té propietari i té data de revisió. El que no està escrit no és un compromís, és un descuit amb bona premsa.

Una revisió no és una reunió de dues hores on algú ensenya un diagrama. És un procés amb participants, guió i sortida.

Com es puntua, sense caure en la trampa del número: l'avaluació oficial produeix una puntuació per pilar, útil com a línia base per comparar-te amb tu mateix d'aquí a sis mesos, i inútil com a objectiu. Perseguir el 100 % porta a aplicar recomanacions que no pertoquen —exactament el mateix error que perseguir la puntuació d'Advisor al mòdul 8—.

El resultat de la revisió de Contoso, prioritzat per risc per unitat d'esforç:

Observeu el que no és a la llista: multiregió actiu-actiu, proves de caos i registre inalterable. No perquè no importin, sinó perquè la seva relació cost-benefici, en aquest context i aquest trimestre, és pitjor que la de les cinc anteriors. Una revisió que produeix vint accions no en produeix cap.

L'avaluació Well-Architected és un qüestionari guiat que recorre els pilars, permet marcar preguntes com a no aplicables i genera un informe amb recomanacions i enllaços a documentació. És autoavaluació: la seva qualitat depèn completament de l'honestedat de qui respon, així que convé fer-la en grup i no en solitari.

Es complementen exactament en el seu punt cec: Advisor mai no dirà «no tens pla de reversió» i l'avaluació mai no dirà «aquesta màquina porta catorze dies al 3 %». Totes dues comparteixen els cinc pilars com a taxonomia, cosa que permet abocar les recomanacions d'Advisor directament al pilar corresponent de la revisió.

A més dels cinc pilars genèrics, el marc publica guies especialitzades que apliquen els mateixos principis a un tipus concret de càrrega. Val la pena saber que existeixen i consultar-les quan pertoqui:

La guia de missió crítica és especialment instructiva encara que no la necessitis: llegir-la ensenya quant costa de debò el «zero aturades» i, gairebé sempre, convenç que 99,9 % amb RTO de 4 h era la decisió correcta.

Un marc que només es fa servir una vegada l'any és un ritual. La manera que serveixi és partir-lo en dos punts de contacte petits:

• A la revisió de disseny, abans de construir: cinc preguntes, una per pilar, respostes en una pàgina. Què passa si això falla? Qui hi pot accedir i amb quina credencial? Quant costarà al mes? Com es desplega i com es reverteix? Quina càrrega suporta i com escala?
• A la sol·licitud d'incorporació de canvis, com a plantilla d'una sola línia per pilar. No és burocràcia si cap a la plantilla del repositori i es respon en un minut.

Per endur-se i fer servir en qualsevol projecte, no només en aquest curs.

Fiabilitat: hi ha RPO i RTO escrits i acordats amb negoci? Quin component és un punt únic de fallada? Quina dependència síncrona es podria fer asíncrona? Hi ha reintents amb retrocés i temps d'espera? S'ha restaurat alguna còpia aquest semestre? Està provat el pla de recuperació?

Seguretat: hi ha alguna credencial fora d'un magatzem de secrets? Algú té propietari permanent? Hi ha alguna dada accessible des d'internet? L'MFA és obligatori per a tothom? Es revisen els accessos periòdicament? Es xifra en trànsit i en repòs? Hi ha detecció activa i algú que la miri?

Cost: existeix pressupost amb alerta? Està tot etiquetat amb propietari i centre de cost? Quin és el cost unitari i cap on va? Quins recursos porten un mes sense ús? Es va optimitzar abans de comprometre's? Estan escrites les retallades rebutjades?

Excel·lència operativa: es pot recrear l'entorn des de codi? Es desplega sense intervenció manual? Quant es triga a revertir? Quina alerta hauria detectat l'últim incident? Està l'arquitectura documentada i actualitzada?

Eficiència del rendiment: quin és l'objectiu de latència i es mesura? Escala automàticament i s'ha provat amb el pic? El model de dades correspon al patró d'accés? Què es pot guardar a la memòria cau sense arriscar la correcció? Què es pot fer asíncron?

• Tractar el marc com una llista d'obligacions. Complir-ho tot és caríssim; el marc pregunta, el negoci respon.
• Perseguir la puntuació. La puntuació serveix per comparar-se amb un mateix, no per presumir ni per fixar objectius.
• Revisar tot el núvol alhora. Es revisa una càrrega de treball; una revisió de «tot» no produeix accions concretes.
• Fer l'avaluació en solitari. El biaix de qui va dissenyar el sistema anul·la el resultat; cal algú que pregunti «i si això cau?».
• No incloure-hi negoci ni finances. Sense ells no es poden decidir compromisos, i tota la revisió queda en teoria.
• Sortir amb vint accions. Cinc amb propietari i data valen més que vint en un full de càlcul.
• No registrar el que es decideix no fer. És la informació que més s'enyora un any després.
• Consell: fes la primera revisió abans de construir, quan canviar d'idea és gratis.
• Consell: guarda l'informe de cada revisió al repositori, amb data. La comparació entre dues revisions ensenya més que qualsevol de les dues.
• Consell: quan algú proposi alguna cosa que millori un pilar, pregunta sempre en veu alta quin pilar empitjora. Si la resposta és «cap», falta anàlisi.

Exercici 1. Pren tres decisions concretes de la plataforma de Contoso —el WAF en mode prevenció, la rèplica fg-contoso-reservas i l'apagada nocturna dels entorns de desenvolupament— i analitza cadascuna com a compromís: quin pilar millora, quin pilar empitjora, com es quantifica cada costat i en quines condicions de negoci la decisió s'hauria d'invertir.

Exercici 2. Ets responsable d'una plataforma de comerç electrònic amb 20.000 comandes al mes, una sola regió, App Service, SQL Database i desplegaments manuals des del portal els divendres. No hi ha còpies provades, els secrets són a la configuració de l'aplicació i no hi ha pressupost de cost. Fes una revisió Well-Architected abreujada: identifica l'estat de cada pilar i produeix cinc accions prioritzades amb propietari i termini, justificant per què aquestes cinc i no unes altres.

Exercici 3. La direcció de Contoso demana apujar la disponibilitat objectiu del 99,9 % al 99,99 % «perquè sona millor». Prepara la resposta tècnica: què implica realment aquesta diferència en minuts d'aturada, quins canvis d'arquitectura exigiria, quin cost aproximat tindria, quins pilars empitjorarien i quines preguntes tornaries a negoci abans d'acceptar el compromís.

Solució 1: WAF en mode prevenció. Millora seguretat —bloqueja injecció, seqüències d'ordres entre llocs i automatismes abans d'arribar a la regió—; empitjora rendiment —uns mil·lisegons per petició, irrellevants davant dels 400 ms d'objectiu— i, sobretot, disponibilitat percebuda per falsos positius: una regla massa estricta bloqueja clients legítims, cosa que és un risc molt més gran que la latència. Es quantifica amb la latència afegida a Application Insights i amb el nombre de peticions legítimes bloquejades. S'hauria d'invertir —passar a només detecció— únicament si es demostrés que bloqueja trànsit real de manera recurrent i l'ajust de regles no ho resol; mai per rendiment. Rèplica fg-contoso-reservas. Millora fiabilitat —RTO de 4 h en lloc de dies i protecció davant d'una fallada regional—; empitjora cost en ≈1.180 €/mes. La quantificació de l'altre costat és la clau: cal estimar el cost d'una aturada d'un dia en temporada alta, que amb ingressos per reserves és molt superior. S'invertiria si el negoci acceptés per escrit un RTO de dies, o si el volum caigués tant que l'aturada costés menys que la rèplica. Apagada nocturna de -dev. Millora cost; empitjora disponibilitat i, de retruc, agilitat —algú que vulgui treballar de matinada es troba l'entorn aturat— i fiabilitat del mateix runbook, que mal filtrat podria apagar producció. Es quantifica amb hores estalviades pel preu hora i amb incidències reportades per l'equip. S'invertiria si hi hagués equip en una altra zona horària o canalitzacions nocturnes que necessitessin l'entorn: llavors l'estalvi es busca en dimensionament, no en apagada.

Solució 2: estat per pilar. Fiabilitat: crític —còpies no provades equival a no tenir còpies; regió única sense pla de recuperació; sense RPO/RTO escrits—. Seguretat: crític —secrets a la configuració de l'aplicació, accessibles a qualsevol amb permís de lectura del recurs—. Excel·lència operativa: dolent —desplegament manual, en divendres, sense reversió ni traçabilitat de quina versió hi ha a producció—. Cost: desconegut, cosa que a aquests efectes és dolenta —sense pressupost no hi ha alerta d'anomalia—. Rendiment: sense dades —no s'esmenta cap mesurament, així que probablement no n'hi hagi—. Cinc accions prioritzades: (1) Restaurar una còpia en un entorn a part aquesta setmana —propietari operació, 5 dies—: és l'acció de menys esforç i més reducció de risc catastròfic, i a més revela si les còpies existeixen de debò. (2) Treure els secrets a Key Vault amb identitat administrada —desenvolupament, 2 setmanes—: elimina l'exposició més probable i més barata d'explotar. (3) Canalització de desplegament amb ranura i reversió, i prohibició de desplegar en divendres —desenvolupament i operació, 3 setmanes—: converteix cada desplegament d'esdeveniment de risc en rutina. (4) Pressupost amb alerta i etiquetatge mínim de propietari i entorn —finances amb operació, 1 setmana—: cost baixíssim, i sense ell no es detecta ni un error ni un abús. (5) Objectius de disponibilitat i latència escrits, amb Application Insights mesurant-los —producte i desenvolupament, 1 mes—: sense objectiu no hi ha manera de saber si alguna cosa va malament. Per què aquestes i no unes altres: les cinc ataquen riscos amb conseqüència catastròfica i cost de mitigació baix; multiregió, escalat automàtic fi o revisions d'accés automatitzades tenen millor aparença però pitjor relació risc-esforç mentre les còpies continuïn sense provar-se.

Solució 3: en minuts, 99,9 % permet uns 43 minuts d'aturada al mes; 99,99 %, uns 4,3 minuts. La diferència no és «un nou més»: és que cap intervenció humana no cap dins del pressupost d'aturada, així que tot ha de ser automàtic. Canvis necessaris: commutació automàtica de base de dades amb proves contínues, actiu-actiu en almenys dues regions amb el trànsit ja repartit —no en fred—, eliminació de tot punt únic inclòs el mateix desplegament, desplegaments progressius amb reversió automàtica per mètrica, proves de caos periòdiques, i guàrdia 24×7 amb capacitat de resposta en minuts. Cost aproximat: com a mínim duplicar la plataforma de producció més el cost operatiu de l'equip, de l'ordre de 25.000-30.000 €/mes addicionals, davant dels 12.550 € actuals. Pilars que empitjoren: cost, òbviament, i excel·lència operativa a curt termini, perquè la complexitat multiregió introdueix classes d'incident noves —incoherència de dades, divisió de cervell, desplegaments desincronitzats— que avui no existeixen; també empitjora l'agilitat, ja que cada canvi s'ha de validar en dues regions. Preguntes per tornar a negoci: quant costa realment un minut d'aturada, mesurat en reserves perdudes i no només estimat? Quants minuts d'aturada hem tingut els últims dotze mesos, i quants haurien estat evitables amb 99,99 %? Hi ha algun contracte, client corporatiu o requisit regulatori que exigeixi aquest nivell, o és una preferència? Està la direcció disposada a finançar un equip de guàrdia continu, que és el cost que no apareix a la factura d'Azure? I una observació honesta: si l'últim any la major part de la indisponibilitat va venir d'errors de desplegament i no de fallades d'infraestructura, invertir en desplegament progressiu i reversió automàtica compra més disponibilitat real que duplicar regions, i costa una fracció.

Ja saps què és l'Azure Well-Architected Framework i per a què serveix de debò: no com a llista d'obligacions ni com a certificació, sinó com a llenguatge comú que despersonalitza la discussió sobre arquitectures, com a mecanisme de detecció primerenca del deute que encara no ha esclatat i, sobretot, com a manera de fer explícits els compromisos que altrament es prenen sense que ningú no els esmenti.

Coneixes els cinc pilars amb els seus principis de disseny —fiabilitat, seguretat, optimització de costos, excel·lència operativa i eficiència del rendiment— i has vist la plataforma de Contoso auditada pilar per pilar, amb la distinció que fa útil una auditoria: el que compleix, el que no compleix —revisions d'accés, tallacircuits, proves de caos, pressupostos d'error, registre inalterable— i el que es va decidir conscientment no fer, que no és el mateix que un oblit.

Tens els compromisos entre pilars amb casos viscuts i quantificats: el WAF que afegeix mil·lisegons i falsos positius, la rèplica que costa 1.180 € al mes, l'apagada que estalvia a costa de disponibilitat, la directiva que va bloquejar un desplegament un divendres; amb la regla que els fa legítims —escrits, amb propietari i amb data de revisió—. Saps executar la revisió com a procés: una càrrega de treball, participants d'arquitectura, desenvolupament, operació, seguretat i finances, cadència semestral, i una sortida que és un pla de cinc accions prioritzades, no una puntuació; coneixes l'avaluació oficial i la seva complementarietat exacta amb Azure Advisor, les guies especialitzades per a AKS, IA, SaaS i missió crítica, com portar el marc al dia a dia amb cinc preguntes a la revisió de disseny i una plantilla a la sol·licitud de canvis, i t'endus una llista de comprovació per pilar aplicable a qualsevol plataforma.

El marc et diu com hauria d'estar feta una arquitectura. La lliçó següent aborda l'altra meitat de l'ofici: com es fan malament. El catàleg honest dels errors que es repeteixen a totes les organitzacions —de cost, de seguretat, d'arquitectura, d'operació, de governança i de dades—, amb el seu símptoma, el que costa arreglar-los tard, com es prevenen, i els quatre que l'equip de Contoso sí que va cometre durant aquest curs.