Il tuo monitoraggio non ha un problema di allarmi, ha un problema di contesto
Mille allarmi a notte non sono mille problemi. Come una regola di due righe ha trasformato il rumore di una rete FTTH in incidenti su cui si può agire.
Il turno di notte in un piccolo NOC è sempre uguale: uno schermo con centinaia di righe rosse e una persona che decide, a occhio, quali contano. Non è che manchi il monitoraggio. Ne avanza.
Per nove anni sono stato dall’altra parte di quello schermo. Quello che ho imparato è che il problema non è quasi mai la mancanza di allarmi: è che ogni allarme arriva da solo, senza nulla attorno che spieghi cosa significa.
Un allarme non è un incidente
Un apparato che segnala perdita di segnale può essere rotto, oppure qualcuno ha tolto la corrente in quell’isolato, oppure si è riavviato da solo ed è tornato. Tre situazioni molto diverse che producono esattamente la stessa riga rossa.
L’operatore risolve incrociando i dati a mente: guarda se lo stesso apparato ha segnalato altro poco fa, se anche i vicini si lamentano, se ci sono lavori programmati. Quell’incrocio è lavoro vero, si fa a mano e si fa male quando si ha sonno.
La domanda che vale la pena farsi non è “come mando meno allarmi?” ma “cosa deve succedere perché valga la pena svegliare qualcuno?”.
La regola che ho finito per usare
In FTTH-Copilot, l’agente di diagnostica che ho scritto per le reti in fibra, la risposta si è rivelata piuttosto noiosa, ed è proprio per questo che funziona:
Raggruppare gli allarmi per dispositivo. Aprire un incidente solo quando lo stesso dispositivo segnala almeno due tipi distinti di allarme dentro una finestra temporale.
Tutto qui. Nessun modello, nessuna soglia magica, nessuna media mobile.
Perché due tipi distinti? Perché il rumore tende a ripetersi identico a sé stesso. Un collegamento instabile manda cento volte lo stesso allarme di perdita di segnale. Un apparato che sta davvero morendo manda cose diverse: prima cala la potenza ottica, poi sale la temperatura, poi sparisce. Due segnali diversi nello stesso punto sono molto più difficili da spiegare per caso di cento segnali uguali.
Il codice che fa questo sta in una schermata. È pubblicato nel repository, in packages/alerts/src/correlate.ts, e la costante che definisce il minimo si chiama DEFAULT_MIN_KINDS. Vale 2.
Quello che nessuno ti dice sulle finestre temporali
La parte difficile non è la regola, è decidere quanto dura la finestra e quando si chiude l’incidente.
Se la finestra è troppo corta perdi correlazioni reali: la temperatura impiega tempo a salire. Se è troppo lunga inizi a mettere insieme cose che non c’entrano nulla e torni al rumore, solo che adesso il rumore arriva raggruppato e sembra più serio.
Non esiste un numero corretto. Esiste un metodo: guarda gli incidenti reali degli ultimi mesi, misura quanto ha impiegato il secondo segnale ad apparire e usa quel percentile. Se non hai quello storico, parti corto e allarga. Costa meno perdere una correlazione che inventarla.
Come capire se funziona
Bastano due metriche, e nessuna delle due è “numero di allarmi”:
- Incidenti per turno. Se cala e il tempo di risoluzione non peggiora, hai vinto.
- Incidenti che l’operatore ha chiuso senza fare nulla. Se questo numero cresce, la tua regola sta raggruppando rumore e promuovendolo a incidente. È peggio che non raggruppare.
Il secondo è quello che conta. Un sistema che ti mente con sicurezza fa più danni di uno che urla.
Da portare a casa
Se il monitoraggio ti sta affogando, prima di comprare uno strumento nuovo prova questo: raggruppa per entità — dispositivo, servizio, cliente, quello che ha senso nel tuo dominio — e pretendi due segnali distinti prima di disturbare una persona. È un pomeriggio di lavoro e di solito basta.
Lo strumento costoso viene dopo, se serve davvero. Quasi mai serve.