La lliçó anterior va deixar la factura de MercadoFresco en 1.749,60 USD al mes, un 22 % per sota del punt de partida, i amb una anàlisi capaç d'explicar cada línia. Però tot això és mirar cap enrere. Si demà algú aixeca un clúster de proves al compte de desenvolupament i se n'oblida, o si una consulta nova es dispara un divendres a la nit, la factura creixerà sense que res s'hi interposi pel camí. Encara ningú no hi ha posat cap límit.

Aquesta lliçó passa d'analitzar a controlar. Veuràs la diferència entre el Cost Explorer i Budgets i per què l'alarma de facturació de 01-02 es queda curta, els quatre tipus de pressupost i les seves periodicitats —inclosos els planificats per a la campanya de Nadal—, la distinció entre llindars sobre cost real i previst, els pressupostos concrets que crea MercadoFresco per compte, servei, etiqueta i categoria de cost, la seva creació per consola, CLI i CDK, les notificacions, i la part amb dents: les accions de pressupost capaces de congelar el compte de desenvolupament quan arriba al seu límit. Al final, la rutina FinOps que sosté tot el cicle.

Avís de cost. Els dos primers pressupostos són gratuïts; a partir d'aquí costen 0,02 USD per pressupost i dia, és a dir, uns 0,60 USD al mes cadascun. Els deu pressupostos de MercadoFresco costen al voltant de 4,80 USD mensuals, un 0,27 % de la factura, que és probablement la millor assegurança del catàleg. Les accions de pressupost costen a part, uns 0,10 USD per acció i dia. Dades, comptes i identificadors ficticis.

1. Analitzar enfront de controlar
2. Per què l'alarma de facturació de 01-02 es queda curta
3. Els quatre tipus de pressupost
4. Periodicitat: fixos, recurrents i planificats
5. Cost real enfront de cost previst
6. Llindars escalonats i a qui avisa cadascun
7. Els pressupostos de MercadoFresco
8. Crear un pressupost per consola, CLI i CDK
9. El JSON complet, comentat
10. Notificacions: correu, SNS i Slack
11. Accions de pressupost
12. El compte de desenvolupament que es congela sol
13. L'advertiment sobre producció
14. Informes de pressupostos i revisió mensual
15. Bones pràctiques
16. Quan un pressupost se supera per una raó legítima
17. FinOps: informar, optimitzar i operar
18. La reunió mensual de cost
19. Errors habituals i consells
20. Exercicis
21. Conclusió

Les dues eines s'assemblen a la pantalla i són radicalment diferents en el seu propòsit:

La diferència pràctica és senzilla: el Cost Explorer requereix que algú se'n recordi, de mirar; Budgets no requereix que ningú faci res. I en una empresa de tres persones, tot allò que requereix que algú se'n recordi acaba fallant algun mes.

Convé també situar-lo enfront de la detecció d'anomalies d'11-03, amb la qual es confon:

• Detecció d'anomalies: «aquesta despesa no s'assembla al teu patró habitual». És estadística, no té opinió sobre si te la pots permetre.
• Budgets: «has superat el límit que tu mateix has posat». És una decisió de negoci expressada en un número.

Totes dues són necessàries i responen a casos diferents. Una pujada gradual del 3 % mensual durant sis mesos no dispara cap anomalia —és perfectament normal mes a mes— i sí que acaba rebentant el pressupost. Un pic d'un dia dispara l'anomalia i probablement no mogui el pressupost mensual.

A la lliçó 01-02, amb el compte acabat de crear, es va configurar una alarma de facturació de CloudWatch sobre la mètrica EstimatedCharges amb un llindar de 10 USD, i també el pressupost presupuesto-mensual-mercadofresco amb el mateix import. Allò va ser el correcte aleshores i avui és inútil, per cinc raons:

1. L'import està obsolet. Fa vint-i-tants mesos que salta el dia 2 de cada mes. Una alarma que sempre està en vermell no és una alarma: és soroll, i ja ningú no en llegeix els correus.
2. És global. Un sol número per a tota l'organització no diu on és el problema.
3. Només mira cost real. S'assabenta quan ja s'ha gastat, no quan es gastarà.
4. La mètrica EstimatedCharges només existeix a us-east-1 i és del compte de gestió: no permet vigilar un compte membre per separat.
5. No pot fer res. Notifica i prou.

La primera acció d'aquesta lliçó és, per tant, jubilar aquell pressupost: pujar-ne l'import al valor real i convertir-lo en el pressupost global de l'organització. No s'esborra —conserva l'històric— però deixa de ser un vestigi.

