Contoso Airlines ja té totes les peces soltes: sap estimar abans de desplegar, sap què ha gastat i de qui és, sap quins compromisos comprar i sap on és el malbaratament. El que encara no té és el més difícil, que no és tècnic: una manera de treballar en què el cost es gestioni sol, sense dependre que algú se'n recordi. Perquè l'optimització que es fa una vegada es desfà sola en sis mesos. Tornen els discos orfes, torna l'entorn encès de nit, torna la ingesta de registres que ningú no consulta, i el trimestre següent la Nuria torna a preguntar el mateix.

Aquesta lliçó tanca el mòdul amb aquest salt: de les eines a la cultura FinOps. Veuràs les seves tres fases i els tres papers que la sostenen —la Nuria, la Marta i en Diego—, el catàleg complet de palanques d'optimització que consolida tot el que s'ha après al curs, el compromís conscient entre cost i fiabilitat, rendiment i seguretat, amb les retallades que Contoso rebutja deliberadament, el pla prioritzat amb la seva taula d'abans i després, el cost unitari com l'indicador que de debò importa, la revisió mensual com a procés de govern, el cost dins del cicle de vida del desenvolupament, i els antipatrons que arruïnen qualsevol iniciativa d'estalvi.

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

1. Què és FinOps i per què és cultura, no eina
2. Les tres fases i els tres papers
3. El catàleg complet de palanques d'optimització
4. El compromís: cost davant de fiabilitat, rendiment i seguretat
5. Les retallades que Contoso rebutja
6. El pla d'optimització de Contoso
7. Abans i després
8. Cost unitari: l'indicador que importa
9. La revisió mensual de costos
10. Polítiques que prevenen la despesa
11. El cost en el cicle de vida del desenvolupament
12. Antipatrons de l'optimització
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

FinOps és una disciplina operativa per gestionar la despesa al núvol: un conjunt de pràctiques que porten la responsabilitat econòmica a l'equip que pren les decisions tècniques, amb dades compartides i en temps gairebé real. No és un producte, no és un tauler i no es compra.

La raó per la qual cal és estructural i ja va aparèixer a 08-01: al núvol, qui gasta els diners és l'enginyer, no el departament de compres. Un model de control en què finances aprova i després enginyeria executa no funciona quan l'execució triga tres segons. Només queden dues opcions: bloquejar la gent amb processos d'aprovació que destrueixen l'agilitat que justificava el núvol, o donar a la gent la dada i la responsabilitat. FinOps és la segona.

Els tres principis que ho resumeixen:

• Visibilitat: cada equip veu el que gasta, amb detall suficient per actuar i sense demanar-ho a ningú.
• Responsabilitat: l'equip que decideix és el que respon de la seva factura, i té marge per decidir.
• Optimització contínua: no és un projecte trimestral, és una rutina mensual amb responsables i dates.

I el motiu pel qual s'insisteix que és cultura: les tres coses que més van estalviar a Contoso no van ser tècniques. Van ser un etiquetatge que permet saber de qui és cada euro, una revisió mensual d'una hora en què algú ha d'explicar les seves xifres, i el costum d'adjuntar una estimació a cada proposta d'arquitectura. Les eines executen; la cultura és la que fa que algú les miri.

El cicle es recorre contínuament i no es pot saltar la primera fase: optimitzar sense informar és endevinar. Contoso va trigar dos mesos en la fase d'informar —etiquetatge, política hereda-centro-coste, vistes, pressupostos, exportacions— abans de tocar ni un sol recurs, i aquest va ser el motiu que la fase d'optimitzar durés tres setmanes en lloc de sis mesos.

Els tres papers, amb nom propi:

La disfunció clàssica és que només hi participin dos dels tres. Si falten finances, l'equip optimitza sense saber si importa. Si falta enginyeria, es fixen topalls que trenquen producció. I si falta negoci —el cas més freqüent— es retalla el que és tècnicament fàcil en lloc del que és econòmicament irrellevant, que poques vegades coincideixen.

