La mia guida: Creare sistemi di allerta che funzionano davvero

Va bene, gente. Chris Wade qui, di nuovo nelle trincee digitali con voi su agntlog.com. Oggi non ci limitiamo a dare un’occhiata; stiamo andando sotto il cofano e forse ci sporcheremo un po’ le mani. L’argomento? Allerta. Ma non solo qualsiasi allerta. Stiamo parlando dell’arte e della scienza di costruire un sistema di allerta che realmente ti serva, invece di sommergerti in un mare di avvisi privi di significato. Un tipo che ti dice che qualcosa è veramente rotto, non solo che un server ha starnutito.

È marzo 2026 e continuo a vedere troppe squadre lottare contro la fatica da allerta. È un problema reale e non si tratta solo di fastidio. Quando ogni piccola fluttuazione attiva una notifica, il tuo team inizia ad ignorare tutto. E questo, miei amici, è come un vero incidente sfugge di mano. È come il ragazzo che gridava al lupo, ma invece di un lupo, è un servizio critico per i clienti che va offline alle 3 del mattino perché nessuno ha controllato l’ennesimo “uso della CPU leggermente elevato” nell’e-mail.

Quindi, parliamo di come andare oltre il rumore e costruire una strategia di allerta che funzioni realmente. Puntiamo alla precisione, rilevanza e azionabilità. Basta con il “tutto è un’emergenza.”

Il Problema del “Tutto è un’Allerta”

Ricordo un’occasione, all’inizio della mia carriera, in cui avevamo una configurazione di monitoraggio piuttosto semplice per una nuova piattaforma e-commerce. Ogni metrica che potevamo raccogliere veniva monitorata. Uso del disco, memoria, CPU, I/O di rete, pool di connessioni del database, persino codici di stato HTTP specifici – se si muoveva, avevamo un’allerta per questo. Il risultato? Il canale Slack del nostro team operazioni era una costante cascata di emoji rosse e sirene lampeggianti. La maggior parte di esse era benigna. Un breve picco della CPU durante un backup pianificato? Allerta. Un’operazione di svuotamento della cache che provoca una temporanea diminuzione dei tempi di risposta? Allerta. Ci stavamo praticamente rendendo sordi.

La parte peggiore è stata quando è venuto alla luce un problema reale – un bilanciatore di carico malconfigurato che stava silenziosamente scartando richieste. Era sepolto sotto un centinaio di altre allerta “informative” riguardo a un lieve aumento delle connessioni al database. Ci è voluto molto più tempo di quanto avrebbe dovuto per identificare e risolvere, tutto perché il nostro rapporto segnale-rumore era abissale.

Questo non riguarda solo la riduzione del volume delle notifiche; si tratta di preservare il carico cognitivo e garantire che quando arriva un’allerta, abbia peso. Significa qualcosa.

Cambiare Focus: Dai Sintomi all’Impatto

Il più grande errore che vedo fare ai team è di allertare sui sintomi piuttosto che sull’impatto. L’elevato utilizzo della CPU è un sintomo. Un cliente che sperimenta caricamenti lenti delle pagine o transazioni fallite è un impatto. Anche se i sintomi possono portare a un impatto, non tutti i sintomi si traducono immediatamente in un problema che richiede un’intervento umano urgente.

Pensa a questo modo: se si accende la spia del motore della tua auto, quello è un sintomo. Se la tua auto sta effettivamente singhiozzando e perde potenza, quello è un impatto. Vuoi essere allertato quando l’auto singhiozza, non per ogni piccola lettura del sensore che è leggermente fuori norma.

Principi Chiave per Allerta Efficaci

• Allerta su SLO/SLI: Il gold standard. Se hai definiti Obiettivi di Servizio (SLO) e Indicatori di Servizio (SLI) per i tuoi servizi, allerta quando vengono violati o sono in rotta verso una violazione. Ad esempio, se il tuo SLO è il 99,9% di disponibilità per le richieste API, allerta quando il tuo tasso di errore supera una soglia predefinita che rende improbabile il raggiungimento di quel SLO.
• Focus sull’Esperienza Utente: Alla fine, ciò che conta di più è l’esperienza dell’utente finale. Possono utilizzare il tuo servizio? Le transazioni vengono completate con successo? Le pagine si caricano rapidamente? Se no, quello è un evento degno di allerta.
• Azionabilità: Ogni allerta dovrebbe idealmente puntare a un compito azionabile o fornire abbastanza contesto perché un ingegnere inizi a fare debug. Se un allerta dice solo “Errore”, non è molto utile. “Pool di connessione al database esaurito sul servizio X che impatta il processamento delle transazioni” è molto meglio.
• Il Contesto è Re: Un allerta senza contesto è solo rumore. Includi metriche rilevanti, link a dashboard, runbook e anche dati storici se possibile.

