Che cosa significa ottimizzare in FinOps

Nell’ambito FinOps, ottimizzare non significa semplicemente trovare l’infrastruttura meno costosa. Significa utilizzare la quantità corretta di tecnologia, nel momento e nel luogo appropriati, pagando una tariffa coerente con il profilo della domanda e con gli obiettivi aziendali.

Il dominio Optimize Usage & Cost della FinOps Foundation distingue due dimensioni complementari:

1. ottimizzazione dell’utilizzo, che riguarda quali risorse vengono consumate, per quanto tempo, con quale configurazione e con quale livello di efficienza;
2. ottimizzazione delle tariffe, che riguarda quanto viene pagato per le risorse effettivamente necessarie.

Questa distinzione è fondamentale. Acquistare uno sconto per una risorsa sovradimensionata non elimina l’inefficienza: la rende soltanto meno costosa.
Allo stesso modo, ridurre l’utilizzo senza verificare le prestazioni può
compromettere la qualità del servizio.

Il costo più basso non è sempre il risultato migliore

Una configurazione più economica può aumentare i tempi di risposta, ridurre la resilienza o richiedere un notevole lavoro di engineering.
Per questo motivo ogni raccomandazione deve essere valutata nel contesto del workload.

Una decisione FinOps dovrebbe considerare almeno:

• beneficio economico atteso;
• tempo necessario per realizzare l’intervento;
• rischio tecnico e operativo;
• impatto su prestazioni e disponibilità;
• durata prevista del workload;
• reversibilità della decisione;
• valore aziendale prodotto dal servizio.

A cosa servono gli strumenti FinOps

Gli strumenti FinOps raccolgono, normalizzano e analizzano dati provenienti da fatture, API dei provider, account, subscription, sistemi di monitoring e piattaforme aziendali. Il loro obiettivo è rendere più semplice la comprensione dei costi e l’identificazione delle opportunità.

Una piattaforma può evidenziare che una macchina virtuale presenta un utilizzo medio ridotto o che un database non viene utilizzato durante la notte. La decisione finale, tuttavia, richiede conoscenza tecnica: il basso utilizzo potrebbe dipendere da un requisito di alta disponibilità, da picchi periodici o da un servizio critico che deve rimanere sempre pronto.

Le funzioni principali

Le funzionalità più comuni comprendono:

• analisi della spesa per periodo, servizio e organizzazione;
• cost allocation e gestione dei costi condivisi;
• budget, forecast e monitoraggio degli scostamenti;
• rilevazione delle anomalie;
• raccomandazioni di rightsizing;
• identificazione delle risorse inattive o sottoutilizzate;
• analisi di copertura e utilizzo dei commitment;
• showback e chargeback;
• definizione di policy;
• automazione degli interventi;
• reporting per finance, engineering e management.

Uno strumento non sostituisce il modello operativo

Le raccomandazioni diventano utili soltanto quando vengono inserite in un processo. Ogni opportunità dovrebbe essere associata a:

• un proprietario tecnico;
• un responsabile economico;
• una stima del beneficio;
• una priorità;
• una valutazione del rischio;
• una scadenza;
• uno stato di avanzamento;
• una verifica del risultato ottenuto.

Senza questo collegamento operativo, una dashboard rischia di diventare un catalogo permanente di opportunità mai realizzate.

Qualità e granularità dei dati

L’efficacia dello strumento dipende dalla qualità dei dati disponibili.
Un’analisi giornaliera può essere sufficiente per il reporting finanziario, ma non sempre permette di comprendere workload caratterizzati da forti variazioni all’interno della giornata.

È quindi necessario valutare:

• frequenza di aggiornamento;
• granularità temporale;
• granularità a livello di risorsa;
• copertura dei provider;
• correttezza dei metadati;
• capacità di integrare metriche tecniche e finanziarie;
• conservazione dello storico;
• modalità di esportazione e accesso tramite API.

Gli strumenti nativi di AWS, Azure e Google Cloud

Le aziende che utilizzano un solo provider possono iniziare con gli strumenti nativi. Queste soluzioni sono integrate con i dati di fatturazione, non richiedono una nuova piattaforma e consentono di costruire i primi processi FinOps senza investimenti eccessivi.

Il limite principale emerge quando l’impresa deve confrontare provider, normalizzare tassonomie differenti o integrare costi cloud, SaaS, licenze e data center.

AWS Cost Explorer e Cost Optimization Hub

AWS Cost Explorer permette di visualizzare e analizzare costi e utilizzo AWS, applicando
filtri temporali, organizzativi e di servizio.

Per le attività di ottimizzazione, AWS propone AWS Cost Optimization Hub, che aggrega raccomandazioni provenienti da più servizi e account.

Tra le opportunità possono rientrare:

• rightsizing delle istanze EC2;
• rilevazione delle risorse inattive;
• ottimizzazione di database e storage;
• adozione di architetture più efficienti;
• Reserved Instances;
• Savings Plans.

Le raccomandazioni di rightsizing AWS aiutano a individuare istanze EC2 potenzialmente sovradimensionate o candidate alla terminazione.

Microsoft Cost Management

Microsoft Cost Management consente di analizzare la spesa Azure, impostare budget, esportare dati, configurare avvisi e gestire l’allocazione dei costi.

Azure mette inoltre a disposizione raccomandazioni e strumenti per:

• ottimizzare macchine virtuali e altri servizi;
• valutare Azure Reservations;
• analizzare Azure Savings Plan for Compute;
• monitorare l’utilizzo degli impegni acquistati;
• distribuire i costi delle reservation tra le unità organizzative.

Le prenotazioni Azure prevedono generalmente impegni di uno o tre anni per servizi compatibili.

Google Cloud Billing

La documentazione Google Cloud Billing raccoglie strumenti per monitorare, comprendere e ottimizzare la spesa Google Cloud.

Le principali funzionalità comprendono:

• report di fatturazione;
• budget e alert;
• esportazione dei dati verso BigQuery;
• analisi delle variazioni di costo;
• raccomandazioni di ottimizzazione;
• gestione dei Committed Use Discounts;
• attribuzione di costi e sconti ai progetti.

I Committed Use Discounts di Google Cloud applicano sconti in cambio di un impegno di utilizzo o di spesa per un periodo stabilito.

Quando serve una piattaforma FinOps dedicata

