Dolt fel i kodredigeraren tiofaldigade trafiken – så förvandlades en vanlig driftstörning till ett åtta timmar långt haveri på GitHub

När grunden försvinner

För de flesta mjukvaruutvecklare är GitHub inte ett verktyg bland andra – det är infrastrukturen. Kod, versionshistorik, granskningsflöden, automatiserade byggsystem och AI-stöd via Copilot: allt samlas på en och samma plattform. Så när den plattformen försvinner i nästan åtta timmar mitt under en arbetsdag, är det inte en irritation. Det är ett fullständigt produktionsstopp.

Det är precis vad som hände nyligen, och enligt Githubs egen redogörelse – uppmärksammad av tekniksajten The Register – är händelseförloppet minst sagt lärorikt.

Hur ett litet fel blev ett stort haveri

Det började, som driftstörningar så ofta gör, med ett fullt rimligt tekniskt problem: inkommande nätverkstrafik överbelastade plattformens lastbalanserare. Under normala omständigheter ska det automatiska skalningssystemet hantera just den situationen – fördela belastningen och anpassa kapaciteten i realtid. Den här gången sviktade det systemet och reagerade inte som avsett.

Där kunde historien ha slutat, med en kortvarig störning och en snabb återhämtning. Men så tillkom ett andra problem, och det är det verkligt intressanta.

Ett tidigare oupptäckt programmeringsfel i Visual Studio Code – Microsofts populära kodredigerare, som äger samma moderbolag som GitHub – fick verktyget att gång på gång försöka återansluta till Githubs tjänster. Varje misslyckad anslutning triggade ett nytt försök, och de nya försöken skapade ännu mer trafik. Uppskattningsvis tiofaldigades det normala trafikflödet som en direkt följd av detta.

Resultatet blev en självförstärkande belastningsspiral. Och den spiralen försenade i sin tur återhämtningen av Copilots så kallade tokentjänst – den komponent som hanterar autentisering och åtkomst till AI-funktionerna. Ju längre det tog att stabilisera trafiken, desto längre dröjde det innan Copilot och övriga centrala funktioner – däribland Issues, Pull Requests och Actions – kunde återställas.

Det klassiska kaskadhaveriet

Detta är ett läroboksexempel på vad systemarkitekter kallar ett kaskadfel: ett enskilt, relativt litet problem som förstärks av oförutsedda samspel mellan komponenter tills det blivit något mycket större. Det är inte unikt för GitHub – liknande mönster har legat bakom stora driftstopp hos Amazon Web Services, Cloudflare och Meta genom åren.

Det som gör det här fallet extra intressant ur ett tekniskt perspektiv är att felet inte satt i Githubs egen infrastruktur. Det satt i en klientapplikation – Visual Studio Code – som miljontals användare kör lokalt på sina egna datorer. Plattformen attackerades alltså, ofrivilligt, av sina egna användare.

Det är en påminnelse om att moderna systemgränser är suddiga. Det räcker inte att bygga en robust serverinfrastruktur om klienterna kan bete sig på oväntade sätt under belastning. Felhantering och återanslutningslogik i klientprogram är inte en detalj – det är en kritisk del av helheten.

Det centraliserade beroendet

Men det finns en större fråga som haveriet aktualiserar: varför är vi så sårbara?

GitHub har under det senaste decenniet blivit den självklara samlingspunkten för öppen källkod och professionell mjukvaruutveckling. Det är en enorm styrka – nätverkseffekterna, ekosystemet, integrationen med otaliga andra verktyg. Men det är också en koncentrationsrisk av sällan skådat slag.

När en enda plattform kontrollerar versionshantering, kodgranskning, automatiserade arbetsflöden och AI-assistans för en stor del av världens programmerare, blir varje driftstörning ett globalt problem. Det finns visserligen alternativ – GitLab, Gitea, Forgejo för den som vill driva egna lösningar – men nätverkseffekterna gör det svårt att flytta.

Det handlar inte om att GitHub gör ett dåligt jobb. Det handlar om en strukturell sårbarhet som följer med centralisering i sig. Och det är en diskussion som techbranschen behöver ta på allvar – inte för att skapa panik, utan för att bygga mer motståndskraftiga system.