GitHub nie działał przez prawie 8 godzin 17 sierpnia
GitHub.com doświadczył awarii trwającej 7 godzin i 47 minut 17 sierpnia 2026 roku, od 13:28 do 21:15 UTC, która pogorszyła działanie niemal każdego kluczowego przepływu pracy programistów na platformie. Podwyższone wskaźniki błędów i opóźnienia dotknęły jednocześnie Issues, Pull Requesty, API REST i GraphQL, GitHub Actions oraz GitHub Copilot, więc zakłócenie nie ograniczyło się do jednej funkcji. Własny post-mortem GitHuba, opublikowany na github.blog pod tytułem "The August 17 outage and the work ahead", podaje maksymalny wskaźnik błędów na poziomie około 20% w całej witrynie i około 50% konkretnie dla pobierania archiwów i surowych plików. The Register, TechTimes i dev.to potwierdziły oś czasu i zakres w swoich własnych relacjach z incydentu.
| Wskaźnik | Wartość |
|---|---|
| Początek (UTC) | 13:28 |
| Koniec (UTC) | 21:15 |
| Czas trwania | 7 godzin 47 minut |
| Maksymalny wskaźnik błędów, cała witryna | ~20% |
| Maksymalny wskaźnik błędów, pobieranie archiwum/raw | ~50% |
Przyczyną było proxy na swoim limicie, a nie nieudane wdrożenie
Post-mortem GitHuba jasno stwierdza, że awarii nie spowodowało wdrożenie kodu ani konfiguracji; była to awaria pojemności i monitoringu wewnątrz własnej infrastruktury sieciowej firmy. Wyzwalaczem było proxy sidecar service mesh Istio w centrum danych w Central US, które osiągnęło swój limit współbieżności, gdy ruch napłynął w nowym wzorcu szczytowym, do którego system nie był dopasowany rozmiarem. Sidecar service mesh znajduje się obok każdej instancji usługi i zarządza jej ruchem sieciowym, więc gdy jeden z nich osiąga twardy pułap przy nieoczekiwanym obciążeniu, wszystko, co jest przez niego przekierowywane, zawodzi jednocześnie, zamiast stopniowo się pogarszać.
Źle skonfigurowany alert sprawił, że nikt tego nie widział z wyprzedzeniem
Wewnętrzna polityka monitoringu była źle skonfigurowana i nie zaalarmowała inżynierów GitHuba, gdy proxy sidecar zbliżało się do swojego limitu współbieżności, więc alert, który miał wywołać reakcję, zanim użytkownicy cokolwiek zauważą, po prostu nigdy się nie uruchomił. Ta luka waży tyle samo co sam limit współbieżności: limit pojemności wykryty wcześnie to ciche uaktualnienie, a limit wykryty dopiero po tym, jak użytkownicy zobaczą błędy, staje się wielogodzinnym incydentem. GitHub twierdzi, że usunięcie tej luki w monitoringu jest częścią prac określonych w tytule post-mortemu jako "work ahead".
Własna logika ponowień GitHuba, zwłaszcza z VS Code, pogorszyła sytuację
Optymistyczna logika ponowień po stronie klienta w całym ekosystemie GitHuba zamieniła przeciążone proxy w kaskadę obejmującą całą platformę, a GitHub wskazał burzę ponowień z klientów VS Code jako istotny czynnik decydujący o tym, jak poważna była awaria. Gdy żądanie zawodzi, a klient natychmiast ponawia je bez odczekania, nie tylko zawodzi ponownie, lecz dodaje kolejne żądanie do już przeciążonego systemu, a pomnożone przez miliony instalacji VS Code odpytujących GitHub w tle, ten wzorzec zamienił ograniczony problem proxy w problem obejmujący całą platformę. To właśnie ten szczegół zamienia incydent z historii o infrastrukturze GitHuba w historię o tym, jak powinien być zbudowany każdy klient każdego API.
Dla każdej firmy, której pipeline przechodzi przez GitHub, było to 8 godzin black-outu
Większość firm traktuje awarię GitHuba jako niedogodność dla programistów, na którą narzeka się w oczekiwaniu, lecz dla każdej firmy, która po cichu uczyniła GitHub Actions i Copilota częścią swojego pipeline'u wydań, 7 godzin i 47 minut bez GitHuba to 7 godzin i 47 minut, w których nie można wydać hotfixa, nie można scalić poprawki bezpieczeństwa, a jeśli Copilot jest częścią przepływu pracy, traci się narzędzie do kodowania wspomaganego przez AI w połowie zadania. To ryzyko koncentracji na jednym dostawcy, ukryte wewnątrz czegoś, co wygląda jak "po prostu korzystanie z GitHuba", i nie pojawia się na żadnej linii budżetu tak, jak zrobiłaby to subskrypcja oprogramowania. Ostrzejsza lekcja dotyczy burzy ponowień: jeśli własne oprogramowanie klienckie GitHuba pogorszyło awarię, agresywnie ponawiając żądania bez odczekania, każda firma budująca własne systemy oparte na zewnętrznych API powinna sprawdzić własną logikę ponowień pod kątem tej samej wady, zamiast odkładać to jako wyłącznie problem GitHuba.
Czytaj dalej: Agent AI Wiz Włamał Się do Snowflake i Oskarżył Copilota | Wasz Drugi Host Git Włączył Się Sam
