Awaria GitHuba: podwojone obciążenie commitami

Siedem Godzin Czterdzieści Siedem Minut, Sprowadzone Do Jednego Przeciążonego Proxy

Własny raport GitHuba, opublikowany na firmowym blogu inżynieryjnym pod tytułem 'The August 17 outage, and the work ahead', wiąże awarię z proxy sidecar Istio w centrum danych Central US, które osiągnęło swoją maksymalną zdolność przetwarzania współbieżnego. Polityka autoskalowania nadzorująca tę pojemność oceniała wyłącznie sam serwis aplikacyjny, a nie stan połączeń i współbieżności sidecarów stojących przed nim, więc nic się nie przeskalowało, gdy sidecary osiągnęły swój limit. Gdy te proxy się nasyciły, żądania przeniosły się na inne węzły, które z kolei osiągnęły własne limity pojemności, a automatyczna logika ponawiania GitHuba pogorszyła spiralę, wysyłając nowe żądania do już przeciążonych load balancerów. Osobny błąd ponawiania, według The Register umiejscowiony w rozszerzeniu VS Code używanym do uwierzytelniania GitHub Copilot, dodatkowo pogłębił awarię: bez przerwy żądał nowych tokenów uwierzytelniających, podnosząc obciążenie usługi wydawania tokenów GitHuba z normalnej bazy 7000 do 9000 żądań na sekundę do 70000-100000 żądań na sekundę, czyli około dziesięciokrotności zwykłego obciążenia.

Liczby Kryjące Się Za Jednym Złym Popołudniem

Awaria trwała od 17 sierpnia 2026 roku, od 13:28 do 21:15 UTC, a własne aktualizacje statusu GitHuba wskazywały szczytowy poziom błędów na poziomie około 20 procent w ruchu web i API oraz około 50 procent przy pobieraniu archiwów i surowej zawartości, czyli dokładnie tego typu żądań, od których zależy potok budowania lub pobranie zależności. Issues, pull requesty, API, Actions i Copilot były zdegradowane, podobnie jak uwierzytelnianie SAML i OIDC, SCIM oraz Team Sync; większość usług wróciła do normy około 16:36 UTC, Actions około 18:03 UTC, a usługa tokenów Copilota jako ostatnia, o 21:02 UTC. GitHub wyraźnie zaznaczył, że ani ten incydent, ani mniejsza awaria Actions z 6 sierpnia nie zostały spowodowane zmianą kodu lub konfiguracji; obie były, jak ujęła to sama firma, w swej istocie awariami pojemności, czyli system wyczerpał zapas mocy, zamiast zepsuć się przez wypuszczony błąd.

Liczba Commitów Niemal Podwoiła Się W Cztery Miesiące

Ukryta w tym samym raporcie jest liczba, która zmienia tę historię awarii w historię infrastruktury: GitHub twierdzi, że miesięczna liczba commitów wzrosła z 1,4 do 2,9 miliarda od kwietnia 2026 roku, czyli praktycznie podwoiła się w ciągu około czterech miesięcy, czemu towarzyszą wykresy pokazujące scalone pull requesty zbliżające się do 130 milionów miesięcznie i nowe repozytoria zbliżające się do 24 milionów miesięcznie. GitHub wskazał już tę przyczynę w swoim raporcie dostępności z maja 2026 roku, gdzie przyznał, że programowanie wspierane przez AI oraz agentowe przepływy pracy dokładały dodatkowej presji na infrastrukturę, a Microsoft publicznie oświadczył, że AI pisze już nawet do 30 procent kodu w niektórych własnych repozytoriach, z zastrzeżeniem ludzkiej weryfikacji. Platforma zwymiarowana na świat, w którym commity napływały w tempie ludzkiego pisania, absorbuje teraz wzorzec obciążenia dyktowany przez agentów kodujących, którzy nieustannie piszą, tworzą gałęzie i wypychają zmiany, a odpowiedzią GitHuba jak dotąd było dodawanie mocy: ponad 3 miliony rdzeni CPU i 120 petabajtów pamięci o wysokiej prędkości, przy czym Azure obsługuje już około 58 procent obciążenia platformy, wobec 12 procent w maju.

