Disservizio di Amazon Web Services: la causa è un errore umano

Disservizio di Amazon Web Services: la causa è un errore umano

Un comando impartito male ha mandato offline un numero di server maggiore del previsto durante un intervento di debug. La società si scusa e modifica alcune pratiche operative per evitare il ripetersi dell'errore in futuro

di pubblicata il , alle 17:15 nel canale Web
Amazon
 

Amazon Web Services ha fatto sapere che il disservizio dei giorni scorsi che ha compromesso l'operatività di vari siti web è stato causato da un errore umano. Nessun attaco, quindi, nessuna "prova di tenuta" andata male: un semplice comando impartito male.

"Siamo orgogliosi del nostro lungo record di disponibilità di Amazon S3 e sappiamo quanto critico sia questo servizio per i nostri clienti, le loro applicazioni e gli utenti finali, e il loro business. Faremo tutto quello che possiamo per imparare da quanto accaduto, usando questo evento per migliorare ancor di più la nostra disponibilità" ha fatto sapere la società.

Questo quanto accaduto: il team di Amazon Simple Storage Service (S3) si stava occupando del debug di un problema che stava rallentando le operazioni del sistema di billing di S3. Alle ore 12:37 un membro autorizzato del team ha eseguito un comando allo scopo di rimuovere un piccolo numero di server per uno dei sottosistemi di S3 usati per il processo di billing. Uno dei comandi è stato inserito in maniera non corretta, causando quindi la rimozione di un numero di server significativamente maggiore di quanto voluto.

AWS specifica: "La rimozione di capacità è una pratica operativa chiave, ma in questo caso lo strumento utilizzato ci ha permesso di rimuovere troppa capacità in maniera troppo rapida. Abbiamo modificato lo strumento così da rimuovere capacità più lentamente e abbiamo aggiunto alcune misure di sicurezza per evitare di rimuovere capacità quando porterebbe qualsiasi sistema al di sotto dei requisiti minimi essenziali per il corretto funzionamento".

La società ha inoltre osservato che gli ingegneri stanno valutando altri strumenti operativi per assicurare che possano avere sistemi di sicurezza simili. "Stiamo inoltre apportando alcuni cambiamenti affinché sia possibile migliorare il tempo di recupero di sottosistemi S3 chiave" fa sapere la società, che si scusa per quanto causato nei giorni scorsi.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione

10 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
frankie03 Marzo 2017, 17:29 #1
Dumah Brazorf03 Marzo 2017, 17:52 #2
Basta mettersi davanti agli uffici del dipartimento IT e vedere chi esce con una scatola in grembo...
floc03 Marzo 2017, 19:04 #3
peggio di quando ho sbagliato finestra ssh e ho spento un server in olanda. Da allora coloro le shell diversamente
Gello04 Marzo 2017, 10:21 #4
Il tizio fra l'altro potrebbe essere stretto collega di un amico

Catitto Homo
aleforumista05 Marzo 2017, 18:06 #5
secondo me hanno fatto qualche rm -R
cignox106 Marzo 2017, 08:21 #6
Non vorrei essere nei panni di quel tipo, nel momento in cui si é accorto dell'errore...
Aquila della notte06 Marzo 2017, 08:53 #7
I problemi generati da un semplice e banale errore dovrebbero farci riflettere su quanto in realtà siamo dipendenti da tutto questo ambaradan [SIZE="1"](non me ne voglia l'utente ambaradan per aver preso in prestito il suo username )[/SIZE]
andbad06 Marzo 2017, 08:57 #8
Originariamente inviato da: floc
peggio di quando ho sbagliato finestra ssh e ho spento un server in olanda. Da allora coloro le shell diversamente


Questa è un'ottima idea. Se la uso, devo pagarti il copyright? (sai com'è, di questi tempo )

By(t)e
!fazz06 Marzo 2017, 10:04 #9
Originariamente inviato da: floc
peggio di quando ho sbagliato finestra ssh e ho spento un server in olanda. Da allora coloro le shell diversamente


capitato anche a me una cosa simile giusto un paio di giorni fa e ho spento l'host di esxi sbagliato tirando giù il sistema di produzione (non ancora attivo per fortuna) invece del sistema di test. per fortuna che esistono vpn e iDrac per riattivare tutto da remoto evitandomi una cinquantina di km

Originariamente inviato da: Gello
Il tizio fra l'altro potrebbe essere stretto collega di un amico

A prescindere dall'errore umano, quello che non e' accettabile per un provider del genere sono le tempistiche per il ripristino...


sulle tempistiche non è che ci sia tanto da fare, hanno iniziato le operazioni di ripristino subito essendosi accorti live dell'errore. il vero problema è che sistemi del genere sono talmente complessi che ci vuole tempo a ripristinare e riavviare in modo corretto tutto il cluster di server
fbryx06 Marzo 2017, 13:46 #10
Originariamente inviato da: Gello
Il tizio fra l'altro potrebbe essere stretto collega di un amico

Catitto Homo


non penso di essere d'accordo con questa affermazione

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^