L'alert fatigue esiste davvero: come la risolvono gli sviluppatori bravi

Quando ogni avviso sembra ugualmente urgente, niente sembra più urgente. Ecco come sistemare il tuo monitoraggio con notifiche a più livelli — e quali strumenti si integrano bene con Echobell.

Indice

Esiste un nome per questo fenomeno: alert fatigue. È quello che succede quando i tuoi strumenti di monitoraggio inviano così tante notifiche che il cervello inizia a filtrarle in automatico — comprese quelle che contano davvero.

Di solito comincia in piccolo. Configuri un avviso via email per ogni errore 5xx. Poi una notifica su Slack per ogni build fallita. Poi i ping di Datadog, le email di Sentry, gli SMS di UptimeRobot. Nel giro di un mese il telefono vibra 50 volte al giorno e niente sembra urgente. Il problema vero? Quando qualcosa si rompe sul serio, ti sei già allenato a ignorarlo.

L'alert fatigue distrugge i tempi di risposta. E tempi di risposta lenti distruggono i prodotti.

Perché la maggior parte dei sistemi di monitoraggio produce più rumore che segnale

Il problema di fondo è che quasi tutti gli strumenti di alerting trattano ogni evento allo stesso modo. Un test instabile che fallisce nel 10% dei casi arriva con lo stesso formato di notifica di “l'API dei pagamenti restituisce 500 a tutti gli utenti”. Uno dei due merita una telefonata alle 2 di notte. L'altro dovrebbe finire in un riepilogo settimanale.

Quando tutto riceve lo stesso trattamento, le persone finiscono per ignorare tutto.

La soluzione non è ridurre gli avvisi — è consegnarli in modo più intelligente. Lo stesso evento, con gravità o frequenze diverse, dovrebbe generare livelli di urgenza diversi sul tuo telefono.

L'approccio a tre livelli

Echobell mette a disposizione tre modalità di consegna, e usarle bene tutte e tre fa tutta la differenza:

  • Normale (Active): notifica push standard. Va bene per gli eventi informativi che non richiedono un intervento immediato.
  • Urgente: supera la Full Immersion di iOS. Adatta alle cose che richiedono attenzione entro un'ora o due.
  • Chiamata: fa squillare il telefono come una chiamata in arrivo. Riservala ai casi del tipo “risolvi adesso, altrimenti ci sono conseguenze reali”.

L'obiettivo è tenere il livello chiamata per gli eventi in cui rispondere in ritardo ha conseguenze concrete — mancati incassi, guasti a cascata, dati degli utenti a rischio. Tutto il resto scende a urgente o più in basso.

Sentry: basta farsi svegliare per ogni eccezione Python

Sentry è l'esempio da manuale di alert fatigue. Di default ti manda un'email per ogni nuovo tipo di issue. Su una codebase attiva, in una settimana normale, è un diluvio.

Ecco una configurazione più intelligente:

  1. In Sentry vai su Alerts → Create Alert → Issue Alert
  2. Aggiungi una condizione: The issue is seen more than 10 times in 1 hour
  3. Aggiungi un'azione: Send a notification via webhook → incolla l'URL del tuo canale Echobell
  4. Imposta il tipo di notifica del canale su time-sensitive

Per i percorsi davvero critici — eccezioni non gestite nei flussi di pagamento, errori di autenticazione, dati corrotti — crea un avviso separato con una soglia più bassa e un canale Echobell di livello calling. Quel canale squilla solo quando si rompe qualcosa su quel percorso specifico.

Il risultato: le issue di routine si accumulano in silenzio nella dashboard di Sentry. I problemi che bloccano la produzione ti fanno squillare il telefono.

Prometheus e AlertManager: instradare in base alla gravità

Se usi Prometheus, hai già AlertManager che si occupa dell'instradamento. Puoi inviare gli avvisi direttamente a Echobell aggiungendolo come receiver webhook.

Nel tuo alertmanager.yml:

receivers:
  - name: echobell-critical
    webhook_configs:
      - url: https://hook.echobell.one/t/<channel-token>
        send_resolved: true

  - name: slack-warnings
    slack_configs:
      - api_url: YOUR_SLACK_WEBHOOK

