Test per prevenire errori di cascata

Senza conoscere le specifiche del problema (e sarebbe istruttivo per tutti noi se Twitter potesse fornire maggiori informazioni su questo, anche se capisco perché non lo farebbero) Immagino che sia uno di quei problemi di tornado-farfalla che sono quasi impossibile da prevedere e che si manifestano solo in una situazione reale, in cui si dispone di un numero realistico di utenti e configurazioni.

Sì, i test di integrazione dovrebbero averlo trovato, e immagino che Twitter abbia un "laboratorio di prova" in cui simula milioni di utenti simultanei che inviano messaggi. Tuttavia, alcune configurazioni particolari, alcune impostazioni strane, alcuni eventi casuali di eventi a mala pena interconnessi, hanno contribuito a creare un problema.

Penso che Twitter abbia mostrato la sua maturità immediatamente tornando indietro, e non tentando di uscire dal problema, come alcuni potrebbero essere stati tentati di fare.

Penso che l'unica cosa che puoi veramente fare da cose come questa sia imparare da loro - per rendere i test di integrazione migliori, se possibile. Non penso che, in generale, ci sia qualcosa che non hanno fatto che avrebbero potuto fare.

Sono nel Regno Unito e attualmente sto assistendo agli effetti di un bug in cascata su NatWest , una delle più grandi banche qui. Ora, il software bancario è veramente ben testato, eppure questi bug si verificano ancora.

Penso che, alla fine della giornata, facciamo il meglio che possiamo con i migliori strumenti e pratiche che conosciamo, ma il software è una cosa complessa e complicata, e a volte capiteranno bug. Come ci comportiamo con loro quando (non se) accadono definisce la nostra competenza come ingegneri.

Amico, non temere la [Chaos Monkey]! - Bill S. Preston, Esq.

Seriamente, come Netflix , Amazon} Servizi Web , Twitter e altri trovati fuori, questi problemi sorgono spontaneamente in sistemi complessi. C'è qualche ricerca che suggerisce che è impossibile sapere con certezza che tali problemi non esistono ( ie , che sono simili a Arresto del problema ). L'unica "best practice" sembra essere quella di colpire casualmente le parti offline frequentemente, e assicurarsi che il sistema nel suo insieme continui a funzionare. All'inizio è doloroso, ed è meglio farlo su sistemi di non-produzione finché non hai capito come gestire molti dei fallimenti risultanti, ma sembra funzionare. Netflix chiama lo strumento che fa questo sul proprio sistema "the Chaos Monkey": -)

Direi che è sia un sottoprodotto di sistemi software complessi che indica una rottura nel processo di sviluppo del software. Questi due stati non si escludono a vicenda.

La programmazione difensiva è il termine generico per aiutare a prevenire questi tipi di bug. Alcune delle tecniche della programmazione concorrente e che non si fidano di nessuna variabile esterna (sto esagerando) sono anche utili.

Dalla mia esperienza, le recensioni dei codici a livello di sistema sono le migliori per cogliere questi tipi di problemi. Per "livello di sistema", intendo qualcuno che sta pensando all'intero sistema / modulo invece di solo il codice che è cambiato. In primo luogo, il revisore dovrebbe individuare quando una variabile / oggetto viene utilizzata in un modo che non è garantito per rimanere coerente. In secondo luogo, il revisore dovrebbe rilevare le situazioni in cui una variabile è impostata per essere utilizzata in quella situazione. Il primo è più facile da individuare rispetto al secondo. Entrambi richiedono un revisore esperto che comprenda i moduli in questione.

Sospetto che il codice in questione non sia stato coperto dai test unitari. (o almeno non adeguatamente). Buoni test unitari coprono le eccezioni di gestione con garbo e condizioni normali.