El mòdul anterior va acabar amb l'arquitectura de MercadoFresco completa: elàstica, segura, observable, desplegable des d'un pipeline, descrita en codi i repartida en cinc comptes de treball. I amb una pregunta incòmoda esperant el dilluns al matí. Abans de respondre quant costa, convé respondre una cosa prèvia: està ben construïda? No pas «funciona?» —funciona— sinó «resisteix una auditoria honesta?».

Aquesta lliçó presenta el mètode que AWS publica per fer aquesta auditoria: el Well-Architected Framework. Veuràs què és i què no és, els sis pilars amb els seus principis de disseny i les seves preguntes clau, la revisió real de MercadoFresco pilar per pilar amb les seves troballes i el seu risc, els compromisos entre pilars que ningú no pot evitar, la Well-Architected Tool per portar la revisió amb mètode, i la conversa que gairebé mai no es té per escrit: RTO, RPO i les quatre estratègies de recuperació davant de desastres. Al final tindràs un pla de millora prioritzat, i el primer punt d'aquest pla és el que obre les cinc lliçons següents.

Avís de cost. La AWS Well-Architected Tool és gratuïta: no cobra per càrregues de treball, revisions, fites ni lents. El que costa diners són les accions que surten del pla de millora —una rèplica en una altra regió, un simulacre de càrrega, un pla de suport superior— i això és exactament el que aquesta lliçó t'ensenya a prioritzar en comptes de comprar-ho tot. Dades, comptes i identificadors ficticis.

1. Què és el Well-Architected Framework i què no és
2. L'anatomia del marc: pilars, preguntes, bones pràctiques i pla de millora
3. Pilar 1: excel·lència operativa
4. Pilar 2: seguretat
5. Pilar 3: fiabilitat
6. Pilar 4: eficiència del rendiment
7. Pilar 5: optimització de costos
8. Pilar 6: sostenibilitat
9. Els compromisos entre pilars i com es documenten
10. El registre de decisions d'arquitectura
11. RTO, RPO i les quatre estratègies de recuperació davant de desastres
12. La decisió de recuperació de MercadoFresco
13. L'AWS Well-Architected Tool: càrregues de treball, fites i lents
14. La rutina: qui revisa, cada quant i què es fa amb les troballes
15. Revisió periòdica enfront de comprovació contínua: Trusted Advisor i Config
16. El pla de millora prioritzat de MercadoFresco
17. Errors habituals i consells
18. Exercicis
19. Conclusió

L'AWS Well-Architected Framework és un document públic —un conjunt de documents, en realitat— que recull el que AWS ha après revisant desenes de milers d'arquitectures de clients. El seu format no és una llista de serveis recomanats, sinó una col·lecció de preguntes agrupades en sis pilars, cadascuna amb les seves bones pràctiques associades.

La forma de les preguntes és sempre la mateixa: «Com ho feu, això?». No pas «Feu servir el servei Y?». Aquesta diferència és tota la utilitat del marc:

• «Com protegiu les dades en repòs?» admet respondre amb KMS, amb xifratge de client, o amb una justificació de per què aquestes dades no necessiten xifratge. Les tres són respostes vàlides si estan raonades.
• «Feu servir KMS?» només admet sí o no, i converteix l'arquitectura en una llista de la compra.

Convé dir amb claredat què no és:

• No és una certificació. Ningú no aprova ni suspèn. No hi ha cap segell «Well-Architected» per penjar al web.
• No és una llista de compra de serveis d'AWS. Moltes de les millors respostes no costen diners: escriure un procediment, fer un simulacre, esborrar un permís.
• No és una auditoria de compliment. No substitueix un ENS, una ISO 27001 ni la revisió d'un professional de protecció de dades. Hi ha solapament, però l'objectiu és diferent.
• No és una feina d'una tarda ni d'una sola vegada. Una arquitectura que estava bé fa un any pot no estar-ho avui: ha crescut, ha canviat el negoci i han aparegut serveis nous.
• No exigeix arreglar-ho tot. El resultat és una llista prioritzada de riscos acceptats conscientment i riscos que es mitigaran. Acceptar un risc per escrit és una resposta professional; ignorar-lo, no.

El que sí que és: una manera estructurada de trobar allò que no sabies que et faltava, i de convertir-ho en una conversa amb el negoci que no depengui de la intuïció de qui parla més fort.

L'estructura és jeràrquica i convé tenir-la clara abans d'obrir l'eina:

Els elements:

Els sis pilars —i el seu ordre importa poc, perquè no hi ha cap pilar més important que un altre en abstracte, només en el teu context— són:

Un detall pràctic abans de començar: la revisió es fa sobre una càrrega de treball concreta, no sobre «l'empresa». MercadoFresco defineix una càrrega anomenada mercadofresco-tienda-produccion, que abasta la botiga, el catàleg, les comandes i el repartiment al compte 111122223333. L'analítica de la Sara serà una segona càrrega de treball amb la seva pròpia revisió, perquè té altres requisits, un altre risc i un altre propietari.

Tracta de com s'executa i es millora la càrrega de treball: procediments, observabilitat, resposta a incidents i aprenentatge.

Principis de disseny:

• Fer les operacions com a codi: si es fa dues vegades a mà, s'automatitza.
• Fer canvis freqüents, petits i reversibles.
• Refinar els procediments sovint, no deixar-los fossilitzats en un document de fa dos anys.
• Anticipar la fallada: assajar-la abans de patir-la.
• Aprendre de totes les fallades operatives amb post mortem sense culpables.
• Fer servir l'observabilitat per obtenir coneixement accionable, no gràfics bonics.

Preguntes clau: com es determinen les prioritats; com s'estructuren els equips per donar suport al resultat de negoci; com es dissenya la càrrega per poder entendre-la en execució; com es redueix el risc dels canvis; com se sap que està a punt per a producció; com se sap que està sana; com es gestionen els esdeveniments operatius; i com evoluciona el que s'ha après.

Revisió de MercadoFresco:

Un detall que sol passar desapercebut: MercadoFresco té una observabilitat excel·lent i una operació fluixa. Sap perfectament què està passant i no ha escrit què fer quan passa. És el patró més habitual en equips tècnics bons.

Tracta de protegir la informació, els sistemes i els actius, amb controls que detectin i responguin.

Principis de disseny:

• Base d'identitat forta: mínim privilegi, separació de funcions, res de credencials de llarga durada.
• Traçabilitat: registrar, monitorar i auditar totes les accions.
• Aplicar seguretat a totes les capes, no només al perímetre.
• Automatitzar les bones pràctiques de seguretat.
• Protegir les dades en trànsit i en repòs, i classificar-les.
• Mantenir les persones lluny de les dades: si ningú no necessita entrar-hi, ningú no hi entra.
• Preparar-se per a l'incident: tenir pla, eines i assaig.

Preguntes clau: com es gestionen el compte i les identitats; com es gestionen els permisos de persones i de màquines; com es detecten esdeveniments de seguretat; com es protegeixen les xarxes, el còmput i les dades; i com es respon a un incident.

Revisió de MercadoFresco:

Tracta que la càrrega faci el que ha de fer quan ho ha de fer, i es recuperi de les interrupcions.

Principis de disseny:

• Recuperar-se automàticament de la fallada, detectant-la amb indicadors clau.
• Provar els procediments de recuperació, no només escriure'ls.
• Escalar horitzontalment per augmentar la disponibilitat agregada.
• Deixar d'endevinar la capacitat.
• Gestionar el canvi mitjançant automatització.

Preguntes clau: com es gestionen les quotes de servei; com es dissenya la topologia de xarxa; com es dissenya l'arquitectura de serveis per resistir la fallada d'una dependència; com es monitora; com es prova la fiabilitat; i com es planifica la recuperació davant de desastres.

Revisió de MercadoFresco:

Aquest pilar és el pitjor parat dels sis, i no per casualitat: tot el que falta són assajos, i els assajos són el primer que s'ajorna quan cal lliurar funcionalitat.

Tracta de fer servir els recursos adequats —no només suficients— i de continuar fent-ho quan el món canvia.

Principis de disseny:

• Democratitzar les tecnologies avançades: consumir-les com a servei en lloc d'operar-les.
• Arribar a escala global en minuts.
• Fer servir arquitectures sense servidor on encaixin.
• Experimentar més sovint, perquè al núvol provar és barat.
• Tenir afinitat mecànica: triar la tecnologia per com funciona per dins, no per costum.

Preguntes clau: com se selecciona l'arquitectura; com se seleccionen i es fan servir els recursos de còmput, emmagatzematge, base de dades i xarxa; i com es monitora el rendiment per assegurar que continua sent l'esperat.

Revisió de MercadoFresco:

Tracta d'obtenir el màxim valor de negoci per dòlar gastat. No és «gastar poc»: és «gastar bé i saber-ho».

Principis de disseny:

