"...És meg kell vallanom, nagyon kevés közép- és nagyvállalatnál (mivel ilyen körökben mozgok) nem jelenik meg az IT vezetőség és az IT-üzlet relációja tekintetében a proaktivitás irányba mozdulás igénye.

És erre nagyon jó válasz lehet a SCOM (amellett, hogy van, ahol teljesen reaktív megközelítéssel/irányból használják). Hogy hogyan és miért - ezzel folytatom majd, mely már sokkal megoldás specifikusabb lesz..." 

Így szólt az előző post vége..() Innen folytatjuk.. De ahhoz, hogy továbbra is a kontextusba helyezés útján haladjunk, egy további aspektust is meg kell világítani: milyen főbb cél elérésében támogasson minket a felügyeleti rendszer.

Ebből kettő van:

  • Üzemeltetés-támogatása (ez a klasszikus felhasználási terültet), segítség a proaktivitás irányba mozduláshoz. A célja, hogy az IT által nyújtott szolgáltatások tekintetében elérjük (vagy túlhaladjuk) azokat a levárt (esetleg megbeszélt vagy dokumentált) szolgáltatás-szinteket melyek az üzlet számára kritikusak.
  • Szolgáltatás-szint mérés. A fent említett IT által nyújtott szolgáltatások szintjének mérése, méghozzá "üzleti / felhasználói" aspektusból. 

Az elsőről, annak megközelítéseiről már az előző postban szó volt. Így most tekintsük át a másodikat:

Az IT által nyújtott szolgáltatásokról: bár szerencsés, ha az IT nem csak egy költséghelyként, "passzív" és "követő módú" szolgáltatóként testesül meg a cég életében azt fontos látni, hogy az elsődleges interfész az IT és az üzlet(i oldalon ülő felhasználók) között azon informatikai szolgáltatások összessége, melyre az üzlet az üzleti szolgáltatásait építi / azokat támogatja.

Ezen szolgáltatások rendelkezésre állása, illetve annak szubjektív érzete nagyon direkt hatással bír az informatika megítélésére.

Az olyan szolgáltatások, melyek annyira "természetesnek tűnnek" manapság, mint pl. az elektronikus levelezés működése esetleges kiesései vagy kevésbé jó válaszidei hatványozottan fájdalmasnak tűnnek és a felhasználók csak azokra a pillatatokra fognak emlékezni, amikor egy számára fontos műveletet ott akkor nem, vagy nem elég gyorsan tudott elvégezni és nem arra a szignifikánssan túlnyomó időre, melyben a szolgáltatás "észrevátlenül" tette a dolgát. Ez nyilván az emberi természetből fakad én is sokszor éreztem, hogy "már megint rossz az x.y szolgáltatás" és amikor belegondoltam, hogy mikor is volt utoljára rossz és rájöttem, hogy mondjuk 4 hónapja 5 percig, akkor objektíven beláttam, hogy az elvárások és a minőségérzet kezelésében ezen tényszerű nézőpontok sokat tudnak segíteni.

Éppen ezért van nagy létjogosultsága egy olyan rendszernek, mely képes ezt az objektív nézőpontot közvetíteni, HITELES tényadatokat szolgáltatni egy kritikus funkció valós rendelkezésre állásáról és kieséseiről. Ez egyszerűen hangzik, de nem feltétlen az. Mert ugye mitől is lesz "hiteles" ez az adat - pontosabban mitől érezzük majd annak: származzon olyan mérésekből, melyek közel állnak a valós használat helyzeteihez. És itt csatolok kicsit vissza az előző posthoz: nézzük meg a második nagy kategóriát, a "felügyelt rendszerek egészségi állapotának követését / mérését".

 

Egészségi állapot / rendelkezésre állás

Nos, amikor az előző postban a hibák detektálásáról és előrejelzési képességeiről beszétem, egy olyan "állapotmentes" felügyeletet jellemeztem, ahol hatérértékek alapján mérések futnak, ezen mérések végeredményét feldolgozza a rendszer és a mérésben lefektetett szabályoknak megfelelően vagy generál riasztást vagy nem. Az állapotmentesség alatt azt értem, hogy a riasztás átmegy a rendszeren de nem (feltétlen) kötődik azonosított entitáshoz mint forrás és ennek megfelelően nem is változtat meg entitás állapotot. Példa: ha van egy log alapú vizsgálat, mely lefut minden sql kiszolgálón és kigyűjti az X event kódú bejegyzéseket, mely egy adatbázis szabad kapacitásának 15% alá csökkenését jelzi, akkor bár az esemény adataiból bejön az adatbázis neve, így az alert konkrét objektum eseményére utal, azon adatbázis állapota / állapotváltása a felügyeleti rendszerben nem tárolódik, mert nincs mögöttes entitás, stringek közlekedtek a rendszeren: az eseménynapló bejegyzésből alert szövegezés lett.

