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

Nagy levegőt véve útnak indítom ezt az x részes témát, melyet már sokszor és sok ügyfélnek volt szerencsém elmesélni, mert kár tagadni - ez a termék a komplexitásból adódóan - az esete többségében a "lehetőségeinek csapdájába esik". Komplexitás + széles beépített tudás - megértés = nem kiszámíthatónak vélt működés, az eredeti cél (üzemeltetés segítése) jobb esetben nem elérése, rosszabb esetben... de ezt hagyjuk, majd később szót ejtek róla.

Messzebbről kell indulnom, így előre is elnézést az olvasótól - bár a cikk(sorzat) címe magától értetődően magába foglalja a megoldás nevét (System Center Operations Manager) - az első cikkben nem illetve nem kizárólag a SCOM-ról (esetleg néha későbbiekben OM-ként is hivatkozhatom) lesz szó, hanem arról, ami a megoldást életre hívta: üzemeltetés támogatása monitorozáson keresztül.

 Nos, ha erről közelítünk, véleményem szerint a két legfőbb funkciója az ilyen rendszereknek a:

• Események - Hibák észlelése  illetve a
• Felügyelt rendszerek egészségi állapotának követése

A másodikról kicsit később, a következő cikkekben beszélnék, nézzük először az elsőt:

Események - Hibák észlelése

Ez a funkcionalitás egy olyan felügyeleti rendszerben, mely "üresen" ékezik - azaz nincs beépített, termékspecifikus tudás - a következőképpen néz ki:

• Oops, tegnap magába zuhant egy kritius alkalmazás, melynek oka az volt, hogy megállt az 'XYZ' szolgáltatás =>
• Meg kellene az ilyen eseteket legközelebb mielőbb értesüljün erről hogy ne ismét az üzleti felhasználók szóljanak =>
• Állítsunk be egy figyelést arra, hogy ha a szolgáltatás leáll, legközelebb tudjunk róla ha baj van

Ezen üzemeltetésben résztvevők általában reaktív módban vannak, folyamatos "tűzoldás" az életük (aminek persze sok oka lehet - de nem célom, hogy a cikkben ennek mögöttes okait tárgyaljam) mely esetben (fenti példa) a felügyeleti rendszer is csak annyit tud segíteni, hogy a már X-szer (jó esetben egyszer) bekövetkezett hiba rögzítésével legalább a felhasználói bejelentés előtt kicsivel értesülünk a nem kívánt esemény ismételt bekövetkezéséről.

Ezen esetekben a felügyeleti rendszer működésére jellemző, hogy:

• Nincs külső tudás, minden saját tapasztalat útján "kerül be"
• Az észlelt esemény már maga a hiba (minimális előre felismerési ablak)
• A felügyelti rendszer terhelése (figyelések száma) valamint a felszínre hozott események száma eleinte nagyon alacsony, majd a további testreszabások kapcsán növekszik
• Minimális vagy nem létező "zaj" - ezt a zaj fogalmat alább tisztázzuk..

Események - Hibák előrejelzése és észlelése 

Nyilvánvaló, hogy az IT rendszerek által nyújtott szolgáltatások működésével kapcsolatos elvárások egy szint után olyan üzemeltetéssel szemben támasztott követelményeket támasztanak, melyeket nehéz megvalósítani anélkül, hogy az egész működési modell ne változzon. Mert ugyan az előző példában valóban sikerül a felhasználó előtt észlelni a hibát - azonban mivel az esemény amit észlelünk már maga a hiba - ez jó esetben csak pár pect időt nyer az informatikának, amíg az első felhasználói panaszok is megérkeznek.

Hogyan lehet ezen változtatni: egyszerű, figyeljük az előjeleket, melyek a hiba hamarosan vélhető bekövetkezésére utalnak (egy klasszikus és nyilvánvaló példa a kötetek szabad helyének folyamatos figyelése és riasztás adott százalék alatt). Ez bár nagyon egyszerűen hangzik és tökéletes megvalósítása esetén el is érkeznénk a proaktív modellhez, mégsem olyan triviális ez. Vegyünk pár példát:

• Az előző mondatban nyilvánvalóként hivatkozott figyeljük meg mennyi hely van a lemezen, ezáltal megelőzhetjük a beteléséből eredendő potenciális problémákat állítás is csak elsőre ilyen egyszerű, mert:
• Mely köteteket figyeljük?
• Mekkora legyen a határérték? Százalék? Abszolút hely? - Hogyan kezeljük ezt, ha a lemezeink mérete 36GB-tól 2TB-ig szór?
• Milyen gyakran nézzük ezt? - Ha túl ritkán, későn vesszük észre, ha túl gyakran, fölösleges terhelés...
• stb...
• Az előző témakör szolgáltatás megállási példája még kevésbé triviális, hogyan kezelendő "proaktívan". Hogyan vesszük előre észre, ha a szolgáltatás meg fog hamarosan állni?
• És még egy igazán súlyos kérdés: még ha választ is találunk az előzőkre, mi van azon még meg nem testesült, tapasztalt hibák megelőzésével, melyekről nem is tudunk, mivel nem fordultak elő? Na azokat hogyan előzzük meg?

Nyilván a fentiekből eredően egy proaktív üzemeltetési modell támogatására más típusú megoldás szükséges: itt bizony (az utolsó kérdésből egyenes úton levezethető) kollektív / külső tudásra is szükség van ahhoz, hogy megkíséreljük célunk elérését. Méghozzá nem is kevésre - valójában lehetleg minnél többre.

Persze hogy ne legyen egyszerű dolgunk, ez a variáció teljesen más - súlyában nem kevésbe kicsi - kérdéseket vet fel:

• Kitől szerzünk be tudást?
• Honnan tudhatjuk, hogy bízhatunk-e benne, mind az előrejelzés pontossága, mind pedig a potenciális hibák feldettsége megfelelő-e?
• És a legfőbb két kérdés: honnan tudjuk, mennyire illeszkedk ez a tudás a mi környezetünkre?
• és milyen módon / mennyi energiával tudjuk ezt illeszteni?

Az utolsó két kérdést kicsit megvilágítom jobban egy példán, mert tételezzük fel, hogy az első két kérdésre megnyugtató választ kapunk (mondjuk Windows operációs rendszerek OS szintű felügyeletéről beszélünk és erre a SCOM Microsoft által publikált felügyeleti csomagját (erről majd később) használjuk). Van nekünk egy figyelésünk, mely akkor kell, hogy riasszon, ha a kiszolgáló "túlságosan elfoglaltnak" tűnik CPU oldalon. Mivel az első két kérdésre megnyugtató választ kaptunk, vegyünk tényként, hogy ezt úgy érjük el, hogy prcenként begyűjtjük a pillanatnyi CPU használatot és ha 5 minta átlaga 90% fölött van, úgy érezzük gond lehet. Na de mi van akkor, ha:

• A kiszolgálónkon van egy olyan alkalmazás, mely a nem ideálisan megírt erőforrás felhasználás miatt gyakorlatilag üzemszerűen 90% fölött pörgeti a CPU adott teljesítménymutatóját, de vgan és jól működik
• A kiszolgálónk hardver kiépítése bizony kevés a rajta szereplő terheléhez

Valójában mindkét fenti példa esetén a eredeti peremfeltételek mellett hiba lenne, ámde ezen esetekben az üzemszerű működés maga átüti a peremfeltételeket? Akkor most nem jó a felügyeleti rendszer vagy az adott figyelés? Nyilván nem ott a gond:amikor ki kellett találni, hogy milyen módon és milyen határértékekkel detektálódjon egy kiszolgáló processzor túlterhelése nyilván nem volt egyetértés. Sokszor el is képzeltem, mikor a termékcsapat (Windows Server) prominens tagjai összeülnek egy szobában fél napra megvitatni, hogy a világon működő 15 millió (fiktív szám, nem tudom valójában
pontosan mennyi) Windows Serverénél milyen feltételekkel dolozzanak, melyek mindenkinek jók lesznek? Azért ezt lássuk be, finoman szólva nehéz, de inkább lehetetlen feladat. Elő kell jönni valamivel, mely vélhetően a legnagyobb százalékra jó közelítőlegesen. Ugye ezután nem is várhatjuk el, hogy a "mennyire illeszkedk ez a tudás a mi környezetünkre?" kérdésre mindíg a "teljesen" válasz hangozhasson el.