• Implantar la gestió financera del núvol (FinOps) com una capacitat, no com un ensurt anual.
• Adoptar un model de consum: pagar pel que es fa servir.
• Mesurar l'eficiència global: cost per unitat de negoci, no cost absolut.
• Deixar de gastar en feina pesada indiferenciada: centres de dades, apedaçament d'amfitrions.
• Analitzar i atribuir la despesa: que cada equip vegi la seva.

Preguntes clau: com s'implanta la governança de la despesa; com es monitoren l'ús i el cost; com es desmantella allò que ja no es fa servir; com s'avaluen les opcions de compra i els tipus de recurs; com es planifica la demanda; i com s'avaluen els canvis de cost al llarg del temps.

Revisió de MercadoFresco:

Vuit troballes i cinc de risc alt. És el pilar pitjor governat, amb diferència, i és coherent amb la realitat: és l'únic que no dona un error en producció quan s'ignora. Simplement cobra.

És el pilar més recent i el pitjor entès. Tracta de l'impacte ambiental d'executar la càrrega de treball: energia, maquinari i recursos consumits.

Principis de disseny:

• Entendre l'impacte i mesurar-lo.
• Establir objectius de sostenibilitat per unitat de treball.
• Maximitzar la utilització: un servidor al 10 % consumeix gairebé el mateix que al 60 %.
• Adoptar maquinari i programari més eficients tan bon punt estiguin disponibles.
• Fer servir serveis gestionats, que agreguen la càrrega de molts clients.
• Reduir l'impacte aigües avall: menys dades transferides, menys dispositius de client forçats a treballar.

Preguntes clau: com se seleccionen les regions segons l'objectiu de sostenibilitat; com s'alineen els patrons de programari amb la demanda; com s'aprofiten les dades; com es gestionen el maquinari i el cicle de vida; i com s'optimitzen els processos de desenvolupament i desplegament.

Revisió de MercadoFresco:

Un apunt honest: en el 90 % dels casos, les accions del pilar de sostenibilitat coincideixen exactament amb les del pilar de costos. Apagar el que ningú no fa servir estalvia diners i energia. És el pilar amb la millor relació entre esforç i resultat, precisament perquè va de la mà del següent.

Aquí és on el marc deixa de ser una llista i comença a ser enginyeria. Els sis pilars no es maximitzen alhora. Cada decisió en puja un i en baixa un altre. Exemples reals de MercadoFresco:

La lliçó no és «tria bé». És més concreta: un compromís només és defensable si està escrit, quantificat i signat per qui assumeix el risc. Multi-AZ costa el doble; si el gerent entén que aquest doble compra no perdre les comandes d'un divendres, la decisió és seva i està presa. Si ningú no l'hi ha explicat, la decisió no existeix: només hi ha una factura.

L'eina per no perdre aquest raonament es diu ADR (Architecture Decision Record, registre de decisions d'arquitectura): un fitxer de text curt, versionat al costat del codi, per cada decisió rellevant. MercadoFresco els desa a mercadofresco-infra sota docs/adr/.

Format mínim, quatre seccions:

Tres regles perquè els ADR serveixin d'alguna cosa:

1. Un fitxer per decisió, i no s'edita: si la decisió canvia, s'escriu un ADR nou que substitueix l'anterior i es marca el vell com a substituïda per ADR-027. L'historial és el valor.
2. S'escriuen quan es decideix, no quan algú pregunta sis mesos després.
3. Inclouen sempre les alternatives descartades i per què. És la part que més s'agraeix quan el context canvia: permet saber si la raó per descartar-les continua sent vàlida.

De totes les troballes de la revisió, la que més incomoda la Marta és aquesta: ningú no ha declarat mai quant pot estar caiguda la botiga ni quantes dades es poden perdre. Sense aquestes dues xifres no es pot dissenyar la recuperació, perquè no hi ha manera de saber si el que es té és suficient.

Les dues definicions, que es confonen constantment:

• RTO (Recovery Time Objective): quant temps pot estar el servei caigut abans que el dany sigui inacceptable. Es mesura des que comença la interrupció fins que el servei torna a funcionar. És una decisió del negoci, no de tecnologia.
• RPO (Recovery Point Objective): quantes dades es poden perdre, mesurades en temps. Un RPO de 15 minuts significa que, després del desastre, s'accepta haver perdut com a màxim els últims 15 minuts de transaccions.

Dit d'una altra manera: el RPO mira cap enrere (què he perdut) i el RTO mira cap endavant (quant trigo a tornar). I tots dos costen diners de manera creixent i no lineal: abaixar el RTO de 8 hores a 4 és barat; abaixar-lo de 30 minuts a 1 minut és caríssim.

