Gdy push wisi albo nie startuje pipeline, sprawdź najpierw stan konkretnego komponentu na stronie statusu GitHuba, a potem wykonaj lokalny odczyt git ls-remote. Commituj dalej - commit jest operacją lokalną i żadna awaria GitHuba go nie zatrzyma. Kluczy i tokenów nie resetuj, dopóki nie wykluczysz incydentu.
Ta strona to procedura rozpoznania, nie status na żywo. Prowadzi od objawu do werdyktu w kilka minut. Jeśli zawodzi inne narzędzie pracy, na przykład Slack albo panel hostingu, przejdź do procedur sprawdzania statusu dostawców - każda usługa ma tam osobny opis.
Poranek, w którym push przestał działać
Zanim przejdziesz do procedury, zobacz, jak wygląda typowa awaria GitHuba w małym zespole - i ile kosztuje reagowanie w złej kolejności.
Kwadrans po dziewiątej Kasia kończy poprawkę i robi push. Operacja wisi na „Writing objects" i po dłuższej chwili kończy się timeoutem. Repozytorium w przeglądarce otwiera się normalnie, więc Kasia uznaje, że to jej klucz SSH. Generuje nowy, podmienia go w ustawieniach konta, próbuje jeszcze raz. Ten sam błąd.
W tym samym czasie Tomek patrzy na pull request, w którym od pół godziny nie ruszyły testy. Klika „Re-run jobs" trzy razy. Żaden bieg nie pokazuje wyniku, więc uznaje, że coś zepsuł w konfiguracji i zaczyna grzebać w pliku workflow na gałęzi, której nie może wypchnąć.
Po godzinie ktoś wreszcie otwiera stronę statusu GitHuba. Incydent dotyczy Git Operations i Actions, interfejs WWW działa bez zakłóceń. Zespół nie mógł nic na to poradzić - ale został z nowym kluczem do posprzątania, trzema zdublowanymi biegami testów w kolejce i zmianami w konfiguracji, które trzeba wycofać.
Żaden z tych ruchów nie wynikał z braku kompetencji. Wynikały z założenia, że GitHub działa albo nie działa w całości - a on psuje się kawałkami. Strona otwarta w przeglądarce nie mówi nic o tym, czy przejdzie push.
Dlaczego GitHub psuje się kawałkami?
GitHub to zestaw niezależnych usług pod wspólnym adresem, nie jedna aplikacja. Awaria jednej z nich nie wyłącza pozostałych - i dlatego diagnozę zaczyna się od pytania, która czynność ci się nie udała, a nie od pytania, czy GitHub działa. Każdej czynności odpowiada komponent na stronie statusu:
- Git Operations - clone, fetch, pull i push, niezależnie od protokołu.
- Actions - uruchamianie testów, buildów i wdrożeń po commicie.
- API Requests - integracje, boty i edytory łączące się przez API.
- Webhooks - zdarzenia wysyłane do systemów zewnętrznych, na przykład do czatu zespołu.
- Packages - pobieranie i publikowanie paczek oraz obrazów.
- Pages - strony hostowane z repozytoriów.
- Issues, Pull Requests i interfejs WWW - praca w przeglądarce.
Z tej listy wynika praktyczny wniosek dla zespołu deweloperskiego. Panel może działać, gdy push zawodzi. Push może przechodzić, gdy kolejka Actions stoi. Merge może się udać, a webhook do wdrożenia nie wyjdzie. Werdykt „GitHub leży" na podstawie jednego objawu jest prawie zawsze za szeroki.
Gdzie sprawdzić oficjalny status GitHuba?
Komunikaty o incydentach publikuje GitHub Status - to jedyne źródło, w którym właściciel platformy potwierdza awarię. Nie zatrzymuj się na nagłówku strony. Odszukaj na liście komponent odpowiadający czynności, która się nie udała, i przeczytaj opis incydentu razem z kolejnymi aktualizacjami.
Komunikat o zakłóceniach w Actions nie wyjaśnia błędu uwierzytelnienia przy push - to osobne komponenty i osobne incydenty. Serwisy zbiorczych zgłoszeń użytkowników pokazują skalę problemu szybciej, ale bez rozbicia na komponenty, więc traktuj je jako sygnał pomocniczy, nie werdykt.
Jak sprawdzić, czy problem jest po twojej stronie?
Zanim cokolwiek zresetujesz, zbierz obserwacje. Zapisz repozytorium, operację, protokół, pełny komunikat błędu i czas ze strefą. Nie wklejaj nigdzie tokenu, klucza prywatnego ani adresu z sekretem w środku.
- Wykonaj bezpieczny odczyt zdalnych referencji, który niczego nie zapisuje:
git ls-remote ADRES_REPOZYTORIUMADRES_REPOZYTORIUM zastąp adresem HTTPS albo SSH z twojego projektu. Jeśli komenda zwraca listę gałęzi i tagów, połączenie z repozytorium działa - problem leży dalej, na przykład w uprawnieniach do zapisu albo w innym komponencie.
-
Porównaj HTTPS z SSH. Ten sam odczyt wykonany oboma protokołami rozdziela awarię platformy od problemu z kluczem, portem albo polityką firmowej sieci. Jeden protokół sprawny przy drugim martwym wskazuje na twoją konfigurację, nie na incydent.
-
Powtórz odczyt przez inną sieć, na przykład hotspot z telefonu. Firmowe proxy i zapora potrafią wyciąć ruch do GitHuba tak, że objaw wygląda jak awaria dostawcy.
-
Poproś drugą osobę z zespołu o ten sam test na jej koncie i jej sieci. Błąd widoczny u wszystkich pasuje do incydentu; błąd tylko u ciebie pasuje do konta.
-
Oddziel konto od platformy. Komunikat o braku uprawnień, wymaganym logowaniu SSO w organizacji albo wygasłym tokenie pojawia się przy w pełni sprawnej platformie. W firmowych organizacjach sesja SSO wygasa po cichu, a błąd po jej wygaśnięciu wygląda jak odmowa dostępu do repozytorium.
Dopiero komplet tych obserwacji uprawnia do decyzji. Reset klucza albo tokenu wykonany na ślepo niczego nie diagnozuje, a po zakończeniu incydentu zostawia do posprzątania konfigurację, która wcześniej działała.
Trzy sygnały i jeden werdykt
| Oficjalny status | Sygnały z zespołu | Twój test lokalny | Werdykt | Co robisz |
|---|---|---|---|---|
| Incydent właściwego komponentu | Te same objawy u kilku osób | Odczyt zawodzi na niezależnych sieciach | Awaria potwierdzona przez GitHub | Pracujesz lokalnie i śledzisz aktualizacje |
| Brak incydentu | Wiele zgodnych zgłoszeń | Ten sam błąd na różnych sieciach i kontach | Szerszy problem bez potwierdzenia | Zbierasz identyfikatory żądań i zgłaszasz do supportu |
| Brak incydentu | Cisza | Błąd jednego konta, repozytorium albo protokołu | Problem po twojej stronie | Sprawdzasz uprawnienia, SSO, token, klucz i sieć |
| Nie można otworzyć strony statusu | Brak danych | Brak testu | Za mało danych na werdykt | Wykonujesz odczyty, żadnych operacji zapisu |
Jak pracować, gdy GitHub ma awarię?
Git działa w całości lokalnie i to jest twoja przewaga podczas incydentu. Twórz małe commity na gałęzi roboczej i opisuj je tak, żeby po przywróceniu usługi dało się je czytać. Push wykonasz później, w tej samej kolejności. Nie używaj force push i nie przepisuj historii tylko dlatego, że zdalna operacja zwróciła błąd - stan po stronie serwera może być inny, niż sugeruje komunikat.
Kilka reguł na czas incydentu chroni cię przed sprzątaniem po nim:
- Bieg w Actions, który nie pokazuje wyniku, mógł zostać przyjęty. Zapisz identyfikator biegu i commit, sprawdź stan kolejki i dopiero wtedy decyduj o ponowieniu - trzy kliknięcia „Re-run" potrafią uruchomić trzy równoległe wdrożenia.
- Gdy Packages nie odpowiada, nie podmieniaj źródła zależności na przypadkowy rejestr. Korzystaj z lokalnego cache albo firmowego mirrora - podstawiona paczka z nieznanego źródła to ryzyko większe niż opóźnienie builda.
- Gdy incydent dotyczy Pages, twoja strona może nie działać, choć repozytorium i proces pracy są sprawne. Komunikuj awarię strony, nie całego projektu.
Co przekazać administratorowi lub do supportu?
Dobre zgłoszenie skraca diagnozę po obu stronach. Podaj adres repozytorium bez sekretów, nazwę komponentu, operację, protokół, czas ze strefą, oczyszczony komunikat błędu i wynik testu na drugiej sieci. Przy problemach z Actions dołącz identyfikator biegu i commit, przy integracjach identyfikator żądania z odpowiedzi API.
Jeśli test lokalny wskazał na twoją infrastrukturę - błąd DNS, odmowę połączenia albo problem z TLS - strona statusu nic tu nie pomoże. Przejdź do diagnozy błędów połączenia i prowadź ją po swojej stronie: od resolvera, przez proxy, do zapory.
Pytania o awarie GitHuba
Czy mogę commitować podczas awarii GitHuba?
Tak, bez żadnych ograniczeń. Commit zapisuje zmiany wyłącznie w lokalnym repozytorium i nie łączy się z serwerem. Pracuj na gałęzi roboczej, utrzymuj małe i opisane zmiany, a push wykonaj po przywróceniu komponentu Git Operations. Awaria zdalnej platformy nie przerywa pracy nad kodem.
Dlaczego GitHub Status jest zielony, a push nie działa?
Zielony status nie potwierdza twojego dostępu ani twojej trasy sieciowej. Wygasła sesja SSO w organizacji, przeterminowany token, cofnięte uprawnienia do repozytorium, zablokowany port SSH w firmowej sieci - każdy z tych przypadków daje błąd przy sprawnym GitHubie. Porównaj HTTPS z SSH i wykonaj test na innej sieci, zanim uznasz to za awarię.
Czy ponawiać workflow w Actions, który nie pokazał wyniku?
Nie od razu. Zadanie mogło zostać przyjęte do kolejki, choć interfejs nie wyświetlił statusu - ponowienie uruchomi wtedy drugą kopię. Zapisz identyfikator biegu i commit, sprawdź stan poprzedniego wykonania po ustąpieniu incydentu i ponawiaj tylko te biegi, które faktycznie nie doszły do skutku.
Czy awaria GitHuba może dotyczyć tylko przeglądarki?
Może. Interfejs WWW, operacje Git i API to osobne komponenty i każdy z nich potrafi mieć incydent niezależnie. Zdarza się więc, że panel nie odpowiada, a clone i push przechodzą normalnie - i odwrotnie. Wynik jednego testu opisuje jeden komponent, nie całą platformę.
Co zrobić, gdy zespół musi wydać wersję w trakcie awarii?
Rozdziel to, co zależy od GitHuba, od tego, co nie zależy. Kod macie lokalnie, więc build i testy da się uruchomić poza Actions, na maszynie zespołu. Jeśli wdrożenie wymaga sprawnego komponentu, który ma incydent, zaplanuj wydanie po jego przywróceniu - obejście klecone w pośpiechu potrafi kosztować więcej niż godzina opóźnienia.