Een verkeerd parameter gebruikte commando was voldoende om in 2017 een van de meest gedenkwaardige uitvalmomenten van Amazon Web Services (AWS) te veroorzaken. Amazon S3 verloor een aanzienlijk deel van haar capaciteit in us-east-1, moest twee subsystemen herstarten en sleepte andere diensten mee in de problemen. Deze casus is bijzonder leerzaam voor sysadmins en ontwikkelaars omdat het geen uitzonderlijk incident was: GitLab, Meta, Cloudflare, Fastly en Atlassian hebben allemaal documentatie over incidenten waarin geautoriseerde commands, scripts, configuraties of code enorme stilstanden veroorzaakten.
De sleutels tot de fouten die grote platforms binnen 30 seconden hadden kunnen breken
- In 2017 verwijderde AWS te veel servers van S3 door een verkeerd ingevoerde parameter en moest twee subsystemen herstarten.
- GitLab verwijderde per ongeluk de hoofddatabasedirectorie in datzelfde jaar en verloor uren aan gegevens.
- Een reguliere expressie overbelaste de CPU’s van Cloudflare in 2019.
- Meta zette in 2021 tijdens een onderhoudsbeurt per ongeluk haar wereldwijde backbone uit.
- Fastly en Atlassian tonen aan dat zelfs een geldige configuratie of een geautoriseerd script verrassende impact kan hebben.
De S3-zaak is bijzonder illustratief omdat AWS er vrij gedetailleerd over heeft uitgelegd wat er gebeurde. Om 09:37 Pacific Time op 28 februari 2017 voerde een bevoegde medewerker een standaard procedure uit om enkele servers eruit te halen terwijl hij een probleem met het factureringssysteem onderzoekt. Eén van de waarden die hij invoerde, was verkeerd, waardoor veel meer servers werden verwijderd dan gepland.
Het probleem raakte de indexerings- en locatie subsystemen van S3. Het eerste beheerde de metadata en informatie over waar de objecten opgeslagen waren; het tweede regelde de toewijzing van nieuwe opslag. Beide systemen vereisten een volledige herstart.
Daar kwam een tweede probleem bij kijken dat bekend is bij infrastructuren die jarenlang groeien: deze grote subsystemen waren al jaren niet meer volledig herstart. S3 was enorm in omvang toegenomen en de controleprocedures om de hele platform weer volledig operationeel te krijgen, duurden langer dan gepland.
AWS S3 en de kosten van teveel macht geven aan een commando
AWS begon om 12:26 met het herstellen van de GET, LIST en DELETE-operaties. Het indexeringssubsyteem was om 13:18 helemaal hersteld en de PUT-operaties, afhankelijk van het locatiesysteem, werkten weer normaal vanaf 13:54. Andere services hadden meer tijd nodig om de achterstand in te halen.
Het bedrag van ongeveer 150 miljoen dollar, dat vaak wordt genoemd bij het incident, verdient een belangrijke nuance. Dit was geen officieel verlies dat Amazon heeft gemeld.
Het risico-modelbedrijf Cyence schatte dat er ongeveer 150 miljoen dollar verlies was voor bedrijven uit de S&P 500 en nog eens 160 miljoen voor Amerikaanse financiële instellingen. Het betreft inschattingen van de economische impact, geen factuur van AWS noch een geaudit bedrag van de verliezen van Amazon.
Wat voor technisch team nog boeiender was, is wat AWS nadien veranderde.
De tool die capaciteit kon verwijderen, bleek te veel servers tegelijk te kunnen verwijderen. Amazon paste de werking ervan aan om die operaties te vertragen en voegde limieten toe die voorkwamen dat een subsystem onder de minimale operationele capaciteit viel.
Het is een bijna perfect voorbeeld van een guardrail.
De oplossing was niet enkel de operator te adviseren de volgende keer beter te controleren. AWS modificeerde het systeem zodanig dat een vergelijkbare menselijke fout niet hetzelfde resultaat kon veroorzaken.
Ook versnelde Amazon de opsplitsing van S3 in kleinere eenheden, genaamd cells. Het doel was de blast radius te verkleinen: als een deel faalt, kunnen herstel en impact beperkt blijven tot een fractie van het systeem.
Zelfs het systeem dat het incident rapporteerde, werd aangepast. De beheerconsole van de Service Health Dashboard was afhankelijk van S3; daardoor kon AWS de status niet tijdig standaard bijwerken tot 11:37. Na het incident verhuisde Amazon die managementlaag naar een gedistribueerde architectuur over meerdere regio’s.
De menselijke fout had meerdere afhankelijkheden blootgelegd die tot dan toe als losstaand redelijk waren beoordeeld.
En AWS is zeker niet het enige voorbeeld.
Zes incidenten die elke sysadmin moet kennen
De post-mortem-rapporten van grote bedrijven tonen een kleine collectie van fouten met gemeenschappelijke kenmerken: de initiële actie leek veel minder gevaarlijk dan haar consequenties.
| Incident | Oorzaak | Gedocumenteerde impact | Technische les |
|---|---|---|---|
| AWS S3, 2017 | Verkeerde parameter in een tool voor serververwijdering | S3 us-east-1 en afhankelijke services urenlang uitgeschakeld | Strikte limieten voor destructieve operaties en vermindering van blast radius |
| GitLab, 2017 | Per ongeluk verwijderen van de hoofddatabasedirectorie | GitLab.com 18 uur offline en verlies van enkele uren aan databasemutaties | Een niet-herstelbare en onaangetoonde backup vormt geen goede recovery-strategie |
| Cloudflare, 2019 | Een regex in de WAF veroorzaakte grootschalig backtracking | CPU’s bijna volledig overbelast, errors 502; het verkeer daalde met 82% | CI/CD moet resourcegebruik controleren en geleidelijke uitrol toepassen |
| Meta, 2021 | Een onderhoudsopdracht deactiveerde onbedoeld de wereldwijde backbone | Facebook en andere diensten onbereikbaar wereldwijd; DNS en interne tools beïnvloed | Validatie van commando’s moet ook falen kunnen voorkomen |
| Fastly, 2021 | Een geldige configuratie van een klant activeerde een verborgen bug | 85% van het netwerk gaf fouten; 95% herstelde binnen 49 minuten | Een geldige invoer kan een ongecontroleerde toestand activeren die tests niet voorzagen |
| Atlassian, 2022 | Een onderhoudsscript kreeg een onjuiste lijst van IDs | 883 sites verwijderd, 775 klanten getroffen, sommigen tot 14 dagen zonder volledige service | Automatisering van destructieve operaties vereist validatie, observatie en geteste recovery |
De tabel ontmaskert ook de geruststellende gedachte dat dergelijke uitval simpelweg door ‘iemand die zich vergist’ ontstaat.
In GitLab bijvoorbeeld, verwijderde een engineer per ongeluk de hoofddata directory van de PostgreSQL server terwijl hij een secundair wilde reconstrueren. Maar het post-mortem toonde een veel complexere keten van problemen aan.
GitLab schatte dat ze wijzigingen verloren die betrekking hadden op ongeveer 5.000 projecten, 5.000 opmerkingen en 700 nieuwe accounts. De Git-repositories en wiki’s werden niet aangetast omdat die op een andere locatie waren opgeslagen. Het systeem was ongeveer 18 uur niet operationeel.
Het incident testte ook de backups en herstelprocedures. De menselijke fout was slechts het laatste knelpunt in een veel langere operationele keten.
Cloudflare geeft een nog dichterbij-ontwikkelvoorbeeld.
In juli 2019 werd een nieuwe regel geïntroduceerd voor haar Web Application Firewall (WAF), waarin een regex de enorme hoeveelheid backtracking veroorzaakte. Het gevolg was dat de CPU’s voor HTTP(S)-verkeer bijna 100% werden belast binnen het hele netwerk.
Op het ergste moment daalde het verkeer met maar liefst 82%.
Wat opvallend is, is dat de wijziging volgens de gebruikelijke procedure verliep: pull request, goedkeuring, continuous integration, testen en uitrol.
De tests controleerden of het WAF de juiste verzoeken detecteerde, maar controleerden niet of een regel de CPU-belasting kon verhogen. En de regels konden binnen seconden wereldwijd uitgerold worden.
Het pipeline had de status groen en toch viel de productie uit.
Cloudflare reageerde door prestatiprofiling toe te voegen aan testen, geleidelijke uitrol en aanpassingen aan de regex-engine, onder andere maatregelen.
Wanneer de fout ook de tools om te herstellen vernietigt
Meta bracht dit probleem in oktober 2021 naar een nog grotere schaal.
Tijdens regulier onderhoud werd een commando uitgevoerd om de beschikbaarheid van haar backbone te testen. Dit commando verstoorde onbedoeld de verbindingen binnen dat wereldwijde netwerk.
Er was een systeem ontworpen om precies dit soort commando’s te auditen en gevaarlijke fouten te blokkeren. Maar een bug in die audittool voorkwam dat het commando kon worden gestopt.
Het probleem leidde ertoe dat Meta haar Border Gateway Protocol (BGP)-verbindingen voor DNS verwijderde. De servers konden blijven werken, maar de rest van het internet kon de diensten niet meer vinden.
Verder werd het nog ingewikkelder doordat ook interne tools voor diagnose uitvallen. Ingenieurs moesten fysiek naar datacenters reizen om bepaalde systemen te herstellen.
Dit is dezelfde cyclische afhankelijkheid die AWS vier jaar eerder al had ontdekt met haar statuspagina.
Herstelketens zouden niet louter afhankelijk moeten zijn van de systemen die ze proberen te herstellen.
Fastly gaf een ander voorbeeld in juni 2021.
Op 12 mei had het bedrijf een bug geïntroduceerd die weken verborgen bleef. Op 8 juni voerde een klant een volledig geldige configuratiewijziging door die de omstandigheden schepten om het te activeren.
Zo begon 85% van het Fastly-netwerk foutmeldingen te geven.
De monitoring detecteerde de storing binnen ongeveer een minuut. Fastly identificeerde de trigger-configuratie en, na 49 minuten, functioneerde 95% van het netwerk weer normaal.
Hier was niet eens per se een operator die iets verkeerd had gedaan.
De configuratie was geldig.
De software was niet voorbereid op die configuratie.
Atlassian toont mogelijk het meest verontrustende voorbeeld voor iedereen die interne scripts beheert.
In april 2022 voerde het bedrijf een script uit om oude applicaties te verwijderen. Door datagedoelen te verkeerd te interpreteren, maakten ze 883 klantenwebsites onbedoeld kapot. Later werd bevestigd dat 775 klanten getroffen waren.
Het script verwijderde de sites sequentieel zonder direct een waarschuwingssignaal te geven.
Jira, Confluence, Atlassian Access, Opsgenie en Statuspage werden voor die klanten ontoegankelijk. Sommigen moesten wel 14 dagen wachten op volledige herstel van de diensten.
De les: het is niet verstandig om gewoon productie te verbieden
Deze incidenten wijzen op een veel nuttigere conclusie dan simpelweg ‘mensen maken fouten’:
Systemen moeten zo ontworpen worden dat men ervan uitgaat dat op een dag een beheerder een verkeerde parameter invoert, een ontwikkelaar een problematische regex schrijft, een script onjuiste gegevens ontvangt of een ogenschijnlijk geldige configuratie een nog niet geteste combinatie activeert.
Dit verandert de manier waarop je kritieke operaties ontwerpt.
Een rm, een BGP-wijziging of een massale verwijderactie mag niet dezelfde uitvoeringstroom volgen als een routine-operatie. Destructieve acties kunnen limieten krijgen, dry-run-opties, bevestigingsvragen, wachttijden en automatische mechanismen die staten blokkeren die niet voldoen aan de minimale operationele vereisten.
Ook hoeven updates niet meteen van 0 naar 100% uitgerold te worden.
Canary deployments, gefaseerde uitrol en feature flags maken het mogelijk om eerst kleine delen van het verkeer te testen voordat een wijziging wereldwijd wordt doorgevoerd. Cloudflare ontdekte in 2019 hoe belangrijk dat is, toen haar capaciteit om regels overal binnen seconden te distribueren, een technologische voorsprong veranderde in een incidentmultiplicator.
Backups verdienen dezelfde achterdocht.
Een taak die meldt backup succesvol voltooid, bewijst niet dat het systeem binnen de verwachte RTO (Recovery Time Objective) kan herstellen. GitLab toonde op de moeilijkste manier aan dat herstel ook onderdeel is van de backup.
En observatie moet blijven functioneren, zelfs als de dienst zelf niet meer werkt.
Statuspagina’s, noodkanalen, authenticatiesystemen en beheertools moeten elkaar ondersteunen via aparte paden, vooral als het verlies ervan bij een storing grote gevolgen kan hebben.
AWS, Meta en Cloudflare documenteerden incidenten waarbij hun eigen afhankelijkheden het diagnosticeren en herstellen bemoeilijkten.
De belangrijkste vraag vóór het uitvoeren van een kritieke operatie is niet enkel of het commando correct is.
Maar ook: wat zou er gebeuren als het commando onjuist bleek te zijn en waarom zou het systeem dat fout niet kunnen voorkomen of beperken in de productieomgeving.
Door dat perspectief te veranderen, wordt menselijke fout een vooraf ingecalculeerd onderdeel van het ontwerp.
Veelgestelde vragen
Was de uitval van Amazon S3 in 2017 te wijten aan een verkeerd geschreven commando?
AWS bevestigde dat een bevoegde medewerker per ongeluk een verkeerd parameter invoerde in een commando dat bedoeld was om enkele servers te verwijderen. Het gebruikte hulpmiddel verwijderde daardoor veel meer capaciteit dan gepland.
Heeft Amazon toen 150 miljoen dollar verloren door die uitval?
Dat klopt niet helemaal. Cyence schatte dat bedrijven uit de S&P 500 ongeveer 150 miljoen dollar verliezen leden, en nog eens 160 miljoen dollar voor Amerikaanse financiële bedrijven. Dit waren inschattingen, geen officieel door Amazon gemelde bedragen.
Wat was de belangrijkste verandering die AWS na dat incident doorvoerde?
AWS voegde limieten toe aan haar capaciteitverwijdertools om te voorkomen dat te veel capaciteit tegelijk werd verwijderd of dat een subsystem onder de minimale operationele capaciteit kwam. Ook versnelde ze de opsplitsing van S3 in kleinere cellen en verbeterde ze de infrastructuur van haar statuspagina.
Hoe voorkom je dat menselijke fouten leiden tot wereldwijde uitval?
Er bestaat niet één enkele oplossing. De gemelde gevallen laten zien dat het combineren van guardrails, minimale operationele limieten, dry-run-mogelijkheden, beperkte permissies, gefaseerde uitrol, recovery-tests, onafhankelijke observatie en het verkleinen van blast radius de risico’s significant verkleinen.