Les quatre estratègies canòniques, de menys a més cost:

Aplicat a la factura mensual consolidada de MercadoFresco, que és de 2.237,60 USD (la desglossarem a 11-03), el cost de cada opció és:

Fixa't que aquests números són de la regió secundària, i que a tots cal sumar-los el cost que mai no apareix a la taula: la feina de mantenir aquesta segona regió coherent amb la primera. Una espera tèbia que fa quatre mesos que no s'actualitza no és una espera tèbia, és una falsa sensació de seguretat.

La Marta porta la conversa al gerent amb dues preguntes concretes, no amb una taula de serveis:

1. «Si la regió d'Irlanda sencera cau —cosa que passa molt rarament però passa—, quantes hores pot estar la botiga tancada abans que el dany sigui greu?»
2. «Quants minuts de comandes ens podem permetre perdre?»

Les respostes, després de discutir-les: 8 hores de RTO i 15 minuts de RPO per al sistema de comandes. El raonament del gerent és defensable: MercadoFresco reparteix producte fresc en 24 hores; una caiguda de 8 hores endarrereix un dia de repartiment, molesta i costa, però no tanca l'empresa. Perdre comandes ja confirmades i cobrades, en canvi, sí que és greu, perquè implica cobrar sense servir.

Aquestes dues xifres eliminen elles soles dues de les quatre estratègies:

• Actiu-actiu i espera tèbia estan sobredimensionades per a un RTO de 8 hores. Pagar 780 o 2.200 USD al mes per baixar de 8 hores a 20 minuts no ho demana ningú.
• Còpia i restauració encaixa en el RTO (8-24 h està al límit) però falla en el RPO si les còpies són diàries.

La decisió resultant és un híbrid raonat: còpia i restauració reforçada.

I aquí ve la part que distingeix un pla d'un document: el RPO real declarat és de 6 hores en cas de desastre regional, no de 15 minuts. La Marta ho escriu així, amb aquestes paraules, a l'ADR-021, i ho porta signat. L'opció d'abaixar-lo a 15 minuts existeix —replicació contínua a l'altra regió— i costa uns 200 USD més al mes. Gerència decideix assumir el risc residual per ara i revisar-ho quan obrin fora d'Espanya.

Tres compromisos addicionals que tanquen la troballa:

1. Simulacre semestral de restauració completa a eu-west-3, amb cronòmetre i acta. Si el RTO mesurat supera les 8 hores, es replanteja l'estratègia.
2. Simulacre trimestral de fallada d'AZ amb AWS Fault Injection Service en preproducció, que és un risc molt més probable que el regional.
3. La primera prova es fa abans de desembre, perquè fer-la en campanya de Nadal seria temerari.

La Well-Architected Tool és un servei gratuït de la consola que converteix el document en un flux de treball amb estat. Els passos:

1. Definir la càrrega de treball. Nom, descripció, entorn (producció o preproducció), regions, comptes implicats, sector i propietari. MercadoFresco defineix:

Comentari de les opcions que importen:

• --environment PRODUCTION canvia el pes d'algunes recomanacions: l'eina és més exigent amb una càrrega de producció.
• --account-ids inclou el compte d'eines 555566667777 perquè el pipeline forma part de la càrrega de treball: no té sentit revisar l'excel·lència operativa ignorant qui desplega.
• --lenses aplica d'entrada la lent base i la de serverless, perquè MercadoFresco té Lambda i Fargate al camí crític.
• --tags etiqueta la revisió mateixa, coherent amb la convenció del curs. Sí: fins i tot la revisió s'etiqueta.

2. Respondre el qüestionari. Per cada pregunta es marquen les bones pràctiques que realment es compleixen i s'hi pot afegir una nota. Hi ha dos paranys clàssics:

• Marcar per optimisme. «Sí, tenim còpies» no és el mateix que «hem restaurat una còpia amb èxit el mes passat». Si no s'ha provat, no està marcat.
• No fer servir les notes. La nota és on s'escriu «ho fem parcialment: només en producció». Sense ella, la revisió d'aquí a sis mesos no té context.

També existeix l'opció «aquesta pregunta no aplica», amb la seva justificació. Fer-la servir és legítim: les preguntes sobre gestió de flota d'instàncies no apliquen a una càrrega íntegrament sense servidor.

3. Obtenir el pla de millora. L'eina calcula el risc per pregunta (alt, mitjà o cap) i genera una llista d'elements de millora amb enllaços a la documentació. La llista es pot exportar i —això és l'important— convertir en tasques del backlog amb propietari i data. Un pla de millora que viu dins de la Well-Architected Tool i no al tauler de l'equip no s'executa mai.