Els dos primers són els que es fan servir cada dia. Els dos últims existeixen perquè un compromís mal aprofitat són diners perduts de manera silenciosa, i esdevenen imprescindibles a partir d'11-05.

El pressupost d'ús és el menys conegut i resol un problema que el de cost no veu: si el preu d'un servei baixa, un pressupost de cost deixa d'avisar encara que el consum s'hagi disparat. MercadoFresco el fa servir per als NAT Gateway, on el volum de dades processades és un indicador de salut de l'arquitectura a més d'un cost.

El pressupost planificat és el que resol el problema real de MercadoFresco: al desembre, la campanya de Nadal multiplica les comandes i amb elles la despesa. Amb un pressupost mensual recurrent de 2.000 USD, el desembre dispara tots els llindars i l'equip aprèn a ignorar-los justament el mes en què més atenció cal.

El pressupost planificat de MercadoFresco:

I amb això es guanya una cosa més valuosa que un avís ben calibrat: la conversa de novembre. Posar-li un número al desembre obliga a estimar-lo, i estimar-lo obliga a parlar amb negoci sobre quantes comandes s'esperen. Un pressupost és, abans que un control, un exercici de previsió.

Cada llindar d'un pressupost es pot avaluar contra dues coses diferents, i cal configurar-les totes dues:

L'exemple que ho aclareix. Un pressupost de desenvolupament de 170 USD mensuals:

• El dia 9, s'han gastat 51 USD. El llindar real del 80 % (136 USD) no dispara: falta molt.
• Aquest mateix dia, la previsió de final de mes és de 170 USD, perquè el ritme diari ha pujat des del dia 6. El llindar previst del 100 % sí que dispara.
• Queden 21 dies per corregir. Aquesta és tota la diferència entre assabentar-se'n a temps i assabentar-se'n tard.

Dos advertiments sobre el previst, que no és màgia:

1. Necessita historial. Un pressupost acabat de crear, o un compte nou, no genera previsions fiables durant les primeres setmanes. AWS necessita de l'ordre de cinc setmanes de dades.
2. Extrapola. Si el dia 3 es va fer una migració puntual que va consumir molt, la previsió es creurà que allò es repeteix tot el mes i dispararà una falsa alarma. S'aprèn a reconèixer-les.

La configuració estàndard de MercadoFresco combina totes dues: previst al 80 % i al 100 % per anticipar, real al 100 % per constatar, i en el cas de desenvolupament, real al 100 % amb acció automàtica.

Un pressupost amb un sol llindar al 100 % avisa quan ja no es pot fer res. Un amb cinc llindars genera tant soroll que s'ignoren tots. Tres és el número que funciona:

La lògica de l'escalat té un principi al darrere: cada llindar ha de tenir un destinatari diferent i una acció esperada diferent. Si el 50 % i el 80 % avisen les mateixes persones perquè facin el mateix, un dels dos sobra. I el 50 % de MercadoFresco no envia correu a ningú expressament: arribar a la meitat del pressupost a mitjan mes és exactament el que ha de passar.

Deu pressupostos, tots coherents amb la factura de 1.749,60 USD posterior a les optimitzacions d'11-03:

Quatre decisions de disseny d'aquesta taula mereixen explicació:

El marge sobre la despesa actual és d'entre el 10 i el 20 %. Ni enganxat —dispararia cada mes per variacions normals— ni folgat —no avisaria mai—. La regla de MercadoFresco: el pressupost es fixa un 15 % per damunt de la despesa real dels tres últims mesos, i es revisa cada trimestre.

La suma dels pressupostos per compte (1.985 USD) és menor que el global (2.000 USD). És intencionat: si tots els entorns s'acosten al seu límit alhora, el global també avisa. Al revés —pressupostos per equip que sumen més que el global— és l'error clàssic que fa que ningú no se'n doni mai per al·ludit.

Desenvolupament és el més estricte i l'únic amb acció. El seu marge és del 18 % però el seu llindar d'acció és el cost real al 100 %, no el previst, per no congelar el compte per una previsió equivocada. És l'entorn on un error costa poc de corregir i on més experiments es fan.

Hi ha pressupostos que se solapen expressament. El d'analitica creua comptes i el de CloudWatch creua serveis: tots dos capturen despesa que ja està comptada als pressupostos per compte. No passa res per comptar dues vegades quan la finalitat és vigilar dues dimensions diferents. El que no s'ha de fer és sumar-los.

