Informatika | Informatikai biztonság » Csonka Attila - Helpdesk és katasztrófamenedzsment

Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila Budapesti Közgazdaságtudományi és Államigazgatási Egyetem Gazdálkodástudományi Kar Információrendszerek Tanszék Helpdesk és katasztrófamenedzsment az IT infrastruktúra menedzsmentben Készítette: Készítés éve: Főszakirány: Szakcsoport: Szakszeminárium vezető: Csonka Attila (2003) 2003 Információgazdálkodás e-Learning Dr. Gábor András VII. / 1 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila VII. / 2 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila I. Tartalomjegyzék I. Tartalomjegyzék 3 II. Bevezető 5 III. A helpdesk III.1 A helpdesk lényege III.2 A helpdesk fajtái 8 9 10 III.2a Az egyszerű, központosított helpdesk 11 III.2b Többfunkciós, központosított helpdesk 12 III.2c Elosztott gyorssegély-szolgálat 12

III.2d A helpdesk rendszerek erőforrás igény szerinti tipizálása 13 III.3 A gyorssegély-szolgálat személyzeti kérdései 14 III.3a A gyakorlatlan munkaerő 14 III.3b Tapasztalt szakemberek 15 III.3c Szakértők alkalmazása 15 III.4 Helpdesk rendszerek tervezése és bevezetése III.4a 15 A helpdesk bevezetésének előkészítése (A cél és a küldetés meghatározása) 17 III.4b A gyorssegély-szolgálati rendszer tervezése 17 III.4c A helpdesk bevezetése 19 III.4d A tudásbázis felépítése 21 III.4e Felmerülő lehetséges problémák 22 III.5 A gyorssegély-szolgálati rendszer bevezetésének hasznai illetve költségvonzatai. 22 III.5A A helpdesk költségei 22 III.5b A helpdesk haszna 24 VII. / 3 Infrastruktúra menedzsment III.6 BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila Esettanulmány III.6a Egy hazai bank gyorssegély-szolgálata 25 III.6b Egy helpdesk hívás a gyakorlatban 28

IV. Katasztrófa-menedzsment IV.1 A katasztrófák megelőzése 31 32 IV.1a Az infrastrukturális védelem 35 IV.1b A hardvervédelem a következő lépésekből áll: 36 IV.1c Szoftvervédelem, Adathordozók védelme 37 IV.2 A katasztrófa elhárítás tervezése 37 IV.2a Katasztrófa elhárítási vázlatok 38 IV.2b A katasztrófa elhárítási terv tartalma 41 IV.2c A terv implementálása, szükséghelyzet utáni helyreállítás 43 IV.3 V. 25 Esettanulmány Irodalomjegyzék VI. Ábrajegyzék 44 48 50 VII. / 4 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila II. Bevezető A XXI. század üzleti vállalkozásainál már elengedhetetlen a modern számítógépes infrastruktúra megléte. Ebben a környezetben meghatározó jelentőségű az eredményes menedzsment az informatikai szolgáltatások területén is. e-Learning tananyagunk a számítógépes infrastruktúra

menedzsmentből a helpdesk, vagy más néven a gyorssegély-szolgálat és a katasztrófa-menedzsment témakörét emeli ki. Az IT infrastruktúra menedzsment területeit a következő ábra szemlélteti. 1. ábra:Az IT infrastruktúra menedzsment területei VII. / 5 Infrastruktúra menedzsment e-Learning BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila tananyagunkban bővebben a helpdesk és a katasztrófa menedzsment témakörét dolgoztuk ki, jó gyakorlati alkalmazhatósága, és kézzelfoghatósága miatt. A SZÁMALK segítségével készített tananyag bárki számára könnyen használható, átfogja az említett két témakört. Az informatikában kezdetben a számítástechnikai központok szinte elszigetelten működtek, ami a felhasználókkal való kapcsolattartás hiánya miatt kevésbé hatékony működést okozott. E miatt az IT problémák megoldása nem azonnal történt, az egyes funkciók elszigetelődése miatt a felhasználói

igények az egyes alkalmazásokra vonatkozóan nem teljesültek. Az IT infrastruktúra menedzsment ezeket az IT szolgáltatások terén kialakult hiányosságokat pótolja. A helpdesk a problémák megoldását, a katasztrófa-menedzsment a nem várt eseményekre való felkészülést, megelőzést segíti. Az informatikai szolgáltatások menedzsmentjének bevezetése megteremti a lehetőséget a vállalkozás számára, hogy az informatikai részleg költség-hatékony, a szervezet alaptevékenységét megalapozó részleg legyen. Az infrastruktúra menedzsment egyes funkcióinak bevezetése időigényes, az alábbi számok hozzávetőlegesen a tervezéstől a bevezetésig terjedő időtartamot jelölik.1 Gyorssegély-szolgálat 3 és 6 hónap között (kifinomult, alapos szolgáltatás) Változáskezelés 1 és 3 hónap között, beleértve a támogató eszközök beszerzését Konfigurációkezelés 4 és 12 hónap között, az ötlettől a megvalósításig

Problémakezelés 2 és 4 hónap között Szoftverfelügyelet terítés 1 és Hetek feltéve, hogy a konfigurációkezelés funkció már működik Forrás: Az ITB ajánlásai VII. / 6 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila 1. táblázat: Egyes funkciók bevezetésének időigénye Valamennyi funkció bevezetése projektként kezelendő és valósítandó meg. A tényleges üzembe helyezés rendszerint a támogató szoftver eszköz bevezetéséhez kapcsolódik. A szükséges szoftver eszközök beszerzése után az esetleges testreszabás következhet, a funkció hátterét biztosító rendszerek és a hozzájuk kapcsolódó eljárások kialakítását követően a dokumentáció létrehozása és a rendszer tesztelése kerül sorra. Ennek sikere esetén a megvalósítási terv szemléje, majd a személyzet kiképzése lehet a következő lépés. Ezután elfogadási tesztelést kell végrehajtani,

végül az éles üzemelés következik. Valamennyi funkció esetében a bevezetésnek specifikus jellemzői vannak. VII. / 7 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila III. A helpdesk A gyorssegély-szolgálat fő funkciója a bekövetkezett IT eszközökkel kapcsolatos hibák orvoslása, naplózása. A hibaelhárítási folyamatot a 2-es számú ábra mutatja. A hiba útja a keletkezéstől a megoldásig a következő: 2. ábra: A hiba útja a Helpdeskig A hiba jelentkezik a végfelhasználónál. A felhasználók először nem a helpdeskkel lépnek kapcsolatba, hanem általában egyik kollégájukkal (Őt nevezik kulcsfelhasználónak), aki tőlük nagyobb tapasztalattal rendelkezik az adott szoftver, vagy a számítástechnika terén. Ha ő nem tud segíteni, akkor hívják a helpdesket. Mivel a felhasználó nem informatikus, nem várható el tőle, hogy elhárítsa, vagy akár pontosan behatárolja annak okát.

Tőle csak az várható el, hogy az előzetes ismeretei alapján újra átgondolja, hogy helyesen járt-e el. Amennyiben a hibajelenség továbbra sem szűnik meg, akkor azt jelentenie kell, lehetőleg minél érthetőbben és részletesebben, hogy minél pontosabban rögzíthessék azt a helpdesk rendszerben. A hibabejelentés történhet telefon, Internet, vagy Intranet útján. VII. / 8 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila A bejelentett hiba alapján a helpdesk rendszer kezelője elsőszintű hibaelhárítást végez, ami azt jelenti, hogy a számítástechnikai munkatárs a saját tudására, vagy a helpdesk szoftver tudásbázisára támaszkodva azonnali hibaelhárítást kísérel meg, ha ez lehetséges. Ha ez nem valósul meg, akkor továbbadja a problémát egy szakértői csoportnak. Ez a másod szintű hibaelhárítás Mindkét folyamat végeztével az esetet dokumentálják, hogy a jövőben előforduló

