SRE Weekly 542: note su incidenti, sicurezza e pratiche operative

Un PLC ha bloccato l’avvio dei generatori. Vedeva la rete di riserva come attiva, ma l’interruttore era aperto per manutenzione. Quella rete non era utilizzabile. I test di guasto erano stati fatti con cura, ma questo incrocio di condizioni non era stato previsto¹.

Numero 542, prima lezione operativa: se dichiarare un incidente intralcia la risposta, c’è un problema. Lo scrive Hugo van der Horst. I processi devono aiutare chi risponde, non mettergli i bastoni tra le ruote¹.

Daniil Romashov descrive un vincolo concreto su AWS Lambda: fissare una concorrenza massima per evitare che un client malfunzionante esaurisca tutta la capacità da solo¹.

Brent Chapman fa un paragone secco. I vigili del fuoco non misurano il tempo medio per spegnere un incendio. Perché noi misuriamo il MTTR?¹

Chris Siebenmann elenca tre segnali di allarme su Ubuntu. La difficoltà nel tornare ai coreutils standard. Il calendario scelto per pubblicare la correzione di CVE-2026-98432. L’idea che non si possa chiedere a un singolo utente di aprire un bug su sudo-rs. Conclude che, con questi elementi, ha dubbi sull’uso di Ubuntu¹.

Lorin Hochstein nota un cortocircuito di sicurezza: un nuovo processo, pensato per proteggere una parte degli utenti, è stato al centro di un incidente. Lo definisce l’equivalente, nella sicurezza, della sua “legge” informale. Attende il report di incidente di uMudhra, atteso per domani¹.

Due risorse pratiche chiudono il numero. Alex Ewerlöf offre una panoramica delle code, con quando usarle e a quali scopi, vista dalla reliability engineering. Tim Irving propone tre modi di leggere i runbook: come passaggio di consegne, come indirizzario di chi sa di più, come raccolta di lezioni apprese con errori passati¹.

Il filo conduttore è la progettazione per l’imprevisto. Un PLC che interpreta correttamente un segnale, ma nel contesto sbagliato. Un limite di concorrenza che impedisce a un singolo client di bloccare gli altri. Una metrica che non sempre dice ciò che serve a chi risponde. E un processo di sicurezza che, per una parte degli utenti, può diventare origine di rischio¹.

L’aggiornamento atteso è il report di uMudhra. Chiarirà come un processo nato per alzare l’asticella della protezione sia finito al centro di un incidente. Nel frattempo, i temi emersi restano concreti: dichiarazione di incidenti che non intralcino, limiti di risorse per isolare i guasti, attenzione a metriche e processi che possano introdurre effetti collaterali¹.