Una piattaforma dedicata può diventare utile quando la complessità supera la capacità degli strumenti nativi e dei processi manuali. La decisione non dovrebbe essere basata esclusivamente sulla dimensione della spesa, ma sul numero di fonti, stakeholder e decisioni da coordinare.

I segnali di complessità

L’adozione può essere giustificata quando:

• l’impresa utilizza più provider cloud;
• esistono centinaia di account, subscription o progetti;
• i dati devono essere normalizzati secondo una tassonomia unica;
• i costi condivisi richiedono regole articolate;
• sono necessari showback o chargeback su larga scala;
• le attività manuali richiedono troppo tempo;
• occorre integrare cloud, SaaS, licenze e data center;
• le raccomandazioni devono essere distribuite a numerosi team;
• servono workflow di approvazione e automazione;
• finance richiede dati contabili e forecast consolidati.

Le funzionalità da valutare

Prima della selezione è opportuno costruire una matrice dei requisiti, distinguendo tra funzionalità indispensabili, utili e non prioritarie.

Valutare il ritorno dell’investimento

Il business case non dovrebbe includere soltanto i risparmi potenziali. Una piattaforma può generare valore anche riducendo il tempo impiegato per produrre report, migliorando il forecast o accelerando la gestione delle anomalie.

Il ritorno può essere valutato attraverso:

• riduzione dei costi effettivamente realizzata;
• costi futuri evitati;
• ore di lavoro manuale eliminate;
• riduzione degli errori di allocazione;
• maggiore accuratezza delle previsioni;
• riduzione del tempo necessario per intervenire;
• aumento della copertura dei costi attribuiti;
• migliore utilizzo degli impegni di spesa.

La scelta degli strumenti dovrebbe quindi seguire la definizione del modello operativo, non precederla.

Il tema dell’ottimizzazione negli ambienti complessi è affrontato anche
nell’articolo Data Manager Ottimizzare i costi cloud, una necessità improrogabile

Rightsizing: dimensionare correttamente le risorse cloud

Il rightsizing consiste nell’adattare configurazione e capacità di una risorsa alla domanda effettiva del workload. L’obiettivo non è assegnare sempre la dimensione più piccola, ma eliminare la capacità inutilizzata mantenendo i requisiti tecnici e aziendali.

La capability Usage Optimization della FinOps Foundation considera correttamente dimensionate le risorse selezionate e configurate per soddisfare requisiti funzionali e non funzionali con il minor costo e impatto ambientale ragionevolmente possibile.

Quali risorse possono essere ridimensionate

Il rightsizing non riguarda soltanto le macchine virtuali. Può coinvolgere:

• istanze di calcolo;
• database gestiti;
• cluster Kubernetes;
• volumi e classi di storage;
• data warehouse;
• servizi di analytics;
• capacità serverless riservata;
• GPU e acceleratori;
• servizi di caching;
• piattaforme dati e AI.

Le metriche da analizzare

Una decisione non dovrebbe basarsi su una sola metrica media. I workload possono presentare picchi brevi ma indispensabili, stagionalità o requisiti di disponibilità che non emergono da una media mensile.

Le metriche più utili comprendono:

• utilizzo medio e percentile della CPU;
• utilizzo e pressione della memoria;
• operazioni e throughput dello storage;
• latenza delle applicazioni;
• traffico di rete;
• numero di richieste o transazioni;
• tempi di risposta;
• error rate;
• durata e frequenza dei picchi;
• vincoli di disponibilità e disaster recovery.

Utilizzare una finestra temporale rappresentativa

La finestra di osservazione deve includere cicli operativi significativi. Analizzare soltanto una settimana potrebbe non rilevare chiusure mensili, campagne commerciali, picchi stagionali o attività di elaborazione periodica.

Prima di approvare una modifica è utile verificare:

1. se il periodo analizzato rappresenta il normale comportamento;
2. se sono presenti eventi eccezionali;
3. se il workload crescerà nel breve periodo;
4. se esistono vincoli contrattuali o di compliance;
5. se l’intervento può essere annullato rapidamente.

Un processo prudente di rightsizing

Rightsizing e servizi critici

Nei sistemi critici è opportuno mantenere margini coerenti con gli obiettivi di servizio. Un utilizzo medio ridotto non dimostra automaticamente che la risorsa sia sovradimensionata: la capacità disponibile potrebbe essere necessaria per assorbire un picco o garantire
continuità durante un guasto.

Rightsizing e container

Negli ambienti Kubernetes è necessario confrontare richieste e limiti configurati con l’utilizzo reale. Request troppo elevate possono bloccare capacità inutilizzata, mentre limiti troppo bassi possono produrre throttling o terminazioni per memoria insufficiente.

Rightsizing per AI e GPU

Nei workload di intelligenza artificiale il costo può essere influenzato da GPU, memoria, durata dell’elaborazione, batch size, precisione numerica e livello di utilizzo dell’acceleratore.

L’ottimizzazione può includere:

• selezione di acceleratori adeguati al modello;
• batching delle richieste;
• riduzione dei periodi di inattività;
• quantizzazione del modello;
• caching dei risultati;
• scelta tra inferenza dedicata e serverless;
• routing delle richieste verso modelli differenti;
• monitoraggio del costo per inferenza o per token.

Scheduling: spegnere le risorse cloud quando non servono

Lo scheduling consiste nell’attivare e disattivare automaticamente le risorse in base agli orari nei quali sono realmente necessarie. È uno degli interventi FinOps più semplici da comprendere e può produrre benefici rapidi negli ambienti che non devono rimanere disponibili in modo continuativo.

Un ambiente di sviluppo utilizzato dal lunedì al venerdì durante l’orario lavorativo non richiede necessariamente la stessa disponibilità di un sistema di produzione. Lasciarlo attivo durante notti, fine settimana e periodi di inattività significa pagare capacità che non produce valore.

Lo scheduling rientra nelle attività di ottimizzazione dell’utilizzo descritte dalla FinOps Foundation perché adegua il consumo tecnologico ai reali schemi di domanda.

Quali risorse possono essere programmate

Le opportunità più frequenti riguardano:

• macchine virtuali di sviluppo e test;
• cluster Kubernetes non produttivi;
• database utilizzati soltanto durante l’orario lavorativo;
• ambienti temporanei per formazione e dimostrazioni;
• istanze dedicate alle attività di integrazione;
• laboratori tecnici e sandbox;
• pipeline di elaborazione periodica;
• notebook e ambienti di data science;
• GPU utilizzate per addestramento o sperimentazione;
• applicazioni interne con finestre operative prevedibili.