Creare Condizioni di Allerta più Intelligenti

Passiamo alla pratica. Come traduciamo questi principi in vere configurazioni di allerta? Si tratta di essere deliberati con le tue soglie e condizioni.

Esempio 1: Il Problema del Carico “Bursty”

Immagina di avere un servizio di elaborazione in background che gestisce il caricamento di immagini. È progettato per essere “bursty” – a volte è inattivo, a volte sta utilizzando la CPU al 90% per alcuni minuti mentre elabora un lotto, poi torna inattivo. Se imposti un’allerta statica per “CPU > 80% per 5 minuti”, riceverai un’allerta ogni volta che fa il suo lavoro. Questa è un’allerta sbagliata.

Invece, considera di allertare su cose come:

• Crescita del backlog dei lavori: Se la coda delle immagini da elaborare cresce costantemente, indicando che i lavoratori non riescono a tenere il passo.
• Tempo di elaborazione superiore all’SLA: Se il tempo medio per elaborare un’immagine supera, diciamo, i 10 secondi, e il tuo SLA è di 15 secondi, questo è un indicatore precoce di problemi.
• Tasso di errore durante l’elaborazione: Se le insuccessi dell’elaborazione delle immagini aumentano.

Diciamo che stai usando Prometheus e Alertmanager. Per il backlog di lavoro, potresti avere qualcosa del genere:

groups:
 - name: image_processor_alerts
 rules:
 - alert: ImageProcessorBacklogGrowing
 expr: sum(image_processor_queue_size) by (instance) > 1000 and rate(image_processor_processed_total[5m]) < 0.1 * sum(image_processor_queue_size) by (instance)
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: "Il backlog del processore di immagini sta crescendo per l'istanza {{ $labels.instance }}"
 description: "La coda di elaborazione delle immagini ha oltre 1000 elementi e il tasso di elaborazione è troppo basso. Questo indica che i lavoratori non stanno tenendo il passo. Controlla la salute dei lavoratori e l'utilizzo delle risorse."
 runbook: "https://my-runbooks.com/image-processor-backlog"

Questa allerta scatta solo se la dimensione della coda è significativa E il tasso di elaborazione non tiene il passo. Questo è molto più intelligente di un'allerta sulla CPU grezza.

Esempio 2: Latenza e Budget di Errore

Per i servizi rivolti agli utenti, la latenza e i tassi di errore sono spesso le metriche più critiche. Invece di allertare su "P99 latenza > 500ms per 1 minuto", che potrebbe essere un piccolo problema temporaneo, considera un’allerta che consuma il tuo budget di errore.

Se il tuo SLO consente errori dello 0,1% su un periodo di 30 giorni, puoi stimare un budget di errore orario o giornaliero. Quando bruci quel budget troppo rapidamente, quello è un alert.

Diciamo che stai monitorando richieste riuscite (http_requests_total{status_code="2xx"}) e tutte le richieste (http_requests_total). Il tuo tasso di errore per una finestra di 5 minuti potrebbe essere:

groups:
 - name: api_service_alerts
 rules:
 - alert: ApiServiceErrorBudgetBurn
 expr: |
 (sum(rate(http_requests_total{job="api-service", status_code=~"5xx|4xx"}[5m]))
 /
 sum(rate(http_requests_total{job="api-service"}[5m]))) > 0.005
 for: 2m
 labels:
 severity: major
 annotations:
 summary: "Il servizio API sta bruciando il budget di errore troppo rapidamente"
 description: "Il tasso di errore del servizio API ha superato lo 0,5% negli ultimi 5 minuti. Questo sta consumando il nostro budget di errore più velocemente del previsto. Indaga sulle recenti distribuzioni o dipendenze upstream."
 dashboard: "https://grafana.example.com/d/api-service-overview"

Questa allerta scatta se il tasso di errore di 5 minuti supera lo 0,5%. La soglia (0,005) è derivata dal tuo SLO; se il tuo SLO consente errori dello 0,1% in un mese, allora lo 0,5% in pochi minuti è sicuramente un campanello d'allarme che stai per superare il budget. Il for: 2m garantisce che non si tratti solo di un picco isolato.

