La mia guida: Costruire sistemi di allerta che funzionano realmente

D’accord, amici. Chris Wade qui, di nuovo nelle trincee digitali con voi su agntlog.com. Oggi non ci limitiamo a controllare le attrezzature; andiamo sotto il cofano e forse ci sporcheremo un po’ le mani. L’argomento? Le allerte. Ma non qualsiasi allerta. Stiamo parlando dell’arte e della scienza di creare un sistema di allerte che vi serva davvero, invece di sommergervi in un oceano di notifiche prive di significato. Il tipo che vi informa che c’è realmente un problema, non solo che un server ha starnutito.

Siamo a marzo 2026, e vedo ancora troppe squadre lottare contro la fatica delle allerte. È un problema reale, e non è solo una questione di fastidio. Quando ogni leggero cambiamento provoca una notifica, il vostro team inizia a ignorare tutto. E questo, amici miei, è come un vero incidente sfugge ai controlli. È come il ragazzo che gridava al lupo, ma invece di un lupo, c’è un servizio clienti critico che va offline alle 3 del mattino perché nessuno ha controllato l’1.000esimo email “Utilizzo della CPU leggermente elevato”.

Quindi, parliamo di come andare oltre il rumore e costruire una strategia di allerta che funzioni davvero. Puntiamo su precisione, pertinenza e azionabilità. Basta con “tutto è un’urgenza”.

Il problema con “Tutto è un’allerta”

Ricordo una volta, all’inizio della mia carriera, in cui avevamo una configurazione di monitoraggio piuttosto basilare per una nuova piattaforma di e-commerce. Per ogni metrica che riuscivamo a estrarre, facevamo un’allerta. Utilizzo del disco, memoria, CPU, I/O di rete, pool di connessioni al database, persino codici di stato HTTP specifici – se si muoveva, avevamo un’allerta per quello. Il risultato? Il canale Slack del nostro team ops era una cascata costante di emoji rossi e sirene lampeggianti. La maggior parte delle volte, era benigno. Un picco breve nell’utilizzo della CPU durante un backup programmato? Allerta. Una pulizia della cache che provoca una temporanea caduta dei tempi di risposta? Allerta. Stavamo diventando completamente sordi.

Il peggio è stato quando è sorto un vero problema – un load balancer mal configurato che rifiutava silenziosamente richieste. Era sommerso da centinaia di altre allerte “informative” riguardanti un leggero aumento delle connessioni al database. Ci è voluto molto più tempo del previsto per identificare e risolvere il problema, tutto perché il nostro rapporto segnale/rumore era abominevole.

Non si tratta solo di ridurre il volume delle notifiche; si tratta di preservare il carico cognitivo e assicurarsi che, quando arriva un’allerta, abbia peso. Significa qualcosa.

Cambiare focus: Dai sintomi all’impatto

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

Pensateci in questo modo: se si accende la spia del motore della vostra auto, è un sintomo. Se la vostra auto sobbalza attivamente e perde potenza, è un impatto. Volete essere allertati quando l’auto sobbalza, non solo per ogni piccola lettura del sensore leggermente al di fuori delle specifiche.

Principi chiave per allerte efficaci

• Allertate sui SLOs/SLIs: Lo standard d’oro. Se avete definito Obiettivi di Livello di Servizio (SLO) e Indicatori di Livello di Servizio (SLI) per i vostri servizi, allertate quando questi vengono violati o tendono verso una violazione. Ad esempio, se il vostro SLO è del 99,9% di disponibilità per le richieste API, allertate quando il vostro tasso di errore supera una soglia predeterminata che rende poco probabile il raggiungimento di questo SLO.
• Focalizzatevi sull’esperienza utente: Alla fine, ciò che conta di più è l’esperienza dell’utente finale. Sono in grado di utilizzare il vostro servizio? Le transazioni vengono completate con successo? Le pagine si caricano rapidamente? Se non è così, è un evento degno di attenzione.
• Azionabile: Ogni allerta dovrebbe idealmente puntare a un compito azionabile o fornire abbastanza contesto affinché un ingegnere possa iniziare a fare debug. Se un’allerta dice semplicemente “Errore”, non è molto utile. “Il pool di connessioni al database è esaurito sul servizio X, impattando il trattamento delle transazioni” è molto meglio.
• Il contesto è re: Un’allerta senza contesto è solo rumore. Includete metriche pertinenti, collegamenti a dashboard, runbook e persino dati storici se possibile.