hasonló hibák megoldása mielőbb megtörténjen, és utat mutasson az esetleges jövőbeni fejlesztésekhez. III.1 A helpdesk lényege A gyorssegély-szolgálat a szervezeten belüli IT szolgáltatások széleskörben és egyre inkább elterjedt eleme, amely a szervezet méretének növekedésével egyre fontosabbá válik. A kötegelt feldolgozású rendszerek idejében csak viszonylag egyszerű problémák jelentkeztek, mint például az egyes erőforrások megosztásának problémái, vagy nyomtatási sorral, listákkal kapcsolatos problémák. A gyorssegély-szolgálat hagyományosan úgy definiálhatnánk, hogy ez tulajdonképp egyfajta panaszkönyvi mechanizmus, ahol egy szolgáltatás élvezői, fogyasztói megjegyzéseket tehetnek, illetve kifogással élhetnek a számukra biztosított termékekkel, szolgáltatásokkal, eljárásokkal, szállításokkal stb. kapcsolatban2 A gyorssegély-szolgálat feladatai közé tartozik az esemény– probléma– és hibafelügyelet.

munkatársainak Azért létezik, hogy (felhasználóinak), ha segítséget nyújtson valamely informatikai a szervezet szolgáltatás használata közben bármilyen rendellenesség vagy üzemzavar lép fel. A 3-as számú ábra mutatja azon területeket, melyekre a gyorssegély-szolgálat hatást gyakorol. 2 Informatikai Tárcaközi Bizottság ajánlásai VII. / 9 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila 3. ábra: A helpdesk kapcsolatrendszere 3 Az első dolog, amit egy helpdesk operátor megnéz, az a felhasználó által adott hibaleírás. Utána összegyűjti a hiba elhárításához szükséges információkat, majd megpróbálja azt megoldani. A hibaelhárítás menetét befolyásolja a vállalatnál kiépített helpdesk rendszer felépítése. III.2 A helpdesk fajtái A gyorssegély-szolgálatnak alapvetően három típusát különböztetjük meg: 3 • Egyszerű, központosított •

Többfunkciós, központosított • Illetve elosztott. Forrás: Klimkó-Szabó: IT infrastruktúra menedzsment VII. / 10 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila III.2a Az egyszerű, központosított helpdesk Ezen helpdesk típust általában akkor célszerű választani, ha a cég egy központi számítógép-központtal rendelkezik. Nagy előnye, hogy közel van a felügyelő személyzethez, a szakértelem jól megosztható, kisebb létszám is elegendő, viszont minden egyes kérést egyetlen mindennel foglalkozó munkahelyre továbbítanak. Nem célszerű ezen típus bevezetése, ha a gyorssegélyszolgálathoz naponta számos kérés érkezik, mert ekkor ez a szervezeti felépítés rontja hatékonyságát. Az egyszerű, központosított helpdesk felépítését a 4-es számú ábra láthatjuk. 4. ábra: Egyszerű, központosított helpdesk 4 4 Klimkó-Szabó: Infrastruktúra menedzsment VII. / 11

Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila III.2b Többfunkciós, központosított helpdesk A többfunkciós helpdesket a specializáció jellemzi, ha az alaptevékenységre időszakonként számos kérés érkezik, akkor ennek bevezetése célszerűbb, mint az egyszerű gyorssegély-szolgálaté. Jellemzője, hogy kapcsolat van az IT és a szervezeti alaptevékenységet segítő helpdesk központ között. A többfunkciós központosított gyorssegély-szolgálatot az 5-ös számú ábra mutatja. 5. ábra: Többfunkciós, központosított helpdesk 5 III.2c Elosztott gyorssegély-szolgálat Ez a módszer hálózatos, többfelhasználós rendszert feltételez, egységes analógiák alapján működnek, az előzőektől gyorsabb és közvetlenebb reagálást tesz lehetővé, ugyanakkor méreténél fogva nehezebb koordinálni. Megvalósítása nagyobb méretű vállalkozásoknál javasolható, mert itt lehet jól kihasználni

azon előnyét, hogy fiókonként (telephelyenként) is elérhető. Felépítését a 6-os számú ábrán láthatjuk. 5 Forrás: Klimkó-Szabó: Infrastruktúra menedzsment VII. / 12 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila 6. ábra: Elosztott helpdesk III.2d A helpdesk rendszerek erőforrás igény szerinti tipizálása A szervezet méretétől és igényeitől függően bevezethet egyszerű, közepes, és nagyméretű helpdesk üzemeltetést Az egyszerű gyorssegély-szolgálat (helpdesk pult) még a kisebb vállalkozások számára sem javasolható, mert a tevékenysége csupán az események rögzítésére korlátozódik. VII. / 13 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila A közepes méretű üzemeltetés a legtöbb cég számára megfelelő lehet, ugyanis ez már képes az események naplózására, koordinálja az IT tevékenységet,

többfelhasználós hozzáférést biztosít az informatikai rendszerekhez. A nagyméretű gyorssegély-szolgálat bevezetése azon vállalkozásoknak ajánlott, melyek több távoli telephellyel rendelkeznek, jellemzője, hogy egyetlen központi részlege van. III.3 A gyorssegély-szolgálat személyzeti kérdései A gyorssegély-szolgálat várható kihasználtságának becslésével, tekintettel a napi várható kérések számára a tervezésnél meg kell állapítanunk a kívánt létszámot, és el kell döntenünk, hogy milyen minőségű szakembergárda üzemeltesse a helpdesket. Az üzemeltető személyzetet képzettségük alapján két csoportra bonthatjuk: • Tapasztalt műszakiak • Minőségi, de nem műszaki személyzet (Ők csak az egyszerűbb feladatokat kezelik, a többi továbbadják a műszakiaknak.) Tapasztalati szintjük alapján a helpdesk személyzetét három osztályba sorolhatjuk: • Gyakorlatlan • Tapasztalt • Szakértő III.3a A

gyakorlatlan munkaerő A gyakorlatlan személyzetre építő gyorssegély-szolgálat előnye, hogy azonnal, és gyorsan képes reagálni a hívásokra, és az egyszerűbb problémákat VII. / 14 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila megoldja, viszont a bonyolultabb eseteket továbbadják egy szakért ői csoportnak. Az első szintű hibaelhárítás folyamatát kifogástalanul el tudják látni. III.3b Tapasztalt szakemberek A tapasztalt embereket foglalkoztató helpdesk esetén a hívásokat továbbítják az adott szakterület specialistájához (tapasztalt szakértőjéhez), így a problémák jelentős részét azonnal kezelni tudják. Probléma lehet, hogy ha a szervezeten belül csupán egy ember foglalkozik az adott témával, akkor ez arroganciát szülhet. Ők végzik a másodszintű hibaelhárítást III.3c Szakértők alkalmazása Szakértői személyzet alkalmazása esetén a vállalkozás a tudás

minőségére épít, a szakemberek a felmerülő problémákat, azok tovagyűrűzése nélkül próbálják megoldani, minden hívást külön-külön elemeznek, és kiértékelnek. Az ilyen szakértői személyzet toborzása nagy körültekintést és persze pénzt igényel. III.4 Helpdesk rendszerek tervezése és bevezetése A gazdálkodó szervezetek IT részlegei túlságosan különböznek ahhoz, hogy egy univerzális megoldás tudjunk adni a gyorssegély-szolgálati rendszerek bevezetéséhez, és üzemeltetéséhez. Mindenek előtt válasszuk ketté a bevezetés folyamatát: 1. Már van a részlegben működő IT szolgáltatás 2. Még nincs semmilyen IT szolgáltatás a részlegben (új részleget hoz létre a szervezet) Az első esetben feltehetőleg azért kerül sor a gyorssegély-szolgálat bevezetésére, mert erre kifejezett igény merül fel, az informatikai szolgáltatások javulását várják a bevezetéstől. Nehezebb a feladat azért, mert már

