import pandas as pd

Managing data infrastructure costs

Il costo del cloud dati cresce quasi sempre senza un singolo colpevole. Si accumula tra query esplorative pesanti, refresh troppo frequenti, storage duplicato, cluster sempre accesi e ambienti di test che nessuno ha mai spento. Gestire questi costi significa leggere la spesa come prodotto di scelte tecniche e abitudini operative, non come un numero da tagliare alla cieca. In questa lezione il tema è una scelta di governo: quale workload sostiene una decisione e quale gira solo per inerzia.

Il problema da risolvere

Conoscere il FinOps per dati in astratto non aiuta. Aiuta sapere cosa fare quando la fattura sale, i workload sono opachi e nessuno sa quale dashboard costa davvero. Una lezione utile separa il segnale dal rumore: dice quale baseline usare, quale controllo eseguire e quale azione diventa difendibile dopo aver guardato la spesa.

Conviene leggere il problema come una conversazione tra valore e spreco. Per ogni workload chiediti quale sostiene una decisione, quale gira per abitudine, quale puoi comprimere, spegnere, schedulare o spostare. Il FinOps per dati funziona quando costo e ownership diventano visibili nello stesso posto: solo allora un team smette di trattare la spesa come un problema di qualcun altro.

Come ragionare sulla decisione

Conviene leggere ogni intervento come una sequenza che collega scelta, evidenza e rischio. La tabella sotto funziona da mappa di lavoro e impedisce che il controllo dei costi diventi un rituale vuoto.

Step	Question to ask	Expected output
Decision	Che cosa cambia se capiamo dove va la spesa?	Scelta esplicita
Signal	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Credible comparison
Vincolo	Che cosa puo falsare la lettura?	Assunzione da dichiarare
Action	Quale passo operativo segue?	Raccomandazione controllabile

Ogni riga deve rendere piu chiaro il costo di una decisione sbagliata. Se un passaggio non incide su una scelta concreta, diventa documentazione o teatro analitico.

Formalizzare unita, segnale e decisione

Per analizzare i costi conviene fissare prima l’unita di lavoro, poi il segnale, poi la decisione attesa. L’unita di analisi qui è il job, la pipeline, il servizio, l’alert, il deploy o la risorsa cloud. Il segnale principale è SLA, MTTR, costo, failure rate, freshness o qualità dei dati. La decisione attesa è un runbook, un alert, una policy di costo, una configurazione CI/CD o un piano di recovery.

Element	Operational Definition	Controllo minimo
Unit of analysis	Oggetto su cui misuri il fenomeno	job, pipeline, service, alert, deploy, or cloud resource
Variabile osservata	Segnale che rappresenta il comportamento	SLA, MTTR, costo, failure rate, freshness, qualità dati
Baseline	Stato contro cui confronti il segnale	Periodo, segmento, controllo o benchmark
Soglia decisionale	Punto in cui cambia l’azione	Criterio scritto prima della lettura
Rischio residuo	Errore che puo restare anche dopo l’analisi	Mistaking an available number for sufficient proof

La formalizzazione non complica la lezione. Rende visibili le assunzioni, così un altro analista può riprodurre la logica, criticare le ipotesi e arrivare alla stessa decisione partendo dagli stessi dati.

Cost audit: where to start

Si parte identificando i cinque modelli o query più costosi. In Snowflake li trovi con QUERY_HISTORY, in BigQuery con INFORMATION_SCHEMA.JOBS. Per ognuno chiediti se è davvero necessario che costi così tanto e se può essere ottimizzato. Poi categorizza: il costo è fisso, come storage e infrastruttura, oppure variabile, come query ad-hoc e job schedulati? Nell’ottanta per cento dei casi cinque modelli consumano oltre la metà del costo totale, quindi ottimizzare quelli dà il massimo ritorno sull’investimento.

Quick high-impact optimizations

Convertire una table in modello incremental riduce il costo dell’80-95% sui modelli grandi con dati append-only. Aggiungere filtri sulle date evita lo spreco quando leggi cinque anni di dati ma ti servono solo gli ultimi 90 giorni, situazione in cui butti via il 95% del compute. In sviluppo bastano 30 giorni di dati, quindi conviene limitare la finestra. Dimensionare il warehouse in modo corretto pesa molto, perché un XL consuma sedici volte un XS: lo aumenti solo quando serve e lo riduci subito dopo. Infine i timeout automatici, per esempio dieci minuti sulle query di produzione, terminano le query runaway invece di fatturarle all’infinito.

Cost culture

Il modo migliore per controllare i costi è renderli visibili. Una dashboard con costo per modello, costo per team e trend mensile cambia il comportamento più di qualsiasi policy. Quando un team vede che la propria dashboard costa 400 dollari al mese, trova quasi subito il modo di farla costare 40.

Esempio: la fattura raddoppiata

Un team riceve una fattura del warehouse raddoppiata dopo il lancio di nuove dashboard. Invece di tagliare alla cieca, separa query ricorrenti, esplorazioni una tantum, refresh inutili e storage duplicato, poi assegna un owner e un budget guardrail a ciascuna categoria. La tabella sotto mostra come leggere alcune evidenze tipiche.

Observed evidence	Cautious interpretation	Recommended action
The number improves	Could be a real effect or normal variation	Look for comparison and segment
One segment changes more than others	The aggregated average hides a difference	Separate cohorts or use cases
Cost grows along with the result	Impact must be read on the margin	Estimate trade-offs and sustainability

La domanda non è “qual è la definizione corretta di FinOps?” ma “quale scelta diventa meno rischiosa se l’analisi dei costi è fatta bene?”.

