Crowdstrike, il caos dovuto ad un errore di validazione: le spiegazioni lasciano interdetti

Hanno dimostrato tutta la loro leggerezza ed arroganza.

Dovrebbero testare a mano decine di applicazioni che hanno diversi aggiornamenti al giorno? Su più sistemi operativi e su hardware differenti?

Chi scrive questo commento non si rende conto della quantità di lavoro che c'è dietro.

Falcon è uno strumento di sicurezza che fa rapid threat containment, gli aggiornamenti devono arrivare nel più breve tempo possibile.


Il problema da risolvere è quello di validazione, non i test automatizzati.

Perdonami ma la validazione secondo te come la fanno?

Ci sarà qualche diavolo di pipeline su qualche servizio di CD/CI che automatizza questo processo.

Che tu la guardi dal punto di vista del patch management o della validazione delle patch sempre di automazione si tratta, e forse certi processi non dovrebbero essere automatizzati per loro stessa natura e per la loro estrema delicatezza.

Non buttiamola sul "allora torna all'età della pietra", l'ho scritto io stesso, l'automazione è uno strumento e come tutti gli strumenti va usato bene, non va usato a prescindere solo perchè è diventato una moda o perchè così permette di risparmiare a discapito della qualità del servizio.

Guarda che in questo caso è proprio l'automazione di certi processi ad aver provocato un casino colossale, e questa automazione secondo te perchè è stata introdotta?

Anzitutto per risparmiare e impiegare meno tempo (leggasi per ottenere il massimo profitto possibile a discapito della qualità, perchè se la validazione della patch è fatta da un processo automatizzato invece che da dei tester veri, allora non devi pagare dei tester, metti in cottura la tua bella pipeline e la fai girare in automatico dopo ogni commit.

Semplifico chiaramente, ma la sostanza sappiamo bene che è quella.

Persino noi che non abbiamo di certo i mezzi di Crowdstrike per ogni minima modifica effettuiamo test reali su macchine in produzione e ci accordiamo con un gruppo di clienti-cavia per provarli sulle loro macchine dopo che le nuove versioni hanno passato i test sulle nostre....

--la società adotterà anche un meccanismo di distribuzione degli aggiornamenti a scaglioni

Non capisco come sia possibile sviluppare software che gireranno su sistemi critici a livello kernel, e distribuire qualsiasi cosa su 8 milioni di macchine contemporaneamente.

A parte quello, non vorrei essere nel tipo a cui appartiene la riga di codice fallata. Quando viene fatto un git blame da noi per un problema, ho sempre i sudori freddi XD

Fate anche dei bei fuzz test a mano, sai che spasso!
L'automazione non è il problema, il problema è il tipo di test che fai in quei test automatici.
A quanto pare un semplice test di deploy, facilmente automatizzabile e ripetibile in poco su tutti i sistemi operativi supportati, non è stato fatto. Anche con i test fatti a mano se non segui un protocollo di test ben pensato dei test non te ne fai molto.
Ma per la mentalità da bumer che pervade ormai ogni cosa no, fatto a mano è meglio, naturale è meglio, tradizionale è meglio, non aggiornare è meglio...

Esattamente, Ho sempre affrontato il problema in modo indiretto. Pensare di testare a mano tutte le possibili combinazioni, Sarebbe un lavoro Molto lungo. Certo poi ci si potrebbe lamentare che non rilasciano le patch in tempo, anche quando si sa di un bug.

dai, che con il buono di 10$ di uber eats si sistema tutto!

Boia cosa hai tirato fuori, la peggior web application che abbia mai visto.

Come ha detto @destroyer85, l'automazione non è il problema.
@Tasslehoff
Non è una supercazzola. Perdonami, in quali settori un (umile) programmatore non dovrebbe mettere il naso? O il becco? Dovremmo tornare a qualche anno fa, dove prima di fare un deploy in produzione bisognava chiedere ai sistemisti di aprire l'accesso al server? Noi abbiamo adottato un sistema per l'automazione di diversi passaggi: nuovo codice; build; deploy. Capitano degli errori? Certo, ma prima di mandare in produzione c'è un sistema di test che verifica che le cose funzionino. Se non lo fanno, non viene fatto nessun deploy.

L'automazione è un aiuto enorme perchè solleva diverse persone da compiti che fino a qualche tempo fa richiedevano l'intervento umano.

È una supercazzola, come dici tu, quando viene presa e adottata senza aver messo in atto tutti i passaggi che garantiscono un rilascio corretto. Ed è esattamente quello che hanno fatto qua: hanno cambiato qualcosa; hanno una pipeline dove ci sono pochi (o forse anche nessun test) su un sistema che simula l'ambiente di produzione; hanno fatto un deploy; boom.

Ogni innovazione nel mondo del software porta con se dei benefici, ma solo se usata nel modo corretto. E nell'ambito corretto. Se così non fosse saremmo ancora a scrivere codice macchina sulle schede perforate.

È anche vero che innovare costa, e farlo correttamente costa molto di più di quanto ci si aspetta. A volte così tanto che o si lasciano pezzi per strada (con rischi, a volte non calcolati), o non si innova. Ma non innovare mai costa, con il tempo, molto di più che farlo bene una tantum.