System Center Operations Manager - út egy (remek) termék megértése felé - II. rész

"...É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 vezetosé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 elozo 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 fobb cél elérésében támogasson minket a felügyeleti rendszer.

Ebbol ketto 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 elsorol, annak megközelítéseirol már az elozo 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öveto módú" szolgáltatóként testesül meg a cég életében azt fontos látni, hogy az elsodleges interfész az IT és az üzlet(i oldalon ülo 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 tunnek" manapság, mint pl. az elektronikus levelezés muködése esetleges kiesései vagy kevésbé jó válaszidei hatványozottan fájdalmasnak tunnek és a felhasználók csak azokra a pillatatokra fognak emlékezni, amikor egy számára fontos muveletet ott akkor nem, vagy nem elég gyorsan tudott elvégezni és nem arra a szignifikánssan túlnyomó idore, melyben a szolgáltatás "észrevátlenül" tette a dolgát. Ez nyilván az emberi természetbol 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 minoségérzet kezelésében ezen tényszeru nézopontok sokat tudnak segíteni.

Éppen ezért van nagy létjogosultsága egy olyan rendszernek, mely képes ezt az objektív nézopontot közvetíteni, HITELES tényadatokat szolgáltatni egy kritikus funkció valós rendelkezésre állásáról és kieséseirol. Ez egyszeruen hangzik, de nem feltétlen az. Mert ugye mitol is lesz "hiteles" ez az adat - pontosabban mitol érezzük majd annak: származzon olyan mérésekbol, melyek közel állnak a valós használat helyzeteihez. És itt csatolok kicsit vissza az elozo 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 elozo postban a hibák detektálásáról és elorejelzési képességeirol 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 megfeleloen 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ötodik azonosított entitáshoz mint forrás és ennek megfeleloen 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 kigyujti 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ésbol 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 szurve (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értelmuen azonosítania kell tudni a nevezett adatbázist sot a vizsgálatok állapotát - vagy legalábbis az állapotváltozásokat követnie és az adott entitáshoz kell tudnia kötni. Na errol a képességrol - az objektum modellrol és annak feltöltésérol a következo 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éno buvszkedéseivel (megpróbálni) meghatározni, mi is volt az állapot egy adott idopontban, mikor voltak a váltások, stb...
• Az állapotváltások alapján az adott állapotban töltött idointervallumok arányosításával könnyen lehet rendelkezésre állási adatokat eloállítani
• Az entitásokon túl azok függosé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 orizhetok
• és továbbiak amelyekrol szintén késobb lesz szó

Ha a fentiek alapján a mukö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 elozo felvetéshez, mitol lesz ez az egészségi állapot "hiteles".

 

Az egészségi állapot / rendelkezésre állás két nézopontja

 

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 komponensekbol é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éro cél két eltéro megközelítést is követel:

A szinkód az elonyö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 erossé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 komponensekbol, 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 komponensrol, szkriptek alapján van hely a meghajtókon és a performancia alapján y.z processz CPU haszáltsága megfelelo 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" komponensekbol, 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özo kliens ezsközökkel a mailboxba elvárt idon 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 egyszerunek hangzik, de nem az. Hogy miért és miben tud itt a SCOM segíteni?
(ez a folytatás fo témája)