4. Crear una fita (milestone). Una fita congela l'estat de les respostes en una data:

Sis mesos després, després d'una nova revisió, l'eina mostra la comparació entre fites: quants riscos alts hi havia, quants n'hi ha, quins es van resoldre i quins n'han aparegut de nous. Aquesta comparació és l'únic indicador honest de si l'equip està millorant o només corrent.

5. Aplicar lents. Una lent afegeix preguntes específiques d'un domini, i canvia el llistó. Les més útils:

Un consell sobre lents: no aplicar-ne més de dues. Cada lent afegeix desenes de preguntes i la revisió deixa d'acabar-se. Val més una revisió completa amb dues lents que una revisió abandonada amb sis.

6. Consultar els resultats per API, que és com s'automatitza el seguiment:

Què fa aquest script, línia a línia:

• get_lens_review retorna l'estat de la revisió per a una lent concreta; PillarReviewSummaries porta el recompte de riscos per pilar, que és exactament el resum executiu que demana gerència.
• list_lens_review_improvements retorna els elements de millora; es filtra per Risk == "HIGH" perquè un pla amb 60 punts no s'executa i un amb 12 sí.
• El resultat es pot bolcar a un fitxer, obrir incidències automàticament o publicar-se com a mètrica a CloudWatch per veure'l evolucionar. MercadoFresco fa la tercera cosa: una mètrica RiesgosAltosWA a l'espai MercadoFresco/Tienda, revisada a la reunió mensual.

Una revisió Well-Architected que es fa una vegada és un informe. La que es repeteix és un procés. La rutina que instaura la Marta:

Dues regles que eviten que el procés mori:

1. Cap element de millora sense propietari ni data. «Caldria fer proves de càrrega» no és una tasca; «el Luis executa una prova de càrrega a 1.400 comandes/hora en preproducció abans del 30 d'octubre» sí que ho és.
2. Màxim cinc millores en curs alhora. Un pla de 40 accions obertes equival a cap acció en curs.

La revisió Well-Architected és periòdica, profunda i humana. No serveix per detectar que algú va obrir un grup de seguretat al món dimarts a la tarda. Per a això hi ha les eines que ja coneixes del mòdul 5, i convé veure com encaixen les tres:

La relació correcta és de realimentació en les dues direccions:

Un exemple concret de MercadoFresco: la revisió descobreix que no hi ha revisió periòdica de permisos. L'acció no és només «revisar els permisos aquest trimestre», sinó convertir la troballa en una comprovació contínua: una regla de Config iam-user-unused-credentials-check i un informe mensual d'IAM Access Analyzer. Així, la troballa no torna a aparèixer a la revisió d'aquí a sis mesos.

La regla general: tota troballa que es pugui convertir en una comprovació automàtica, es converteix. La revisió humana s'ha de reservar per al que cap eina no pot avaluar: si el RTO és adequat per al negoci, si l'equip sap què fer a les 3 de la matinada, si la decisió de fa un any continua sent vàlida.

Sumant els sis pilars, la revisió inicial dona aquest balanç:

Catorze riscos alts són massa per atacar-los alhora, així que es prioritzen creuant impacte i esforç:

Per què el pilar de costos va primer, encara que fiabilitat tingui els mateixos riscos alts i soni més important. Tres raons concretes:

1. És l'únic pilar del qual ningú no té ni una dada. No es pot prioritzar allò que no es mesura, i les decisions de fiabilitat que vindran després —pilot light o warm standby?— són decisions de cost disfressades de decisions tècniques.
2. Les accions són d'esforç baix i efecte immediat. Activar etiquetes, esborrar orfes i apagar entorns de nit són hores de feina, no setmanes, i alliberen pressupost.
3. El pressupost alliberat finança la resta del pla. Els diners que es deixen de llençar en desenvolupament de nit són exactament els que paguen les còpies entre regions i les proves de càrrega.

Aquest és el fil de les cinc lliçons que queden. 11-02 converteix la factura en una cosa llegible mitjançant etiquetes i assignació. 11-03 l'analitza amb Cost Explorer i executa les optimitzacions. 11-04 posa límits i avisos amb Budgets. 11-05 compromet capacitat amb Savings Plans i reserves. I 11-06 tanca el curs amb el projecte integrador.

