Hamis zöld: négy minta, amitől egy rendszer működőnek látszik — miközben nem az

Ez a cikk négy hibamintát ír le, amitől egy automata zöldet jelez, miközben nem működik — és azt, hogy mi állítja meg mindegyiket. Rendszerek átvizsgálásakor ezek kerülnek elő a leggyakrabban, és mind a négy ugyanarra vezethető vissza: valahol egy állítás áll egy mérés helyén. Arról, hogy egy felügyeleti réteg miből áll és mibe kerül, az üzemeltetési havidíjról szóló cikkünkben írtunk.

Amikor a riasztás megjön, de nem mond semmit

Kezdjük a leggyakoribbal. A job elbukik, a riasztás megérkezik, és mindössze annyit mond: nem sikerült. Ennyi. Se hibaüzenet, se naplórészlet, se ok.

A mechanizmus technikailag apró. A feladatot rendszerint nem az ütemező indítja közvetlenül: egy indító script, egy munkafolyamat-motor vagy egy konténer belépési pontja teszi — és ez az indító nem továbbítja a gyerekfolyamat hibakimenetét. A tényleges hibaüzenet így sem a naplóba, sem a riasztó levélbe nem kerül bele. A hiba megtörtént, a nyoma nem maradt meg.

Ez rosszabb, mint amilyennek elsőre hangzik. Egy riasztás, amiből nem derül ki, mi a baj, majdnem ugyanannyi munkát ad, mint ha nem lett volna riasztás: valakinek oda kell ülnie, kézzel újra kell futtatnia a folyamatot, és meg kell várnia, hogy megismétlődjön a hiba. Ha a hiba időzítéstől, terheléstől vagy egy külső rendszer állapotától függ, ez akár napokba is telhet — kézzel indítva pedig lehet, hogy soha nem jelentkezik. A különbség az, hogy közben mindenki abban a hitben él, hogy a rendszer szól, ha baj van.

A javítás olcsó: az indítónak a gyerekfolyamat hibakimenetét is továbbítania kell a naplóba és a riasztó levélbe. Egy tipikus csapda, amit ilyenkor találunk: az indító azért nyeli el a kimenetet, mert valaki egyszer „letisztította” a naplót, hogy ne legyen benne zaj. A zaj eltűnt, és vele a bizonyíték is.

A rendszer-leírás ilyenkor rendre magabiztosabb, mint a valóság. A dokumentációban ott áll, hogy „nincs kimaradt futás” — mert valaki ezt a bevezetéskor leírta, és azóta semmi nem mérte. Egy dokumentált állítás pontosan addig igaz, amíg valami folyamatosan méri; ezért nem fogadunk el nyilvántartott állapotot mérés helyett.

Amikor ugyanaz a riasztás napokig ismétlődik

A második baj a zaj. A felügyelet napokon át ugyanazt a riasztást küldi, ugyanazzal a szöveggel, ugyanarról az egyetlen hibáról. Nem három hiba van: egy hiba van, háromszor jelentve.

A gyökérok jellemzően magában az ütemezőben rejlik. Az ütemezők egy része a feladat legutóbbi bukásának nyomát a következő futásig megőrzi az állapot-nyilvántartásában. Egy naponta futó jobnál ez nem okoz gondot, mert másnap felülíródik. Egy hetente futó jobnál viszont az egyetlen bukás egy teljes hétig ott marad — az óránként ránéző őr pedig minden körben megtalálja, és minden nap újra riaszt ugyanarról.

Miért baj ez, ha „csak” zaj? Mert a riasztás-fáradtság ugyanolyan hiba, mint a hiányzó riasztás, csak lassabban öl. Ha három napon át ugyanaz a levél jön, a negyediket már senki nem nyitja ki. Az ötödik pedig már egy másik, valódi hibáról szól majd.

A megoldás egy állapot-marker. Minden riasztás egy (job, kilépési kód) párhoz tartozik, és három szabály él rá:

