A következõk a folyamatosan végzendõ problémakezelési eljárásokat reprezentálják:
Az esemény-felügyelet a lehetõ legjobb szintû szolgáltatások biztosításában segít az események káros hatásainak minimalizálásával. Azonnali beavatkozással és a normális szolgáltatások lehetõ leggyorsabb helyreállításával minimalizálja a felhasználói közösségre gyakorolt lehetséges hatást. Bár egyes események a felhasználók számára nem észlelhetõk, természetesen erre is figyelmet kell fordítani.
Az esemény-felügyelet folyamatának hat fázisa van, mint az a következõ bekezdésekben olvasható.
Feljegyzés és készültség
Az események az
informatikai terület bármely részébõl
eredhetnek (hardver, rendszer és alkalmazási szoftver,
kommunikáció, környezet, eljárások,
dokumentáció, szállítók). Valamennyi
esemény feljegyzésre kell kerüljön az
esemény-adatbázisban (egy automatikusan generált
megfelelõ formalapon), és az esemény jelzése
után riasztani kell a megfelelõ személyzetet.
Támogatás és osztályozás
Amint riasztás megtörtént,
Acél az, hogy az események 90%-a megoldható legyen ezen a ponton, minimalizálva a költséges szakértõi gárda igénybevételét. Amennyiben az összevetési folyamat sikertelen lenne, vagy a helyreállítási folyamat túl komplex, akkor a problémakezeléshez kell utalni a feladatot.
Vizsgálatok és diagnózis
Amint az esemény eszkalációja megtörtént, sor kerülhet a kimerítõ vizsgálatra és diagnosztizálása. Ez egy iteratív folyamat, melyben különbözõ területek számos munkatársa vehet részt, különbözõ helyekrõl és különbözõ idõben. Ez az eljárásmód a szigorú és szakszerû megközelítést kíván meg valamennyi tevékenységnél, és megköveteli a megfelelõ eredmények pontos rögzítését. A 12. ábra egy tipikus folyamatot mutat be.
Hiba feloldás és helyreállítás
Mint korábban hangsúlyoztuk, az események többsége a klasszifikációs (osztályozási) fázis után közvetlenül a hibaelhárításhoz kerül helyreállítás céljából. A maradékot diagnosztizálni kell, ennek sikere esetén a hibát megoldják, vagy áthidaló megoldással teszik lehetõvé a normál vagy az elfogadható informatikai szolgáltatások helyreállítását. A problémakezelési rendszernek lehetõvé kell tennie valamennyi esemény és tevékenység feljegyzését a hiba feloldási és helyreállítási fázisban.
Az esemény zárása
A problémakezelési folyamat e szakaszát felügyelni kell, hogy csak a feljogosított személyek köre vehessen részt benne. Az esemény feljegyzésének és osztályozási kód besorolásának (amennyiben annak már meg kellett történnie) végsõ szemléjét követõen az eseményt zárni kell. Valamennyi eseményhez tartoznia kell egy osztályozási kódnak, amely jelzi az esemény kiinduló okát.
Esemény-figyelés és követés
Legyen szó akár
egyszerû, akár összetett eseményrõl,
a felügyeleti rendszernek lehetõvé kell tenni
az események figyelését és követését
életciklusuk minden fázisa során. A folyamatnak
részese lehet akár egy, akár több csoport;
a hibák lehetnek a felhasználó által
észlelhetetlenek vagy a teljes felhasználói
közösségre hatást gyakorlóak. Az
esemény életciklusa néhány perctõl
a néhány órán át akár
(ritkán) napokig is terjedhet. Számos elintézetlen
esemény létezhet egyidejüleg. A probléma-felügyeleti
rendszernek lehetõvé kell tennie az események
figyelését és követését
azok életciklusa során. A gyorssegélyszolgálat
munkatársai látják el ezt a feladatot a kulcsadatok
felhasználásával (pl. a hatás kód,
a felhasználó (bejelentõ) azonosítója,
a konfigurációs elem kódja).
Az esemény-felügyeleti tevékenység
A kezdeti esemény-felügyelet annak a felügyeleti szekciónak a felelõssége legyen, amely észleli az eseményt - a számítógépes üzemeltetés, a hálózatot felügyelõ személyzet vagy a gyorssegély-szolgálat. Kívánatos, hogy rendelkezésre álljon olyan elektronikus eszköz, amellyel ez a felügyeleti szekció segítséget kérhet a megfelelõ személyzettõl az informatikai szervezeti egység más részlegeibõl. A problémakezelést kell a felügyeleti szekción kívüli elsõ választható segélykérési ponttá tenni, kivételként kezelve a szállítót, amely közvetlenül szerzõdhetett a berendezési hibákkal kapcsolatos kérések megoldására.
A problémakezelési személyzet vizsgálja meg a hozzá továbbított eseményeket, a legfõbb célnak tekintve azt, hogy a normális szolgáltatást visszaállítsa olyan gyorsan, amint csak lehetséges. A specialista szakértelemért idõben kell folyamodni, megfelelõen az elõre definiált eszkalációs eljárásnak. A bonyolultnak tûnõ eseményeknél az idõ kritikus tényezõ. Biztosítani kell a változáskezelési eljárásoknak való megfelelést, amikor a megfelelõ megoldás vagy az áthidaló eljárás végrehajtásra kerül. Az esemény lezárása a normális szolgáltatás helyreállításával történik meg.
A jelentõsebb események felügyelete
Jelentõsebb események azok, amelyeknél a felhasználói közösségre való kihatás különösen nagy, vagy ahol a zavar idõtartama, még ha csak a felhasználók egy viszonylag kis arányára is, hosszúvá válik. Ezeknek az eseményeknek magas prioritást kell kapniuk. Eljárások szükségesek a vezetés folyamatos informálásához. A probléma-menedzser felelõs formális ülések összehívásáért, melyeken meg kell jelennie az informatikai szolgáltatások vezetésének és a PK funkció, a speciális támogató személyzet, a gyorssegély-szolgálat valamint a szállítói támogatás kulcsembereinek. Az ülésen szemlézni kell az elõrehaladást, és meg kell határozni a legjobb cselekvési irányt. A probléma-menedzser közvetlen és átfogó felelõsséggel tartozik a jelentõs eseményekért, és az ilyen üléseken vezetõ szerepet játszik.
A probléma felügyelet nagyon hasonlít az esemény-felügyeletre, de elsõdlegesen a problémák okának meghatározásával foglalkozik. Míg az esemény-felügyelet célja a gyors hibaelhárítás, a probléma-felügyelet az események okainak meghatározásával foglalkozik, az ismert hibákból eredõ események újbóli elõfordulását igyekszik megelõzni. A személyzet azonosítja az események valódi okát, diagnosztizálja és ismert hibákká alakítja õket, amelyek meghatározott konfigurációs elemekhez (KE) kapcsolhatók. Prioritást kell adni azon problémák megoldásának, amelyek jelentõs eseményeket okozhatnak.
A probléma-felügyeletnek négy fázisa van.
Probléma-azonosítás és feljegyzés
Probléma-azonosításra akkor van szükség, amikor legalább egy esemény nem illeszkedik a meglévõ problémákkal vagy ismert hibákkal. A probléma feltárásához szükséges erõforrásokat arányosan kell allokálni; azaz egy egyedi esemény felderítésére rendszerint kevesebb erõforrást rendelnek, mint egy ismétlõdõ eseményhez.
Azonban, amint több esemény bizonyul hasonlónak, egy új probléma létezése kerül megerõsítésre, azaz egy új problémát ismernek fel. Minden problémát feljegyeznek egy adatbázisban, bár a szokványos esemény adatok többsége érdektelen. Mivel az események java rutinjellegû vagy már meglévõ problémáknak és ismert hibáknak tulajdonítható, az azonosított hibák száma ennek megfelelõen kevés kell legyen. Ez megóvja a problémakezeléssel foglalkozó személyzetet az eseményekkel való elárasztástól. A következõ (13.) ábra bemutatja a probléma azonosítás folyamatát.
A probléma súlyosságának elemzése
Egy új probléma azonosítását követõen azonnal meg kell becsülni súlyosságát. Súlyossági kódrendszert kell kialakítani, amely megfelel a szervezet igényeinek. A súlyossági kódolás lehetõvé teszi az erõfeszítések hatékony allokációját, és ez a kódolási rendszer biztosítja a szabványos megközelítést.
Az erõforrások elosztása
A súlyossági kódolás valamint az eredményes, hatékony és kontrolláltan megvalósított személyzet-elosztás szükségképpen egy eredményesebb és költséghatékonyabb struktúrához vezet. Minél magasabb a súlyossági besorolás, annál nagyobb hangsúlyt helyeznek a személyzet kijelölésére, míg egy kisebb súlyossági kód esetében várakozni lehet, amíg megfelelõ személyzet áll rendelkezésre. Ezzel megelõzhetõ az erõforrások rossz elosztása valamint elkerülhetõ a túlzott lelkesedés és a ráfordítások többszörözése. Az azonos jellegû események is befolyásolhatják az allokációt, amint például nagy számban kapcsolódó, kis súlyossági kódú események is megkívánhatják az azonnali beavatkozást. Ez a helyzet kézben tartható oly módon, hogy az események eszkalációjához küszöbértéket használnak: egy elõre meghatározott számú azonos jellegû esemény elõfordulásakor eszkalálni kell.
Probléma vizsgálat és diagnózis
A probléma vizsgálatának folyamata hasonlít az eseményeknél bemutatotthoz és hasonló rendszer eszközöket kíván az elõrehaladás, az eredmények és a támogató szerepek rögzítéséhez. A vizsgálat célja a diagnózis, ami gyakran eljárásbeli és nem eszközökbõl (KE) eredõ hibákat fed fel. Sajnos az ilyen típusú hiba nem jut el automatikusan az ismert hiba státuszba és emiatt nem mindig követik nyomon. Egy ál-feljegyzés valamely szabálytalan eljárásra lehetõvé teszi az ismert hibává való konverziót, ami azután nyomon követhetõ a hiba-felügyeleti rendszeren.
A probléma-felügyeleti tevékenység
Bizonyos jelentõs
problémák közvetlenül azonosíthatók
a hozzájuk kapcsolódó elsõ esemény
vizsgálata során. Ebben az esetben a probléma-feljegyzés
rögtön elõállítható, de
nem szabad megfeledkezni a megfelelõ esemény feljegyzés
módosításáról sem, az új
probléma-feljegyzés megfelelõ adatának
felhasználásával. Az események feljegyzései
alapján azonosíthatóak az újabb problémák.
Szemlét kell tartani minden lezárt eseménynél,
amely nincs összefüggésben ismert problémával
vagy hibával. Ha ez a szemle nem képes kapcsolódó
problémát találni, új probléma-feljegyzést
kell elõállítani. Minden problémát
súlyossági kóddal kell megjelölni, és
a részletes vizsgálat elõtt meg kell bízni
a vele foglalkozó személyzetet a PK-en belülrõl.
A kijelölt személy viseli a felelõsséget
a problémáért és minden kommunikáció
fókuszpontja ill. a probléma megoldására
irányuló tevékenység koordinátora
lesz.
A probléma-felügyelet, akárcsak az esemény-felügyelet, megkívánja az átfogó, nagy adattartalmú feljegyzések karbantartását. Biztosítani kell, hogy minden diagnosztikai adat kapcsolódjon a probléma történeti feljegyzéséhez, és hogy pontosan meghatározható és fellelhetõ formában legyen tárolva. Erre szüksége lehet a probléma-felügyelet során más területek személyzetének és a szállítóknak. Fontos, hogy a megfelelõ eljárásokat pontosan kövessük.
A hiba-felügyeletrõl általában
A hiba-felügyelet az a folyamat, amely során nyomon követik az ismert hibákat, amíg a változáskezelés funkció egy változtatás sikeres megvalósításával megoldja õket. Ebbe tartozik a konfigurációs elem változtatása az ismert hiba megszüntetése és ezáltal a probléma megoldása érdekében. A hiba-felügyelet hidat képez a fejlesztési és az éles környezet között. Ezt a folyamatot jobban összefoglalhatjuk a változtatási kérelem életciklus leírásával (lásd a vonatkozó fejezetet is)
Az ismert hiba adatok két forráson keresztül juthatnak a hiba-felügyeleti rendszerbe. Ezek:
Egy új alkalmazás üzembe helyezése tartalmazhatja a fejlesztési fázisból eredõ ismert hibákat. Ezek általában nem súlyos hibák, de megkívánják az éles környezetbe való átvitelt. A probléma- és a hiba-felügyelet eljárásai alapvetõen megegyeznek mind az éles, mind a fejlesztési környezetben, és a szükséges támogató eszközök is ugyanazok. A 14. ábra mutatja, hogy az éles és a fejlesztési környezet hiba-felügyelete ciklikus kapcsolatban van. Az együttes munka és a két környezet problémakezelési rendszerének integrációja lehetõvé teszi a szituáció ideális módon való kezelését.
Az éles üzemeltetés során lelt hibák eredményeként VK-ek gyûlnek össze. A kiadási stratégia számításba veszi a kiadás végsõ kialakítását, hogy tartalmazhassa az elfogadott változásokat a rendszer lehetõségeinek módosításához és/vagy kiterjesztéséhez. A fejlesztõ személyzet tudatában van valamennyi ismert hibának és problémának, amely a kiadási csomaggal kapcsolatos. Õk törölhetnek ismert hiba feljegyzéseket amennyiben kijavították õket, de újonnan bevezetett hibákat adhatnak hozzá a javított hibák adatbázisához, magából a fejlesztési tevékenységbõl eredõen.
A kiadás megvalósítása
során ez a javított hiba adatbázis felváltja
a korábbi kiadás adatbázisát, mint
éles verzió. A kör azután ismétlõdik,
amint új hibát fedeznek fel az éles mûködés
során.
A hiba-felügyeleti tevékenység
A probléma-menedzsernek vagy a problémakezelési személyzet tagjának szemlét kell tartania valamennyi új ismert hiba felett. Az eljárás változik aszerint, hogy ki viseli a hibát tartalmazó dologért a felelõsséget.
Belsõ felelõsség
A problémakezelési személyzet kezdeti becslést ad a hiba elhárítási módjairól, amennyiben szükséges, specialistákkal együttmûködve. A problémakezelési csapat ezután befejezheti a változtatási kérelem (VK) elkészítését a változáskezelési eljárásoknak megfelelõen. A VK prioritását a hiba súlyossága határozza meg. A VK és az ismert hiba feljegyzés tartalmazza egymás azonosítóját a teljes audit nyomon követhetõség érdekében.
A következõ tevékenységek, a hiba megoldása, a hatáselemzés, a megoldás részletes értékelése, a végrehajtandó tevékenységek, a hibás elem változtatása és a változás tesztelése a változtatási menedzser felügyelete alá tartozik. A megoldási folyamat során a probléma-menedzser rendszeres jelentéseket kap a változáskezeléstõl a hiba megoldásának elõrehaladásáról. Figyelni kell, hogy a hiba megoldásának elõrehaladása megfelel-e a Szolgáltatási Szint Megállapodásokban (SzSzM) rögzített követelményeknek. Ez jellemzõen meghatározza, hogy súlyossági szintenként bizonyos számú megoldatlan hibánál nem lehet több egyetlen mérési intervallumban sem (pl. az elmúlt 4 hétben). Ha egy súlyossági szinten a hibák száma elér egy elõre meghatározott küszöböt, ami valószínûleg a SzSzM megszegéséhez vezet, el kell indítani a felterjesztési (eszkalációs) folyamatot.
A probléma megoldását jelentõ változtatások sikeres megvalósítása után a problémakezelés formálisan zárja az ismert hiba feljegyzést. Minden ismert hibához tartozó hibaelhárítási feljegyzést karban kell tartani a problémakezelési rendszerben. Ez az adat azután elérhetõ események és a problémák összevetése céljából, iránymutatást ad jövõbeni vizsgálatokhoz események megoldása vagy áthidalása során, és felhasználható vezetõi információk szolgáltatásához.
Külsõ felelõsség
Megfontolandó szabvány hiba feljegyzések kialakítása specifikus eszközönként (KE) vagy eszköz-kategóriánként, a rutin jellegû hardver hibák azonosítása érdekében. Ezek használandók a hibaarány gyors mutatójának követésére, bár több információt, mint pl. a hibák közötti átlagidõ (MTBF) és az állásidõ, az esemény adatokból származtatnak.
A szállító által karbantartott termékekkel kapcsolatos hibákat a problémakezelési funkció vagy valamelyik specialista csoport azonosíthatja, és továbbítja a megfelelõ szállító illetékes funkciójához, mint megoldásra váró problémát. Nyilvánvaló, hogy az informatikai szervezeti egységtõl nem várható el ugyanolyan szintû közvetlen felügyelet egy szállító által karbantartott szoftver hibájának megoldása felett, mint saját eszközök esetében. Nagyon formális eljárások alkalmazhatók. A szállító által adott segítséget figyelni kell, biztosítandó, hogy a válasz elfogadható idõn belül maradjon. Ahol a szoftver karbantartási célokat - pl. a javításig eltelõ átlag és maximum idõ - és a kapcsolódó informatikai infrastruktúra megbízhatósági és szolgáltató képességi szinteket szerzõdésben vagy licenc feltételekben határozták meg, ennek megszegése esetén kezdeményezni kell a vállalatnál a probléma orvoslását. A karbantartási célok specifikálásának lehetõségére már a szoftver beszerzésekor gondolni kell, fõleg ha versenyeznek az üzletért. Megjegyzendõ, hogy a külsõ eredetû szoftverek hibáinak megoldásához szükséges változtatások éppúgy a változáskezelési eljárások alanyai, mint a belsõ termékek.
Sok hardver hiba kiigazítását az esemény-felügyelet végzi, és nem a hiba-felügyelet ill. a változáskezelés. A hardver-javítást végzõknek ilyen esetben értesíteni kell a problémakezelést és a változáskezelést. Azonban minden változás a hardver specifikációban a normál változáskezelési eljárás alá tartozik.
A problémakezelés által szolgáltatott információ és adatok a fõ forrásai az aktuális szolgáltatási szintek meghatározásának. Ez az információ igények szerint alakítható, hogy az informatikai vezetés minden szintjét ellássa a szükséges statisztikákkal.
Az 15. ábra példa az automatizált támogató eszközbõl kinyerhetõ bõséges terjedelmû információra.
A problémakezelési adatok információval szolgálnak a megelõzõ tevékenységekhez a szolgáltatás megbízhatóságának javítása érdekében. Meg kell határozni az informatikai infrastruktúra "sérülékeny" összetevõit az események, problémák adatai és az ismert hiba adatok alapján. Meg kell vizsgálni e sérülékenység mögött álló okokat. Ahol a probléma-menedzser egynél több számítógépes rendszerért felelõs, ügyelni kell annak megelõzésére, hogy az egyik rendszerben elõforduló hiba a többi rendszerben is megjelenjék.
Egy új problémakezelési rendszer információt igényel a korábbi papír-alapú rendszertõl, hogy eredményes legyen kezdettõl fogva. Máskülönben trendelemzési képessége a KE-ek robusztusságával erõsen korlátozott, amíg elegendõ történeti adat össze nem gyûlik. A szállítók által szolgáltatott ismert hibajelentések információkat adhatnak a kezdeti hibákról. A gyártó rendszerébõl eredõ tervezési jelentések informálhatnak a kezdeti problémákról. E jelentéseket rendszeresen meg kell vizsgálni, hogy a lehetséges hardver hibák még az elõfordulásuk elõtt azonosíthatóak legyenek. Ideális esetben ezt a szállítónak kell elvégeznie, amennyiben nem, akkor a probléma-menedzser felelõssége, hogy biztosítsa e feladat ellátását. Ezek a jelentések kiválthatják a hardver KE-ek cseréjét, mielõtt még bármely hiba elõfordulna.
A problémakezelés adatai a rendszeres hatékonysági és eredményességi szemlék alapjául szolgálnak. Eljárásokat kell kialakítani a kulcs hatékonysági kritériumokat elõállító jelentések készítésére. Ha egyes specifikált mutatók célértékei nem állapíthatóak meg némi éles üzemeltetési gyakorlat nélkül, meghatározásuk történjék meg egy hónapon belül. A probléma-menedzsernek folyamatossági alapon egybe kell vetnie az aktuális eredményeket a célértékekkel, havonta egyszer. Minden szemle eredményét fel kell jegyezni és tárolni audit célokra. Ha a célzott értékeket nem sikerült elérni, bizonyosodjunk meg arról, hogy ennek oka a túlságosan ambiciózus célkitûzés és nem a gyenge mûködés volt.
Egyre nehezebb célrendszer kialakítását kell tervezni, az eredményes problémakezelésbõl fakadó hasznoknak megfelelõen. Ezen kívül rendszeresen szemlézni kell a következõket, melyek a problémakezelési funkció sikeres mûködéséhez szükséges feltételek.
Kapcsolódások az informatikai szervezeten belül
Fõként az éles mûködés elsõ heteiben szorosan kell figyelni a munkakapcsolat hatékonyságát a gyorssegély-szolgálattal, a számítógépes tevékenységek és a hálózati felügyelet személyzetével, a változásmenedzserrel valamint a specialista csoportokkal. Az ezeken a területeken tapasztalt nehézségek jelentõs hatással lehetnek az átfogó hatékonyságra. Biztosítani kell a jó munkakapcsolatok kialakítását. Rendszeres kapcsolatfenntartó üléseket kell tartani a csapatépítés támogatása érdekében.
Szállítói kapcsolatok
Az eredményes problémakezelési rendszer megléte kölcsönösen elõnyös az informatikai divízió és a szállítói számára egyaránt. Szövetkezni kell a szállítók és a legalsó szintek személyzetével, és meg kell próbálni túljutni a rendszerrel kapcsolatos nehézségeken. Ha formális kapcsolat létezik a az informatikai divízió és a szállító problémakezelési rendszere között, akkor rendszeres közös auditokkal lehet figyelemmel kísérni a pontosságot. Kérni kell a szállítót, hogy elõre figyelmeztessen minden szándékolt változtatásra a rendszerében.
A személyzet elkötelezettsége és az eljárások használata
Fennáll a veszélye annak, hogy a "családiasság felületességet szül", amint a problémakezelési rendszer használata rutinná válik. Az eljárások megfelelõ betartását rendszeres ellenõrzésekkel kell biztosítani.
Verziókiadási stratégia és változtatáskezelés fejlesztése
Figyelemmel kell kísérni a fejlesztési környezethez kapcsoló interfészek eredményességét és pontosságát, fõként az ismert hibák adatainak átadásával kapcsolatban. Meg kell bizonyosodni arról, hogy a problémakezelési és a változáskezelési rendszerek kompatibilisek és kölcsönösen segítik egymást.
Rendszeres audit
Rendszeres auditot kell elõkészíteni valamennyi problémakezelési tevékenységre és eljárásra vonatkozóan. Ezen auditok célja annak megerõsítése, hogy a problémakezelés és a támogató csoportok betartják az elfogadott eljárásokat. Célja ezenkívül:
Tervezni kell azt, hogy a problémakezelési rendszer lépést tartson az informatikai fejlesztésekkel, fõleg azzal, ahogy az ellátók fejlesztik rendszereik hibajelentõ és diagnosztizáló mechanizmusait. Meg kell találni a módját a szállítótól származó ezen adatoknak és más hiba-információknak a megszerzésére, valamint a szállítói rendszereknek a saját problémakezelési rendszerrel való integrációjára.
Figyelemmel kell kísérni a sikeres problémakezelési rendszer hatását a funkció személyzetének munkaterhelésére. A tapasztalatok szerint egy eredményes problémakezelési funkció, fõként, ha egy eredményes változáskezelési rendszer és szoftver minõség kontroll mellett mûködik, csökkenti az események és a problémák számát. Ez a kisebb számú esemény és következményeképp a lecsökkent számú segítségkérés a személyzet létszámának csökkentését eredményezheti. De az új alkalmazások és az új felhasználók természetesen növelik a problémák és események okozta munkaterhet.
A probléma-menedzsert tájékoztatni kell minden várható változásról, ami hatással lehet a munkamennyiségre, tehát terv készíthetõ nem csak a személyzeti kérdésekrõl, de egyéb erõforrásokról is, mint pl. az adatbázis méret.