Error: tractar la revisió com un examen que cal aprovar. L'equip marca bones pràctiques que no compleix del tot perquè l'informe surti verd. Consell: l'informe no el llegeix ningú de fora. L'única cosa que es perd marcant de més és l'oportunitat de trobar el problema abans que el trobi un divendres a les 19:00.

Error: revisar «tota l'empresa» com una sola càrrega de treball. Surt un qüestionari impossible de respondre perquè la resposta correcta és «depèn del sistema». Consell: una càrrega de treball és un conjunt de components que lliuren valor de negoci junts i comparteixen propietari. MercadoFresco en té dues: la botiga i l'analítica.

Error: convertir el pla de millora en un document i tancar-lo. Sis mesos després, la nova revisió troba exactament les mateixes troballes. Consell: els elements de millora surten de l'eina el mateix dia i entren al tauler de l'equip amb propietari i data, o no existeixen.

Error: confondre «tenim còpies» amb «sabem restaurar». És la troballa més repetida del pilar de fiabilitat de tot el sector. Consell: una còpia no provada és una hipòtesi. Restaura una vegada, amb cronòmetre i en un entorn net, i anota el temps real: gairebé sempre triplica l'estimat.

Error: fixar el RTO i el RPO des de tecnologia. L'equip tècnic decideix «posem-hi 15 minuts» sense preguntar a ningú, i després dissenya una arquitectura que costa tres vegades més del que cal. Consell: el RTO i el RPO els declara el negoci responent dues preguntes en llenguatge planer, i s'escriuen en un ADR signat.

Error: comprar l'estratègia de recuperació més cara «per si de cas». Un actiu-actiu sense necessitat duplica la factura i, pitjor, duplica la feina de manteniment; sol acabar desincronitzat i donant una falsa seguretat. Consell: comença per l'estratègia que compleix el RTO i el RPO declarats, i puja-la quan el negoci apugi les exigències, no abans.

Error: aplicar sis lents alhora. La revisió passa de 60 preguntes a 300 i s'abandona a la segona sessió. Consell: la lent base més una o dues d'específiques. Se'n poden afegir més a la revisió següent.

Consell: fes servir les notes de cada pregunta com a memòria. «Complert només en producció, pendent en preproducció, vegeu ADR-018» converteix la revisió següent en mitja hora de feina en lloc de dues hores d'arqueologia.

Consell: mesura el procés, no només l'arquitectura. L'indicador útil no és «tenim 14 riscos alts», sinó «en teníem 14 i ara en tenim 6». Les fites existeixen exactament per a això.

Consell: accepta riscos per escrit i amb data de caducitat. «Acceptem un RPO regional de 6 h fins a l'obertura a Portugal, revisió al març» és una decisió professional. «Ja ho mirarem» no ho és.

Una empresa fictícia, LlibreriaAtlas, ven llibres en línia amb una arquitectura molt més senzilla que la de MercadoFresco: dues instàncies EC2 darrere d'un ALB, una RDS MySQL d'una sola AZ, S3 per a les portades, sense CDN, desplegaments per SSH i còpies diàries automàtiques de RDS amb 7 dies de retenció. Mai no han restaurat una còpia. No tenen etiquetes. L'equip són dues persones.

1. Escriu cinc troballes del pilar de fiabilitat amb el seu risc (alt o mitjà).
2. Indica quina atacaries primer i per què, sabent que el pressupost és limitat.
3. Proposa un RTO i un RPO raonables i digues quina estratègia de recuperació hi encaixaria.

MercadoFresco es planteja afegir inspecció del cos de les peticions al WAF de l'ALB per detectar intents d'injecció al formulari de comanda. Mesurat en preproducció: afegeix entre 4 i 9 ms de latència per petició i uns 12 USD al mes. La botiga té un objectiu de TiempoConfirmacionPedido p99 per sota de 900 ms i actualment està a 840 ms.

1. Identifica quins pilars pugen i quins baixen.
2. Escriu l'ADR complet amb context, decisió, conseqüències i alternatives descartades.
3. Indica quina mètrica vigilaries després d'aplicar-ho i què faria que revertissis la decisió.

El gerent de MercadoFresco canvia d'opinió: després de llegir una notícia sobre una caiguda regional d'un competidor, demana RTO d'1 hora i RPO de 10 minuts.

1. Quines estratègies de la taula continuen sent vàlides amb aquests objectius?
2. Calcula l'impacte sobre la factura mensual de 2.237,60 USD de l'opció més barata que els compleixi, en valor absolut i en percentatge.
3. Prepara tres preguntes que li faries al gerent abans d'aprovar la despesa.

Solució a l'exercici 1

