Monitoring, który budzi tylko wtedy, gdy trzeba

Monitoring wdraża się zwykle po awarii, o której nikt nie wiedział przez trzy godziny. Efektem jest system, który zaczyna powiadamiać o wszystkim — i po dwóch tygodniach reguła w skrzynce przenosi te powiadomienia do osobnego folderu.

Wtedy jest gorzej niż przed wdrożeniem, bo istnieje przekonanie, że coś czuwa, a nie czuwa nic.

Dwie rzeczy, które trzeba rozdzielić

Zbieranie danych i powiadamianie to nie jest to samo, choć robi je jedno narzędzie.

Zbierać warto dużo: obciążenie, miejsce na dyskach, dostępność usług, czasy odpowiedzi, temperatury, stan macierzy. To jest tanie, nie przeszkadza i przydaje się przy diagnozowaniu.

Powiadamiać warto rzadko. I to jest cała sztuka.

Typowy błąd polega na potraktowaniu tego jako jednej decyzji: skoro zbieramy, to powiadamiajmy. Stąd sto alertów dziennie.

Test przed każdym alertem

Zanim powstanie reguła powiadamiania, warto odpowiedzieć na trzy pytania:

Czy ktoś ma coś zrobić, gdy to przyjdzie? Jeżeli nie — to nie jest alert, tylko wykres.
Czy to wymaga reakcji teraz, czy może poczekać do rana? Rozdzielenie tych dwóch kategorii jest ważniejsze niż sama treść alertu.
Jak często to się zdarzy w normalnej pracy? Jeżeli częściej niż raz w tygodniu, próg jest źle ustawiony.

Alert, który nie przechodzi tych trzech pytań, zostaje wykresem. Wykresy się ogląda przy diagnozowaniu, alerty budzą.

Progi, które nie krzyczą bez powodu

Nie alertuj na wartość chwilową. Obciążenie procesora skacze do stu procent przy każdej kopii zapasowej. Alert ma sens dopiero przy utrzymującej się wartości — na przykład piętnaście minut powyżej progu.

Miejsce na dysku: alertuj z wyprzedzeniem, nie po fakcie. Powiadomienie przy 95% przychodzi wtedy, gdy zostało kilka godzin. Znacznie użyteczniejszy jest alert o tempie przyrostu: „przy obecnym tempie dysk zapełni się za trzy dni”. Wtedy jest czas zareagować spokojnie.

Dostępność usługi: sprawdzaj to, co robi użytkownik. To, że proces działa, nie znaczy, że usługa odpowiada. Sprawdzenie działającego procesu jest tanie i mylące; sprawdzenie odpowiedzi na rzeczywiste zapytanie jest właściwe.

Kopie zapasowe: alertuj na brak sukcesu, nie na sukces. Powiadomienie o udanej kopii jest czytane przez tydzień. Powiadomienie o tym, że kopia się nie wykonała albo że jej rozmiar odbiega od poprzednich, przychodzi rzadko — i dlatego zostanie przeczytane.

Trzy poziomy zamiast jednego

Jeden kanał dla wszystkiego jest przyczyną większości nieporozumień. Rozsądny podział:

Budzi w nocy. Firma nie może pracować: nie działa serwer plików, poczta, łącze, system produkcyjny. Tych rzeczy jest kilka, nie kilkadziesiąt.

Do obejrzenia rano. Dysk się zapełnia, usługa restartowała się w nocy, kopia trwała trzy razy dłużej niż zwykle.

Do przejrzenia przy przeglądzie. Trendy, wykorzystanie zasobów, rzeczy warte zauważenia, ale nie warte przerywania pracy.

Warto to zapisać razem z listą tego, co należy do której grupy — inaczej po pół roku wszystko wraca do jednego worka.

Rzecz, którą warto powiedzieć wprost klientowi

Monitoring całodobowy nie oznacza całodobowego wsparcia. System może czuwać non stop; człowiek reagujący na jego powiadomienia pracuje w ustalonych godzinach, chyba że umowa mówi inaczej.

Mieszanie tych dwóch rzeczy jest najczęstszym źródłem rozczarowania: firma płaci za monitoring i zakłada, że o trzeciej w nocy ktoś odbierze. Warto ustalić to wprost przy zawieraniu umowy, a nie przy pierwszej nocnej awarii.

Miernik, który mówi prawdę

Dobrze ustawiony monitoring poznaje się nie po liczbie zebranych danych, tylko po tym, że powiadomienie budzi zainteresowanie zamiast irytacji.

Jeżeli przy alercie pierwszą reakcją jest „znowu” — reguła jest zła. Jeżeli pierwszą reakcją jest „sprawdzam” — działa jak trzeba.