egy meglévő rendszerhez és a megszokott eljárásokhoz kell alkalmazkodni. VII. / 15 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila A második eset tulajdonképp egy zöldmezős beruházás, ez esetben a hasonló méretű és tevékenységű részlegeken alapuló becslésekre kell építenünk a bevezetés folyamatát, azaz tervezett adatokat kell alapul vennünk tényadatok helyett. Bármely eset is áll fenn figyelembe kell venni, a tevékenységek és várható események méretét, és a helpdesk a szervezeti alaptevékenységet segítő lehetőségét, amely nem csupán az informatikához kapcsolódó kérésekkel, (klasszikus értelemben vett helpdesk) hanem a szolgáltatás használatához ad átfogó, általános segítséget. Pl Egy készletnyilvántartó rendszer esetében iránymutatást ad az adott készlet besorolását illetően. Ha meghatároztuk a bevezetendő rendszer alapparamétereit, akkor elkezdhetjük a

tervezést. Rendszerfejlesztés Használat A cél meghatározása Vezetői feladatok A folyamatok Küldetés meghatározása ellenőrzése Eszközök megválasztása Szervezeti feladatok IT rendszerekhez Technikai kapcsolódó A projekt-team A felhasználók képzése kiválasztása és képzése Események rögzítése Implementáció Karbantartás Integráció Ellenőrzés folyamatok Tudásbázishoz Kezdeti tudásbázis A tudásbázis folyamatos kapcsolódó felépítése bővítése 2. Táblázat: A helpdesk tervezése és használata során fellép ő feladatok 6 6 S. David – J Botkin: Experience management for self-service and helpdesk support VII. / 16 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila A következő alfejezetekben a táblázat egyes részeit fogjuk megvizsgálni alaposabban. A III4a fejezet a cél és a küldetés meghatározása; a III4b az eszközök meghatározása; a III.4c az

implementáció, integráció, és ellenőrzés; a III.4d fejezet pedig a tudásbázis felépítésének témakörével foglalkozik III.4a A helpdesk bevezetésének előkészítése (A cél és a küldetés meghatározása) Vezetői feladatok: A gyorssegély-szolgálat bevezetésék sikeréhez először a célokat kell meghatároznunk, ez utat mutat a menedzsmentnek a bevezetés sikerének értékeléséhez. A célok kommunikálása a gyorssegély-szolgálat bevezetését végző projektteam felé a menedzsment elengedhetetlenül fontos feladata. A bevezetési folyamat sikerének vannak kvantitatív (erős) és kvalitatív (gyenge) kritériumai. A kvantitatív kritériumok magukba foglalják egy probléma megoldásnak átlagos kötéségét, a probléma megoldási idő, és a személyzet kérdését. A kvalitatív kritériumok szubjektív szempontokon alapulnak, úgymint a felhasználók vagy a helpdesk operátorok megelégedettsége. A vállalati kultúrában, a munkavállaló

a vállalkozással, és a többi munkavállalóval szembeni (negatív) hatalmának forrása a szaktudás, melynek továbbadásától sokan, még a helpdesk operátorok közül is vonakodnak. A helpdesk szolgáltatás bővítése, bevezetése során ezt az akadályt, úgy lehet legyőzni, hogy bevonjuk őket a fejlesztésbe, figyelembe vesszük igényeiket, kéréseiket. Ezáltal sajátjuknak is érezhetik a projektet Ilyen formán a befektetett tudás számukra megtérül. III.4b A gyorssegély-szolgálati rendszer tervezése7 Az eszközök megválasztása már a konkrét tervezési szakasz része. Figyelembe kell venni a meglévő hardver, szoftver, hálózati kiépítettség, és még sok más 7 e-Learning tananyag a Helpdesk és katasztrófa-menedzsmet témakörében (Számalk 2003) VII. / 17 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila egyéb fontos tényezőt. A legfontosabb feladat ebben a szakaszban, hogy

figyelembe vegyük mind a felhasználók, mind pedig a helpdesk operátorok képzettségi szintjét. A projektteam képzése után az implementáció következik Implementációs tervet kell készíteni, amely részletes fázisokra bontja a megvalósítást. Ezután meg kell tervezni a főbb elemeket és az alkalmazandó rendszert is. Teszt-tervet is kell készíteni a rendszerhez, amely annak teljesítményét és funkcionalitását ellenőrzi (válaszidő, eszkaláció, jelentések, rendszeradminisztráció, interfészek a többi funkcióval, katasztrófa-terv). Szükség lehet egy kész termék testreszabására, ami magába foglalhatja képernyőtervek és jelentés formátumok tervezését. A gyorssegély-szolgálat interakciós helyein (ahol fogadják a felhasználók kéréseit) szükséges a szoftverhez való hozzáférés lehetősége, illetve a futtatást lehetővé tevő berendezés. Meg kell határozni az eseménykezelés módjait (ez lehet közvetlen - pl. telefon,

intranet - és kontrollált - visszahívásos jellegű, pl. fax, e-mail) Definiálni kell a lehetséges eseményekhez tartozó súlyossági szinteket, és az ezeknek megfelelő válaszidőket. Eszkalációs eljárást kell tervezni, ehhez az eszkalációs küszöböket (kritériumokat) világosan meg kell határozni: • Kódolási rendszer (a hibákra vonatkozó strukturált kód szerint) • Súlyossági/következmény kódok (kód a hozzátartozó leírással és a helyreállítási szintidővel) • Meghibásodás osztályozása • Híváskezelési eljárások (eleinte papír-alapú leírások, folyamat-diagramok alkalmazhatók, ideális esetben számítógép alapú forgatókönyvek segítik a folyamatot). VII. / 18 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila Ezek a kapcsolódó rendszerelemek olyan tervezést igényelnek, amit az adott környezethez kell igazítani. Ki kell alakítani a gyorssegély-szolgálati

eljárásokat katasztrófa-szituáció eseteire is (hálózat, telefon kiesése, adatvesztés, elektromos ellátás hiánya, stb.) III.4c A helpdesk bevezetése A tervezési szakasz lezárultával hozzáláthat a vállalkozás a gyorssegélyszolgálat bevezetéséhez. A működő környezet megteremtése feszesebb ellenőrzést (projekt menedzsmentet) igényel, mint a tervezési fázis, minthogy több ember vesz benne részt és a függőségek nyilvánvalóbbakká válnak. Jóval nagyobb hangsúlyt kell helyezni a projektirányítási (menedzsment) szempontokra, annak érdekében, hogy sikeresen valósítsuk meg a kitűzött követelményeket. Ebben a szakaszban a következő tevékenységekre van szükség: • a szükséges berendezéseket be kell szerezni, és üzembe kell állítani, • a kész szoftver eszközöket testre kell szabni, • a rendszereket tesztelni kell, • fel kell állítani a berendezések/szoftverek leltárát, • el kell készíteni

a dokumentációkat, • ki kell képezni a személyzetet, • végre kell hajtani az átvételi tesztelést. A berendezések beszerzése és üzembeállítása VII. / 19 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila Az időigényes engedélyeztetési eljárásokat (ha szükségesek) a lehető legkorábban meg kell kezdeni. A szoftver csomagokat és a további szükséges berendezéseket meg kell rendelni. A szállítókat értesíteni kell a szállítás időpontjairól és helyszíneiről, ahogy az a megvalósítási tervben szerepel. Minden kapcsolódó hálózati, vagy építészeti munkával az üzembe helyezési tervek szerint egyeztetni kell. Az összes berendezésnek át kell esnie egy alapos üzembe helyezési teszten, ha az szükséges, szállítói segítség igénybevételével. A készen kapható eszközök testreszabása Meg kell győződnünk arról, hogy a beszerzett szoftver eszközökön elvégzett

összes módosítás megfelel az utolsó (elfogadott) specifikációnak. Ha a tervezési szakaszok során nem volt lehetséges a testre szabás elvégzése, akkor éljünk a szoftver által nyújtott módosítási/finomítási lehetőségekkel. (Itt szoktak először előjönni azon típus problémák, hogy a szoftver vásárlója/megrendelője nem azokat a megkívánt funkciókat kapta amire tulajdonképpen szüksége lenne.) Ha kisegítő egyedi rutinokra, mint pl. adatbázis betöltésre/konverzióra, meglevő rendszerek változtatására és ad hoc elemző lehetőségekre lenne szükség, akkor ezeket ebben a szakaszban, minél hamarabb ki kell fejleszteni. A rendszerek tesztelése Minden egyes rendszert alaposan, mélyrehatóan tesztelni kell a tesztelési terv előírásai szerint, a testre szabás és a kapcsolódó célirányos fejlesztések befejezése után. Figyelmet kell fordítani az esemény-felügyelő rendszerre A rendszer funkcionalitásának sikeres tesztelése