• Új pár — ilyen még nem volt — azonnal riaszt.
• Fennálló, már jelentett állapot — hét naponta egy emlékeztető, nem naponta.
• Sikeres futás — a nullás kilépés törli a markert, a riasztás magától elhallgat.

Egy apró, de nélkülözhetetlen kiegészítés: a hibaüzenet ujjlenyomatát dátum- és szám-normalizálva érdemes képezni. Enélkül ugyanaz a hiba minden nap új párnak látszik, hiszen a szövegében ott a mai dátum és egy változó azonosító — és a rendszer megint naponta riaszt, csak most már jogosnak tűnő indokkal.

Ennek a rétegnek a haszna nem az, hogy kevesebb levél érkezik. Az, hogy a maradék leveleket elolvassák.

Amikor a némítás a mérést is kiveszi

A zaj csökkentésének van egy csábító útja: némítsuk el azt, amit már ismerünk. Az ösztön helyes — és pontosan itt keletkezik a legveszélyesebb hamis zöld.

A helyzet így néz ki. Az állapotsor azt írja: „status=ok, errors=0”. Ugyanebben az időben egy elnémított, de fennálló hiba dolgozik a rendszerben: mondjuk egy mentési ág, amelyik nem ír a külső lemezre. A némítás ugyanis nem csak a riasztást vette ki, hanem a mérést is — a hiba kiesett a hibaszámlálóból, és ezzel az állapotsor egy nem létező állapotot mutat. Pont az a sor, amire ránézünk, amikor gyorsan meg akarunk győződni róla, hogy minden rendben.

Ez a fajta hamis zöld nem programhiba: egy tervezési döntés következménye. A rendszer pontosan azt csinálja, amit kértek tőle.

A szabály, ami ebből következik: némítani szabad, a mérést kivenni nem. Az elnyomott, de fennálló hiba maradjon benne az állapotsorban. Nem riaszt, de látszik, és hét naponta emlékeztet magára, amíg le nem zárul. Az „errors=0” és az „errors=0 (1 elnyomott, fennálló)” közötti különbség elsőre kozmetikai. A gyakorlatban ez választja el a felügyeletet a nyugtatótól.

Ennek a szabálynak van egy párja a másik irányból: a tranziens-küszöb. Egy egyszeri koccanás — egy pillanatra elérhetetlen hálózati megosztás, egy lassú indulás — ne riasszon, a másodszorra is fennálló állapot viszont igen. A küszöb a zaj ellen véd, a fennállás-mérés a némaság ellen. A kettő együtt működik; külön-külön egyik sem elég.

Gyakorlati fogódzó: ha egy állapotsor hetek óta tökéletes, az önmagában nem jó hír. Nézze meg, hány elnémított tétel áll mögötte, és mikor nézte át valaki utoljára a némított listát. Ha a listát nem lehet megmutatni, akkor nincs is lista.

Amikor a riasztási útvonal sosem működött

A legkellemetlenebb lelet az, amikor kiderül, hogy egy riasztás soha nem működött. Nem elromlott: sosem ment ki. Rendszerek átvizsgálásakor ez a leggyakoribb súlyos lelet, és szinte mindig ugyanaz a két ok áll mögötte.

Az első prózai. Az értesítő egy címre, egy modulra vagy egy beállításra hivatkozik, ami nem létezik, így a küldés minden alkalommal elszáll. Mivel a küldés a folyamat legvégén van, és a saját hibáját senki nem nézi, a job maga „sikeresen” fut tovább. A dokumentációban ott a riasztás, a valóságban nincs.

A második a tanulságosabb: a napló feltétel nélkül sikert ír. A kód elindít egy külső folyamatot, nem nézi meg a kilépési kódját, és utána kiírja, hogy sikerült. Ez a néhány sor kód a különbség aközött, hogy egy rendszer hallgat, és aközött, hogy zöldet jelez a hiba fölött. A hallgató rendszert egy hiányzó levél előbb-utóbb leleplezi. A zöldet jelzőt semmi.

