Un watchdog ben progettato non è aggressivo: è disciplinato. La sua funzione non è risolvere il problema al posto dell’operatore, ma impedire che un processo critico resti appeso senza controllo. Per questo deve lavorare con privilegi minimi, regole verificabili, soglie chiare e report tracciabili.
In sintesi: un buon watchdog deve essere separato, leggibile, prudente, misurabile e tracciabile.
Linee Guida
Per implementare un watchdog corretto bisogna prima chiarire che non è un secondo processo operativo, ma un supervisore. Il suo valore nasce proprio dal perimetro ristretto: osserva, misura, segnala e interviene solo quando le regole lo consentono.
Un buon watchdog dovrebbe seguire queste linee guida:
Separare controllo e lavoro
La sessione watchdog deve essere distinta dalla sessione principale. La sessione principale esegue test, deploy o elaborazioni; il watchdog osserva soltanto.
Definire regole scritte prima dell’esecuzione
Il comportamento del watchdog deve essere documentato in un file operativo: cosa controllare, ogni quanto controllare, quali soglie usare, cosa può fermare e cosa non può toccare.
Lavorare in sola lettura per default
Tutti i controlli devono essere non invasivi: lettura log, controllo processi, query SELECT, stato job, timestamp file. Le azioni modificanti devono essere eccezioni esplicite.
Limitare il perimetro di intervento
Il watchdog non deve poter fermare “tutto il sistema”. Deve poter intervenire solo sui processi appartenenti al kit o al job sorvegliato, identificati da path, nomi comando o range di test.
Usare segnali oggettivi di avanzamento
Non basta vedere un processo vivo. Bisogna confrontare più segnali:
- timestamp e dimensione dei log;
- processi attivi e loro durata;
- job applicativi running;
- stati DB intermedi;
- output della sessione principale.
Definire soglie di hang misurabili
Esempio: “processo vivo oltre 5 minuti senza aggiornamento log” è una regola verificabile. “Mi sembra bloccato” non lo è.
Intervenire in modo progressivo
Se il watchdog deve fermare processi, dovrebbe prima usare uno stop morbido, per esempio TERM, poi attendere, verificare di nuovo e solo dopo usare uno stop forzato sui PID ancora presenti.
Non fare cleanup automatico
Dopo un blocco, il watchdog non dovrebbe cancellare file, svuotare tabelle, droppare job o ripristinare ambienti. Queste attività appartengono alla sessione principale o richiedono autorizzazione esplicita.
Registrare sempre le evidenze
Ogni decisione deve poter essere spiegata: PID osservati, comando, durata, log fermo, stato DB, job running, azione eseguita o motivo per cui non è stata eseguita.
Preferire falsi allarmi a interventi pericolosi
Un watchdog corretto è conservativo. Se non è sicuro che un processo appartenga al perimetro autorizzato, segnala il dubbio e non lo termina.
- Lasciare il controllo finale all’utente
Per azioni fuori perimetro, come kill di processi host, spegnimento VM, cleanup DB o drop job Oracle, il watchdog deve chiedere conferma esplicita.
- Produrre un report finale
Alla fine deve indicare cosa ha visto, cosa ha fermato, cosa non ha fermato, stato finale dei job, stato finale dei dati osservati e presenza di eventuali anomalie funzionali.
Nessun commento:
Posta un commento