route:
  group_by: ['alertname', 'job']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: slack-warnings
  routes:
    - match:
        severity: critical
      receiver: echobell-critical

Con questa configurazione gli avvisi con severity: critical vanno a Echobell e ti fanno squillare il telefono; i warning finiscono su Slack, dove possono aspettare fino al mattino. Non devi modificare nemmeno una regola di Prometheus — basta aggiungere il livello di instradamento in AlertManager.

Imposta il canale Echobell su Chiamata. Se AlertManager lo etichetta come critico, merita uno squillo vero.

AWS CloudWatch: SNS → Lambda → Echobell

CloudWatch non ha un output webhook nativo, ma con SNS e una piccola funzione Lambda ci arrivi in pochi minuti.

  1. Crea un topic SNS e collegalo al tuo allarme CloudWatch
  2. Crea una funzione Lambda iscritta a quel topic:
import json
import urllib.request

def lambda_handler(event, context):
    message = json.loads(event['Records'][0]['Sns']['Message'])
    alarm_state = message.get('NewStateValue', 'UNKNOWN')

    payload = {
        "title": f"AWS: {message['AlarmName']}",
        "body": message.get('NewStateReason', 'No details'),
        "notificationType": "calling" if alarm_state == "ALARM" else "active"
    }

    req = urllib.request.Request(
        'https://hook.echobell.one/t/<channel-token>',
        data=json.dumps(payload).encode(),
        headers={'Content-Type': 'application/json'},
        method='POST'
    )
    urllib.request.urlopen(req)

Questo schema funziona con qualsiasi servizio AWS che supporti SNS: eventi RDS, guasti dei servizi ECS, avvisi sulle soglie di fatturazione, cambi di stato delle istanze EC2. Aggiungi una Lambda, collegala a SNS e ogni allarme CloudWatch diventa una telefonata quando scatta sul serio.

Trasformare l'instradamento degli avvisi in una decisione di squadra

Il vero vantaggio degli avvisi a più livelli è rendere esplicita la decisione di instradamento — invece di lasciarla come qualcosa che una persona ha configurato una volta e che poi nessuno riesce più a trovare.

Una struttura pratica per un piccolo team di sviluppo:

CanaleTipoChi si iscrive
production-api-criticalChiamataChi è di turno
production-api-warningsUrgenteTutto il team di sviluppo
staging-allNormaleTeam di sviluppo (facoltativo)
background-jobsNormaleChi è interessato

Quando cambia il turno di reperibilità, chi esce annulla l'iscrizione al canale critico e chi entra si iscrive. Il passaggio di consegne finisce qui — niente file di configurazione, niente pannelli di amministrazione.

I canali Echobell si condividono con un link, quindi a ogni nuova persona del team basta una decina di secondi per iscriversi.

Il test del rapporto segnale/rumore

Prima di aggiungere un nuovo avviso, poniti una domanda: se scatta alle 3 di notte di venerdì, che cosa faccio davvero?

  • “Mi sveglio e lo risolvo subito” → Chiamata
  • “Me ne occupo domattina appena inizio” → Urgente o Normale
  • “Probabilmente niente, tornerei a dormire” → chiediti se quell'avviso debba esistere

Nella maggior parte dei sistemi di monitoraggio la prima categoria è troppo affollata e la seconda troppo vuota. Per la maggior parte degli eventi la risposta giusta è “me ne occupo domani”, e una notifica urgente che compare sulla schermata di blocco senza squillare è esattamente lo strumento adatto.

Una modifica alla volta

Se la tua configurazione attuale genera alert fatigue, la soluzione più rapida non è rifare tutto da zero. Scegli la sorgente più rumorosa — probabilmente le email di Sentry o un canale Slack che ormai tutti hanno silenziato — e classifica ogni tipo di evento come chiamata, urgente o normale.

Una sorgente. Una settimana. Guarda se il rumore cala senza perdere segnale.

Poi passa alla successiva.

Una configurazione degli avvisi ben calibrata è una di quelle cose che migliorano la giornata di lavoro in silenzio, senza fare scena. Smetti di temere il telefono. E inizi a fidarti: se squilla, vuol dire che conta davvero.


Correlati

Articoli correlati