GitHubs driftstopp: en fördubblad commit-belastning

Sju Timmar Och Fyrtiosju Minuter, Spårat Till En Överbelastad Proxy

GitHubs egen rapport, publicerad på företagets egen ingenjörsblogg under titeln 'The August 17 outage, and the work ahead', spårar avbrottet till en Istio-sidecarproxy i datacentret Central US som nådde sin maximala samtidiga bearbetningskapacitet. Autoskalningspolicyn som övervakade den kapaciteten utvärderade bara själva applikationstjänsten, inte anslutnings- och samtidighetstillståndet för sidecarerna framför den, så ingenting skalades upp när sidecarerna nådde sin gräns. När de proxyservrarna mättades flyttades förfrågningar till andra noder, som i sin tur nådde sina egna kapacitetstak, och GitHubs automatiska omförsökslogik förvärrade spiralen genom att skicka nya förfrågningar mot lastbalanserare som redan var överbelastade. En separat omförsöksbugg, enligt The Register belägen i en VS Code-tillägg som används för GitHub Copilot-autentisering, förvärrade avbrottet ytterligare: den fortsatte att begära nya autentiseringstoken utan paus och drev GitHubs tokenutfärdandetjänst från en normal baslinje på 7 000 till 9 000 förfrågningar per sekund upp till 70 000 till 100 000 förfrågningar per sekund, ungefär tio gånger den vanliga belastningen.

Siffrorna Bakom En Dålig Eftermiddag

Avbrottet pågick från den 17 augusti 2026, från klockan 13:28 till 21:15 UTC, och GitHubs egna statusuppdateringar satte de högsta felfrekvenserna till omkring 20 procent för webb- och API-trafik och cirka 50 procent för nedladdningar av arkiv och rått innehåll, precis den typ av förfrågan som en byggpipeline eller en beroendehämtning är beroende av. Issues, pull requests, API:er, Actions och Copilot var alla nedsatta, tillsammans med SAML- och OIDC-autentisering, SCIM och Team Sync; de flesta tjänster återhämtade sig omkring klockan 16:36 UTC, Actions omkring klockan 18:03 UTC, och Copilot-tokentjänsten sist, klockan 21:02 UTC. GitHub var tydligt med att varken denna incident eller det mindre Actions-avbrottet den 6 augusti orsakades av en kod- eller konfigurationsändring; båda var, med företagets egna ord, i grunden kapacitetsfel, det vill säga att systemet fick slut på marginal i stället för att gå sönder på grund av en utskickad bugg.

Commit-volymen Har Nästan Fördubblats På Fyra Månader

Gömt i samma rapport finns siffran som förvandlar den här historien om ett avbrott till en historia om infrastruktur: GitHub uppger att den månatliga commit-volymen har vuxit från 1,4 till 2,9 miljarder sedan april 2026, alltså praktiskt taget fördubblad på omkring fyra månader, tillsammans med diagram som visar sammanslagna pull requests närma sig 130 miljoner i månaden och nya repositories närma sig 24 miljoner i månaden. GitHub hade redan pekat ut orsaken i sin tillgänglighetsrapport från maj 2026, där företaget medgav att AI-understödd programmering och agentiska arbetsflöden lade extra press på infrastrukturen, och Microsoft har offentligt uppgett att AI numera skriver upp till 30 procent av koden i vissa av sina egna repositories, med förbehåll för mänsklig granskning. En plattform som var dimensionerad för en värld där commits kom in i mänskligt skrivtempo absorberar nu ett belastningsmönster som dikteras av kodningsagenter som skriver, grenar och pushar löpande, och GitHubs svar hittills har varit att lägga till kapacitet: över 3 miljoner CPU-kärnor och 120 petabyte höghastighetslagring, där Azure numera bär omkring 58 procent av plattformsbelastningen, mot 12 procent i maj.

GitHub Actions Registrerade Tretton Incidenter På Sjutton Dagar

Tech Times, som analyserade GitHubs incidenthistorik och statusdata, rapporterade att GitHub Actions ensamt registrerade 13 separata incidenter under en period på 17 dagar i augusti, och att drifttiden över 90 dagar sjönk från 99,39 procent före avbrottet den 17 augusti till 99,33 procent efteråt, en nedgång från omkring 13 timmars ackumulerad drifttidsförlust på tre månader till cirka 14,5 timmar. Mediet framställde incidenten den 17 augusti som att den ensam förbrukat nästan en hel årsbudget av tillåten drifttidsförlust mot ett mål om tre nior. GitHubs egen rapport räknar annorlunda och kallar den 17 augusti sin andra betydande incident under månaden efter Actions-avbrottet den 6 augusti, en rimlig räkning av stora, plattformsomfattande avbrott, men som inte säger något om de mindre, tätare Actions-störningarna därunder. Båda räkningarna kan vara sanna samtidigt, och tillsammans beskriver de ett tillförlitlighetsproblem i två lager: kärntjänsten för Git klarar sig bättre än CI/CD-pipelinen byggd ovanpå den, och det är just den pipelinen som bär den största delen av den nya belastningen från AI-understödd utveckling.

En Plattform, Varje Pipeline: Koncentrationsrisken

För ett företag som kör hela sitt tekniska arbetsflöde via GitHub, det vill säga versionskontroll, CI via Actions, sitt eget paketregister och Copilot för kodgenerering, är inget av det bakgrundsbrus; det är en enda leverantör placerad på den kritiska vägen för varje release. Ett europeiskt utvecklingsteam känner av detta precis som ett amerikanskt team gör under själva avbrottsfönstret, men bär ett extra lager av exponering: avtalade leveransdatum, SLA-åtaganden mot EU-kunder och incidentrapporteringsskyldigheter under regelverk som NIS2 pausar inte för att avbrottet uppstod i ett amerikanskt datacenter utanför teamets kontroll. Att behandla 'GitHub är nere' som bakgrundsbrus slutar att vara vettigt så snart de underliggande siffrorna visar varför det hände: infrastruktur byggd för en långsammare, mänskligt taktad värld absorberar nu ett belastningsmönster som nästan fördubblats på fyra månader, på en plattform som, enligt egen utsago, tillbringat augusti med att åtgärda samma kategori av kapacitetsfel två gånger.

Så Ser Redundans Ut I Praktiken

Inget av detta talar för att överge GitHub, som förblir standardvalet av goda skäl, men det är ett konkret argument för att behandla beroendet av en enda leverantör som en planerad risk snarare än en eftertanke som upptäcks mitt i ett avbrott. Det betyder en spegelkopia av kritiska repositories på en andra värd eller en självhostad Git-server, en alternativ CI-runner-konfiguration som kan ta över builds när Actions är nedsatt och inte bara när det är helt nere, samt en lokal eller självhostad cache för paketberoenden, så att ett avbrott i registret inte stoppar varje build i pipelinen. Ingen av dessa åtgärder behöver köra kontinuerligt; de måste finnas, testas då och då och vara tillräckligt väl dokumenterade för att ett team under press vid nästa incident inte improviserar en lösning för första gången medan klockan för en kunddeadline fortsätter att ticka.

Läs vidare: Din Andra Git-Värd Slog På Sig Själv  |  Irland stoppar sitt Microsoft-avtal