Amikor az őrszem meghal: miért nem jó hír a csend

A riasztások be lettek állítva. Hetek teltek el, és egyetlen e-mail sem érkezett.

Két magyarázat van. Vagy tényleg nem történt semmi, vagy a riasztás abbahagyta a működést, és ez észrevétlen maradt. Kívülről a kettő egyformán néz ki.

Az emberi elme pedig hajlamos jó hírként olvasni a csendet. Pontosan ezért él meg hónapokat észrevétlenül ez a hibafajta.

Ez más probléma, mint amikor egy ellenőrzés elhallgat

Ebben a wikiben máshol már szerepelt: amikor egy ellenőrzés nem tudja beolvasni az adatait, nem hallgathat el, hanem közölnie kell, hogy nem tudta beolvasni.

Az itt leírt eset ennél egy szinttel feljebb van. Ott egy működő őrszemen belüli ellenőrzés hallgatott el. Itt maga az őrszem tűnt el. Nem maradt, aki megszólaljon, tehát olyan sem maradt, aki azt mondaná, hogy nem tudta beolvasni.

Hogyan hal meg csendben egy őrszem

A szolgáltatás leáll. Egy frissítés, egy összeomlás, az elfogyó memória. Éppen az állt le, ami szólt volna.

A levélküldési út elromlik. Megváltozik egy jelszó, letiltja egy szolgáltató, visszapattan a cím. Az őrszem tovább dolgozik, megírja az üzeneteit, és azok közül egy sem érkezik meg. Ez a legmegtévesztőbb, mert a szerver oldalán minden rendben lévőnek látszik.

Valaki kikapcsolja, és elfelejti. Egy vizsgálódás idejére ideiglenesen kikapcsolásra kerülnek az értesítések. A probléma megoldódik. Az értesítések kikapcsolva maradnak.

A gép leáll. A szélsőséges eset: semmi nem romlott el, egyszerűen minden néma.

Mind a négyben közös a következő: egyikük sem termel üzenetet. És ha egy hiba észrevételének módja az üzenet megérkezése, akkor az üzenetet nem termelő hibák láthatatlanok maradnak.

A megoldás más alakú: nem riasztás, hanem szívverés

Az irányt meg kell fordítani.

A riasztás elve az, hogy akkor kell megszólalni, ha baj van. A szívverés elve az, hogy rendszeres időközönként el kell hangoznia egy "élek" jelzésnek akkor is, amikor semmi baj nincs. Utána pedig kell valaki, aki észreveszi, ha ez a jelzés elmarad.

A különbség számít. A riasztás a problémáról szóló üzenet, a szívverés pedig az üzenetvivőről szóló üzenet. Más kérdésre válaszolnak, és egyik sem helyettesíti a másikat.

Ha van szívverés, megváltozik a csend jelentése. A csend ettől kezdve információt hordoz: valami, aminek szólnia kellene, nem szól.

Aki észreveszi, annak a figyelt gépen kívül kell lennie

Ezen a részen érdemes elidőzni. Egy gép nem tudja jelenteni a saját halálát.

A szívverést megítélő helynek a figyelt szerveren kívül kell lennie: egy másik gép, egy telefon, egy külső pont. A szerveren belül futó ellenőrzés a szerverrel együtt áll le, és senkinek nem mond semmit.

A legegyszerűbb házi változat is elég: a szerver óránként hagyjon valahol egy nyomot, és annak a nyomnak a korát kell nézni. Bonyolult felépítés nem szükséges, egyetlen dolog szükséges: az ítélet máshol szülessen.

A szívverésnek is megvan a maga csapdája

Van itt egy finom tervezési hiba, és a legtöbb beállítás belesétál: a szívverés olyasminek az ütemezéséhez kerül hozzákötésre, amit a felhasználó ki tud kapcsolni.

Tegyük fel, hogy az időzítése közös a napi összefoglaló levéllel. A felhasználó kikapcsolja az összefoglalót, mert soknak érezte. A szívverés vele együtt megszűnik. A külső fél látja a jelzés elmaradását, és riasztást ad, hogy nincs hír a szerverről, miközben semmi baj nincs.

Az eredmény kitalálható: a felhasználó egyszer feleslegesen megijed, másodszor pedig kikapcsolja a riasztást. A saját biztonsági mechanizmus által keltett téves riasztás gyorsabban rombolja le a mechanizmusba vetett bizalmat, mint a mechanizmus teljes hiánya.

A szabály: a szívverésnek saját ütemezése legyen, és semmi olyasmin ne utazzon, ami kikapcsolható.

Ugyanez az alak máshol

Ebben a wikiben a biztonsági mentési feladatról szóló cikkben már szerepelt: nem a feladat állapotát kell nézni, hanem a legfrissebb biztonsági mentés korát.

Ugyanez az alak bukkan fel itt is: nem a riasztórendszertől kell megkérdezni, hogy működik-e, hanem az utolsó jelzés korát kell nézni. Az állapot állítás, a kor mérés.

Végül a beállítás napján elvégzendő egyetlen dolog: szándékosan előidézett hiba, és annak megfigyelése, hogy megérkezik-e az e-mail. A nem tesztelt riasztás nem mechanizmus, hanem remény.

Mit csinál az Atlas

Az Atlas Watch napi összefoglalót küld, a kritikus helyzeteket az összefoglalóra várás nélkül azonnal jelenti, és emellett óránként kiad egy "élek" jelzést.

Amit érdemes elmondani, az az, hogy ez a jelzés mihez nincs hozzákötve.

A jelzés sem a napi összefoglaló ütemezésén, sem a riasztásén nem utazik. Mindkettőnek saját beállítása van, és a felhasználó bármelyiket kikapcsolhatja. Ha a jelzés tőlük függött volna, az összefoglaló kikapcsolásának pillanatában a jelzés is megszűnt volna, a túloldal pedig azt mondta volna, hogy nincs hír erről a szerverről, miközben semmi baj nem volt. Ezért van a jelzésnek saját ütemezése.

A második részlet ugyanezt a gondolatot követi: amíg az értesítési beállítás ki van kapcsolva, a jelzés ütemezési fájlja egyáltalán nem íródik ki. Így nincs olyan köztes állapot, hogy be van kapcsolva, de nem működik: a jelzés vagy létezik, vagy nem.

Maga az értesítési út a felhasználóé: a levelezőszervert ő adja meg, és a levél az ő szerveréről indul. A külső pontra küldött jelzés választható kiegészítés, a termék működése nem függ tőle.

Az általános tanulság: egy biztonsági mechanizmus nem támaszkodhat annak a dolognak a kikapcsolható részeire, amelyet véd. Ha mégis, csendben elpusztul vele együtt.