után a rendszer teljesítőképességét kell vizsgálat alá vetni. Ez maga után vonhatja nagyobb létszámú személyzet foglalkoztatását és az összes kapcsolódó berendezés üzembe helyezését. A berendezések és szoftverek nyilvántartásának felállítása VII. / 20 Infrastruktúra menedzsment A konfigurációkezelés BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila nyilvántartása lényegi és szükséges része az eseménykövető rendszernek. Ha nem létezne ilyen nyilvántartás, a lehető leggyorsabban létre kell hozni. A nyilvántartás felállítása jelentős adminisztratív munkával jár, és késleltetheti a gyorssegély-szolgálat indítását. A dokumentációk elkészítése A tervezési szakasz dokumentumai alapján be kell fejezni az összes előírt dokumentációt. Ezek közé kell, hogy tartozzon a gyorssegély-szolgálat, a számítógép üzemeltetés, a hálózati üzemeltetés, a problémakezelés és más

kisegítő csoportok és felhasználó személyzet eljárásai. Ahol az lehetséges, az előző területeken érintett személyzet járuljon hozzá a dokumentációk elkészítéséhez, és adjon az anyag elkészítéséhez technikai segítséget. A személyzet kiképzése Ez valószínűleg a megvalósítási terv legkritikusabb része, így kitüntetett figyelemben kell részesíteni. A képzésnek folyamatos tevékenységnek kell lennie a tervezés, megvalósítás és testre szabás során, ugyanakkor szükséges egy képzési program is, azért, hogy biztosítsuk a személyzet teljes körű felkészültségét az éles üzembeállítás idejére. III.4d A tudásbázis felépítése Egy olyan gyakorlatorientált rendszer, mint a gyorssegély-szolgálat teljesen hasztalan hasonló környezetben történt esetek, problémák leírása nélkül. A tudásbázis létrehozásának három fő célja van: • A helpdesk operátorok képzése • A folyamatok megismerése •

A rendszer elindítása VII. / 21 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila A gyakorlatban a kezdeti tudásbázis felépítésében a tervezést, és a bevezetést végző projektteam nagy szerephez jut, segítségükkel feltölthető és elindítható alapesetekkel a helpdesk tudásbázisa. Meg kell alkotni azokat a szükséges formanyomtatványokat, bejelentő lapokat, melyek segítségével a tudásbázis folyamatosan bővíthető. III.4e Felmerülő lehetséges problémák A helpdesk funkció bevezetése, tervezése, és üzemeltetése során számos probléma merülhet fel. Ha a szolgáltatást újonnan vezették be a vállalatnál, akkor előfordulhat, hogy a felhasználók esetleg kikerülik a szolgálatot, és egyenesen az informatikai személyzetnek jelentik a meghibásodást különösen, ha a bevezetés előtt ez volt a megszokott rendszer. (Pl Esettanulmány) Ebben az esetben, az informatikai személyzettől

meg kell követelni a probléma továbbítását. Megeshet, hogy a funkció bevezetése során oly mértékű többletköltségek jelentkeznek, hogy az megakadályozza a teljese megvalósítást, az ilyen sikertelen bevezetésnél a további kísérletekhez már sokkal nehezebb lesz a felhasználók megnyerése. A gyorssegély-szolgálat, mint kizárólagos kapcsolattartási pont, szűk keresztmetszetnek bizonyulhat, ha nagy számban lépnek fel események, vagy ha egy esemény bekövetkeztekor nagyszámú felhasználó érintett. Ezt a csúcsterhelés megfelelő felmérésével, illetve egy alkalmas helyi megbízott kinevezésével kerülhetjük el. III.5 A gyorssegély-szolgálati rendszer bevezetésének hasznai illetve költségvonzatai. III.5a A helpdesk költségei 1. "Időköltség": Az informatika területén a hibaelhárítás hagyományosan személyes kapcsolatokon keresztül valósul meg. Harmadik személy bevonása jelentősen megnövelheti a problémamegoldás

időszükségletét. VII. / 22 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila 2. Standard megoldás hiánya: A szervezetek különbözőek, ezért nem lehet egy olyan standard megoldást kidolgozni, ami minden egyes szervezet esetében megfelelő hatékonyságot, illetve eredményességet biztosítana. Ennek következtében minden egyes szervezet esetében, a bevezetés előtt, előzetes, az adott szervezetre vonatkozó felmérésre van szükség, ami többletköltségeket eredményezhet. Ez az elemzés azonban nem spórolható meg, illetve nem lehet félvállról venni, mert annak nem megfelelő súlyú kezelése olyan rendszer bevezetését eredményezheti, ami a szervezet profiljának nem megfelelő, ezáltal nem segíti annak működését sem. Érdemes tehát pénzt és időt áldozni rá 3. A munka végzéséhez szükséges erőforrások költségei: Ahhoz, hogy a segélyszolgálat betöltse rendeltetését megfelelő

emberekre, felszerelésekre (szoftver, hardver stb.) van szükség, aminek beszerzése (esetleg saját fejlesztése) többletberuházással jár. Ezek egy hatékony rendszer esetében hamar megtérülnek. • Alkalmazottak fizetése: 250-500 ezer forintig, • A feladatok elvégzéséhez szükséges hardware biztosítása: egy PC 500-600 ezer forint 4. Ha szükséges egyedi fejlesztés: Előfordulhat, hogy a megfelelő szoftver nem áll rendelkezésre, és egyedi fejlesztésre van szükség. Ez olyan méretű többletráfordítást eredményezhet, ami gondos és alapos előzetes kutatómunkát, illetve kalkulációkat igényel. 5. Megfelelő infrastruktúra kialakítása: Ebbe a kategóriába a felhasználok felé irányuló kommunikációs csatornák kialakítása tartozik. Ezeken a csatornákon keresztül lehet a megfelelő információkat eljuttatni az illetékes felhasználókhoz. Az infrastruktúra kialakítása: 100 milliós nagyságrendű, (ebben benne van az intranet

kifejlesztése is), VII. / 23 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila 6. A túlterheltség problémájának kezelése Ha a rendszer túlterheltté válik az mindenképpen a segélyszolgálat munkájának hatékonyság-csökkenését eredményezi. 7. Ellenérzések a helpdeskkel kapcsolatban A szervezeten belül jelentkezhet rendszerrel szembeni ellenérzés. Ebben az esetben előfordulhat, hogy nem megfelelően használják, vagy nem minden esetben (amikor egyébként indokolt lenne) veszik igénybe a szolgáltatást a szervezet dolgozói. 8. Ha a bevezetés sikertelen: A funkció bevezetésének sikertelensége a felhasználók körében hiteltelenséghez vezethet. A második (és a sokadik) kísérlethez már sokkal nehezebb lesz a felhasználók elkötelezettségét megszerezni! Ennek következtében az első bevezetésnél nagy körültekintéssel kell eljárni. III.5b A helpdesk haszna 1.

Kommunikáció: A helpdesk elősegíti a hatékony kommunikációt a felhasználók és az informatikai részlegek között. 2. "Központi gyűjtőhely": A rendszerrel kapcsolatos hibáknak, hiányosságoknak a gyűjtőhelye. A tipikus hibák kiszűrhetővé válnak és ezáltal javítható a rendszer működésének hatékonysága. 3. Visszacsatolási pont: Az informatikai szolgáltatásokkal kapcsolatos vélemények összegyűjtése is itt történik. 4. Gyorsaság: Fontos a felhasználók problémáinak azonnali kezelése Az előzetesen történő forgatókönyvek kialakítása szintén a gyorsaságot segíti elő. VII. / 24 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila 5. Minőség: A problémamegoldó szolgáltatás színvonalának javulása 6. Tájékoztatás: A felhasználó folyamatos tájékoztatása az események bekövetkezéséről. 7. Együttműködés: Együttműködés más informatikai

