import pandas as pd

Cheat sheet Infrastructure & Ops

Prima di rilasciare o modificare un sistema dati, il team deve controllare ownership, deploy, monitoring, accessi, costi, backup e rollback. Questa cheat sheet raccoglie i punti che evitano di scoprire un problema solo quando la dashboard è già davanti agli utenti. Va usata come controllo operativo, non come promemoria teorico: ogni voce deve produrre un owner, una soglia, un test o una decisione di architettura. Se una risposta manca, il sistema può funzionare oggi e diventare fragile domani.

A cosa serve la checklist

Il punto non è memorizzare definizioni, ma decidere cosa fare quando il team ha dati incompleti, costi non attribuiti o vincoli tecnici che rendono fragile il sistema. La checklist separa ciò che va presidiato subito da ciò che può aspettare e dichiara rispetto a quale stato precedente stai misurando un miglioramento.

Nel contesto dell’infrastructure ops, la prima domanda non è quale metrica calcolare, ma quale decisione dovrà essere presa grazie a quel dato. Una dashboard o un alert hanno valore solo se riducono incertezza decisionale. Se non cambiano una scelta, sono documentazione o teatro analitico.

Principio managed-first

La regola di default è preferire il servizio gestito al self-hosted, quasi sempre. L’eccezione vale quando il costo del servizio supera il costo del team che lo gestirebbe in casa. Tenere a mente questa singola regola sotto pressione evita gran parte delle decisioni sbagliate sull’infrastruttura.

Stack di riferimento

Lo stack tipico di una piattaforma dati segue una catena lineare, dove ogni stadio alimenta il successivo.

Storage (S3/warehouse) → Compute → Orchestration (Airflow/Prefect) → Transformation (dbt) → Monitoring

CI/CD per dbt

Il pattern di build incrementale esegue solo i modelli modificati in uno schema CI isolato, così la pipeline resta veloce e non tocca i dati di produzione.

dbt build --select state:modified+ --target ci --defer --state ./target/
# Esegue solo modelli modificati in schema CI isolato

Monitoring a tre livelli

Il monitoring va pensato su tre piani distinti, perché un job può girare senza errori e produrre comunque dati sbagliati o numeri che non hanno senso per il business.

Livello	Cosa	Tool
Pipeline operativa	È girato?	Airflow UI, dbt Cloud
Data quality	I dati sono corretti?	dbt tests, Elementary
Metriche business	I numeri hanno senso?	Alert su metriche chiave

Cost management

Sul controllo dei costi pochi interventi spostano la maggior parte della spesa. Di solito i primi 5 modelli consumano oltre il 50% dei costi, quindi conviene ottimizzare quelli per primi. Passare da table a incremental su uno event stream può ridurre i costi dell’80%. I filtri sulla data nei modelli evitano di leggere 5 anni di dati quando ne servono 90 giorni. Un timeout di 10 minuti sulle query di produzione blocca le esecuzioni fuori controllo. E una dashboard dei costi visibile a tutti i team rende la spesa una responsabilità condivisa.

Una mappa per usare la checklist

Conviene leggere ogni voce attraverso una sequenza che lega il controllo a una decisione concreta, invece di spuntare caselle.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se questo controllo è presidiato?	Scelta esplicita
Segnale	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Confronto credibile
Vincolo	Che cosa può falsare la lettura?	Assunzione da dichiarare
Azione	Quale passo operativo segue?	Owner, soglia o test

Per rendere analizzabile ogni voce, definisci l’unità di lavoro (job, pipeline, servizio, alert, deploy o risorsa cloud), collegala a una metrica osservabile (SLA, MTTR, costo, failure rate, freshness) e dichiara la decisione attesa (runbook, alert, policy di costo, CI/CD o piano di recovery). La checklist è solida quando un altro ingegnere può riprodurre la stessa logica e arrivare alle stesse conclusioni partendo dagli stessi dati.

Netflix e la disciplina delle metriche

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 è che ogni azienda debba copiare Netflix, ma che il dato non viene trattato come ornamento, viene trattato come infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, per esempio una nuova riga di raccomandazioni, una diversa immagine di copertina o un algoritmo di ranking, non misura solo il click immediato. Guarda anche segnali di qualità, cioè se l’utente guarda davvero il contenuto, se torna nei giorni successivi e se riduce il tempo speso a cercare. Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve periodo ma erodono valore nel lungo. La cheat sheet serve allo stesso scopo: collegare ogni controllo a un esito reale.

Esempio SQL: costruire una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. L’obiettivo è creare 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 essere la risposta finale. Serve a creare una superficie di osservazione fatta di trend, segmenti, differenze tra canali e variazioni nel tempo.

Esempio Python: controllare stabilità e anomalie

Una metrica operativa utile deve essere stabile abbastanza da orientare le decisioni e sensibile abbastanza da segnalare i cambiamenti reali. In Python puoi 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 valore del controllo è pratico: eviti di reagire a ogni oscillazione casuale, ma vedi subito quando una variazione merita un’indagine. In azienda alimenta alert, review settimanali e retrospettive operative.

Errori tipici e come evitarli

Il primo errore è lavorare su dati aggregati troppo presto, perché una media globale nasconde due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato, dato che eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Il terzo è confondere correlazione e causalità.

C’è anche l’errore di usare la cheat sheet come etichetta invece che come processo, cioè spuntarne le voci senza assegnare un owner, una soglia o un test. La domanda di controllo è semplice: se questo risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca ancora il collegamento tra analisi e azione.

Esercizio applicato

Al livello base scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie a uno dei controlli della cheat sheet, indicando metrica, unità di analisi, baseline e rischio principale.

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

Al livello research-grade trasforma l’esercizio in un memo decisionale con assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e piano di monitoraggio. Come materiale usa log delle pipeline, metriche dell’orchestratore, cost explorer, dati CI/CD, incident report e dashboard ops. Se non hai dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione di segmento e una metrica di outcome.

Checkpoint

Prima di chiudere, verifica di saper rispondere a queste cinque domande.

1. Quale decisione concreta dovrebbe migliorare grazie a questa cheat sheet?
2. Quale unità di analisi rende il problema misurabile?
3. Quale baseline useresti per evitare una lettura isolata?
4. Quale assunzione, se falsa, cambierebbe la conclusione?
5. Quale output consegneresti a uno stakeholder non tecnico?

Riepilogo

La cheat sheet è uno strumento decisionale, non un elenco di buoni propositi. Il valore nasce quando ogni voce, dal principio managed-first al monitoring a tre livelli fino al controllo dei costi, produce un owner, una soglia o un test. Una buona checklist non si chiude con “abbiamo spuntato tutto”, ma con una frase operativa: quale decisione prendiamo, con quale livello di confidenza e quale metrica useremo per sapere se avevamo ragione.