Monitoring i status

Prawie każda strona statusu, na jaką trafisz, pokazuje piękne liczby. 100 procent uptime, wszystko na zielono, żadnej rysy. Problem w tym, że te liczby najczęściej nie znaczą "wszystko działało", tylko "nikt nie patrzył". Brak danych zostaje policzony jako sukces, a klient dostaje ładny obrazek, który nie ma pokrycia w rzeczywistości.

Zbudowaliśmy monitoring, który robi coś trudniejszego niż ładny wykres: mówi prawdę, nawet gdy prawda jest niewygodna. Kiedy nie wiemy, jak działała usługa, wynik ma brzmieć "nie wiem", a nie "wszystko dobrze". Do tego dochodzi publiczna strona statusu z uczciwą historią i obsługa incydentów prowadzona tam, gdzie zespół i tak siedzi. Ten case study jest o tym, jak liczyć dostępność bez oszukiwania samego siebie.

Mechanizm typowego kłamstwa statusu jest banalny. Jeśli w danym okresie sonda nie zebrała żadnej próbki, a mimo to wliczasz ten okres jako sprawny, twój uptime zawsze będzie wyglądał świetnie. Im rzadziej patrzysz, tym lepiej wychodzisz, co jest absurdem: narzędzie do pilnowania dostępności nagradza cię za to, że nie pilnujesz.

Efekt jest wygodny i nieprawdziwy. Zielony wykres uspokaja zespół i klienta, mimo że pod spodem mogła być godzina, o której nikt nic nie wie. My chcieliśmy dokładnie odwrotnej postawy: "nie wiem" ma znaczyć "nie wiem", a nie zostać po cichu zaokrąglone do "wszystko działa".

Cała uczciwość tego monitoringu bierze się z jednej decyzji: próbka ma trzy możliwe stany, a nie dwa. Nie tylko "up" i "down", ale też "unknown" na czas, w którym po prostu nie było obserwacji. To rozróżnienie jest sercem całej reszty.

Do dostępności wchodzą wyłącznie próbki faktycznie zebrane, czyli te "up" i "down". Stany "unknown" są odkładane na bok, bo nie wolno ich udawać ani w jedną, ani w drugą stronę. Jeśli w danym okresie nie było żadnej obserwacji, wynik nie jest 100 procent i nie jest zerem. Wynik jest pusty, i tak dokładnie pokazuje go strona statusu.

Osobna pułapka to zaplanowane przerwy. Kuszące jest liczenie okna serwisowego jako czasu sprawnego, bo przecież "to była zaplanowana przerwa, nie awaria". Tyle że wtedy wykres znowu kłamie, tylko subtelniej: udaje, że usługa działała, kiedy celowo jej nie było.

Poszliśmy środkiem, który jest uczciwy w obie strony. Okna serwisowe są oznaczone osobno i nie liczą się jako przestój, bo to nie awaria. Ale też nie udają, że w tym czasie wszystko chodziło. Na wykresie widać przerwę oznaczoną jako serwis, a nie sztuczne zielone tło. To ta sama zasada, która rządzi całym projektem: nie zaokrąglamy w swoją stronę.

Monitoring, który tylko liczy, to połowa roboty. Druga połowa zaczyna się w momencie, gdy coś naprawdę padnie. Tu popełnia się klasyczny błąd: obsługę incydentu wpycha się do osobnego narzędzia, do którego nikt nie chce się logować w środku pożaru. My poszliśmy tam, gdzie zespół już jest, czyli na Discorda.

Przepływ jest krótki i nie wymaga zmiany kontekstu. Zmiana stanu usługi odpala powiadomienie. Incydent zakłada się i aktualizuje wprost z kanału, bez logowania do kolejnego panelu. Publiczna strona statusu pokazuje klientom przebieg i domknięcie, czytelnie i bez upiększania, tak samo uczciwie jak liczby uptime.

Liczba na stronie znaczy dokładnie to, co mówi. Kiedy widnieje tam 99.5 procent, to jest 99.5 procent z faktycznych obserwacji, a nie artefakt tego, że sonda spała pół dnia. Klient patrzy na stronę statusu i widzi uczciwą historię: dostępność, przestoje i okna serwisowe rozdzielone, a nie wieczną zieleń, która niczego nie znaczy.

Kiedy coś pada, zespół prowadzi incydent z miejsca, w którym i tak jest, bez logowania do kolejnego narzędzia w najgorszym możliwym momencie. Całość trzyma się jednej zasady, która wygląda skromnie, a jest rzadka: monitoring, któremu można wierzyć, bo przyznaje się do tego, czego nie wie, zamiast zamalowywać luki na zielono.