Celem jest wiedzieć, że Twój system jest niezdrowy, zanim powiedzą Ci o tym użytkownicy. Dobra obserwabilność pozwala odpowiadać na pytania, których nie przewidywałeś, a nie tylko sprawdzać stały zestaw dashboardów. Jako tech lead konfigurujesz to przed incydentem, a nie podczas niego.
Powiadom, co odczuwa użytkownik, a nie o wewnętrznych fluktuacjach. Zakotwicz alerty w SLO: współczynnik błędów, opóźnienia (p95/p99) i dostępność. Skok CPU nie jest incydentem; upadek kasy dla 2% użytkowników jest.
| Alertuj na | Nie wysyłaj powiadomienia na |
|---|---|
| Współczynnik błędów naruszający SLO | Pojedynczy skok CPU |
| Opóźnienie p99 powyżej budżetu | Jedno wolne żądanie |
| Nieudane sprawdzenia zdrowotności | Dysk w 60% |
Każdy alert powinien być pilny, rzeczywisty i funkcjonalny — identyfikuje, co jest nie tak i wskazuje na następny krok. Alerty, które się ciągle wyzwalają, ucz zespół je ignorować; zmęczenie alertami to sposób, w który rzeczywiste incydenty przechodzą niezauważone. Dodaj sprawdzenia zdrowotności i dashboardy, które pokazują złote sygnały na pierwszy rzut oka.
Teamiące, które obserwują tylko po incydencie, latają w ciemno: dowiedzą się o awariach od wściekłych klientów i debugują na przypuszczeniach. Inwestycja w obserwabilność z przodu zamienia tajemnice z 3 nad ranem w diagnozy 5-minutowe, zmniejsza czas przestojów i uwalnia zespół do tworzenia zamiast gaszenia pożarów.