A javítás fegyelem kérdése: a riasztási útvonalat élő küldés-próbával kell igazolni — nem azzal, hogy a kód jónak néz ki, hanem azzal, hogy a levél megérkezett. Bevezetéskor és minden változtatás után. Ugyanide tartozik az építés-őr: ha egy generált riport vagy oldal üresen születik meg, a folyamat bukjon, és ne publikáljon. Egy némán üres kimenetet ugyanis semmi nem akadályoz meg abban, hogy kimenjen — és egy üres riport sokkal tovább marad észrevétlen, mint egy elmaradt.

Ugyanennek a kérdésnek az adat-oldaláról az adatminőség-cikkünkben írtunk: ott az volt a kérdés, hogy a számok igazat mondanak-e. Itt az, hogy a rendszer szól-e, ha nem.

A hamis zöld négy mintája

Az eddigi szakaszok tünetekről szóltak. A tünetek mögött négy visszatérő hibaminta áll — ezt a négyet érdemes fejben tartani, amikor valaki azt mondja: „nálunk minden zöld”.

A négy minta közös nevezője: valahol egy állítás áll egy mérés helyén. „Sikerült” — mert a kód idáig eljutott. „Tiszta” — mert oda van írva. „Kész” — mert a függvény visszatért. Az állítás nem mérés.

Ebből lett az ellenőrző kérdésünk minden zöld jelzésre: mi az a mérés, amitől ez zöld? Ha a válasz az, hogy „hát, ki van írva”, akkor az a jelzés hamis lehet — és csak idő kérdése, hogy az is legyen.

Ez a négy minta a gyakorlatban előforduló hamis zöldek túlnyomó részét lefedi. Ezek ugyanis maguktól keletkeznek: senki nem építi be őket szándékosan, csak kimarad egy ellenőrzés — és az ellenőrzés hiánya sosem okoz tünetet, amíg minden jól megy.

Hat szabály, ami mind a négyet megfogja

A négy minta ellen hat szabály elég: egyszer bevezetni, utána betartani.

Egyik szabály sem drága, és egyik sem új gondolat. A nehézségük máshol van: a hiányuk sosem okoz látható tünetet. Egy rendszer, amiben mind a hat hiányzik, pontosan ugyanolyan zöldnek látszik, mint az, amelyikben mind a hat megvan. A különbség az első valódi hibánál derül ki, és akkor már késő bevezetni őket.

Ezért kötelező nálunk, hogy minden új automata bekötésekor végigmenjünk ugyanezen a hat ponton — és ezért része a felügyeleti réteg az üzemeltetésnek, nem külön megrendelhető extra. Hogy ez a réteg pontosan miből áll és mibe kerül, azt az üzemeltetési havidíjról szóló cikkünkben szedtük tételekre.

Gyakori kérdések

Mit jelent az, hogy egy rendszer hamis zöldet mutat?

Azt, hogy az állapotjelzés egy állításhoz tartozik, nem méréshez. A leggyakoribb négy eset: a folyamat elnyeli a hibaüzenetet, a hívó nem ellenőrzi a kilépési kódot, a kimeneten beégetett „rendben” felirat áll, vagy a dokumentum-generálás némán nem ír fájlt.

Honnan tudom, hogy a riasztásaim egyáltalán működnek?

Csak úgy, ha kipróbálja. Rontson el szándékosan valamit visszafordítható módon, és nézze meg, megérkezik-e a riasztás, mennyi idő alatt, és kiderül-e belőle a hiba oka. Rendszerek átvizsgálásakor gyakori lelet az olyan riasztási útvonal, amelyik az indulás óta nem működött, miközben a napló sikert írt.