Aquesta és la taula que consolida tot el curs. Cada fila és una palanca vista en algun mòdul anterior, aquí posada al seu lloc econòmic.

Dues maneres de llegir aquesta taula. En vertical, és la llista de tot el que pots tocar. En horitzontal, és un avís: la columna de risc diu que les palanques més rendibles no són les més segures, i que hi ha tres files —redundància, retenció de còpies i mostreig— on estalviar significa acceptar més risc, no eliminar malbaratament. Aquesta distinció és el tema de l'apartat següent.

Hi ha dues classes d'optimització, i confondre-les és l'origen de gairebé tots els desastres:

La primera columna s'executa sense demanar permís: ningú no ha d'aprovar que s'esborri una IP pública que no està associada a res. La segona no la decideix mai enginyeria en solitari, perquè no és una decisió tècnica: és un intercanvi de diners per risc, i el risc l'assumeix el negoci.

La manera de plantejar correctament un compromís davant de qui l'ha de decidir té tres parts: quant s'estalvia, què es perd exactament i què passa el dia que això importi. Formulat així, la majoria de retallades discutibles cauen soles. Formulat com «podem estalviar 190 € al mes en emmagatzematge», gairebé totes s'aproven, i ningú no recorda per què el dia de l'incident.

Aquestes propostes van aparèixer a la revisió i es van rebutjar per escrit, que és tan important com el que sí que es va fer:

Contoso hauria pogut abaixar la seva factura uns altres 2.555 € al mes aplicant aquesta llista. Va decidir no fer-ho, i ho va escriure. Aquest document té més valor del que sembla: quan d'aquí a un any algú pregunti per què es paga GZRS, la resposta estarà escrita amb la seva data i la seva signatura, i ningú no haurà de reconstruir el raonament des de zero. Un equip madur no és el que més retalla: és el que sap què no retalla i per què.

Partint de la factura analitzada de juliol —17.800 €—, l'equip va prioritzar les accions per estalvi, risc i esforç. Xifres orientatives i fictícies:

El criteri d'ordenació no va ser l'estalvi absolut, sinó la relació estalvi ÷ (risc × esforç), i per això l'acció 3 —457 € de neteja sense risc ni esforç— es va executar abans que la 1, tot i estalviar sis vegades menys. Hi ha a més una dependència dura entre totes dues: la regla 3 de 08-03 exigeix optimitzar abans de comprometre's, així que la neteja i el redimensionament havien d'anar primer perquè la reserva es comprés sobre la plataforma ja aprimada.

I un advertiment sobre l'aritmètica que convé fer sempre: aquests estalvis no són perfectament additius. L'acció 2 redueix la ingesta i amb ella la base sobre la qual es calcularia un futur compromís de capacitat; l'acció 4 redueix l'egress però també les transaccions de Storage, encavalcant-se lleugerament amb la 5. L'estimació honesta que Contoso va portar al comitè no va ser una xifra sinó un interval: entre 12.400 € i 13.000 € al mes, i el nou pressupost es va fixar en 13.000 € per no prometre el millor cas.

Tres lectures. Cap servei no es va degradar: els temps de resposta, la disponibilitat i l'RPO/RTO són idèntics abans i després, i així es va verificar amb els taulers del mòdul 7 durant les quatre setmanes següents. Més de la meitat de l'estalvi va venir de dos llocs —compromisos i observabilitat—, coherent amb la regla d'optimitzar de dalt a baix. I fw-contoso-hub-pro continua costant el mateix, perquè no tot el que és car és optimitzable, i reconèixer-ho forma part de la feina.

Un total absolut és un mal indicador, perquè no distingeix entre gastar més per créixer i gastar més per malbaratar. L'indicador que sí que ho distingeix és el cost unitari: cost dividit per unitat de valor de negoci. En una aerolínia, cost per reserva venuda.