Calcolare il potenziale teorico

Una risorsa attiva 24 ore al giorno per sette giorni alla settimana viene eseguita per 168 ore. Se è necessaria soltanto per 10 ore al giorno dal lunedì al venerdì, il suo periodo operativo scende a 50 ore settimanali.

La riduzione teorica del tempo di esecuzione è quindi:

(168 − 50) ÷ 168 × 100 = 70,2%

Il risparmio effettivo può essere inferiore, perché alcuni costi continuano a essere applicati anche quando la capacità di calcolo è arrestata. Volumi, snapshot, indirizzi IP, licenze o altri componenti collegati possono infatti rimanere fatturabili.

Definire una policy di scheduling

Una policy efficace dovrebbe indicare:

• quali ambienti possono essere arrestati automaticamente;
• gli orari e il fuso orario di riferimento;
• i giorni festivi e le eccezioni;
• chi può richiedere un’estensione temporanea;
• come vengono gestiti processi ancora in esecuzione;
• quali controlli devono precedere lo spegnimento;
• come riattivare una risorsa fuori programma;
• chi riceve gli avvisi prima e dopo l’azione;
• come viene misurato il beneficio economico.

Etichette e metadati utili

Lo scheduling può essere governato attraverso tag o metadati standardizzati.
Per esempio:

Scheduling statico e dinamico

Lo scheduling statico segue un calendario predefinito. È semplice e adatto agli ambienti con orari regolari.

Lo scheduling dinamico utilizza invece segnali come attività degli utenti, carico applicativo, code di elaborazione o presenza di processi aperti. Offre maggiore flessibilità, ma richiede controlli e automazioni più sofisticati.

Procedere per livelli di rischio

Un programma di scheduling dovrebbe iniziare dalle risorse meno critiche: laboratori, sandbox e ambienti di test. Dopo aver verificato il funzionamento delle automazioni, può essere esteso a servizi con requisiti più articolati.

1. 1. identificare le risorse candidate;
   2. verificare proprietari, dipendenze e periodi di utilizzo;
   3. applicare la policy a un gruppo pilota;
   4. avvisare gli utenti prima dello spegnimento;
   5. monitorare errori e richieste di eccezione;
   6. confrontare la spesa con la baseline;
   7. estendere progressivamente il perimetro.

Autoscaling: adattare la capacità alla domanda

L’autoscaling modifica automaticamente il numero o la dimensione delle risorse in base al carico. Rispetto allo scheduling, non segue soltanto un calendario: reagisce a metriche tecniche o segnali applicativi.

L’obiettivo è evitare due condizioni opposte:

• • capacità eccessiva durante i periodi di bassa domanda;

• • capacità insufficiente durante i picchi.

Un’automazione ben configurata migliora contemporaneamente efficienza e qualità del servizio. Una configurazione errata, invece, può aumentare la spesa, generare instabilità o reagire troppo lentamente.

Autoscaling orizzontale e verticale

Scegliere metriche coerenti con il workload

La CPU è una metrica comune, ma non sempre rappresenta correttamente la domanda. Un’applicazione può essere limitata dalla memoria, dal numero di connessioni, dalla latenza dello storage o dalla lunghezza di una coda.

Le metriche possono includere:

• CPU e memoria;
• numero di richieste per istanza;
• latenza;
• numero di connessioni;
• profondità di una coda;
• throughput;
• numero di sessioni attive;
• durata delle elaborazioni;
• utilizzo di GPU e acceleratori;
• metriche applicative personalizzate.

Impostare limiti minimi e massimi

Ogni policy deve definire un livello minimo capace di preservare disponibilità e tempi di risposta. Deve inoltre stabilire un limite massimo per impedire che un errore applicativo o un attacco provochi una crescita incontrollata.

Il limite massimo non dovrebbe basarsi soltanto sul budget. Deve considerare anche quote tecniche, disponibilità regionale, dipendenze e capacità dei sistemi downstream.

Evitare oscillazioni continue

Soglie troppo sensibili possono generare continui aumenti e riduzioni di capacità. Questo comportamento, spesso definito thrashing, può peggiorare prestazioni e stabilità.

Per limitarlo è possibile utilizzare:

• periodi di stabilizzazione;
• soglie differenti per scale-out e scale-in;
• medie mobili;
• incrementi e decrementi progressivi;
• tempi minimi di permanenza della capacità;
• metriche multiple;
• approvazione manuale per le modifiche più rischiose.

Autoscaling e commitment

Autoscaling e commitment devono essere progettati insieme. Se un’organizzazione acquista un impegno sulla capacità massima e il sistema scala spesso verso il basso, una parte dello sconto può rimanere inutilizzata.

Una strategia più prudente consiste nel coprire con commitment il carico di base stabile e mantenere on demand, spot o altre forme flessibili per i picchi.

Serverless non significa automaticamente economico

I servizi serverless eliminano la necessità di gestire direttamente la capacità, ma devono comunque essere monitorati. Elevata frequenza delle chiamate, durata delle esecuzioni, memoria assegnata e traffico dati possono produrre costi rilevanti.

Per i workload serverless è utile misurare:

• costo per richiesta;
• costo per transazione;
• durata media e percentile delle esecuzioni;
• memoria assegnata rispetto a quella utilizzata;
• numero di invocazioni fallite o ripetute;
• costi di logging e osservabilità;
• traffico tra regioni o servizi;
• capacità riservata non utilizzata.

Reserved Instances, Savings Plans e commitment cloud

Dopo aver ottimizzato l’utilizzo, l’organizzazione può valutare come ridurre la tariffa pagata per la domanda che rimane stabile. I provider offrono sconti in cambio di impegni temporali, economici o di utilizzo.

La capability Rate Optimization della FinOps Foundation sottolinea la relazione tra ottimizzazione delle tariffe e ottimizzazione dell’utilizzo. Acquistare commitment prima del rightsizing può infatti vincolare l’impresa a una domanda destinata a ridursi.

Che cos’è un commitment

Un commitment è un impegno assunto nei confronti del provider in cambio di una tariffa inferiore rispetto al prezzo on demand. L’impegno può riguardare:

