Diagnoza incydentu: od alertu do weryfikacji
Przejdziesz od alertu 5xx do potwierdzenia przyczyny, naprawy i testu końcowego.
1. Krótka teoria
Incydent zaczyna się od objawu, nie od zgadywania komendy naprawczej. Po alertcie potwierdź aktualny wynik /health oraz zakres wpływu: wszystkie żądania czy tylko jedno API, jeden host czy wiele instancji. Zapisz czas początku i ostatnią zmianę. Potem czytaj logi orders-api z tego okna oraz metryki błędów, opóźnień i zasobów. Komunikat o połączeniu z bazą wymaga weryfikacji app-db, jej logów, sieci i puli połączeń. Nie zakładaj, że restart aplikacji naprawi awarię zależności. Oddziel hipotezę od potwierdzonej przyczyny i zapisuj wyniki kolejnych testów. Naprawę wybierz zgodnie z runbookiem: może nią być korekta konfiguracji, przywrócenie zależności lub rollback ostatniej zmiany. Po działaniu sprawdź health, ważny endpoint, błędy i opóźnienia w nowym oknie oraz stabilność przez ustalony czas. Zamknięcie alertu bez weryfikacji użytkownika nie kończy incydentu. Ten schemat jest zgodny z praktyką Symulatora Dynamic Incident: objaw → zakres → dowody → przyczyna → naprawa → kontrola.
2. Przykłady komend
date --iso-8601=seconds
Zapisuje czas rozpoczęcia diagnozy.
$ date --iso-8601=seconds
curl -sS -o /dev/null -w '%{http_code} %{time_total}
' http://127.0.0.1:8000/health
Potwierdza aktualny objaw i czas odpowiedzi.
$ curl -sS -o /dev/null -w '%{http_code} %{time_total}
' http://127.0.0.1:8000/health
journalctl -u orders-api --since '15 minutes ago' --no-pager
Czyta logi aplikacji z czasu incydentu.
$ journalctl -u orders-api --since '15 minutes ago' --no-pager
systemctl status orders-api --no-pager
Sprawdza stan procesu osobno od stanu aplikacji.
$ systemctl status orders-api --no-pager
docker compose ps app-db
Sprawdza stan zależnej bazy uruchomionej w ćwiczeniowym Compose.
$ docker compose ps app-db
docker compose exec app-db pg_isready -U orders -d orders
Weryfikuje gotowość bazy po hipotezie o zależności.
$ docker compose exec app-db pg_isready -U orders -d orders
df -h /var
Sprawdza miejsce, gdy logi sugerują błąd zapisu.
$ df -h /var3. Zadanie praktyczne
orders-api, odpowiedź 503 z /health i log połączenia z app-db. Poprowadź notatkę w ośmiu krokach: alert, health, zakres, logi, metryki, zależności, naprawa, weryfikacja. Dla każdej hipotezy podaj jeden test. Zanim zaproponujesz restart albo rollback, zapisz dowód przyczyny. Po ćwiczeniowej naprawie sprawdź ważny endpoint oraz trend 5xx w kolejnym oknie.
4. Typowe błędy
- Restartowanie usługi bez ustalenia, czy awaria dotyczy zależnej bazy.
- Czytanie logów z innej godziny niż czas alertu.
- Uznawanie jednej hipotezy za przyczynę bez testu potwierdzającego.
- Naprawianie tylko jednego hosta przy problemie obejmującym cały ruch.
- Zamykanie incydentu bez testu funkcji i obserwacji błędów po zmianie.
5. Podsumowanie
Skuteczna diagnoza przechodzi od wpływu na użytkownika do zawężania przyczyny. Łącz health, logi, metryki, systemd, sieć i zależności, a naprawę wykonuj po teście hipotezy. Zakończ dopiero po weryfikacji działania i stabilności.