GitHubs nedbrud: en fordoblet commit-belastning

Syv Timer Og Syvogfyrre Minutter, Sporet Til Én Overbelastet Proxy

GitHubs egen rapport, offentliggjort på virksomhedens engineering-blog under titlen 'The August 17 outage, and the work ahead', sporer nedbruddet til en Istio-sidecarproxy i datacentret Central US, som nåede sin maksimale samtidige behandlingskapacitet. Den autoscaling-politik, der overvågede den kapacitet, vurderede kun selve applikationstjenesten, ikke forbindelses- og samtidighedstilstanden for de sidecars, der lå foran den, så intet skalerede op, da sidecarserne ramte deres grænse. Da de proxyer blev mættet, flyttede forespørgsler sig til andre knuder, som til gengæld ramte deres egne kapacitetslofter, og GitHubs automatiske gentagelseslogik forværrede spiralen ved at sende nye forespørgsler mod load balancere, der allerede var overbelastede. En separat gentagelsesfejl, ifølge The Register placeret i en VS Code-udvidelse brugt til GitHub Copilot-godkendelse, forværrede nedbruddet yderligere: den blev ved med at anmode om nye godkendelsestokens uden pause og drev GitHubs tokenudstedelsestjeneste fra en normal basis på 7.000 til 9.000 forespørgsler i sekundet op til 70.000 til 100.000 forespørgsler i sekundet, cirka ti gange den sædvanlige belastning.

Tallene Bag En Dårlig Eftermiddag

Nedbruddet strakte sig fra den 17. august 2026, fra kl. 13:28 til 21:15 UTC, og GitHubs egne statusopdateringer satte de højeste fejlrater til omkring 20 procent for web- og API-trafik og cirka 50 procent for downloads af arkiver og råt indhold, netop den type forespørgsel, som en build-pipeline eller en dependency-hentning er afhængig af. Issues, pull requests, API'er, Actions og Copilot var alle nedsat, ligesom SAML- og OIDC-godkendelse, SCIM og Team Sync; de fleste tjenester genoprettedes omkring kl. 16:36 UTC, Actions omkring kl. 18:03 UTC, og Copilot-tokentjenesten sidst, kl. 21:02 UTC. GitHub gjorde det udtrykkeligt klart, at hverken denne hændelse eller det mindre Actions-nedbrud den 6. august skyldtes en ændring i kode eller konfiguration; begge var, i virksomhedens egne ord, i bund og grund kapacitetsfejl, altså at systemet løb tør for margin i stedet for at bryde sammen på grund af en udsendt fejl.

Commit-volumen Er Næsten Fordoblet På Fire Måneder

Gemt i den samme rapport findes det tal, der gør denne historie om et nedbrud til en historie om infrastruktur: GitHub oplyser, at det månedlige commit-volumen er vokset fra 1,4 til 2,9 milliarder siden april 2026, altså stort set fordoblet på omkring fire måneder, ledsaget af grafer, der viser sammenlagte pull requests nærme sig 130 millioner om måneden og nye repositories nærme sig 24 millioner om måneden. GitHub havde allerede peget på årsagen i sin tilgængelighedsrapport fra maj 2026, hvor virksomheden erkendte, at AI-understøttet programmering og agentiske arbejdsgange lagde ekstra pres på infrastrukturen, og Microsoft har offentligt oplyst, at AI nu skriver op til 30 procent af koden i nogle af selskabets egne repositories, med forbehold for menneskelig gennemgang. En platform, der var dimensioneret til en verden, hvor commits ankom i menneskeligt skrivetempo, absorberer nu et belastningsmønster dikteret af kodeagenter, der løbende skriver, forgrener og pusher, og GitHubs svar indtil videre har været at tilføje kapacitet: over 3 millioner CPU-kerner og 120 petabyte lagerplads med høj hastighed, hvor Azure nu bærer omkring 58 procent af platformbelastningen mod 12 procent i maj.

GitHub Actions Registrerede Tretten Hændelser På Sytten Dage

Tech Times, der analyserede GitHubs hændelseshistorik og statusdata, rapporterede, at GitHub Actions alene registrerede 13 separate hændelser inden for 17 dage i august, og at oppetiden over 90 dage faldt fra 99,39 procent før nedbruddet den 17. august til 99,33 procent bagefter, et fald fra omkring 13 timers akkumuleret nedetid over tre måneder til cirka 14,5 timer. Mediet fremstillede hændelsen den 17. august som alene ansvarlig for at have brugt næsten et helt års budget for tilladt nedetid mod et mål om tre ni-taller. GitHubs egen rapport tæller anderledes og kalder den 17. august sin anden betydelige hændelse på måneden efter Actions-nedbruddet den 6. august, en rimelig optælling af store, platformbrede nedbrud, men som intet siger om de mindre, hyppigere Actions-forstyrrelser derunder. Begge optællinger kan være sande samtidig, og tilsammen beskriver de et pålidelighedsproblem i to lag: den centrale Git-tjeneste klarer sig bedre end den CI/CD-pipeline, der er bygget oven på den, og det er netop den pipeline, der bærer den største del af den nye belastning fra AI-understøttet udvikling.

Én Platform, Hver Pipeline: Koncentrationsrisikoen

For en virksomhed, der kører hele sit engineering-workflow gennem GitHub, altså versionsstyring, CI via Actions, sit eget pakkeregister og Copilot til kodegenerering, er intet af det baggrundsstøj; det er én enkelt leverandør placeret på den kritiske vej for hver eneste release. Et europæisk udviklingsteam mærker dette ligesom et amerikansk team gør under selve nedbruddets vindue, men bærer et ekstra lag af eksponering: kontraktlige leveringsfrister, SLA-forpligtelser over for EU-kunder og hændelsesrapporteringspligter under rammer som NIS2 stopper ikke, fordi nedbruddet opstod i et amerikansk datacenter uden for teamets kontrol. At behandle 'GitHub er nede' som baggrundsstøj giver ikke længere mening, så snart de underliggende tal viser, hvorfor det skete: infrastruktur bygget til en langsommere, menneskeligt tempoerede verden absorberer nu et belastningsmønster, der næsten er fordoblet på fire måneder, på en platform, der efter eget udsagn har brugt august på at rette den samme kategori af kapacitetsfejl to gange.

Sådan Ser Redundans Ud I Praksis

Intet af dette taler for at forlade GitHub, som fortsat er standardvalget af gode grunde, men det er et konkret argument for at behandle afhængighed af én leverandør som en planlagt risiko frem for en eftertanke, der opdages midt i et nedbrud. Det betyder en spejlkopi af kritiske repositories på en anden host eller en selv-hostet Git-server, en alternativ CI-runner-konfiguration, der kan overtage builds, når Actions er nedsat, og ikke først når det er helt nede, samt en lokal eller selv-hostet cache til pakkeafhængigheder, så et nedbrud i registret ikke stopper hver eneste build i pipelinen. Ingen af disse tiltag behøver at køre kontinuerligt; de skal eksistere, testes en gang imellem og være dokumenteret godt nok til, at et team under pres under den næste hændelse ikke improviserer en løsning for første gang, mens uret for en kundefrist fortsat tikker.

Læs videre: Din Anden Git-Vært Tændte Sig Selv  |  Irland dropper sin Microsoft-kontrakt