La lliçó anterior va acabar amb una regla incòmoda: abans de comprometre's cal optimitzar, perquè reservar un recurs sobredimensionat és pagar tres anys per un error. Però per optimitzar cal saber què està mal dimensionat, què porta mesos encès sense que ningú ho faci servir i què es va quedar enrere en una migració que va acabar fa un any. En una plataforma amb cinquanta-i-escaig recursos repartits en dues subscripcions, aquesta informació no la té ningú al cap.

La té Azure. Azure Advisor analitza contínuament els recursos reals de les teves subscripcions i produeix recomanacions concretes —amb nom de recurs, motiu i estalvi estimat— en cinc categories. És gratuït, no requereix cap configuració prèvia i és al portal des del primer dia, que és exactament la raó per la qual gairebé ningú no el mira: no cal activar-lo, així que no hi ha cap moment en què algú decideixi fer-lo servir.

Aquesta lliçó el recorre sencer: les cinc categories i la seva correspondència amb els pilars del Well-Architected Framework, la puntuació i com interpretar-la sense obsessionar-s'hi, les recomanacions de cost en detall —infrautilització, recursos orfes, canvi de mida i compra de reserves—, el recorregut complet del que Advisor diu a Contoso i què fa l'equip amb cada recomanació, els casos en què Advisor s'equivoca, la seva automatització amb CLI i API, la seva configuració, i finalment el malbaratament que Advisor no veu i que cal anar a buscar amb Azure Resource Graph.

Recordatori: totes les xifres en euros són orientatives i fictícies. Els preus reals varien per regió i canvien amb freqüència; consulta'ls a la calculadora oficial.

1. Què és Advisor i per què és el punt de partida
2. Les cinc categories i els pilars del Well-Architected Framework
3. La puntuació d'Advisor
4. Les recomanacions de cost en detall
5. El recorregut de Contoso: aplicar, ajornar o descartar
6. Quan Advisor s'equivoca
7. Consultar i automatitzar Advisor
8. Configuració: exclusions, llindars i àmbit
9. Integració amb Defender for Cloud i Cost Management
10. El malbaratament que Advisor no veu: Azure Resource Graph
11. L'informe mensual de la Marta
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

Advisor és un motor de recomanacions que avalua la configuració i la telemetria reals dels teus recursos contra un conjunt de bones pràctiques de Microsoft. La diferència amb qualsevol llista de consells publicada a internet és substancial:

Tres propietats que convé tenir clares des del principi. Advisor només llegeix: no canvia res pel seu compte, les seves recomanacions són propostes i aplicar-les és sempre una acció explícita. Necessita temps i dades: les recomanacions d'infrautilització es basen en finestres d'observació de dies, així que en una subscripció acabada de crear n'apareixeran poques. I la seva cobertura no és total: hi ha malbaratament que Advisor no detecta, i per això existeix l'apartat 10.

La correspondència amb el Well-Architected Framework no és casual: Advisor és, a la pràctica, la implementació automatitzada d'una part del marc sobre els teus recursos reals. El marc complet —els seus principis, les seves preguntes de revisió i els seus compromisos entre pilars— es tracta a la lliçó 09-02; aquí n'hi ha prou amb retenir la idea que les cinc categories no són independents i sovint estiren en direccions oposades. Una recomanació de cost que proposa eliminar una rèplica xoca de ple amb una de fiabilitat que demana redundància. Advisor presenta totes dues sense resoldre el conflicte, perquè resoldre'l requereix conèixer el negoci. Aquest arbitratge és la feina de l'arquitecte, no de l'eina.

Advisor calcula una puntuació de 0 a 100 global i per categoria, ponderant l'impacte potencial de les recomanacions pendents sobre el consum dels recursos afectats. Serveix per a dues coses legítimes: mesurar la tendència en el temps i comparar subscripcions o equips.

I convé dir amb claredat per a què no serveix, perquè l'ús indegut d'aquesta mètrica fa mal de debò:

