Automatizzare alerting e remediation con i workflow

Ogni infrastruttura genera alert. Il problema non è la loro mancanza: è il loro eccesso, e la loro forma grezza. Un alert che dice "CPU alta su host-12" alle tre di notte, senza contesto, non è informazione utile: è rumore che logora chi è di turno. Automatizzare alerting e remediation significa due cose: trasformare quel rumore in un segnale chiaro, e far gestire alla macchina i casi che la macchina può chiudere da sola, in sicurezza.

Perché un alert grezzo non basta

Un alert diventa utile solo dopo tre passaggi: arricchimento (di che host si tratta, che ruolo ha, è in finestra di manutenzione?), classificazione (è un problema reale o un picco rientrato? quanto è grave?) e instradamento (chi deve saperlo, e su quale canale?).

Fare questi tre passaggi a mano, ogni volta, è esattamente il lavoro ripetitivo che andrebbe automatizzato. Ed è un lavoro perfetto per un motore di workflow: logica condizionale, chiamate ad API, nessun calcolo pesante.

L'architettura: quattro stadi

La pipeline ha una forma semplice e lineare:

1. Monitoraggio - il sistema che osserva (Prometheus, Zabbix, un health check) rileva una condizione anomala.
2. Webhook - invece di mandare una mail, il monitoraggio invoca un webhook HTTP con un payload strutturato.
3. Motore di workflow - riceve il webhook, arricchisce, decide, instrada. Può essere un orchestratore self-hosted o una piattaforma interna: quel che conta è il pattern, non il nome del prodotto.
4. Azione - una notifica mirata, oppure, nei casi previsti, una remediation automatica.

Il vantaggio del webhook rispetto alla mail è che il payload è dati, non testo. Su dati si ragiona.

Costruire il workflow

Il monitoraggio invia un payload del genere:

{
  "alert": "high_cpu",
  "host": "web-03",
  "value": 94,
  "threshold": 85,
  "severity": "warning",
  "timestamp": "2026-05-15T02:11:00Z"
}

Il workflow lo elabora in quattro nodi.

1. Trigger - Webhook. Il nodo di ingresso espone un endpoint HTTP. Va protetto: un token nell'header, e l'endpoint raggiungibile solo dalla rete del monitoraggio, non da internet.

2. Arricchimento. Un nodo che interroga la fonte di verità sugli asset (una CMDB, un inventario, anche un semplice file): a web-03 associa ruolo, ambiente, referente, e verifica se è in una finestra di manutenzione pianificata. Se lo è, il workflow termina qui: nessuna notifica per un evento atteso.

3. Decisione. Un nodo condizionale che combina i segnali. Non il solo valore di soglia: un picco di CPU rientrato in due minuti è diverso da uno che dura da venti. La logica tipica:

• evento in finestra di manutenzione, oppure rientrato da solo, e severità warning -> registra e basta;
• severità warning persistente -> notifica sul canale di team;
• severità critical su un host di produzione -> notifica con escalation a chi è di turno.

4. Instradamento. Il nodo finale costruisce un messaggio leggibile, già arricchito ("CPU al 94% su web-03, produzione, referente Tizio, persistente da 20 minuti") e lo manda sul canale giusto. Un messaggio così non costringe nessuno ad alzarsi per capire di cosa si tratta.

Già fermandosi qui, senza alcuna remediation automatica, la pipeline ha eliminato il rumore e dato contesto. È metà del valore.

La remediation sicura

L'altra metà è far chiudere alla macchina i casi che può chiudere. Ma qui serve disciplina, perché un'automazione che agisce sull'infrastruttura senza criterio fa più danni di un incidente.

Tre regole non negoziabili.

Solo azioni idempotenti. L'azione deve poter essere eseguita più volte senza effetti diversi. "Riavvia il servizio se è fermo" è idempotente. "Aggiungi una regola" non lo è: alla decima volta hai dieci regole.

Solo azioni reversibili. Se l'automazione sbaglia, deve esistere un modo semplice per tornare indietro. Riavviare un servizio applicativo è reversibile. Cancellare file no.

Sempre con guardrail. Prima di agire, il workflow verifica delle precondizioni: l'host è davvero quello atteso, l'azione non è già stata tentata negli ultimi N minuti (un contatore evita i loop), l'ambiente è quello previsto. E ogni azione viene registrata: cosa, quando, su cosa, con quale esito.

Uno script di remediation tipico, invocato dal workflow, ha questa forma:

#!/usr/bin/env bash
set -euo pipefail
SERVICE="$1"

# Guardrail: agisci solo se il servizio risulta fermo
if systemctl is-active --quiet "$SERVICE"; then
  echo "noop: $SERVICE risulta attivo"
  exit 0
fi

logger -t auto-remediation "restart tentato su $SERVICE"
systemctl restart "$SERVICE"
sleep 5

if systemctl is-active --quiet "$SERVICE"; then
  echo "ok: $SERVICE riavviato"
else
  echo "fallito: $SERVICE ancora fermo, serve un operatore"
  exit 1
fi

Nota il finale: se la remediation non risolve, lo script lo dice chiaramente e il workflow torna a fare il suo lavoro originario, notificare una persona. L'automazione non nasconde il problema: lo gestisce se può, lo passa se non può.

Cosa non automatizzare

La domanda giusta non è "cosa posso automatizzare", ma "cosa è sicuro automatizzare". Restano fuori, sempre, e vanno a un operatore:

• tutto ciò che cancella o sovrascrive dati;
• le modifiche a firewall, rete e DNS, per il rischio di lockout;
• le azioni su sistemi in cluster, dove un riavvio mal calibrato rompe il quorum;
• qualunque caso ambiguo, dove la diagnosi non è certa.

Vale lo stesso principio che applico a qualunque sistema autonomo, inclusi gli agenti AI descritti nel caso studio dell'assistente vocale: un sistema automatico deve avere confini netti e dichiarati. Dentro quei confini è prezioso, perché toglie lavoro ripetitivo e accorcia i tempi di reazione. Fuori da quei confini, il suo compito non è agire: è chiamare una persona, con tutto il contesto già pronto.