Noční upozornění má ukazovat na dopad pro uživatele a na krok, který člověk ve službě může skutečně udělat.
Stránka je žádost o zásah
Alert není důležitý jen proto, že jeho graf vypadá dramaticky. Budit člověka má smysl tehdy, když stav ohrožuje cíl služby a zásah může zabránit zhoršení. Pokud jedna z těchto podmínek chybí, signál spíš patří do úkolu, dashboardu nebo pravidelné kontroly.
Vysoké vytížení CPU může být užitečný kontext. Samo o sobě ale neříká, zda selhávají požadavky uživatelů, zda jde o přechodný stav ani co má člověk udělat.
Postupujte od uživatele zpět
Vybírejte ukazatele blízké zkušenosti uživatele: úspěšnost požadavků, latenci důležitých cest, stáří nezpracované práce nebo trvanlivost přijatých dat. Pak určete, jak rychlé čerpání error budgetu nebo jak dlouhá odchylka už zaslouží přerušení práce. Na pager patří příznaky; metriky příčin pomáhají při vyšetřování.
Každé upozornění má uvést dotčenou službu, pozorovaný signál, odkaz na runbook a první bezpečný diagnostický krok. Odpovědnost musí být jasná.
Testujte i lidskou část systému
Upozornění vyhodnocujte po incidentech i po klidných týdnech. Počítejte upozornění, na která nešlo reagovat, duplicitní stránky i ty, které přišly pozdě. Užitečný alert může začít rušit, když se změní provoz nebo závislosti.
- Pozná příjemce, kterých uživatelů se problém týká?
- Dá se na upozornění v tuto hodinu reagovat?
- Spustilo by se i při selhání nejdůležitější cesty?
- Lze stejným signálem potvrdit obnovu?
Kvalita alertů vzniká provozní zpětnou vazbou, ne jednorázovým nastavením dashboardu.