Zanim ogłosisz awarię albo zaczniesz grzebać we własnych ustawieniach, sprawdź trzy rzeczy: oficjalny status tego komponentu usługi, z którego korzystasz, zgłoszenia innych użytkowników i test na drugim koncie, urządzeniu albo połączeniu. Te trzy sygnały razem mówią, czyją procedurą iść dalej - dostawcy czy własną.
Ta strona nie pokazuje statusu na żywo. Pomaga wybrać właściwą procedurę, zanim wykonasz pierwszy ruch - bo pierwszy ruch wykonany na ślepo potrafi kosztować najwięcej.
We wtorek rano Ola nie może wysłać wiadomości na Slacku. Restartuje aplikację, potem laptopa, w końcu zmienia hasło - i blokuje sobie konto na dobre. Pół godziny później dostawca publikuje komunikat o incydencie z wysyłaniem wiadomości i naprawia go po swojej stronie. Slack wraca, konto Oli nie. Cały poranek kosztowało jedno niesprawdzone źródło: strona statusowa dostawcy.
Najpierw nazwij, co dokładnie nie działa
Zdanie „internet nie działa" albo „system się wysypał" nie wskazuje nikogo, kto mógłby to naprawić. Zanim cokolwiek zrestartujesz, zapisz cztery rzeczy:
- czynność, która się nie udała - wysłanie wiadomości, pobranie kodu, synchronizacja zamówienia;
- system, który miał tę czynność wykonać;
- komponent, jeśli usługa je rozróżnia - API, logowanie, konkretny region;
- zakres - jedno konto, jedno urządzenie, jedna sieć czy wiele niezależnych miejsc.
To nie jest jeszcze diagnoza. To notatka, dzięki której sprawdzisz właściwe źródło i nie będziesz zmieniać kilku rzeczy naraz - a zmiana kilku rzeczy naraz to najprostszy sposób, żeby nie wiedzieć, co pomogło.
Skąd wiadomo, po której stronie jest problem?
Żaden z trzech sygnałów nie wystarcza sam. Rozstrzyga dopiero ich zestawienie:
- Oficjalny status u dostawcy. Ma znaczenie tylko wtedy, gdy komunikat dotyczy komponentu i regionu pasujących do twojego objawu. Zielony nagłówek całej platformy nie mówi nic o twoim koncie ani o twojej integracji.
- Zgłoszenia innych użytkowników. Pokazują, że objaw występuje szerzej, ale nie wskazują przyczyny - potrafią mieszać różne funkcje, konta i sieci. Traktuj je jako sygnał do zestawienia ze źródłem oficjalnym, nie jako dowód.
- Test po swojej stronie. Spróbuj tej samej czynności na innym koncie, urządzeniu albo połączeniu. Jeśli objaw znika, zawęziłeś problem do jednego punktu dostępu. Jeden udany test nie dowodzi jednak, że cała usługa działa wszędzie.
Którą procedurę wybrać?
| Co nie działa | Najpierw ustal | Procedura |
|---|---|---|
| Strona za CDN, DNS, cache, Workers albo zasób R2 | czy objaw dotyczy komponentu Cloudflare, serwera źródłowego czy jednej trasy | sprawdzanie statusu Cloudflare |
| Repozytorium, push, pull, API, Actions, Packages albo Pages | która operacja zawiodła i czy problem dotyczy jednego repozytorium | sprawdzanie awarii GitHuba |
| Logowanie do ChatGPT, rozmowa, generowanie, pliki albo wywołanie API | czy błąd dotyczy aplikacji, konta, funkcji czy API | zakres problemu w ChatGPT i OpenAI API |
| Wiadomości, pliki, powiadomienia albo integracje w komunikatorze | czy objaw występuje w aplikacji, w przeglądarce i w tym samym workspace | test dostępu do Slacka |
| Panel operatora, hosting, serwer, sieć, Public Cloud albo jeden region | jaki produkt i region obsługują twój zasób | diagnoza usług OVHcloud |
| Pobieranie zamówień, marketplace, kurier, magazyn albo automatyzacja sprzedaży | po której stronie integracji jest ostatni potwierdzony rekord | sprawdzanie panelu i integracji BaseLinkera |
| Własna domena, proces, proxy albo aplikacja zwraca błąd | czy administrujesz warstwą, która wypisuje ten komunikat | diagnostyka własnego serwera od objawu |
Każda z tych stron prowadzi testy właściwe dla swojej platformy. Nie powtarzamy ich tutaj, bo ten sam objaw - „nie mogę się zalogować" - u każdego dostawcy oznacza inną operację i inne miejsce sprawdzenia.
Co, gdy kilka usług pada naraz?
Jeżeli GitHub, Slack i ChatGPT przestają działać na jednym urządzeniu albo w jednej sieci, podejrzanym jest wspólny element - urządzenie, sieć, DNS, proxy albo firmowa polityka dostępu. Porównaj to samo urządzenie na innym dozwolonym połączeniu i drugie urządzenie w obecnej sieci. Nie wyłączaj przy tym firmowego proxy ani ochrony - to nie jest test, to obejście zabezpieczeń. Zanim uznasz, że wina leży po stronie łącza, zmierz stratę pakietów i opóźnienie zgodnie z procedurą pomiaru przez ping.
Gdy objaw znika po zmianie jednego wspólnego elementu, nie ogłaszaj awarii trzech dostawców naraz. Zapisz zakres i przekaż go osobie, która administruje siecią, urządzeniem albo kontami. Gdy różne osoby na różnych połączeniach widzą ten sam objaw w jednej usłudze, wróć do tabeli i wybierz procedurę tej usługi.
Co zapisać, zanim zaczniesz naprawiać?
Zachowaj dokładny komunikat błędu bez parafrazy, nazwę czynności, komponent, czas ze strefą oraz zakres kont, urządzeń i połączeń. Jeśli operacja ma identyfikator, zapisz go po usunięciu danych poufnych. Do żadnego zgłoszenia nie dołączaj hasła, tokenu, klucza prywatnego, ciasteczka sesyjnego ani danych klienta.
Nie ponawiaj masowo operacji o nieznanym wyniku. Wiadomość, workflow, wywołanie API albo synchronizacja zamówienia mogły zostać przyjęte mimo braku potwierdzenia na ekranie - ponowienie zrobi wtedy duplikaty. Procedura konkretnej usługi mówi, co sprawdzić przed kolejną próbą.
Pytania o awarie usług
Od czego zacząć, gdy nie działa usługa?
Zapisz czynność, system, komponent, dokładny komunikat i zakres objawu. Potem odczytaj oficjalny status pasującego komponentu, sprawdź zgłoszenia innych użytkowników i porównaj własny dostęp na innym koncie, urządzeniu albo połączeniu. Zestawienie tych trzech sygnałów wskazuje procedurę dostawcy albo diagnostykę własnej infrastruktury.
Czy zielony status oznacza, że problem jest po mojej stronie?
Nie. Zielony status oznacza tylko brak opublikowanego incydentu w zakresie, który dostawca obserwuje. Nie potwierdza stanu twojego konta, integracji, regionu ani aplikacji. Zanim przypiszesz problem jednej stronie, porównaj status właściwego komponentu, zgłoszenia innych użytkowników i wynik testu po swojej stronie.
Czy wiele zgłoszeń innych użytkowników potwierdza awarię?
Nie. Wiele zgłoszeń mówi, że objaw jest szerszy, ale nie wskazuje wspólnej przyczyny - mogą się w nich mieszać różne funkcje, konta i sieci. Awarię po stronie dostawcy potwierdza jego komunikat dotyczący pasującego komponentu. Bez takiego komunikatu zakres problemu pozostaje niepotwierdzony.
Co znaczy, że kilka usług nie działa w jednej sieci?
Taki układ wskazuje na wspólny element dostępu - urządzenie, sieć, DNS, proxy albo politykę bezpieczeństwa. Porównaj to samo urządzenie na innym dozwolonym połączeniu i drugie urządzenie w obecnej sieci. Wynik zawęża zakres problemu, ale sam nie nazywa jeszcze przyczyny technicznej.
Kiedy przejść do diagnostyki własnego serwera?
Wtedy, gdy to ty administrujesz domeną, proxy, procesem albo aplikacją, która wypisuje błąd, a status dostawcy nie wyjaśnia objawu. Diagnostyka od objawu prowadzi wtedy od DNS, połączenia, TLS, kodu HTTP albo uprawnień do właściwej procedury naprawy we własnej warstwie.
Ta strona wybiera ścieżkę. Strona konkretnej usługi zbiera dowody dla tej platformy, a diagnostyka własnego serwera zaczyna się tam, gdzie kończy się odpowiedzialność dostawcy. Skąd bierze się sama zależność od cudzej infrastruktury i jak ją ograniczyć przy zakupie, opisuje tekst o firmowych programach w modelu abonamentowym.