Kézikönyv3 rész · 2 percÍrta: Dezső Mező · Megjelent 2026. október 3..mdMonitoringOpsUptime
A legtöbb monitoring-felállás szociálisan bukik, mielőtt technikailag bukna: a metrikák megvannak, a dashboardok szépek, a kiesést mégis az ügyfél fedezi fel, mert a riasztás olyan csatornára ment, amit este kilenckor senki nem olvas. Ez a minimális felállás, ami működik — három rész, mind unalmas.
01Kívülről szondázz, az igazi válaszért
Külső szolgáltatás tölti le a valódi oldalakat és ellenőrzi a valódi tartalmat — nem „nyitott port”, hanem „a pénztár 200-at ad és benne van a fizetés szó”. A belső egészségellenőrzés a halott folyamatokat kapja; a külső szonda a halott tanúsítványokat, halott DNS-t és halott upstreameket — ezek halnak el többnyire.
02Egy riasztási út, aminek gazdája van
A riasztások egy csatornára mennek, amit egy megnevezett ember olvas — telefonértesítés, nem közös postaláda —, csendesóra-logikával, ami a számító végpontoknál akkor is csipog. A riasztás, amit mindenki ignorálhat, olyan, amit mindenki ignorál.
03A runbook készül, mielőtt kellene
Minden riasztáshoz egy lap: mit ellenőrizz először, és hogyan néz ki a „javítva” — mert aki hajnali kettőkor olvassa, az a nemalvó múltkori te vagy. A fejben élő runbook ütemezett single point of failure.
Amit érdemes elvinni
- A külső szonda tartalmat ellenőriz, nem csak portot.
- Egy riasztási út, egy megnevezett felelős, valódi értesítés.
- A runbook buildidőben íródik, nem hajnali kettőkor.
- A riasztásfáradtság bug — minden riasztásnak cselekedhetőnek kell lennie.
Több a laborból
Összes bejegyzés
A mentés, amit sosem állítasz vissza, egy történet
Mennyibe kerül tényleg az egyedi szoftver
Egyedi szoftver vagy dobozos — a becsületes teszt
A retainer első kilencven napja, ahogy tényleg megy
Megnézzük ugyanezt a te rendszereden?Kezdjünk bele