Per consola, a Billing → Budgets → Create budget, el flux és: plantilla o personalitzat → tipus → periodicitat i import → filtres (compte, servei, etiqueta, categoria) → llindars i destinataris → accions. És còmode per al primer i desaconsellable per als deu: un pressupost creat a mà no és a Git, no es revisa per pull request i desapareix si algú l'esborra.

Per CLI, amb dos fitxers JSON:

Per CDK, que és com MercadoFresco els manté de debò, al repositori mercadofresco-infra:

Tres detalls del codi que eviten errors freqüents:

• TagKeyValue amb el format user:Clau$Valor. Aquest $ com a separador i el prefix user: són obligatoris i no apareixen al lloc més obvi de la documentació. Amb la sintaxi mal escrita, el pressupost es crea sense error i filtra a zero, de manera que no avisa mai.
• include_tax=False i include_credit=False. Coherent amb la decisió d'11-03: el número de treball és el cost de serveis. Amb els impostos inclosos, un pressupost de 2.000 USD saltaria amb 1.653 USD de despesa real i ningú no sabria per què.
• use_amortized=True. Avui no canvia res perquè no hi ha compromisos, però a partir d'11-05 sí: sense amortitzar, el mes en què es pagui un Savings Plan per avançat dispararia tots els llindars de cop.

L'equivalent per CLI del pressupost de desenvolupament, que és el més complet perquè inclou acció:

I el fitxer d'avisos, que és un fitxer a part i no una propietat de l'anterior:

Els camps que importen:

• ThresholdType admet PERCENTAGE o ABSOLUTE_VALUE. El percentatge sobreviu als canvis d'import del pressupost; l'absolut s'ha d'actualitzar a mà i s'oblida.
• ComparisonOperator admet GREATER_THAN, LESS_THAN i EQUAL_TO. El LESS_THAN té un ús legítim poc conegut: avisar que la utilització d'un Savings Plan ha baixat d'un mínim, que és justament el que caldrà a 11-05.
• IncludeSupport: true i IncludeSubscription: true es deixen actius: la quota de suport i les subscripcions són despesa real que cal controlar, a diferència dels impostos.
• Es poden barrejar destinataris SNS i correu en el mateix llindar. Deu subscriptors com a màxim per notificació.

Tres canals, amb papers diferents:

Perquè Budgets pugui publicar al tema alertas-mercadofresco cal autoritzar-ho explícitament a la política del tema, i és el pas que més vegades s'oblida:

Les condicions aws:SourceAccount i aws:SourceArn no són cap adorn: sense elles, qualsevol pressupost de qualsevol compte d'AWS podria publicar en aquest tema. És el patró de protecció contra el «suplent confós» que ja es va veure a 04-01.

El resultat a Slack, a través del canal #mercadofresco-alertas que l'equip ja fa servir des del mòdul 5, té un avantatge afegit sobre el correu: és públic dins de l'equip. Un avís que veu tothom s'atén; un que arriba a una bústia compartida, no.

Aquí Budgets deixa de ser un sistema d'avisos i passa a ser un control. Una acció de pressupost (Budget Action) s'executa quan s'arriba a un llindar i pot fer tres coses:

I en dos modes:

• Automàtic (AUTOMATIC): s'executa sola en arribar al llindar.
• Manual (MANUAL): notifica i espera que una persona autoritzada l'aprovi des de la consola.

La regla que governa l'elecció és senzilla i no admet excepcions còmodes: automàtic només on el pitjor cas sigui una molèstia; manual on el pitjor cas sigui un incident.

El cas concret de MercadoFresco: el compte 333344445555 té un pressupost de 170 USD i, en arribar al 100 % de cost real, se li adjunta automàticament una SCP que impedeix crear recursos nous.

La política que s'aplica:

I la seva configuració com a acció:

Les decisions que fan que això sigui segur i no una bomba:

• Només es denega la creació de recursos cars. El que ja funciona continua funcionant: ningú no perd la feina en curs. Es pot continuar desplegant codi, llegint registres i consultant bases de dades. L'única cosa que no es pot fer és encendre alguna cosa nova i cara.
• Es dispara amb cost real, no previst. Congelar un compte per una previsió equivocada seria inacceptable fins i tot a desenvolupament.
• La SCP s'aplica només al compte 333344445555, no a l'OU sencera. Un error al TargetIds que apuntés a l'OU Cargas congelaria també producció, i aquest és exactament el tipus d'accident que cal dissenyar perquè no pugui passar.
• El rol d'execució té permisos mínims: només organizations:AttachPolicy sobre aquesta política i aquest compte.
• Hi ha un procediment de desbloqueig escrit a mercadofresco-infra/docs/runbooks/, amb qui el pot executar (la Marta) i què es documenta després. Una acció automàtica sense procediment de reversió documentat és un parany per a l'equip.