• una determinata quantità di spesa per ora;
• una famiglia di istanze;
• una regione;
• un servizio specifico;
• una quantità di CPU, memoria o altre risorse;
• un periodo generalmente pari a uno o tre anni.

AWS Savings Plans e Reserved Instances

AWS distingue tra Reserved Instances e diverse tipologie di Savings Plans.
I Savings Plans AWS applicano prezzi scontati in cambio di un impegno di utilizzo espresso in spesa oraria per uno o tre anni.

La flessibilità varia in base al piano. I Compute Savings Plans possono applicarsi a differenti opzioni di calcolo compatibili, mentre gli EC2 Instance Savings Plans sono collegati a una famiglia di istanze e a una regione.

Le Reserved Instances sono generalmente più specifiche rispetto alla configurazione coperta. Non corrispondono necessariamente a una macchina virtuale fisicamente riservata: in molti casi rappresentano soprattutto un beneficio tariffario applicato all’utilizzo compatibile.

Azure Reservations e Azure Savings Plan for Compute

Azure offre Azure Reservations per servizi e configurazioni compatibili, insieme ad Azure Savings Plan for Compute.

Secondo la documentazione Microsoft, un savings plan si basa su un impegno di spesa oraria applicabile ai servizi di calcolo idonei. Una reservation è invece più specifica rispetto alla combinazione di servizio e ambito coperto.

In termini generali:

• • un savings plan offre maggiore flessibilità per workload che cambiano;
  • una reservation può essere adatta a utilizzi stabili e configurazioni
    sufficientemente prevedibili;
  • la scelta deve considerare durata, portabilità, copertura, utilizzo e
    condizioni contrattuali.

Google Cloud Committed Use Discounts

Google Cloud propone Committed Use Discounts basati, a seconda del servizio, su risorse o spesa.

I CUD possono prevedere un impegno di uno o tre anni. Condizioni, applicabilità e attribuzione variano in base al servizio, al tipo di commitment e all’account di fatturazione.

Confronto concettuale

Il confronto è indicativo. Prodotti, condizioni e modalità di applicazione possono cambiare: prima dell’acquisto è necessario verificare la documentazione aggiornata del provider e le condizioni contrattuali dell’organizzazione.

Coverage e utilization

Due indicatori sono particolarmente importanti:

• • coverage:
    quota dell’utilizzo idoneo coperta da commitment;

• • utilization:
    quota del commitment acquistato effettivamente utilizzata.

Una coverage bassa può indicare un potenziale di ottimizzazione tariffaria.
Una utilization bassa segnala invece che una parte dell’impegno acquistato
non trova consumo compatibile.

Come dimensionare un commitment

Una procedura prudente dovrebbe comprendere:

1. 1. analizzare un periodo storico rappresentativo;
   2. escludere consumi temporanei o destinati a terminare;
   3. considerare rightsizing e scheduling già pianificati;
   4. identificare la domanda minima stabile;
   5. valutare crescita, migrazioni e cambi di architettura;
   6. simulare coverage e utilization;
   7. confrontare durata e flessibilità delle opzioni;
   8. definire il processo di approvazione;
   9. monitorare l’impegno dopo l’acquisto;
   10. programmare con anticipo la revisione prima della scadenza.

Acquisti progressivi invece di un unico grande impegno

In condizioni di incertezza può essere preferibile acquistare commitment in tranche successive. Questa strategia riduce il rischio di coprire eccessivamente una domanda destinata a cambiare e crea scadenze distribuite nel tempo.

Stabilire una governance degli acquisti

L’acquisto dovrebbe coinvolgere almeno FinOps, engineering, finance e procurement. Per gli impegni più rilevanti può essere necessaria l’approvazione del management.

La richiesta dovrebbe documentare:

• baseline utilizzata;
• periodo analizzato;
• assunzioni sulla crescita;
• workload coperti;
• opzioni di pagamento;
• beneficio stimato;
• rischi di sottoutilizzo;
• responsabile del monitoraggio;
• modalità di attribuzione dei costi e dei benefici.

Forecasting e budgeting cloud

Il forecasting stima la spesa futura sulla base di dati storici, trend, iniziative pianificate e variazioni attese. Il budgeting stabilisce invece un riferimento economico rispetto al quale monitorare la spesa.

Nei modelli tradizionali il budget viene spesso definito annualmente e modificato con frequenza limitata. Nel cloud, la domanda può cambiare rapidamente a causa di nuovi prodotti, crescita degli utenti, migrazioni, progetti di intelligenza artificiale e modifiche architetturali.

Un processo FinOps efficace combina quindi:

• budget con responsabilità chiare;
• forecast aggiornati periodicamente;
• analisi degli scostamenti;
• spiegazione dei principali driver;
• scenari alternativi;
• collegamento con roadmap tecniche e di prodotto.

Budget e forecast non sono la stessa cosa

Costruire una baseline affidabile

Una previsione puramente statistica può essere insufficiente quando il business sta cambiando. La baseline dovrebbe distinguere:

• spesa ricorrente stabile;
• crescita organica;
• stagionalità;
• progetti temporanei;
• migrazioni pianificate;
• servizi destinati alla dismissione;
• nuovi prodotti;
• cambiamenti tariffari;
• acquisti e scadenze dei commitment;
• ottimizzazioni già approvate.

Forecast statistico e forecast driver-based

Il forecast statistico proietta dati storici attraverso trend e stagionalità. È utile quando il comportamento passato rappresenta ragionevolmente il futuro.

Il forecast driver-based utilizza invece variabili aziendali o tecniche, per esempio:

• numero di clienti;
• transazioni previste;
• volume di dati;
• utenti attivi;
• numero di inferenze AI;
• token elaborati;
• nuove regioni o mercati;
• rilasci di prodotto;
• workload da migrare;
• capacità pianificata.

Nelle organizzazioni mature i due metodi vengono combinati: lo storico fornisce la base, mentre i driver incorporano gli eventi che il passato non può rappresentare.

Forecast bottom-up e top-down

Creare scenari alternativi

Una singola cifra può trasmettere una precisione che non esiste. È spesso più utile costruire almeno tre scenari:

• • scenario base:
    evoluzione considerata più probabile;
  • scenario di crescita:
    domanda superiore alle previsioni;
  • scenario prudente:
    rallentamenti, rinvii o maggiore ottimizzazione.