La tercera fila és la que canvia la conversa al comitè. La factura d'agost puja un 10 % respecte al juliol i, mirada en absolut, sembla un fracàs. Mirada en cost unitari, és la millor notícia de l'any: la plataforma va absorbir un 60 % més de reserves amb un 10 % més de despesa, és a dir, escala amb eficiència creixent. Una factura que puja pot ser una excel·lent notícia, i sense cost unitari no hi ha manera de demostrar-ho.

L'indicador es calcula unint l'exportació diària de cost de stlagocontosopro (08-02) amb la taula de reserves, a syn-contoso-analitica-pro:

Contoso publica tres indicadors unitaris: cost per reserva venuda, cost per targeta d'embarcament emesa i cost per milió de peticions a l'API de Disponibilitat. Cadascun té responsable, i tots tres es revisen mensualment. La regla que els governa: l'objectiu no és que la factura baixi; és que el cost unitari baixi. Si el negoci creix un 40 % i la factura creix un 15 %, l'equip ha fet una feina excel·lent encara que la Nuria pagui més que el mes passat —i ho sap, perquè l'indicador l'hi ensenya—.

El procés que sosté tota la resta cap en una hora al mes:

Quatre regles apreses per les males i que marquen la diferència entre una reunió útil i una cerimònia:

• S'envia l'informe abans. Una reunió que comença llegint dades no pren decisions.
• Tota acció té nom i data. «Caldria mirar el tema dels registres» no és una acció.
• Es compara l'estalvi promès amb el realitzat. És el punt que dona credibilitat, i també el que destapa les estimacions optimistes.
• Es celebra el cost unitari, no la factura. Si es premia abaixar la factura, algú acabarà frenant el creixement del negoci per aconseguir-ho.

L'optimització més barata és la que evita la despesa abans que existeixi, i per a això hi ha les directives del mòdul 4, aplicades des de la iniciativa «Base de governança de Contoso»:

Aquest últim matís mereix atenció perquè és el bucle complet del mòdul: una directiva pensada per millorar l'observabilitat crea despesa a log-contoso-pro. No és un argument per no tenir-la; és un argument per desplegar-la amb les categories de registre triades conscientment, en lloc d'activar-les totes.

I un advertiment sobre l'equilibri: una directiva Deny massa estricta es converteix en una cua d'excepcions que algú ha d'aprovar, i això reintrodueix exactament la fricció que el núvol venia a eliminar. Contoso manté una llista curta de Deny —regions, mides desproporcionades, etiquetes— i fa servir Audit per a tota la resta, revisant el resultat a la reunió mensual.

Que el cost sigui un criteri de disseny i no una auditoria posterior exigeix integrar-lo en quatre punts del procés, tots ja vistos:

La peça amb més efecte cultural és la tercera. Quan la sol·licitud d'incorporació de canvis mostra automàticament que apujar la SKU d'una base de dades són 380 € al mes (08-01), la conversa sobre cost passa entre dos enginyers, en el moment en què canviar-ho costa editar una línia, i sense que ningú hagi de fer de policia. El cost deixa de ser una auditoria i es converteix en informació de disseny, que és tot l'objectiu de FinOps.

El tercer mereix un comentari a part perquè és el més freqüent entre equips tècnics motivats. Una jornada d'enginyeria té un cost que sol estar en l'ordre de diversos centenars d'euros; dedicar vint hores a un estalvi de 50 € al mes triga gairebé un any a amortitzar-se, temps durant el qual aquestes vint hores podrien haver estat en una altra cosa. Abans d'optimitzar alguna cosa, estima quant costa optimitzar-la. És la mateixa disciplina de 08-01 aplicada a la feina pròpia.