Progettare condizioni di allerta più intelligenti

Rendiamo questo pratico. Come traduciamo questi principi in configurazioni di allerta reali? Si tratta di essere deliberati con le vostre soglie e condizioni.

Esempio 1: Il problema di carico “burst”

Immaginate di avere un servizio di elaborazione in background che gestisce i caricamenti di immagini. È progettato per essere “bursting” – a volte inattivo, a volte utilizza la CPU al 90% per alcuni minuti mentre elabora un lotto, dopodiché torna inattivo. Se impostate un’allerta statica per “CPU > 80% per 5 minuti”, riceverete un’allerta ogni volta che fa il suo lavoro. È una brutta allerta.

Invece, pensate ad allertare su cose come:

• Crescita del backlog di lavori: Se la coda delle immagini da elaborare aumenta costantemente, indicando che i lavoratori non riescono a tenere il passo.
• Tempi di elaborazione che superano l’SLA: Se il tempo medio per elaborare un’immagine supera, diciamo, i 10 secondi, e il vostro SLA è di 15 secondi, è un indicatore anticipato di un problema.
• Tasso di errore durante l’elaborazione: Se gli errori di elaborazione delle immagini aumentano.

Diciamo che utilizzate Prometheus e Alertmanager. Per il backlog di lavori, potreste avere qualcosa come:

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 aumenta per l'istanza {{ $labels.instance }}"
 description: "La coda di elaborazione delle immagini ha più di 1000 elementi e il tasso di elaborazione è troppo basso. Ciò indica che i lavoratori non stanno tenendo il passo. Controllare la salute dei lavoratori e l'utilizzo delle risorse."
 runbook: "https://my-runbooks.com/image-processor-backlog"

Questa allerta si attiva solo se la dimensione della coda è significativa E se il tasso di elaborazione non sta seguendo. È molto più intelligente di un'allerta grezza sulla CPU.

Esempio 2: Latenza & Budget di errore

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

Se il vostro SLO consente lo 0,1% di errori su un periodo di 30 giorni, potete stimare un budget di errore orario o giornaliero. Quando bruciate questo budget troppo rapidamente, è un'allerta.

Diciamo che monitorate le richieste riuscite (http_requests_total{status_code="2xx"}) e tutte le richieste (http_requests_total). Il vostro 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 esaurendo il suo budget di errore troppo rapidamente"
 description: "Il tasso di errore del servizio API ha superato lo 0,5% negli ultimi 5 minuti. Questo esaurisce il nostro budget di errore più velocemente del previsto. Investigare i recenti deploy o le dipendenze a monte."
 dashboard: "https://grafana.example.com/d/api-service-overview"

Questa allerta si attiva se il tasso di errore su 5 minuti supera lo 0,5%. La soglia (0,005) è derivata dal vostro SLO; se il vostro SLO consente lo 0,1% di errori in un mese, allora lo 0,5% in pochi minuti è sicuramente un segnale d'allerta che siete sul punto di superare il vostro budget. Il for: 2m garantisce che non si tratti solo di un picco isolato.

L'elemento umano: Runbook e comunicazione

Un'allerta non è tanto buona quanto l'azione che incita. È qui che entrano in gioco i runbook. Ogni allerta critica dovrebbe avere un runbook corrispondente – un insieme documentato di passi che un ingegnere può seguire per indagare, diagnosticare e potenzialmente rimediare al problema.

