Il bug di CrowdStrike: una lezione sul risk management e l'importanza del testing
Giorgio BrajnikIl recente incidente che ha coinvolto CrowdStrike ha messo in luce una serie di criticità nei processi decisionali legati al risk management e al testing del software.
Quali aspetti strategici legati al testing del software si possono evidenziare?
(Ovviamente sono consapevole del fatto che ex-post e stando lontano dalle stanze dei bottoni sia estremamente facile pontificare. Ciononostante ritengo che da questo tipo di incidenti occorra imparare qualcosa.)
Analizziamo tre livelli di questo processo che sono andati male, tutti riconducibili alla gestione del rischio e al testing inadeguato.
1. Il rilascio del pacchetto da parte di CrowdStrike
Il primo livello riguarda il fornitore stesso, CrowdStrike. È evidente che il processo di test adottato per questa versione sia stato carente, probabilmente a livello di test di regressione automatizzati.
Domande chiave:
- A quali rischi ci si espone rilasciando una nuova versione?
- Quali test si possono scrivere ed eseguire per mitigare questi rischi?
Un approccio più robusto ai test di regressione e un’analisi approfondita dei potenziali scenari di fallimento avrebbero potuto prevenire questo incidente.
2. Il comportamento del sistema operativo Windows
Il secondo livello riguarda Microsoft-Windows e il suo comportamento di fronte al malfunzionamento del pacchetto. La mancanza di un meccanismo per garantire un funzionamento degradato è preoccupante.
Domande chiave:
- Quali sono i rischi di progettare un sistema con questo comportamento?
- Che tipo di test possono essere implementati per mitigare questi rischi?
- Quale dovrebbe essere il comportamento desiderato del sistema in caso di fallimento?
Un approccio più resiliente, con meccanismi di fallback e modalità di funzionamento degradato, potrebbe limitare significativamente l’impatto di bug simili in futuro. Chiaramente tutto ciò andrebbe regolarmente testato.
3. La gestione degli aggiornamenti da parte delle aziende
Il terzo livello concerne le aziende che utilizzano Windows e accettano gli aggiornamenti dei pacchetti.
Domande chiave:
- Quali sono i rischi nell’accettare automaticamente gli aggiornamenti?
- Che tipo di test possono essere implementati per verificare la compatibilità degli aggiornamenti con l’ambiente aziendale?
Per mitigare i rischi, le organizzazioni dovrebbero implementare processi di verifica e test degli aggiornamenti prima di distribuirli su larga scala, possibilmente in ambienti controllati.
Conclusione
Questo incidente sottolinea l’importanza critica del risk management e del testing approfondito a tutti i livelli della catena del software. Dalle aziende di sviluppo ai fornitori di sistemi operativi, fino agli utenti finali aziendali, è fondamentale implementare strategie robuste di gestione del rischio e pratiche di testing rigorose.
Investire in queste aree non è solo una questione di qualità del software, ma di resilienza aziendale e protezione contro potenziali interruzioni catastrofiche. È tempo di ripensare i nostri approcci al testing e alla gestione del rischio nel mondo sempre più interconnesso del software: definire una strategia di testing adeguata è il modo di procedere.
Un articolo del NYT sull’impatto. e un altro articolo più ampio.
Un articolo sul rimedio (anacronistico): sembra di essere ritornati indietro al 1980! Alla faccia del DevOps (il metodo - non il sistema MS).
Pubblicato originariamente come Articolo LinkedIn.