Lo scorso 28 febbraio una significativa porzione dei servizi cloud di Amazon (AWS) sono stati oggetto di un disservizio durato circa 5 ore (qui per alcuni dettagli). Non mi soffermo, ed accenno solo, alle ripercussioni di tale disservizio: il fermo dei servizi di moltissime aziende, con conseguenti danni per lo stop del lavoro e di immagine, ma anche conseguenze più curiose come l'impossibilità di accendere le lampadine "intelligenti" (a riprova di quanto già detto a proposito delle esagerazioni dell'"Internet delle cose"...). L'aspetto più interessante della vicenda è invece quello relativo alla spiegazione che Amazon ha fornito, insieme alle sue scuse: un errore umano (qui una fonte che rimanda anche al post ufficiale di Amazon).
La cosa è risultata particolarmente stimolante per me che in passato ricoprivo un ruolo simile a quello del poveretto che ha materialmente commesso l'errore, ed ora invece ricopro il ruolo di colui che deve assicurarsi che queste cose non accadano. Infatti, non ho potuto fare a meno di pensare ad una scena, che è totalmente frutto della mia immaginazione, ma che potrebbe essere verosimile: il tecnico è alle prese con un malfunzionamento (alcuni dei server sono lenti), segue la procedura per casi come questi, cioè escluderli dal cluster per poi indagare meglio o riavviarli, eseguendo un comando che potrebbe suonare più o meno così:
put-offline server 3-6
cioè: metti off-line (fuori linea) i server dal 3 al 6; solo che ha fretta, e nella concitazione preme il pulsante 6 insieme a quello 7 (a chi non è mai successo di premere 2 pulsanti insieme) e immediatamente dopo, senza rendersene conto, l'invio: e invece di togliere dal cluster 4 server, ne toglie 65! Al che non è difficile comprendere come mai tutti quei servizi sono andati in tilt...
Amazon correttamente dice di aver modificato i suoi sistemi, praticamente aggiungendo un controllo che limiti il numero di server che è possibile mandare offline con un solo comando, o qualcosa del genere.
Il mio giudizio in sintesi: quello che è successo non peggiora assolutamente la mia opinione su Amazon come fornitore di servizi cloud; né la sua soluzione fa aumentare la mia fiducia sui servizi cloud in generale. Perché quello che è successo dimostra solo quello che tutti i veri informatici sanno: cioè che i peggiori disastri sono causati dall'uomo, semplicemente perché l'uomo non è infallibile.
Tutti i sistemi informatici devono essere gestiti dall'uomo: per questo, esiste sempre il cosiddetto amministratore di sistema, cioè colui che ha potere assoluto su quel sistema, inclusa la possibilità di distruggerlo. Si suppone che costui sia sano di mente, fedele e motivato nel suo lavoro, capace ed attento. Ciò è probabilmente vero nel 99,9% dei casi, o del tempo; ma può sempre capitare il momento in cui si è stanchi, sotto pressione, o semplicemente disattenti. Nulla di diverso da quello che succede ai piloti di aerei: possono commettere errori per via della stanchezza, fino addirittura a far schiantare coscientemente l'aereo per problemi psicologici. D'altra parte, gli aerei si schiantano anche per guasti o malfunzionamenti che semplicemente non erano stati previsti, e che i test non avevano evidenziato. Nei sistemi informatici avviene la stessa cosa (per fortuna con conseguenze meno tragiche): possono andare in tilt per via di micro errori in fase di progettazione o realizzazione, e mai evidenziati dai test.
In ogni caso, l'importante è che dagli episodi del genere si traggano le corrette indicazioni e si prendano le necessarie contromisure, così che almeno quel tipo di incidente non avvenga più. Modificare un sistema aumentando i controlli automatici per impedire le azioni dannose è sicuramente una buona pratica; un'altra è aumentare l'addestramento o la formazione (e questo è soprattutto vero per gli utenti dei sistemi, i cui imprevedibili errori sono forse meno dannosi, ma certamente rimangono gravi); non dimenticando quella che dovrebbe essere la più basilare delle contromisure, ossia dare al lavoratore le migliori condizioni possibili.