Gli scenari aiutano a valutare commitment, budget e capacità senza trasformare il forecast in una promessa rigida.

Misurare l’accuratezza del forecast

L’accuratezza può essere misurata attraverso lo scostamento tra valore previsto e consuntivo:

Scostamento percentuale = (Consuntivo − Forecast) ÷ Forecast × 100

È importante osservare anche la direzione dell’errore. Previsioni sistematicamente inferiori al consuntivo indicano un bias differente rispetto a previsioni costantemente superiori.

Analizzare gli scostamenti per causa

Ogni variazione significativa dovrebbe essere classificata. Alcune categorie utili sono:

• crescita della domanda;
• nuovo servizio o progetto;
• ritardo in una dismissione;
• errore di configurazione;
• variazione dei prezzi;
• modifica dei commitment;
• anomalia o incidente;
• variazione valutaria;
• allocazione errata;
• beneficio di ottimizzazione non realizzato.

Stabilire un calendario operativo

Un possibile ciclo mensile comprende:

1. 1. chiusura e validazione del consuntivo;
   2. analisi degli scostamenti;
   3. aggiornamento dei driver tecnici e di business;
   4. revisione delle iniziative pianificate;
   5. aggiornamento del forecast;
   6. confronto con il budget;
   7. condivisione delle azioni correttive;
   8. approvazione delle modifiche rilevanti.

Budget alert: evitare soglie isolate

Un alert basato soltanto sul superamento di una percentuale del budget può arrivare troppo tardi o produrre falsi allarmi. È preferibile combinare:

• spesa consuntiva;
• spesa prevista a fine periodo;
• velocità di crescita;
• variazioni giornaliere;
• anomalie rispetto allo storico;
• driver di business;
• soglie specifiche per ambiente e prodotto.

Forecasting dei costi AI

I workload di intelligenza artificiale richiedono particolare attenzione, perché la spesa può dipendere da variabili molto dinamiche:

• numero di richieste;
• token in input e output;
• modello utilizzato;
• dimensione del contesto;
• GPU e acceleratori;
• tempo di addestramento;
• volume dei dati;
• frequenza del retraining;
• caching;
• livelli di servizio richiesti.

Per questi progetti è utile affiancare alla previsione economica metriche unitarie come costo per inferenza, costo per mille richieste, costo per token, costo per esperimento e costo per modello addestrato.

Cost allocation, showback e chargeback

L’allocazione dei costi permette di collegare la spesa cloud a prodotti, servizi, business unit, clienti, progetti o team responsabili.

Senza un sistema di allocazione affidabile, l’organizzazione può conoscere il costo complessivo del cloud, ma non riesce a spiegare chi lo genera, per quale finalità e con quale risultato.

La cost allocation rappresenta quindi una delle condizioni fondamentali per trasformare la fattura cloud in un’informazione utile alle decisioni.

Perché allocare i costi

L’obiettivo non è soltanto attribuire una voce contabile. Una buona allocazione permette di:

• • identificare i prodotti e i servizi che generano la spesa;
  • assegnare responsabilità economiche più chiare;
  • confrontare costi, ricavi e valore prodotto;
  • costruire budget e forecast più accurati;
  • individuare anomalie e inefficienze;
  • distribuire correttamente sconti e costi condivisi;
  • calcolare metriche unitarie;
  • supportare showback e chargeback.

Le principali dimensioni di allocazione

Ogni organizzazione deve definire una tassonomia coerente con la propria struttura. Le dimensioni più comuni comprendono:

• business unit;
• centro di costo;
• prodotto;
• applicazione;
• ambiente;
• progetto;
• cliente;
• proprietario tecnico;
• proprietario economico;
• regione o area geografica;
• requisito normativo;
• fase del ciclo di vita.

Una tassonomia troppo semplice può non fornire informazioni sufficienti.
Una tassonomia eccessivamente articolata può invece diventare difficile da mantenere.

È quindi preferibile partire da poche dimensioni obbligatorie, chiaramente definite, ed estendere il modello soltanto quando esiste un reale bisogno informativo.

Tag, account e gerarchie organizzative

I tag sono uno degli strumenti più utilizzati per classificare le risorse, ma non devono essere considerati l’unica soluzione.

Una strategia completa può combinare:

• tag e label;
• account, subscription e progetti;
• folder e management group;
• namespace e cluster;
• mapping tra risorse e applicazioni;
• regole di allocazione;
• cataloghi dei servizi;
• dati provenienti da CMDB o piattaforme ITSM.

La combinazione di più fonti consente di classificare anche costi che non supportano direttamente i tag o che vengono fatturati a livello aggregato.

Allocazione diretta e indiretta

L’allocazione diretta è generalmente più semplice e trasparente.

L’allocazione indiretta richiede invece un criterio di distribuzione condiviso e comprensibile.

Come distribuire i costi condivisi

Servizi di rete, sicurezza, logging, osservabilità, piattaforme dati e infrastrutture comuni possono servire numerosi prodotti.

Questi costi possono essere:

• • mantenuti in un centro di costo centrale;
  • distribuiti in parti uguali;
  • ripartiti in base al consumo;
  • attribuiti secondo il numero di utenti;
  • ripartiti in base alle transazioni;
  • collegati ai ricavi;
  • distribuiti attraverso un driver tecnico o commerciale.

Non esiste un criterio universalmente corretto. La regola deve essere coerente con il modo in cui il servizio viene utilizzato e deve poter essere spiegata agli stakeholder.

Showback

Lo showback mostra a ogni team la spesa attribuita, senza trasferirla formalmente sul suo budget.

È spesso il primo passo più sicuro, perché consente di verificare la qualità dei dati e correggere eventuali errori prima di introdurre conseguenze
contabili.

Un report di showback dovrebbe indicare almeno:

• spesa del periodo;
• confronto con budget e forecast;
• principali servizi utilizzati;
• variazioni rispetto al periodo precedente;
• costi condivisi attribuiti;
• sconti e commitment applicati;
• opportunità di ottimizzazione;
• azioni assegnate al team.

Chargeback

Il chargeback trasferisce formalmente la spesa al centro di costo, al prodotto o alla funzione responsabile.

Questo modello crea una responsabilità economica più diretta, ma richiede dati affidabili, criteri condivisi e processi di contestazione.

Prima di introdurlo è opportuno verificare:

• la copertura dei costi allocati;
• la stabilità della tassonomia;
• la correttezza dei costi condivisi;
• la modalità di attribuzione degli sconti;
• la gestione degli errori;
• le responsabilità di approvazione;
• il trattamento delle eccezioni;
• la riconciliazione con i sistemi finanziari.

Attribuire correttamente sconti e commitment

L’allocazione non riguarda soltanto i costi lordi.

L’organizzazione deve decidere come distribuire:

• sconti contrattuali;
• Reserved Instances;
• Savings Plans;
• Committed Use Discounts;
• crediti promozionali;
• costi non coperti;
• commissioni centrali;
• variazioni valutarie.

Una modalità consiste nell’attribuire il beneficio ai team che generano l’utilizzo compatibile.

Un’altra modalità prevede che sconti e commitment rimangano gestiti a livello centrale. La scelta deve essere documentata per evitare letture incoerenti della marginalità dei prodotti.

Cost anomaly detection: individuare rapidamente le variazioni anomale

La cost anomaly detection identifica variazioni di spesa inattese rispetto al comportamento storico o al profilo previsto.

L’obiettivo non è segnalare ogni aumento, ma distinguere una crescita giustificata da un evento che richiede attenzione.

Un incremento può infatti dipendere da un nuovo cliente, da una campagna commerciale o da un rilascio pianificato. In questi casi la variazione può essere perfettamente coerente con il valore prodotto.

La stessa crescita, se non prevista, potrebbe invece essere causata da una configurazione errata, da una risorsa duplicata o da un volume di logging fuori controllo.

Perché i budget alert non bastano

Un budget alert segnala il superamento di una soglia economica.

Può però non rilevare un’anomalia di piccole dimensioni assolute ma molto significativa per un singolo prodotto, account o servizio.

La anomaly detection analizza invece deviazioni rispetto a un comportamento atteso, prendendo in considerazione:

• storico della spesa;
• stagionalità;
• trend;
• giorno della settimana;
• servizio;
• account o subscription;
• regione;
• prodotto;
• dimensione dell’aumento;
• durata della variazione.

Esempi di anomalie

• un cluster creato per errore e lasciato attivo;
• una crescita improvvisa del traffico dati;
• un aumento anomalo del logging;
• un job che continua a essere eseguito senza terminare;
• un database replicato in una regione non prevista;
• una modifica alla classe di storage;
• un aumento delle richieste verso un modello AI;
• una reservation non più applicata;
• una variazione dei prezzi o delle condizioni di fatturazione;
• un errore di tagging che sposta i costi tra prodotti.

Definire soglie significative

Una soglia esclusivamente percentuale può produrre molto rumore.

Un aumento del 200% su una spesa molto piccola può essere irrilevante.
Al contrario, una crescita del 10% su un servizio molto costoso può richiedere un intervento immediato.

È quindi utile combinare:

• soglia percentuale;
• soglia economica assoluta;
• criticità del servizio;
• durata dell’anomalia;
• ambiente interessato;
• proprietario del costo;
• impatto previsto a fine mese.

Il workflow di gestione

Il contesto è indispensabile

Un alert privo di informazioni sul proprietario o sul prodotto rischia di essere ignorato.

Ogni notifica dovrebbe includere:

• servizio interessato;
• account o subscription;
• periodo della variazione;
• incremento assoluto e percentuale;
• proiezione a fine mese;
• proprietario tecnico;
• prodotto o centro di costo;
• modifiche recenti;
• collegamento alla dashboard;
• azione richiesta.

Misurare l’efficacia della anomaly detection

Il numero di alert non è una misura di successo.

Un sistema efficace dovrebbe ridurre il tempo necessario per individuare e correggere le variazioni rilevanti.

I KPI possono comprendere:

• tempo medio di rilevazione;
• tempo medio di assegnazione;
• tempo medio di risoluzione;
• percentuale di falsi positivi;
• percentuale di alert senza proprietario;
• costo evitato grazie all’intervento;
• numero di anomalie ricorrenti;
• percentuale di cause automatizzate o prevenute.

KPI FinOps: quali indicatori misurare davvero

I KPI FinOps devono aiutare l’organizzazione a prendere decisioni.

Un indicatore è utile quando ha un proprietario, una frequenza di aggiornamento, una soglia e una possibile azione associata.

Misurare decine di metriche senza definire come utilizzarle produce dashboard complesse, ma non necessariamente una migliore governance.

KPI di visibilità e allocazione

• percentuale di spesa attribuita;
• percentuale di risorse con owner noto;
• copertura dei tag obbligatori;
• quota di costi condivisi regolamentati;
• percentuale di spesa non allocata;
• tempo necessario per produrre il reporting.

Questi indicatori misurano la capacità dell’organizzazione di comprendere la propria spesa.

KPI di forecasting

• scostamento tra forecast e consuntivo;
• bias medio delle previsioni;
• accuratezza per prodotto o business unit;
• percentuale di forecast aggiornati nei tempi previsti;
• numero di driver di business incorporati;
• variazione del forecast rispetto al mese precedente.

È importante non misurare soltanto l’errore complessivo.

Un risultato aggregato apparentemente corretto può nascondere errori opposti tra prodotti diversi.

KPI di ottimizzazione dell’utilizzo

• spesa associata a risorse inattive;
• percentuale di risorse sovradimensionate;
• tempo medio di implementazione delle raccomandazioni;
• risparmi effettivamente realizzati;
• costo evitato;
• percentuale di opportunità completate;
• riduzione delle ore di esecuzione;
• utilizzo medio delle risorse critiche.

KPI di ottimizzazione tariffaria

• coverage dei commitment;
• utilization dei commitment;
• tasso effettivo di sconto;
• spesa on demand potenzialmente copribile;
• impegni in scadenza;
• costo dei commitment non utilizzati;
• beneficio realizzato rispetto al prezzo on demand.

KPI di governance

• percentuale di team coinvolti;
• numero di azioni senza owner;
• tempo di chiusura delle anomalie;
• copertura delle policy;
• numero di eccezioni attive;
• percentuale di architecture review con valutazione economica;
• numero di team con obiettivi FinOps;
• livello di maturità per capability.

KPI di valore

I KPI più maturi collegano il costo a un’unità di business o di prodotto.

Alcuni esempi sono:

• costo cloud per cliente;
• costo per transazione;
• costo per ordine;
• costo per utente attivo;
• costo per gigabyte elaborato;
• costo per ambiente;
• costo per richiesta API;
• costo per inferenza AI;
• costo per mille token;
• costo tecnologico come percentuale dei ricavi.

Le metriche unitarie permettono di distinguere una crescita sana da una perdita di efficienza.

Se la spesa aumenta del 20% mentre le transazioni crescono del 40%, il costo unitario può essere migliorato anche se il costo totale è superiore.

Evitare KPI puramente cosmetici

Alcuni indicatori possono essere facili da comunicare ma poco utili.

Il numero totale di dashboard, di raccomandazioni o di alert non dimostra che l’organizzazione stia prendendo decisioni migliori.

È preferibile misurare quante opportunità vengono completate, quanto tempo richiedono e quale beneficio producono.

Dashboard FinOps per CIO, CFO e product owner

Una sola dashboard non può rispondere alle esigenze di tutti gli stakeholder.

Il CIO, il CFO, i team tecnici e i product owner osservano la stessa spesa da prospettive differenti.

Una buona piattaforma FinOps dovrebbe quindi offrire viste coerenti, ma adattate alle decisioni di ciascun ruolo.

Dashboard per il CIO

Il CIO ha bisogno di una vista complessiva su spesa, rischio, efficienza e capacità di supportare la strategia aziendale.

La dashboard può includere:

• spesa totale e trend;
• forecast a fine periodo;
• scostamento rispetto al budget;
• spesa per business unit;
• principali driver di crescita;
• opportunità di ottimizzazione;
• rischi legati a commitment e lock-in;
• maturità FinOps;
• costo unitario dei servizi strategici;
• efficienza di cloud, data platform e AI.

Dashboard per il CFO

Il CFO è interessato soprattutto a prevedibilità, attribuzione e impatto economico.

La dashboard può mostrare:

• budget, consuntivo e forecast;
• scostamenti per centro di costo;
• spesa allocata e non allocata;
• showback o chargeback;
• commitment acquistati e passività future;
• variazioni valutarie;
• costi capitalizzati e operativi;
• benefici realizzati;
• costi evitati;
• previsioni per trimestre e anno.

Dashboard per engineering

I team tecnici hanno bisogno di informazioni granulari e direttamente utilizzabili.

La dashboard può includere:

• spesa per servizio e risorsa;
• trend di utilizzo;
• raccomandazioni di rightsizing;
• risorse inattive;
• opportunità di scheduling;
• anomalie recenti;
• costo degli ambienti non produttivi;
• impatto delle modifiche architetturali;
• coverage dei workload;
• azioni assegnate e relative scadenze.

Dashboard per il product owner

Il product owner deve collegare la spesa al comportamento e al valore del prodotto.

Gli indicatori più utili possono essere:

• costo complessivo del prodotto;
• costo per cliente;
• costo per transazione;
• trend di utilizzo;
• marginalità;
• costo per funzionalità;
• impatto dei nuovi rilasci;
• costo degli ambienti di sviluppo e test;
• opportunità prioritarie;
• confronto tra crescita dei costi e crescita del prodotto.

Livello di dettaglio e frequenza

Principi di progettazione

Una dashboard efficace dovrebbe:

• rispondere a poche domande chiare;
• mostrare variazioni e non soltanto valori assoluti;
• evidenziare owner e azioni;
• distinguere dati consuntivi e previsioni;
• permettere di passare dal dato aggregato al dettaglio;
• segnalare la qualità delle informazioni;
• utilizzare definizioni condivise;
• ridurre indicatori ridondanti;
• mantenere una frequenza coerente con la decisione;
• indicare chiaramente il periodo analizzato.

Caso pratico: come applicare FinOps a una piattaforma digitale

Per comprendere come le diverse tecniche si combinano, consideriamo un’azienda che gestisce una piattaforma digitale basata su cloud pubblico.

L’infrastruttura comprende ambienti di produzione, sviluppo e test, database gestiti, cluster Kubernetes, servizi di storage e componenti dedicati all’intelligenza artificiale.

Negli ultimi sei mesi la spesa è aumentata del 35%, mentre il numero di clienti attivi è cresciuto del 18%.

Il management vuole capire se la crescita dei costi sia giustificata, quali inefficienze siano presenti e quali interventi possano essere realizzati senza compromettere prestazioni e roadmap del prodotto.

Fase 1: costruire la baseline

Il team FinOps raccoglie i dati di spesa e utilizzo degli ultimi dodici mesi.

La prima analisi evidenzia:

• • una parte significativa della spesa non attribuita a un prodotto;
  • ambienti di sviluppo attivi anche durante la notte;
  • macchine virtuali con utilizzo medio molto basso;
  • cluster Kubernetes con request superiori all’utilizzo reale;
  • commitment con utilization inferiore alle attese;
  • crescita non prevista dei costi di logging;
  • assenza di una metrica unitaria condivisa.

Fase 2: migliorare l’allocazione

Viene definita una tassonomia minima obbligatoria.

Ogni risorsa deve essere associata a:

• prodotto;
• ambiente;
• team responsabile;
• centro di costo;
• data di revisione.

I costi condivisi di rete, sicurezza e osservabilità vengono distribuiti in base al consumo attribuibile ai singoli prodotti.

Dopo il primo ciclo di correzione, la percentuale di spesa allocata passa dal 62% all’89%.

Fase 3: intervenire sull’utilizzo

Il team classifica le opportunità in base a rischio e beneficio.

Gli interventi a basso rischio comprendono:

• • spegnimento notturno degli ambienti non produttivi;
  • eliminazione di volumi non più collegati a risorse attive;
  • riduzione della conservazione dei log non necessari;
  • chiusura di progetti temporanei conclusi;
  • revisione delle request Kubernetes più sovradimensionate.

Gli interventi più delicati vengono invece testati progressivamente:

• rightsizing dei database;
• riduzione della capacità minima dei cluster;
• modifica delle policy di autoscaling;
• ottimizzazione delle GPU utilizzate per l’inferenza;
• revisione delle classi di storage.

Fase 4: rivedere i commitment

Prima di acquistare nuovi impegni, il team ricalcola la domanda stabile dopo rightsizing, scheduling e variazioni pianificate.

L’analisi mostra che una parte della crescita recente dipende da ambienti temporanei e non dovrebbe essere coperta con commitment pluriennali.