szolgáltatókkal a vezetők számára összeállított jelentések készítésében. III.6 Esettanulmány III.6a Egy hazai bank gyorssegély-szolgálata Egy hazai lakossági és vállalati szolgáltatásokat nyújtó országos hálózattal rendelkező bank helpdesk rendszere nagyvonalakban következő jellemzőket követte: 1. Mivel számos fiókkal rendelkeztek, ezért központosított helpdesk mellett döntöttek. 2. Az egyes számítógépes alkalmazások minden fiókban azonosak voltak 3. Fiókonként működött egy kisebb-nagyobb helyi IT részleg, aminek feladata a problémák azonnali orvoslása (első szintű hibaelhárítás) volt. 4. A felhasználó döntötte el, hogy probléma felmerülése esetén felhívja e a gyorssegély-szolgálatot vagy a helyi kollégákhoz fordul tanácsért. 5. A kisebb problémák orvoslása általában azonnal megtörtént, viszont tovagyűrűző rendszerhibák esetén a megoldás váratott magára. Összefoglalva, a szervezetnél, egy

többfunkciós, központosított gyorssegélyszolgálat működött. VII. / 25 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila 7. ábra: A bank helpdesk rendszere A bank helpdesk rendszere a gyakorlati tapasztalatok szerint nem működött túl jól, ennek oka az volt, hogy a felhasználók kezdetben bizalmatlanok voltak a helpdesk személyzetével szemben. A gyorssegély-szolgálat személyzete gyakorlatlan volt a problémák kezelése tekintetében. A központi helpdesknél gyakorlott, nagy tapasztalatokkal rendelkező személyzetet kellett volna alkalmazni, ugyanis a felhasználók a tapasztalatok szerint csak akkor hívták őket, ha nagyobb probléma merült fel, amit helyben nem tudtak orvosolni. Ezért lett volna szükség itt a nagyobb szakértelemre. A másik oldalról, ha a központi helpdeskünk gyakorlatlan szakembereket alkalmaz, akkor ez esetben felesleges helyi problémaelhárító IT részlegeket is

üzemeltetni, mert ez közel hasonló feladatokat lát el. A nagyobb rendszerhibákat vagy nem, vagy pedig csak elkésve tudták kezelni, ezért nem működött megfelelően a bank gyorssegély-szolgálata. VII. / 26 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila A bank később felderítette a hiba okát, végső soron lecserélték teljes IT rendszerüket, és átalakították a gyorssegély-szolgálatot is, mégpedig úgy hogy megszüntették a helyi IT részlegeket, és áttértek az egyszerű, központosított helpdeskre. 8. ábra: Egyszerű, központosított helpdesk a banknál Az eset tanulsága, hogy egy várhatóan sok hibával működő rendszer esetén különös figyelmet kell fordítanunk a gyorssegély-szolgálat megtervezésére, hogy az képes legyen a hibákat időben felderíteni, és megoldani. Annak ellenére, hogy a rendszer nem működött olajozottan, nem fordult elő a banknál adatvesztés, ami a napi

tranzakciók újrarögzítését követelte volna. (Az archiválás naponta történt.) VII. / 27 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila III.6b Egy helpdesk hívás a gyakorlatban A következő beszélgetést, egy informatikai szolgáltatások nyújtására szakosodott cég, és egyik ügyfele között rögzítettük: –Jó napot kívánok ZW Service Desktől, miben segíthetek? –Jó napot kívánok! Kis Balázs vagyok az XY cégtől, és egy problémát szeretnék bejelenteni. (A helpdeskes rögzíti a nevet és megindítja a dokumentálást, rögtön látja az adatbázisban az ügyfél adatait, majd megkezdi a probléma detektálását.) –Igen, tessék mondani, hallgatom! –Nem férek hozzá a leveleimhez, nem működik a levelezőrendszerem. –Mit tapasztalt, kapott valamilyen hibaüzenetet? –Elindítottam a gépet, de kaptam egy piros ablakban egy hibaüzenetet. –Mi volt a lényege a

hibaüzenetnek? –Sajnos már nem emlékszem, nincs előttem. –Tudja reprodukálni? –Igen, elindítom még egyszer. (Közben folyik a dokumentálás: jelenleg ez egy incidens típusú probléma, hisz először fordul elő az ügyfélnél.) –Igen? –Ezt a hibaüzenetet kapom: „Unable to open your profile”. –Kapott-e megelőzően is ilyet? –Nem, ez az első alkalom. VII. / 28 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila –Vannak-e hálózati meghajtói? (Tehát hálózaton vannak-e a gépei?) –Hogyan? –My computer, C meghajtón kívül más meghajtó van-e? –Van. –Megnyitható? –Igen. –Rendben. Akkor továbbítom a problémát a kollegám felé –Mikorra lesz megoldásom? –A szerződésben vállalt határidőn belül mindenképpen, regisztráltam az esetét a 7345-ös számra. –Köszönöm. –Erről levelet is fog kapni, de mivel ezzel van a gond, ezért telefonon is értesítjük még Önt. A

probléma megoldása esetén meg mindenképpen hívom –Rendben. –Viszonthallásra. –Viszhall. Az eset tipikusnak mondható: A felhasználó nem a szokásos programüzeneteket tapasztalja, közben hiba történik, a problémát nem tudja egyértelműen leírni. Ezt a helpdesknél dokumentálják majd, ha tudják, megoldják. A jövőbeni hasonló problémák esetén viszont már azonnal tudnak cselekedni: ha a tudásbázisban előfordult volna már ilyen eset, akkor elképzelhető, hogy a helpdeskes kolléga azonnal meg tudta volna azt oldani. Jól döntött a hívást fogadó szakember VII. / 29 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila akkor, amikor közölte a referenciaszámot, és nem mondott konkrét időpontot, a megoldást illetően. Ez utóbbi azért fontos, mert az IT személyzettől (különösen) elvárják, hogy mindent pontosan és határidőre teljesítsen, és abban az esetben, ha a hiba orvoslása

közben váratlan esemény történik, akkor megrendülhet az ügyfél bizalma. Később esetleg nem a helpdeskhez fordul, hanem egy tapasztaltabb kollégájához, aki ha megoldja a problémát az esetről nem szerez a helpdesk tudomást, vagy ami még rosszabb megkísérli saját maga elhárítani a hibát, és ezzel több kárt csinál, mint hasznot. VII. / 30 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila IV. Katasztrófa-menedzsment Az üzleti vállalkozások számára nagy kihívást jelent az előre nem várható eseményekre való felkészülés, különösen akkor, ha a nem várt esemény az üzletmenet szempontjából kritikus IT szolgáltatásoknál következik be. A nem várt eseményekre való felkészülés a katasztrófa elhárítás tervezése. A múltban a katasztrófa-menedzsmentnek nem tulajdonítottak nagy fontosságot, azonban a tapasztalat bebizonyította ennek létjogosultságát, pl. nagy

informatikai szolgáltatóknál bekövetkezett szándékos támadások kieséseket okoztak, mert nem voltak erre megfelelően felkészülve, vagy gondoljunk csak arra, hogy hányszor bosszankodtunk már bank automaták előtt állva, mert az különféle okokra hivatkozva nem adott ki pénzt. Ennél fogva a szervezetnek jól fel kell készülnie az előre nem várt katasztrófák bekövetkezésére, és arra katasztrófa elhárítási terveket kell készítenie, mégpedig úgy, hogy mielőbb képes legyen az alaptevékenységének folytatására, és a szolgáltatás helyreállítására. Az informatikai katasztrófák lehetséges következményeit az alábbi (9-es számú) ábra szemlélteti. A következmények súlyossága az függ a vállalkozás tevékenységi körétől. (pl A szolgáltatás folyamatosságának megszakadása egy áramszolgáltatónál súlyosabb, mint az esetleges információvesztés, de nem úgy egy banknál.) Feltehetjük azonban a kérdést, hogy

