FinOps è uno di quei termini che significano cose molto diverse a seconda della dimensione dell'azienda. Per una Fortune 500, è una practice di 30 persone con uno sponsor a livello di CFO, un budget per gli strumenti più grande del tuo monte salari e comitati direttivi trimestrali. Per il tuo SaaS da 30 persone, si riduce più o meno a: "perché la bolletta AWS è più alta del 27% rispetto al trimestre scorso, e di chi è il compito di scoprirlo?" Questo articolo è per il secondo gruppo.

Prima la buona notizia rassicurante: lo spreco cloud è noioso. La stragrande maggioranza deriva dagli stessi cinque pattern, in ogni azienda, a ogni scala. Compute inattivo che nessuno ha spento. Istanze sovradimensionate provisionate per un picco che non si è mai ripresentato. Risorse senza tag che nessuno può attribuire, quindi nessuno si sente responsabile. Ambienti di sviluppo e staging dimenticati, attivi 24 ore su 24 per un software che rilascia due volte al mese. E storage che resta su tier premium anni dopo l'ultima volta che qualcuno lo ha letto. Nessuno di questi richiede una certificazione FinOps Foundation per essere risolto. Tutti richiedono che qualcuno, effettivamente, guardi.

Il pattern che vediamo più spesso merita un paragrafo tutto suo. Uno sviluppatore avvia una c5.4xlarge per un load test di giovedì. Il test si conclude alle 16 di venerdì. L'istanza resta accesa per tutto il weekend, perché spegnerla è un passaggio manuale in una console che nessuno apre di sabato. Al daily standup di lunedì, il team ha bruciato 180 € su una macchina inattiva - non per incompetenza, ma perché il comportamento predefinito del sistema è "continua a fatturare". Moltiplica per ogni team, ogni weekend, ogni esperimento dimenticato, e ottieni una percentuale significativa del tuo budget infrastrutturale che non fa assolutamente nulla.

Perché le dashboard non risolvono il problema? Perché la visibilità non è mai stata il collo di bottiglia - il tuo cloud provider ha già un cost explorer, e tu semplicemente non lo apri. Una dashboard ti dice cosa è successo dopo che i soldi sono già spariti, in un posto che devi ricordarti di visitare, in un formato che richiede venti minuti di filtri prima di dirti qualcosa di concretamente utile. Tra "i dati esistono" e "qualcuno ha agito di conseguenza" si colloca l'intera disciplina reale del FinOps, ed è esattamente la parte per cui un piccolo team non ha capacità residua.

C'è anche un problema strutturale che le dashboard non possono risolvere: la frammentazione multi-cloud. Nel momento in cui usi AWS per il prodotto, Hetzner per i workload batch e un progetto DigitalOcean vagante che qualcuno ha avviato nel 2024, "quanto spendiamo" smette di avere una risposta unica. Ogni provider esporta i costi nel proprio formato, secondo il proprio calendario, con la propria idea di cosa sia un progetto. La maggior parte dei piccoli team reagisce monitorando con attenzione la bolletta grande e lasciando alla deriva quelle piccole - ed è così che una perdita di 400 €/mese sopravvive per due anni.

Quindi, com'è davvero il FinOps per un team senza un team FinOps? Nella nostra esperienza, quattro abitudini coprono la maggior parte del valore. Uno: un'unica fonte di verità per la spesa su tutti i provider, suddivisa per servizio, progetto e ambiente - non perché le dashboard risolvano le cose, ma perché le discussioni sull'attribuzione finiscono quando tutti vedono gli stessi numeri. Due: un rilevamento anomalie più intelligente di una semplice soglia - le bollette cloud sono naturalmente rumorose, e un "avvisami sopra i X €" statico o scatta in continuazione o non scatta mai; segnalare deviazioni genuine dal proprio baseline è lavoro per il machine learning, non per un cron job e la speranza. Tre: raccomandazioni di right-sizing con una cadenza regolare - una lista mensile del tipo "queste dodici istanze sono sovradimensionate, ecco la taglia più piccola sicura, ecco il risparmio" che qualcuno rivede in quindici minuti. Quattro: avvisi di budget che escalano - un avviso discreto all'ingegnere all'80%, uno più forte al team lead al 100%, perché un budget di cui nessuno è responsabile è solo un desiderio.

Nota cosa hanno in comune tutte e quattro: accorciano il ciclo dall'insight all'azione. È tutto qui il gioco. Non più dati - meno distanza tra "il sistema se n'è accorto" e "un umano ha deciso". Un piccolo team non ha bisogno di una practice FinOps; ha bisogno dei venti minuti a settimana in cui le decisioni sui costi sono ben preparate, pre-prioritizzate e riunite in un unico posto.

Questo è ciò che abbiamo costruito in Sencai: spesa per servizio, progetto e ambiente su ogni provider collegato; anomalie di costo segnalate da ML; raccomandazioni di right-sizing programmate; avvisi di budget che escalano. Il ciclo dall'insight all'azione, compresso fino a stare dentro un daily standup. E il prossimo passo in roadmap - Autopilot - riguarda la chiusura completa di quel ciclo per i casi noiosi: arresto automatico programmato delle risorse di sviluppo taggate, esecuzione del right-sizing approvato durante le finestre di manutenzione. Il giudizio resta a te; premere il pulsante non dovrebbe.

Se vuoi sapere a che punto sei oggi, ecco un esercizio di quindici minuti: recupera la bolletta del mese scorso da ogni provider che usi - inclusi quelli che avevi dimenticato. Ordina per servizio. Cerchia tutto ciò che non riesci ad attribuire a una funzionalità di prodotto attiva entro dieci secondi. Nella maggior parte delle aziende, quel cerchio rappresenta il 25-35% del totale. Non è un problema di budgeting. È solo entropia - e l'entropia è molto, molto risolvibile.