import pandas as pd

Alerting e anomaly detection su stream

Un alert scatta alle tre del mattino. Il traffico sembra anomalo, ma potrebbe essere una campagna marketing partita di notte, un batch in ritardo o un incidente vero. Il problema non è solo rilevare la deviazione: è decidere quando vale la pena svegliare una persona, con quale evidenza in mano e quale azione attesa. Su uno stream questo confine va costruito prima, perché in produzione non hai il tempo di rifletterci a freddo.

Perché serve un criterio, non solo una soglia

In un sistema reale l’alerting non vive isolato. Fa parte di un insieme più ampio fatto di decisioni, dati disponibili, vincoli tecnici e qualità dell’esecuzione. Il rischio di chi inizia è trattarlo come una definizione da imparare a memoria: due formule, un template, fatto. Il lavoro vero è un altro: capire quale decisione cambia quando il segnale diventa affidabile, quali assunzioni stai facendo e cosa succede quando quelle assunzioni saltano.

La domanda di partenza non è “quale metrica calcolo?” ma “quale decisione dovrà essere presa grazie a questa analisi?”. Una dashboard, una query o un modello statistico hanno valore solo se riducono l’incertezza su una scelta. Se non cambiano niente, sono teatro. Un sistema di alerting maturo non massimizza il numero di segnali: massimizza la probabilità che ogni segnale produca una risposta utile.

Una sequenza di lavoro

Per impostare il problema senza perdersi, conviene seguire una sequenza fissa. Prima definisci il problema in linguaggio di business. Poi scegli l’unità di analisi giusta, che può essere l’utente, l’account, l’evento, la sessione, l’ordine o la campagna. Verifichi che i dati misurino davvero il fenomeno e non una sua ombra, costruisci una metrica interpretabile, segmenti per evitare che la media nasconda comportamenti opposti, e infine trasformi il risultato in una raccomandazione verificabile.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se leggiamo meglio il segnale?	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 dichiarata
Azione	Quale passo operativo segue?	Raccomandazione controllabile

Ogni passaggio serve a rendere visibile il costo di una decisione sbagliata. È la differenza tra un rituale tecnico e un criterio di scelta.

Soglie statiche e soglie dinamiche

Il modo più semplice di rilevare un’anomalia è la soglia statica: “se error_rate supera l’1%, manda un alert”. Funziona finché il traffico è stabile, ma se una campagna raddoppia il volume l’alert scatta anche su un sistema perfettamente sano.

La soglia dinamica risolve il problema confrontando il valore con una baseline adattiva: “se error_rate supera la media mobile a 7 giorni più tre deviazioni standard, manda un alert”.

WITH stats AS (
  SELECT AVG(error_rate) OVER (ORDER BY minute ROWS 10080 PRECEDING) AS baseline,
         STDDEV(error_rate) OVER (...) AS stddev
  FROM metrics
)
SELECT * FROM stats WHERE error_rate > baseline + 3 * stddev;

La baseline si muove insieme al volume, e i falsi positivi crollano. Questa è la prima vera leva per ridurre il rumore.

Tre livelli di sofisticazione

Le tecniche di anomaly detection si dispongono su una scala. Al primo livello c’è l’approccio threshold-based: semplice e veloce, ma con molti falsi positivi, adatto a metriche stabili come un health check che smette di rispondere. Al secondo livello stanno i metodi statistici come lo Z-score o l’IQR, sensibili ai cambi di distribuzione e adatti a metriche con pattern noti, per esempio un throughput orario con picchi attesi. Al terzo livello arrivano i metodi di machine learning come Isolation Forest o le LSTM, che catturano pattern non lineari e servono quando la metrica ha stagionalità su più periodi e interazioni tra variabili.

Salire di livello non è sempre meglio. Costa di più in complessità e manutenzione, quindi va giustificato dalla natura della metrica.

Caso reale: anomaly detection in Netflix

Netflix usa un sistema basato sulla Robust Principal Component Analysis (RPCA) per monitorare migliaia di metriche operative. L’idea è scomporre i dati in una componente a basso rango, che rappresenta il pattern normale, e una componente sparsa, che isola le anomalie. La decomposizione resta fattibile su stream, e questo la rende utilizzabile in tempo reale.

Il risultato concreto è che Netflix è passato da migliaia di alert al giorno a poche decine, mantenendo un tasso di detection dei problemi reali superiore al 95%. Il guadagno non è statistico: è che le persone hanno ricominciato a fidarsi degli alert.

