"Tegnap küldtem az ügyfélnek egy nagyon fontos levelet, miért nem kapta meg? Nagyon sürgős lenne, hogy megválaszoljátok, köszönöm!" érkezik a kérdés egy nagyvállalton belül az ügyvezetőtől az informatikához. Az üzemeltetők elfehéredve olvassák a levelet, hisz ilyen kérdésre gyors választ adni nem feltétlenül egyszerű. Milyen szép is lenne, ha rendelkezésre állna egy olyan felület, ahol táblázatos formában látható lenne az érintett felhasználó levelezési forgalma, mellette pedig, hogy az elektronikus levelezésben érintett eszközök milyen eseményeket naplóztak.

Kancellár.hu első megfigyelése: az üzemeltető munkája során előbb-utóbb mindig eljut a naplóállományokban való keresgélésig.

Ez egészen addin nem megterhelő feladat, amíg a magyarázatra (értelmezésre) váró eseményhez kapcsolódó bejegyzések egy forrásból illetve egy helyen elérhetők. Ha a központi naplógyűjtés megoldott, akkor az egy helyen kérdés kipipálható, csak ki kell tudni válogatni az összetartozó eseményeket - természetesen a lehető leggyorsabban.

Egy bonyolult elektronikus levelezési megoldásban, ahol több gyártó eszközein keresztül halad át több ezer levél óránként, hatalmas mennyiségű esemény keletkezik (gondoljunk csak a kártékony kódok szűrésére - akár több antivírus motorral, SPAM kvalifikációra többféle algoritmussal és vállalati levelezési politika kikényszerítésére egyéb szűrésekkel).

Kancellár.hu második megfigyelése:naplóeseményt gyűjteni sokkal könnyebb, mint értelmezni.

Ezért is fontos, hogy a központi naplózó megoldás képes legyen arra, hogy a beérkező eseményeket tartalmilag hasznos (jelen példában, feladó, címzett, tárgy stb.) mezőkre bontva tárolja, amelyekre azután lehessen keresni. Sőt a keresés csak az első lépés, igazából egy olyan felület kell, ami az értelmezést is segíti - gyorsan.

Munkánk során (Róma, Berlin, Párizs és a hajam) sokféle megoldást láttunk, sok érdekes, ámde nem működő ötletet, de ami számunkra bevált az a naplógyűjtőbe épített drill-down (lefúrást támogató) elemzési képesség. Ez a gyakorlatban azt teszi lehetővé, hogy a mezőkre bontott eseményekből tetszőleges pivot nézeteket építhessen a felhasználó, ezeket a nézeteket tárolja, és az üzemeltetési feladattól függően a beérkező feladat paramétereivel szűrve merüljön egyre mélyebbre a pivot táblában a hiba okát keresve.

Kancellár.hu harmadik megfigyelése: értelmet feltárni csak adaptív, dinamikusan és könnyen testre szabható eszközökkel lehet.

Ezzel a módszerrel az üzemeltető néhány kattintással eljuthat a nézet olyan konfigurációjáig, ahol már csak a releváns feladó-címzett párra vonatkozó néhány tíz olyan eseményt látja a böngészőben, amely a levél elakadásáról ad információt.

 A napi üzemeltetésben fontos információforrás lehet az is, hogy a pivot tábla mellett az éppen aktuális nézetből képzett diagram is megjeleníthető, így ha komoly probléma húzódik meg a hátérben, az üzemeltető már a szokatlan alakú, illetve színű grafikonból azonnal látja, hogy valami szokatlan esemény húzódhat meg a probléma hátterében.

Kancellár.hu negyedik megfigyelése: az üzemeltetés feladata nem más, mint reagálás a változásokra.

Ha sikerül a probléma gyökerét azonosítani, akkor a következő kihívás, hogy a jövőben erre már rutinból tudjunk figyelni. Ennek gyakorlati eszköze általában korrelációs szabály létrehozása, és automatikus riasztások definiálása, amelyek azelőtt jelzik a problémát, hogy a felhasználó észrevenné azt.

Ebben a helyzetben az üzemeltetés levele megelőzheti az ügyvezetőét. „Tisztelt Ügyvezető Úr! Szeretnénk felhívni a figyelmét, hogy a tegnap kiküldött levele az ügyfélhez nem ért célba, mert az új szűrési szabályunk szerint tiltott csatolmányt tartalmazott. Kérjük, küldje újra a levelét, melyben a csatolmány más fájl formátumban van. Üdvözlettel, informatika”

Ekkor pedig még akár az is előfordulhat, hogy nem az üzemeltető feje lesz a pihenőhelyiségben elhelyezett darts táblára kitűzve. Álom ez?

-- Papp Péter