La strategia viene quindi modificata:

• • la baseline stabile viene coperta con impegni progressivi;
  • i picchi rimangono su modelli flessibili;
  • gli acquisti vengono suddivisi in tranche;
  • la utilization viene monitorata ogni settimana;
  • le scadenze vengono distribuite su periodi differenti.

Fase 5: introdurre una metrica unitaria

Il team sceglie come metrica principale il costo cloud per cliente attivo.

La formula è:

Costo cloud per cliente attivo = spesa cloud attribuita ÷ clienti attivi

Questa metrica permette di distinguere tra crescita del costo totale e perdita di efficienza.

Se il numero di clienti cresce più rapidamente della spesa, il costo unitario diminuisce anche quando il valore assoluto della fattura aumenta.

Fase 6: misurare i risultati

Il risultato non è soltanto una riduzione della spesa.

L’azienda ottiene maggiore visibilità, previsioni più accurate, responsabilità più chiare e una migliore capacità di collegare costi e crescita del prodotto.

Checklist operativa per l’ottimizzazione FinOps

La seguente checklist può essere utilizzata durante una revisione mensile o trimestrale della spesa cloud.

Visibilità e allocazione

• • La maggior parte della spesa è attribuita a un proprietario?
  • Prodotti e business unit utilizzano una tassonomia coerente?
  • I costi condivisi sono distribuiti con criteri documentati?
  • Gli sconti vengono attribuiti in modo comprensibile?
  • Le risorse senza owner vengono riesaminate periodicamente?

Ottimizzazione dell’utilizzo

• • Le risorse inattive vengono identificate ed eliminate?
  • Gli ambienti non produttivi utilizzano scheduling?
  • Le raccomandazioni di rightsizing vengono validate dai team tecnici?
  • Le request e i limit dei container riflettono l’utilizzo reale?
  • Storage, snapshot e backup rispettano policy di ciclo di vita?
  • Autoscaling e capacità minima vengono riesaminati?
  • Logging e osservabilità sono proporzionati al valore informativo?

Ottimizzazione tariffaria

• • Coverage e utilization vengono monitorate separatamente?
  • Gli impegni sono dimensionati sulla domanda stabile?
  • Rightsizing e scheduling vengono considerati prima degli acquisti?
  • Le scadenze dei commitment sono distribuite?
  • Il team valuta durata, flessibilità e rischio di sottoutilizzo?
  • Gli acquisti hanno un owner e un processo di approvazione?

Forecasting e budgeting

• • Il forecast viene aggiornato regolarmente?
  • I principali driver di business sono documentati?
  • Le iniziative future sono incluse nella previsione?
  • Gli scostamenti vengono classificati per causa?
  • Esistono scenari base, prudente e di crescita?
  • Budget e forecast vengono mantenuti distinti?

Anomalie e governance

• • Gli alert includono owner e contesto?
  • Esiste un workflow di triage e risoluzione?
  • I falsi positivi vengono monitorati?
  • Le anomalie ricorrenti generano azioni preventive?
  • Ogni opportunità ha una priorità e una scadenza?
  • I benefici realizzati vengono verificati sul consuntivo?

Valore e prodotto

• • L’organizzazione utilizza almeno una metrica unitaria?
  • La crescita dei costi viene confrontata con la crescita del prodotto?
  • Le decisioni considerano prestazioni e affidabilità?
  • Il costo entra nelle architecture review?
  • Product owner e business partecipano alle revisioni?

Gli errori più comuni nell’ottimizzazione dei costi cloud

Applicare automaticamente tutte le raccomandazioni

Una raccomandazione automatica non conosce sempre requisiti, dipendenze e priorità del workload.

Ogni intervento deve essere validato dal proprietario tecnico.

Comprare commitment troppo presto

Acquistare sconti prima di rightsizing, scheduling e dismissioni può vincolare l’impresa a una domanda destinata a diminuire.

Misurare soltanto il risparmio

Ridurre la spesa non è sempre un risultato positivo.

È necessario verificare l’impatto su prestazioni, resilienza, sicurezza, produttività e valore del prodotto.

Usare medie troppo semplici

Una media mensile può nascondere picchi brevi ma critici.

Rightsizing e autoscaling devono considerare percentile, stagionalità e requisiti di servizio.

Ignorare i costi indiretti

Spegnere una risorsa non elimina necessariamente storage, backup, rete, licenze e costi operativi.

Il beneficio deve essere verificato sul costo complessivo.

Non distinguere opportunità e benefici realizzati

Una raccomandazione identificata non equivale a un risparmio.

È necessario distinguere tra:

• opportunità teorica;
• azione approvata;
• azione implementata;
• beneficio verificato.

Creare dashboard senza owner

Un dato privo di destinatario e azione associata difficilmente produce un cambiamento.

Ottimizzare una sola volta

I workload cambiano continuamente.

Nuovi rilasci, migrazioni, crescita degli utenti e modifiche tariffarie rendono necessaria una revisione periodica.

Strumenti e KPI devono produrre decisioni, non soltanto report

Gli strumenti FinOps rendono visibili costi, utilizzo e opportunità.

Il loro valore dipende però dalla capacità dell’organizzazione di trasformare queste informazioni in decisioni operative.

Rightsizing, scheduling e autoscaling intervengono sull’utilizzo.

Reserved Instances, Savings Plans, Azure Reservations e Committed Use Discounts intervengono invece sulla tariffa pagata.

Forecasting, cost allocation e anomaly detection permettono di governare la spesa nel tempo.

KPI e dashboard collegano infine le attività tecniche agli obiettivi finanziari e di prodotto.

Nessuna di queste pratiche deve essere utilizzata in modo isolato.

Un commitment acquistato prima del rightsizing può diventare inefficiente.
Un alert senza owner può essere ignorato. Una dashboard senza metriche unitarie può mostrare la crescita della spesa senza spiegare il valore prodotto.

La maturità FinOps si riconosce quando l’organizzazione riesce a rispondere
rapidamente a tre domande:

1. 1. quanto stiamo spendendo;
   2. perché lo stiamo spendendo;
   3. quale valore stiamo ottenendo.

Nella quarta parte della guida verranno approfonditi FinOps per intelligenza
artificiale, GreenOps, sostenibilità, multicloud e nuove metriche orientate
al valore.