miért is van szükség egyáltalán katasztrófamenedzsmentre, hiszen ilyen rendkívüli helyzet nem túl sűrűn fordul elő egy szervezet életében. Elsősorban azért szükséges a katasztrófa-menedzsment, mert minden egyes esetben, amikor az informatikai szolgáltatások színvonala csökken, vagy nem áll egyáltalán rendelkezésre, akkor a felhasználók nem tudják elvégezni napi feladataikat. Az informatikai rendszerektől való függőség a VII. / 31 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila jövőben várhatóan növekedni fog, ez pedig nagyobb kockázatot jelent. A katasztrófa elhárítási terv pedig pont az az eszköz, amely az informatikai szolgáltatásokkal kapcsolatos kockázatokat csökkenti. A vállalakozások vezetése a katasztrófákra való tervezést gyakran pénzkidobásnak gondolja mindaddig, amíg a szükséghelyzet be nem következik. Ugyanis a tervezésnek csak ekkor

számszerűsíthető igazán a haszna. 9. ábra: IT katasztrófák lehetséges következményei A katasztrófákat vagy meg kell előznünk, vagy enyhítenünk kell lehetséges következményeit. A lehetséges következmények enyhítésével a katasztrófa elhárítás tervezése foglalkozik. IV.1 A katasztrófák megelőzése A katasztrófáknál a megelőzés szempontjából az elsődleges lépés, a veszélyforrások azonosítása és csoportosítása. Az esetlegesen bekövetkező károkra vonatkozóan kárértéki szinteket kell felállítani, amik általában a VII. / 32 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila következő csoportokat foglalják magukba. Ezeket a kategóriákat kvantitatív mutatók alapján alakítják ki: 8 • jelentéktelen kár, A • csekély kár, • közepes kár, • nagy kár, • kiemelkedően nagy kár katasztrófa-menedzsmentben veszélyforráson a biztonság ellen

ható események bekövetkezésének lehetőségét értjük. A veszélyforrások a következők lehetnek: • Természeti csapás • Szándékosság • Szoftver, hardver vagy rendszerhibák Az informatikai katasztrófák lehetséges okait, és előfordulási gyakoriságait a 10. Ábra szemlélteti 8 Több szerző (ld. Irodalomjegyzék): Informatikai rendszerek biztonsági követelményei (3237oldal) VII. / 33 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila Szoftver (24%) Víz (9%) Áram (21%) Sztrájk (7%) Épület (3%) Tûz (36%) 10. ábra: Az informatikai katasztrófák okai Az ábráról látható, hogy a katasztrófa tehát emberi vagy civilizációs eredetű nem várt negatív következményű rendkívüli esemény. Ezen esemény bekövetkezési valószínűsége pedig a kockázat. A kockázatértékelés területén az úgynevezett CCTA Risk Analysis Management Method (CRAMM) módszert használják, ez a

módszer leírja a számítástechnikai rendszerek sebezhető pontjait, és javaslatokat tesz ellenintézkedésekre. A katasztrófák megelőzési lehetőségei közül a CRAMM az alábbiakat említi: • Tűzjelző eljárások használata • Adatvédelmi eljárások alkalmazása • Beléptetési eljárások • Karbantartó és • Személyzeti eljárások alkalmazása. VII. / 34 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila A katasztrófa védelem két szinten jelenik meg egy szervezetben, egyrészt az információvédelem, másrészt a működés megbízhatóságának területén. Ennek alapján 8 kiemelt terület van, amelyek a katasztrófák megelőzése szempontjából alapos vizsgálatra szorul. • Infrastrukturális védelem, • Hardvervédelem, • Szoftvervédelem, • Adathordozók védelme, • Adatok védelme, • Dokumentumok védelme, • Kommunikáció biztonságának biztosítása, • Személyek

biztonsága, IV.1a Az infrastrukturális védelem Az infrastrukturális védelem kiterjed a légkondicionálás, tűzvédelem, villám-, víz-, és sugárzásvédelem, valamint az elektromos áram okozta problémák kivédésére, amely a katasztrófák 21%-ának okozója. Az IT infrastruktúra menedzsment tárgykörében viszont fontosabb témakör a hardver, szoftver, és az adathordozók védelme. Az információfeldolgozás biztonsága egy jó és tesztelt hardver és egy megbízható szoftver együttműködésén alapszik. A hardver részét alkotják a számítógép-hálózatok, a kábelezés, a számítógépek, az operációs rendszerek, az adatbázis-kezelő rendszerek, az irodaautomatizálás, és az alkalmazási csomagok. A biztonságos működés érdekében nagyon fontos egy korrekt VII. / 35 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila megállapodás a hardver-szállítókkal a garantált javítási,

cserélési feltételekről és határidőkről. IV.1b A hardvervédelem a következő lépésekből áll: 1. A belépés ellenőrzése Ez könnyebben megvalósítható, ha minden készülék és műszaki berendezés egy helyen, feltétlenül kulccsal zárható helyiségben található. 2. A külső adathordozók centralizált beviteli/kiviteli felügyelete 3. A hardver környezeti feltételeinek ellenőrzése (hőmérséklet, nedvességtartalom, és ide tartozik a már említett légkondicionálás is). 4. Folyamatos nyilvántartás a rendszer minden készülékéről, azok műszaki változásairól. A hardver eszközök, szolgáltatások igénybevételéhez a felhasználó azonosítását és hitelesítését végző rendszer karbantartása. 5. A különösen érzékeny komponensek megelőző cseréje 6. Rendszeres megelőző karbantartás, pótalkatrészek készletezése 7. A használat hosszabb kimaradása esetén a felhasználó fokozott ellenőrzése. Alkalmazható

kényszerű kijelentkezés, a berendezés "blokkolása", képernyőzárolás. 8. A fejlesztő és a végrehajtó számítógépek szigorú elhatárolása (ez azt jelenti, hogy felhasználói gépen nem folyhat szoftverfejlesztés). 9. Mint az egész katasztrófavédelemben, itt is fontos alternatív cselekvési forgatókönyvek összeállítása a hardver kiesésekre vonatkozóan. VII. / 36 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila IV.1c Szoftvervédelem, Adathordozók védelme A szoftverek és az adathordozók védelmében elsősorban a megelőzésre kell koncentrálni, célunk a vírusfertőzések, az adathordozók esetében pedig a fizikai sérülések elkerülése. IV.2 A katasztrófa elhárítás tervezése A katasztrófa elhárítási terv lehetővé teszi, hogy a sérült IT rendszereket és szolgáltatásokat mielőbb a megkívánt megfelelő szintre tudják hozni szükséghelyzetben. A

tervezés ráfordításokat igényel a vállalattól, nincsenek azonnali hasznai, ezért nagyon fontos a vezetés elkötelezettsége a tervezés iránt. A katasztrófa-elhárítás tervezés fő lépései a következők: 1. Előkészítés, a felső vezetés támogatásának elnyerése 2. A tervező csapat kialakítása, az alapelvek tisztázása 3. A jelenlegi rendszerek, szolgáltatások, eszközök számbavétele, a prioritások meghatározása 4. A fenyegető tényezők meghatározása, a valószínűségek hozzárendelése, kockázatértékelés 5. A meglévő katasztrófa megelőzés és a szükséges kockázat- menedzsment összevetése 6. Katasztrófa-szituáció esetére riadó-, és a helyreállítás tervezése 7. A kapcsolódó védelmi szervezetek szerződéseinek megkötése, ellenőrzése 8. A kész terv példányainak átadása, ismertetése az érintettekkel, biztonsági másolatok elhelyezése VII. / 37 Infrastruktúra menedzsment BKÁE

Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila 9. Egyeztetés a szolgáltatási szint menedzserrel, a szükséges képzések felügyelete 10. A terv tesztelése 11. Karbantartás IV.2a Katasztrófa elhárítási vázlatok Katasztrófa-elhárítási vázlatok alatt a szükséghelyzetekre való felkészülés lehetséges módszereit értjük. Az hogy egy vállalkozás melyiket választja, az pénztárcájától, és lehetőségeitől függ. Alapvetően a következő katasztrófa elhárítási eljárások közismertek: • Semmit sem teszünk • Kézi helyettesítő eljárások alkalmazása • Kölcsönösségi egyezmény • Erőd megközelítés • Hideg indítású fix helyű megközelítés • Hideg indítású mobil megközelítés • Meleg indítású külső megközelítés • Meleg indítású belső megközelítés • Meleg indítású mobil megközelítés VII. / 38 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar

Információrendszerek Tanszék Csonka Attila 11. ábra: katasztrófa elhárítási vázlatok Vizsgáljuk meg egyenként az egyes lehetőségek tartalmát: 1. Semmit nem teszünk: Ez a lehetőség nem igényel ráfordítást a vállalkozástól, ugyanakkor azon következményekkel jár, hogy semmire sem készül fel, így az esetleges kár nagyobb lehet, mint a megtakarított költség. 2. Kézi helyettesítő eljárások kidolgozása: Ezen változatot napjainkban igen ritkán alkalmazzák, mert a szervezeteknél megfigyelhető az a tendencia, hogy csak olyan és annyi munkaerőt alkalmaznak, amennyi az adott feladat elvégzésére elengedhetetlenül szükséges, ezért ez a módszer megfelelő képzettségű és számú személyzet nélkül ritkán jön szóba. VII. / 39 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila 3. Kölcsönösségi egyezmény: Ezen forma alkalmazásánál hasonló profilú vállalkozások

kötelezettséget vállalnak egymás megsegítésére IT szolgáltatások kiesése esetén. Elméletben ez a módszer az egyik legjobb megoldás lehetne a vállalkozások számára, a gyakorlatban viszont nem túl népszerű megoldás, mert egyrészt a hasonló tevékenységi kör gyakran rivális vállalkozásokat takar, másrészt a katasztrófa helyzetben a segítő cég normális üzletmenete rovására mehet a segítség. 4. Erőd megközelítés: E módszer esetében a cég nem alakít ki költséges tartalék telephelyet, hanem meglévő telephelyének minél üzembiztosabbá tételére törekszik, a kritikus berendezések többszörözése segítségével. 5. Hideg indítású fix megközelítés: A vállalkozás fenntart egy üres számítógép termet, ahol a szükséges infrastruktúra rendelkezésre áll, viszont a számítástechnikai eszközökről szükség esetén gondoskodni kell. 6. Hideg indítású mobil megközelítés: Ebben az esetben a vállalkozás a

telephelyet szállítja a megfelelő helyszínre, viszont a számítástechnikai eszközökről külön kell gondoskodni. 7. Meleg indítású külső megközelítés: Egy külső cég telephelyet biztosít a vállalkozás számára, számítástechnikai ahol eszközök mind az rendelkezésre infrastruktúra, állnak. A mind a szolgáltatást többnyire egyidejűleg több cégnek is biztosítják, így a költségek megoszlanak. 8. Meleg indítású belső megközelítés: Ez a katasztrófa elhárítási vázlat a klasszikus eset: a vállalkozás saját maga gondoskodik tartalék telephelyről, ahol minden szükséges IT eszköz a rendelkezésére áll az alaptevékenység folytatásához. E módszer azért népszerű, mert abban az VII. / 40 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila esetben, ha a telephelyet épp nem használják rendeltetése szerint, használhatják oktatásra, fejlesztésre,

tesztelésre stb. 9. Meleg indítású mobil megközelítés: Egy külső cég szállítja le a szükséges IT eszközöket megadott határidőre, viszont az infrastruktúráról az igénybevevő cégnek kell gondoskodnia. IV.2b A katasztrófa elhárítási terv tartalma A követendő események sorát a katasztrófa elhárítási tervben részletesen le kell írni. Tevékenység-sorozat katasztrófa esetén:9 1. Az esemény bekövetkezte 2. Az esemény felismerése 3. Beavatkozás az esemény megállítására 4. A katasztrófa-elhárítási csapat riasztása 5. A károk enyhítése 6. A helyreállítási folyamat megindítása 7. Az alaptevékenység visszaállítása 8. Tényleges helyreállítás 9. A tanulságok levonása 9 ITB ajánlások VII. / 41 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila A jó katasztrófa-elhárítási tervnek feltétlenül ki kell terjedni az adminisztratív elemekre, az akcióterv

lépéseire, annak tesztelésére, karbantartására, és az alkalmazottak képzésére. A CCTA (Central Communication and Telecommunication Agency) ezen túlmenően a katasztrófa elhárítási tervbe a következőket ajánlja: 1. Adminisztráció: Itt kell felsorolni azon érintett személyeket, akik a katasztrófa elhárításáért felelősek, meg kell határozni a tartalék telephely típusát és helyét, és a terv használatának körülményeit. 2. Informatikai infrastruktúra: Ide tartozik a külső partnerekkel kötött katasztrófa elhárítási és helyreállítási szerződések ismertetése, és az egyes tartalékrendszerek. (pl. szoftver, hardver, és egyéb telekommunikációs elemek felsorolását) 3. IT infrastruktúra menedzsment és követendő eljárások: E fejezetnek kell tartalmaznia a katasztrófa helyezet esetén követendő pontos lépéseket, a tartalék telephelyre vonatkozó üzemeltetési feltételeket, a követendő helyettesítési

eljárásokat, és a betartandó IT előírásokat. 4. Személyzet: Ezen fejezetben kell megnevezni azokat a munkatársakat, akiket a tartalék telephelyre szállítanak (ha ez szükséges). 5. Biztonság: A fejezet a CCTA ajánlása szerint tartalmazza a bomba és tűzriadó esetén követendő eljárásokat, a tartalék alkatrészek felsorolását, az értesítendő külső szerveket, az elsősegély-nyújtási eljárások leírását. 6. Tartalék telephely: A terv ezen részében a tartalék telephelyen betartandó biztonsági előírásokat, és a lebonyolítandó műveletek listáját kell leírni. VII. / 42 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila IV.2c A terv implementálása, szükséghelyzet utáni helyreállítás Mint minden terv, így a katasztrófa elhárítási terv is akkor ér valamit a gyakorlatban, ha annak megvalósítására a vállalkozás felkészíti dolgozóit. Az alkalmazottaknak pontosan

tisztában kell lenniük a tervek tartalmával, mivel katasztrófa helyzet esetén az emberek általában nem terveket szoktak olvasni, hanem többnyire ösztönösen cselekszenek. Ez a cselekvés válasz a katasztrófa-helyzetre. Életbe lép a riadóterv: első lépés az előidéző vagy fenntartó okok megszűntetése, a kárelhárítás. Összeáll a válságstáb, megtörténnek az előírt személyi riasztások, megindul a tervszerű híradás. Fel kell venni a megfelelő beavatkozó szervvel a kapcsolatot A riadó után a veszteségek számbavétele, és a katasztrófa-állapot megállapítása következik. A rendkívüli intézkedések célja a védekezés eredményessége, alapelvek az óvatosság és a gyorsaság. A katasztrófa következtében lehetséges a termelő, szolgáltató tevékenységek korlátozása, ideiglenes szüneteltetése. Ekkor lép életbe a mentési terv, ami tartalmazza a cselekvési rendet, a tájékoztatási módszereket. Felmerülhetnek szállítási

feladatok a speciális vagyontárgyak és egyebek mentése során. Információs rendszereknél elsődlegesen menteni kell a következőket: adatfeldolgozó rendszer, operációs rendszer, program termékek és a távközlési hálózat. Ezután el kell végezni az úgynevezett funkcionális helyreállítást, azaz az informatikai rendszer alkalmazásainak és adatainak ideiglenes helyreállítását, a közműkiváltás, a telephelyen extra szükséglétesítmények létrehozását. A helyreállítás célja a tartalék telephelyen való legjobb szolgáltatási szint elérése. El kell kezdeni az elvesztett vagy késleltetett tranzakciók ismételt bevitelét. Az üzemeltetők, a rendszeradminisztrátorok, az alkalmazók és a végfelhasználók együtt munkálkodnak azon, hogy helyreállítsák a normál VII. / 43 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila feldolgozási rendet. A biztonsági intézkedések szintje

