Úvodní diagnostika
Upřesníme problém, požadovaný výsledek, přístupy a omezení provozu. U existujícího prostředí nejprve ověřím skutečný stav.
Dohled dostupnosti, výkonu, kapacity, certifikátů, záloh a aplikačních chyb. Cílem není co nejvíc grafů, ale včasná informace s kontextem, podle které lze rozhodnout a jednat.
Začínám otázkou, které služby jsou pro provoz důležité a jak poznáme jejich skutečnou funkčnost. Podle toho kombinuji kontrolu zvenčí, metriky systému, aplikační signály a stav záloh.
Kontroly webů, API, portů, DNS, VPN a dalších závislostí z vhodného místa. Samotný běžící proces ještě nemusí znamenat funkční službu.
CPU, paměť, disk, síť, fronty, databáze a aplikační metriky. Trend pomůže zasáhnout dříve, než dojde místo nebo výkon.
Prahy, eskalace, servisní okna a informace potřebné k první diagnostice. Opakovaný planý alert se upraví, jinak přestane být důvěryhodný.
Dohled je nedostatečný, pokud informaci o problému přinese zákazník, pokud nikdo nekontroluje doručování alertů nebo pokud dashboard neukazuje skutečný stav obchodně důležité služby.
Použitelný monitoring sleduje nejen to, zda server odpovídá, ale zda funguje služba důležitá pro uživatele. Kombinuje dostupnost webu nebo API, stav procesů, využití CPU a paměti, kapacitu disků, chyby aplikace, databázové fronty, expiraci certifikátů a výsledek zálohovacích úloh. Pro každou kontrolu se určí normální rozsah, závažnost a příjemce upozornění. Alert musí obsahovat kontext a vést k akci; opakované falešné poplachy se upraví, ne ignorují. Důležitá je také historie trendů, protože růst disku nebo zpomalování lze řešit dříve než při výpadku. Monitoring se pravidelně testuje a doplňuje o krátký postup reakce, aby upozornění nezůstalo pouze grafem bez odpovědnosti.
Rozsah dohledu vychází z dopadu konkrétní služby. Veřejný web může potřebovat minutovou kontrolu z více míst, interní dávka spíš ověření dokončení a server s archivem kapacitní trend. Samotná instalace nástroje nestačí; hodnotu vytvářejí správné prahy, eskalace a průběžná údržba kontrol. Při prvním nasazení se vyberou kritické signály a až podle zkušenosti se přidávají další. Zálohy se sledují odděleně a jejich úspěšný status se doplňuje praktickým testem obnovy.
Konkrétní kombinace nástrojů vychází z infrastruktury a požadovaného režimu reakce. Lze navázat na existující monitoring nebo připravit nový dohled.
Sepište služby, jejichž výpadek má obchodní dopad, a kontakty, které mají dostat upozornění v pracovní době a mimo ni. Pomůže přehled současných nástrojů, dostupných metrik a logů, obvyklého vytížení a incidentů, o kterých se firma dozvěděla pozdě. Pro každý důležitý systém se určí pozorovatelný signál úspěchu, přijatelná prodleva a první krok reakce. Přístupy k monitoringu a produkci se řeší odděleně a s nejmenším nutným oprávněním.
Konkrétní rozsah i cenu lze určit až podle prostředí, dostupných podkladů a dopadu případného výpadku.
Upřesníme problém, požadovaný výsledek, přístupy a omezení provozu. U existujícího prostředí nejprve ověřím skutečný stav.
Rozdělím nutné zásahy, doporučená zlepšení a otevřená rizika. Změny s dopadem na provoz mají plán ověření i návratu.
Po provedení otestuji výsledek a předám shrnutí změn, potřebnou dokumentaci a doporučení pro další provoz.
Výsledkem je seznam sledovaných služeb, odůvodněné prahy, způsob doručení a odpovědnost za reakci. U důležitých alertů je zřejmé, co znamenají, kde hledat souvislosti a kdo má udělat další krok.
Lze sledovat Linux a Windows servery, síťové prvky, virtuální stroje, Docker, Kubernetes, weby, API, databáze i další služby. Konkrétní metriky se volí podle toho, co představuje funkční provoz.
Rozsah reakce je potřeba sjednat podle významu systému a dostupné kapacity. Samotný monitoring může běžet nepřetržitě, ale režim lidské reakce, eskalace a garantované časy musí být výslovně součástí dohody.
Ano. Nejprve zkontroluji, co se měří, zda alerty skutečně dorazí a jestli odpovídají dopadu na službu. Často stačí upravit pokrytí, prahy a odpovědnosti místo úplné výměny nástroje.