Il mio guida: Costruire sistemi di avviso che funzionino 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 sporchiamo un po’ le mani. L’argomento? Le allerte. Ma non qualsiasi allerta. Parliamo dell’arte e della scienza di creare un sistema di allerta che vi serva realmente, piuttosto che annegare in un oceano di notifiche senza significato. Il tipo che vi informa che c’è effettivamente un problema, non solo che un server ha starnutito.

Siamo a marzo 2026, e vedo ancora troppe squadre combattere contro la fatica da alert. È un vero problema, e non si tratta solo di un fastidio. Quando ogni leggera fluttuazione attiva una notifica, il vostro team inizia a ignorare tutto. E questo, amici miei, è come un vero incidente sfugge di mano. È come il ragazzo che gridava al lupo, ma invece di un lupo, è 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 alla precisione, alla pertinenza e all’azione. Niente più “tutto è un’urgenza”.

Il problema con “Tutto è un’allerta”

Ricordo una volta, all’inizio della mia carriera, in cui avevamo una configurazione di monitoraggio abbastanza basilare per una nuova piattaforma di e-commerce. Ogni metrica che potevamo 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 questo. Il risultato? Il canale Slack del nostro team ops era una cascata costante di emoji rossi e sirene lampeggianti. La maggior parte del tempo, era benigno. Un picco breve nell’utilizzo della CPU durante un backup pianificato? Allerta. Una pulizia della cache che provoca una temporanea diminuzione dei tempi di risposta? Allerta. Stavamo diventando completamente sordi.

Il peggio è accaduto quando è emerso un vero problema – un bilanciatore di carico mal configurato che rifiutava silenziosamente le richieste. Era sommerso da un centinaio di altre allerte “informative” riguardanti un lieve aumento delle connessioni al database. Ci è voluto molto più tempo del previsto per identificare e risolvere il problema, tutto questo 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 di assicurarsi che, quando arriva un’allerta, abbia peso. Significa qualcosa.

Cambiare focus: Dai sintomi all’impatto

Il più grande errore che vedo le squadre commettere è di allertare sui sintomi piuttosto che sull’impatto. Un alto utilizzo della CPU è un sintomo. Un cliente che sperimenta tempi di caricamento lenti 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.

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

Principi chiave per allerte efficaci

• Allerte sui SLOs/SLIs: Lo standard d’oro. Se avete definito Obiettivi di Livello di Servizio (SLOs) e Indicatori di Livello di Servizio (SLIs) 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 predefinita che rende poco probabile il raggiungimento di questo SLO.
• Concentratevi 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 si completano con successo? Le pagine si caricano rapidamente? Se non è così, è un evento degno di allerta.
• Azionabile: Ogni allerta dovrebbe idealmente indirizzare verso 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” è decisamente migliore.
• Il contesto è re: Un’allerta senza contesto è solo rumore. Includete metriche pertinenti, collegamenti a dashboard, runbook e anche dati storici se possibile.

Progettare condizioni di allerta più intelligenti

Rendiamo tutto 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 del 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, poi torna inattivo. Se impostate un’allerta statica per “CPU > 80% per 5 minuti”, riceverete un’allerta ogni volta che fa il suo lavoro. È un’allerta inefficace.

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 superiori all’SLA: Se il tempo medio per elaborare un’immagine supera, diciamo, i 10 secondi, e il vostro SLA è di 15 secondi, è un indicatore precoce di problema.
• Tasso di errore durante l’elaborazione: Se i fallimenti nell’elaborazione delle immagini stanno aumentando.

Diciamo che utilizzate Prometheus e Alertmanager. Per il backlog di lavori, potreste 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 trattamento delle immagini contiene più di 1000 elementi e il tasso di trattamento è troppo basso. Questo indica che i lavoratori non seguono. 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 trattamento non segue. È molto più intelligente di un'allerta grezza sull'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 "Latenza P99 > 500ms per 1 minuto", che potrebbe essere un leggero intoppo 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 quotidiano. Quando bruciate questo budget troppo rapidamente, è un'allerta.

