Błąd 503 Service Unavailable oznacza, że serwer chwilowo nie jest gotowy obsłużyć żądania. Najczęściej wiąże się z pracami konserwacyjnymi lub przeciążeniem, ale może też wynikać z awarii aplikacji albo usługi, od której zależy strona. Kod 503 jest odpowiedzią tymczasową, dlatego przed wprowadzeniem zmian sprawdź przyczynę problemu, logi i dostępne zasoby. Następnie potwierdź, że usługa ponownie działa poprawnie.
Spis treści
Co oznacza kod HTTP 503
503 Service Unavailable to kod stanu HTTP. Serwer używa go, gdy nie może tymczasowo obsłużyć żądania. Według MDN taki stan może wystąpić podczas konserwacji lub przeciążenia serwera.
Odpowiedź 503 może zawierać nagłówek Retry-After. Wskazuje on, kiedy klient powinien spróbować ponownie. Jeżeli czas przywrócenia usługi jest znany, warto udostępnić go w odpowiedzi HTTP, zamiast pozostawiać użytkownika bez informacji o charakterze przerwy.
Najczęstsze błędy podczas obsługi awarii 503
Restartowanie usług bez sprawdzenia objawów
Restart wykonany bez wcześniejszego sprawdzenia logów może ukryć ślady problemu. Najpierw zapisz godzinę wystąpienia błędu, adres strony, której dotyczy, oraz komunikat widoczny w przeglądarce. Następnie sprawdź wpisy z tego okresu w logach serwera, aplikacji i usług zależnych.
Restart może być elementem odzyskiwania działania, ale nie powinien być pierwszą i jedyną reakcją. Po restarcie nadal trzeba sprawdzić, czy odpowiedzi HTTP wróciły do normy i czy źródłowa przyczyna nie występuje dalej.
Traktowanie każdej strony 503 jako awarii
Strona konserwacyjna także może zwracać kod 503. Jest to oczekiwane zachowanie, gdy usługa jest chwilowo niedostępna z powodu planowanych prac. Błędem jest wyłączanie mechanizmu konserwacji bez potwierdzenia, że aplikacja oraz jej zależności są gotowe do obsługi ruchu.
Sprawdź, czy komunikat 503 pochodzi z celowo włączonej strony konserwacyjnej, czy z aplikacji albo serwera. Rozróżnienie tych przypadków ogranicza ryzyko udostępnienia strony w trakcie nieukończonych prac.
Pomijanie przeciążenia zasobów
Przeciążenie jest jedną z przyczyn odpowiedzi 503 wskazywanych przez MDN. W czasie incydentu sprawdź stan zasobów używanych przez usługę, zwłaszcza CPU, pamięci RAM i przestrzeni dyskowej. Zestaw te dane z czasem pojawienia się błędów w logach.
W Elastycznym Web Hostingu zasoby są automatycznie dopasowywane do bieżącego ruchu i obciążenia strony. Przy większym obciążeniu mogą wzrosnąć dostępne CPU, RAM i przestrzeń, a po spadku obciążenia wracają do poziomu bazowego. Nie zwalnia to jednak z sprawdzenia, czy problem dotyczy samej aplikacji lub usługi zależnej.
Ignorowanie usług zależnych
Strona może zwracać 503, mimo że jej główny proces odpowiada. Problem może dotyczyć usługi pośredniej lub zewnętrznej zależności wykorzystywanej przez aplikację. Brief awarii powinien obejmować również stan tych zależności, ich odpowiedzi oraz wpisy w logach z tego samego przedziału czasu.
Nie uznawaj incydentu za zakończony wyłącznie dlatego, że strona główna wyświetla się raz poprawnie. Sprawdź także funkcje, które korzystają z usług zależnych.
Bezpieczna kolejność przywracania działania
- Potwierdź zakres błędu. Sprawdź, czy 503 występuje na całej stronie, w wybranej części aplikacji czy tylko dla określonej funkcji.
- Zapisz dane z chwili awarii. Zbierz godzinę zdarzenia, adresy zwracające 503, komunikaty oraz wpisy z logów serwera, aplikacji i zależności.
- Ustal typ niedostępności. Rozróżnij zaplanowaną konserwację, przeciążenie, błąd aplikacji i problem po stronie usługi zależnej.
- Sprawdź stan zasobów i usług. Oceń dostępność procesów aplikacji oraz usług wymaganych do obsługi żądania.
- Wprowadź jedną zmianę naraz. Po każdej zmianie sprawdź odpowiedź strony. Taki sposób ułatwia powiązanie działania z wynikiem.
- Przywróć ruch dopiero po testach. Jeśli używasz strony konserwacyjnej, wyłącz ją po potwierdzeniu, że podstawowe funkcje działają poprawnie.
[Screenshot: widok odpowiedzi HTTP 503 oraz nagłówka Retry-After w narzędziu diagnostycznym]
Jakie logi i kontrole stanu sprawdzić
Przed deklaracją rozwiązania problemu porównaj czas wystąpienia 503 z informacjami z kilku miejsc:
- logi serwera WWW, aby sprawdzić żądania zakończone odpowiedzią 503,
- logi aplikacji, aby znaleźć błędy występujące przy obsłudze tych samych żądań,
- logi procesów lub usług zależnych, jeżeli aplikacja z nich korzysta,
- stan CPU, RAM i przestrzeni dyskowej w okresie awarii,
- odpowiedzi kluczowych adresów i funkcji aplikacji po wykonaniu zmian.
Kontrola stanu nie powinna ograniczać się do samego kodu strony głównej. Sprawdź adresy, które były objęte problemem, oraz elementy zależne od usług pośrednich.
Jak potwierdzić zakończenie incydentu
Incydent można uznać za rozwiązany po potwierdzeniu, że żądania nie zwracają już 503, a aplikacja obsługuje podstawowe funkcje w oczekiwany sposób. Warto wykonać te testy po zakończeniu prac konserwacyjnych, zmianie konfiguracji lub przywróceniu usługi zależnej.
- Otwórz wcześniej niedostępny adres i sprawdź kod odpowiedzi HTTP.
- Przetestuj podstawową funkcję strony powiązaną z problemem.
- Sprawdź, czy w aktualnych logach nie pojawiają się nowe wpisy 503.
- Potwierdź dostępność usług zależnych używanych przez testowaną funkcję.
- Jeżeli stosowano stronę konserwacyjną, usuń ją dopiero po zakończeniu powyższych kontroli.
FAQ
Czy błąd 503 oznacza trwałą awarię strony?
Nie. Kod 503 oznacza tymczasową niedostępność usługi. Może pojawić się podczas konserwacji albo przeciążenia serwera, co opisuje http.dev.
Czy stronę konserwacyjną należy wyłączyć od razu po pojawieniu się 503?
Nie. Najpierw potwierdź, czy strona konserwacyjna jest zamierzona oraz czy aplikacja i jej zależności są gotowe do obsługi ruchu. Wyłączenie jej przed testami może ujawnić użytkownikom nadal niedziałającą usługę.
Dlaczego po restarcie trzeba ponownie sprawdzić logi?
Restart może przywrócić odpowiedzi strony, ale nie potwierdza sam w sobie usunięcia przyczyny. Kontrola nowych wpisów 503, stanu zasobów i działania usług zależnych pozwala sprawdzić, czy problem nie powraca.