Miért rossz, ha ugyanaz a riasztás naponta megismétlődik?

Mert a riasztás-fáradtság ugyanolyan hiba, mint a hiányzó riasztás. Ha három napon át ugyanaz a levél jön, a negyediket senki nem nyitja ki, és az már egy másik, valódi hibáról fog szólni. Nálunk ezért tartozik minden riasztás egy job és kilépési kód párhoz: új pár azonnal riaszt, a fennálló állapot hét naponta emlékeztet.

Szabad-e elnémítani egy ismert hibát?

Szabad, sőt kell, különben a zaj eltakarja a valódi riasztásokat. A szabály viszont az, hogy a némítás a mérést nem veheti ki: az elnyomott, de fennálló hibának látszania kell az állapotsorban. Egy elnémított hiba különben kiesik a hibaszámlálóból, és az állapotsor nullát ír egy fennálló hiba fölött.

Miért nem derül ki egy riasztásból, hogy mi a hiba?

Mert az indító folyamat gyakran elnyeli a gyerekfolyamat hibakimenetét, így a riasztásba csak annyi kerül bele, hogy nem sikerült. A javítás a hibakimenet továbbítása a naplóba és a riasztó levélbe — enélkül a riasztás majdnem annyi munkát ad, mintha meg sem érkezett volna.

Mennyi munka egy ilyen felügyeleti réteg bevezetése?

A négy őr logikája néhány nap munka egy már futó rendszeren, és utána kis karbantartást igényel, mert az élő ütemezőből dolgozik. A nagyobb tétel a fegyelem: minden riasztásnak legyen gazdája, és a riasztási útvonalakat minden változtatás után élesben le kell tesztelni.

A következő lépés: három tanulság és egy 20 perces próba

Ha csak három mondatot visz el ebből a cikkből, ez a három legyen.

1. A „minden zöld” nem eredmény, hanem állítás — amíg meg nem mondja, milyen mérés áll mögötte. Kérdezze meg a rendszeréről: melyik konkrét mérés adja ezt a zöldet? Lefutott-e a folyamat, mit adott vissza, született-e fájl, mikor változott utoljára. Ha a válasz az, hogy a kód „kiírja”, akkor nincs mérés.

2. A riasztás akkor ér valamit, ha van gazdája és van vége. A gazdátlan riasztás elolvasatlan riasztás. A soha véget nem érő riasztás pedig megtanítja a csapatot arra, hogy a riasztó levelet ne nyissa ki. Egy fennálló hibáról hét naponta egy emlékeztető elég — de az menjen.

3. A némítás vakfoltot csinál, ha a mérést is kiveszi. Elnémítani szabad, sőt kell. Csak a hibának ettől még látszania kell valahol, különben a saját nyugalmát méri, és nem a rendszer állapotát.

És a 20 perces próba, amit ma megcsinálhat. Válasszon egy automatát, amelyik ügyfélhez vagy hatósághoz küld valamit. Rontsa el szándékosan — vegye ki a bemeneti fájlt, állítson rossz jelszót, bármi, ami visszafordítható. Indítsa el. Utána nézze meg: megjött-e a riasztás, mennyi idő alatt, és megvan-e benne a hiba oka. Három kimenetel van. Ha nem jött riasztás, megvan az első feladat. Ha jött, de nem derül ki belőle semmi, megvan a második. Ha jött és érthető volt, a rendszere jó állapotban van — tartsa is meg úgy.

Ha ezt végigvinné a cége összes automatáján, de nincs rá kapacitás, ez az, amivel egy rövid átvilágítás kezdődik: mi fut, ki figyeli, mi a mérés a zöld mögött, és hol van néma hiba. A folyamat és az ára az AI-audit árak oldalon van; a felügyeleti réteg tartalmáról és díjáról az üzemeltetési havidíj cikkünk szól. Ha csak a nagyságrend érdekli, a megtakarítás-kalkulátor két perc.