GitHub wijt storing van bijna acht uur aan autoscaling en een retry-bug in VS Code

GitHub wijt de storing van 17 augustus aan een verkeerd ingestelde autoscaling in het datacenter in Central US en een sluimerende retry-bug in Visual Studio Code, die het tokenverkeer van Copilot ongeveer vertienvoudigde. Het incident duurde 7 uur en 47 minuten. Toen API Requests, Issues, Pull Requests, Actions en Copilot die middag tegelijk op major outage gingen, had het bedrijf nog geen oorzaak.

Twee dingen in dat rapport raken iedereen die software laat bouwen. De versterker zat niet in de infrastructuur van GitHub maar in de editor op de laptops van ontwikkelaars: een mislukte tokenaanvraag kon een stortvloed aan nieuwe aanvragen uitlokken. En Europese klanten met data residency ontkwamen er niet aan, omdat hun Actions-workflows publieke stapdefinities ophalen die op GitHub.com staan. Waar je data staat, bepaalt dus niet waaraan je pijplijn hangt.

Een sidecar die niet meegroeide

De directe oorzaak was netwerkverzadiging op de loadbalancers in Central US, na een nieuwe piek in het verkeer. Daaronder zat een Istio-sidecar die zijn gelijktijdigheidslimiet raakte en niet automatisch opschaalde. De schaalregel keek naar de capaciteit van de hostdienst en niet naar de limieten van de sidecar zelf.

Vanaf daar liep het door. Vier HAProxy-knooppunten raakten door hun flow-limieten heen, waardoor de authenticatieroute in de gateway degradeerde en inloggen op grote schaal traag werd of mislukte. Optimistische retry-logica trok de interne loadbalancers verder vol. Pas toen HAProxy op die knooppunten tegelijk werd gepauzeerd, herstelde het beeld meteen. Op het hoogtepunt lag het foutpercentage rond 20 procent op web- en API-verkeer en rond 50 procent op archief- en ruwe bestandsdownloads.

De retry-lus in VS Code die het herstel uren vertraagde

Een deel van het falende verkeer werd verplaatst naar Northern Virginia. Daar ontstond het tweede probleem: vertraagde antwoorden van één intern eindpunt activeerden een sluimerende retry-bug in Visual Studio Code. Een mislukte tokenoperatie kon veel extra aanvragen genereren en in een lus belanden. Het verkeer naar de Copilot Token Service ging van normaal 7.000 tot 9.000 aanvragen per seconde naar 70.000 tot 100.000.

GitHub kreeg dat pas stil door de retries in de gateway te verminderen en inkomende tokenaanvragen op de loadbalancers met een 403 te blokkeren, om het verkeer daarna per locatie stapsgewijs weer op te voeren. Dat is waarom Copilot uren later herstelde dan de rest: het merendeel van de diensten was om 16.36 UTC terug, Actions bleef verstoord tot ongeveer 18.03 UTC en de Copilot Token Service was pas om 21.02 UTC volledig in orde. Om 21.15 UTC ging het incident dicht. De fout in de editor liet de storing verder escaleren, constateert Techzine.

Een complicerende factor bij het herstel noemt GitHub apart: een reeks scraping-aanvallen op de codeload-endpoints, precies de route waarlangs builds archieven en ruwe bestanden ophalen. Dat past in een bredere verschuiving, want geautomatiseerd verkeer heeft het menselijke verkeer op internet inmiddels ingehaald.

Vijf maatregelen, drie daarvan over retries

GitHub noemt vijf vervolgacties. De schaalregels worden gecorrigeerd zodat ze de gelijktijdigheid en capaciteit van service-mesh-sidecars meenemen. De Istio-limieten voor verzoeken, gelijktijdigheid en schaling worden bij de geraakte diensten doorgelicht. De retry-limieten en het backoff-gedrag in gateways en clients worden herzien. Het retry-gedrag van VS Code wordt aangepakt. En de capaciteitsbewaking van de loadbalancers en de regionale failover worden verbeterd.

Drie van die vijf gaan over retry-gedrag en niet over capaciteit. Daarmee verschuift de diagnose van een klassieke storing. De piek in het verkeer was het begin, maar wat er bijna acht uur van maakte, waren de clients die op elke fout harder gingen kloppen. Inmiddels draait op vrijwel elke ontwikkelaarslaptop een assistent die voortdurend tokens ververst en opnieuw probeert. Wat bij 9.000 aanvragen per seconde onschuldige retry-logica heet, is bij 100.000 de storing zelf. De vraag voor je eigen koppelingen en pijplijnen is daarmee niet of een leverancier omvalt, maar wat jouw code doet op het moment dat hij hapert.