Costruire una vista di controllo in SQL

Il pattern seguente è generico ma eseguibile nella maggior parte dei warehouse moderni. Serve a creare una base analitica con metrica, segmento e finestra temporale, così da poter 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;

Questa query non è la risposta finale. È una superficie di osservazione: trend, segmenti, differenze tra canali, variazioni nel tempo. Da qui formuli ipotesi più precise.

Controllare stabilità e anomalie in Python

Una metrica utile deve essere stabile abbastanza da orientare le decisioni e sensibile abbastanza da segnalare 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 è pratico: non reagisci a ogni oscillazione casuale, ma quando una variazione esce dalla banda attesa la segnali. In azienda questo tipo di controllo alimenta alert, review settimanali e retrospettive di prodotto.

Esempio o caso studio

Immagina un team che vuole introdurre anomaly detection su error rate, pagamenti falliti e latenza delle API. Prima di partire stabilisce le baseline per fascia oraria, definisce la severità, assegna l’owner di ciascun alert e scrive un playbook di risposta. Lo fa perché un segnale senza azione associata diventa solo rumore organizzativo. La tabella sotto mostra come ragionare quando un numero cambia.

Evidenza osservata	Lettura prudente	Azione consigliata
Il numero migliora ma la baseline è debole	Può essere effetto reale o dipendere dal campione	Rafforzare il confronto prima di scalare
Un segmento cambia più degli altri	La media aggregata nasconde la differenza	Separare coorti o casi d’uso
Il costo cresce insieme al risultato	Il beneficio va letto sul margine	Applicare una soglia economica esplicita
Il sistema produce numeri incoerenti	La fiducia nel dato è parte della decisione	Correggere ownership e controlli

Regole per un buon sistema di alert

Un buon sistema di alert rispetta poche regole non negoziabili. Ogni alert deve richiedere un’azione umana: se non c’è niente da fare, quello che stai mandando è un log, non un alert. La priorità deve riflettere l’impatto sul business e non la rarità statistica, quindi un P1 sveglia le persone alle 3 del mattino mentre un P3 può aspettare l’indomani. Serve un rate limiting, al massimo un alert al minuto per lo stesso problema, perché i duplicati non aggiungono informazione. E ogni alert deve portare il contesto con sé: non “CPU sopra il 90%” ma “CPU di web-server-03 al 94% contro una baseline del 45%, iniziato alle 14:32, impatta la checkout API”.

Errori comuni da evitare

L’errore più frequente è trattare l’anomaly detection come un’etichetta tecnica invece che come un criterio di scelta: si mostra un numero senza dire quale decisione cambia, quale baseline lo rende interpretabile e quale rischio resta aperto. Accanto a questo ce ne sono altri tre ricorrenti. 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é se chi usa una feature converte di più non vuol dire che sia la feature a causare la conversione: potrebbe usarla perché è già più motivato.

Per ridurre questi rischi, ogni analisi dovrebbe portarsi dietro almeno tre controlli: una definizione esplicita della metrica, un confronto per segmento e una verifica contro un periodo precedente o un gruppo di controllo.

Lab / esercizio

Livello base

Scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie all’alerting. Indica metrica, unità di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, il problema è ancora troppo astratto.

Livello intermedio

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

Livello research-grade

Trasforma l’esercizio in un decision memo che includa assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione.

Dataset e materiali consigliati

Usa ClickHouse, uno stream di eventi, un flusso CDC, metriche operative, dashboard realtime e log applicativi. Se non hai dati reali, genera un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione di segmento e una metrica di outcome.

Quiz o checkpoint

1. Quale decisione concreta dovrebbe migliorare grazie a questo sistema di alert?
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 controllo presenteresti prima di raccomandare un’azione?

Riepilogo operativo

L’alerting e l’anomaly detection su stream vanno trattati come strumenti decisionali, non come argomenti 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”: finisce con una frase operativa, cioè quale decisione prendiamo, con quanta confidenza e con quale metrica verificheremo se avevamo ragione. La forma giusta della lezione resta sempre quella: decisione, segnale, baseline, rischio e azione. Tutto il resto serve solo se rende più affidabile uno di questi passaggi.

Riferimenti:

• Netflix Technology Blog. (2018). “Radon: Robust PCA for Anomaly Detection.” Netflix Tech Blog.
• Hochenbaum, J. et al. (2017). “Automatic Anomaly Detection in the Cloud.” KDD 2017.