L'efecte real observat el primer mes: el dia 24 de setembre, el compte va arribar a 170 USD perquè el Luis havia aixecat un clúster d'EKS per a l'exercici de 10-03 i el va deixar encès un cap de setmana. La SCP es va aplicar, el Luis va veure l'avís a Slack, va esborrar el clúster i la Marta va treure la SCP en deu minuts. Cost de l'incident: uns 40 USD. Sense el pressupost, el clúster hauria continuat encès fins a la revisió mensual: uns 220 USD.

Convé dir-ho amb tota claredat perquè és l'error més greu que es pot cometre amb aquesta eina:

No apliquis mai una acció automàtica restrictiva al compte de producció sense entendre exactament què es trenca.

L'escenari que ho explica: un divendres de campanya, les comandes es disparen, la despesa puja i el pressupost de producció arriba al 100 %. L'acció automàtica denega ecs:CreateService i elasticloadbalancing:CreateLoadBalancer. Fins aquí, potser inofensiu. Però si la política inclogués ec2:RunInstances o qualsevol acció que faci servir l'autoescalat, el sistema no podria escalar precisament en el moment en què més falta fa, i una decisió d'estalvi de 300 USD provocaria una caiguda que costa molt més que això.

Per això el pressupost pres-mf-produccion de MercadoFresco:

• No té cap acció automàtica. Cap.
• Té una acció manual de només notificació reforçada al 120 %, que exigeix aprovació explícita i que a la pràctica és un recordatori que cal mirar.
• El seu marge és més gran que el de la resta, perquè un mes bo de vendes ha de cabre-hi sense generar alarma.

I el principi general que se'n deriva: el control de costos no ha de poder degradar mai el servei als clients. Un pressupost superat es corregeix amb una decisió, no amb un tall automàtic.

L'AWS Budgets Reports permet programar un informe periòdic —diari, setmanal o mensual— amb l'estat de fins a 50 pressupostos, enviat per correu a un màxim de 50 destinataris. Costa 0,01 USD per informe enviat.

MercadoFresco en té un:

La seva funció no és informar —l'equip ja rep avisos a Slack— sinó obrir la reunió mensual amb un document comú. Que les quatre persones hagin vist el mateix PDF abans de seure estalvia els primers quinze minuts de qualsevol reunió de costos.

Les set regles que MercadoFresco escriu al seu document de gestió de costos:

1. Un pressupost per unitat amb propietari, no només un de global. Un pressupost global avisa que hi ha un problema; un per compte o per component avisa on és. El global sense els específics és gairebé inútil.
2. Marges del 10 al 20 % sobre la despesa real dels últims tres mesos. Enganxat genera falses alarmes; folgat no avisa mai.
3. Revisió trimestral de tots els imports, coincidint amb la revisió d'un pilar de Well-Architected. Un pressupost que fa un any que no es toca està malament, tant si sobra com si falta.
4. Llindars previstos per actuar, reals per constatar. Sempre tots dos.
5. Tot en codi. Els deu pressupostos viuen a mercadofresco-infra i es despleguen amb el pipeline. Un de creat a mà a la consola desapareix sense deixar rastre quan algú l'esborra.
6. Accions automàtiques només on el pitjor cas sigui una molèstia. Desenvolupament sí, preproducció potser, producció mai.
7. Un pressupost superat sempre genera una línia escrita, encara que la conclusió sigui «és normal, pugem l'import». Sense aquest registre, d'aquí a sis mesos ningú no recordarà per què el pressupost val el que val.

És el cas més comú i el pitjor gestionat. El negoci creix, les comandes pugen un 35 %, la factura puja un 20 % i el pressupost salta. No hi ha cap error, cap recurs oblidat ni cap ineficiència: simplement el número era d'abans.

El procediment de MercadoFresco, en quatre passos:

1. Comprovar el cost unitari abans que el total. Si el cost per comanda ha baixat o s'ha mantingut, el creixement és sa i la conversa és una altra. Si ha pujat, hi ha alguna cosa més que creixement.
2. Identificar la causa concreta. «Han pujat les comandes» no n'hi ha prou; cal veure quines línies de la factura han crescut i comprovar que creixen les que han de créixer —Fargate, Aurora, cues— i no les que no haurien de fer-ho —registres, transferència, orfes—.
3. Decidir explícitament: pujar el pressupost, optimitzar, o totes dues coses. La decisió la pren qui és propietari del pressupost, no qui el vigila.
4. Documentar el canvi d'import amb la seva data i el seu motiu al mateix repositori on viu el pressupost. El commit és el registre.

El que no s'ha de fer, i es fa constantment: pujar l'import a la consola sense dir-ho a ningú. Al cap d'un any, ningú no sap per què el pressupost de producció és de 3.400 USD ni qui ho va decidir, i el número ha deixat de significar res.

Tot el que hem vist a les tres últimes lliçons té un nom a la indústria: FinOps, la disciplina de gestionar la despesa al núvol com una responsabilitat compartida entre tecnologia, finances i negoci. El seu model té tres fases que es repeteixen en cicle:

Els tres principis que sostenen el model i que convé no perdre de vista:

• Els equips són propietaris de la seva despesa. No hi ha una persona que controla els diners de tothom: hi ha informació repartida i responsabilitat local. Per això el repartiment per Propietario d'11-02 importa.
• Les decisions es prenen sobre valor de negoci, no sobre cost absolut. Gastar més pot ser la decisió correcta. La pregunta mai no és «com gastem menys?» sinó «obtenim valor pel que gastem?».
• Un equip central habilita, no controla. A MercadoFresco aquest equip és la Marta amb dues hores al mes. En una empresa gran seria un equip, però el seu paper és el mateix: donar eines i context, no aprovar despeses.

Qui hi participa, en una empresa de tres persones:

La Marta instaura una reunió de 30 minuts, el dia 5 de cada mes, amb un guió fix:

Les tres regles que fan que la reunió sobrevisqui més de tres mesos:

1. Comença pel cost unitari, no pel total. Canvia el to de la conversa de «gastem molt» a «gastem bé o malament».
2. Una sola acció al mes. Dotze accions executades a l'any valen més que quaranta d'abandonades.
3. Ningú no s'emporta una sorpresa en públic. Si la despesa d'algú s'ha disparat, se'n parla abans. Una reunió de costos que es converteix en un tribunal deixa de celebrar-se.

Error: un únic pressupost global. Avisa que hi ha un problema i no diu on. Consell: un per compte com a mínim, i un per component crític. El global és el sostre, no l'instrument.

Error: pressupostos per equip que sumen més que el global. Cadascú es pensa que va bé i el total es dispara sense que ningú se'n doni per al·ludit. Consell: la suma dels específics ha de quedar per sota del global, deixant marge.

Error: fer servir només llindars sobre cost real. T'assabentes quan ja no es pot fer res. Consell: previst al 80 % i al 100 % per anticipar, real al 100 % per constatar.

Error: deixar el pressupost de 10 USD de la primera lliçó. Salta cada dia 2, s'ignora, i amb ell s'ignoren tots els altres avisos del mateix canal. Consell: un pressupost que sempre està en vermell fa mal actiu. Actualitza'l o treu-lo.

Error: incloure impostos i crèdits a l'import. El pressupost salta amb una despesa real molt inferior i ningú no entén per què. Consell: IncludeTax=false i IncludeCredit=false, coherent amb l'anàlisi d'11-03.

Error: escriure malament el filtre per etiqueta. El format és user:Clau$Valor; amb una altra sintaxi el pressupost es crea sense error i filtra a zero, de manera que no avisa mai. Consell: després de crear-lo, comprova a la consola que mostra una despesa actual diferent de zero.

Error: acció automàtica a producció. Un divendres de campanya, la política denega l'escalat justament quan cal. Consell: producció mai; i si algun dia es fa, que la política no toqui res que faci servir l'autoescalat.

Error: oblidar la política del tema SNS. El pressupost es crea, s'arriba als llindars i no arriba res. Consell: afegeix el permís a budgets.amazonaws.com amb aws:SourceAccount, i prova l'avís creant temporalment un pressupost de 0,01 USD.

Error: pujar l'import a la consola quan salta. Al cap de sis mesos ningú no sap per què el pressupost val el que val. Consell: l'import viu al CDK; canviar-lo és un commit amb el seu motiu.

Consell: crea el pressupost abans de crear els recursos. Un pressupost és un límit acordat, no un resum a posteriori. Quan s'obri un entorn nou, el primer que es desplega és el seu pressupost.

