Cheat sheet Infrastructure & Ops

Questa sintesi operativa, sul binario ml-tabellare, ti dà il ripasso dei pattern di gestione dell’infrastruttura dati: cosa controllare, in che ordine e con quale prova.

Il punto di partenza

Questa checklist lega ownership, deploy, monitoring, costi e recovery a controlli eseguibili. La rileggi ogni volta che nasce un workload nuovo o cambia una parte critica.

La sequenza operativa

1. Assegna owner, soglia e test a ogni voce prima del rilascio.
2. Verifica deploy, monitoring e accessi in staging isolato.
3. Controlla costi, backup e rollback con prova di ripristino.
4. Riesegui la checklist a ogni nuovo workload o modifica critica.

Lo stack di riferimento

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

Ogni stadio alimenta il successivo con owner e SLA dichiarati. Se uno stadio resta senza owner, il guasto emerge solo davanti agli utenti.

Verdetto: catena corta con owner per stadio e staging obbligatorio prima della produzione.

CI/CD per dbt in una riga

Il pattern incrementale esegue solo i modelli modificati in schema isolato così la pipeline resta veloce e non tocca la produzione.

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

Il monitoring a tre livelli

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

Un flusso può girare senza errori e produrre dati sbagliati o numeri implausibili. Servono tutti e tre i piani con alert distinti.

Verdetto: tre livelli con owner diversi; un solo livello lascia punti ciechi.

Le cinque regole del cost management

Cinque regole tengono i costi sotto controllo. I primi 5 modelli consumano oltre il 50 per cento dei costi quindi si ottimizzano per primi. Il passaggio da tabella completa a incrementale su flussi di eventi taglia fino all’80 per cento. I filtri sulle date evitano di leggere 5 anni quando servono 90 giorni. Un timeout di 10 minuti blocca le esecuzioni fuori controllo. La dashboard dei costi visibile a tutti rende la spesa responsabilità condivisa.

Esempio SQL: costruire una vista di controllo

Il pattern crea una base analitica con metrica, segmento e finestra temporale. Così confronti periodi e gruppi senza riscrivere la logica.

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;

Esempio Python: controllare stabilità e anomalie

Il controllo su finestra mobile evita reazioni al rumore e segnala variazioni da indagare.

# 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 costo di ignorare la checklist

Il 1 agosto 2012 Knight Capital distribuisce un aggiornamento del software di trading con un flag riutilizzato per errore. In 45 minuti il sistema esegue milioni di ordini involontari e accumula una perdita di 440 milioni di dollari. L’azienda non si riprende più e viene acquisita entro l’anno. Il post-mortem elenca tutto ciò che questa checklist prescrive: deploy senza canarino, flag senza owner e monitoraggio che non ferma niente da solo.

Domande finali della sintesi

1. Quale voce della checklist resta senza owner nella tua piattaforma?
2. Quale test di qualità blocca un deploy difettoso prima della produzione?
3. Quale livello di monitoring segnala per primo dati errati?
4. Quale prova conferma che rollback e backup funzionano davvero?