Ha viszont ez szinte lehetlen, akkor a következő kérdés hatványozottan fontos ("és milyen módon / mennyi energiával tudjuk ezt illeszteni?"). Azaz hogyan kezeljük a fenti szervereket (milyen határértékeketvlasztunk, hogyan érvényesítjük ezt szelektíven, stb..), melyre a SCOM bizony nagyon erős képességeket tud felsorakoztatni - de erről majd részleteiben később, a testreszabási
lehetőségek kitárgyalásánál...

Tisztán látszik, hogy azért ez a proaktív módszer egy potenciálisan elég rögös út. Nézzük is meg a főbb jellemzőit összehasonlítva a reaktív megközelítéssel:

Remélem a táblázatból érződik, hogy ezen két modell erősen más elvárásokra szinte "ellentétes" megközelítéssel felel. Ezt megpróbálom a "zaj" és a lehetséges kiemelt szavak kontextusba helyezésével szemléltetni:

Egy teljesen reaktív módba kényszeredett és/vagy ilyen módon gondolkodó üzemeltető egy proaktív megközelítésű megoldást finoman szólva nem fog szeretni, számára a felügyeleti rendszer üzemeltetés-támogatási létjogosultsága is kérdés, hiszen a felhasználó úgyis szól ha baj van, a megoldást meg sem ideje nincs nézgetni, sem "haszna" nincs, mivel 100-ból 80 riasztás "felesleges zaj" mivel semmi nem állt meg. Ő azt akarná a rendszertől hogy csak akkor szóljon ha baj van - de igazából minek is, mert a felhasználó úgyis szól... Elnézést a sarkas fogalmazásért, de szükséges és fontosnak tartom azt is, hogy ez a gondolkodás, vagy a lehetőségek által adott kényszeredett gondolkodás teljesen logikus és védhető is. Más kérdés, hogy ennek az üzemeltetési hatékonysága illetve az IT megítélése szempontjából hogy is fogalmazzak finoman: szuboptimális.

Mivel ha nem is ennyire sarkasan, de szinte mindig találkozom ezzel a helyzettel és sikerül kicsit elbeszélgetni az érintett személlyel és felteszem a kérdést, hogy "ha ezeknek a riasztásoknak a célja esetleg nem az lenne, hogy szívbajt hozza rá hogy összedőlt a világ, majd elolvasva konstatálja, hogy még élünk, hanem az, hogy ez egy lehetséges előjele egy jövőbeli hibának, akkor sem látja-e értelmét" akkor minden esetben egy "hát, ebben van valami" választ kapom. De hozzá i teszi, hogy mivel nagyon kevés az ideje, mivel folyton tüzet kell oltania, nagyon sok plusz munka lenne, hogy ezekkel kezdjünk valami.

És ezzel elérkeztünk a záró táblázatomhoz és gondolataimhoz a "mi egy felügyeleti rendszer szerepe az események/hibák tekintetében" témában: mely megközelítés a "jó". Erre én mindig diplomatikusan azt válaszlom, hogy "a., nincsenek abszolút jó vagy rossz döntések, csak következmények:)" illetve "b., amely jobban megfelel az üzemeltetés elvárásainak, céljainak". Valójában mint az alábbi táblázatból látszik, egy felügyeleti rendszer életben tartása mindenképpen munkaigényes, kérdés hogy mikor hogyan fektetjük ezt bele illetve hogy milyen a kockázatkezelési modell:

És amit szoktam mondani: hiszek abban, hogy mindkét módszernek megvan a létjogosultsága és valójában bármelyből is idul egy üzemeltetés optimális esetben valahol félúton meg tud állni. A kérdés csak az, hogy milyen típusú kockázatokat vállal inkább fel, mely kultúra áll közelebb az üzemeltetőihez illetve a vezetőséghez, valamint milyen elvárásai vannak az üzletnek / illetve milyen relációban áll az IT az üzlettel. É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...

V