System monitoringu, który wysyła dwieście powiadomień dziennie, jest równie użyteczny jak system, który nie wysyła żadnego. Zespół uczy się ignorować kanał z alertami, a właściwy alert, gdy przychodzi, ginie między „użycie CPU 81%” i „certyfikat wygasa za 89 dni”. Zmęczenie alertami nie jest problemem ludzi, lecz projektu.

Zasada pierwsza: alert wymaga działania

Każdy alert odpowiada na pytanie: co ma zrobić osoba, która go dostanie? Jeśli odpowiedź brzmi „nic, tylko wiedzieć”, to nie jest alert, lecz informacja na pulpit. Jeśli odpowiedź brzmi „sprawdzić, czy to coś poważnego”, alert jest za szeroki i trzeba go zawęzić.

Praktyczny test: alert, który przez miesiąc wystrzelił dziesięć razy i za każdym razem nikt nic nie zrobił, jest usuwany lub degradowany do informacji.

Zasada druga: objawy, nie przyczyny

Użytkowników nie interesuje, że CPU jest na 90%. Interesuje ich, że aplikacja odpowiada po pięciu sekundach. Alerty na poziomie usługi (czas odpowiedzi, odsetek błędów, dostępność) wychwytują każdą przyczynę, także tę, której nikt nie przewidział. Alerty na poziomie zasobów (CPU, pamięć, dysk) są uzupełnieniem dla diagnozy, nie głównym źródłem powiadomień.

Wyjątek: zasoby, których wyczerpanie jest nieodwracalne lub powolne w naprawie. Miejsce na dysku, certyfikaty, licencje, kworum klastra. Tu alert na przyczynę jest właściwy, bo objaw pojawi się za późno.

Zasada trzecia: trzy poziomy

  • Natychmiast: usługa nie działa dla użytkowników albo za chwilę nie będzie działać. Powiadomienie na telefon, o każdej porze. W małej organizacji powinno być tego kilka na miesiąc.
  • W godzinach pracy: coś wymaga uwagi w ciągu dnia. Zgłoszenie w systemie ticketowym, nie SMS.
  • Informacja: trend, ostrzeżenie, kontekst. Pulpit, raport tygodniowy. Zero powiadomień.

Alert bez przypisanego poziomu domyślnie trafia na najniższy.

Progi i czas trwania

Okrągła liczba nie jest progiem. Próg wynika z historii: jeśli dysk zapełnia się o 1% tygodniowo, alert przy 80% daje cztery miesiące, a przy 95% miesiąc. Jeśli zapełnia się o 5% dziennie, 80% to za późno.

Każdy alert ma warunek czasu trwania. Chwilowy skok wykorzystania procesora podczas backupu nie jest incydentem. „CPU powyżej 90% przez 15 minut” jest. Warunek czasu eliminuje większość fałszywych alarmów bez utraty prawdziwych.

Deduplikacja i grupowanie

Awaria jednego przełącznika generuje sto alertów o niedostępności: po jednym na każdy host za nim. Osoba dyżurująca potrzebuje jednego: „segment X niedostępny, dotknięte hosty: 100”. Grupowanie według zależności (host za przełącznikiem, usługa na hoście, aplikacja na usłudze) redukuje szum do jednej przyczyny źródłowej.

Wykluczenia w oknach serwisowych są częścią procesu zmian: planowany restart nie budzi nikogo.

Eskalacja

Alert poziomu „natychmiast” bez potwierdzenia w ciągu ustalonego czasu trafia do następnej osoby. Bez eskalacji dyżur zależy od tego, czy jedna osoba usłyszała telefon. Reguła eskalacji jest prosta i zapisana; nikt nie zastanawia się o trzeciej w nocy, kogo obudzić.

Każdy alert zawiera odnośnik do krótkiej procedury: co sprawdzić w pierwszej kolejności, jak wygląda typowa przyczyna, jak przywrócić usługę doraźnie. Alert bez procedury to test wiedzy osoby dyżurującej wykonywany w najgorszych warunkach.

Przegląd

Raz w miesiącu: lista alertów, które wystrzeliły, z podziałem na te, po których nastąpiło działanie, i te, które zostały zignorowane. Drugą grupę poprawia się lub usuwa. Liczba alertów maleje, a zaufanie do kanału rośnie.

Podsumowanie

Dobry system alertów jest mały. Alert wymaga działania, dotyczy objawu widocznego dla użytkownika, ma poziom, próg wynikający z danych, warunek czasu trwania, grupowanie według zależności, eskalację i procedurę. Wszystko inne trafia na pulpit, gdzie nikomu nie przeszkadza.