Awaria serwera: co sprawdzić i w jakiej kolejności

Ten poradnik dotyczy samego serwera: VPS-a, serwera dedykowanego albo serwera w chmurze, który prowadzisz. Jeśli nie działa jedna strona, a wszystko inne na maszynie działa, albo Twoja strona jest na hostingu współdzielonym, zacznij od poradnika Strona nie działa: co zrobić. Tu patrzymy na maszynę: czy w ogóle odpowiada, czy da się na nią wejść i co się zatrzymało.

Krok 1: co dokładnie nie działa?

„Awaria serwera” może oznaczać trzy bardzo różne rzeczy, a każda ma własną naprawę. Najpierw ustal to z zewnątrz, z sieci, która nie jest Twoja. Dla stron na serwerze narzędzie Is it down? w kilka sekund mówi, czy nazwa jest rozwiązywana, czy port odpowiada i jaki kod statusu wraca. Dla maszyny użyj pingu i testu portu z własnego komputera:

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Odczytaj wyniki razem:

• Brak pingu, brak SSH, brak portu WWW: maszyna jest wyłączona, zawieszona albo nie działa sieć przed nią. Przejdź do kroku 2.
• Ping odpowiada, SSH nie: maszyna działa, ale SSH jest zablokowane, zatrzymane albo serwer jest zbyt przeciążony, żeby odpowiedzieć. Przejdź do kroku 3.
• SSH działa, strona nie: serwer jest w porządku, usługa nie. Przejdź do kroku 4.

Niektóre serwery celowo odrzucają ping. Jeśli ping nigdy nie działał, polegaj na testach portów.

Krok 2: nic nie odpowiada

Zanim zrobisz cokolwiek innego, otwórz panel dostawcy albo konsolę chmury. Trzy pytania rozstrzygają większość przypadków w minutę:

1. Czy serwer działa? Zatrzymana instancja, zawieszone konto albo nieudana płatność z zewnątrz wyglądają dokładnie jak awaria.
2. Czy jest znany incydent? Sprawdź stronę statusu dostawcy dla Twojego regionu albo centrum danych.
3. Co pokazuje konsola? Konsola webowa albo szeregowa pokazuje ekran maszyny nawet bez sieci. Kernel panic, „Out of memory: Killed process” w pętli albo start zatrzymany na sprawdzaniu systemu plików: każde z nich mówi, gdzie leży problem.

Jeśli maszyna się zawiesiła, restart z konsoli zwykle ją przywraca. Zanim zrestartujesz, zrób zrzut ekranu konsoli: po restarcie dowody znikną. Jeśli nie startuje, większość dostawców oferuje system ratunkowy, z którego można zamontować dysk, odczytać logi i naprawić /etc/fstab albo zepsutą konfigurację sieci.

Krok 3: ping odpowiada, SSH nie

Maszyna żyje, więc przyczyna siedzi na niej. Zaloguj się przez konsolę i sprawdź zwykłych podejrzanych:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

Reguła firewalla dodana w pośpiechu, własny adres IP zbanowany po kilku złych hasłach albo zmiana konfiguracji SSH, która nie przeszła testu, to najczęstsze blokady. Odblokuj swój adres przez sudo fail2ban-client set sshd unbanip TWOJE_IP i zawsze uruchamiaj sudo sshd -t, zanim zrestartujesz SSH. Jeśli SSH działa, ale jest bardzo wolne, serwer jest przeciążony: przejdź do kroku 4.

Krok 4: jesteś w środku, odczytaj cztery liczby

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Obciążenie (uptime): wartość znacznie powyżej liczby rdzeni CPU oznacza przeciążoną maszynę. top albo htop pokazuje, który proces za to odpowiada.
• Pamięć (free -m): brak wolnej pamięci i swapu plus „Killed process” w dmesg oznacza, że jądro zatrzymało proces, żeby przetrwać. Zwykle była to baza danych albo PHP.
• Dysk (df -h): pełny dysk to najczęstsza przyczyna problemów z serwerem. Bazy danych przestają zapisywać, logi stają, sesje zawodzą. df -i sprawdza i-węzły: dysk może być „pełny” przy gigabajtach wolnego miejsca, jeśli miliony małych plików zużyły wszystkie i-węzły.
• Błędy I/O albo system plików tylko do odczytu w dmesg: problem ma sam dysk. Przestań zapisywać, zrób kopię zapasową, jeśli jeszcze możesz, i skontaktuj się z dostawcą.

Żeby bezpiecznie zwolnić miejsce, zacznij od dziennika systemowego i starych archiwów:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Nigdy nie usuwaj plików bazy danych ani plików strony, żeby zrobić miejsce.

Krok 5: która usługa się zatrzymała i dlaczego

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed wymienia każdą usługę, która zatrzymała się z błędem. Dziennik tej usługi podaje powód: port już zajęty, błąd składni w pliku konfiguracyjnym, brakujący certyfikat, brak miejsca. Testuj konfigurację przed każdym restartem (nginx -t, apachectl configtest, php-fpm -t), potem uruchom przez sudo systemctl restart USLUGA. Restart bez testu może położyć usługę, która jeszcze w połowie działała.

Krok 6: co się zmieniło?

Awarie mają przyczyny, a przyczyną jest zwykle ostatnia zmiana. Poszukaj jej:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Automatyczne aktualizacje, nowe jądro czekające na restart, wdrożenie, zadanie cron, które zapełniło dysk kopiami zapasowymi, wygasły certyfikat albo edycja konfiguracji przez kogoś innego: jeśli któraś z tych linii pokrywa się z czasem początku awarii, masz trop.

Gdy te same problemy z serwerem wracają

Serwer, który raz przestał działać przez pełny dysk albo zatrzymaną bazę danych, zrobi to znowu. Sprawdzanie z zewnątrz mówi Ci, kiedy nie działa; sprawdzanie od środka mówi Ci wcześniej. Agent serwerowy przesyła obciążenie, pamięć, dyski i usługi z wnętrza maszyny i wysyła alert, gdy dysk przekroczy Twój próg albo zaznaczona usługa się zatrzyma, kiedy jest jeszcze czas na reakcję. Monitoring serwerów z agentem jest częścią płatnych planów.

Gdy nie chcesz tego robić o trzeciej w nocy

Awaria serwera? Naprawiamy. Jeśli wolisz naprawę od samodzielnego szukania, Quick Fix usuwa częste przyczyny w stałej cenie: restartuje zatrzymaną usługę po udanym teście jej konfiguracji, zwalnia pełny dysk i odnawia wygasły certyfikat, najpierw z kopią zapasową. Gdy to nie wystarczy, przejmuje Deep Fix, przez całą dobę, rozliczany w blokach po 15 minut, z ceną pokazaną przed zamówieniem. Oba działają przez Responder, SSH jako root albo SSH do hostingu. Szczegóły na stronie naprawa serwera 24/7.