System Center Operations Manager - út egy (remek) termék megértése felé - I. rész
Nagy levegot 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 "lehetoségeinek csapdájába esik". Komplexitás + széles beépített tudás - megértés = nem kiszámíthatónak vélt muködés, az eredeti cél (üzemeltetés segítése) jobb esetben nem elérése, rosszabb esetben... de ezt hagyjuk, majd késobb szót ejtek róla.
Messzebbrol kell indulnom, így elore is elnézést az olvasótól - bár a cikk(sorzat) címe magától értetodoen magába foglalja a megoldás nevét (System Center Operations Manager) - az elso cikkben nem illetve nem kizárólag a SCOM-ról (esetleg néha késobbiekben 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 errol közelítünk, véleményem szerint a két legfobb 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ésobb, a következo cikkekben beszélnék, nézzük eloször az elsot:
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övetkezoké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 mielobb értesüljün errol 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észtvevok általában reaktív módban vannak, folyamatos "tuzoltá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 elott kicsivel értesülünk a nem kívánt esemény ismételt bekövetkezésérol.
Ezen esetekben a felügyeleti rendszer muködésére jellemzo, hogy:
- Nincs külso tudás, minden saját tapasztalat útján "kerül be"
- Az észlelt esemény már maga a hiba (minimális elore 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étezo "zaj" - ezt a zaj fogalmat alább tisztázzuk..
Események - Hibák elorejelzése és észlelése
Nyilvánvaló, hogy az IT rendszerek által nyújtott szolgáltatások mukö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 muködési modell ne változzon. Mert ugyan az elozo példában valóban sikerül a felhasználó elott észlelni a hibát - azonban mivel az esemény amit észlelünk már maga a hiba - ez jó esetben csak pár pect idot nyer az informatikának, amíg az elso felhasználói panaszok is megérkeznek.
Hogyan lehet ezen változtatni: egyszeru, figyeljük az elojeleket, melyek a hiba hamarosan vélheto 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 egyszeruen 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 elozo mondatban nyilvánvalóként hivatkozott figyeljük meg mennyi hely van a lemezen, ezáltal megelozhetjük a betelésébol eredendo potenciális problémákat állítás is csak elsore ilyen egyszeru, 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éson vesszük észre, ha túl gyakran, fölösleges terhelés...
- stb...
- Az elozo témakör szolgáltatás megállási példája még kevésbé triviális, hogyan kezelendo "proaktívan". Hogyan vesszük elore é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 elozokre, mi van azon még meg nem testesült, tapasztalt hibák megelozésével, melyekrol nem is tudunk, mivel nem fordultak elo? Na azokat hogyan elozzük meg?
Nyilván a fentiekbol eredoen 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ésbol egyenes úton levezetheto) kollektív / külso 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 egyszeru dolgunk, ez a variáció teljesen más - súlyában nem kevésbe kicsi - kérdéseket vet fel:
- Kitol szerzünk be tudást?
- Honnan tudhatjuk, hogy bízhatunk-e benne, mind az elorejelzés pontossága, mind pedig a potenciális hibák feldettsége megfelelo-e?
- És a legfobb 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 elso két kérdésre megnyugtató választ kapunk (mondjuk Windows operációs rendszerek OS szintu felügyeletérol beszélünk és erre a SCOM Microsoft által publikált felügyeleti csomagját (errol majd késobb) használjuk). Van nekünk egy figyelésünk, mely akkor kell, hogy riasszon, ha a kiszolgáló "túlságosan elfoglaltnak" tunik CPU oldalon. Mivel az elso két kérdésre megnyugtató választ kaptunk, vegyünk tényként, hogy ezt úgy érjük el, hogy prcenként begyujtjü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 eroforrás felhasználás miatt gyakorlatilag üzemszeruen 90% fölött pörgeti a CPU adott teljesítménymutatóját, de vgan és jól muködik
- A kiszolgálónk hardver kiépítése bizony kevés a rajta szereplo terheléhez
Valójában mindkét fenti példa esetén a eredeti peremfeltételek mellett hiba lenne, ámde ezen esetekben az üzemszeru mukö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 muködo 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. Elo kell jönni valamivel, mely vélhetoen a legnagyobb százalékra jó közelítolegesen. 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övetkezo 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 eros képességeket tud felsorakoztatni - de errol majd részleteiben késobb, a testreszabási
lehetosé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 fobb jellemzoit összehasonlítva a reaktív megközelítéssel:
Reaktív |
Proaktív |
Nincs külso tudás, minden saját tapasztalat útján "kerül be" |
Minél nagyobb és validabb külso tudás |
Az észlelt esemény már maga a hiba (minimális elore felismerési ablak) |
Az észlelt esemény optimális esetben még nem a hiba, hanem egy lehetséges elojele |
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 |
A felügyelti rendszer terhelése (figyelések száma) valamint a felszínre hozott események száma eleinte nagyon magas, majd a további testreszabások kapcsán csökken |
Minimális vagy nem létezo "zaj" |
Sok potenciálisan "zaj"-nak vélt riasztás |
Remélem a táblázatból érzodik, hogy ezen két modell erosen 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ó üzemelteto egy proaktív megközelítésu 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. O azt akarná a rendszertol 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 lehetoségek által adott kényszeredett gondolkodás teljesen logikus és védheto 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 összedolt a világ, majd elolvasva konstatálja, hogy még élünk, hanem az, hogy ez egy lehetséges elojele egy jövobeli 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:
|
Reaktív |
Proaktív |
Mibe kell a munkát fektetni |
Mivel minden figyelést magam definiálok, lépésrol lépésre haladva érem el a lefedést: kevésbol több felé haladok |
Nagymértéku beépített tudással kezdek és azt szabom testre: sokból kevesebb felé haladok |
Milyen kockázatokkal jár |
|
|
És amit szoktam mondani: hiszek abban, hogy mindkét módszernek megvan a létjogosultsága és valójában bármelybol 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 üzemeltetoihez illetve a vezetosé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 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 a következo postban
Comments
- Anonymous
January 01, 2003
"...És meg kell vallanom, nagyon kevés közép- és nagyvállalatnál