A fenti példa mentén itt kihívás pl. arra a kérdésre válaszolni, hogy az elmúlt 3 hónapban az X és Y adatbázisok hányszor és milyen hosszan voltak kritikus hely közeli állapotban, hiszen ezt csak tippelni tudjuk az elmúlt három hónap alertjeinek végignézésével adatbázis név stringre és az alertek megjelenésének / lezáródásának állapotára szűrve (feltéve, ha egyáltalán lezáródik magától ez az alert ha az állapot visszatér "normálisba" :))

Ahhoz, hogy a fenti kérdésre érdemben tudjunk válaszolni, a felügyeleti rendszernek ismernie és egyértelműen azonosítania kell tudni a nevezett adatbázist sőt a vizsgálatok állapotát - vagy legalábbis az állapotváltozásokat követnie és az adott entitáshoz kell tudnia kötni. Na erről a képességről - az objektum modellről és annak feltöltéséről a következő postban, most fogadjuk el, hogy ez adott. Hogy mit nyerünk ezzel? Sokmindent :)

  • Nem kell az alertek text és egyéb állapotok alapján trténő bűvszkedéseivel (megpróbálni) meghatározni, mi is volt az állapot egy adott időpontban, mikor voltak a váltások, stb...
  • Az állapotváltások alapján az adott állapotban töltött időintervallumok arányosításával könnyen lehet rendelkezésre állási adatokat előállítani
  • Az entitásokon túl azok függőségeinek és relációinak felderítésén keresztül egymásra hatásokat és következményeket is azonosíthatunk, megjósolhatnunk
  • Az egészségi állapot adatokat hatékonyan tudjuk tárolni, hiszen nem kell minden mérési ciklus eredményét tárolni, elég az állapotváltozásokat -> ennek eredményeképpen ezen adatok egységnyi tárolókapacitás mellett sokkal hosszabb ideig meg is őrizhetők
  • és továbbiak amelyekről szintén később lesz szó

Ha a fentiek alapján a működés mélyebb ismerete nélkül is belátjuk, hogy ez jó, mivel egy adott objektum egészségi állapotáról / rendelkezésre állásáról információval rendelkezünk, visszakanyarodhatunk az előző felvetéshez, mitől lesz ez az egészségi állapot "hiteles".

 

Az egészségi állapot / rendelkezésre állás két nézőpontja

 

A fenti ábra célja, hogy érzékeltessem és felvezessem a különbségeket az üzemeltetés-támogatási és a szolgáltatás-szint szempontrendszere között. Míg az üzemeltetés-támogatás a szolgáltatás lebontására, pontos komponenseire, azok relációira és jelzéseire fókuszál, a szolgáltatás-szint - ha a klasszikus módon felhasználói aspektusból vizsgáljuk inkább a felhasználói érzetre épít. Itt ugyanis mindegy - a felhasználót nem érdekli - hogy az adott szolgáltatástnyújtó informatikai rendszer milyen komponensekb��l és azok milyen relációjából épül fel, ott csak az számít, hogy ellátja-e feladatát, elvégzi-e a dolgát,azon felhasználói tranzakciók végrehajtását ami miatt a rendszer létezik (lásd post eleje).

Nyilvánvaló az, hogy két ennyire eltérő cél két eltérő megközelítést is követel:

A szinkód az előnyös (zöld) és hátrányos (piros) tuljdonságokat hivatott jelképezni. Anélkül, hogy írásban újraértelmezném a bevágás tartalmát, látszik hogy ez a két megközelítés szinte kiegészíti egymást, az egyik erőssége a másik gyengéje és fordítva

A komponens alapú megközelítést az eddigi simereteink alapján azt gondolom könnyebb értelmezni, az elemi komponensekből, azonosított entitásokból a relációik definiálásával igyekszünk választ adni arra, hogy ha megy pl. ez a három windows service, az eseménynapló nem tartalmaz kritikus hibát az Y komponensről, szkriptek alapján van hely a meghajtókon és a performancia alapján y.z processz CPU haszáltsága megfelelő akkor a szolgáltatásnak "jónak kell lennie".

De mi is ez a tranzakció alapú történet? Nem akarok "tippelni" és "jósolni" komponensekből, hanem az érdekel, hogy a felhasználók most mit éreznek, megy-e nekik amit szeretnének vagy nem. Ha a példaszolgáltatásunk az e-mail, akkor:

  •  "be tud-e lépni a különböző kliens ezsközökkel a mailboxba elvárt időn belül?"
  •  "tud-e levelet küldeni cégen belül / cégen kívül?"

Ezeket nyilván hitelesen úgy tudjuk megválaszolni, ha MEGPRÓBÁLJUK. Ez egyszerűnek hangzik, de nem az. Hogy miért és miben tud itt a SCOM segíteni?
(ez a folytatás fő témája)