Ho visto tante squadre costruire questi incredibili sistemi di monitoraggio, per fallire quando un avviso si attiva perché nessuno sa cosa fare. L'ingegnere di turno riceve una notifica, risolve l'allerta e poi inizia a cercare freneticamente nei wikis interni o a contattare ingegneri senior. È tempo perso, un aumento del tempo medio di riparazione (MTTR) e uno stress inutile.

Cosa rende un buon runbook?

• Titolo e ID chiari: Facili da trovare e da utilizzare come riferimento.
• Contesto dell'allerta: Riassumere cosa significa l'allerta e perché è stata attivata.
• Passaggi di triage iniziale: «Controlla i log del servizio X», «Controlla il punto di terminazione della salute», «Guarda il dashboard Y».
• Cause frequenti: Elencare le ragioni conosciute per l'allerta (ad esempio, recente distribuzione, guasto di un servizio dipendente).
• Passaggi di rimedio: «Riavvia il servizio Z», «Aumenta il numero di istanze», «Ritira la distribuzione».
• Percorso di escalation: Chi contattare se il problema non può essere risolto con i passaggi documentati.
• Link a Dashboards/Logs: Link diretti agli strumenti pertinenti.

E oltre ai runbook, pensate alla comunicazione. Quando scatta un'allerta, chi deve essere informato? È solo l'ingegnere di turno, o un problema critico per il cliente richiede una notifica più ampia ai product manager o addirittura ai dirigenti? Utilizzate diversi canali di notifica (Slack per informazioni, PagerDuty per problemi critici) e politiche di escalation per gestire tutto questo in modo efficace.

Informazioni Pratiche per la Vostra Strategia di Allerta

D'accordo, mi avete seguito attraverso i miei discorsi e esempi. Ecco cosa voglio che ricordiate oggi:

1. Audit delle Vostre Allerte Esistenti: Sul serio, esaminatele attentamente. Per ciascuna, chiedete: "Questa allerta richiede un'azione umana immediata? Se no, può essere riconfigurata come metrica di dashboard, notifica a bassa gravità, o completamente rimossa?" Siate inflessibili.
2. Definite i Vostri SLOs/SLIs (se non l'avete già fatto): È fondamentale. Una volta che sapete cosa conta davvero per l'affidabilità del vostro servizio e l'esperienza dell'utente, la vostra strategia di allerta si organizzerà naturalmente.
3. Passare dai Sintomi all'Impatto: Riconfigurate le allerte per concentrarvi sui momenti in cui l'esperienza dell'utente o l'affidabilità del servizio sono davvero compromesse, e non solo quando una metrica di sistema supera una soglia arbitraria.
4. Implementate un'Allerta Basata sul "Burn Rate" o sul Budget: Soprattutto per i servizi critici, andate oltre le soglie statiche e allertate quando consumate il vostro budget di errori troppo rapidamente.
5. Sviluppate e Collegate Runbooks: Ogni allerta critica ha bisogno di un runbook chiaro e azionabile. Facilitare la vita del vostro team di turno per trovarli e seguirli. Ciò riduce drasticamente il MTTR e lo stress.
6. Testate le Vostre Allerte (Regolarmente!): Non limitatevi a stabilirle e dimenticarle. Simulate periodicamente guasti o attivate manualmente allerte per assicurarvi che si attivino correttamente, notifichino le persone giuste e che i vostri runbook siano sempre aggiornati.

Costruire un sistema di allerta efficace è un processo continuo e non una configurazione unica. Richiede un perfezionamento costante, ascolto dei feedback del vostro team di turno e adattamento man mano che i vostri sistemi evolvono. Ma concentrandovi sull'impatto, sull'azione e fornendo contesto, potete trasformare le vostre allerte da una fonte di fatica a uno strumento potente per mantenere l'affidabilità del servizio. Tenete l'orecchio attento alle vere allerte e lasciate che il resto svanisca sullo sfondo.

È tutto per ora. Fino alla prossima volta, mantenete questi agenti monitorati e queste allerte significative.

🕒 Published: April 4, 2026