Diciamo che seguite 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 bruciando 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 deployment 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 è decisamente un campanello d'allarme che state per 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 è buona quanto l'azione che suscita. È qui che entrano in gioco i runbook. Ogni allerta critica dovrebbe avere un runbook corrispondente – un insieme documentato di passaggi che un ingegnere può seguire per indagare, diagnosticare e potenzialmente rimediare al problema.

Ho visto tanti team costruire questi incredibili sistemi di monitoraggio, per poi fallire nel momento in cui un allerta si attiva perché nessuno sa cosa fare. L'ingegnere di guardia riceve una notifica, risolve l'allerta e poi inizia a cercare freneticamente in wiki interni o a contattare ingegneri senior. È tempo perso, un aumento del tempo medio di riparazione (MTTR) e stress inutile.

Cosa rende un buon runbook?

• Titolo e ID chiari: Facile da trovare e da fare riferimento.
• Contesto dell'allerta: Ripetere cosa significa l'allerta e perché si è attivata.
• Fasi di triage iniziale: "Controlla i log del servizio X", "Controlla l'endpoint di salute", "Guarda il dashboard Y".
• Cause comuni: Elenca le ragioni note per l'allerta (ad esempio, recente deployment, guasti di un servizio dipendente).
• Fasi di rimedio: "Riavvia il servizio Z", "Aumenta il numero delle istanze", "Ripeti il deployment".
• Percorso di escalation: Chi contattare se il problema non può essere risolto con le fasi documentate.
• Link a Dashboards/Logs: Link diretti agli strumenti pertinenti.

E al di là dei runbook, pensa alla comunicazione. Quando si attiva un'allerta, chi deve essere informato? È solo l'ingegnere di guardia, oppure un problema critico di fronte al cliente richiede una notifica più ampia ai product manager o addirittura ai dirigenti? Usa diversi canali di notifica (Slack per informativo, PagerDuty per critico) e politiche di escalation per gestirlo in modo efficace.

Informazioni Pratiche per la tua Strategia di Allerta

Va bene, mi hai seguito attraverso i miei discorsi ed esempi. Ecco cosa voglio che tu ricordi oggi:

1. Audit delle tue Allerte Esistenti: Seriamente, passale in rassegna. Per ciascuna, chiedi: "Questa allerta richiede un'azione umana immediata? In caso contrario, può essere riconfigurata come metrica di dashboard, notifica di bassa gravità, o completamente rimossa?" Sii spietato.
2. Definisci i tuoi SLO/SLI (Se non lo hai già fatto): È fondamentale. Una volta che sai cosa conta davvero per l'affidabilità del tuo servizio e l'esperienza utente, la tua strategia di allerta si organizzerà naturalmente.
3. Passare dai Sintomi all'Impatto: Riconfigura le allerte in modo che si concentrino sui momenti in cui l'esperienza utente o l'affidabilità del servizio è effettivamente compromessa, e non solo quando una metrica di sistema supera una soglia arbitraria.
4. Implementa un'Allerta Basata sul "Burn Rate" o sul Budget: Soprattutto per i servizi critici, vai oltre le soglie statiche e allerta quando consumi il tuo budget di errori troppo rapidamente.
5. Sviluppa e Collega Runbook: Ogni allerta critica ha bisogno di un runbook chiaro e azionabile. Facilita il compito del tuo team di guardia nel trovarli e seguirli. Questo riduce drasticamente il MTTR e lo stress.
6. Testa le tue Allerte (Regolarmente!): Non limitarvi a impostarle e dimenticarle. Simula periodicamente guasti o attiva manualmente allerte per assicurarti che si attivino correttamente, che notifichino le persone giuste e che i tuoi runbook siano sempre precisi.

Costruire un sistema di allerta efficace è un processo continuo, non una configurazione unica. Richiede costante affinamento, ascolto dei feedback del tuo team di guardia e adattamento 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 affaticamento in uno strumento potente per mantenere l'affidabilità del servizio. Rimani attento alle vere allerta, e lascia che il resto svanisca in sottofondo.

È tutto per ora. Fino alla prossima volta, mantieni questi agenti sotto controllo e queste allerte significative.

🕒 Published: April 4, 2026