Consell: fes servir un pressupost d'ús per al que no vols que creixi, encara que avui sigui barat: GB pel NAT, GB ingerits a CloudWatch, peticions a l'API del Cost Explorer. El cost pot baixar de preu; el consum desbocat continua sent un símptoma.

Una empresa fictícia, RopaCircular, ven roba de segona mà. Té tres comptes —producció (2.800 USD/mes), preproducció (600 USD/mes) i dades (900 USD/mes)— i un equip de vuit persones. Al novembre, el Black Friday multiplica per tres les seves vendes. El gerent ha demanat «que no se'ns en vagi de les mans» i ha donat un sostre anual.

1. Proposa el conjunt de pressupostos amb els seus imports, tipus i periodicitats.
2. Indica quins llindars posaries a cadascun i a qui avisarien.
3. En quin compte posaries una acció automàtica i amb quina política exacta?
4. Com tractaries el novembre?

El dia 11 d'octubre arriba aquest avís a alertas-mercadofresco:

1. És motiu d'alarma? Raona-ho amb les dades disponibles.
2. Enumera tres comprovacions que faries, en ordre.
3. Si resulta que les comandes d'octubre van un 22 % per damunt de setembre, quina decisió prendries i què documentaries?

Et demanen aplicar una acció automàtica al compte de preproducció 222233334444, amb pressupost de 290 USD, per evitar que es dispari com va passar una vegada a desenvolupament.

1. Escriu la política que aplicaries, justificant què hi inclous i què en deixes fora.
2. Tria entre llindar real o previst i entre mode automàtic o manual, justificant-ho.
3. Enumera tres coses que podrien sortir malament i com les mitigaries.

Solució a l'exercici 1

(1) Conjunt de pressupostos proposat:

Cinc pressupostos amb marges d'entre el 14 % i el 17 %. La suma dels tres per compte (4.950 USD) queda lleugerament per damunt del global de 4.800, cosa que en aquest cas és acceptable perquè el global és planificat i actua com a sostre mensual; si es vol el patró estricte, es puja el global a 5.200.

El rc-anual mereix un comentari a part: és el que tradueix literalment el que ha demanat el gerent. Un pressupost anual acumula tot l'exercici i avisa quan la suma dels mesos transcorreguts apunta a superar el sostre. És l'únic que respon a la pregunta «complirem l'any?», que cap pressupost mensual no pot respondre.

(2) Llindars i destinataris:

Fixa't que l'anual fa servir llindars reals i més baixos: amb un horitzó de dotze mesos, arribar al 75 % al setembre ja és un senyal accionable.

(3) Acció automàtica: només a preproducció, i amb aquesta política:

Es denega crear recursos cars i no es toca res del que ja existeix. A producció no s'hi posa cap acció, per la raó de sempre: el pitjor cas és una caiguda durant el Black Friday, que costa moltíssim més que el sobrecost que s'evitaria. A dades tampoc: un procés de càrrega interromput a mitges pot deixar el magatzem inconsistent, que és un incident i no una molèstia.

(4) El novembre. Amb un pressupost planificat que assigni al novembre un import d'acord amb el triple de vendes —uns 8.500 USD globals— i amb dues mesures d'acompanyament: pujar els llindars d'anomalia durant la campanya, perquè el patró canvia i el detector generarà falsos positius; i desactivar temporalment l'acció automàtica de preproducció durant la setmana del Black Friday, ja que és quan més proves es fan i una congelació en aquell moment bloquejaria l'equip justament quan no s'ho pot permetre. Totes dues mesures es documenten amb data de reversió, perquè ningú no oblidi tornar-les a activar al desembre.

Solució a l'exercici 2

(1) És motiu d'alarma? D'alarma no, d'atenció sí. Les dades diuen això: el dia 11 s'ha consumit el 43,7 % del pressupost, quan el proporcional seria un 35,5 %. La previsió de 1.482 USD supera el pressupost en un 5,9 %, que és un marge petit i està dins del que una previsió es pot equivocar. A més, l'avís és del tipus previst, no real: queden 20 dies per actuar. Ignorar-lo seria un error, i alarmar-se també.

(2) Tres comprovacions, en ordre:

1. El cost per comanda. Si l'octubre porta més comandes que el setembre i el cost unitari es manté o baixa, el creixement és sa i la conversa passa a ser sobre l'import del pressupost, no sobre un problema tècnic. És la primera comprovació sempre.
2. Vista diària del mes al Cost Explorer, filtrada al compte de producció. Es busca un esglaó: si la despesa diària va pujar de cop un dia concret i s'hi manté, hi ha un recurs nou o un canvi de configuració; si la pujada és gradual, és volum de negoci.
3. Desglossament per servei comparant amb el mes anterior, mirant el valor absolut de la variació. Si pugen Fargate, Aurora i les cues, és activitat real. Si puja CloudWatch, la transferència de dades o apareix un servei que abans no hi era, és una altra cosa.

(3) Decisió i documentació. Amb les comandes un 22 % per damunt i el pressupost projectat un 5,9 % per damunt, el cost per comanda està baixant de manera notable: el sistema absorbeix un 22 % més de negoci amb un 6 % més de despesa. És la millor notícia possible.

La decisió correcta és pujar el pressupost de producció de 1.400 a 1.600 USD, i no fer cap optimització d'urgència. El que es documenta, al commit que canvia l'import al CDK:

Amb dos apunts que eviten problemes futurs: cal revisar també el pressupost global de 2.000 USD, perquè si producció puja a 1.600 la suma dels específics s'acosta massa al sostre; i convé anotar la revisió de gener, perquè l'import d'octubre incorpora un creixement que pot no ser permanent.

Solució a l'exercici 3

(1) La política. Preproducció té una particularitat que la distingeix de desenvolupament: s'ha d'assemblar a producció, i el pipeline hi desplega automàticament. Això condiciona què es pot denegar:

S'inclou la creació de bases de dades, clústers, memòries cau i instàncies, que a preproducció es creen a mà per a proves puntuals i són el que dispara la factura. Es deixa fora deliberadament ecs:CreateService, ecs:RunTask, elasticloadbalancing:*, lambda:* i cloudformation:*, perquè tot això ho fa servir el pipeline a cada desplegament: denegar-ho trencaria la integració contínua, i un equip que no pot desplegar a preproducció acaba desplegant a producció sense provar, que és infinitament pitjor que gastar 50 USD de més.

(2) Llindar i mode: ACTUAL al 100 % i mode MANUAL.

• Real i no previst, per la mateixa raó que a desenvolupament: una previsió equivocada no ha de bloquejar un entorn del qual depèn el pipeline.
• Manual i no automàtic, i aquesta és la diferència clau amb desenvolupament. A desenvolupament el pitjor cas és que el Luis no pugui aixecar una màquina de proves durant unes hores: una molèstia. A preproducció el pitjor cas és que es bloquegi la validació d'un desplegament urgent —per exemple, un pedaç de seguretat—: això ja és un incident. El mode manual notifica, mostra l'acció proposada i espera que la Marta l'aprovi amb un clic, cosa que preserva el control sense automatitzar el risc.

(3) Tres coses que podrien sortir malament i la seva mitigació:

Un quart risc que convé anticipar: l'avís de l'acció manual pot quedar-se sense aprovar si arriba un divendres a la tarda. La mitigació no és tècnica sinó organitzativa: acordar que les accions manuals pendents formen part de la revisió diària de la guàrdia, que és una de les troballes d'excel·lència operativa que 11-01 va deixar obertes.

MercadoFresco ha passat de saber el que gasta a no poder passar-se sense assabentar-se'n.

Saps distingir analitzar de controlar: el Cost Explorer mira cap enrere i requereix que algú se'n recordi; Budgets mira cap endavant i no requereix que ningú faci res. I saps situar-los enfront de la detecció d'anomalies, que respon a una altra pregunta —«això no s'assembla al teu patró»— i que no detecta una pujada gradual del 3 % mensual capaç de rebentar un pressupost en sis mesos. Amb les cinc raons per les quals l'alarma de 10 USD de 01-02 havia quedat inservible, la primera de les quals és la més greu: un avís que sempre està en vermell fa mal actiu, perquè ensenya l'equip a ignorar el canal sencer.

Tens els quatre tipus de pressupost —cost, ús, Savings Plans i reserves—, amb el d'ús com el menys conegut i el que detecta el que el de cost no veu quan baixen els preus. I les periodicitats, amb el pressupost planificat resolent el problema real de la campanya de Nadal: imports diferents per mes, de 2.000 en operació normal a 2.600 al desembre, perquè el mes que més atenció necessita no sigui justament el mes en què tots els avisos s'ignoren. Amb l'efecte col·lateral més valuós: posar-li un número al desembre obliga a estimar-lo, i estimar-lo obliga a parlar amb negoci.