• Creure que FinOps és una eina. Es compra un tauler i no canvia res; el que canvia les coses és la revisió mensual amb responsables.
• Confondre eliminar malbaratament amb acceptar un compromís. El primer s'executa; el segon es decideix amb el negoci i s'escriu.
• Optimitzar sense verificar després. S'aplica el canvi i ningú no comprova si l'estalvi va aparèixer a la factura.
• Mesurar només la factura total. Sense cost unitari no es distingeix créixer de malbaratar.
• Retallar observabilitat a cegues. És la partida més fàcil de tocar i la que et deixa sense instruments.
• No escriure el que es rebutja. D'aquí a un any ningú no recordarà per què es paga GZRS.
• Automatitzar apagades sense salvaguardes per etiqueta. Un runbook mal filtrat apaga producció un dimarts.
• Consell: fixa avui la revisió mensual al calendari, encara que el primer informe sigui dolent. La rutina crea la dada, no a l'inrevés.
• Consell: publica el cost unitari al mateix tauler on l'equip mira la latència. El que es veu, es gestiona.
• Consell: guarda un registre de decisions de cost —aplicades i rebutjades— al costat de les plantilles de contoso-infra.

Exercici 1. La factura de Contoso Millas (centro-coste=CC-2077) és de 1.240 €/mes: App Service Premium v3 (420 €), PostgreSQL flexible amb alta disponibilitat (390 €), Log Analytics (180 €), blobs de justificants en GZRS (140 €) i Functions en consum (110 €). El projecte té 6.000 bescanvis al mes i un pressupost de 900 €. Proposa un pla prioritzat amb estalvi, risc i esforç, indica què no retallaries i calcula el cost unitari abans i després.

Exercici 2. Un enginyer proposa reduir la retenció de log-contoso-pro de 90 a 7 dies, estalviant 480 €/mes. Analitza la proposta: què es perd, quines alternatives hi ha amb el mateix estalvi i menys impacte, i com la plantejaries al comitè si tot i així s'hagués de fer.

Exercici 3. Dissenya la reunió mensual de costos d'una empresa de 40 persones amb una sola subscripció i 4.000 €/mes de factura. Defineix assistents, durada, ordre del dia, indicadors i què automatitzaries perquè l'informe es prepari sol.

Solució 1: cost unitari de partida: 1.240 € ÷ 6.000 bescanvis = 0,207 €/bescanvi. Pla prioritzat. (1) Log Analytics (180 €): aplicar les tres palanques de 07-02 —revisar amb Usage quines taules s'ingereixen, passar els registres de contenidor o d'aplicació no investigats a pla Basic i ajustar la retenció per taula—; estalvi estimat 90 €, risc baix, esforç mitjà; és la partida amb millor relació estalvi/risc. (2) PostgreSQL (390 €): l'alta disponibilitat amb redundància de zona duplica el còmput; això és un compromís, no malbaratament, així que ho decideix negoci —si un programa de fidelització tolera unes hores d'indisponibilitat, desactivar-la estalvia uns 180 €; si no, es manté i es busca en un altre lloc—. En paral·lel, sí que és malbaratament pur comprovar el dimensionament i reservar a 1 any si l'ús porta tres mesos estable (uns 60 € més). (3) App Service (420 €): comprovar si Premium v3 és necessari per redundància de zona i ranures o si es va triar per inèrcia; si el projecte tolera un nivell inferior, l'estalvi és gran, però es perden ranures i escalat —de nou, compromís—. (4) Blobs GZRS (140 €): passar a ZRS n'estalvia una part, però els justificants de bescanvi poden tenir valor probatori; no es retalla sense consultar-ho a legal. (5) Functions en consum (110 €): ja és al model més eficient; no es toca. El que no es retalla en cap cas: la retenció mínima legal dels justificants, i les còpies de la base de dades. Resultat plausible: ~330 € d'estalvi sense compromisos (Log Analytics, reserva i neteja) → 910 €/mes, cost unitari 0,152 €/bescanvi, un 27 % menys, pràcticament dins del pressupost sense degradar res. Si el negoci accepta a més renunciar a l'alta disponibilitat, es baixa de 900 € amb escreix, però aquesta decisió no la signa enginyeria.