SQL example: building a control view

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. Crea una base analitica con metrica, segmento e finestra temporale, così da confrontare periodi e gruppi senza riscrivere la logica ogni volta.

WITH base_events AS (
  SELECT
    user_id,
    account_id,
    event_type,
    event_time,
    DATE_TRUNC('week', event_time) AS week,
    source,
    device_type
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '180 days'
    AND user_id IS NOT NULL
),
weekly_user_metrics AS (
  SELECT
    week,
    user_id,
    COALESCE(source, 'unknown') AS source,
    COALESCE(device_type, 'unknown') AS device_type,
    COUNT(*) AS total_events,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(DISTINCT event_type) AS event_diversity,
    MAX(CASE WHEN event_type IN ('purchase', 'subscribe', 'activation') THEN 1 ELSE 0 END) AS reached_key_outcome
  FROM base_events
  GROUP BY week, user_id, source, device_type
)
SELECT
  week,
  source,
  device_type,
  COUNT(DISTINCT user_id) AS users,
  ROUND(AVG(active_days), 2) AS avg_active_days,
  ROUND(AVG(event_diversity), 2) AS avg_event_diversity,
  ROUND(AVG(reached_key_outcome) * 100, 2) AS key_outcome_rate
FROM weekly_user_metrics
GROUP BY week, source, device_type
ORDER BY week, source, device_type;

La query non pretende di dare la risposta finale. Serve a creare una superficie di osservazione: trend, segmenti, differenze tra canali, variazioni nel tempo. Da qui l’analista formula ipotesi più precise.

Python example: checking stability and anomalies

Una metrica utile deve essere abbastanza stabile da orientare decisioni e abbastanza sensibile da segnalare cambiamenti reali. In Python possiamo controllare le variazioni anomale settimana su settimana.

# df contiene: week, segment, users, key_outcome_rate
# key_outcome_rate espresso in percentuale, es. 12.4

df = df.sort_values(['segment', 'week']).copy()
df['previous_rate'] = df.groupby('segment')['key_outcome_rate'].shift(1)
df['wow_change_pp'] = df['key_outcome_rate'] - df['previous_rate']
df['rolling_mean'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).mean()
)
df['rolling_std'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).std()
)
df['z_score'] = (df['key_outcome_rate'] - df['rolling_mean']) / df['rolling_std']

anomalies = df[df['z_score'].abs() >= 2].sort_values('z_score')
print(anomalies[['week', 'segment', 'key_outcome_rate', 'wow_change_pp', 'z_score']])

Il controllo evita di reagire a ogni oscillazione casuale ma segnala quando una variazione merita un’indagine. Applicato ai costi, lo stesso schema individua il picco di spesa che esce dalla normale variabilità settimanale.

Real case: Netflix and the discipline of metrics

Netflix è un esempio utile perché ha costruito molte decisioni di prodotto intorno a segnali comportamentali osservabili: completamento degli episodi, tempo di ricerca prima della riproduzione, abbandono dopo pochi minuti, ritorno nella settimana successiva, efficacia delle raccomandazioni. Il punto non è copiare Netflix, ma il metodo: il dato non è un ornamento, è infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, per esempio una nuova riga di raccomandazioni, una diversa immagine di copertina o un nuovo algoritmo di ranking, non misura solo il click immediato. Guarda anche i segnali di qualità: l’utente guarda davvero il contenuto? torna nei giorni successivi? riduce il tempo speso a cercare? Questa disciplina evita di ottimizzare vanity metric che sembrano positive nel breve periodo ma erodono valore nel lungo. Lo stesso vale per i costi: se la riduzione di spesa non è collegata a un outcome, rischi di tagliare ciò che serve.

Esercizio

Al livello base, scrivi in cinque righe quale decisione concreta dovrebbe migliorare la gestione dei costi, indicando metrica, unita di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, il tema è ancora troppo astratto.

Al livello intermedio, costruisci una tabella con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario, azione consigliata. Includi almeno un caso in cui il segnale non basta per decidere.

Al livello research-grade, trasforma l’esercizio in un decision memo con assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Come materiale usa log pipeline, metriche dell’orchestratore, cost explorer, incident report e dashboard ops; se non hai dati reali, genera un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Common mistakes to avoid

L’errore più frequente è usare il controllo dei costi come etichetta invece che come processo: il team mostra un grafico senza decisione, una metrica senza baseline, una conclusione senza dire quale assunzione potrebbe invalidarla. La domanda di controllo è semplice: se questo risultato fosse instabile, quale scelta sbaglierei?

Tre errori ricorrenti restano in agguato. Il primo è lavorare su dati aggregati troppo presto, perché una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Il terzo è confondere correlazione e causalità, perché gli utenti che usano una feature potrebbero convertire di più solo perché erano già più motivati. Per ridurre questi rischi, ogni analisi dovrebbe includere definizione esplicita della metrica, confronto per segmento e verifica contro un periodo precedente o un gruppo di controllo.

Checkpoint

Prima di chiudere, prova a rispondere. Quale decisione concreta dovrebbe migliorare questa lezione? Quale unita di analisi rende il problema misurabile? Quale baseline useresti per evitare una lettura isolata? Quale assunzione, se falsa, cambierebbe la conclusione? Quale output consegneresti a uno stakeholder non tecnico?

Summary

La gestione dei costi dell’infrastruttura dati è uno strumento decisionale, non un argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione. Una buona analisi non finisce con “il numero è salito” o “il numero è sceso”, ma con una frase operativa: quale decisione prendiamo, con quale confidenza, e quale metrica useremo per sapere se avevamo ragione. La forma utile resta sempre la stessa: decisione, segnale, baseline, rischio e azione. Tutto il resto serve solo se rende più affidabile uno di questi passaggi.