GitHub Actions Odnotował Trzynaście Incydentów W Siedemnaście Dni

Tech Times, analizując historię incydentów i dane statusu GitHuba, doniósł, że sam GitHub Actions odnotował 13 osobnych incydentów w ciągu 17 dni tego sierpnia, a jego dostępność w ujęciu 90-dniowym spadła z 99,39 procent przed awarią 17 sierpnia do 99,33 procent po niej, czyli spadek z około 13 godzin skumulowanego przestoju w trzy miesiące do około 14,5 godziny. Tamten serwis przedstawił incydent z 17 sierpnia jako sam w sobie pochłaniający niemal cały roczny budżet dozwolonego przestoju wobec celu trzech dziewiątek. Własny raport GitHuba liczy inaczej i nazywa 17 sierpnia swoim drugim istotnym incydentem w tym miesiącu, po awarii Actions z 6 sierpnia, co jest uczciwym liczeniem dużych awarii obejmujących całą platformę, ale nic nie mówi o mniejszych, częstszych zakłóceniach Actions leżących poniżej. Obie liczby mogą być prawdziwe jednocześnie, a razem opisują dwupoziomowy problem niezawodności: rdzeniowa usługa Git trzyma się lepiej niż zbudowany na niej potok CI/CD, i to właśnie ten potok dźwiga większość nowego obciążenia rozwoju wspieranego przez AI.

Jedna Platforma, Każdy Potok: Ryzyko Koncentracji

Dla firmy prowadzącej cały swój przepływ pracy inżynierskiej przez GitHub, czyli kontrolę wersji, CI przez Actions, własny rejestr pakietów i Copilota do generowania kodu, nic z tego nie jest szumem w tle; to jeden dostawca leżący na krytycznej ścieżce każdego wydania. Europejski zespół programistyczny odczuwa to tak samo jak zespół amerykański w samym oknie awarii, ale dźwiga dodatkową warstwę ekspozycji: umowne terminy dostaw, zobowiązania poziomu usług wobec klientów z UE oraz obowiązki zgłaszania incydentów wynikające z ram takich jak NIS2 nie zatrzymują się dlatego, że awaria powstała w amerykańskim centrum danych poza kontrolą zespołu. Traktowanie 'GitHub nie działa' jako szumu w tle przestaje mieć sens, gdy tylko leżące u podstaw liczby pokazują, dlaczego do tego doszło: infrastruktura zbudowana na wolniejszy, ludzki rytm absorbuje teraz wzorzec obciążenia, który niemal podwoił się w cztery miesiące, na platformie, która z własnego przyznania spędziła sierpień na dwukrotnym naprawianiu tej samej kategorii awarii pojemności.

Jak Naprawdę Wygląda Redundancja

Nic z tego nie jest argumentem za porzuceniem GitHuba, który z dobrych powodów pozostaje wyborem domyślnym, ale to konkretny argument za traktowaniem zależności od jednego dostawcy jako zaplanowanego ryzyka, a nie refleksji odkrytej w połowie awarii. Oznacza to lustrzaną kopię krytycznych repozytoriów na drugim hoście lub samodzielnie utrzymywanym serwerze Git, alternatywną konfigurację runnera CI zdolną przejąć budowanie, gdy Actions jest zdegradowany, a nie dopiero gdy całkowicie nie działa, oraz lokalny lub samodzielnie utrzymywany bufor dla zależności pakietów, tak aby awaria rejestru nie zatrzymywała każdego budowania w potoku. Żaden z tych środków nie musi działać nieprzerwanie; muszą istnieć, być testowane od czasu do czasu i być wystarczająco dobrze udokumentowane, aby zespół pod presją podczas kolejnego incydentu nie improwizował rozwiązania po raz pierwszy, podczas gdy zegar terminu klienta wciąż tyka.

Czytaj dalej: Wasz Drugi Host Git Włączył Się Sam  |  Irlandia anuluje umowę z Microsoftem