(1) Cinc troballes de fiabilitat a LlibreriaAtlas:

(2) Què atacar primer: la restauració provada. No és la resposta intuïtiva —la intuïció diu «Multi-AZ»— però és la correcta amb pressupost limitat per tres raons: costa zero euros (només temps), valida o invalida tota l'estratègia de còpies de cop, i si resulta que les còpies no serveixen, canvia del tot la prioritat de tota la resta. Multi-AZ és la segona, i ja costa diners: aproximadament duplica el cost de la instància RDS.

(3) RTO i RPO raonables. Una llibreria en línia no és un servei crític de vida: RTO de 4 hores i RPO de 24 hores són perfectament defensables si el negoci els accepta —amb còpies diàries, el RPO real ja és de 24 h—. Amb aquests objectius, l'estratègia adequada és còpia i restauració, reforçada amb dues coses barates: replicar les instantànies a una altra regió i tenir la infraestructura descrita en CloudFormation per poder reconstruir-la sense dependre de la memòria de ningú. Si el negoci exigís un RPO d'1 hora, la resposta no seria canviar d'estratègia sinó activar còpies més freqüents o passar a un motor amb recuperació a un punt en el temps.

Solució a l'exercici 2

(1) Pilars afectats:

• Puja seguretat: protecció addicional contra injecció al punt exacte on entren dades d'usuari, en una capa diferent de la validació de l'aplicació (defensa en profunditat).
• Baixa eficiència del rendiment: entre 4 i 9 ms per petició. Amb el p99 a 840 ms i l'objectiu a 900, el marge restant passa de 60 ms a uns 51 ms en el pitjor cas. Continua complint, però amb menys folgança.
• Baixa optimització de costos: 12 USD al mes, un 0,5 % de la factura. Marginal.
• Neutre per a fiabilitat, amb un matís: una regla WAF mal ajustada que bloquegi peticions legítimes sí que afecta la fiabilitat percebuda. És el risc real d'aquesta decisió, no la latència.

(2) ADR:

(3) Què vigilar i què revertiria la decisió. Es vigilen tres coses: el p99 de TiempoConfirmacionPedido al tauler mercadofresco-produccion, la taxa de peticions bloquejades pel WAF, i el nombre de comandes confirmades per hora comparat amb la setmana anterior. La decisió es reverteix si el p99 supera els 900 ms de manera sostinguda, o si PedidosConfirmados cau de manera inexplicable, que seria el senyal de falsos positius bloquejant compres reals. La reversió és barata: tornar la regla a mode recompte és un canvi d'un camp.

Solució a l'exercici 3

(1) Estratègies vàlides amb RTO 1 h i RPO 10 min:

• Còpia i restauració: no compleix. RTO típic de 8-24 h i, amb còpies entre regions cada 6 h, un RPO de 6 h.
• Llum pilot: compleix just. RTO d'1-4 h —cal treballar per quedar-se a la banda baixa— i RPO de 5-15 min amb rèplica contínua d'Aurora cap a l'altra regió.
• Espera tèbia: compleix amb folgança (RTO 10-30 min).
• Actiu-actiu: compleix de sobres i és innecessari per a aquests objectius.

La resposta honesta és que la llum pilot compleix el RPO amb seguretat i el RTO només si s'assaja. Un RTO d'1 hora amb llum pilot exigeix automatització total de l'arrencada: res de reconstruir a mà. És l'opció que cal proposar, amb la condició explícita d'un simulacre que ho demostri.

(2) Impacte en la factura:

I hi ha un cost que no és en aquesta xifra i que convé posar damunt la taula: la feina recurrent. Mantenir la segona regió alineada, executar el simulacre semestral i arreglar el que el simulacre trenqui són de l'ordre de 6 a 10 dies de feina l'any, que a cost intern superen el cost d'infraestructura.

(3) Tres preguntes per al gerent:

1. «D'on surt el requisit?» Si ve d'una notícia sobre un competidor, potser el risc real que preocupa no és el regional —que és rar— sinó un de molt més probable: un desplegament dolent, un esborrat accidental o un atac. Aquests es mitiguen amb reversió automàtica, esborrat amb retenció i WAF, que ja existeixen i costen molt menys.
2. «Quant factura MercadoFresco en 8 hores?» És el número que converteix la conversa en una decisió d'inversió. Si són 4.000 USD i la probabilitat d'una caiguda regional és d'una vegada cada uns quants anys, gastar 3.222 USD anuals s'ha de discutir amb aquests dos números al davant.
3. «Assumim també el compromís d'assajar-ho dues vegades l'any?» Sense aquesta condició, la resposta correcta és no muntar-ho: una llum pilot no provada dona la mateixa disponibilitat que no tenir res, però amb factura.

