Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Typfout in commando leidde tot grote storing Amazon S3 en downtime veel websites

De storing bij clouddienst Amazon S3 die downtime veroorzaakte bij veel Amerikaanse websites en diensten, kwam doordat een medewerker een typfout in een commando maakte. Daardoor haalde de Amazon-medewerker veel meer servers offline dan de bedoeling was.

Het is onbekend wat de typfout precies was, maar de medewerker wilde met het commando een paar servers offline halen voor het proces van in rekening brengen van S3-diensten, meldt Amazon. Door het commando verkeerd in te voeren, ging het index-subsystem offline. Dat is het systeem dat alle servers indexeert en dus de locatie en metadata bevat van alle S3-servers in de regio. Daardoor werd het onmogelijk om veel servers te gebruiken.

Het herstarten van het index-subsysteem was vrij snel gedaan, maar veel servers hadden inmiddels een backlog van requests en het duurde daardoor langer voordat alles weer normaal functioneerde. De storing vond dinsdagavond Nederlandse tijd plaats.

Door de storing waren veel Amerikaanse websites en diensten geheel of deels onbereikbaar. Veel sites en diensten gebruiken de diensten van Amazon. Onder andere Imgur, Medium, Slack, Yahoo webmail, Quora, Trello en Runkeeper ondervonden gevolgen van de problemen.

Amazon neemt diverse maatregelen om te zorgen dat de storing niet meer zal voorkomen. De belangrijkste daarvan is dat de tool die de medewerker gebruikte om enkele servers offline te halen niet meer in een keer de belangrijkste servers kan beheren. Ook wil Amazon zijn index-subsystem sneller kunnen herstarten.

Door Arnoud Wokke

Redacteur mobile

03-03-2017 • 07:42

118 Linkedin Google+

Submitter: HyperioN

Reacties (118)

Wijzig sortering
Het probleem was niet zo dat er iets te veel servers down gehaald werden, het probleem was dat de infra er blijkbaar niet goed reageerde terwijl dat wel de bedoeling had moeten zijn.
While this is an operation that we have relied on to maintain our systems since the launch of S3, we have not completely restarted the index subsystem or the placement subsystem in our larger regions for many years. S3 has experienced massive growth over the last several years and the process of restarting these services and running the necessary safety checks to validate the integrity of the metadata took longer than expected.
Heel kort door de bocht, er zouden minimaal 10 servers moeten zijn, en per ongeluk werd het aantal servers naar 5 gebracht. Het systeem zou dit weer gewoon naar 10 moeten brengen, maar dat ging niet zo goed als de keren dat het van 8 naar 10 moest gaan.
Nu gaan ze hun tooling aanpassen dat je niet meer het aantal servers onder 8 kan krijgen. Maar ze moeten nog steeds het probleem in recovery fixen waarvan ze niet op de hoogte waren.
Apple heeft zijn diensten draaien bij Amazon, Azure maar ook Google Cloud (Bron) maar is ook erg bezig om met eigen datacenter te bouwen zodat ze niet afhankelijk zijn van Amazon, Azure en Google Cloud. De twee datacenters komen in elk geval in Europa en zouden dit jaar waarschijnlijk in gebruik genomen worden.

Wat ik uit de verhalen heb begrepen is dat ze met name niet tevreden zijn over de snelheid van de huidige clouddiensten. Ook willen ze het aantal storing hiermee omlaag brengen.

Bron 1
Bron 2
Bron 3
Nee Nee Nee erg lullig voor die medewerker. Shit happens.

Typisch voorbeeld van slechte impact analyse. Als de impact juist was bepaald had men geweten wat de gevolgen hadden kunnen zijn van een typo. Een public cloud provider van deze omvang kan het zich niet veroorloven om dit soort fouten te maken. De downtijd is opgebruikt voor een periode van 3,5 jaar. Maw men heeft nu al in maart zoveel downtijd gehad dat ze de komende 3,5 jaar niks meer mogen laten uitvallen (S3). Overigens wordt S3 als 4 digit available 99,99 verkocht. Hier zie je overigens wel heel duidelijk het verschil. Bij traditionele IT bedrijven spreekt men van penalties die al gelijk in 10Ks kunnen lopen. Hier spreekt men van service credits wat discount is op de servicekosten van S3. Das nogal een verschil. Amazon kan dus gewoon besluiten heel de flikkerseboel te upgraden tegen een discount van 10 - 20% op de servicekosten van die maand. Weet dat iedereen die naar de cloud gaat? Nee geloof ik niks van.

