Czy to u mnie nie działa, czy u nich? Krótka historia jednej awarii
Każdy zna ten moment.
Chcesz wejść na stronę, platformę szkoleniową albo panel klienta i nagle nic. Przeglądarka kręci kółkiem, po chwili pojawia się błąd, a w głowie zaczyna się klasyczna procedura diagnostyczna użytkownika końcowego:
Czy to mój internet? Czy Wi-Fi znowu udaje, że działa? Czy to DNS? Czy strona padła? Czy może ja już klikam coś nie tak?
W przypadku jednej platformy e-learningowej sytuacja wyglądała właśnie tak: usługa przestała odpowiadać, a z zewnątrz nie było jasnej informacji, czy ktoś już o tym wie.
Pierwsze pytanie: czy to u mnie?
Zanim zacznie się oskarżać serwer, hosting, DNS, operatora, pogodę i fazy Księżyca, warto sprawdzić podstawy.
Najpierw zwykły test dostępności adresu IP:
ping IP_ADDRESS
Wynik: brak odpowiedzi.
Sam ping nie przesądza jeszcze sprawy, bo ICMP może być blokowany. Niektóre serwery po prostu nie odpowiadają na ping i żyją szczęśliwie dalej.
Dlatego kolejnym krokiem był test po HTTP/S.
curl -v https://example.com
Tutaj połączenie zatrzymywało się na próbie połączenia z adresem IP_ADDRESS:443.
Czyli przeglądarka nie była „obrażona”, a problem nie wyglądał jak literówka w adresie. Klient próbował połączyć się z serwerem, ale nie był w stanie zestawić połączenia.
Drugi krok: czy porty w ogóle żyją?
Następnie prosty test portów:
nc -vz example.com 80
nc -vz example.com 443
Efekt: timeout na portach 80 i 443.
To już wyglądało mniej jak problem lokalnej przeglądarki, a bardziej jak problem po stronie usługi, serwera, hostingu albo ścieżki sieciowej do niego.
Trzeci krok: sprawdźmy z innego miejsca
Bardzo ważny etap: test z innego łącza, najlepiej z zupełnie innej lokalizacji.
Bo jeśli testujesz tylko ze swojego domu, to nadal może być:
- Twój router,
- Twój dostawca internetu,
- lokalny DNS,
- problem po trasie między Tobą a serwerem.
Dlatego dobrze jest wykonać test z zewnętrznego VPS-a.
Z zewnętrznego serwera próba połączenia z portem 443 zwracała komunikat:
No route to host
I to już jest mocna wskazówka: problem nie wyglądał na lokalny problem użytkownika. Skoro z innego miejsca w internecie również nie dało się połączyć, to awaria była najprawdopodobniej po stronie infrastruktury usługi, hostingu, routingu, firewalla albo samego serwera.
Czyli gdzie jest problem?
Na podstawie tych testów można było powiedzieć:
To raczej nie jest problem mojego laptopa, przeglądarki ani domowego Wi-Fi.
Nie znaczy to jeszcze, że znamy dokładną przyczynę. To mogło być wiele rzeczy:
- wyłączony serwer,
- awaria hostingu,
- problem z routingiem,
- źle ustawiony firewall,
- problem po stronie dostawcy VPS,
- awaria reverse proxy,
- nieudana zmiana konfiguracji,
- problem sieciowy w data center.
Ale z punktu widzenia klienta ważne było coś innego: usługa nie działała, a użytkownik nie wiedział, czy ktokolwiek już o tym wie.
Najgorsze w awarii nie zawsze jest to, że coś padło
Awaria może się zdarzyć każdemu.
Serwery padają. Routing potrafi zrobić psikusa. Firewall potrafi być zbyt ambitny. Certyfikat TLS potrafi wygasnąć w najmniej odpowiednim momencie. A aktualizacja „na chwilę” czasem zamienia się w wieczór z logami.
Problem zaczyna się wtedy, gdy klient dowiaduje się o awarii przed właścicielem usługi.
To jest ten nieprzyjemny scenariusz:
„Dzień dobry, czy Państwa platforma działa?” „A nie działa?” „No nie.” „Aha…”
I nagle klient staje się systemem monitoringu.
Tylko że klient nie powinien być monitoringiem. Klient powinien być klientem.
Co można było zrobić lepiej?
Nie zawsze da się uniknąć awarii, ale można lepiej przygotować się na jej obsługę.
1. Monitoring dostępności
Podstawą powinien być prosty monitoring z zewnątrz:
- czy strona odpowiada po HTTPS,
- czy port
443jest dostępny, - czy odpowiedź HTTP ma sensowny kod,
- czy certyfikat TLS nie kończy się za chwilę,
- czy DNS wskazuje poprawny adres.
To nie musi być od razu ogromny system klasy enterprise. Czasem wystarczy proste sprawdzanie co minutę lub kilka minut i alert na e-mail, Discorda, Slacka albo telefon.
Najważniejsze jest to, żeby właściciel usługi wiedział o problemie zanim napisze klient.
2. Prosta strona awaryjna
Druga rzecz: awaryjna zaślepka.
Nie chodzi o cuda. Wystarczy prosta strona:
Mamy problem techniczny. Wiemy o awarii i pracujemy nad przywróceniem usługi. Przepraszamy za niedogodności.
To jest o wiele lepsze niż cisza, timeout i niepewność.
Taka strona może być utrzymywana osobno, np. na innym hostingu, w statycznym pliku, w prostym reverse proxy albo jako awaryjne przekierowanie DNS/Cloudflare.
Nawet ręczne przełączenie na taką zaślepkę jest lepsze niż sytuacja, w której użytkownik widzi tylko błąd połączenia i nie wie, czy usługa jeszcze istnieje.
3. Procedura „co robić, gdy padnie”
W małych firmach często nie trzeba zaczynać od wielkiego planu ciągłości działania. Wystarczy jedna krótka instrukcja:
- gdzie jest serwer,
- kto ma dostęp,
- gdzie są DNS-y,
- gdzie jest panel hostingu,
- jak sprawdzić logi,
- jak włączyć stronę awaryjną,
- gdzie są backupy,
- jak sprawdzić, czy backup da się odtworzyć.
To może być jedna strona dokumentacji. Ale w czasie awarii taka jedna strona bywa więcej warta niż pięć lat „jakoś to działało”.
Co bym zaproponował po takiej awarii?
W takim przypadku nie zaczynałbym od rewolucji. Najpierw podstawy:
- monitoring dostępności strony z zewnątrz,
- alerty, żeby właściciel usługi wiedział o awarii od razu,
- prostą stronę awaryjną,
- krótką dokumentację infrastruktury,
- sprawdzenie backupu i procedury odtworzenia,
- przegląd DNS, TLS, firewalla i hostingu,
- ustalenie minimalnej procedury reagowania na awarie.
Dopiero potem można myśleć o bardziej zaawansowanych rzeczach.
Bo czasem problemem nie jest brak Kubernetesa, klastra i kosmicznej architektury. Czasem problemem jest brak prostego pytania:
„Skąd wiemy, że to padło?”
I drugiego:
„Co pokazujemy klientowi, kiedy już wiemy?”
Morał
Nie każda awaria oznacza katastrofę. Ale każda awaria bez informacji wygląda gorzej, niż musi.
Jeśli usługa nie działa, klient powinien zobaczyć jasny komunikat, a nie zgadywać, czy problem jest u niego, u operatora, w przeglądarce, w kablu, w DNS-ach czy może w Merkurym w retrogradacji.
Monitoring, alerty, backup i prosta strona awaryjna nie są luksusem. To podstawowa higiena techniczna.
Jeśli chcesz uporządkować taki obszar u siebie, zobacz usługę Backup i monitoring serwerów.
Zwłaszcza wtedy, gdy na platformie opiera się kontakt z klientami, sprzedaż, szkolenia albo codzienna praca firmy.
Aktualizacja: własny test DR
Ten wpis nie skończył się tylko na komentarzu do cudzej awarii. Potraktowałem go jako impuls do sprawdzenia własnej infrastruktury.
Moja strona logos.net.pl działa na Raspberry Pi 4, a jako backup przygotowałem VPS. Przetestowałem ręczne przełączenie ruchu przez Cloudflare Tunnel z Raspberry Pi na VPS i z powrotem.
Opisałem to tutaj:
Najciekawszy wniosek? Sam failover zadziałał praktycznie od razu. Problemem okazał się mój lokalny Pi-hole, który cache’ował DNS i przez chwilę udawał, że procedura nie działa.