Solució 2: què es perd amb 7 dies de retenció: la capacitat d'investigar qualsevol incident de més d'una setmana, la comparació amb la línia base del mes anterior, l'anàlisi de tendències que sustenta el mateix exercici d'optimització, i —crític— el compliment, perquè AzureActivity i els registres d'accés solen tenir requisits de conservació de mesos o anys; retallar a 7 dies de manera indiscriminada pot ser directament un incompliment. A més, els incidents de seguretat i el ransomware es detecten tard (07-05): sense registres no hi ha manera de reconstruir què va passar. Alternatives amb estalvi comparable i molt menys impacte, en ordre: (1) reduir la ingesta del que ningú no consulta —la palanca de més impacte—, identificant amb la taula Usage les taules que representen el gruix del volum i desactivant categories de diagnòstic no fetes servir o filtrant-les amb transformacions a la regla de recopilació; (2) pla Basic per a taules de gran volum i poca consulta com els registres de contenidor; (3) retenció diferenciada per taula, que és el que resol el conflicte: AzureActivity a 365 dies per compliment, AppTraces a 30, registres de depuració a 8; (4) arxiu a llarg termini, molt més barat, amb treballs de cerca quan calgui; i (5) exportació a stlagocontosopro per al que només es necessita de manera esporàdica. Amb la combinació de les cinc s'assoleix un estalvi similar conservant el que és investigable. Si tot i així s'hagués de fer la retallada, es planteja al comitè com a compromís explícit: «estalviem 480 €/mes i acceptem que qualsevol incident de més d'una setmana serà no investigable i que els registres d'auditoria deixaran de complir el requisit X», amb la signatura de qui assumeix aquest risc i una data de revisió.

Solució 3: assistents quatre persones: qui porta finances, qui porta infraestructura, un representant de producte i el responsable tècnic del producte principal; més de cinc persones per a 4.000 € és desproporcionat. Durada 30 minuts mensuals. Ordre del dia: (1) factura del mes, variació i desviació respecte al pressupost, 5 min; (2) cost unitari de l'indicador de negoci triat, 5 min; (3) top 5 de partides i anomalies detectades, 5 min; (4) malbaratament d'Advisor i Resource Graph amb decisió aplicar/ajornar/descartar, 10 min; (5) accions amb responsable i data, 5 min. Indicadors: total, variació mensual, cost unitari, percentatge de recursos sense etiquetar, estalvi realitzat davant del promès, i cobertura de compromisos si n'hi ha. Automatització: un runbook mensual a Azure Automation que executi az advisor recommendation list --category Cost i les consultes de Resource Graph d'orfes i de recursos sense etiquetar, aboqui el resultat en un compte d'emmagatzematge i publiqui el resum a Teams 48 hores abans de la reunió; una exportació diària de cost; pressupost amb alertes al 80 % real i 100 % previst cap al grup d'accions existent; i detecció d'anomalies activada. A aquesta mida no pertoca el chargeback —amb una sola subscripció i quatre persones, el showback i una conversa basten— ni comprar reserves abans de tenir tres mesos d'ús estable.

Ja saps què és FinOps i per què és cultura i no eina: al núvol qui gasta els diners és qui escriu la plantilla, i l'única alternativa a bloquejar la gent amb aprovacions és donar-li la dada i la responsabilitat. Coneixes les seves tres fases —informar, optimitzar, operar—, la regla que no es pot saltar la primera, i els tres papers amb els seus noms: la Nuria aportant pressupost i context econòmic, la Marta aportant el coneixement de què es pot tocar, i en Diego i producte decidint què val la pena; amb la disfunció típica que falti negoci i s'acabi retallant el que és tècnicament fàcil en lloc del que és econòmicament irrellevant.

Tens el catàleg complet de palanques que consolida el curs sencer —apagar, netejar orfes, dimensionar, escalar automàticament, instàncies d'accés puntual, reserves i plans d'estalvi, Hybrid Benefit, consolidar plans, nivells sense servidor amb pausa, escalat automàtic de RU/s, pausar Synapse, nivells i cicle de vida d'emmagatzematge, les tres palanques de Log Analytics, mostreig a Application Insights, memòria cau i CDN contra l'egress, plans d'allotjament adequats, arquitectures sense servidor i basades en esdeveniments, i límits de tokens— amb el seu estalvi típic i, sobretot, amb el seu risc. I amb ell, la distinció que evita els desastres: eliminar malbaratament s'executa sense demanar permís, acceptar un compromís ho decideix el negoci informat, amb les tres preguntes —quant s'estalvia, què es perd exactament i què passa el dia que això importi—. Per això Contoso va deixar 2.555 € al mes sobre la taula rebutjant per escrit treure la redundància de zona de db-reservas, la rèplica fg-contoso-reservas, el WAF, Defender for Cloud, el GZRS de les targetes, la retenció de còpies i el bastió.