Tens la distinció entre llindars sobre cost real i previst, i la raó de configurar tots dos: el dia 9 amb 51 USD gastats, el llindar real no dispara i el previst sí, deixant 21 dies per corregir. Amb els dos advertiments del previst —necessita unes cinc setmanes d'historial i extrapola qualsevol despesa puntual— i l'escalat de tres llindars amb la regla que l'ordena: cada llindar ha de tenir un destinatari i una acció esperada diferents, fins al punt que el 50 % de MercadoFresco no avisa ningú expressament.

Tens els deu pressupostos concrets sobre la factura de 1.749,60 USD: global de 2.000, producció 1.400, preproducció 290, desenvolupament 170, eines 70, govern 55, més els transversals per etiqueta analitica (220), per servei CloudWatch (170), d'ús de NAT (900 GB) i el planificat de Nadal. Amb les quatre decisions de disseny: marges del 10 al 20 %, la suma dels específics per sota del global perquè el sostre també avisi, desenvolupament com l'únic amb acció, i pressupostos que se solapen expressament perquè vigilen dimensions diferents —i que per això no se sumen—.

Tens la creació per consola, CLI i CDK, que és com es mantenen de debò, amb els tres detalls que fallen: el format user:Clau$Valor del filtre per etiqueta, que mal escrit crea un pressupost que filtra a zero i no avisa mai; IncludeTax i IncludeCredit a false per treballar sobre el cost de serveis; i UseAmortized activat des d'ara, perquè el mes en què es pagui un compromís no dispari tots els llindars. Més les notificacions pels tres canals i la política del tema SNS amb aws:SourceAccount i aws:SourceArn, que és el pas que més vegades s'oblida.

I tens la part amb dents: les accions de pressupost, amb els seus tres tipus —política IAM, SCP i aturar instàncies— i els seus dos modes, governats per una regla sense excepcions còmodes: automàtic només on el pitjor cas sigui una molèstia; manual on el pitjor cas sigui un incident. Amb el cas complet del compte de desenvolupament 333344445555, que es congela sol al 100 % de cost real mitjançant una SCP que només denega crear recursos cars i no toca res del que ja funciona, apuntada al compte i mai a l'OU, amb rol de permisos mínims i runbook de desbloqueig. I l'incident real que ho va justificar tot: un clúster d'EKS oblidat un cap de setmana, 40 USD en lloc de 220. Amb l'advertiment que cal gravar a foc: cap acció automàtica restrictiva a producció, perquè una política que impedeixi escalar un divendres de campanya converteix un estalvi de 300 USD en una caiguda que costa molt més.

I tens la rutina que ho sosté tot: els informes de pressupostos que obren la reunió amb un document comú, les set bones pràctiques, el procediment de quatre passos per quan un pressupost se supera per una raó legítima —començant sempre pel cost unitari, i acabant sempre amb un commit que expliqui el nou import—, i el marc FinOps amb el seu cicle d'informar, optimitzar i operar, els seus tres principis —els equips són propietaris de la seva despesa, les decisions es prenen sobre valor i no sobre cost, i l'equip central habilita en lloc de controlar— i la reunió mensual de 30 minuts que comença pel cost per comanda, produeix una sola acció i en la qual ningú no s'emporta una sorpresa en públic.

Queda una palanca sense fer servir, i és l'única que redueix la factura sense canviar absolutament res de l'arquitectura. Tot el que MercadoFresco té funcionant —les tasques de Fargate que estan enceses 24 hores al dia, les funcions Lambda que s'invoquen cada minut, els nodes d'ElastiCache que fa mesos que no s'apaguen— s'està pagant a preu sota demanda, és a dir, al preu de qui podria marxar demà. Hi ha una part d'aquest consum que és completament previsible i que continuarà sent-hi d'aquí a un any. I AWS paga per saber-ho per endavant.

A 11-05, «AWS Savings Plans», es tanca el cicle d'optimització comprometent capacitat: els quatre models de compra amb el seu descompte i el seu risc, com funciona el compromís per dòlar-hora amb un exemple numèric pas a pas, què cobreix cada tipus i què no —important en una arquitectura com aquesta, majoritàriament serverless—, com s'identifica la base estable enfront de la part elàstica, i el pla de compra concret de MercadoFresco amb el seu estalvi mensual i anual. Amb l'ordre que 11-03 ja va avançar i que aquí es justifica del tot: primer apagar el que sobra, després comprometre.