Edit (bij dit soort constructies is de SLA voor veel bedrijven waardeloos. De SLA beschrijft de discount na een lagere score dan 99.0% uptime van 25%. In theorie kan het zo zijn dat ze zelfs 32% outage hebben, 2 dagen in de week dus, je toch maar 25% discount krijgt op het S3 tarief. Das toch bizar dat men dat pikt?)

Anyway dit had gewoon voorkomen kunnen worden door de change met een hogere impact te classificeren met daarbij standaard een 4 of 6 ogen procedure. Gaat het dan nog fout dan zijn de mensen niet geschikt.

[Reactie gewijzigd door InsanelyHack op 3 maart 2017 12:05]

Anyway dit had gewoon voorkomen kunnen worden door de change met een hogere impact te classificeren met daarbij standaard een 4 of 6 ogen procedure. Gaat het dan nog fout dan zijn de mensen niet geschikt.
Sommige fouten kun je gewoon niet voorzien, ongeacht het aantal ogen dat je er op zet of hoe hoog de classificatie ook is of hoe vaak je van tevoren ook hebt getest en hoe capabel de mensen ook zijn. Shit happens.

Wat er in mijn mening echt toe doet is hoe men met fouten omgaat en hoe men gaat voorkomen dat dit nogmaals optreedt.
Alleen in een omgeving die er niet toedoet worden nooit fouten gemaakt die impact hebben.

Bij dit soort incidenten is het belangrijk om drie kanten op te kijken:
1. wat zijn de factoren die tot de handeling leidden (kan dat anders)
2. wat had dit kunnen voorkomen in de uitvoering
3. Wat kan in geval van dit incident helpen met sneller herstel of reductie van impact.

Maar dan nog hoor. Heb het overal gezien, van superprofessioneel tot cowboy-bedrijf: fouten worden gemaakt. Van juniors die met te weinig ondersteuning een te zware taak moeten doen, tot een zeer professioneel beheerteam dat ondanks onderhoudsdraaiboek en stappenplan en gedetailleerde planning beide poten van een dubbel uitgevoerde High-Available omgeving weet down te krijgen.

Belangrijkste is dat een organisatie er vervolgens open voor staat om er van te leren, in plaats van hard te schreeuwen en het onderliggende probleem niet aan te pakken. Dat zijn de organisaties waarbij het maar zelden voorkomt versus de organisaties "Schering&Inslag".
Het laat natuurlijk wel zien dat de hele infrastructuur eigenlijk gewoon een kaartenhuis huis.
Welke infrastructuur is dat niet?
1 defecte trein en half NL heeft vertraging, 1 zwaar ongeluk en je komt niet meer in/uit een stad en 1 keer noodweer en Europa heeft een tekort aan groente.

De gemiddelde IT infrastructuur is 10x robuuster dan praktisch elk ander aspect van een gemiddeld bedrijf. Welk bedrijf heeft een 2de kantoor volledig ingericht en draaiend om direct te kunnen 'switchen'. Of die mensen die 'onmisbaar' zijn in de organisatie hebben een fail-over (iemand die alleen maar 'erachteraan loopt'?
Het lastige is dat veel in IT land bestaat uit 'de enige'. De enige database voor de planning van een transportbedrijf, terwijl 1000 vrachtwagens rondrijden. De betrouwbaarheid van die database is waarschijnlijk geweldig als je die vergelijkt met hoeveel 'downtime' en 'gepland onderhoud' de vloot vrachtwagens heeft, echter is er geen alternatief als het misgaat.

Maar goed, zo kon ik laatst HR niet bereiken vanwege een 'field day' en regelmatig is er niemand te bereiken, maar het wel compleet onacceptabel vinden als het HR systeem een storing heeft... Volgens mij heeft HR vaker 'storing' dan hun systeem :+

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True