• No és un objectiu en si mateixa. Perseguir el 100 % porta a aplicar recomanacions que no pertoquen només perquè desapareguin de la llista.
• No és comparable entre organitzacions. Depèn de la composició dels teus recursos.
• Baixa en créixer. Desplegar recursos nous genera recomanacions noves; una caiguda pot significar que l'equip està construint, no empitjorant.
• Descartar una recomanació amb motiu apuja la puntuació, i això està bé: és la manera de dir-li a l'eina que ja has decidit.

A Contoso, la puntuació de cost va passar de 61 a 84 en dos mesos. La Nuria va preguntar, amb raó, quants euros eren aquests 23 punts. La resposta honesta va ser: els euros són a la taula de l'apartat 5; la puntuació és un indicador de procés, no de resultat. La xifra que es porta al comitè és l'estalvi en euros; la puntuació es fa servir internament per veure si l'equip està atenent la llista o deixant-la créixer.

Les recomanacions de la categoria de cost cauen en quatre grups, i val la pena conèixer-los perquè cadascun es decideix de manera diferent.

Recursos infrautilitzats. Advisor observa la CPU i la xarxa de les màquines virtuals durant una finestra configurable (7, 14, 21, 30, 60 o 90 dies) i marca les que es mantenen per sota d'un llindar. Proposa apagar o redimensionar. És la recomanació amb més estalvi potencial i també la que més judici exigeix, perquè una màquina al 3 % pot ser un malbaratament o pot ser un servidor de llicències que fa molt poca cosa però és imprescindible.

Recursos orfes: el malbaratament silenciós. Són recursos que continuen facturant sense estar associats a res. No donen error, no apareixen en cap alerta i ningú no els troba a faltar:

Canvi de mida i de SKU. Advisor proposa baixar de nivell bases de dades amb ús baix, canviar a SKU més modernes i barates (per exemple, d'una sèrie antiga al seu equivalent actual amb millor relació preu/rendiment), o passar a nivells sense servidor on el patró ho justifica.

Recomanacions de compra de reserves i plans d'estalvi. Són les mateixes que es veuen a Cost Management i es regeixen pel que ja saps de 08-03: no s'accepten a cegues, perquè miren cap enrere i calculen sobre l'estat sense optimitzar.

La Marta va obrir Advisor sobre les dues subscripcions i va treballar la llista sencera. Cada recomanació acaba en una de tres decisions, i les tres són respostes vàlides sempre que quedi constància del motiu:

Quatre observacions sobre aquesta taula, que són les que fan que l'exercici valgui la pena:

• Cap de les accions aplicades no afecta un recurs que algú estigués fent servir. És malbaratament pur: 457 € al mes, 5.484 € l'any, per netejar.
• Les dues recomanacions descartades són tècnicament correctes i econòmicament equivocades, i només un humà amb context ho podia saber (apartat 6).
• Ajornar és una decisió, no una evasiva, sempre que tingui data i motiu. Les tres ajornades tenen totes dues coses.
• Els orfes tornaran a aparèixer. Això no és un projecte que s'acaba; és una revisió mensual (apartat 11).

Abans d'aplicar res, la salvaguarda que Contoso va escriure: instantània de 30 dies abans d'esborrar qualsevol disc, i verificació que cap IP pública no té un registre DNS apuntant-hi. Esborrar un disc orfe és irreversible, i estalviar 9 € per provocar una restauració de dos dies és un mal negoci.

Advisor no s'equivoca en les dades: s'equivoca en el context, perquè no el té. Els patrons en què cal desconfiar:

• Estacionalitat. La recomanació 9 proposa reduir vmss-api-disponibilidad-pro perquè la seva CPU mitjana és baixa. És cert i és irrellevant: l'API existeix per suportar l'obertura de la temporada d'estiu, quan l'escalat automàtic puja a 14 instàncies i cadascuna necessita la seva mida. Una recomanació calculada sobre 30 dies de febrer no ho pot saber.
• Recursos deliberadament inactius. disk-motor-datos-copia és una còpia intencionada prèvia a una migració de motor. Per a Advisor és un disc orfe; per a l'equip és una xarxa de seguretat amb data de caducitat.
• Infraestructura de contingència. Tot el pilot lleuger de North Europe (07-05) està, per definició, infrautilitzat. Aquesta és la seva funció.
• Càrregues d'arrencada en fred. Una instància mínima sempre activa a ca-motor-disponibilidad està gairebé ociosa, i existeix precisament perquè la primera petició no esperi.
• Finestres d'observació curtes. Un procés que s'executa el dia 1 de cada mes és invisible en una finestra de 14 dies.

La conclusió, que val per a qualsevol eina de recomanació automàtica: Advisor proposa; una persona amb context decideix. I quan decideixi descartar, ho ha de fer amb la funció de descart de la mateixa eina, indicant el motiu i una data de revisió. Descartar «per sempre» i en silenci converteix la llista en soroll; descartar amb motiu i amb caducitat la manté útil.

extendedProperties és on viuen les dades interessants i el seu contingut varia segons el tipus de recomanació: annualSavingsAmount, savingsCurrency, targetSku, currentSku, region. Val la pena inspeccionar una recomanació completa amb -o json la primera vegada, per saber quins camps hi ha.

Per automatitzar l'informe mensual, Contoso executa això des d'un runbook d'aa-contoso-operaciones (07-04) el dia 1 de cada mes, deixa el resultat a stlagocontosopro i publica el resum a Teams:

Existeixen a més alertes de recomanacions noves: es configura una regla que notifica quan Advisor genera una recomanació d'una categoria i impacte determinats, amb destinació a un grup d'accions. Contoso la té sobre recomanacions de cost d'impacte Alt, dirigida a ag-equipo-contoso, el mateix grup d'accions de 07-01 i dels pressupostos de 08-02. Un consell pràctic: no alertis sobre recomanacions d'impacte baix o mitjà, o el canal s'omplirà de soroll i deixarà de llegir-se en una setmana.

I un advertiment amb l'API d'Advisor: les recomanacions es recalculen periòdicament, i els seus identificadors no són estables entre generacions. Un script que desi identificadors per comparar-los d'un mes a l'altre no funcionarà; cal comparar per recurs i tipus de recomanació.

Advisor es configura, i fer-ho bé és el que separa una llista útil d'una llista que ningú no mira:

Les dues decisions que més rendiment donen. Un llindar diferent per entorn: en desenvolupament interessa un llindar alt, perquè qualsevol màquina per sota del 20 % probablement estigui sobredimensionada i el risc de redimensionar-la és nul; en producció interessa un llindar baix i conservador, perquè un fals positiu costa una incidència. I una finestra llarga en producció: amb 14 dies, l'estacionalitat d'una aerolínia genera recomanacions absurdes cada temporada baixa.

Les regles d'exclusió convé fer-les servir amb moderació. Excloure un recurs el treu del radar per sempre i en silenci, mentre que descartar una recomanació amb data la retorna a la llista quan toca. L'exclusió és per a infraestructura la naturalesa de la qual és estar ociosa —contingència, arrencada en fred—; el descart és per a tota la resta.

Advisor no calcula tot el que mostra: és també un aparador d'altres serveis.

Les conseqüències pràctiques d'aquest diagrama: la categoria de seguretat d'Advisor és la puntuació de seguretat de Defender for Cloud, així que es treballa allà i no aquí —els plans de pagament del mòdul 4 amplien molt el que es detecta—; i les recomanacions de compra de reserves són les mateixes de Cost Management, calculades pel mateix motor, així que tant se val des d'on es mirin, però es decideixen amb els criteris de 08-03.

Advisor cobreix bé el que és estàndard, però hi ha malbaratament que no detecta: recursos sense etiquetar que no es poden imputar, entorns de desenvolupament encesos de nit, recursos creats fora de les regions permeses, o qualsevol convenció pròpia de l'organització. Per a això hi ha Azure Resource Graph (07-04), que consulta l'inventari complet amb KQL en segons.

Discos orfes, amb la seva mida i el seu nivell —inclou els que Advisor encara no ha processat—:

Recursos sense les etiquetes obligatòries, que és l'origen del cubell «sense imputar» de 08-02:

IP públiques sense associar i equilibradors sense backend, en una sola consulta:

Entorns de desenvolupament que haurien d'estar apagats: màquines etiquetades horario=laborable que estan en execució. Executada al matí confirma que el runbook les va encendre; executada de matinada revela les que se li van escapar.

Comptes d'emmagatzematge sense contingut recent i recursos fora de regió, dues comprovacions més d'higiene:

Aquestes consultes viuen versionades a contoso-infra al costat de les plantilles Bicep, i aquesta és una recomanació important: una consulta de malbaratament que només existeix a l'historial del portal d'una persona no és un procés. En un repositori, qualsevol l'executa, es revisa a la sol·licitud d'incorporació de canvis i evoluciona amb la plataforma.

Tot l'anterior es condensa en un document d'una pàgina que la Marta porta al comitè el primer dimarts de cada mes, amb aquesta estructura fixa:

Dos trets fan que aquest informe funcioni on d'altres moren. Cap en una pàgina, així que es llegeix. I inclou el que es va descartar i per què, que és el que impedeix que el comitè pregunti cada mes per la mateixa recomanació i el que demostra que l'equip decideix en lloc d'obeir una eina. La secció d'accions executades, amb l'estalvi real —no l'estimat—, és la que construeix credibilitat amb finances: la primera vegada que la Nuria va comprovar que els 457 € promesos apareixien efectivament a la factura del mes següent, la conversa sobre costos va canviar de to per sempre.

• No mirar mai Advisor, precisament perquè no cal activar-lo. És l'error més comú i el més barat de corregir.
• Aplicar tot el que diu. Advisor no coneix l'estacionalitat, ni la contingència, ni les teves còpies deliberades.
• Descartar en silenci i per sempre. El descart sense motiu ni data converteix la llista en soroll.
• Perseguir la puntuació. És un indicador de procés; el resultat es mesura en euros i en risc evitat.
• Esborrar discos orfes sense instantània prèvia. Estalviar 9 € i provocar una restauració de dos dies és un mal negoci.
• Acceptar la recomanació de compra de reserva abans de redimensionar. Es paga tres anys la mida equivocada (08-03).
• Fer servir la mateixa finestra i el mateix llindar en desenvolupament i en producció. Produeixen recomanacions inútils en un lloc i perilloses en l'altre.
• Desar identificadors de recomanació per comparar entre mesos: no són estables.
• Consell: executa avui les consultes de discos orfes i IP sense associar. És el minut més ben invertit d'aquesta lliçó.
• Consell: alerta només sobre recomanacions de cost d'impacte alt. La resta es veu a la revisió mensual.
• Consell: versiona les teves consultes de Resource Graph al repositori d'infraestructura, al costat de les plantilles.

Exercici 1. Advisor proposa per a vm-motor-disponibilidad-dev baixar de Standard_D4s_v5 a Standard_D2s_v5 per CPU mitjana del 3 % en 30 dies. Enumera les comprovacions que faries abans d'aplicar-ho i en quin cas concret rebutjaries la recomanació tot i que la dada sigui correcta.

Exercici 2. Escriu una consulta d'Azure Resource Graph que trobi totes les instantànies de disc amb més de 180 dies d'antiguitat, mostrant nom, grup de recursos, mida, propietari i centre de cost, ordenades per mida. Explica què faries amb el resultat abans d'esborrar res.

Exercici 3. Contoso Millas (centro-coste=CC-2077) acaba de rebre les seves primeres recomanacions: reduir la SKU de la seva App Service (impacte mitjà, 40 €/mes), eliminar dos discos no associats (18 €/mes), comprar una reserva de 3 anys del PostgreSQL (impacte alt, 55 €/mes) i activar còpies de seguretat a la base de dades (categoria fiabilitat, sense estalvi). Prioritza les quatre, indica decisió i motiu, i digues quina configuració d'Advisor ajustaries per a aquest projecte.

Solució 1: comprovacions prèvies. (1) Finestra i estacionalitat: 30 dies poden no cobrir un procés mensual; ampliar la finestra a 60 o 90 dies i mirar el percentil 95 de CPU, no només la mitjana —una màquina al 3 % de mitjana que arriba al 90 % durant dues hores cada nit està ben dimensionada—. (2) Altres dimensions: la recomanació es basa en CPU i xarxa, però la màquina pot estar limitada per memòria o per IOPS de disc; cal mirar la memòria disponible a log-contoso-pro abans de reduir una mida que també redueix RAM i IOPS màximes. (3) Requisits del programari: alguns motors exigeixen un mínim de vCPU per llicència o configuració. (4) Impacte operatiu: el canvi de mida exigeix reiniciar la màquina, així que necessita finestra, encara que en desenvolupament sigui trivial. (5) Coherència amb la línia base: si aquesta VM està coberta per una reserva, redimensionar-la la pot deixar sense ús —aquí no s'aplica, és desenvolupament i no està reservada—. Es rebutjaria, tot i la dada correcta, si la màquina fos l'agent d'un procés mensual de tancament que consumeix tota la CPU un dia al mes, o si fos allà com a capacitat de contingència per assumir la càrrega d'un altre entorn. En aquest cas concret —desenvolupament, sense reserva, sense procés mensual— s'aplica: el risc és nul i l'estalvi és real.

Solució 2: la consulta i el procediment.

Abans d'esborrar: (1) agrupar per propietari i enviar a cadascun la seva llista, amb termini de 10 dies per reclamar el que vulgui conservar —qui va crear la instantània sap per què—; (2) creuar amb el registre d'activitat a log-contoso-pro per descartar que alguna s'hagi fet servir recentment per crear un disc; (3) comprovar si alguna precedeix una migració d'esquema o un canvi important, que és justament la que cal conservar; (4) etiquetar en lloc d'esborrar en la primera passada, amb una etiqueta caducidad=2026-10-01, i esborrar en la revisió mensual següent el que ningú no hagi reclamat; i (5) deixar constància a l'informe mensual. La instantània sense propietari és el cas difícil: si ningú no la reclama i no hi ha traça d'ús, s'esborra, però aquesta situació és en si mateixa una recomanació de governança —exigir l'etiqueta propietario amb una directiva Deny del mòdul 4—.

Solució 3: prioritat i decisions. Primer, activar les còpies de seguretat (fiabilitat, sense estalvi): no és una recomanació de cost, però és l'única l'absència de la qual pot costar el projecte sencer; el criteri de priorització mai no és només l'euro. Segon, eliminar els discos no associats (18 €/mes): risc nul, esforç mínim, amb instantània prèvia de 30 dies. Tercer, reduir la SKU d'App Service (40 €/mes): s'aplica només si hi ha 60 dies de dades i el percentil 95 ho avala, i tenint en compte que baixar de Premium v3 a un nivell inferior pot fer perdre ranures de desplegament, redundància de zona o escalat automàtic —cal comprovar què es perd abans de mirar el que es guanya—. Quart i ajornada, la reserva de 3 anys del PostgreSQL (55 €/mes): és el major estalvi i la decisió més perillosa, perquè el projecte té quatre mesos de vida i no compleix la regla de Contoso de tres mesos d'ús estable; s'ajorna 60 dies i, si el consum es confirma, es compra a 1 any en lloc de 3, atès l'horitzó de negoci de dos anys. Configuració d'Advisor a ajustar: incloure la subscripció del projecte a l'àmbit, fixar la finestra d'observació en 60 dies perquè l'estacionalitat de bescanvis no generi soroll, un llindar de CPU del 10 % intermedi pel fet de tractar-se de producció de baix risc, i una alerta d'impacte alt dirigida a ag-equipo-contoso amb el responsable del projecte com a destinatari addicional.

Ja saps què és Azure Advisor i per què és el punt de partida obligatori de qualsevol exercici d'optimització: és gratuït, analitza els teus recursos reals en lloc de donar-te consells genèrics, quantifica l'estalvi de cada recomanació i és allà des del primer dia. Coneixes les seves cinc categories —fiabilitat, seguretat, excel·lència operativa, rendiment i cost—, la seva correspondència amb els cinc pilars del Well-Architected Framework que veuràs a 09-02, i el fet fonamental que estiren en direccions oposades: l'eina presenta el conflicte, l'arquitecte el resol. Interpretes la puntuació com a indicador de procés i no com a objectiu, sabent que baixa quan creixes i que descartar amb motiu és una manera legítima d'apujar-la.

Domines les recomanacions de cost en els seus quatre grups: infrautilització amb la seva finestra i el seu llindar, recursos orfes —discos no associats, IP públiques reservades, instantànies antigues, passarel·les sense connexions, equilibradors sense backend, comptes buits—, canvi de mida i de SKU, i les recomanacions de compra que ja sabies no acceptar a cegues. Has recorregut la llista completa de Contoso decidint una per una entre aplicar, ajornar o descartar, amb 457 € al mes de malbaratament pur eliminats sense tocar ni un sol recurs en ús, i amb les dues recomanacions descartades que demostren el límit de l'automatització: la reducció de vmss-api-disponibilidad-pro, que ignora la temporada d'estiu, i el disc disk-motor-datos-copia, que és una còpia deliberada. Advisor proposa; una persona amb context decideix, i deixa constància del motiu i de la data de revisió.

Saps a més consultar-lo i automatitzar-lo amb CLI, alertar només sobre l'impacte alt cap a ag-equipo-contoso, i configurar-lo amb criteri: llindar alt en desenvolupament, llindar baix i finestra de 60 dies en producció, exclusions només per a infraestructura la naturalesa de la qual és estar ociosa. Situes el seu paper d'aparador de Defender for Cloud i de Cost Management. I, sobretot, saps anar a buscar el malbaratament que Advisor no veu amb Azure Resource Graph: discos orfes, recursos sense les quatre etiquetes obligatòries, IP i equilibradors sense ús, entorns de desenvolupament encesos de matinada tot i el runbook, comptes d'emmagatzematge fora de regió. Tot això versionat a contoso-infra i condensat en l'informe mensual d'una pàgina que la Marta porta al comitè, amb la seva secció de descarts i el seu estalvi real mesurat.

Amb això tens les tres grans fonts d'estalvi identificades i quantificades: l'estimació que evita la despesa abans de crear-la, el compromís que rebaixa el preu del que ja funciona, i la neteja que elimina el que no serveix a ningú. Falta el més difícil, que no és tècnic: convertir tot això en una manera de treballar que no depengui que algú se'n recordi. La lliçó que tanca el mòdul tracta de FinOps: les seves tres fases i els seus tres protagonistes —la Nuria, la Marta i en Diego—, el catàleg complet de palanques d'optimització consolidant tot el que s'ha après al curs, el compromís conscient entre cost, fiabilitat, rendiment i seguretat, el pla prioritzat de Contoso amb la seva taula d'abans i després, el cost unitari com a indicador que de debò importa, la revisió mensual com a procés de govern, i els antipatrons que arruïnen qualsevol iniciativa d'optimització —començant pel més car de tots: estalviar cinquanta euros a costa de vint hores d'enginyeria—.