a végzett munka jellegétől függ. A felelős vezető feladata annak biztosítása, hogy a szükséges szintű biztonságot elérjék. A normál telephelyre történő visszatérés tervezése, a visszatérésig szükséges idő nagyban függ a károk mértékétől, a berendezések, a helyszínek és telekommunikációs vonalaknak az eredeti telephelyen történő helyreállításának időigényétől. A normál állapot elérésének alappillérei: • Hardverrekonstrukció • Szoftverrekonstrukció • Adatrekonstrukció A normál állapothoz történő visszatérést engedélyező döntés része kell, legyen az eredeti gyakorlat felülvizsgálata, hogy az eredeti katasztrófa ismételt bekövetkeztét el lehessen kerülni. Megtörténik a tapasztalatok értékelése, hasonló esetek elkerülésére teendő intézkedések definiálása. IV.3 Esettanulmány Egy magyar–német tulajdonban lévő fiókhálózattal nem rendelkező bank alapvetően szokásos üzletmenetéhez

két szoftvert alkalmaz: egyik a napi tranzakciók rögzítésére szolgál, a másikban aktíváikra (hiteleikre) vonatkozó többletinformációkat tárolnak. Mint például a futamidő, lejárat, törlesztések időpontjai, késedelmek, állami támogatások stb. Az esetleges fizetési késedelmekről az ügyfelet a hitelnyilvántartó rendszer segítségével értesítik, a szerződés szerinti késedelmi kamatot, viszont kézzel írják fel a tranzakciós rendszerben, így visszacsatolás keletkezik köztük. A példában szereplő bank adatfeldolgozásának menetét az 12-es ábra mutatja. VII. / 44 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila A hitelnyilvántartó rendszer a tranzakciós rendszertől kötegelt feldolgozással veszi át az adatokat, minden napzáráskor. A hitelnyilvántartó rendszer viszont már kissé idejétmúlt, nem nagyszámú tétel kezelésére tervezték, funkciói hiányosak. A bank

vezetése kezdetben erre a rendszerre már nem kívánt anyagi ráfordításokat eszközölni, mert felismerték, hogy új integrált rendszerre lenne szükségük, úgy vélték, hogy a folytonos üzletmenet szempontjából a tranzakciós rendszer igen, viszont a hitelnyilvántartó rendszer nem létfontosságú. Így nem foglalkoztak a katasztrófa-menedzsmenttel e rendszerekre vonatkozóan. A tranzakciós rendszerre viszont kidolgoztak egy katasztrófa elhárítási tervet, úgy határoztak, hogy nem alakítanak ki költséges tartalék telephelyet, nem kívántak bevonni külső vállalkozásokat tartalékrendszerek bérlésére. Lefektették viszont a kézi helyettesítő eljárások alkalmazását tervükben. A vállalkozás esetében ez azért volt lehetséges, mert alkalmazottaik nagy részétől megkövetelték a szoftver ismeretét, és többségük ismerte is a folyamatokat, így szükséghelyzetben tudnák alkalmazni ezeket az eljárásokat. A tranzakciós rendszer jól

működött, viszont a hitelnyilvántartó rendszerben gondok adódtak: egyik hétfői napon adatvesztés történt, és aznapi továbbá az egy héttel azelőtti pénteki tranzakciók elvesztek, a hitelnyilvántartó rendszer ideiglenesen használhatatlanná vált. Erre vonatkozó katasztrófa elhárítási tervük nem volt, ezért a tranzakciós rendszerre kidolgozott terveket próbálták alkalmazni. Sikertelenül, mert a hitelnyilvántartó rendszer igen speciális volta miatt a kézi helyettesítő eljárások elvégzésére nem találtak kellő számú, és képzettségű személyzetet. A szükséghelyzet végül három nap elteltével oldódott meg, úgy hogy a rendelkezésre álló képzett személyzet csak a hiba elhárításán, és az elveszett adatok pótlásán dolgozott. A bank azt a következtetést volta le, hogy szükségük VII. / 45 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila van egy új, és összevont

katasztrófa terv kidolgozására, és megkezdték ennek előkészületeit. Megítélésem szerint a bank a költség-haszon szemléletet tartotta szem előtt, mikor először döntött a katasztrófa elhárítási terv mellőzéséről az utóbbi rendszerre vonatkozólag, vagy másképp a „nem teszünk semmit” lehetőséget választotta. Ez a szemlélet helyes volta akár be is igazolódhatott volna, ha sikerül egy új, integrált rendszert üzembe helyezniük még az üzemzavar megtörténte előtt. A vezetés rosszul mérte fel a helyzetet akkor, amikor csak a tranzakciós rendszert minősítette az üzletmenet szempontjából kritikus tényezőnek, ugyanis a hitelnyilvántartó rendszerben bekövetkezett leállás végső soron kihatott a tranzakciós rendszerre is azáltal, hogy az adatok feldolgozásának folyamatossága hiányt szenvedett. Mindazonáltal nagyobb anyagi, és erkölcsi kár nem érte a hitelintézetet. Hibáztak akkor, amikor a „nem

teszünk semmit” szemléletet választották. Ha mondjuk, nem akarták nagyobb költségekbe verni magukat egy tartalék telephely kialakításával, vagy külső cég bevonásával, esetleg félve a bank- és üzleti titkok sérülésétől. Választhatták volna az „erőd megközelítést”. Vagyis jelen esetben például azt, hogy módosítják a rendszert úgy, hogy az kötegelt feldolgozással napjában ne csak egyszer, hanem többször vegye át az adatokat. Vagy megerősíthették volna azáltal a tranzakciós rendszert és a hitelnyilvántartó rendszert is egyúttal, hogy naponta többször végeznek adatmentést. VII. / 46 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila 12. ábra: A banki adatfeldolgozás menete VII. / 47 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila V. Irodalomjegyzék Nyomtatott irodalom: 1. Klimkó Gábor – Szabó Zoltán: IT

infrastruktúra menedzsment (Gábor András: Információmenedzsment) 2. PRINCE: Configuration Management Guide 3. Mehmet Göker – Thomas Roth-Bergehofer: Development and Utilization of a Case-Based Helpdesk Support System in a Corporate Environment 4. Sheila Garfield – Sefan Wermter: Recurrent Neural Learning for Helpdesk Call Routing 5. Karen Schoemehl Investing in the helpdesk 6. Contingency Planning IT Infrastructure Library 7. CCTA Risk Analysis and Management Methodology 8. Bodlaki Ákos, Csernay Andor, Mátyás Péter, Muha Lajos, Papp György Dr., Vadász Dezső: Informatikai rendszerek biztonsági követelményei 9. Ambris József, Herendi Dezső, Obert Ferenc, Orovecz István, Seemann László, dr. Szakál Béla: Polgári védelem, katasztrófa elhárítás, 1995 VII. / 48 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila Online irodalom: 1. Az informatikai Tárcaközi Bizottság honlapja http://www.itbhu 2.

Elektronikus Információs szolgálat (Lecture Notes in Computer Science: Springer 2003) http://www.eiszhu Letöltés ideje: 2003. március VII. / 49 Infrastruktúra menedzsment BKÁE Gazdálkodási Kar Információrendszerek Tanszék Csonka Attila VI. Ábrajegyzék 1. ábra:Az IT infrastruktúra menedzsment területei 5 2. ábra: A hiba útja a Helpdeskig 8 3. ábra: A helpdesk kapcsolatrendszere 10 4. ábra: Egyszerű, központosított helpdesk 11 5. ábra: Többfunkciós, központosított helpdesk 12 6. ábra: Elosztott helpdesk 13 7. ábra: A bank helpdesk rendszere 26 8. ábra: Egyszerű, központosított helpdesk a banknál 27 9. ábra: IT katasztrófák lehetséges következményei 32 10. ábra: Az informatikai katasztrófák okai 34 11. ábra: katasztrófa elhárítási vázlatok 39 12. ábra: A banki adatfeldolgozás menete 47 VII. / 50