L'Elemento Umano: Runbook e Comunicazione

Un’allerta è valida solo quanto l'azione che provoca. Qui entrano in gioco i runbook. Ogni allerta critica dovrebbe avere un corrispondente runbook – un insieme documentato di passaggi che un ingegnere può seguire per investigare, diagnosticare e potenzialmente risolvere il problema.

Ho visto così tanti team costruire questi straordinari sistemi di monitoraggio, solo per crollare quando scatta un'allerta perché nessuno sa cosa fare. L'ingegnere di guardia riceve l’avviso, fissa l’allerta e poi inizia a cercare freneticamente nei wiki interni o a contattare ingegneri senior. Tempo sprecato, aumento del tempo medio di ripristino (MTTR) e stress inutile.

Cosa rende un buon runbook?

• Titolo e ID Chiari: Facile da trovare e riferimento.
• Contesto dell'Allerta: Ripetere cosa significa l'allerta e perché è scattata.
• Passi Iniziali di Triaggio: "Controlla i log del servizio X", "Verifica l'endpoint di salute", "Guarda il dashboard Y."
• Cause Comuni: Elenca le ragioni conosciute per l'allerta (ad es. distribuzione recente, interruzione del servizio dipendente).
• Passi di Remediazione: "Riavvia il servizio Z", "Aumenta le istanze", "Ripristina la distribuzione."
• Percorso di Escalation: Chi contattare se il problema non può essere risolto con i passaggi documentati.
• Link a Dashboard/Log: Link diretti agli strumenti pertinenti.

Oltre ai runbook, pensa alla comunicazione. Quando scatta un'allerta, chi deve sapere? È solo l'ingegnere di guardia, o un problema critico che coinvolge i clienti richiede una notifica più ampia ai product manager o persino ai dirigenti? Usa diversi canali di notifica (Slack per informativo, PagerDuty per critico) e politiche di escalation per gestire tutto ciò in modo efficace.

Appunti Utili per la Tua Strategia di Allerta

Okay, quindi sei rimasto con me attraverso le mie lamentele e esempi. Ecco cosa voglio che tu porti via oggi:

1. Controlla le Tue Allerte Esistenti: Seriamente, esaminale. Per ciascuna, chiediti: "Questa allerta richiede un'azione umana immediata? Se no, può essere riconfigurata come una metrica di dashboard, una notifica di bassa gravità o rimossa del tutto?" Sii spietato.
2. Definisci SLO/SLI (Se Non Lo Hai Già Fatto): Questo è fondamentale. Una volta che sai cosa importa davvero per l'affidabilità del tuo servizio e l'esperienza utente, la tua strategia di allerta si sistemerà naturalmente.
3. Passa dai Sintomi all'Impatto: Riconfigura le allerte per concentrarti su quando l'esperienza utente o l'affidabilità del servizio è veramente degradato, non solo quando una metrica di sistema attraversa una soglia arbitraria.
4. Implementa Allerta Basata sul "Burn Rate" o sul Budget: Soprattutto per i servizi critici, oltrepassa soglie statiche e allerta quando stai consumando il tuo budget errori troppo rapidamente.
5. Sviluppa e Collega Runbooks: Ogni allerta critica ha bisogno di un runbook chiaro e azionabile. Rendi facile per il tuo team di pronto intervento trovarli e seguirli. Questo riduce drasticamente il MTTR e lo stress.
6. Testa le Tue Allerte (Regolarmente!): Non impostarle e dimenticarle. Simula periodicamente guasti o attiva manualmente le allerte per assicurarti che si attivino correttamente, avvisino le persone giuste e che i tuoi runbook siano ancora accurati.

Costruire un sistema di allerta efficace è un processo continuo, non un'impostazione una tantum. Richiede un affinamento continuo, ascoltare il feedback del tuo team di pronto intervento e adattarsi man mano che i tuoi sistemi evolvono. Ma concentrandoti sull'impatto, sull'azione e fornendo contesto, puoi trasformare le tue allerte da una fonte di fatica in uno strumento potente per mantenere l'affidabilità del servizio. Tieni gli occhi aperti per le vere allerta, e lascia che il resto svanisca sullo sfondo.

È tutto per ora. Fino alla prossima volta, mantieni quei dispositivi monitorati e quelle allerte significative.

🕒 Published: April 4, 2026