MercadoFresco ja no té només una arquitectura: té una auditoria d'aquesta arquitectura, feta amb mètode i no amb intuïció.

Saps què és el Well-Architected Framework i, sobretot, què no és: no és una certificació, ni una llista de compra de serveis, ni una auditoria de compliment. És una col·lecció de preguntes amb la forma «com ho feu, això?», agrupades en sis pilars —excel·lència operativa, seguretat, fiabilitat, eficiència del rendiment, optimització de costos i sostenibilitat—, cadascuna amb bones pràctiques que es marquen només quan de debò es compleixen. I saps que la unitat de la revisió és la càrrega de treball, no l'empresa.

Tens la revisió completa de MercadoFresco pilar per pilar, amb 14 riscos alts i 12 de mitjans, i amb un patró que es repeteix en gairebé tots els equips tècnics bons: una observabilitat excel·lent al costat d'una operació sense runbooks, una arquitectura elàstica que mai no s'ha provat sota càrrega, unes còpies que mai no s'han restaurat i un pilar de costos del qual literalment ningú no té una dada. Amb les troballes escrites com a troballes —«no hi ha RTO declarat», «mai no s'ha simulat la fallada d'una AZ», «el compte de desenvolupament no té límit de despesa», «ningú no ha revisat els permisos des que es van crear»— i amb el seu risc i la seva acció al costat.

Tens els compromisos entre pilars quantificats en lloc d'intuïts: Multi-AZ triplica el còmput d'Aurora, el WAF amb inspecció de cos afegeix de 4 a 9 ms, Spot canvia cost per interrupcions, els endpoints de VPC compren seguretat i surten més cars que el NAT. I l'eina perquè aquest raonament sobrevisqui al pas del temps: el registre de decisions d'arquitectura, un fitxer per decisió, versionat, que no s'edita i que inclou sempre les alternatives descartades i per què.

Tens RTO i RPO entesos de debò —un mira cap endavant, l'altre cap enrere— i les quatre estratègies de recuperació amb el seu cost real sobre la factura: còpia i restauració (+2-4 %), llum pilot (+10-15 %), espera tèbia (+30-40 %) i actiu-actiu (+90-110 %). I la decisió de MercadoFresco, presa pel negoci i no per l'equip tècnic: RTO de 8 hores i RPO de 15 minuts, resolts amb còpia i restauració reforçada, amb el risc residual escrit sense adorns —el RPO regional real és de 6 hores— i amb dos simulacres compromesos al calendari.

I tens la rutina: qui convoca, qui hi participa —inclòs negoci, perquè RTO, RPO i pressupost no són decisions tècniques—, cada quant, quant dura i què en surt; les fites per comparar la revisió d'avui amb la d'aquí a sis mesos, que és l'únic indicador honest de millora; les lents especialitzades amb el consell de no aplicar-ne més de dues; i el repartiment de papers entre la revisió semestral humana, les comprovacions contínues de Config i els avisos de Trusted Advisor, amb la regla que els uneix: tota troballa que es pugui convertir en comprovació automàtica, es converteix.

El resultat és un pla de millora prioritzat de deu accions amb propietari i data. I el seu primer punt no és el més vistós ni el més urgent en aparença: és el pilar d'optimització de costos, perquè és l'únic del qual no hi ha ni una dada, perquè les seves accions són d'esforç baix i efecte immediat, i perquè el pressupost que allibera és exactament el que finança les proves de càrrega i les còpies entre regions de la resta del pla.

Així que la pregunta del gerent continua damunt la taula, ara amb un mètode al darrere per respondre-la. Quant costa tot això i està ben gastat? El problema és que avui la resposta seria una xifra única d'una factura d'una sola línia, i amb això no es pot decidir res: no se sap quant és producció i quant desenvolupament, ni quant costa el catàleg enfront de les comandes, ni quant d'aquesta xifra correspon a Madrid i quant a Sevilla, ni quina part es pot retallar sense que ningú no ho noti.

A 11-02, «Etiquetatge i assignació de costos», es resol aquest problema primer: les cinc etiquetes obligatòries del curs deixen de ser una convenció escrita en un document per convertir-se en dimensions activades, imposades per política i auditades, capaces de respondre per fi qui gasta què. Sense aquest pas, tot el que ve després —analitzar, pressupostar i comprometre— es fa a cegues.