T'endus el pla prioritzat complet, ordenat per estalvi dividit entre risc i esforç, amb la neteja executada abans que els compromisos; el resultat mesurat —de 17.800 € a 12.550 € al mes, un 29 % menys, sense degradar ni un sol servei— i l'honestedat de presentar-lo com a interval i pressupostar el pitjor cas. Saps que l'indicador que de debò importa és el cost unitari, que va baixar de 0,193 € a 0,136 € per reserva venuda i va continuar baixant en la temporada alta tot i que la factura pujava, perquè una factura que puja pot ser una excel·lent notícia i sense aquest indicador no hi ha manera de demostrar-ho. I tens el procés que ho sosté: la revisió mensual d'una hora amb els seus assistents, el seu informe enviat amb 48 hores, les seves accions amb nom i data i la seva comparació entre estalvi promès i realitzat; les polítiques que prevenen la despesa des de la governança del mòdul 4; la integració del cost en el cicle de vida del desenvolupament, amb l'estimació a la revisió d'arquitectura i el comentari automàtic a la sol·licitud de canvis de Bicep; i els antipatrons que arruïnen qualsevol iniciativa, amb el més car de tots ben identificat: estalviar cinquanta euros a costa de vint hores d'enginyeria.

Amb això es tanca el mòdul 8 i, amb ell, la construcció de la plataforma. Val la pena mirar el conjunt: Contoso Airlines va començar aquest curs amb una idea vaga del que era el núvol i acaba amb una plataforma desplegada sobre còmput, emmagatzematge i xarxes ben triats; amb les seves dades als serveis adequats i els seus nivells de servei justificats; assegurada amb identitat, RBAC, secrets, WAF, Defender for Cloud i directives que impedeixen crear el que no ha d'existir; lliurada per canalitzacions i infraestructura com a codi en lloc de per clics; ampliada amb contenidors, funcions, missatgeria i IA; observada d'extrem a extrem, investigable amb KQL, automatitzada i recuperable amb un pla provat; i ara estimada, mesurada, pressupostada, repartida, optimitzada i governada, amb cada euro imputat a un centre de cost i cada decisió de retallada —incloses les que es van rebutjar— escrita amb el seu motiu. La pregunta de la Nuria Peña, la que va obrir aquest mòdul, té per fi resposta: se sap quant costa cada peça, quina part d'aquesta factura és valor i quina part era malbaratament, i qui decideix sobre cadascuna.

Queda una última cosa, i és mirar tot això de cop. Al llarg de vuit mòduls has vist la plataforma per parts, cadascuna a la seva lliçó, i aquesta és la manera d'aprendre-la; però no és la manera en què existeix. El mòdul 9 tanca el curs amb la vista de conjunt: l'arquitectura completa de Contoso Airlines dibuixada sencera, amb tots els seus components i totes les seves connexions, perquè la puguis llegir com es llegeix un plànol; l'Azure Well-Architected Framework, que és el marc que justifica —o desmunta— cadascuna de les decisions que has anat prenent, amb els seus cinc pilars i els seus compromisos entre ells; els errors comuns que es repeteixen a totes les organitzacions i com evitar-los abans de cometre'ls; com es migra una organització sencera amb el Cloud Adoption Framework, perquè Contoso encara té sistemes a Barcelona; i cap on va Azure, amb les certificacions que acrediten el que ja saps fer. Ja tens totes les peces: el mòdul 9 és on aprens a llegir el conjunt amb criteri.