Infrastruktúra menedzsment

Átírás

1 Miniszterelnöki Hivatal Informatikai Koordinációs Iroda Informatikai Tárcaközi Bizottság ajánlásai 15 sz. Infrastruktúra menedzsment Budapest, 1998

2 Készült Central Computer and Telecommunication Agency (CCTA, a brit kormány informatikai központja) és a Miniszterelnöki Hivatal Informatikai Koordinációs Iroda (MeH IKI) együttműködése keretében, a MeH IKI megbízásából. Készítette: MTA Információtechnológiai Alapítvány

3 TARTALOMJEGYZÉK 1. ELŐSZÓ Olvasótábor Feltételezett előismeretek Áttekintés Az infrastruktúra menedzsment főbb gondolatainak áttekintése Az infrastruktúra-menedzsment funkciók áttekintése Szolgáltatások megalapozása A szolgáltatások nyújtása (tervezése és menedzsmentje) Az infrastruktúra-menedzsment bevezetéséből eredő hasznok Az infrastruktúra-menedzsment bevezetésének buktatói Lehetséges problémák A szolgáltatási kultúra kialakításának nehézségei Tervezés és bevezetés A funkciók tervezése A bevezetés kérdései Az emberi tényező Képzés Időzítés KONFIGURÁCIÓKEZELÉS A konfigurációkezelés funkció bevezetése A konfigurációkezelés funkció tervezése A megvalósítás Problémák A konfigurációkezeléshez kapcsolódó eljárások A konfigurációkezelés négy alapfunkciója A konfigurációkezelés eljárásai Ajánlott irodalom GYORSSEGÉLY-SZOLGÁLAT A gyorssegély-szolgálat alfunkciói A gyorssegély-szolgálathoz kapcsolódó tevékenységek Esemény-felügyelet Vezetői információk szolgáltatása Szervezeti alaptevékenységre vonatkozó segélykérések Megelőző tevékenységek Audit és szemlézés A gyorssegély-szolgálati funkció bevezetése A funkció megtervezése A gyorssegély-szolgálati rendszer kiépítése és validálása Problémák Ajánlott irodalom PROBLÉMAKEZELÉS A problémakezelés eljárásai Esemény-felügyelet Probléma-felügyelet Hiba-felügyelet Vezetői információ Megelőző problémakezelés Eredményességi és hatékonysági szemlék A jövő tervezése A problémakezelés megvalósítása Tervezés Megvalósítás Problémák Ajánlott irodalom VÁLTOZÁSKEZELÉS A változáskezeléshez kapcsolódó tevékenységek Szerepek és feladatkörök a változáskezelésben A változáskezelés fő tevékenységei i

4 Tartalomjegyzék 5.2 A változáskezelési funkció bevezetése A funkció megtervezése A változáskezelési funkció kiépítése és validálása Problémák Ajánlott irodalom SZOFTVER FELÜGYELET ÉS TERÍTÉS A szoftver felügyelet és terítés eljárásai A szoftver felügyelet és terítés fő folyamatai Sürgős kiadások A Hiteles Szoftver Könyvtárral kapcsolatos eljárások Kiadások összeállítására szolgáló eljárások Kiadás sorszámozás Szoftver terítési és üzembe helyezési eljárások Szoftverek átdolgozása Eljárások vásárolt szoftverek esetére Belső készítésű PC szoftverek Folyamatosan végzendő eljárások, szemlék és audit A SzFT funkció bevezetése A SzFT tervezése Megvalósítás Problémák Ajánlott irodalom RENDELKEZÉSRE-ÁLLÁS MENEDZSMENT A rendelkezésre-állás menedzsment megközelítése A rendelkezésre-állás menedzsment eljárásai Tervezési feladatok Üzemeltetési feladatok A rendelkezésre-állás menedzsment funkció bevezetése A rendelkezésre-állás menedzsment funkció megtervezése Függőségek Az emberi tényező A rendelkezésre-állás menedzsment funkció megvalósítása Problémák Ajánlott irodalom KAPACITÁSMENEDZSMENT A kapacitás menedzsment tevékenységei A kapacitás menedzsment eszközei A Kapacitás Menedzsment Adatbázis Jelentések Szolgáltatási szint megállapodás Költség menedzsment Teljesítmény menedzsment Terhelés menedzsment Alkalmazások méretezése Erőforrás menedzsment Igény menedzsment Modellezés A kapacitás terv elkészítése Szemlézés és audit A kapacitás menedzsment funkció bevezetése A tervezés tervezése A kapacitás menedzsment bevezetésének szakaszai Megvalósítás Megvalósítás utáni szemle és audit Problémák Ajánlott irodalom KÖLTSÉGMENEDZSMENT A költségmenedzsment funkció A költségmenedzsment funkció struktúrája A költségek felosztása A számlázás A költség-elszámolási tervek és jelentések ii

5 Tartalomjegyzék A költségmenedzsment munkáját segítő eszközök A költségmenedzsment haszna A költségmenedzsment funkció bevezetése Tervezés A funkció megvalósítása A megvalósítás utáni szemlézés és auditálás Problémák Ajánlott irodalom KATASZTRÓFA ELHÁRÍTÁS TERVEZÉS A katasztrófa elhárítási terv szükségessége A katasztrófa-elhárítás tervezés megvalósítása A projekt előkészítése Kockázatelemzés és menedzsment A katasztrófa elhárítási terv tartalma A megvalósítás menete Ajánlott irodalom SZOLGÁLTATÁSI SZINT MENEDZSMENT A szolgáltatási szint menedzsment folyamata A szolgáltatási szint menedzsment bevezetése Tervezés Megvalósítás Problémák A szolgáltatási szint menedzsmenthez kapcsolódó tevékenységek Szolgáltatási szint követés A szolgáltatási minőség szemléje Szolgáltatás-fejlesztési programok Szolgáltatási szint megállapodások szemléi A céloknak való megfelelés auditja Ajánlott irodalom SZOFTVER TÁMOGATÓ ESZKÖZÖK Rendszer szintű követelmények Biztonsági követelmények Felhasználói felülettel kapcsolatos követelmények Konfigurációkezelés Gyorssegélyszolgálat Problémakezelés Változáskezelés Szoftver terítési és felügyeleti követelmények Kapacitástervezési követelmények Költségmenedzsment követelmények KIFEJEZÉSSZÓTÁR iii

6 Tartalomjegyzék ÁBRAJEGYZÉK 1. ábra: Probléma és eseménykezelő rendszer ábra: A szolgáltatási menedzsment részei ábra: A konfigurációs elemek lebontása ábra: KE lebontás (példa) ábra: A gyorssegély-szolgálat áttekintése ábra: Esemény életciklus ábra: Egy esemény feldolgozásának folyamata ábra: Egyszerű, központosított gyorssegély-szolgálat ábra: Többfunkciós, központosított gyorssegély-szolgálat ábra: Elosztott gyorssegély-szolgálat ábra: Az eseménykezelési folyamat áttekintése ábra: Esemény vizsgálatok és diagnózis ábra: Az esemény besorolási/összevetési folyamat ábra: A hiba-javítási ciklus az éles és a fejlesztési környezetben ábra: Vezetői információk ábra: Problémakezelés és támogatás ábra: Centralizált problémakezelés ábra: A változtatások kezelése ábra: A halasztást nem tűrő változtatások kezelése ábra: A SzFT funkció folyamatai ábra: A szoftverterítés folyamata ábra: Szoftver lebontás ábra: A nyújtott informatikai szolgáltatások és a megalapozó szerződések ábra: A rendelkezésre-állás menedzsment áttekintése ábra: A rendelkezésre-állás tervezése ábra: Események és mérőszámok ábra: A kapacitás menedzsment eszközkészlete ábra: A kapacitás menedzsment elemei ábra: A teljesítmény menedzsment folyamatai ábra: A terhelés menedzsment folyamatai ábra: Az implementációs szakasz ábra: Az informatikai katasztrófák okainak aránya ábra: Szolgáltatási megállapodások ábra: SzSzM változatok ábra: SzSzM kikötések központi kezelése ábra: A szolgáltatási szint menedzsment részei iv

7 Tartalomjegyzék RÖVIDÍTÉSEK ACU CCTA CRAMM ECU EF HMSO HSzK IBK IHF IT ITB ITIL ITTT JF KE KF KK KKAB KMA KMD MeH IKI MTBF MTBSI MTTR OCU PF PJ PK RMAB SCU SQL SzFT SzSzM TCU VK VKE VTT VTTB VTTDB Accommodation Cost Units, elhelyezéssel kapcsolatos költségek Central Computer and Telecommunication Agency CCTA s Risk Analysis and Management Method Eequipment Cost Unit, (hardver) eszközre terhelt költség Esemény Feljegyzés, Incident Record Her Majesty's Stationery Office Hiteles Szoftver Könyvtár, Definitive Software Library Informatikai Biztonsági Koncepció Ismert Hiba Feljegyzés, Known Error Record Információ Technika Informatikai Tárcaközi Bizottság Information Technology Infrastructure Library Informatikai Tervezési Titkárság Jogosultsági feljegyzés, Authorisation Record Konfigurációs Elem, Configuration Item Kibocsátási feljegyzés, Release Record Konfigurációkezelés Konfigurációkezelési Adatbázisban, Configuration Management Database Kapacitás Menedzsment Adatbázis, Capacity Management Database követelmény-meghatározó dokumentum Miniszterelnöki Hivatal - Informatikai Koordinációs Iroda Mean Time between Fails, Hibák közötti átlagidő Mean Time Between System Incidents, Rendszeresemények közti átlagidő Mean Time to Repair, Javítás átlagos ideje Organisation Cost Unit, szervezetre terhelt költség Probléma Feljegyzés, Problem Record Probléma Jelentés, Problem Report Problémakezelés, Problem Handling Rendelkezésre-állás Menedzsment Adatbázis, Availability Management Database Software Cost Unit, szoftverre terhelt költség Systematic Query Language Szoftver Felügyelet és Terítés, Software Control and Distribution Szolgáltatási Szint Megállapodás, Service Level Agreement (SLA) Transfer Cost Units, átruházandó költségek Változtatási Kérelem, Request for Change Vizuális Kijelző Egység Változásügyi Tanácsadó Testület, Change Advisory Board VTT Döntőbizottság, Change Advisory Board Executive Committee Változtatásügyi Tanácsadó Testülettel / Döntőbizottság v

8 1. Előszó Közhely, hogy manapság a szervezetek számára egyre nélkülözhetetlenebbé válik az informatika. Ez az állítás igaz mind a közszolgálati, mind a profitorientált szervezetek esetében. Így az informatikai infrastruktúra üzemeltetése, az informatikai vagyontárgyakkal való gazdálkodás, az üzemeltető szervezet és a felhasználók közötti jó viszony felépítése egyre nagyobb fontosságot nyer. Az informatikai infrastruktúrába beleértjük a szervezetet, a számítógépeket, a hálózatot, a hardver elemeket, a szoftver elemeket, illetve a szoftverrel kapcsolatos telekommunikációt, melyekre az alkalmazói rendszerek és az egyes IT szolgáltatások ráépülnek és futnak. Az itt tárgyalt témák és megközelítésmódjuk nagy része ismerős lesz azok számára, akik valaha számítóközponti környezetben dolgoztak. A nagyszámítógépekre alapozó világ számára, az eszközök magas értéke miatt a nélkülözhetetlen volt a szervezettség, a kézbentartás lehetősége. A nyolcvanas években kialakult személyi számítástechnika környezete gyakran kevésbé volt ennyire áttekinthető és szervezett. Az informatika és az informatikai vagyontárgyak összessége mára azonban akkora anyagi értéket képvisel, hogy ez az örökzöld téma újra és újra előtérbe kerül. Ez az ajánlás a brit Information Technology Infrastructure Library (ITIL) sorozat első tíz kötetében található témákat tekinti át. Az ITIL, amely maga több mint negyven kötetből áll, többek között az informatikai vagyontárgyaknak, mint infrastruktúrának a főbb üzemeltetési kérdéseit tekinti át, de vannak kifejezetten technikai kérdésekkel foglalkozó kötetei is. Az ITIL sorozat maga közel tíz éves múltra tekinthet vissza, és közben az informatika és alkalmazási köre robbanásszerű változásokon ment át. Az ügyfél-kiszolgáló modell, a hálózatok és a hálózati számítógépek elterjedése, a világháló és az intranet technológia gyökeresen átformálta világunkat. Az ITIL tartalma, szükségessége, és a benne megfogalmazott gondolatok érvényessége e nagyléptékű változások után sem veszített semmit időszerűségéből. Ezen a területen magyar nyelven viszonylag kevés az irodalom. Az Olvasó tehát hiánypótló művet tart a kezében, amelyet reményeink szerint kézzelfogható haszonnal forgathat majd mind maga, mind az őt alkalmazó szervezet számára Olvasótábor Az ajánlás elsődlegesen olyan középvezetők számára íródott, akik informatikai infrastruktúrát üzemeltetnek egy szervezet számára. Haszonnal forgathatják ezen túlmenően mindazok, akik ilyen infrastruktúra működtetésében részt vesznek Feltételezett előismeretek Az ajánlás megértéséhez elvben semmilyen előismeret nem szükséges. Ugyanakkor felhívjuk a figyelmet arra, hogy a tárgyalandó témák egyike-másika száraznak tűnhet a laikus számára. Ezek megértését azonban lényegesen megkönnyítheti, ha az Olvasó már dolgozott üzemeltetésben. Az ismertetett problémák így első kézből, saját tapasztalatokra is építhetők Áttekintés Az ajánlás fejezetekre bomlik. Az első rész a bevezető, ami áttekintést nyújt az ITIL Service Support sorozatbeli modulokról. (Az ITIL a számítógépes szolgáltatások problémáit modulokban tárgyalja. A modulokat sorozatba csoportosították, ahol az egyes sorozatok a számítógépes szolgáltatások egyegy különös részére vonatkoznak. Minden egyes modul külön kerül tárgyalásra.) Minden modul esetében a résztvevők áttekintést kapnak a modul feladatáról, fontosabb folyamatairól és a szervezetbe történő bevezetés kérdéseiről. Az általános áttekintést nyújtó bevezetést követően az egyes infrastruktúra menedzsment funkciók kerülnek részletes bemutatásra. Ezek a következők: konfigurációkezelés gyorssegélyszolgálat problémakezelés változáskezelés szoftver felügyelet és terítés szolgáltatási szint menedzsment katasztrófa elhárítás tervezés kapacitás menedzsment 1

9 Infrastruktúra menedzsment Előszó költségmenedzsment (informatikai szolgáltatások esetében) rendelkezésre-állás menedzsment Külön fejezet foglalkozik a szoftver eszközökkel, a megértést pedig terminológia-szótár segíti. Az ajánlás célja egyrészt, hogy segítse az alapelvek megértését, másrészt hogy felkészítse az Olvasókat a gyakorlatban felmerülő kérdések kezelésére. Azt is szeretné megvilágítani az Olvasó számára, hogy az egyes funkciók bevezetése milyen következményekkel járhat a szervezet egésze számára. 1.2 Az infrastruktúra menedzsment főbb gondolatainak áttekintése Mint már említettük, egyre növekszik azoknak a szervezeteknek a száma, amelyek erős függésbe kerülnek az IT szolgáltatásoktól. Eközben a felhasználók is egyre pontosabban képesek meghatározni IT szolgáltatási követelményeiket és minőségi igényeiket. Ebben a megváltozott kultúrában meghatározó jelentőségű az eredményes menedzsment az informatikai szolgáltatások területén is. Miközben a szervezetek jelentős összegeket fordítottak és fordítanak szoftverfejlesztési eszközökbe és módszertanokba, egészen máig elenyésző volt azoknak a szervezeteknek a száma, amelyek használtak valamilyen módszert a már létrehozott és működő rendszereik menedzselésére, szolgáltatási minőségének ellenőrzésére. Ennek egyik oka az volt, hogy hiányoztak azok az irányelvek és elfogadott szabványok, amelyekkel egy információrendszert karban lehet tartani és kezelni a felhasználói szükségleteknek való folyamatos és hosszú távú megfelelés érdekében. A számítástechnika hőskorában az informatikusok és a felhasználók kapcsolata nagyon szegényes volt, hiszen a számítóközpontok elszigetelten működtek, és a felhasználókkal való kommunikáció meglehetősen korlátozott volt. Ez rossz hatékonyságú megoldásokhoz vezetett az üzemeltetés terén: a segítség nem áll mindig rendelkezésre, és a problémák elhárítását nem felügyelték formálisan, a kommunikáció hiánya az események (szolgáltatási zavarok) és problémák újbóli megjelenését eredményezhette, az IT funkció elszigetelése a felhasználóktól az igények nem megfelelő alkalmazásához vezethetett. Jellemzően nem volt megfelelő szintű (gyakoriságú és mélységű) kommunikáció az informatikai üzemeltető és a felhasználó között, amikor egy alkalmazás éles használatba került. Pedig ez a megfelelő szintű szolgáltatások, a zökkenőmentes és eredményes felhasználás alapfeltétele. Az itt bemutatandó megközelítés ezt a helyzetet igyekszik megoldani. A hangsúly arra kerül, hogy a felhasználót ellássák a megfelelő információkkal és eszközökkel alapfeladata ellátásához. Ehhez egy szolgáltatási jellegű kultúra meghonosításán át vezet az út. Minden, a szolgáltatási kultúrában résztvevő osztálynak, részlegnek és személyzetének fel kell fognia, hogy a legfőbb célja az, hogy létfontosságú szolgáltatásokat nyújtson a szervezet számára. Az informatikai szolgáltatások menedzsmentje az informatikai szolgáltatások kapcsán kialakult hiányosságokat orvosolja. Feladatkörébe tartozik az üzemelő informatikai szolgáltatások és a bázisul szolgáló informatikai infrastruktúra tervezése, üzembe helyezése és folyamatos kontrolja. Az informatikai szolgáltatások menedzsmentje szolgáltató kultúra meghonosítását jelenti a szervezetben, olyan módszertan felhasználásával, amely biztosítja, hogy a szervezet számára nyújtott szolgáltatások megfeleljenek a felhasználói igényeknek és prioritásoknak, miközben költséghatékonyan állíthatók elő. Az informatikai szolgáltatások menedzsmentjének bevezetése lehetővé teszi, hogy az informatikai szolgáltató egység ne csupán mint jelentős költségek forrása jelenjék meg a szervezet számára, hanem mint a szervezeti alaptevékenységet megalapozó, professzionális, költség-hatékony szolgáltatásokat nyújtó egység. Az informatikai szolgáltatások fontossága egyre nyilvánvalóbb a szervezetek többsége számára, ahogy az információtechnológia termelési folyamataik, termékeik és szolgáltatásaik egyre integránsabb részévé válik. Ennek megfelelően egyre nagyobb minőségi és megbízhatósági igényekkel lépnek fel az informatikai szervezettel szemben. Ezt a folyamatot jellemzi, hogy a szervezetek egyre szorosabb kapcsolatot igyekeznek kialakítani informatikai egységükkel ennek 2

10 Infrastruktúra menedzsment Előszó egyik eleme a technológia-orientált üzemelésről a szolgáltatás-orientált működés felé való elmozdulás, ami a minőség előtérbe kerülését jelenti. A szervezetek gazdaságosabban működő és objektíven értékelhető informatikai funkciót igényelnek, amely gyorsan képes reagálni az igényekre, és szolgáltatásai megbízhatóak, jó a rendelkezésre állásuk, biztonságosak és gazdaságosak. A növekvő mértékű technológiai összetettség a technológia gyors fejlődéséből és a szervezeti igények bővüléséből fakad, a szervezet egyre több tevékenységét támogatják egyre bonyolultabb informatikai rendszerek. Az informatikai szolgáltatások infrastruktúrája egyre komplexebb, a kölcsönhatások, összefüggések egyre nehezebben kezelhetők. Ahhoz, hogy ezt az összetettséget kontrollálni tudjuk, sokkal több kell, mint pusztán jó mentési és helyreállítási megoldások. A növekvő komplexitás a szolgáltatási kultúra szükséglete mellett a másik fő ok, amely az informatikai szolgáltatások menedzsmentjének szükségességét indokolja. A mai szervezeti infrastruktúrát csak jól megtervezett, szabályozott, követhető, ellenőrizhető eljárásrendekkel és kiterjedt információgyűjtéssel lehet kezelni és minőségileg menedzselni. Hiszen még a legfejlettebb technológián alapuló alkalmazások sem igazán hasznosak, ha: Nem világos, milyen folyamatot kell elvégezni ami az erőfeszítések többszörözését, rossz megoldásokat, sorozatos megtorpanásokat okoz, emiatt túl hosszúak lesznek a reagálási, javítási idők, növekszik az ideges és frusztrált felhasználók száma. Az egyes folyamatokat nem lehet nyomon követni és bizonytalan lefolyásúak, mivel a tevékenységekből hiányzik a konzisztencia és ez károsan befolyásolja a felhasználók elégedettségét és megakadályozza a szolgáltatási szintek betartását. A tevékenységeket ellátó személyzetnek nincsenek egyértelmű felelősségi körei, feladatai, mivel elszámoltathatatlanok, ha a folyamat elakad, nincs felelőse, az informatikai személyzet tagjai feladatkörükön kívüli problémákba bonyolódnak, a felhasználó pedig tanácstalan, nem tudja, kihez forduljon. Ha a folyamatot nem mérik, akkor az nem értékelhető, változtatható vagy fejleszthető igazán. Ha jól definiált folyamatokkal rendelkezünk és mérni tudjuk ezeket, akkor képessé válunk a teljesítményünk értékelésére, ami a folyamatos fejlődés alapfeltétele. Ez a javulási képesség, a változó szervezeti igényekkel szembeni reagáló képesség és rugalmasság alapfeltétele, és megelőzést tesz lehetővé ahelyett, hogy az események után kullognánk. Az informatikai szolgáltatások menedzsmentje olyan eljárások összessége, amelyek együttesen minőségi informatikai szolgáltatásokat képesek biztosítani. Átfogó modell nyújt, amelyen keresztül a szolgáltatásokat kezelő egyes tevékenységek a szervezet igényeinek megfelelően megvalósíthatók és üzemeltethetők. Az informatikai szolgáltatások menedzsmentjének fő céljai: Felhasználói igényekre koncentráló informatikai szolgáltatásokat nyújtson. Az informatikai szolgáltatásokat a szervezeti céloknak rendelje alá. Költség-hatékonyan legyen képes az informatikai szolgáltatások megvalósítására és menedzsmentjére. Az informatikai szolgáltatások menedzsment elvei az IT Infrastructure Library által dokumentált legjobb gyakorlaton (best practice) alapulnak, azaz nem az elmélet, hanem a tapasztalat gyümölcsei. Az informatikai szolgáltatások menedzsmentje lehetővé teszi, hogy: a technológia-orientált informatikai egységet szolgáltatás-orientálttá tegyük, minőségi IT szolgáltatásokat nyújthassunk és ezáltal elérhessük, hogy a szervezeti célok és követelmények teljesüljenek, javítsuk a rendszerek megbízhatóságát és rendelkezésre állását, megalapozott szolgáltatási minőségi szinteket határozhassunk meg, és mérhessük a szolgáltatások minőségét, növeljük a hatékonyságot, javítsuk az eredményességet, és csökkentsük a kockázatot, javítsuk a munka-gyakorlatot a kiváló minőség érdekében. 3

11 Infrastruktúra menedzsment Előszó A tíz funkcióból álló informatikai szolgáltatások menedzsment megközelítés első öt eleme a szolgáltatások megalapozását szolgálja. Ez az öt funkció a megbízható és ellenőrizhető informatikai szolgáltatásoknak az alapja. A második öt funkció a szolgáltatások nyújtására, biztonságosságára és hatékonyságára, egyszóval a minőségének kezelésére szolgál. 1.3 Az infrastruktúra-menedzsment funkciók áttekintése Szolgáltatások megalapozása A szolgáltatások megalapozása (Service Support) sorozat öt részből áll: konfigurációkezelés gyorssegélyszolgálat problémakezelés változáskezelés szoftver felügyelet és terítés Ezeknek a szorosan összefonódó témáknak az integrálása vezet el a szolgáltatások megalapozásának a legfontosabb eleméhez: egy teljes körű változtatás-, probléma- és eseménykezelő rendszerhez. Felhasználó Segélykérések Hálózat felügyelet Gyorssegélyszolgálat Számítógép üzemeltetés Változtatási kérelmek Esemény adatok Probléma és hiba felügyeleti rendszer új problémák probléma / hiba adatok Esemény felügyeleti rendszer Esemény adatok Konfigurációs nyilvántartás adatai Esemény adatok Konfigurációkezelési rendszer Változáskezelési rendszer Információk a változtatásokról 1. ábra: Probléma és eseménykezelő rendszer A cél az, hogy gyakorlati útmutatást adjon egy ilyen rendszer felépítéséhez az ötlet fogantatásától a rendszer üzemeltetéséig és karbantartásáig, aminek során az ITIL egyes moduljait használjuk fel. A konfigurációkezelés abban segítheti az IT vezetést, hogy eredményesebben felügyelje hardver és szoftver vagyontárgyait, kezelje a változtatásokat, az eseményeket és a problémákat. A gyorssegélyszolgálat a technikai zavarok (események) kezelését, a felhasználói tevékenységek támogatását, az eseményekkel kapcsolatos információk összegyűjtését szolgálja. A problémakezelés segít a hibák következményeinek a minimalizálásában, a hibák mögöttes okainak feltárásában és ennélfogva csökkenti a hibák számát. A változáskezelés az a funkció, ami változások hatékony és megbízható kezelését biztosítja, jobb erőforrás elosztás és kevesebb negatív következmény mellett. A szoftver felügyelet és terítés segíthet a szoftverek és a kapcsolódó dokumentációk használatának, változtatásának és terítésének a felügyeletében. Minden egyes fenti funkció esetében szükséges a felelősségek, tevékenységi körök világos kijelölése. 4

12 Infrastruktúra menedzsment Előszó A szolgáltatások nyújtása (tervezése és menedzsmentje) A szolgáltatások nyújtása (Service Delivery) sorozat öt részből áll: Szolgáltatási szint menedzsment Katasztrófa elhárítás tervezés Kapacitás menedzsment Költségmenedzsment IT szolgáltatások esetében Rendelkezésre-állás menedzsment Ezek témák adják az információtechnológiai szolgáltatások menedzseléséhez szükséges pénzügyi, minőségi és mennységi folyamatok leírását. E funkciók nem nélkülözhetik az előzőekben bemutatott, a szolgáltatások megalapozását szolgáló infrastruktúra menedzsment funkciókat. A szolgáltatási szint menedzsment révén lehet informatikai szolgáltatások terén minőségi szinteket számszerűsíteni, és a felhasználók igényeit az erőforrás-korlátokkal összeegyeztetni. A katasztrófa elhárítás tervezés hangsúlyozza, felméri az informatikai infrastruktúra sebezhető pontjait és a lehetséges fenyegetéseket, és ezekkel szemben ellenintézkedéseket javasol, illetve katasztrófa elhárítási tervet készít a szervezeti tevékenységek folyamatosságának biztosítása érdekében. A kapacitás menedzsment lehetővé teszi a szolgáltatási szintek és a költségek közötti egyensúly fenntartását, a kapacitások hosszú távú tervezethetőségét és optimális szintjét. A költségmenedzsment segít abban, hogy a költségeket minimális szinten tarthassuk a lehető legmagasabb szolgáltatási szinteket elérése mellett. Bemutatja az informatikai szolgáltatások járulékos költségeinek leírását, követését és felügyeletét. A rendelkezésre-állás menedzsment szisztematikus megközelítést javasol arra, hogy hogyan állapítsuk meg a rendelkezésre-állás mértékét, úgy, hogy az összhangban legyen a felhasználói elvárásokkal, a tényleges igényekkel és a pénzügyi erőforrásokkal. 1.4 Az infrastruktúra-menedzsment bevezetéséből eredő hasznok Az IT infrastruktúra menedzsment bevezetése az alábbi hatásokat válthatja ki: Lehetővé teszi a múlt tapasztalataiból való okulást azáltal, hogy történeti adatokkal szolgál a szolgáltatásra gyakorolt hatásokról. Fenntartja a IT részleg szavahihetőségét a felhasználók szemében. Ezt a minőségi szolgáltatások megbízható nyújtásával éri el. Kézben tarthatóvá teszi az IT szolgáltatásokat, a jobb vezetői információk lehetővé teszik a szolgáltatási menedzsment és rendelkezésre állási menedzsment funkció részére a szolgáltatási szint megállapodások nyomon követését, illetve a követelmények pontosabb meghatározását tartalmazó szerződéskötéseket. Lehetővé teszi a szervezeti alaptevékenységek megalapozását, elébe megy a rendszerfejlesztéseknek és változtatásoknak. A szervezet gyorsabban tudja a változtatásokat feldolgozni, alkalmazkodni hozzájuk és változtatásokra reagálni. Lehetséges lesz az értékes IT vagyontárgyak felügyelete. Javulás érhető el a következő területeken: A felhasználók termelékenysége: hiba esetén gyorsabban lehet a felhasználók eredeti munkakörülményeit helyreállítani, mert rendelkezésre áll a kellően kiképzett személyzet és a megfelelő eljárások, ami végső soron a felhasználók termelékenységének növekedéséhez vezet. Támogató személyzet termelékenysége: sok esetben eredményesebben lehet felhasználni a képzett és gyakorlott személyzetet. 5

13 Infrastruktúra menedzsment Előszó Az IT részleg és a felhasználók közötti kapcsolat: a megjavult kommunikáció eredményeképpen javulni fog a kapcsolat az IT részleg és felhasználók között. 1.5 Az infrastruktúra-menedzsment bevezetésének buktatói Lehetséges problémák Az IT infrastruktúra menedzsment bevezetése és üzemeltetése során számos probléma léphet fel. Ezekre az egyes modulok tárgyalásánál kitérünk, azonban előrebocsátunk közülük néhány visszatérő gondolatot: Nem reális, eltúlzott szolgáltatási szinteket ígérnek be. Túlságosan ambiciózus az időzítés és betarthatatlan határidőket tűznek ki. A változások ütköznek a szervezet kultúrájával. Nem áll rendelkezésre alkalmas számítógépes eszköz és a kézi rendszerek szűk keresztmetszetnek bizonyulnak. Adminisztrációs gondok lépnek fel. A szabályok és eljárások megkerülése előfordulhat sürgős, halasztást nem tűrő változtatások esetén. A szükséges emberi, fizikai és pénzügyi erőforrás-igényeket helytelenül mérik fel A szolgáltatási kultúra kialakításának nehézségei Az alább gondok igen gyakran felmerülnek a szolgáltatási kultúra bevezetése és megvalósítása során. A változással szembeni viselkedésmód: A szolgáltatás menedzsment túl korai bevezetése ellenállást szülhet. A jelenlegi eljárásokhoz való ragaszkodást csak megerősítheti a strukturáltabb és fegyelmezettebb megközelítésmód igénye a szolgáltatási menedzsment személyzetével szemben. Mindenkinek, aki a változással szembetalálja magát, tisztában kell lennie a változtatás indokaival, annak érdekében, hogy a bevezető projekt sikeres lehessen. Egy ilyen változás egyesek számára a jelenlegi teljes környezetük felülvizsgálatát jelentheti. Erőforrások, kinevezések: Gyakori gond az, hogy az ilyen változtatás minden terhe olyan emberek vállára nehezedik, akik amúgy is túlterheltek, és kevés erőforrással rendelkeznek. Éppen ezért szükséges a felsővezetői elkötelezettség és elismertség a szolgáltatási menedzsment bevezetéséhez. Nem csak a fizikai és pénzügyi költségek fognak nőni, hanem a személyzetiek is! A szervezet elismerése: Az informatika és a felhasználók közötti kapcsolat múltja gyakran rossz emlékekkel terhelt, hiszen a felhasználókat esetleg arra kényszerítették, hogy olyan rendszereket használjanak, melyeknek a tervezésébe vajmi kevés beleszólásuk volt. A szolgáltatási menedzsmentnek kell létrehoznia, irányítania és segítenie a két fél közötti megértést, megfelelő kapcsolatot. Semmiképpen sem szabad úgy tekinteni, mint egy újabb informatikai funkció erőltette ötletet, aminek semmi köze sincs a felhasználók tényleges igényeihez. Túlzott elvárások: Előfordulhat, hogy a jelenlegi szolgáltatások nem segítik a felhasználók munkáját. Ugyanakkor, az eltúlzott célkitűzések és elvárások még rosszabb helyzethez vezethetnek, ami által a szolgáltatási menedzsment hitelességét részlegesen vagy teljesen elveszítheti. Korlátos tudatosság: Számos felhasználó úgy véli, hogy ha az általa használt szolgáltatás nem elérhető, akkor az közvetlen negatív hatást gyakorol a szervezetre. Ez igaz lehet, a felhasználó azonban rendszerint csak korlátozottan képesek felmérni az informatikai szolgáltatások tényleges súlyát, szervezeti jelentőségét. A szolgáltatási menedzsmenthez kapcsolódó oktatás legalább olyan fontos, mint a szolgáltatás rendelkezésre állására, a válaszidőkre és az outputra vonatkozó igények. A személyzet tudatosságának javítására a szolgáltatási menedzsment funkció bevezetése során feltétlenül figyelmet kell fordítani. Kritikus szolgáltatások: Ha katasztrófa következne be, vajon melyik a legkritikusabb szolgáltatás? Sok eset volt már, ahol a helyreállítási tevékenység a katasztrófa elhárítására irányult, pedig a lehetséges kimenetel az, hogy az alaptevékenység leáll! 6

14 Infrastruktúra menedzsment Előszó Eszközök: Minél jobb minőségű a kapott információ, annál több esélye van a vezetésnek és a személyzetnek arra, hogy a szervezetet irányítsa és felügyelje. A rendelkezésre álló eszközök száma nő, és ezek fontos szerepet játszanak a szolgáltatás menedzsment működtetése során. Költségek és minőség: A szolgáltatásokat a jelenlegi módnál pontosabban kell mérni, azért hogy értékarányos szolgáltatásokat tudjunk nyújtani, hogy a szolgáltatásokat értékelni tudjuk. Ma a világban már sok informatikai részleg közvetlenül számláz a felhasználóknak a szolgáltatásaikért, azzal a végső céllal, hogy a megfelelő rendszereket jutányos áron bocsássa rendelkezésre (habár a közszolgálati szférában ez talán nem tipikus). Nincs javulás: A javulás hiánya lehet a legfontosabb indoka egy szervezet számára, hogy bevezesse a szolgáltatás menedzsment funkciót. 1.6 Tervezés és bevezetés A funkciók tervezése Első lépésként a kezdeti tervezés keretében meg kell határozni a bevezetendő funkció szerepét. Már ebben a kezdeti szakaszban meg kell kezdeni a figyelem-felkeltési kampányt, hogy a vezetés támogatását már ilyenkor biztosítsuk. Meg kell határozni a funkció szervezeti felépítését. Vázlatos tervet kell készíteni a funkció kifejlesztéséről. Ezt követően kezdeményezni lehet a funkció bevezetésének projektjét. Formális projektmenedzsment megközelítést kell alkalmazni a tervezés és bevezetés során. Projekttervet kell készíteni: valamennyi funkció megvalósítása projektként kezelendő, így a tervezést az Informatikai Tárcaközi Bizottság által ajánlott projektirányítási módszertan (PRINCE) alkalmazásával javasolt elvégezni (lásd ITB 5. számú ajánlása). A projekt fő lépései a következők: 1. Megvalósíthatósági tanulmány 2. Kezdeményezés 3. Specifikációs szakasz 4. Termékkiválasztás és átfogó tervezés 5. Fejlesztés és egyezőség ellenőrzése (validálás) 6. Implementáció 7. Megvalósítás utáni szemle 8. Éles üzemelés Megvalósíthatósági tanulmányt kell készíteni, amelynek ki kell terjednie a funkció iránti követelményekre, az ellátandó feladatokból fakadó igényekre a támogatandó eszközök kapcsán, át kell tekintenie a rendelkezésre álló ill. elérhető eszközöket, meg kell határoznia a dokumentációs követelményeket és meg kell terveznie az egyéb eszközökkel való integráció módját, majd az üzembe-helyezés tevét is vázolnia kell. Ezt követheti (formális előterjesztés után) a menedzsment jóváhagyásának megszerzése. Ezután a kezdeményezés lépéseként a projekthez szükséges erőforrások hozzárendelését kell elvégezni. A követelményjegyzéket a funkció küldetésének meghatározásából kiindulva kell elkészíteni, formálisan definiálva a funkció feladatát. Ez a későbbi specifikációs szakaszban felhasználható. A specifikáció keretében a funkció ellátásának szükségleteit és lehetséges megoldásait kell részletesen elemezni, elfogadási kritériumokat kell meghatározni, és mérőszámokat kell definiálni. A termék-értékelés és rendszer tervezés során részletesen értékelni kell a funkciót (funkciókat) támogató lehetséges eszközöket, el kell készíteni a dokumentációk vázlatát, elfogadási tesztet kell tervezni, át kell tekinteni a függőségeket és kezelésük módjait, majd a személyzeti kérdések megoldását kell elvégezni. Kritikus fontosságú feladat a személyzet kiválasztása: valamennyi funkció kifejlesztése speciális team létrehozását igényli, amelyben a szervezet érintett funkcióinak, szakterületeinek legjobb szakembereinek kell együttműködni. A fejlesztő csapat kulcsembere, jellemzően a vezetője a kialakítandó funkció menedzsere, aki a sikeres bevezetést követően a funkció specifikus feladatköréért lesz felelős. A funkciók üzemeltetéséhez szükséges létszám több tényező függvénye, így a szervezet (egység) mérete, struktúrája, az infrastruktúra jellege, bonyolultsága, illetve az 7

15 Infrastruktúra menedzsment Előszó ellátandó feladat összetettsége, stb. A szervezet és a feladat sajátosságaitól függően egyes funkciók és szerepkörök kombinálhatók, ami szintén kihatással van a funkciónkénti létszámra. Megoldás lehet bizonyos feladatok részmunkaidőben való ellátása is. Szoftver eszközök iránti igények felmérése és a szoftver beszerzése meghatározó jelentőségű a funkciók szempontjából. Az egyes funkciókhoz kapcsolódó szoftver eszközökkel külön fejezet foglalkozik, és valamennyi funkció részletes leírása megfogalmaz útmutatásokat a kiválasztáshoz. Hangsúlyozni kell az egyes funkciók eszközeinek együttműködési képességét, az ideális több funkciót integráló rendszerek alkalmazása. Az eljárások tervezése komplex feladat, valamennyi funkció specifikus eljárások rendszere, amelyek kapcsolódnak a többi funkcióhoz is, adatokat, információkat vagy direkt bemeneteket szolgáltatva. Az egyes funkciók tervezésének kritikus eleme a megfelelő, a szervezet igényeihez és az alkalmazandó rendszer lehetőségeihez illeszkedő eljárásrendek tervezése. Az auditok és szemlék tervezése is a tervezés része kell legyen, hogy mind a megvalósítás, mind a tényleges üzemelés ellenőrizhető és értékelhető legyen. Tervet kell készíteni mind a projekt megvalósításának ellenőrzésére (megvalósítás utáni szemle), mind a későbbiekben üzembe állított funkció különféle szempontok szerinti auditálásának módjára, szemlézési eljárásaira. A bevezetés tervezése: részletes tervet kell készíteni, fázisokra és kisebb megvalósítási lépésekre bontva a bevezetést. A tervnek tekintettel kell lenni a szervezeti sajátosságokra és az informatikai szolgáltató egység jellemzőire is, hiszen teljesen más megoldásokat kíván valamely funkció bevezetése egy teljesen új szolgáltató egységnél, mint egy már működő egység esetében A bevezetés kérdései 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 testre szabá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, majd ellenőrizni kell, hogy valamennyi függőség kezelése megoldott-e. Végül az éles üzemelés következhet. Valamennyi funkció esetében specifikus jellemzői vannak a bevezetésnek, amelyekre az egyes fejezetek részletesen kitérnek. Figyelemfelkeltő kampány kezdeményezése Annak érdekében, hogy az IT infrastruktúra menedzsment koncepciója elfogadásra kerüljön, illetve a személyzetet mind az IT, mind a felhasználói oldalon informálni lehessen arról, hogy hogyan és miként érintik őt majd a változások, figyelemfelkeltő kampányt kell kezdeményezni. A kampány során világossá kell tenni az IT infrastruktúra menedzsmentből származó hasznokat. A felső vezetésnek támogatnia kell a folyamatot, illetve részt kell vennie az eseményekben. Kezdetben csak ajánlásokat lehet a személyzet számára megjelölni. Később majd a felelősségi köröket és szerepeket is pontosan ki kell jelölni. A kampány során használhatunk hírleveleket, munkaértekezleteket, hirdetőtáblákat, szemináriumokat, előadásokat, külső oktatást. A kapcsolatok tudatos felépítésének gondolatának "eladását" gondosan kell csomagolni és az ügyfeleknek (személyzet, felhasználók, informatika) bemutatni. A képzés a kampány későbbi részében lesz fontos. A kormányzati szektor szervezetei hasonló kezdeményezéseket indítottak a fejlett országokban. Az új kultúra iránti elkötelezettséget már korán ki kell alakítani, ami az alapját képezi a helyes hozzáállásmód kialakításának. A felhasználók aktív bevonása minden egyes szakaszban lehetőséget ad a közös építkezésre, amivel elkerülhető a kényszerítés, erőltetetés érzése. 8

16 Infrastruktúra menedzsment Előszó Függőségek Megalapozó folyamatok Sok elem szükséges az IT infrastruktúra menedzsment sikerese tervezéséhez. Az egyes infrastruktúramenedzsment részek egyenkénti gondos megtervezése elengedhetetlenül fontos a teljes rendszer megtervezéséhez. A teljes infrastruktúra-menedzsment megvalósítása során figyelembe veendők azok a függőségek, amelyek az egyes funkciók egymásra épüléséből illetve együttműködéséből erednek. A szolgáltatások menedzseléséhez az első lépés a megalapozó funkciók (az első öt funkció) sikeres üzembe helyezése. A szolgáltatás minőségét végső soron garantáló szolgáltatási szint menedzsment pedig valamennyi tárgyalt funkció sikeres megvalósítását feltételezi. Rendelkezésreállás menedzsment Üzemeltetés menedzsment Kapacitás menedzsment Hálózat felügyelet Katasztrófa - elhárítás tervezés Szolgáltatási szint menedzsment Gyorssegély szolgálat Probléma kezelés *Biztonsági menedzsment Változtatás menedzsment Konfigurációkezelés 2. ábra: A szolgáltatási menedzsment részei Támogató eszközök A támogató (szoftver) eszközök nélkülözhetetlenek a legtöbb informatikai infrastruktúra komponens számára, illetve a közöttük fennálló kapcsolatok fenntartásában. A megfelelő szoftver eszközök növelik annak esélyét, hogy az elvárt teljesítménymutatókat elérjék. Az IT infrastruktúra menedzsment végső célja a szolgáltatás minőségének a javítása. A támogató eszközök költségeit figyelembe kell venni. Az olyan eszközök, melyek egyidejűleg támogatják a változáskezelés, a problémakezelés és a konfigurációkezelés munkáját, várhatólag drágábbak lesznek, mint az egyes funkciókat önállóan támogató eszközök. További szempontok Komolyan figyelembe kell venni az informatikai infrastruktúra menedzsment tervezése, megvalósítása és megvalósítás utáni szakaszai során az alábbi szempontokat is Képzés, pénzügyis és adminisztrációs kérdések, beszállítók, elhelyezés és felszerelések Az emberi tényező Igaz ugyan, hogy mind a rendszerek, a szolgáltatások és a tervezés nagyban hozzájárul az informatikai infrastruktúra menedzsment sikeres bevezetéséhez, de a siker kulcsa mégis az alkalmazottak (köztisztviselők és közalkalmazottak) hozzáállása. Az emberek félelmeivel ugyanúgy foglalkozni kell, mint azzal a kérdéssel, hogy a szükséges fegyelmezett hozzáállás kialakuljon a teljes informatikai személyzetben. Az oktatás és a képzés alapfeltétele annak, hogy az elkötelezettséget el lehessen érni, illetve el lehessen fogadtatni a 9

17 Infrastruktúra menedzsment Előszó személyzettel az új felelősségeket. A múltban nehéznek bizonyult az informatikai személyzet motiválása, mert munkájuk eredményeként nem jött létre semmilyen késztermék. A strukturális változások, a megnövekedett felelősségek és változások a gyakorlatban mind-mind hozzájárulnak a végcél eléréséhez. Kifinomult felvételi eljárások, különösen a gyorssegélyszolgálat személyzete esetében, a személyes igények, készségek meghatározása és továbbfejlesztésének lehetővé tétele, a továbbképzés egyaránt fontos lesz. Az alábbi listában felsoroljuk azokat, akik érintettek az új kultúra bevezetésében a szervezetbe: a felhasználók és az informatikai személyzet, a funkciók vezetői, a változásügyi tanácsadó testület, a segítő személyzet, a beszállítók és a szerződéses partnerek, a konzultánsok, a projekt csapatok, az auditorok. A felhasználók és az informatikai személyzet Az a feladat, hogy meggyőzzük őket a felhasználói részleg és az informatikai szervezeti egység kölcsönös előnyeiről. Például, ha nem sikerül megvalósítani egy gyorssegélyszolgálatot (vagy ha éppen egy sikertelen szolgálatot valósítanánk meg), az a felhasználók körében az informatikai szolgáltatások leértékelődéséhez vezethet. Általában többe kerül egy már elrontott dolgot helyrehozni, mint azt rögtön az első alkalommal helyesen megvalósítani! A funkció vezetői Az informatikai infrastruktúra menedzsment beindítása előtt kell őket kinevezni, hogy már a kezdeményezési fázisban elkezdhessék munkájukat. A szükséges képességeket, készségeket és felelősségeket az érintett moduloknál fogjuk tárgyalni. A változásügyi tanácsadó testület A változásügyi tanácsadó testület (VTT) képes kell legyen arra, hogy mind a szervezeti szemszögéből nézve, mind műszaki szempontból a változásokat, azok hatásait helyesen értékelje. A VTT üléseinek gyakorisága attól függ, hogy az adott IT részleg mekkora és hogy az infrastruktúra mennyire érzékeny. Rövid, de gyakori ülések tartása kevesebb lehetőséget ad arra, hogy a VTT legyen a szűk keresztmetszet, mint a ritkábban megtartott, de hosszabb ülések. A segítő személyzet Tartsunk szoros kapcsolatot a teljes informatikai személyzettel, folyamatosan értesítsük őket a tervekről, a célkitűzésekről és a teljes folyamat előrehaladásáról. Természetesen ennek lesznek bizonyos költségei. A beszállítók és a szerződéses partnerek A jelenlegi hardver, szoftver, hálózat, létesítmény és környezeti felügyeletéről formális szerződések intézkedhetnek. Amennyiben a jelenlegi informatikai szolgáltatások nem megfelelőek, akkor jövőbeli szolgáltatási igények kielégítése érdekében további ráfordításokat kell fontolóra venni, a kapcsolatos szerződéseket, megállapodásokat pedig ajánlatos szemlézni és esetlegesen újratárgyalni. Nem szabad elfeledkezni az informatikai szolgáltatások külső függőségeiről. Ha a felhasználó három másodperces válaszidőt kér, de a hálózati szolgáltató csak négy másodpercet tud garantálni, akkor hálózati szolgáltatás erősítésének többletköltsége vajon indokolható-e? Előfordulhat az is, hogy a szerződések újratárgyalásánál felmerülő költségeket nem tervezték bele a költségvetésbe. A szakértők Előfordulhat, hogy az informatikai infrastruktúra menedzsment bevezetésének határideje miatt, vagy ha nem áll rendelkezésre a szükséges tudás házon belül, szakértők (konzultánsok) segítségét kell igénybe venni. A projekt csapatok A funkciók bevezetése érdekében projekt csapatokat kell összeállítani, amelyek felügyelik és menedzselik a bevezetés folyamatát. 10

18 Infrastruktúra menedzsment Előszó Az auditorok Meg kell valósítani a rendszeres (éves) belső vagy külső auditálás gyakorlatát az IT szolgáltatások megalapozó folyamatainak bevezetése után Képzés A tervezési folyamat részeként, mind helyszíni (munkák közbeni) és formális képzéseket kell tartani a fontosabb témakörökben. A kezdeti figyelem felkeltésétől a készség szintű elsajátításáig a képzésnek átfogó jellegűnek és részletesnek kell lennie a teljes személyzet részére. Ebbe beleértendők a külső partnerek, mint például a beszállítók is, ha ez indokolt Időzítés A szervezeteknek minél hamarabb hozzá kell kezdeniük az informatikai infrastruktúra menedzsment funkcióik tervezéséhez. Az alábbiak irányadó számok arról, hogy mennyi ideig tarthat az egyes funkciók bevezetése a tervezéstől a megvalósításukig: Gyorssegélyszolgálat Változáskezelés Konfigurációkezelés Problémakezelés Szoftverfelügyelet és terítés 3 és 6 hónap között (kifinomult, alapos szolgáltatás) 1 és 3 hónap között, beleértve a támogató eszközök beszerzését 4 és 12 hónap között, az ötlettől a megvalósításig 2 és 4 hónap között Hetek, feltéve hogy a konfigurációkezelés funkció már működik Az időtartamok függnek az egyes helyszínek nagyságától, bonyolultságától, a testre szabási igények nagyságától. A funkciók párhuzamosan, egyidejűleg is megvalósíthatók, az alábbiak függőségek és tényezők figyelembevételével mekkora a teljes IT üzemeltetés mérete, mekkora az egyes funkciók terjedelme, milyen a más IT rendszerekkel való integráltság foka, az értékelendő szoftvercsomagok száma, milyen a rendelkezésre álló személyzet száma és minősége, milyen a vezetői döntéshozatal gyorsasága. 11

19 2. Konfigurációkezelés Ahogy az informatikai rendszerek egyre nagyobbak és összetettebbek lesznek, és az infrastruktúra változásai egyre gyakoribbak és egyre nehezebben kezelhetők, úgy növekszik az igény egy funkcióra, amely az infrastruktúra felügyeletét, kontrollját teszi lehetővé: ez a konfigurációkezelés. Számos szervezet már működteti konfigurációkezelés valamilyen formáját. Ez rendszerint papír alapú nyilvántartás. Ahogy azonban az alkalmazott gyakran kritikus jelentőségű informatikai rendszerek összetettsége nő, ahogy egyre több komponens alkotja a szolgáltatások hátterét, ahogy egyre több és kiterjedtebb hatása lehet egy cserének vagy valamely hibának, úgy válik egyre fontosabbá az eredményes működéshez egy hatékony eljárásokra épülő és rugalmas információszolgáltatást lehetővé tévő adatbázist felhasználó funkció. Egyetlen szervezet sem lehet igazán hatékony eszközeinek menedzselése nélkül, különösen, ha azok az eszközök létfontosságúak a szervezet tevékenységének folytatásában és sikerességében, amint az sok esetben igaz az információ technológia alapú rendszerekre. A konfigurációkezelés (röviden: KK) ad közvetlen kontrollt az informatikai menedzsment számára a szervezeti informatikai eszközök fölött. Minél nagyobb a függés az informatikai (információtechnológiai) eszközöktől, annál nagyobb szükség van e vagyontárgyak felügyeletére és menedzselésére. Összességében azért van szükségünk a konfigurációkezelésre: hogy tudjuk: milyen informatikai vagyon van a szervezet birtokában, o az eszközök hol találhatóak, o az eszközöknek mekkora az értéke, o az eszközöket mire használják, o milyen kapcsolatban van más eszközökkel hogy kezelhetőek legyenek a változások és csökkenthetőek a költségek, hogy szervezetnek lehetősége legyen az eszközök eredményes használatára. A konfigurációkezelés a következőkkel járul hozzá a gazdaságos és minőségi informatikai szolgáltatásokhoz: Az informatikai infrastruktúra változásainak és fejlesztéseinek menedzsmentjét olcsóbbá és hibákra kevésbé hajlamossá teszi. Lehetővé teszi nagyszámú változtatás gyors, hatékony és biztonságos megvalósítását az infrastruktúrában. A problémák hatékony és eredményes kezelését is segíti, hiszen azonosíthatja az érintett konfigurációs elemeket (röviden: KE-eket) és segít a problémák és események megoldásában is, információszolgáltatása révén pedig trendek meghatározását, és így a megelőzést is segíti. A szoftverek jobb felügyeletét teszi lehetővé, a változások ellenőrzése révén. Nagyobb biztonságot eredményez, mivel a KE-k felügyelete révén nehezebb ezek rossz szándékú megváltoztatása. A jogszabályi kötelezettségeknek való megfelelésben is segít, mert azonosítja a nem jogtiszta másolatokat. Megkönnyíti a kiadások tervezését: a karbantartási költségek, a licencdíjak meghatározását. Az informatikai szolgáltatások menedzsmentjén belül a konfigurációkezelés közvetlen ellenőrzést biztosít az informatikai vezetés számára a szervezet informatikai eszközei felett. Ahogy a szervezetek egyre jobban függenek számítógépes rendszereiktől, úgy lesz egyre fontosabb ezek ellenőrzése és kezelése a szervezet hatékonysága és eredményessége érdekében. A konfigurációkezelés az informatikai infrastruktúra menedzsmentben való alkalmazása esetén négy alapvető funkcióból áll: Azonosítás specifikálni és azonosítani kell az informatikai infrastruktúra minden összetevőjét. 12

20 Infrastruktúra menedzsment Konfigurációkezelés Ellenőrzés képesség arra, hogy elfogadják és "befagyasszák" a konfigurációs elemeket, és változtatásokat csak a megfelelő hatóságok jóváhagyásával valósíthassák meg. Státusz követés valamennyi KE-mel kapcsolatos történeti és jelenlegi adatokat fel kell jegyezni és jelentést kell készíteni róluk. Verifikáció szemlék és auditok biztosítják az egyezést a KE-ek és a konfigurációkezelési adatbázisban (KKAB) feljegyzett hivatalosan elfogadott állapot között. 2.1 A konfigurációkezelés funkció bevezetése Miután eldöntésre került, hogy a konfigurációkezelés alkalmazásra kerül a szervezetnél, annak tervezési és megvalósítási folyamatát projektszerűen kell kezelni, olyan elfogadott projektmenedzsment módszert alkalmazva, mint a PRINCE (lásd az ITB 5. számú ajánlását) A konfigurációkezelés funkció tervezése Konfigurációmenedzser kinevezése Az Informatikai Szolgáltatási Menedzsernek ki kell neveznie a konfigurációmenedzsert, aki felelős a konfigurációkezelési funkció működéséért, és aki valószínűleg projektmenedzsere a funkció tervezésének és megvalósításának. A személyzet A szükséges támogató személyzet létszámát a konfigurációmenedzser becsüli meg, a következő tényezők figyelembevételével: A konfigurációs csoport az informatikai infrastruktúra mellett fejlesztési projektekért is felelős lesz-e? A csoport felelős lesz-e a változás kezelésért és/vagy a szoftver felügyelet és terítésért? A hardver/hálózat üzembe helyezési feladatok és az átvételi felelősség is a csoport feladatkörébe tartozik-e majd? Mekkora az informatikai infrastruktúra mérete, milyen szinten kell ellenőrzést gyakorolni, és hogy ezáltal milyen számú konfigurációs elem van? Milyen a támogató eszközök alkalmazhatósága? A szoftver változások és kiadások, és a hardver/kommunikációs felszerelések változásainak mértéke, gyakorisága és komplexitása milyen? Ahol személyzet nem áll rendelkezésre vagy nem kellőképpen képzett, valamiféle kiegészítő készségfejlesztő tréning szükséges, áthidaló megoldásként. Ha a konfigurációkezelésbeli szerepek kombinálódnak más területek szerepeivel, (mint a változáskezelés), képzés szükséges e területekhez tartozó ismeretanyagokból is. Érdemes megjegyezni, hogy a konfigurációkezelés csoport kulcsszerepet játszik az informatikában és ezért lehetőséget ad számos más informatikai csoport munkájába való betekintésre. Ez vonzó hatású lehet a lehetséges jelöltek számára. Megállapodás a célokban A KK és a projekt csoport feladata meghatározni a KK funkció céljait, meghatározva az informatikai infrastruktúra kiterjedtségét, méretét. A részletes célokhoz tartozik: Az informatikai infrastruktúrát alkotó fizikai elemek nevének és verziójának, valamint az elemek közötti kapcsolatoknak (pl. B használja A-t; C kapcsolódik D-hez; E része F-nek; stb.) és a szükséges jellemzőknek a feljegyezése. Annak biztosítása, hogy az informatikai infrastruktúra minden változása a jogosultságnak megfelelően történjen, és azonnal feljegyzésre kerüljön. Annak biztosítása, hogy csak az engedélyezett változások legyenek megvalósíthatók. 13

21 Infrastruktúra menedzsment Konfigurációkezelés Az informatikai infrastruktúra valamennyi elemére vonatkozóan a jelenlegi státuszának és közelmúltbeli történetének meghatározása. A szoftverek hiteles és megbízható kiadási meghatározása és tárolása: o a disztribúció és használat céljaira, o vészhelyzetben való felhasználás céljából, o jövőbeni fejlesztő munka alapjaként. A vásárolandó vagy fejlesztendő elemek hitelesen kibocsátott specifikációinak meghatározása és tárolása. Annak ellenőrzése, hogy az informatikai infrastruktúra aktuális állapota egyezik-e a jóváhagyottal. A kontrollálandó infrastruktúra összetevők A KK funkció átfogó céljainak eldöntése után meg kell határozni, milyen informatikai infrastruktúrakomponensek kerüljenek felügyelet alá. A hardver és a kommunikációs eszközök, a szoftverek és ezek dokumentációi, a jelenlegi és a tervezett hardver szabványok mindenképpen kontrollálandók, de az infrastruktúrával kapcsolatos valamennyi környezeti összetevő is felügyelet alá vonható. A konfigurációkezelés terminológiája szerint az informatikai infrastruktúra összetevőit konfigurációs elemeknek (KE) hívjuk. Ebbe beletartoznak a hardver és szoftver összetevők, a hálózati elemek, a dokumentáció és az informatikai infrastruktúrával kapcsolatos valamennyi más elem. A1 A2 A3.1 A Rendszer A3 A3.2 A4 A ábra: A konfigurációs elemek lebontása A konfigurációkezelés fontos kérdése annak eldöntése, hogy milyen szintig gyakorolják a felügyeletet hiszen a felső szintű KE-ek összetevőkre bonthatók, amelyek maguk is KE-ek, és így tovább. Ennek illusztrációja az A rendszert bemutató 3. ábra, ahol az A az A1, A2, A3 és A4 összetevőket tartalmazza. Valamennyi összetevő lebontható további összetevőkre. Ebben a példában az A3-at az A3.1, A3.2 és az A3.3 építi fel. Valamennyi bemutatott elem konfigurációs elem (KE), beleértve a teljes rendszert. A fenti diagram szerint az A rendszer az A3 elem szülő-konfigurációs elemének nevezhető. Az A3.1 részelem az A3 összetevő gyermekeként azonosítható. A konfigurációs elemeket rendszerint addig a szintig definiálják, amíg a komponensek önállóan üzembe helyezhetők, kicserélhetők vagy módosíthatók. Pl. nem érdemes szoftver modulokat azonosítani, ha a legalacsonyabb szint, ahol még változtatások történhetnek, a teljes szoftver program. Különböző esetekben, attól függően, hogy ki akarja használni az információt és milyen célra, változhat az a szint, amelytől a KE információt azonosítani vagy kivonatolni kell. Bár ugyanaz a KE az informatikai infrastruktúra több helyén is használható, könnyen előfordulhat, hogy máskülönben ugyanolyanként kezelhető KE-ek kissé különböző verzióit használják. Egy ilyen kissé eltérő verziónak különböző lesz. Az ilyen KE-eket variánsoknak nevezik. A mai nagy és komplex informatikai infrastruktúrák megkövetelik a támogató számítógépes eszközök használatát, amelynek része a rugalmas és kiterjedt vizsgálatokat lehetővé tevő KKAB. Ez általában 14

22 Infrastruktúra menedzsment Konfigurációkezelés egy relációs adatbázis. A KKAB részletes adatokat tartalmaz a KE-ek tulajdonságairól és történetükről, illetve a közöttük levő fontosabb kapcsolatokról. A KE-ek kapcsolataira példák a következők: Összekapcsolás-viszony: pl. egy terminál kapcsolódik a LAN-hoz. Használati viszony: pl. egy program felhasználja egy másik program modulját. Rész-viszony: pl. egy szoftver modul egy programnak a része. Másolati viszony: pl. valamely PC egy a szabvány PC-k közül. Típus-viszony: pl. egy PC 486-os rendszer a 486-os tömör megnevezése lehet az azonos típusú PC-knek, bár önmagában olyan dolog, hogy 486-os, nem létezik. A megfelelő mennyiségű adattal feltöltött és karbantartott KKAB nélkülözhetetlen vizsgálati, elemzési szolgáltatásokat nyújt (pl. egy kiadási csomag KE komponenseinek és verziójuknak a listázása, változások által érintett KE-ek meghatározása, adott KE-hez kapcsolódó valamennyi változtatási kérelem listázása, egy adott szállítótól adott periódusban vásárolt KE-ek, stb.). A lehetséges komponensek sokfélesége miatt gondosan kell megtervezni a KK funkciót, és figyelmet kell fordítani a KKAB céljára ajánlott szoftverre, annak lehetőségeire és korlátjaira. A KKAB-nak tartalmaznia kell a KE-ek közötti valamennyi kapcsolatot. Mechanizmussal kell szolgálni a változtatási kérelmek (VK), az esemény feljegyzések (EF), a probléma feljegyzések (PF) és az ismert hiba feljegyzések (IHF) összekapcsolására a hivatkozott konfigurációs elemmel. A konfigurációs elemek azonosítási szintjének tervezése Alaposan meg kell fontolni, hogy milyen szintig azonosítjuk a konfigurációs elemeket. Ha a teljes informatikai infrastruktúrát tekintjük a legmagasabb szintű KE-nek, és azt bontjuk tovább kisebb összetevőkre, majd azokat még további, kisebb komponensekre, akkor nyilvánvalóvá válik, hogy dönteni kell, mi lesz a legalacsonyabb azonosított szint. Még akkor is el kell dönteni ezt, ha nem fogjuk azonnal a legalsó szinthez tartozó adatokkal feltölteni a KKAB-t, mivel így költséges reorganizációktól kímélhetjük meg magunkat. Kielégítő megoldást jelent egy olyan azonosítási szint, ahol a legkisebb egység még önállóan üzembe helyezhető, cserélhető vagy módosítható. IT infrastruktúra Hardver Szoftver Hálózat(ok) Dokumentáció 1. csomag 2. csomag Program 1-1 Program 1-2 Program 1-3 Modul Modul ábra: KE lebontás (példa) Egyensúlyt kell kialakítani az elérhető információk és a szolgáltatásukhoz szükséges erőforrások és erőfeszítések között. A KE-ek lebontása szülő/gyermek kapcsolatként írható le, ahol a gyermek a szülője lehet egy másik alacsonyabb szintű komponensnek (amely számára gyermek ). A KE 15

23 Infrastruktúra menedzsment Konfigurációkezelés információ csak akkor hasznos, ha segíti a változások kezelését, az események és problémák felügyeletét, vagy az egyedileg változtatható, másolható, elmozdítható eszközök felügyeletét. Döntés a variánsokról A szervezetnek el kell döntenie, hogy megengedi-e vagy sem a variánsok használatát. Alternatív lehetőségként felmerül, hogy teljesen új KE legyen minden megváltoztatott KE-ből. Itt kompromisszumot kell kötnünk: a variánsok használata révén kevesebb KE-et kell kezelni, és könnyebb a közösen kezelendő KE-ek azonosítása hibák kezelése vagy változtatások megvalósítása során. Ez a módszer viszont jelentősen növeli a KK rendszer összetettségét. Általános szabályként tekinthető, hogy ha egy KE egy másik KE kissé módosított változatának tekinthető, és az egyiket érintő problémák valószínűleg hatnak a másikra, vagy az egyiken végrehajtott változtatásnak a másikon is meg kell történnie, akkor a variáns használata megfontolandó. Máskülönben ezek különböző KE-ként kezelendők. Előírások Döntés szükséges a verziók alkalmas számozási rendszeréről. Két vagy háromszintű számozási rendszer ajánlható, amelynek felső szintje a nagyobb változások, az alsó szint pedig a kisebb változások jelölésére szolgál. Ha egy KE-et megváltoztattak valamilyen módon, meg szokás tartani az eredeti nevet, de a verziószámot megváltoztatják. A nagyobb változásokat új modellszámokkal kell jelezni. Az azonos specifikációjú KE-ek, szoftver másolatok a másolatszámmal vagy sorozatszámmal különböztethetők meg. Az összes egyedi KE azonosítására elnevezési konvenciót kell kialakítani. Ez a konfiguráció-menedzser feladata. Az egyes KE előfordulásokat egyedileg meg kell tudni különböztetni a KE név és a másolatszám/sorozatszám segítségével. Megjegyzendő, hogy a verziószám a KE-nek az ugyanolyanként kezelhető, de megváltoztatott verzióját is azonosítja. Ugyanannak a KE-nek több mint egy verziója létezhet együtt egyidejűleg. A variánsok a hasonló KE-mel azonos nevet viselhetnek, de attól különböző verziószámot kell kapniuk. A másolatszám egy KE meghatározott másolatát azonosítja. Ha különböző másolatok azonos nevet viselnek, a másolatszám a név lényeges részének tekintendő, hogy semelyik két másolat ne lehessen azonos. Az elnevezési szabályok tervezésekor nagyon fontos elegendő figyelmet fordítani a lehetséges jövőbeni növekedésre. Az elnevezési konvenció kialakításakor a következő szempontokat érdemes figyelembe venni: törekedjünk viszonylag rövid elnevezésekre, tegyük a neveket olyan kifejezőekké, amennyire csak lehetséges, hasznosítsunk minden létező és alkalmas konvenciót, amely a személyzet számára már ismert. A konfigurációs elemekről feljegyzendő tulajdonságok tervezése A tervezés lényegi részeként adatgyűjtést kell végezni, hogy megszerezzük a szükséges információkat az attribútumokról. A különféle KE kategóriáknál különbözni fognak a feljegyzendő tulajdonságok. A döntést a feljegyzendő tulajdonságokról a KKAB is befolyásolhatja. Meg kell tervezni a szükséges adatok összegyűjtését is. Általában van már valamilyen adat (nyilvántartás) a szervezet birtokában, ami felhasználható. Termékbázisok tervezése A termékbázisok egy adott KE (és az alkotó KE-ek) adott időpontbeli állapotának, jellemzőinek, összetételének rögzítése, amely biztos kiindulási alapul szolgálhat beszerzésekhez, továbbfejlesztésekhez, hibás változtatás esetén a visszaállításhoz. Ilyenek pl. a csomagkiadások feljegyzései vagy a hardver-specifikációk. A konfigurációs elemek címkézésének tervezése Valamennyi KE-et a megfelelő módon el kell látni a KE névvel, verziószámmal, modell számmal, másolatszámmal a könnyű azonosítás lehetővé tétele érdekében. Ahol a KE hardver eszköz, fizikai címkét kell használni, míg szoftverek esetében a fájl fejének kell tartalmaznia a címkét. Gondot kell 16

24 Infrastruktúra menedzsment Konfigurációkezelés fordítani a dokumentációra, naprakészségét biztosítandó. A megfelelő adatokat a tároló médián is fel kell tüntetni. A konfigurációs elemek regisztrációjának tervezése Eljárásokat kell tervezni és létrehozni az új és jelenlegi KE-ek KK felügyelet alá vonásához, adataiknak a KKAB-ba való felviteléhez. Fontos, hogy a KK bevezetésétől fogva új KE kontroll nélkül ne kerülhessen az éles környezetbe. Ideális esetben a KE státusza változtatásakor automatikusan módosul (pl. szoftver fejlesztés, kiadások során). Eljárások szükségesek ahhoz, hogy minden új és engedélyezett KE megfelelően regisztrálásra kerüljön a KKAB-ban. Az elosztott felügyelet Ha a KK rendszer elosztott informatikai infrastruktúrát ellenőriz sok helyszínnel, megfontolandó a KK funkció szétosztása is. Bár egyetlen központi KKAB alapvetően szükséges, bizonyos körülmények között a KE-ek jobb fizikai kontrollja lehetséges az egyes helyszíneken alkalmazott KK személyzet segítségével. Ilyen esetben feltétlenül szükséges elérést biztosítani a centralizált KKAB-hoz. Kapcsolat a változáskezeléssel és a problémakezeléssel A KK teszi lehetővé az infrastruktúra változások felügyeletét. Ha változtatásra van szükség, változtatási kérelmet (VK-et) nyújtanak be, ami dokumentálja, hogy mely KE és hogyan érintett a változás által. Engedélyezés után a VK változtatási feljegyzéssé vagy kiadási feljegyzéssé alakul, ami dokumentálja a KE változásait, leírja a visszaállítás módját és annak következményeit. Az érintett KEek feljegyzéseit is frissíteni kell. A KKAB-ban információt kell tárolni a KE-ek jelenlegi és korábbi, valamint tervezett verzióiról. Az ilyen KE-ek státuszának is tükrözni kell a beszerzés / fejlesztési / tesztelési / implementálási / archiválási folyamatot. A támogató eszközök tervezése A támogató szoftvert alaposan meg kell vizsgálni és értékelni kell, mivel az jelentősen befolyásolhatja a KK funkció működését. Hasznos, ha az eszköz képes grafikusan is támogatni a KE-ek definiálását és ábrázolását. A konfigurációs auditok tervezése Tervet kell készíteni a rendszeres konfigurációs auditról, amely ellenőrzi, hogy a KKAB adatai konzisztensek-e a tényleges KE-ekkel. Ilyen auditokra szükség van a KK funkció bevezetését követően, az infrastruktúra jelentősebb változásait követően, katasztrófák bekövetkezése után, illetve véletlenszerűen kiválasztott időpontokban is. Szemlék és auditok tervezése Tervet kell készíteni a KK funkció hatékonyságát és eredményességét ellenőrző rendszeres szemlékről és auditokról. Széleskörű értékelésre van szükség a KK bevezetése előtt és után, a KK hatásának értékeléséhez. A KK-nek a változáskezelésben, a problémakezelésben, az informatikai eszközök felügyeletében játszott pozitív szerepének demonstrálásában segíthet a következő információk feljegyzése: az engedély nélkül végrehajtott változtatások havonkénti száma, hatása a szolgáltatások színvonalára, a hibák miatt visszavont változtatások havonkénti száma és hatása a szolgáltatás színvonalára, a KE-ek eltéréseinek száma az engedélyezett állapottól és a hatásuk a szolgáltatásra, a költségekre, változtatási kérelmek esetén a hatásvizsgálat időszükséglete és átlagos költsége, az események és problémák súlyossága havonként, a gyorssegély-szolgálat által a hívás folyamán (azonnal, eszkaláció nélkül) megoldott kérések száma, a rögtön nem megoldható segélykérések diagnosztizálására fordított átlagos idő, a szolgáltatási szint megállapodások megszegéseinek száma, súlyossága, a használatban levő, de engedélyezetlen KE-ek száma, értéke. 17

25 Infrastruktúra menedzsment Konfigurációkezelés Ezen adatok által hosszabb időszak által kirajzolt trendek javulást kell mutassanak. A megvalósítási terv Ha a konfigurációkezelés terjedelméről már megszületett a döntés, a megvalósítás tervét kell elkészíteni. Működtetés és menedzsment Tervet kell készíteni a KK jelenlegi működéséről és menedzsmentjéről. A megfelelő gyakorlatra érdemes és kell építeni A megvalósítás Amint a KK rendszer tervezése kész, következhet a megvalósítás. Üzembe helyezés, tesztelés és kiképzés A KK támogató eszközöket installálni és tesztelni kell, orvosolva a törvényszerű gyermekbetegségeket. A szoftverek üzembe helyezése után rögtön a szükséges kiképzés kezdődhet. A tesztelést a képzéssel kombinálva kétszeres hasznot érhetünk el és két legyet ütünk egy csapásra. A megvalósítás nyilvánossá tétele A megvalósítás részét kell képeznie egy figyelemfelkeltő kampánynak is, hogy a személyzetben tudatosítsa az új KK eljárások bevezetésének időpontjait. Minden érintettel tudatni kell, hogy milyen változások várhatók és azok hogyan érintik őket. Meg kell győzni őket arról, hogy a funkció valóban hasznos a szervezet számára, és nem csupán egy rájuk kényszerített ötlet. A meggyőzés eszközeként szolgálhatnak a témáról tartott szemináriumok, prezentációk, a szervezetben terjesztett tájékoztató dokumentumok. A konfigurációs adatbázis feltöltése Ezután következhet a KE-ek részletes adatainak a KKAB-ba való bevitele, a már korábban tárgyalt fokozatos módon, biztosítva, hogy az újonnan az informatikai infrastruktúrához adott elemeket ne lehessen figyelmen kívül hagyni. Ebbe beleértendők a még nem implementált VK-ek. Ha ezek kerülnek először az adatbázisba, akkor minden új vagy kapcsolódó változás az új eljárások alanya lesz, beleértve a jóváhagyást és az implementációt. A történeti feljegyzések várhatnak egy későbbi, nyugodtabb időpontig. Más szóval inkább minden új KE-re és VK-re fordítsuk a figyelmünket, mintsem a létező feljegyzésekre. A feltöltés fáradságos, időigényes tevékenység, ezért szükséges lehet átmeneti segítség igénybevétele (adatrögzítők alkalmazása). Átállás az új rendszerre Az új rendszerre való átállás csupán embereket kíván, akik elkezdik használni az új eljárásokat. Eszközök és procedúrák alkalmazása a folyamat automatizálására kimutatja vagy akár meg is előzheti a korábbi gyakorlat továbbélését. Hangsúlyt kell helyezni arra, hogy minden új elem hozzáadása az új eljárásokon keresztül történjen. A megvalósítás utáni szemlék és audit A konfigurációkezelésnek a változáskezelésben, problémakezelésben, az informatikai eszközök felügyeletében játszott pozitív szerepének kimutatásában a következő mérőszámok feljegyzése segíthet: az engedély nélkül végrehajtott változások száma és hatása a szolgáltatások színvonalára havonként, a hibák miatt visszavont változások száma és hatása a szolgáltatások színvonalára havonként, a KE-ek engedélyezett állapottól való eltéréseinek száma és hatásuk a szolgáltatásra, az informatikai költségvetésre, változtatási kérelmek esetében a hatásvizsgálat időszükséglete, átlagos ideje, az események és a problémák súlyossága és száma havonként, a gyorssegély-szolgálat által a hívás folyamán (azonnal, további eszkaláció nélkül) megoldott kérdések száma, a rögtön nem megoldható segélykérések diagnosztizálására fordított átlagos idő, 18

26 Infrastruktúra menedzsment Konfigurációkezelés a Szolgáltatási Szint Megegyezések megszegéseinek száma, súlyossága, amennyiben azok a gyorssegélyszolgálat, a változáskezelés és a problémakezelés által vétett hibákból fakadnak, a használatban levő, engedélyezetlen KE-ek száma és értéke. Függőségek Számos funkció szükséges ahhoz, hogy a konfigurációkezelésből fakadó hasznokat és lehetőségeket kiaknázhassuk: változáskezelés, szoftver felügyelet és terítés, tesztelő funkciók, problémakezelés. Megfelelő képzettségű és létszámú személyzetre is szükség van, máskülönben a konfigurációkezelés szűk keresztmetszetté válhat, az esetleges hibák helyrehozatala pedig jelentős költségekkel jár. A KK funkció tervezésének időszükséglete a funkció bonyolultságától függően 4-12 hónapig tarthat, az implementáció pedig kb. 1-3 hónapig Problémák A KK bevezetése során természetesen hibákat lehet elkövetni, mint például: Rossz KE szint meghatározása: túl alacsony szintig definiálva a KE-eket túlságosan részletes nyilvántartást kapunk, ami nehézkességet és szükségtelen költségeket okoz. Ha túl magas szinten határoztuk meg a KE-ek szintjét, akkor a szükségesnél jóval nagyobb információtechnológiai infrastruktúra változtatásokra kényszerülünk. Kézi KK rendszerrel való próbálkozás: sokan kezdetben kézi rendszerekkel kísérleteznek, és csak később akarnak átállni számítógéppel támogatott rendszerre ez azonban hamar túlterhelést és késéseket, ebből eredően frusztrációt okoz, így a KK bevezetése félbemarad. Sürgős változtatások: ezek a legváratlanabb időpontokban jelentkezhetnek, fel kell rá készülni, hogy a KK is elláthassa a velük kapcsolatos teendőit ez rugalmas megoldásokat igényel! Túl ambiciózus határidők: ha nem biztosítunk megfelelő időt a KK személyzet számára feladata ellátására, akkor a funkciót szűk keresztmetszetként érzékelhetik. A KK lassúsága mellett azonban hasznai messze nagyobbak, mint a mellőzésével vagy kikerülésével lehetséges időmegtakarítás. Mivel a KK viszonylag új megközelítés, tapasztalható némi kezdeti ellenállás. Ez azonban leszerelhető, ha összevetjük a költségeit a nélküle felmerülő problémákkal. A KK megkerülése: sokan sietségből vagy rossz szándékból megkísérlik a KK eljárásainak megkerülését. Ezért tudatosítani kell az emberekben KK hasznait, illetve szükség esetén szigorú ellenintézkedések is szükségesek lehetnek. 2.2 A konfigurációkezeléshez kapcsolódó eljárások A konfigurációkezelés négy alapfunkciója Négy fő funkcióján keresztül a konfigurációkezelés naprakész listát tart fenn az informatikai infrastruktúra valamennyi konfigurációs eleméről, és információval rendelkezik: az informatikai infrastruktúrában éppen használt létező valamennyi KE-ről és lehetséges verzióiról, a KE-ek státuszáról, valamennyi KE tulajdonosáról, az elemek közötti kapcsolatokról. Azonosítás Az informatikai infrastruktúra egyes komponensei konfigurációs elemként azonosításra, leírásra és felsorolásra kerülnek, a közöttük levő különféle kapcsolatok leírásával együtt. A 3. ábra példáját tekintve, az azonosítás a bemutatott KE-ek elnevezésével és felsorolásával, valamint a köztük levő kapcsolatok leírásával foglalkozik. 19

27 Infrastruktúra menedzsment Konfigurációkezelés Felügyelet A KE-ek csak a megfelelő jogosultság esetén módosíthatók, változtathatók vagy cserélhetők. A felügyelet biztosítja, hogy egyetlen KE sem változtatható vagy cserélhető, sem új KE-mel való bővítés nem történhet a megfelelő jogosultság nélkül. Státuszkövetés A státuszkövetés a KE-ek jelenlegi, korábbi és tervezett státuszáról és tulajdonságairól készült feljegyzések karbantartása, e státuszok és tulajdonságok változásainak nyomon követése: pl. ahogy egy KE státusza változik a fejlesztés a tesztelés, az éles használatra való beütemezés, az éles használat majd az archiválás során. Verifikáció A konfigurációkezelési adatbázisban (KKAB) található KE-ek érvényességét felül kel vizsgálni a KE tényleges státuszának és az adatbázisban levő hivatalos adatoknak az összehasonlításával. A verifikáció annak az ellenőrzésével foglalkozik, hogy a valóságos, aktuális KE-ek megfelelnek-e a KKAB-ban leírt, hivatalosan elfogadott állapotnak. Amennyiben ez nem teljesül, az engedélyezetlen beavatkozásra, változtatásra, visszaélésekre utal, ami zavarok és így károk forrása lehet! A konfigurációkezelés eljárásai A konfigurációkezelés fő funkciói a következők: mechanizmust nyújt arra, hogy az informatikai infrastruktúra minden eleme és azok valamennyi változása megfelelően engedélyezett legyen, működteti a KKAB-t, amely jelzi az informatikai infrastruktúra engedélyezett állapotát, és naprakészen tartja, hogy lehetővé tegye a változások menedzselést és az események ill. problémák kezelését. A KK által ellátandó tevékenységek a következők: A változáskezelés kapcsán: o Minden új KE regisztrációja és a megszüntetett KE-ek törlése. o A KKAB módosítása valamennyi KE-mel kapcsolatos státuszváltozás kapcsán. o A KKAB felhasználása VK hatásbecslésre, a megvalósítandó változások definiálására, a várt változások hatásának feljegyzésére, a helyreállítási tevékenység dokumentálására és a hatások előrejelzésére, és a rendszer pontos regisztrálására, amikor a változás megtörténik. A hardver szabványok, a dokumentumok tőpéldányainak stb., KK kontroll alatt való karbantartása. A KKAB segítségével az események és problémák kezelésének támogatása. Rendszeres ellenőrzés a KKAB-ban feljegyzett helyzetet az installált rendszerrel összehasonlítva, és minden szükséges korrekció megtétele. A KE-ekről vezetői információk szolgáltatása (pl. arról, hogy melyik probléma és hiba hat melyik KE-re, milyen mértékben; élettartam-lejárati dátumokról; licencdíj-megújítási dátumokról és költségekről; stb.). A KK eredményességének és hatásfokának felmérése, jelentés a vezetésnek, valamint minden szükséges korrekció megtétele. A KK rendszer felkészítése a jövőbeni munkaterhelésre és növekedésre (azaz, hogy a KK funkció ellátása a megfelelő személyzettel és informatikai erőforrásokkal). A változtatások követése Valamennyi engedélyezett változásnak és kiterjesztésnek feljegyzésre kell kerülnie a KKAB-ban. A változásokat a megvalósítás előtt a KKAB-ban levő jogosultsági feljegyzéssel vetik össze ellenőrzés céljából. A megvalósítás után a változás által érintett KE-ek státuszát is módosítani kell. Ahhoz, hogy a KKAB pontosan tükrözze az informatikai infrastruktúra állapotát, a következő specifikus KK tevékenységeket lehet feljegyezni: amikor az informatikai infrastruktúrához új KE-et adnak hozzá, 20

28 Infrastruktúra menedzsment Konfigurációkezelés amikor a KE státusza változik, amikor a KE tulajdonosa változik, amikor a KE elhelyezése változik, amikor a KE-et érintő kapcsolatok változnak, amikor egy régi KE-et eltávolítanak az informatikai infrastruktúrából, amikor regisztrálatlan KE-et észlelnek, vagy pontatlan KKAB információkat találnak (pl. amikor a gyorssegély-szolgálat regisztrálatlan, vagy pontatlanul feljegyzett KE-mel kapcsolatos hívást kap; vagy egy konfigurációs audit alkalmával). Az informatikai funkció személyzetének figyelnie kell arra, hogy jelentse a KK-nek valamennyi engedélyezetlen KE-et, vagy az olyan KE-et, amely nem egyezik a KKAB-ban róla feljegyzett információkkal. A KK funkciónak meg kell határoznia a regisztrálatlan elemek eredetét, javasolnia vagy kezdeményeznie kell az elem regisztrációját, javítását, vagy törlését (az adatbázisban); és ki kell javítania azokat az eljárásbeli hiányosságokat, amelyek a regisztrálatlan elem becsúszását lehetővé tették, majd jelentést kell tennie a vezetésnek. A KK kapcsolata a változáskezeléssel A KK hozzájárul a változások irányításához az informatikai infrastruktúrában. A KKAB-nak információkat kell tartalmaznia a KE-ek korábbi és jelenlegi verzióiról. A KKAB-ban levő KE státuszának meg kell változnia, amint az a tesztelésből az éles használatba majd végül archiválásra kerül. Terveket és eljárásokat kell tehát kialakítani, amelyek lehetővé teszik a státusz változásának naplózását a következőknek megfelelően: Új KE esetében KE fejlesztése vagy beszerzése folyik. Meglévő KE esetében VK érkezett a KE-mel kapcsolatban: a KE új verzióját kérték, a VK engedélyezésre került és a változást tervbe vették: a KE új verziója készül és kerül implementálásra egy kiadás (release) részeként. Valamennyi KE esetében: Elem beszerzése vagy kiadása várható: a változtatási vagy kiadási feljegyzés és a KE komponenseinek státusza változik a beszerzési vagy fejlesztési folyamat előrehaladásának megfelelően, Elem vagy kiadás tesztelés alatt: a változási vagy kiadási jelzi a tesztelendő elemeket, a tesztelés folyamán a változási vagy kiadási feljegyzés és a kapcsolódó KE-ek komponenseinek rekordjai változnak a tesztelés függvényében, Elem vagy kiadás éles használatba kerül: a változási vagy kiadási feljegyzés jelöli meg az éles használatra kerülő elemet; amint az Elem vagy kiadás használata elkezdődik, a változási vagy kiadási feljegyzés és a kapcsolódó KE-ek komponenseinek státusza is megfelelően változik. A hatálytalanított kiadási és KE komponens feljegyzések is megváltoznak, jelezve, hogy archiválásra kerültek. A konfigurációs auditok Rendszeres konfigurációs auditálásra van szükség annak verifikálásához, hogy valamennyi aktuális KE engedélyezett-e és konzisztens-e a KKAB-ban foglaltakkal. A felderített engedélyezetlen vagy helytelen KE-ek száma befolyásolni fogja az auditok gyakoriságát. A konfigurációs adatbázis mentése, archiválása és karbantartása A KE-ek jelenlegi és történeti rekordjait tartalmazó KKAB-ról rendszeres mentéseket kell készíteni, és biztonságosan tárolni. A jelenlegi KE adatokat visszaállítási céllal, a történetieket az esetleg szükséges referencia céljából kell elkészíteni. A biztonsági másolat végső soron illeszkedik a rendszeres karbantartáshoz, és a redundáns vagy törölt KE rekordok az archiválási folyamatok részévé válnak. 21

29 Infrastruktúra menedzsment Konfigurációkezelés Vezetői jelentések Rendszeres előrehaladási jelentéseket kell nyújtani a vezetés számára. E jelentések a következőket tartalmazhatják: a KKAB auditok eredményei, információk az észlelt regisztrálatlan vagy pontatlanul kezelt KE-ekről és a korrekciókról, információk a regisztrált KE-ekről/KE verziókról, KE kategóriákra, típusokra és státuszokra lebontva (lehetséges még az elhelyezkedés és más KE tulajdonságok alapján is), a növekedési információk, a KE-ek és a KKAB változási üteme, a KK munkájában levő hátralékok, vagy a KK tevékenysége által okozott késedelmek, és a javasolt megoldások, a KK személyzeti pozíciója, az egyéb informatikai szolgáltató személyzet engedélyezett munkájának túlórában végzett mértéke, a hatékonysági és eredményességi szemlék, a (munkateher) növekedési szemlék és a KK funkció auditjainak eredményei, valamint a problémák kezelésére tett javaslatok. A KKAB növekedésével trendelemzési és vizsgálati képessége révén egyre nagyobb felügyeletet tesz lehetővé a változások felett, és megelőző szerepe növekedhet a problémák azonosításában. A jövőbeni munkateher és növekedés A konfigurációkezelési funkció méretét és munkaterhét rendszeresen felül kell vizsgálni. Ellenőrzésekre van szükség annak biztosítására, hogy a megfelelő személyzet, erőforrások és támogató eszközök rendelkezésre álljanak a KK számára. Ahogy az informatikai infrastruktúra terjeszkedik és változik, a konfigurációkezelés tevékenysége (feladatmennyisége) is növekszik. A KKnek részletes terveket kell készítenie a következő periódusokról pl. 12 hónapról és körvonalaznia kell a következő évre szóló terveket is. A hatékonyság és az eredményesség megfigyelése A bevezetéstől számított kb. három hónap eltelte után kezdő felülvizsgálatot, áttekintést kell végezni a konfigurációkezelésről. Ez ellenőrzi az implementációs tervek végrehajtását, a funkció hatékonyságát és eredményességét. Ezután rendszeres szemlék szükségesek a hatékonyság és eredményesség ellenőrzése érdekében. A következő információk származtathatók a felülvizsgálatokból: a KK helytelen alkalmazásából fakadó KKAB hibák ill. az informatikai infrastruktúra hibák gyakorisága, a KKAB frissítettségének mértéke, a regisztrálatlan KE-ek gyakorisága, a Szolgáltatási Szint Megállapodások a KK rendszer hibáinak tulajdonítható megszegései, a KK rendszert érintő hibák és események gyakorisága és hatása, a KK rossz disztribúciós és implementációs tevékenységéből eredő szoftver hibák gyakorisága, a KK tevékenységek lassúsága okozta szűk keresztmetszetek ill. késések, a KKAB elemzési szolgáltatásainak konzisztens elérhetősége a megfelelő informatikai személyzet számára, trendelemzésre való felhasználhatóságának mértéke, a pontos és rendszeres vezetői jelentés készítés kiterjedtsége, a KK munkaterhelésének változásával és növekedésével foglalkozó tervek eredményessége. Minden periódus vizsgálatainak eredményeit össze kell vetni az előző felméréssel, és ahol szükséges, korrekciót kell végrehajtani. A KK funkció hatékonyságában és eredményességében fokozatos és folyamatos javulásnak kell érvényesülnie. 22

30 Infrastruktúra menedzsment Konfigurációkezelés A céloknak való megfelelés vizsgálata Ajánlott a konfigurációkezelést auditálni az implementálás után három hónappal és legalább évente azután. A következő kérdések lehetnek az audit részei: véletlenszerűen kiválasztott VK esetében a kezdeményezéstől a megvalósításig vizsgálni a KK procedúrák alkalmazását KE-ek összevetése a VK-kel, amelyek befolyásolják ezeket a KE-eket Vannak-e rendszeres konfigurációs auditok? A KE-ek archiválásra kerülnek-e és a biztonsági háttér verziókat megőrzik és feljegyzik-e? Helyesek-e azok a szoftverek verziói, amelyek jelenleg különböző helyszíneken használatban vannak? Az elnevezési konvenciókat betartják-e? A KE variánsokat az eljárásoknak megfelelően alakítják-e ki és kezelik? Rendszeresen karbantartják-e a KKAB-t? Szemléket és távlati terveket rendszeresen készítik-e? Rendszeresen szolgáltatnak-e pontos jelentéseket a vezetésnek? A személyzet megfelelően képzett? Az eredmény a vezetői jelentések része lehet és a különbségeket, eltéréseket az eljárásoknak megfelelően kell kiigazítani. 2.3 Ajánlott irodalom Configuration Management. IT Infrastructure Library, CCTA. HMSO ISBN A témával foglalkozó Web-oldalak: Eszközök Néhány példa:

31 3. Gyorssegély-szolgálat A gyorssegély-szolgálat a számítógépes szolgáltatások lényeges alkotóeleme, és fontossága egyre növekszik, ahogy az informatika alkalmazása egyre szélesebb körben elterjed egy szervezetben az évek során. Az informatikai, számítógépes szolgáltatások fejlődése az egyszerű kötegelt feldolgozástól az összetett tranzakció-feldolgozó hálózatokon át a korszerű kliens-szerver rendszerekig új felelősségeket rótt az informatikai személyzetre. Az egyszerű feladatok bonyolult funkciókká nőtték ki magukat. A felhasználók gondjai az informatikai szolgáltatások bonyolultsága növekedésének arányában megsokszorozódtak. Amikor még kizárólag csak kötegelt rendszerekkel dolgoztak, akkor csak viszonylag egyszerű problémák léptek fel, mint a nyomtatási listák eltűnése, illetve erőforrásmegosztási gondok kezelése. Az ilyen kérésekkel gyakran az adatfelügyelet szakemberei, illetve esetleg a számítógép operátorok foglalkoztak. A számítógépes eredménylistákat rendszerint felhasználói csoportonként egyetlen személy kapta kézhez, és így a kérések is általában egyetlen forrásból származtak. Ma a számítógép operátorok már képtelenek lennének a segélyhívások özönével megbirkózni. A rendszerek bonyolultságának növekedtével párhuzamosan az információtechnológia használata egyre egyszerűbb lett. Ugyanakkor továbbra is fontos marad, hogy az informatikai részlegek a felhasználók számára szükség esetén azonnali segítséget tudjanak nyújtani. Ez különösen igaz akkor, amikor az informatika a szervezeti tevékenységek újabb és újabb területein válik meghatározóvá. Alapvetően fontos egy hatásos kommunikációs csatorna léte a felhasználói közösségek és az informatikai részlegek között, különösen abban az esetben, ha az informatikai szolgáltatások során problémák lépnek fel. Ez az anyag az ilyen ún. belső (szervezeten belül szolgáltatásokat nyújtó) gyorssegély-szolgálatra vonatkozik. A gyorssegély-szolgálat hagyományos meghatározása az lehetne, hogy ez tulajdonképpen egy 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ással stb. kapcsolatban. Bármely szolgáltató ágazatban, ahol ilyen "panaszkönyvi" mechanizmust használnak, a kulcskérdés a felhasználói problémák kezelése, és a jobbításra való törekedés. Az informatika világában ezeknek az igényeknek a rögzítése, hivatkozása és elemzése figyelemre méltó erőfeszítést és időráfordítást igényel. Mivel az adatokat általában több különböző csatornán keresztül gyűjtik, esetleg több, egymástól eltérő hagyományos papíros-alapú rendszerben, ezért előfordulhat, hogy nem áll össze a teljes kép az informatikai szolgáltatásokat érintő zavarokról, és emiatt a problémák tovább élnek. Közelebbről megvizsgálva a kérdést, a gyorssegély-szolgálat több mint, egy panasziroda, szélesebb felelősségi körrel bír, még akkor is, ha a gyorssegély-szolgálat tevékenységeinek nagy része az esemény-felügyelet körül forog, és szorosan kapcsolódik a problémakezelés témaköréhez. 3.1 A gyorssegély-szolgálat alfunkciói Az informatikai szolgáltatások zavaraival foglalkozó tevékenységeket három csoportba sorolhatjuk. Mindegyik területen más a működtetési célkitűzés: Esemény-felügyelet Probléma-felügyelet Hibafelügyelet Ez a fejezet a gyorssegély-szolgálathoz kapcsolódóan az esemény-felügyelethez tartozó tevékenységekre koncentrál. Az 5. ábra mutatja területeket, ahol a gyorssegély-szolgálat felügyeletet gyakorol. A gyorssegély-szolgálat foglalkozhat csupán néhány szoftverrel kapcsolatos kérdéssel, de feladata lehet az is, hogy a szervezet bármely technikai alkalmazása kapcsán felmerülő probléma esetén segítséget nyújthat. Nagyobb szervezeteknél több, más-más feladatkörű gyorssegély-szolgálat is megvalósítható. 24

32 Infrastruktúra menedzsment Gyorssegély-szolgálat A gyorssegély-szolgálat azért létezik, hogy azonnali segítséget adjon a felhasználóknak, amikor valamely informatikai szolgáltatás használata közben üzemzavar lép fel. A rendellenesség származhat abból, hogy a szolgáltatás nem az elvárt módon (rendellenesen) működik, de a fellépett jelenséget okozhatja a felhasználói ismeretek hiánya is. A szolgálat ezen túlmenőn központi gyűjtőhelye az információtechnológiára épülő rendszerben vélelmezett hibák és hiányosságok bejelentésének. A gyorssegély-szolgálat visszacsatolási pont is, amely összegyűjti a felhasználói közösség véleményét és igényeit az informatikai szolgáltatásokkal kapcsolatos kérdésekről. Hagyományosan személyes ismeretségek alakultak ki az informatikai személyzet és a felhasználók között, és a segítség nyújtása nem intézményesült. Egy ismeretlen harmadik személy (a gyorssegélyszolgálat munkatársa) bevonása bizony nehezen emészthető gondolat a problémák megoldásába, hiszen esetleg növeli a hibaelhárítás idejét, hacsak éppen az elhárítás, mint szolgáltatás színvonala nem javul ez által! Sok ügyfélszolgálati vezető esetében munkakörük létrehozásának legvalószínűbb indoka éppen valamilyen szervezeti igény, amit az a közvetlen hatás vált ki, amit a szolgáltatás gyakorol a szervezet ügyfeleire. Ilyen indok lehet például: Probléma-elhárító felhasználói szolgáltatás rendelkezésre-bocsátása, a hívások központi adatrögzítése, audit lehetősége, tervezési statisztikákhoz adatgyűjtés, a felhasználói hívások hatékonyabb kezelése, költséghatékonyság növelése. A gyorssegély-szolgálat lényege tulajdonképpen úgy fogalmazható meg, hogy ez a funkció felelős a felhasználók kérdéseinek és problémáinak azonnali kezeléséért és a normál szolgáltatás helyreállításáért. 25

33 Infrastruktúra menedzsment Gyorssegély-szolgálat Esemény Szervezeti felelősségi körük Esemény felügyelet I Jelentős? N Többszöri előfordulás Gyorssegélyszolgálat Számítógép üzemeltetés Hálózat-felügyelet, a Probléma kezeléssel támogatva szükség esetén Tünetek összehasonlítása Probléma Probléma felügyelet Diagnózis Problémakezelés szükség esetén speciális támogatással Ismert hiba Hibafelügyelet Helyreállítás Változtatás 5. ábra: A gyorssegély-szolgálat áttekintése 3.2 A gyorssegély-szolgálathoz kapcsolódó tevékenységek A gyorssegély-szolgálat adja a kizárólagos kapcsolatot a felhasználók és az informatikai részleg között. Ennek megfelelően a legfontosabb operatív tevékenységek kétféle csoportba sorolhatók: a felhasználótól jövő hívások kezelése (reaktív szerep), 26

34 Infrastruktúra menedzsment Gyorssegély-szolgálat az információk eljuttatása a felhasználókhoz és az érintett egyéb funkciókhoz (megelőző, proaktív szerep) Esemény-felügyelet Jól meghatározott eljárásokat kell követni annak biztosítása érdekében, hogy a gyorssegélyszolgálatnál minden egyes hívással a lehető legeredményesebb és leghatékonyabb módon foglalkozzanak. A hívásokat figyelemmel kell követni, azért hogy biztosítsuk egy kellemes és segítőkész hozzáállás (attitűd) kialakítását a gyorssegély-szolgálatnál. Az esemény-felügyelet feladata: az események regisztrálása, riasztás, az esemény besorolása jellegzetességeinek, szimptómáinak alapján, kezdeti segítség nyújtása: áthidaló megoldás keresése, ha az lehetséges, az esemény elemzése, okainak diagnosztizálása (a probléma kezelés funkció részeként), az esemény elhárítási módjának azonosítása (acél az, hogy az esetek 90%-ban az előző lépés maradjon ki), az esemény lezárása, az esetleges további fejlemények figyelemmel kísérése. Az 5. ábrán látható folyamat mutatja a szolgáltatás vagy berendezés kieséséről érkező bejelentés fogadása utáni tevékenységeket. A gyorssegély-szolgálat felelős a felhasználói közösség által jelzett események fogadásáért, rögzítéséért és a követő tevékenységek nyomon követéséért. Olyan helyen, ahol az üzemeltetés, vagy a hálózati üzemeltetés rögzíti az eseményeket, nekik kell értesíteni a gyorssegély-szolgálatot. Az eseményeket bejelentésük után be kell sorolni. E besorolásnak több célja lehet: az esemény kategorizálása hely szerint, ok szerint, súlyosság (következmény) szerint. Ha szükséges, többféle besorolás is alkalmazható. Az események kezelésének, az ismert hibák gyors felismerésének segítésének érdekében gyakran forgatókönyveket készítenek a gyorssegély-szolgálat számára. Ezek felépítése hasonló a növényhatározó kézikönyvekhez: kérdésekre adott igen-nem válaszok alapján vezet el egy adott válaszhoz. 27

35 Infrastruktúra menedzsment Gyorssegély-szolgálat Állásidô Válaszidô Helyreállítási idô Észlelés Javítás Helyreállítás Esemény Diagnózis Visszaállítás Esemény Észlelésig eltelt idô Javítási idô Hibák közti idô Rendszer események közti idô idô Esemény jellemzôk és mérôszámok 6. ábra: Esemény életciklus A gyorssegély-szolgálat felelős minden egyes, még le nem zárt esemény feloldásáért a következő eljárás követése útján: Rendszeresen ellenőriznie kell minden le nem zárt esemény státuszát és a beállt fejleményeket. Figyelemmel kell követnie azokat az eseményeket, melyeket a különböző specialista csoportok egymás között ide-oda adogatnak, ami az esemény megítélésének bizonytalanságára és a személyzet tagjai közötti vitára utal. Prioritást kell adni a nagyobb kihatással bíró események monitorozásának. Folyamatosan tájékoztatni kell az érintett felhasználókat a fejleményekről, anélkül, hogy bevárnánk az ő érdeklődésüket. Így a gyorssegély-szolgálatról jó benyomás alakul ki. 28

36 Infrastruktúra menedzsment Gyorssegély-szolgálat Felhasználói hívás a gyorssegélyszolgálat felé Alapvető részletek feljegyzése: dátum, idő, felhasználó azonossága A KKAB-hoz fordulás Igen A hívás lekérdezés? Nem Hatáskód kiosztása, eseményszám hozzárendelése, felhasználó értesítése Az esemény részleteinek felmérése Meg tudja oldani a Gyorssegélyszolgálat? Nem Az esemény továbbítása a probléma menedzsment számára Megoldási javaslat adása a felhasználónak Megoldás után Az esemény kóddal ellátása és lezárása 7. ábra: Egy esemény feldolgozásának folyamata A gyorssegély-szolgálatnak fel kell arra készülnie, hogy eszkaláljon (továbbadjon vagy felterjesszen) egy eseményt, ha nem sikerül kielégítő fejleményeket elérni (azaz nem tudják lezárni az eseményt). A felterjesztést jól meghatározott eljárások szerint kell elvégezni. Fontosabb eseményként azokat lehet meghatározni, melyek esetében a felhasználói közösségre gyakorolt hatás foka rendkívül magas, vagy az esemény okozta szolgáltatás kiesésének időtartama túlzottan hosszú lenne. A magas és hosszú szavakat jelentéssel kell megtölteni, azaz számszerűsíteni kell őket, hiszen e nélkül olyan kritériumot adunk meg, ami ellenőrizhetetlen. Az ilyen eseményeket különös figyelemmel kell kezelni. 29

37 Infrastruktúra menedzsment Gyorssegély-szolgálat Hardver meghibásodás következményeinek felmérése A gyorssegély-szolgálat rendelkezzen olyan eszközökkel, amelyek lehetővé teszik a nagyobb hardver meghibásodások felhasználókra gyakorolt hatásának a felmérését. Ajánlatos, hogy grafikus megjelenítési eszközöket használjunk e célra. Ezek az eszközök lehetővé teszik a gyorssegély-szolgálat személyzete számára az érintett felhasználók értesítését a problémákról, valamint hogy tájékoztatást adjon számukra a várható fejleményekről. Kapcsolat a konfigurációs nyilvántartással A gyorssegély-szolgálat fontos szerepet játszik a végfelhasználónál elérhető berendezésekről vezetett naprakész és pontos nyilvántartás karbantartásában. Ennélfogva a gyorssegély-szolgálat személyzete biztosítja a kapcsolatot az eseménykezelés és a konfigurációkezelés között. A felhasználói hívások nyomán felismert bármilyen eltérést a KKAB-ban engedélyezett állapothoz képest azonnal jelenteni kell egy eltérési jelentésben. Napzáró eljárások Az eseménykezelő rendszerben ki kell alakítani egy rutin napi eljárási rendet, amelynek tartalmaznia kell az alábbiakat: A le nem zárt eseményekről készüljön egy összesítő jelentés, hatáskódok szerinti sorrendben, a következő nap vagy műszak dolgozói számára. Rendszerintegritás ellenőrzési eljárások kerüljenek elvégzésre. Biztonsági mentések készüljenek az eseménykezelési adatbázisról, azért hogy a helyreállítás lehetséges legyen Vezetői információk szolgáltatása A gyorssegély-szolgálat az alapadatok egyik fő szolgáltatója. Együttműködik az informatikai szolgáltatások más csoportjaival a vezetés számára összeállított áttekintő jelentések készítésében. A gyorssegély-szolgálat felelőssége az eseményekkel kapcsolatos információk időben történő eljuttatása a vezetés számára. A jelentések tartalmát az egyéb funkciókkal együtt kell kialakítani Szervezeti alaptevékenységre vonatkozó segélykérések Abban az esetben, ha egy felhasználó nem eseményt jelent be, hanem konkrét segítséget kérne, akkor egy olyan speciális személyhez kell fordulni, akit erre a célra az illető szervezeti egység az első megkeresendő emberként jelölt ki. Ez a mechanizmus kiszűri az "ostobácska" kérdéseket, és elkerüli a gyorssegély-szolgálatnál szükségtelenül fellépő szűk keresztmetszetet és túlterhelést. Egyes szervezeti tevékenységre vonatkozó segélykéréseket esetenként technikai eseményként azonosíthatnak, de akár ez az eset, akár nem, az eljárások változatlanok maradnak. Az egyetlen igazi különbség a kettő között az elemzési célra alkalmazott kategóriakód Megelőző tevékenységek A gyorssegély-szolgálat feladatai közé tartozik az is, hogy szükség esetén figyelmeztesse a felhasználókat események bekövetkeztének esélyére. A cél az, hogy kerüljük el azokat a vermeket, amibe már más beleesett! A megelőző tevékenység megjelenési formája sokféle lehet. Igénybe vehető belső hírlevél, levelezési lista, szükség esetén személyes megkeresés. Ide tartozik a vezetői jelentések elkészítése is, ahol értékelhetik a képzési tapasztalatokat, stb. A legfontosabb az, hogy a felhasználók, beleértve ebbe a számítógépes rendszerek felhasználóit és a vezetést is, úgy érezzék, hogy a gyorssegély-szolgálat valóban azért dolgozik, hogy az ő munkájukat minél zökkenő mentesebbé tegye! Audit és szemlézés Minden funkció esetében időről időre meg kell vizsgálni annak működését, hogy vajon azt nyújtja-e, amit elvártak tőle. 30

38 Infrastruktúra menedzsment Gyorssegély-szolgálat Rendszeres eredményességi és hatékonysági szemlék Annak érdekében, hogy mérhessük a gyorssegély-szolgálat eredményességét és hatékonyságát, alkalmas mutatókat és konkrét mutató értékeket kell kijelölni. Ilyenek mutató például: Az összes szervezeti tevékenységre vonatkozó, a kezeléshez további tevékenységet nem igénylő lezárt segélykérések százalékos aránya. A gyorssegély-szolgálat által saját hatáskörben lezárt, a kezeléshez más egységet igénybe nem vevő események százalékos aránya. A gyorssegély-szolgálatnál pultonként (fogadóhelyenként) feldolgozott hívások száma, valamint az összes hívások száma. Az esemény leküzdésének és áthidalásának átlagideje, hatáskód szerinti rendezésben. Az eredményességi szemlék során ezen a mutatók mért értékét kell a tervszámokkal összevetni. A gyorssegély-szolgálat nyújtotta támogatási szintek a Szolgáltatási Szint megállapodásokban fogalmazandók meg. Folyamatos audit Minden egyes gyorssegély-szolgálati tevékenységet és eljárást rendszeres, független audit tárgyává kell tenni. Az audit eljárás magába foglalja: Minta/véletlenszerű események és kérdések eljuttatását a gyorssegély-szolgálathoz, a bejelentés kezelése stílusának az értékelését. Annak ellenőrzését, hogy minden eseménynél; a visszajelzés eljut-e az esemény bejelentőjéhez, és a mögöttes problémákat valóban megoldják-e. Annak ellenőrzését, hogy a jövőbeli változtatások ismeretesek-e a gyorssegély-szolgálat számára, és vannak-e kapcsolódó terveik. A személyzet kiképzési naplójának ellenőrzését. 3.3 A gyorssegély-szolgálati funkció bevezetése A tervezés első lépése a gyorssegély-szolgálat küldetésének egyértelmű megfogalmazása. Ezt követheti a gyorssegély-szolgálatot érintő politikák, irányelvek egyértelmű meghatározása: milyen szolgáltatásokat nyújt, milyen területeket támogat. Ez gyakran a szolgáltatási szint megállapodásokban kerül definiálásra. E tevékenységeket egy előzetes igényfelmérés nagymértékben támogatja. A gyorssegély-szolgálat bevezetése projektként kezelendő, így ajánlott olyan bevált menedzsment technikát alkalmazni a folyamathoz, mint a PRINCE (lásd az ITB 5. számú ajánlását). A bevezetés fő fázisai: Megvalósítási tanulmány készítése Kezdeményezés Specifikáció Termékkiválasztás és átfogó tervezés Fejlesztés és értékelés Implementáció Megvalósítás utáni szemle Működtetés A funkció megtervezése A tervezésnek figyelembe kell vennie azt a két fő fejlesztés irányt, ami metszi a logikai határokat a gyorssegély-szolgálat, a számítógép üzemeltetés és a hálózati üzemeltetés között. Ez a két irány: több gyorssegély-szolgálati funkció automatizálása, beleértve ebbe az események rögzítését, osztályozását, összevetésüket ismert problémákkal és hibákkal; olyan problémáknak az észlelése és figyelemmel követése, melyek megelőző, és nem reagáló jellegű válaszokat tesznek lehetővé. 31

39 Infrastruktúra menedzsment Gyorssegély-szolgálat Időtálló tervezés Az informatikai infrastruktúra fejlődni, bővülni fog, és a gyorssegély-szolgálatnak képesnek kell lennie az infrastruktúrával szemben támasztott jövőbeni igények kielégítésére is. A jövőbeli igényekre vonatkozó előrejelzéseket az alábbi adatok alapján készíthetünk: Gyorssegély-szolgálati statisztikák, melyek trendek felismerését szolgálják. Kapacitástervezési követelmények. Várható szolgáltatási szint követelmények. Információk új alkalmazásokról és szolgáltatásokról, új szoftver verziók kibocsátásáról, változásokról a hardverelemekben. Hivatkozási alap Mind az újonnan létrehozandó, mind a létező gyorssegély-szolgálat esetében körültekintően meg kell vizsgálni a szolgálat hivatkozási alapját (terms of reference). A hivatkozási alap fogja tartalmazni a szolgáltatási szint meghatározását, a probléma felterjesztés (eszkaláció) mikéntjét, a naplózási módszereket, a szükséges készségeket. A hivatkozási alapban megfogalmazottakat tételesen szemlézni/ellenőrizni kell annak érdekében, hogy betartásukat biztosítsuk. Egy integrált problémakezelési mechanizmust és gyorssegély-szolgálatot előirányzó megvalósíthatósági tanulmánynak az alábbiak a lehetséges célkitűzései: egy, az egész informatikai szervezetet átfogó gyorssegély-szolgálat és problémakezelési rendszer kifejlesztésére és megvalósítására leginkább alkalmas megközelítési mód azonosítása, költség- és erőforrásbecslések elkészítése a javasolt megközelítés megvalósítására, és részletes terv készítése a következő szakaszra. Követelmény-meghatározó dokumentum A kiinduló követelmény-meghatározó dokumentum (KMD) adja meg a gyorssegély-szolgálat szerepének és funkciójának a formális definícióját. Ajánlatos, hogy a kiinduló KMD a gyorssegélyszolgálat küldetésének egy bővített változatára épüljön. Hivatkozzon ezen túl a változásokra és a kapcsolódó területekre (mint például problémakezelés), speciális szakértelem beszerzése, szállítói támogatás és felhasználó személyzet területén alkalmazott új munkamódszerekre. Néhány jó tanács a dokumentum összeállításához: Értékeljük az elvben alkalmas kész termékeket, melyek segíthetik a gyorssegély-szolgálat munkáját. Látogassunk meg egy, a sajátunkkal összemérhető munkahelyet (ahol már bevezetésre került gyorssegély-szolgálat) Kerüljük el az újrafelfedezéseket! Járuljunk hozzá a gyorssegély-szolgálat és az informatikai infrastruktúra menedzsment rendszerekkel való ismerkedéshez. Előzetes becslések a szervezetről Amikor gyorssegély-szolgálatot vezetünk be egy olyan részlegbe, ahol már elérhető (azaz működik) egy informatikai szolgáltatás, az alábbi tevékenységeket kell elvégezni: Elemezzük a meglevő módszereket. Mérjük fel a szolgáltatás nyújtásához szükséges erőfeszítések nagyságát. Szemlézzük az informatikai fejlesztési és előrejelzési terveket. Vajon új szervezeti tevékenységek növelik-e a felhasználóknak a szolgáltatás iránti igényeit? Javul-e az alkalmazási rendszerek stabilitása, és csökken-e az események száma? Tervezték-e eredményes nyomon követő/felügyelő eszközök használatát a hálózati/felhasználói területen? Elemezzük a tevékenységeket és a hálózati naplókat. 32

40 Infrastruktúra menedzsment Gyorssegély-szolgálat Ha a gyorssegély-szolgálatot olyan részlegbe kívánjuk bevezetni, ami még nem működik, akkor a tervezésnek: Előrejelzéseken kell alapulnia, mintsem tényleges adatokon. Használjuk az összemérhető részlegekből származó számadatokat. Szemlézzük és becsüljük előre a használandó erőforrások és várható feladatok nagyságát. A szervezetek túlságosan is különböznek egymástól ahhoz, hogy egyetlen univerzális "jó" szervezeti felépítési megoldás létezzen. A megfelelő szervezeti forma kiválasztásakor vegyük figyelembe: a tevékenységek és a várható kezelendő események (tranzakciók) méretét, vajon központosított, vagy elosztott gyorssegély-szolgálat legyen-e, ha nagy tranzakció számosságokkal kell foglalkozni, a munkával való elégedettséget és az optimális hatékonyságot, a szervezeti alaptevékenységet segítő gyorssegély-szolgálat (business support help desk) lehetőségét, ami nem csupán az informatikához kapcsolódó kérdésekkel és eseményekkel foglalkozik, hanem a szolgáltatás használatához ad általános segítséget. A gyorssegély-szolgálat szervezeti felépítése A gyorssegély-szolgálat típusának kiválasztása az egyik legnehezebb kérdés a funkció bevezetésekor. A megfelelő típus választása kritikus jelentőségű, és megfelelő tapasztalat nélkül nehéznek fog bizonyulni. A gyorssegély-szolgálat formája és szervezeti elrendezése alapvetően befolyásolja a hatékonyságot és az eredményességet. Alapvetően két típusról beszélhetünk: Központosított Elosztott Egyszerű, központosított gyorssegély-szolgálat Ebben az esetben a felhasználói közösség egyetlen, átfogó feladatkörű gyorssegély-szolgálattal áll kapcsolatban, amely a számítóközpontban helyezkedik el. Jellemzői: Az összes kérést egyetlen, mindennel foglalkozó helyre címeznek. Feltehetőleg egyetlen üzemeltetési funkció ( híd, operations bridge) része. Központi számítóközpont esetén alkalmas lehet. Közel van a felügyelő személyzethez. Központosított gyorssegély-szolgálat esetén elmondható, hogy a szakértelem jól megosztható, kevesebb létszám elegendő, a központi adatbázis egyszerűbben fenntartható. 33

41 Infrastruktúra menedzsment Gyorssegély-szolgálat Felhasználó 1. telephely Felhasználó 2. telephely Felhasználó 3. telephely Felhasználó 4. telephely Felhasználó n. telephely Számítógép üzemeltetés Gyorssegély-szolgálat Hálózati felügyelet Közös üzemeltetés ( híd ) 8. ábra: Egyszerű, központosított gyorssegély-szolgálat Többfunkciós, központosított gyorssegély-szolgálat Felhasználó 1. telephely Felhasználó 2. telephely Felhasználó 3. telephely Felhasználó 4. telephely Felhasználó n. telephely Számítógép üzemeltetés Hálózati felügyelet IT gyorssegélyszolgálat Szervezeti támogató gyorssegélyszolgálat Közös üzemeltetés ( híd ) 9. ábra: Többfunkciós, központosított gyorssegély-szolgálat Ez esetben a felhasználók két gyorssegély-szolgálattal állnak kapcsolatban, az egyik technikai, a másik szervezeti alaptevékenységekkel kapcsolatos kérdéseket támogatja. Jellemzői: Kapcsolat van a két gyorssegély-szolgálati központ (az informatikai és a szervezeti alaptevékenységet segítő) között. Az alaptevékenységre vonatkozó kérdések számossága indokolhatja. Specializáció jellemzi. Elosztott gyorssegély-szolgálat Elosztott esetben mindenképpen fontos, hogy egységes eljárások szerint, egységes jelentési és egyéb dokumentum-formátumok felhasználásával működjenek az egyes gyorssegély-szolgálati egységek. Ez 34

42 Infrastruktúra menedzsment Gyorssegély-szolgálat a megoldás gyorsabb és közvetlenebb reagálást tehet lehetővé, jobban figyelembe vehetők a speciális tényezők, ugyanakkor nehezebb a részlegek koordinációja. Felhasználó 1 Felhasználó 2 Felhasználó n. Felhasználó 1 B számítógép központ gyorssegélyszolgálat Felhasználó 1 Felhasználó 2 A Számítógép központ gyorssegélyszolgálata Központi Gyorssegélyszolgálat C számítógép központ gyorssegélyszolgálata Felhasználó 2 Felhasználó n. n. számítógép központ gyorssegélyszolgálata Felhasználó n. Felhasználó 1 Felhasználó 2 Felhasználó n. Jellemzői: 10. ábra: Elosztott gyorssegély-szolgálat Nagy, elosztott rendszerű, több telephelyes szervezet esetében ajánlható Telephelyenként (vagy telephelyi csoportonként) érhető el a gyorssegély-szolgálat. A központi iroda koordinál, logikailag egyetlen adatbázison át. Minden egyes gyorssegély-szolgálati helyen egy bizonyos minimális küszöbérték felett van az elvégzett szolgáltatások (kezelt események) száma. Személyzeti kérdések Meg kell határozni becslések felhasználásával a személyzet iránti igényt. Ez legfőképpen a kezelendő események számától (pl. napi eseményszám), a felhasználói populáció nagyságától, a becsült eseménykezelési időtől, a szolgáltatási időszak hosszától ill. a gyorssegély-szolgálat várható kihasználtságától függ. A gyorsszolgálati munkához szóba jövő személyek ismereteik alapján két kategóriába sorolhatók: tapasztalt műszakiak, akik kezelni képesek a legtöbb eseményt, minőségi, de nem-műszaki személyzet, akik megoldják a rutin feladatokat, de a műszakilag bonyolultakat továbbadják. A személyzettel szemben támasztott követelmények meghatározása előtt vegyük figyelembe a gyorssegély-szolgálati tevékenységeknek az előre jelzett, várható mennyiségét, valamint azt is, hogy Szeretnénk-e hogy tisztán műszakiak túl sok időt töltsenek el a telefonnál? 35

43 Infrastruktúra menedzsment Gyorssegély-szolgálat Milyen interperszonális készségekkel rendelkezik a jelenlegi személyzet? A személyzeti erőforrások alkalmas kiosztása nagymértékben részlegszintű felelősség, de annak érdekében, hogy a betanulási időszakban meglegyen a kölcsönös segítség az informatikai részleg, illetve a felhasználói részleg között, toborozzunk személyzetet mind a szervezeti tevékenységek ismerői, mind a számítógépes/hálózati tevékenységek ismerői közül. A gyorsszolgálatokat három típusba sorolhatjuk aszerint, hogy az események mekkora hányadát kezelik helyben: gyakorlatlan, tapasztalt, szakértő. Gyakorlatlan A gyakorlatlan embereket foglalkoztató gyorssegély-szolgálat a kérdések nagy részét képes kezelni abban az értelemben, hogy azonnal reagál, a nehezebb eseteket azonban inkább továbbadja pl. egy szakértői csoportnak. A naplózott információk az alapadatokra szorítkoznak, és gyorsan továbbítják őket. Néhány jó tanács a gyakorlatlan személyzetet alkalmazó gyorssegély-szolgálatok esetére használjunk belső szabványokat és eljárásokat, tartsunk fegyelmet, erőskezű vezetés szükséges, a hívások időtartamát kézben kell tartani. Tapasztalt A tapasztalt személyzetet alkalmazó gyorssegély-szolgálat egy területre, pl. hálózatok/távfeldolgozás vonatkozó hívások nagy részét fogadja. Az a célja, hogy a jelentett események jelentős részét azonnal megoldja. Az ilyen fajta gyorssegély-szolgálatok esetén felléphet néhány nem kívánatos hatás is: túlzott részvétel és önelégültség jelentkezhet, a szolgálat belekeveredhet bonyolultabb problémákba, a terület ismerete arroganciát szülhet, előfordulhat, hogy nem tekintik kizárólagos kapcsolattartási pontnak. Szakértő A szakértő személyzetet alkalmazó gyorssegély-szolgálat megkísérli az összes probléma megoldását, lehetőség szerint eszkaláció nélkül. Minden egyes hívást rögzítenek és elemeznek. A jellemzője az ilyen rendszernek az elvégzett elemzések mélysége. A szakértői személyzet egyszerre rendelkezik műszaki tudással és kommunikációs készségekkel. Ilyen esetben a szolgáltatás a személyzet minőségére épül, körültekintő felülvizsgálatot és alapos munkaerő toborzást igényel, teljes körű oktatásra és kiképzésre van szükség, specialisták eszközeinek használatához vezet, közvetlen összeköttetést ad a gyorssegély-szolgálat vezetőjéhez és feljebb. Eszközök és egyéb tényezők Elszállásolás A legtöbb szervezetben előnyökkel jár, ha a gyorssegély-szolgálat, az üzemeltetők és a hálózati személyzet egy helyen kerülnek elhelyezésre. Ez az úgynevezett híd (operations bridge). A szükséges kommunikációs eszközök A gyorssegély-szolgálat a felhasználók és az informatikai szolgáltató közötti kommunikáció elősegítője, közvetítő, ezért információgyűjtő és továbbító feladatai ellátásához a megfelelő kommunikációs csatornák biztosítása nélkülözhetetlen. A felhasználók el kell, hogy juttassák kéréseiket a gyorssegély-szolgálathoz. Ennek sokféle megoldása lehetséges: a személyes bejelentéstől a papír-alapú (levél) formán át a telefonos, illetve elektronikus kapcsolatig. A telefonon kívül a fax, az , az intranet is szóba jöhet, mint lehetséges megoldás. Fontoljuk meg a 36

44 Infrastruktúra menedzsment Gyorssegély-szolgálat hangalapu kommunikáció segítése érdekében egy kisebb telefonközpont üzembe helyezését, ami nyújthat hívás-sorbaállítási szolgáltatásokat, hívási statisztikákat, közvetlen vonalakat, belső és külső kommunikációs kapcsolatokat, üzenetrögzítési lehetőséget. Sok informatikai szolgáltatás esetében az elkövetett hibák következménye végül az lesz, hogy a hibavizsgáló csapatot árasztják el telefonokkal, a nagyszámítógépes csapatot pedig zaklatják hiba elhárítása közben. Kezelni kell tehát az esetleges túlterheléseket is. Egy elektronikus levelező vagy bulletin (hirdetőtábla) rendszer alkalmazását is érdemes megfontolni, a felhasználók felé irányuló információk könnyebb közzététele érdekében. Egyéb eszközök, pl. szakértő rendszerek, CD-könyvtár is segíthetik a munkát. Termékválasztás és nagyvonalú tervezés Ha az azonosított követelmények tárgyában már egyezségre jutottunk és azokat elfogadtattuk a felelős vezetéssel, a gyorssegély-szolgálat munkáját segítő szoftver eszköz kiválasztása és tervezése kerülhet sorra. Mind a gyorssegély-szolgálat szervezeti felépítése és típusa, mind a választott szoftver közvetlen hatással jár a teljes szervezetre. A tervezés szakaszai: értékeljük a rendszereket, az eszközöket és berendezéseket, tervezzük meg a gyorssegély-szolgálati rendszert. A rendszerek és berendezések értékelése Szorítkozzunk a szoftver eszközök kezelhető nagyságú listájára. A kiválasztásban az alábbi kulcstényezők használhatók fel: tranzakciók számossága (jelenleg és előrevetítve), a (szoftver) szállító megbízhatósága, költségek, kompatibilitás (a meglevő informatikai infrastruktúra elemeivel és eljárásaival). Azok az eszközök, melyek nem fedik le a kapcsolódó funkciókat, lehet, hogy nem alkalmasok a szolgálat munkájának segítésére. Ha egyáltalán nincs alkalmas eszköz, akkor egyedi fejlesztésre van szükség. Vegyük azonban figyelembe, hogy az egyedi fejlesztésnek igazodnia kell a szabványokhoz, a határidők, a költségek és kockázatok nőni fognak, a költségek indoklása nehéz lehet. Eszköz egyedi fejlesztésére csak legvégső esetben kerüljön sor. Ha az értékelési eljárások kiszűrték az összes szóba jöhető készen kapható szoftverterméket, akkor először vizsgáljuk felül az alkalmasság kritériumait, figyelembe véve egy egyedi fejlesztés költségvonzatát, időigényét és kockázatait, még mielőtt belefogunk egy belső fejlesztési munkába! A gyorssegély-szolgálati rendszer tervezése 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ékek testre szabására, ami magába foglalhatja képernyőtervek és riportformátumok tervezését. A gyorssegély-szolgálat interakciós helyein (ahol fogadják a felhasználók kéréseit) szükség lesz majd a szoftverhez való hozzáférés lehetőségére, illetve a futtatást lehetővé tevő berendezésekre. A főbb elemek Meg kell határozni az eseménykezelés módjait (ez lehet közvetlen pl. telefon és kontrollált visszahívásos jellegű, pl. fax, ). Definiálni kell a lehetséges eseményekhez tartozó súlyossági 37

45 Infrastruktúra menedzsment Gyorssegély-szolgálat 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, a főbb KE-ek szerinti bontásban) 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). 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.). Igények a berendezésekkel és a környezettel szemben Mérjük fel a berendezések vonatkozó igényeket a szoftver futtatását lehetővé tevő hardverek szempontjából: PC alapú rendszer Középkategóriájú gép Nagyszámítógép A választásnak összeegyeztethetőnek kell lennie a választott gyorssegély-szolgálati szerkezettel. Kicsi és közepes méretű informatikai egységek számára az eszköz valószínűleg vagy PC, vagy középkategóriájú gép lesz, egy vagy többfelhasználós kivitelben. A rendszerhez hozzá kell férnie az üzemeltető személyzetnek, a hálózati csoportnak, a problémakezeléssel foglalkozó személyeknek és a kisegítő személyzetnek. A hozzáférés biztosítható a gyorssegély-szolgálati pult(ok)nál, hangrögzítéses vagy papíralapú módszerrel; vagy egyenesen a szoftver eszközzel. Még a legkisebb informatikai egységek esetében is előnyös lehet egy olyan integrált eszköz használata, amely többet tesz lehetővé az események puszta naplózásánál. Minimum lehetővé kell tennie a leltárral (a konfigurációs adatbázissal vagy nyilvántartással) való kapcsolattartást, és az események trend elemzését. Az egyszerű gyorsszolgálati pult jellemzői: Az összes eseménnyel kapcsolatos adatot gyűjtik és rögzítik. Eseménynaplózásra korlátozódik. Kevéssé használják. Kicsi és közepes méretű üzemeltetés jellemzői: Többfelhasználós hozzáférést nyújt informatikai rendszerek számára. A gyorssegély-szolgálat figyeli és koordinálja a tevékenységeket. Lehetővé teszi az eseményekről szóló feljegyzések átadását az informatikai támogató/segítő csoportok között. Minigép, vagy minigépek hálózata segíti az elosztott gyorssegély-szolgálatok munkáját. Közepestől nagy méretű üzemeltetés jellemzői: Minigépek hálózata segíti az elosztott gyorssegély-szolgálatok munkáját. A távoli részlegek száma rugalmasan változhat. Egyetlen központi részleg van. A helyi rendszerek rendelkeznek távoli hozzáféréssel. A központi kiszolgáló hardvere nagyobb teljesítményű. Időzítés A gyorssegély-szolgálat bevezetésének a teljes időtartama az ötlet kidolgozásától és alkalmazhatóságának vizsgálatától a működő funkcióig feltehetőleg 3 és 6 hónap között lesz. A 38

46 Infrastruktúra menedzsment Gyorssegély-szolgálat tervezési fázisban felhasznált idő hossza sok tényezőtől függ, beleértve ezek közé a szoftver testre szabását és az egyes üzembe helyezések bonyolultságának fokát A gyorssegély-szolgálati rendszer kiépítése és validálása A gyorssegély-szolgálati funkció megtervezése és a kellő felkészülés után ebben a részben a terv megvalósítását tárgyaljuk. 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 az alábbi 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 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 testre szabása Bizonyosodjunk meg róla, 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. 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 A konfigurációkezelés 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 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, 39

47 Infrastruktúra menedzsment Gyorssegély-szolgálat 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. Az átvételi teszt végrehajtása Az alapképzések, illetve az összes kisegítő tevékenység és berendezés elkészülte után egy végső átvételi tesztet kell végrehajtani. E tesztben részt kell vennie a teljes érintett személyzetnek, és szimulálni kell a működő környezetet. A tesztnek kell véglegesítenie a képzést, így tartalmaznia kell néhány váratlan helyzetet, különösen rendszer-helyreállítási tevékenységeket. Éles üzembeállítás Mielőtt még éles üzembe helyeznénk a rendszert, legyünk bizonyosak afelől, hogy a vonatkozó tervet szemlére bocsátották, és hogy tudatában vagyunk a jelenlegi gyengeségeknek és prioritásoknak. Csak akkor indítsuk el a gyorssegély-szolgálati tevékenységeket, ha az bizonyosan a gyorssegély-szolgálat szavahihetőségének elfogadását eredményezi a felhasználók körében és az informatikai részlegben. Új telephelyek esetében a gyorssegély-szolgálat éles üzembe helyezése része lesz egy átfogó informatikai szolgáltatás üzembe helyezési ütemtervnek. A mérettől függően ezt szakaszokra bonthatjuk, amely keretein belül a személyzet végleg elsajátíthatja az oktatásra került anyagokat, és fokozatosan megismerkedhet az eljárásokkal. Meglevő telephelyek esetében a bevezetés folyamata ismét szakaszokra bomlik. A szakaszokra bontás legfontosabb szempontja az, hogy mindig a már kivívott bizalomra épít. Egy ajánlott megvalósítási sorrend az alábbi: Tájékoztató rendszer felállítása a kezdetektől fogva alapvetően lényeges a felhasználói közösséggel való jó kapcsolattartás. A szervezeti tevékenységek segítése Állítsunk fel eljárásokat a felhasználói kérdések kezelésére Esemény-felügyelet bevezetése A gyorssegély-szolgálat felelős a felhasználóktól származó összes hívás fogadásáért, valamint a felhasználók részére az elvégzett hibaelhárítási tevékenységekről való tájékoztatásért. Konfigurációs elemek szemléletes megjelenítése A konfigurációs nyilvántartás grafikus, könnyen áttekinthető megjelenítésének a lehetőségével a gyorssegély-szolgálat gyorsan azonosíthatja a berendezések meghibásodásakor érintett felhasználókat, és javaslatot tehet lehetséges helyreállítási tevékenységekre. Egy ideális rendszerben a konfigurációs elemek grafikus megjelenítését szorosan egybeépítik az eseménykezeléssel. Amennyiben egy esemény naplózásra kerül, akkor ez a rendszer automatikusan megjeleníti a kapcsolódó hibás eszközt, és kapcsolódásait. Központosított vezetői jelentés összeállítása ezt a funkciót csak akkor kell bevezetni, amikor a felhasználókat segítő funkciók ténylegesen és eredményesen működnek Problémák A gyorssegély-szolgálati funkció bevezetése, üzemeltetése során problémák merülhetnek fel. 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. Előfordulhat, hogy a felhasználók megkísérlik a gyorssegély-szolgálat kikerülését, és egyenesen az informatikai személyzetnek jelentik az eseményeket, közvetlenül segítséget kérve. Ez különösen akkor fenyeget, ha a gyorssegély-szolgálat bevezetése előtt ez volt a bevált gyakorlat. Ilyen felhasználói magatartás esetén az informatikai személyzettől meg kell követelni azt, hogy minden, hozzájuk bejelentett eseményt a gyorssegély-szolgálat tudomására kell hozni. A gyorssegély-szolgálat létrehozása ellenérzéseket szülhet az üzemeltető személyzet, illetve a specialisták körében. Ez különösen akkor fenyeget, ha a gyorssegély-szolgálat él azzal a jogával, hogy jelentéseket készítsen a vezetés számára. 40

48 Infrastruktúra menedzsment Gyorssegély-szolgálat Előfordulhat, hogy a funkció bevezetése során olyan nagy, előre nem várt többletköltségek lépnek fel, melyek megakadályozzák a funkció működtetését. 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! 3.4 Ajánlott irodalom Help Desk. IT Infrastructure Library. HMSO, ISBN Computer Support Directory: Voice, Fax, and Online Access Numbers; Adler, Bill, Jr./ Fraser, Kristy. McGraw-Hill; ISBN: X Effective User Support: How to Manage the IT Help Desk; Bruton, Noel. McGraw Hill Text; 1996 ISBN: Microsoft Sourcebook for the Help Desk: Techniques and Tools for Support Organization Design and Management; Microsoft Corporation, Staff. Microsoft Press; ISBN: Running an Effective Help Desk: Planning, Implementing, Marketing, Automating, Improving, Outsourcing; Czegel, Barbara. QED Publishing; ISBN: Virtual Help Desk: Strategic Management Center; Thomas, Andrew H. International Thomson Computer Press; ISBN: X A témával foglalkozó Web-oldalak: Példák: Szoftverek és szolgáltatások:

49 4. Problémakezelés A szervezetek egyre jobban függenek tevékenységük ellátásában az informatikától. A szolgáltatásokban jelentkező zavarok tehát komolyan veszélyeztethetik a zökkenőmentes munkát. A mai, gyorsan változó informatikai környezetben a kisebb-nagyobb zavarok, problémák elkerülhetetlenek. Ezért fontos, hogy bármely probléma, amely befolyásolja az informatikai szolgáltatásokat, diagnosztizálásra és kijavításra kerüljön azzal a céllal, hogy csökkenteni lehessen e problémák hatását az informatikai szolgáltatások minőségére. Az itt ajánlott megközelítés bemutatja a működési zavarok helyes azonosítását és kezelését, a figyelmet a hibák valódi okaira terelve. E mögöttes okok megoldásával csökkenthető az üzemeltetési zavarok (események) száma és súlyossága, valamint javítható az informatikai szolgáltatások minősége ez a problémakezelés feladata. A problémák az élet elkerülhetetlen velejárói, és még a legmegbízhatóbb informatikai fejlesztések esetében is mindig működési hibák lépnek fel. E hibák számos okból fakadnak és bizonyos körülmények között elkerülhetetlenek. Azonban a hatásukra a teljes informatikai infrastruktúrában helyreállíthatatlan károkat keletkezhetnek. A problémakezelés (röviden: PK) ezekkel a zavarokkal eseményekkel, problémákkal és ismert hibákkal foglalkozik. A szervezeteknek szükségük van egy szisztematikus és fegyelmezett megközelítésre, hogy kezelhessék az informatikai szolgáltatásaikat érintő problémákat. Tevékenységük hatékonysága és eredményessége érdekében fontos, hogy az informatikai szolgáltatásaikra hatással lévő minden problémát a minimumon tartsanak, azonosítsanak, diagnosztizáljanak és felügyeljenek. Valójában a legjobb előre mozdulni a következő fázisba, és előre jelezni, hogy hol fordulhatnak elő problémák. Az események azok a váratlan jelenségek, amelyek károsan hatnak az informatikai szolgáltatásokra. Az ilyen események száma akár néhány száz is lehet minden nap ez az informatikai tevékenységek méretétől és stabilitásától függ. Problémának nevezünk egy egyedi, jelentős hatású eseményt, amelynek hatása nagymértékben rontja a felhasználók számára nyújtott szolgáltatás minőségét. Ha egyes események megegyező tüneteket mutatnak, tehát valamilyen közös okra vezethetők vissza, akkor ezt a helyzet szintén problémára utal. A vizsgálatokat és a sikeres diagnosztizálást követően problémák ismert hibákká válnak. A problémakezelés szorosan kapcsolódik a változtatásmenedzsmenthez és a konfigurációkezeléshez. Egy eredményes problémakezelési funkció gyorsan javíthat az informatikai szolgáltatások minőségén. Ez egyértelműen jelentkezik a szervezeti felhasználók esetében is, de jó hatással van az informatikai szolgáltatók termelékenységére és munkamoráljára is. A legfőbb hasznok a következők: csökken az események száma, ezeknek a hatása is kisebb lesz az informatikai szolgáltatások minőségére, fokozatosan csökken a problémák és az ismert hibák súlyossága és száma, a már megoldott problémák és ismert hibák megoldottak is maradnak, tanulni lehet a korábbi hibákból, javul a felhasználók termelékenysége, akárcsak a specialistáké, az informatikai vezetés elismertsége javul, jobb lesz a kontroll az informatikai szolgáltatások felett. Egy szervezet rendszereinek tökéletesen hibamentessé tétele nem reális, így a problémakezelés mindig nélkülözhetetlen feladat marad. A végső cél tehát nem az, hogy a rendszer hibáktól mentes legyen, hanem az, hogy az események/hibák számát elfogadható szintre csökkentse, és általában csökkentse a problémák számát. A problémakezelés általános kifejezés, számos értelmezési lehetőséggel. Az Informatikai Infrastruktúra Menedzsmentbéli értelmezését a következőkben vázoljuk. A problémakezelés olyan megközelítés, amely az informatikai szolgáltatások zavarainak (hibáinak, eseményeinek) valamennyi fajtáját kezeli. Célja nem csak az, hogy minimalizálja a megjelenő hibák hatását az esemény megoldása során (ami tüneti kezelést jelent), hanem a hibák gyökerének megkeresésével és elhárításával azok újbóli előfordulását is megakadályozza. A problémakezelés természetesen 42

50 Infrastruktúra menedzsment Problémakezelés megköveteli az együttműködést az informatikai funkció más részlegeivel. Bár a problémakezelés természetszerűleg reagáló jellegű, de fontos, hogy a problémák megjelenésének megelőzésével is foglalkozzon. A problémakezelés négy fő elemből áll: Esemény-felügyelet a normál szolgáltatás helyreállítása, ha valamilyen hiba történik. Probléma-felügyelet az események kiinduló okának megkeresése. Hiba-felügyelet a problémák megoldása. Vezetői információ információgyűjtés és szolgáltatás az előző három tevékenységről. 4.1 A problémakezelés eljárásai A következők a folyamatosan végzendő problémakezelési eljárásokat reprezentálják: Esemény-felügyelet, ezen belül a jelentősebb események felügyelete Probléma-felügyelet Hiba-felügyelet Vezetői információ szolgáltatása Megelőző problémakezelés Hatékonysági és eredményességi szemlék Folyamatos audit A jövő tervezése Esemény-felügyelet 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. 43

51 Infrastruktúra menedzsment Problémakezelés Esemény feljegyzés és riasztás kezdeti támogatás és segítségnyújtás 10% Az események 90 %-a Esemény megfigyelés és követés Vizsgálatok és diagnózis Kijavítás és helyreállítás Esemény zárása Támogatás és osztályozás Amint riasztás megtörtént, 11. ábra: Az eseménykezelési folyamat áttekintése A felhasználókkal tisztázzák helyzetet és feljegyzik a részleteket. Valamennyi érintett konfigurációs elemre (KE) gyakorolt hatást is feljegyzik. Meghatározzák az esemény okát, és az osztályozási adatokat (pl. tünetek és KE) összevetik a problémák és az ismert hibák adatbázisával. Az esemény jellegzetességei alapján meghatározható a helyreállításhoz szükséges beavatkozás, vagy döntés születhet a problémakezeléshez való eszkalációról, további vizsgálatok végett. 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 44

52 Infrastruktúra menedzsment Problémakezelés 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émafelü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). 45

53 Infrastruktúra menedzsment Problémakezelés Esemény Esemény előrehaladás összefoglalása Szabad formátumú szöveges feljegyzés Személyzet hozzárendelés Ki, mikor? Alapadatok összegyűjtése Eredmények? Esemény, probléma, ismert hiba adatbázis Történeti adatok gyűjtése Korreláció? Diagnosztikai adatrendszer - adatforrások, újságok Diagnosztikai adatok Kvázi azonosító Szöveges feljegyzések Diagnózis/ áthidalás N I Diagnózis és helyreállítás/ áthidaló megoldás További támogatás hozzárendelése Helyreállítási kísérlet Mit, miért? N Eszkalációs küszöb elérése I Mikor? Esemény zárás 12. ábra: Esemény vizsgálatok és diagnózis 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élyszolgá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. 46

54 Infrastruktúra menedzsment Problémakezelés 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émamenedzser közvetlen és átfogó felelősséggel tartozik a jelentős eseményekért, és az ilyen üléseken vezető szerepet játszik Probléma-felügyelet 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élyzetelosztá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 47

55 Infrastruktúra menedzsment Problémakezelés 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émafeljegyzé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. 48

56 Infrastruktúra menedzsment Problémakezelés Esemény riasztás Rutin esemény? I Az esemény rutineljárások követése N Az ismert hiba esemény számlálójának módosítása I Kapcsolható az ismert hiba adatbázishoz? A problémafeljegyzés eseményszámlálójának módosítása N Az esemény feljegyzés módosítása az ismert hiba azonosítójával Kapcsolható a probléma adatbázishoz? I Az esemény-feljegyzés módosítása a probléma azonosításával N Az esemény-feljegyzés módosítása a kategória adattal Új feljegyzés létrehozása a probléma adatbázisban Az esemény-feljegyzés módosítása a kategória adattal Az ismert hiba adatbázisból a helyreállítás v. az áthidaló megoldás megkeresése Új probléma riasztás A probléma-adatbázisból a helyreállítás v. áthidaló megoldás kinyerése Szükséges-e segítség I Továbbítás a probléma kezelési csoporthoz I Szükséges-e segítség N A helyreállítás végrehajtása Esemény elôrehaladás N A helyreállítás végrehajtása Hiba-felügyelet 13. ábra: Az esemény besorolási/összevetési folyamat 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 49

57 Infrastruktúra menedzsment Problémakezelés é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) A hiba azonosítása és a lehetséges megoldási módok kezdeti felbecslése, majd: o Vagy a sürgős megoldások engedélyezése és végrehajtása (csak extrém körülmények között) o Vagy változtatási kérelem (VK) benyújtása. A változásmenedzser a hiba súlyosságára alapozva meghatározza a kezdeti prioritását A VK a Változtatási Tanácsadó Testület elé kerül hatás- és erőforrásbecslés, valamint az időzítésre való javaslattétel céljából. A változtatást normális esetben egy kiadási csomag részeként valósítják meg. A hiba megoldásának megvalósítását és tesztelését a megfelelő változtatás-megvalósító végzi egy kiadási csomag részeként. Független teszt megvalósítása A kiadási csomag végrehajtásra, a hiba megoldásának sikeressége pedig megerősítésre kerül Lezárják az ismert hiba és a VK feljegyzéseket. Az ismert hiba adatok két forráson keresztül juthatnak a hiba-felügyeleti rendszerbe. Ezek: A problémakezelési alrendszerben és az éles környezetben azonosításra és feljegyzésre kerülő probléma-feljegyzések, melyek az ismert hiba feljegyzések alapjává válhatnak, valamint a fejlesztési tevékenységekből eredő ismert hibák. 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 hibafelü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. 50

58 Infrastruktúra menedzsment Problémakezelés Éles működés Kiadás Alkalmazás fejlesztés és karbantartás Problémák Problémák Vizsgálatok és diagnózisok Éles ismert hiba adatbázis Fejlesztési ismert hiba adatbázis Vizsgálatok és diagnózisok Változtatási kérelmek Változáskezelés 14. ábra: A hiba-javítási ciklus az éles és a fejlesztési környezetben 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. 51

59 Infrastruktúra menedzsment Problémakezelés 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özkategó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 Vezetői információ 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 Megelőző problémakezelés 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 Eredményességi és hatékonysági szemlék 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 52

60 Infrastruktúra menedzsment Problémakezelés 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. 53

61 Infrastruktúra menedzsment Problémakezelés Erőfeszítések feljegyzése Személyzet kihasználtsága Tervezett támogatás Reagáló támogatás Rezsi Szolgáltatási minőség Átfogó szolgáltatási szint statisztikák A szolgáltatási hibák elemzése Nagygépes statisztikák Hálózati statisztikák Felhasználói berendezések statisztikái Problémakezelés Termék minőség Vásárolt termékek minősége Alkalmazási termékek minősége Hálózati termékek minősége A vásárolt termékek ismert hiba elemzése A vásárolt termékek megoldatlan problémáinak elemzése A problémakezelés (ill. támogatók) eredményessége Szolgáltatások visszaállítása Szállító válaszkészsége és javításai Kis beszerzésigényű berendezések Részleg válaszkészsége és javításai Kis rendszerek javítása Fejlesztett termékek minősége Fejlesztett termék megbízhatósági státusza Kiadási csomag státusza Termékek hibáinak megoldási státusza Tesztelés elôrehaladása Teszt-események elemzése Teszt probléma / hiba elemzés 15. ábra: Vezetői információk 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 54

62 Infrastruktúra menedzsment Problémakezelés 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: Annak ellenőrzése, hogy a jelentések az ütemezésnek megfelelően készülnek és kerülnek elemzésre. Reprezentatív esemény minta révén annak igazolása, hogy a szolgáltatásokban tapasztalt zavarok az előírt időtartamon belül és korrektül megoldásra kerülnek. Reprezentatív probléma-minta segítségével annak ellenőrzése, hogy ezeket helyesen és az előírt időtartamon belül diagnosztizálják. Reprezentatív ismert hiba minta révén igazolni, hogy a KE-ek engedélyezett változtatásával lettek megszüntetve, és az előírt időtartamon belül. Annak ellenőrzése, hogy minden eszkalációs küszöböt betartottak-e. Annak ellenőrzése, hogy minden feljegyzés helyes és teljes. Annak ellenőrzése, hogy a dokumentációt megfelelően karbantartják-e a módosításokat a problémakezelési funkció személyzete elterjeszti, az átvevők pedig alkalmazzák. A személyzeti képzés feljegyzések ellenőrzése A jövő tervezése 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. 55

63 4.2 A problémakezelés megvalósítása Infrastruktúra menedzsment Problémakezelés Tervezés A legtöbb informatikai szolgáltatásnak van valamilyen formájú esemény-kezelő rendszere. Azonban az esetek többségében ez csupán imitált tevékenység, ami messze nem kielégítő szolgáltatást eredményez a felhasználók számára. Az informatikai infrastruktúra menedzsment egy fegyelmezett megközelítést nyújt a problémakezeléshez. Személyzeti kérdések Ha elhatározásra került, hogy a problémakezelés az informatikai vezetés felelősségi körébe tartozik, ki kell nevezni a probléma-menedzsert. Ezt követően sor kerülhet a funkció nagyvonalú tervezésére és a személyzet iránti igény becslésére. A problémakezelési funkcióhoz szükséges létszám jelentősen változhat részlegről részlegre. Függ a részleg méretétől, komplexitásától és megbízhatóságától, valamint függ olyan más tényezőktől is, mint a rendszerfejlesztés és a karbantartás kiterjedtsége, hatóköre. A már kinevezett probléma-menedzser és az informatikai szolgáltatási vezetőnek formális és gyakorlatias tervezést kell végrehajtania, amelynek kezdeti fázisai: A problémakezelés szerepének meghatározása Figyelemfelkeltő kampány Döntés a problémakezelés szervezeti struktúrájáról Taktikák tervezése a problémakezelési rendszer kialakítására A problémakezelés funkciót kifejlesztő projekt kezdeményezése A problémakezelés szerepének meghatározása Meg kell határozni a problémakezelés funkció szerepét az informatikai szervezeti egységben. Az átfogó cél az informatikai szolgáltatások minőségének maximalizálása az elromlott dolgok megjavításával, a hibák újbóli előfordulásának megelőzésével. E cél elérése érdekében a problémakezelésnek egyszerre kell reagáló és megelőző jelleggel működnie. Összefoglalva, a problémakezelés csoport felelős a következőkért: Reagáló eljárások: o a számítógépes tevékenységek, a hálózat-felügyelet és a Gyorssegély-szolgálat támogatása az események megoldásában, amikor csak szükséges, o a problémák meghatározása (az események kiinduló oka) és ehhez kapcsolódóan a megoldásuk vagy ismert hiba státuszba való konverziójuk, o az ismert hibák felügyelete és az elhárítási tevékenység koordinációja. Megelőző eljárások: o a rendszerek vagy szolgáltatások változtatásának kezdeményezése az egyes események előfordulásának vagy újbóli megjelenésének megelőzése céljából, o az esemény és a probléma elemző jelentések szemlézése trendek azonosítása és a lehetséges problémáknak még előfordulásuk előtti azonosítása érdekében, o összetett rendszerben annak megakadályozása, hogy az egyik rendszerben megjelenő probléma megjelenjék a többiben is. A problémakezelés megelőző tevékenysége történeti adatokat kíván, hogy a trendelemzés és az előrejelzés révén lehetővé tegye a potenciális és az előrelátható problémák azonosítását. Ebbe beletartozik az is, hogy meg kell előzni a problémák átterjedését az egyik rendszerről a másikra. Figyelemfelkeltő kampány A probléma-menedzsernek figyelemfelkeltő kampányt kell megterveznie és végrehajtania, hogy segítse a problémakezelési funkció általános elfogadását és informálja az érintetteket arról, hogyan és miképp befolyásolja munkájukat a problémakezelés. Szemináriumok, személyes találkozók, körlevelek használhatók erre a célra. Fontos tudatosítani, hogy a problémakezelést azért hozzák 56

64 Infrastruktúra menedzsment Problémakezelés létre, hogy támogassa a hatékonyan előállított és minőségi informatikai szolgáltatásokat. E kampányt már a korai szakaszban el kell kezdeni, és folytatni a funkció implementációjáig, vagy még azon is túl. Felügyeleti részlegek Nagyszámítógépek Hálózatok Végfelhasználók Számítógép üzemeltetés Hálózat felügyelet Események Események Események N Szükséges-e segítség N Szükséges-e segítség N Szükséges-e segítség I I I Problémakezelés Esemény felügyelet (második támogatási szint) Gyorssegélyszolgálat Problémafelügyelet Hiba felügyelet További támogatás Speciális támogató részlegek Rendszer támogatás Hálózati specialisták Alkalmazási specialisták Szállítók támogató személyzete 16. ábra: Problémakezelés és támogatás 57

65 Infrastruktúra menedzsment Problémakezelés Döntés a problémakezelés szervezeti struktúrájáról Probléma - menedzser Megelôzô funkciók Probléma / hiba felügyelet Esemény - támogatás 17. ábra: Centralizált problémakezelés A problémakezelési funkció szervezeti struktúrája függ a környezet felépítésétől. Centralizált üzemeltetés esetén, ahol lényegében egyetlen adat-központ van, ott egyetlen csoport ajánlott. Többelemű adat-központ esetén vagy elosztott jellegű szituációban számos lehetőség van. A figyelembe veendő legfőbb tényező az, hogy vajon a problémakezelés személyzetét szétosszák valamennyi adatközpont részleghez, vagy minimalizálják a kihelyezett személyzet iránti igényt. Figyelembe veendő tényezők: A távoli központok és szolgáltatások mérete és komplexitása, és szervezeti fontosságuk. A távoli számítógépes rendszerek becsült megbízhatósága, a távoli részlegen használni tervezett alkalmazások stabilitása. A távoli központok fölötti centralizált felügyelet lehetőségének kifinomultsága és eredményessége. A távoli központok biztonsági követelményei. A lokális számítógépes üzemeltetés és a hálózat felügyelet személyzettel való ellátottsága. A távoli részleg személyzetére háruló munkateher és a kielégítő munkakör lehetősége. A felhasználói vezetéssel kialakított viszony jellege (politikai klímája). A képzett problémakezelési személyzet elérhetősége. Ez a szituáció nem egyedi, és más területeken is megjelenik (mint pl. a gyorssegély-szolgálatnál). Az informatikai vezetésnek szüksége van egy kezdeti képre arról, hogy kell a problémakezelési funkciót szervezni és egy integrált problémakezelési rendszerré alakítani, a problémakezelési személyzet, a felügyeleti személyzet és a támogató csoportok között megosztva a feladatokat. Előzetes tervek és taktikák kidolgozása a problémakezelés kialakításához A probléma-menedzsernek meg kell bizonyosodnia arról, hogy elegendő pénz áll rendelkezésre a személyzet, a szoftver, a berendezések és a kapcsolódó fejlesztések költségeinek fedezésére. Mivel a problémakezelés négy nagy alrendszerből épül fel, ezek kifejlesztése és megvalósítása fokozatosan történhet. Azonban más Információtechnológiai Infrastruktúra Menedzsment funkciók, mint a konfigurációkezelés és a változáskezelés integrálódnak a problémakezelés folyamatába, és ezért a tervezéskor figyelembe kell venni őket. Meglévő részlegek Nincs egyszerű megoldás azoknál a már meglévő részlegeknél, ahol szükség van az új rendszerre való átalakításra, de közben további terheket jelent a meglévő eljárások folytatása. A meglévő gyengeségek határozzák meg a prioritásokat. A legrosszabb (helyzetű) területek kapnak elsőbbséget. 58

66 Infrastruktúra menedzsment Problémakezelés Pl. ha a rosszul ellátott változtatási eljárások és a silány üzembe helyezés eredményeként gyatra szolgáltatásban részesülnek a felhasználók, ez válik elsődleges fontosságú területté. A szűk keresztmetszetek kialakulásának elkerülése érdekében fokozatos megközelítés ajánlott. Hangsúlyt kell helyezni a kompatibilitás fenntartására és az integrációra valamennyi megvalósítási és szemle fázisban. 1. fázis A felhasználók támogatását, az események, problémák és az ismert hibák kezelését szolgáló meglévő, napi gyakorlatot jelentő eljárások felmérésével és szemléjével kell kezdeni. Meg kell vizsgálni, milyen támogató eszközöket használnak? Kielégítő-e a más informatikai infrastruktúra menedzsment funkciókkal való kapcsolat? Mit kell megtartani, és mit megszüntetni (erősségek-gyengeségek)? 2. fázis Meg kell tervezni a gyorssegély-szolgálat megvalósítását a megfelelő eszközökkel. Ki kell alakítani a konfigurációkezelés által kezelt nyilvántartásokat az esemény-felügyelet és a változáskezelés számára. Létre kell hozni a problémakezelés esemény-felügyeleti részét, és meg kell határozni a specialista támogatási csoport felelősségi körét. 3. fázis Az esemény-felügyeleti rendszert ki kell terjeszteni, és lehetővé kell tenni a számítógépes üzemeltetésnek és a hálózat-felügyeletnek az események közvetlen naplózását. 4. fázis Ki kell alakítani a vezetői jelentéseket készítő rendszert. 5. fázis Meg kell valósítani a problémakezelés, a konfigurációkezelés és a vezetői jelentéskészítés egyensúlyát. A megelőző jellegű tevékenységeket akkor lehet kialakítani, ha a problémakezelés személyzetére már nem rónak túlzott terheket a reagáló jellegű feladatok, a szolgáltatások minőségének javulása következtében. E fokozatos megközelítés révén csökken az érintett funkciókra gyakorolt többletteher, azonban növekszik a szükséges idő is a simább fejlesztés ellenére. Zöldmezős részlegek A zöldmezős (új) részleg előnye az, hogy az informatikai infrastruktúra menedzsment összetevőinek teljesen integrált rendszere építhető ki a meglévő szolgáltatások kezelésének terhe nélkül. Ha nem lehetséges a problémakezelés kialakítása a gyorssegély-szolgálat, a változáskezelés és a konfigurációkezelés kifejlesztésével együtt, akkor a prioritást a problémák és változások egyedüli kezelésének kell adni. Hangsúlyozottan ajánljuk, hogy az éles felhasználói szolgáltatások elindításakor valamennyi informatikai infrastruktúra menedzsment funkció hatásos implementációja álljon rendelkezésre. A funkciót kifejlesztő projekt kezdeményezése A problémakezelés kifejlesztését és megvalósítását teljesen meghatározott projektként kell végrehajtani. Javasoljuk a PRINCE-t (a PRINCE projekt menedzsment módszertan, lásd ITB 5. számú ajánlás) felhasználni, formális átvételi eljárásokkal minden szakaszban. Projekt követelményjegyzéket kell készíteni, amely tartalmazza a megvalósíthatósági tanulmányt és a projekt fázisokat. Meg kell határozni a terjedelmet és a függőségeket. Ajánlatos egy számítógép-alapú problémakezelési rendszer szoftvercsomag használata. A projektnek a következő fázisai lesznek: Megvalósíthatósági tanulmány: A rendszer követelmények, a felhasználói igények, a szoftvercsomag-alapú megoldások, a költségek és hasznok magas szintű értékelése szükséges az ajánlott megközelítés megfogalmazásához. A kezdeményezési fázis: A projekt költségeinek és erőforrásainak kiszámításához és allokációjához átfogó szintű követelmény tervek és technikai tervek szükségesek, megfelelő részletezettséggel. A specifikációs fázis: A problémakezelési rendszerhez szükséges felhasználói specifikációt és az elfogadási kritériumokat részletesen le kell írni. 59

67 Infrastruktúra menedzsment Problémakezelés Termékértékelés és rendszerfejlesztés: Értékelni kell az alternatív szoftvercsomagokat, és meg kell tervezni a testre szabott és a kisegítő jellemzőket. A rendszer és az eljárások fejlesztése: Ki kell fejleszteni a felhasználóra szabott és a kisegítő jellemzőket, meg kell tervezni a dokumentációt és a tesztelést. Megvalósítás: Elő kell készíteni a működési környezetet, az átvételi tesztelést, majd az éles üzembe helyezést. Megvalósítás utáni szemle: El kell végezni a rendszer teljesítményének, eredményességének és megbízhatóságának formális szemléjét. Működtetés és menedzsment (a projekt után): Gondoskodni kell a problémakezelés rendszer folyamatos működtetéséről és vezetéséről, hogy a kitűzött (a hivatkozási alapban rögzített) célok teljesüljenek. Időzítés A problémakezelés bevezetési prioritásának meghatározásához meglévő részleg esetében meg kell becsülni az informatikai szolgáltatási tevékenység elfogadott szintjeit a következő tényezők felhasználásával: Az informatikai szolgáltatások minősége (az események számával mérve). A szolgáltatási minőség trendjei. Az ismert hibák azonosításának könnyűsége. A felügyelő személyzet (számítógépes üzemeltetés és a hálózat felügyelete, gyorssegélyszolgálat) által megoldott problémák aránya az összeshez képest. A tervezett feladatokon és a váratlan események elhárításán (esemény-felügyelet) dolgozó személyzet aránya. Vezetői információ elérhetősége a hibák okairól és súlyosságairól. A szolgáltatásokat támogató termékek (szoftver és hardver) minősége. Ha ez az értékelés az eredményesség alacsony szintjét jelzi, a problémakezelés bevezetésének magas prioritást kell kapnia. Egyébként általában törekedni kell a minél hamarabb való bevezetésére. Zöldmezős részlegeken a problémakezelés kifejlesztése és megvalósítása az új informatikai tevékenységek kialakításának integráns részét kell képezze. A megelőzés a legjobb gyógyszer! Figyelmet kell fordítani a funkció kapcsolódásaira is. A problémakezelés az egyik fő kezdeményezője az informatikai infrastruktúra változtatásainak, számos változtatási kérelmet (VK) nyújt be. Emiatt fontos a jó kapcsolat a változtatáskezeléssel, mivel a nem megfelelően felügyelt változtatáskezelési eljárások növelhetik a kezelendő problémák megjelenésének kockázatát. A konfigurációkezelés látja el a problémakezelés eljárásait (alfunkcióit) információval a problémák, ismert hibák okozójaként azonosított konfigurációs elemekről (KE). A problémakezelés az alapja a rendelkezésre-állás menedzsmentnek is, mivel kezeli a megbízhatatlanságot és nélkülözhetetlen statisztikákat szolgáltat. A problémakezelésnek a Szolgáltatási Szint Megállapodások elfogadott szolgáltatási szintjeinek biztosításában is fontos szerepe van. Emiatt fontos, hogy a tervezés során a már meglévő funkciókhoz igazodjunk, illetve ajánlott valamennyi kapcsolódó funkció kialakítása, hogy a problémakezelésből fakadó hasznok teljes mértékben kiaknázhatóak legyenek Megvalósítás Az előkészítés és a tervezés végeztével a feladat e tervek által egy eredményesen működő problémakezelési rendszer megvalósítása. Az esemény-felügyelet alrendszer a gyorssegély-szolgálat bevezetésének részét képezi. Mi a rendszer és az eljárások szempontjaira összpontosítunk. A problémakezelési rendszer fejlesztése A következő tevékenységek szükségesek ebben a fázisban: A problémakezelési eszköz beszerzése és üzembe helyezése. 60

68 Infrastruktúra menedzsment Problémakezelés A képernyő és jelentési formátumok igényekre szabása. Az egyedi rutinok kifejlesztése. A kódolási rendszer specifikálása. A Konfigurációkezelési Adatbázis (KKAB) létrehozása amennyiben még nem elérhető. A dokumentáció előkészítése. A rendszer funkcióinak és teljesítményének tesztelése. A problémakezelési eszközök beszerzése és üzembe helyezése A kiválasztott problémakezelési rendszer szoftver üzembe helyezése és tesztelése érdekében megfelelő időben kell a rendeléseket feladni. Még a tervezési fázisban szükséges lehet némi berendezésre (számítógépre). Nagyon valószínű, hogy hardver beszerzés és szoftverfejlesztési munka szükséges a problémakezelés működtetése érdekében. A szállítás esetleges hosszú teljesítési ideje miatt a rendelés feladását ajánlatos a korai időszakban elvégezni. A felszerelés kiegészítésre, bővítésre szorulhat, és további informatikai infrastruktúra elemek lehetnek szükségesek a problémakezelési funkció számára, amikor az működni kezd. A képernyő és jelentési formátumok kialakítása A tervezési specifikáció követelményei szerint meg kell valósítani minden változtatást az eszközökön. Törekedni kell arra, hogy az ilyen testre szabási tevékenységet minimumon tartsuk, és az olyan jellemzők megvalósítására kell koncentrálni, mint az automatikus mezőfeltöltés és a nem kívánt vagy szükségtelen mezők és adatok törlése. Ha egy általános célú terméket választottunk, ez a testre szabás magában foglalja a kódfejlesztést és a rendszer-paraméterek beállítását is. Az egyedi rutinok fejlesztése Ki kell fejleszteni minden szükséges rutint, amellyel a megkívánt funkciók elláthatók, de az eszközök nem nyújtják őket. Ezek a rutinok lehetnek, pl. adatbázis-beolvasó és konvertáló szolgáltatások, vagy kapcsolófelületek (interfészek) más informatikai infrastruktúra menedzsment rendszerekhez, illetve rendszer-karbantartási szolgáltatások. A kódolási rendszerek specifikálása Egyetértésre kell jutni a többi érintett féllel (pl. a gyorssegély-szolgálattal, a speciális támogató csoportokkal, a konfigurációs menedzserrel, a számítógép működési és hálózat-felügyelettel) a probléma/hiba-felügyelet által alkalmazott összes kódolási rendszerek struktúrájáról. Két kódolási rendszer feltétlenül szükséges. Az egyik a probléma besorolási kód, ami azonosítja a problémák/ismert hibák okait. E kód fő célja, hogy lehetővé tegye a problémáknak és okaiknak az elemzését, ezért a kód kialakításánál számításba kell venni a később megkövetelt jelentéseket is. Megfontolandó egy strukturált kód használata, amely lehetővé teszi az elemzést különböző részletezettségi szinteken. Ez a fajta kódolási rendszer struktúrájában hasonló az eseménykódolásban alkalmazotthoz, de a finomabb bontás a hibás KE precízebb azonosítását teszi lehetővé. A másik kódolási rendszer a súlyosságot méri, megmutatja valamennyi probléma hatását az informatikai szolgáltatásokra. A súlyossági kód kigondolásával párhuzamosan eszkalációs eljárásrendet kell kialakítani valamennyi súlyossági szinthez, irányelvként használva a szolgáltatási szint szerződésben elfogadott és definiált tervezett hibaelhárítási időket. A Konfigurációkezelési Adatbázis létrehozása Ha a rendszer-specifikáció része egy interfész a KKAB-hoz, ki kell fejleszteni azt. Ha nincs KKAB, gondoskodni kell róla, hogy a konfigurációs menedzser létrehozza kézi adatgyűjtéssel vagy a meglévő forrásokból való konverzióval. A dokumentáció előkészítése Felhasználva a termékértékelési és rendszertervezési fázisból eredő dokumentáció-tervezési specifikációt, elő kell készíteni és engedélyeztetni minden rendszer-dokumentációt. Ebbe beletartoznak a működtetési kézikönyvek és a rendszertervezési specifikációk módosításai. A rendszer funkcióinak és teljesítményének tesztelése A rendszert alapos tesztelésnek kell alávetni, hangsúlyt helyezve az egyedi rutinokra és a rendszer interfészekre. Nem szabad megfeledkezni a rendszer adminisztrációs és a helyreállítási funkciókról. Teljesítmény tesztre van szükség a feldolgozási arány és a válaszidő célok eléréséhez. Amennyire csak 61

69 Infrastruktúra menedzsment Problémakezelés lehetséges, próbáljuk ki és ellenőrizzük a probléma/hiba adatokat felhasználó jelentéseket és ellenőrizzük ezek integritását is. A megvalósítás A megvalósítási fázis a következő fő tevékenységekből áll: A megvalósítási terv szemléje és finomítása. A személyzet képzése a rendszer koncepciójára és működtetésére. Átvételi teszt végzése. Üzembeállítás. A megvalósítási terv szemléje és finomítása Szemlét kell tartani a megvalósítási terv fölött a Rendszer- és eljárásfejlesztés fázis során szerzett tapasztalatok fényében, és a tapasztalatok alapján meghatározott minden szükséges változtatást is el kell végezni a tervben. A személyzet képzése a rendszer koncepciókra és a működtetésére A megvalósítási fázis során a problémakezelési funkció személyzetét ki kell képezni a problémakezelés és a hiba-felügyelet területére. Az alrendszert ritkábban használók, mint amilyenek a speciális felhasználói csoportok, további segítséget igényelnek mind ebben a kritikus periódusban, mind az éles működés első napjaiban. Meg kell bizonyosodni afelől, hogy a problémakezelés személyzetét idejében kiképezték arra, hogy biztosítani tudja ezt a szükséges további támogatást. Teljesítmény-átvételi teszt A befejezett problémakezelési rendszert részletes átvételi tesztnek kell alávetni, beleértve a rendszer funkciókat, interfészeket és a kapcsolódó berendezéseket és hálózatot. Ekkor kell tesztelni a mentést (back-up) és a katasztrófa-előkészületeket, valamint az eljárási dokumentációt. Az elfogadási kritériumot a specifikációs fázisban kell felvázolni, a teszt-specifikációt pedig a rendszertervezési fázisban kell kialakítani. Az elfogadási tesztelés lehetőséget ad a személyzet képzésére is. Az üzembe helyezés A probléma/hiba-felügyeleti alrendszerrel kapcsolatos rövid távú nehézségek valószínűleg nem befolyásolják közvetlenül a felhasználói szolgáltatásokat. Ezért az üzembe helyezés viszonylag alacsony kockázatú tevékenységnek tekinthető. Ilyen körülmények között nem szükséges az alrendszert a felváltásra kerülő korábbival párhuzamosan működtetni. Azonban, ha a régi rendszer létfontosságú vezetői információkat vagy szerződéses kihatásokkal járó, a szállító teljesítményét értékelő jelentéseket szolgáltat, megfontolandó a párhuzamos működtetés. Semmilyen esetben se vállaljunk olyan kockázatot, ami veszélyeztetheti a problémakezelés funkció hitelességét az informatikai szolgáltatás vezetés vagy a speciális támogató csoportok szemében. Meg kell gondolni a meglévő probléma/ismert hiba feljegyzések kézi rögzítését az új rendszerbe, különösen a probléma adatok esetében. Ha ez nem lehetséges az éles használat kezdete előtt, az adatok fokozatosan is felvihetők az éles működés során, a legnagyobb súlyosságú problémákkal kezdve. Ha a meglévő adatok elektronikus formában kerültek tárolásra, egy átalakító rutin alkalmazása megfontolandó. Nyilvánosságra kell hozni egy részletes üzembe helyezési ütemtervet, és meg kell bizonyosodni arról, hogy minden érintett tudatában van az eseményeknek. Ki kell választani egy napot és egy időpontot, ami a legkényelmesebb és általánosan alkalmas, mint amilyen egy csúcsidőszakon kívüli periódus. Az éles használat első szakaszában alaposan figyelni kell a rendszert és a személyzet eredményességét, és meg kell tenni minden szükséges korrekciót a nehézségek megszüntetésére. Megvalósítás utáni szemle és audit Az üzembe helyezést követően amint lehetséges, végre kell hajtani a projekt szemléjét. Meg kell vizsgálni, hogy milyen volt a projekt lefolyása, időben befejeződött-e, túllépte-e a költségvetést, milyenek a tapasztalatok. Szükség van egy formális megvalósítás utáni szemlére. Ebben a következőket kell megvizsgálni: A szükségletek és a realitás egyeztetése sikerült-e a meghatározott követelményeknek megfelelő rendszert létrehozni, különös tekintettel a teljesítményre. 62

70 Infrastruktúra menedzsment Problémakezelés A tevékenységi szintek összehasonlítása az előrejelzésekkel a munka volumene és a személyzet létszáma összevethető-e az előrejelzésekkel? Az emberi összetevő értékelése milyen a teljesítmény és milyen érzésekkel használják a rendszert? A hatékonysági és eredményességi mérőszámok szemléje a tényleges mértékek hogy viszonyulnak a célokhoz? Az elért hasznok meghatározása. Összevetni a tényleges és a tervezett szerepet sikeresen ellátja-e a problémakezelés a neki szánt szerepet? Problémák A problémakezelés funkció bevezetésével kapcsolatban problémák is jelentkezhetnek, törekedni kell ezek elkerülésére: A felhasználók közvetlenül fordulnak a problémakezeléshez illetve a specialista csoportokhoz, a gyorssegély-szolgálat megkerülésével a problémakezelés csak az engedélyezett forrásokból fogadhat el kéréseket. Korlátozott az integráció az esemény/probléma/hiba felügyeleti alrendszerek között ha az egyes feljegyzések között nem képesek kapcsolatot teremteni, akkor elveszhetnek a problémakezelésből fakadó előnyök. Az éles és a fejlesztői környezet rendszere inkompatibilis ez megnehezíti az ismert hibák átadását a két környezet között. A személyzet elkötelezettségének hiánya ellenállás lehetséges, főleg a normál szolgáltatási időszakon túl, és minél informálisabb volt a korábbi gyakorlat, annál nagyobb az ellenállás valószínűsége. Ennek elkerülése végett az érintetteket minél jobban be kell vonni a tervezésbe, tájékoztatni kell őket és a személyes meggyőzés lehetőségeit is igénybe kell venni. 4.3 Ajánlott irodalom Problem Management. IT Infrastructure Library. HMSO ISBN A témával foglalkozó Web-oldalak: Eszközök:

71 5. Változáskezelés A változás az élet természetes velejárója. Az informatikai szolgáltatásoknak is változniuk kell a szervezeti működésben bekövetkező változások és a változó felhasználói követelmények nyomán. A szolgáltatás minőségét viszont meg kell őrizni a változtatások során. A minőség igényét a szervezetnek az információtechnológiától való függősége váltja ki. Minőség nélkül az összesített költségek magasabbak lennének, és a szervezet eredményessége és hatékonysága egészében tekintve kisebb. A változtatások hibáktól és helytelen döntésektől mentes megvalósításának képessége alapvetően fontos egy eredményes informatikai szolgáltató számára. A szervezeteknek tehát meg kell tanulniuk, hogyan kezeljék eredményesen és hatékonyan a változásokat. Ahogy a szervezetek egyre inkább függnek az informatikai szolgáltatásoktól, ahogy folytatódik a technológia gyors változása és terjedése, úgy növekszik az igény arra, hogy az informatika a követelményekkel lépést tartson. Ez a szükséglet elkerülhetetlenné teszi a változtatásokat a szolgáltatásokban és az infrastruktúrában, ami azonban egy bizonyos kiterjedtségi és bonyolultsági szinten túl a hagyományos módon követhetetlenné válik. Ennek következménye tapasztalhatjuk azt, hogy számos, jelenleg felismert problémát az informatikai szolgáltatás minőségében a közelmúltban az informatikai rendszereken végrehajtott változások okoznak. A változáskezelés mechanizmust ad az információtechnológiai infrastruktúrát érintő változtatások kezdeményezésének, megvalósításának és szemlézésének a felügyeletére és menedzselésére. Az informatikai szolgáltatások eredményes és hatékony nyújtásához szükséges a mélyreható változások kezelésének képessége. A változáskezelési funkció létéből származó hasznok közé tartozik: a változtatások kisebb hatást gyakorolnak az informatikai szolgáltatások minőségére és a szolgáltatási szint megállapodásokra, jobban ítélik meg a javasolt változtatások költségkihatásait, azon esetek száma csökken, melyeknél szükséges volt a változtatás előtti állapot visszaállítása; de a visszaállítás képessége szükség esetére megmarad, a változtatásokkal kapcsolatos, a vezetés érdeklődésére számot tartó adatok gyűjtésre kerülnek, a felhasználók termelékenysége javul (a kevesebb megszakítás miatt), az informatikai személyzet termelékenysége nő (nem kell szükségtelen változásokkal vesződniük), kialakul a számos változás nehézségek nélküli, egyidejű kezelésének képessége. A változáskezelés lényegében azt biztosítja, hogy a változásoknak az információtechnológiai szolgáltatások minőségére gyakorolt hatása minimális legyen a változások kezelésével kapcsolatos szabványosított eljárások betartatása által. 5.1 A változáskezeléshez kapcsolódó tevékenységek Változtatási kérelmeket (VK) sokféle okból nyújthatnak be egy szélesebb felhasználói közösség tagjai. Az informatikai infrastruktúra valamennyi részét érinthetik a kért változtatások: hardvert, szoftvert, telekommunikációs eszközöket, oktatást, informatikai infrastruktúra menedzsment eljárásokat, taktikai terveket, környező infrastruktúrát. A VK-k dokumentálására szabványos formalapokat vagy képernyőterveket kell kidolgozni. A lapok formáját lehet, hogy egyes számítógépes eszközök eleve megszabják. 64

72 Infrastruktúra menedzsment Változáskezelés Szerepek és feladatkörök a változáskezelésben Változásmenedzser Feltétlenül szükség van a változásmenedzser szerep nevesítésére és betöltésére, aki személyes felelősséggel bír a változtatásokkal kapcsolatos kérdések intézéséért. A változásmenedzser feladata: a változtatási kérelmek (VK) gyűjtése, naplózása, besorolása, szükség esetén visszautasítása, a Változásügyi Tanácsadó Testület (VTT, lásd később) tagjai számára a szükséges anyagok előkészítése az ülésekhez, a VTT ülések elnöklése, a változtatás kivitelezésében, tesztelésében és beüzemelésében érintett személyek és szervezetek közötti koordinálás, az üzembe helyezett változtatások szemlézése, a fel nem dolgozott VK-k figyelemmel kísérése, vezetői jelentések elkészítése. Ott, ahol a változáskezelési és konfigurációkezelési funkció együttműködik, a megfelelő szerepeket egyesíthetik. A Változásügyi Tanácsadó Testület Változásügyi Tanácsadó Testületet kell felállítani, amely felbecsüli minden egyes változtatás hatásait és erőforrásigényét. Általában az informatikai szolgáltató szervezeti egységnek, az informatikai alkalmazások fejlesztését végző szervezeti egységeknek és a rangidős felhasználóknak kell képviseltetniük magukat ebben a testületben, melyet a változásmenedzser elnököl. A testület tagjai legyenek: a változásmenedzser, a felhasználói menedzserek, a szervezeti vezetők, a felhasználói csoportok képviselői. Ezen túlmenően, az egyedi változástól függően részt vehetnek az alkalmazás fejlesztők/karbantartók, az informatikai szolgáltatás személyzete, az irodai szolgáltatást biztosító személyzet (ahol az informatikai változások az elhelyezést befolyásolhatják, avagy fordítva), a szerződéses partnerek képviselői. A Változásügyi Tanácsadó Testület Döntőbizottsága Halasztást nem tűrő változtatások esetében előfordulhat, hogy nehéznek bizonyul egy teljes körű VTT értekezletet összehívni. Ezért szükséges a VTT Döntőbizottság (VTTB) felállítása, amely a sürgős értékeléseket elvégzi. Ajánlatos, hogy a VTTB-nek legyen tagja a változásmenedzser, a problémamenedzser, a szolgáltatási szint menedzser és egy rangidős felhasználói menedzser (habár ezt rugalmasan kezelhetjük) A változáskezelés fő tevékenységei Változtatási kérelmek naplózása Minden egyes változtatási kérelmet naplózni kell, és egyedi azonosítóval kell ellátni (az időbeli sorrend szerint). A VK-k naplózását a konfigurációkezelési rendszer eszközeivel kell elvégezni, amely tartalmazza a konfigurációs elemeket, és lehetővé teszi változások egyéb komponensekre gyakorolt hatásainak könnyebb értékelését. Szabályzatba kell foglalni, hogy ki jogosult egy VK létrehozására, illetve a VK-hoz történő hozzáférésre. Kizárólag a változásmenedzser vagy a konfigurációmenedzser, vagy a hozzájuk tartozó személyzet törölhet egy VK-t. Egy probléma jelentés (PJ) megoldásaként benyújtott VK esetében hivatkozni kell a PJ azonosítójára, hogy kereszthivatkozások készítése lehetséges legyen. 65

73 Infrastruktúra menedzsment Változáskezelés A prioritások hozzárendelése Minden VK-hoz hozzá kell rendelni egy prioritási szintet, melyet a változtatást kezdeményezője és a változásmenedzser egyeztetett. A prioritások lehetővé teszik az erőforrások hozzárendelésének és a határidők megállapításának jobb megalapozását. Például: 0 Sürgős Számos felhasználó számára a szolgáltatás kieséhez, vagy súlyos használhatósági problémához vezet, vagy ezzel egyenértékű komoly gondot okoz. Azonnali beavatkozást igényel. Sürgősen össze kell hívni VTT vagy VTTB ülést. Az erőforrásokat azonnal hozzá kell rendelni az engedélyezett változtatás elvégzése érdekében. 1 Magas prioritású 2 Közepes prioritású 3 Alacsony prioritású Súlyosan érint néhány felhasználót, vagy hatást gyakorol a felhasználók széles rétegére. A legmagasabb prioritást kapja a VTT-beli előterjesztésben, illetve a változtatás kivitelezése, tesztelése és megvalósítási erőforrások hozzárendelése szempontjából. Nincs komoly kihatása, de javítása nem várhat a következő változat vagy módosítás kibocsátásáig. Közepes prioritást kap a VTT előterjesztésekben. A változtatás indokolt és szükséges, de tényleges kivitelezése várhat a következő ütemezett változat kibocsátásáig. Az erőforrásokat értelemszerűen kell hozzárendelni. A változtatási kérelmek osztályozása A változásmenedzsernek meg kell vizsgálnia minden kevéssé sürgős VK-t, és be kell őket sorolnia az alábbi három előre meghatározott kategória valamelyikébe. 1 Kis hatású 2 Közepes hatású 3 Alapvető hatású A változásmenedzsernek felhatalmazással (jogkörrel) kell rendelkeznie e változások ütemezésére, de elvégzésük tényét jelentenie kell a VTT-nek és az informatikai szolgáltatás vezetőségének. A VK-t be kell mutatni az informatikai vezetőnek a VTT ülésein történő megvitatásra. Minden kapcsolódó dokumentumot az értekezlet előtt el kell juttatni az érintettekhez. Egyeztetni kell az informatikai tervezési titkársággal (vagy ezt a szerepet ellátó szervezeti egységgel), vagy az informatikai döntőbizottsági szinttel, még mielőtt ütemezésre és megvalósításra kerülne a VTT útján. A VK-k többségének a fenti 1 és 2 kategória valamelyikébe kell esnie. A következő oldalon található 18. ábra írja le a változtatási kérelmek feldolgozásának folyamatát A kihatás és erőforrásigény felbecslése Az alábbi tényezőket kell figyelembe venni a VK-k kihatásának és erőforrásigényének felbecslése során az informatikai infrastruktúrára és a szolgáltatásra gyakorolt hatásokat (kapacitás és teljesítmény, megbízhatóság és rugalmasság, katasztrófa-elhárítási tervek, biztonság), az egyéb szolgáltatásokra gyakorolt hatásokat, melyek ugyanazt az informatikai infrastruktúrát veszik igénybe, a változtatás el nem végzésének a hatását, a változtatás elvégzéséhez szükséges erőforrások nagyságát, beleértve ebbe a járulékos költségeket, az igényelt személyzet számát és rendelkezésre állását, a szükséges időt, bármilyen új igényelt infrastruktúrát. 66

74 Infrastruktúra menedzsment Változáskezelés A VTT tagjainak saját véleményük alapján nyilatkozniuk kell, hogy támogatják-e a változtatás elvégzését, és elégedettek-e a hozzárendelt prioritásokkal. Meg kell jegyeznünk, hogy a VTT csupán tanácsadó testület és a végső döntést a változtatások engedélyezéséről konkrét személyeknek kell meghozniuk. 67

75 Infrastruktúra menedzsment Változáskezelés Elutasítva Változás menedzser A kérelmek megsz űrése Konfigurációs menedzser A VK kezdeti nyilvántartása Elfogadva Változás menedzser Kezdeti prioritás kiosztása Konfigurációs menedzser A nyilvántartás módosítása Igen Sürg ős Nem Változás menedzser Döntés a kategóriákról ld. 2. ábra Sürg ős eljárások Változás menedzser Változtatások engedélyezése és ütemezése, jelentés a VTT-nek 1. kategória 2. kategória Változás menedzser VK-k szétosztása a VTT tagoknak 3. kategória Változás menedzser Az elfogadott változtatások VTT elé terjesztése további intézkedések céljából VTT tagok A változtatás hatásának és er őforrásainak becslése, az engedély és prioritás megerôsítése, ütemezés lehet iteratív Konfigurációs menedzser A nyilvántartás módosítása a további menetrend kiadása Nem Engedély Igen Konfigurációs menedzser A nyilvántartás módosítása Változtatást megvalósító Változtatások felépítése, helyreállítási és tesztelési tervek kidolgozása Konfigurációs menedzser A nyilvántartás módosítása az elôrehaladási jelentéssel Kudarc Független tesztelő Teszt változtatása Siker Változás menedzser A változtatás kivitelezésének koordinálása Konfigurációs menedzser A nyilvántartás módosítása Konfigurációs menedzser A felhasználók értesítése, A nyilvántartás módosítása Működik Igen Nem Változtatást megvalósító Helyreállítási terv kivitelezése Konfigurációs menedzser Eltelt idô A nyilvántartás módosítása Változás menedzser A változtatás ellenôrzése Nem Siker Igen Zárás Start Konfigurációs menedzser A VK zárása Konfigurációs menedzser A nyilvántartás módosítása Bármely új VK hozzárendelése a régihez 18. ábra: A változtatások kezelése 68

76 Infrastruktúra menedzsment Változáskezelés A változtatás követése A változtatás kivitelezése A változásmenedzser koordinál a közvetlen vezetéssel a változtatások határidőre történő kivitelezése érdekében. A változásmenedzser addig nem bocsáthat egyetlen változtatást sem útjára, amíg a kellő dokumentációk, illetve az előző helyzetet visszaállítására szolgáló eljárások rendelkezésre nem állnak. Azért szükséges az előző állapotra történő visszaállás lehetővé tétele, mert a legalaposabb tesztelés és kivitelezés mellett is előfordulhat, hogy a változtatás kivitelezése után problematikus esemény lép fel. A változtatás tesztelése Minden egyes változtatást, ahol az lehetséges, alaposan tesztelni kell mielőtt még üzembe helyeznék, hogy elkerüljünk olyan változtatásokat, melyek az informatikai szolgáltatásokat hátrányosan érintenék. Ahol nem került sor teljes körű tesztelésre, ott különös figyelmet kell fordítani az üzembe helyezésre. A változtatás üzembe helyezése A változásmenedzser felelőssége annak biztosítása, hogy a változtatások az ütemterv szerint kerüljenek üzembe helyezésre. Ez lényegében koordinációs szerep, minthogy a tényleges megvalósítás mások felelőssége. A változtatások tényleges üzembe helyezését oly módon kell ütemezni, hogy minimális hatást gyakoroljon a szolgáltatásra. Előnyős lehet rendszeres, a felhasználókkal egyeztetett változtatási időpontok kijelölése. A változtatás szemléje Minden üzembe helyezett/elvégzett változtatást szemlézni kell egy előre meghatározott idő eltelte után. A szemlék célja annak megállapítása, hogy a változtatás a kívánt hatásokat eredményezte-e és elérte-e céljait, a felhasználók elégedettek-e az eredményekkel, nem léptek-e fel előre nem látott vagy nem kívánatos mellékhatások, vajon a terv szerinti erőforrásokat használták-e fel a változtatás elvégzése során. Minden egyes szemle megállapításait el kell juttatni a VTT-hez a követő intézkedések kijelölése érdekében (ha az szükséges). Halasztást nem tűrő változtatások A változtatások többségét előre kell látni, tervezni és a megfelelő időben benyújtani. Ugyanakkor előfordul, hogy egy halasztást nem tűrő változtatást nem lehet elkerülni. Ennélfogva ki kell alakítani a megfelelő eljárásokat az ilyen esetek kezelésére. Halasztást nem tűrő változtatások erőforrás- és hatásbecslése Ideális esetben a halasztást nem tűrő változtatások hatását és erőforrásigényét értékelni kellene a VTT-nek, de mint az előzőekben mondtuk, ez nem mindig lehetséges. Ha nincs idő egy teljes körű VTT ülés összehívására, akkor a VTTB-vel kell kapcsolatba lépni, és döntést kell arról hozni, hogy elvégezzék-e a változtatást. A VTTB minden tevékenységét és döntését fel kell jegyezni. Halasztást nem tűrő változtatás kivitelezése Ha egy halasztást nem tűrő változtatási kérelem esetében az a döntés született, hogy azt el kell végezni, akkor a változtatást feladatként ki kell adni a megfelelő műszaki csoportnak. A változásmenedzser feladata annak biztosítása, hogy elégséges személyzet és erőforrás álljon rendelkezésre, még akkor is, ha esetleg otthonról kell embereket berendelni munkára. A sürgősségtől függetlenül meg kell tervezni a kiinduló állapotra történő visszatérési eljárásokat. Halasztást nem tűrő változtatások tesztelése A változtatás sürgőssége ellenére ajánlatos tesztelni a módosított részeket. Teszteletlen változtatásokat nem szabad üzembe helyezni, hacsak arra a szükség nem kényszerít rá. Halasztást nem tűrő változtatás üzembe helyezése A változásmenedzsernek biztosítania kell, hogy kellő technikai támogatás álljon rendelkezésre az üzembe helyezés ideje alatt, különösen ha nem volt kellő mélységű a tesztelés, vagy egyáltalán nem is került sor rá. Amennyiben a változtatás nem küszöbölné ki a problémát, akkor szükséges lehet a 69

77 Infrastruktúra menedzsment Változáskezelés javítás javítása, és egy újabb üzembe helyezési kísérlet. Minden egyes kísérletet felügyelni, és dokumentálni (naplózni) kell. A naplók és feljegyzések teljessége A változásmenedzser felelős annak biztosításáért, hogy a naplóbejegyzések napra készen kövessék az eseményeket. Amennyiben a feljegyzések / naplóbejegyzések nem készülnének el a halasztást nem tűrő változtatás megtételekor, kézzel kell e feljegyzéseket vezetni, és addig meg kell őket őrizni, amíg a hivatalos bejegyzéseket visszamenőlegesen meg nem ejtik. A halasztást nem tűrő változtatások szemléje Ha a halasztást nem tűrő változtatás sikeresen üzembe helyezésre került, ugyanúgy kell kezelni, mint az egyéb változtatásokat, azaz szemlézni kell. Jelentés a vezetésnek Rendszeresen jelentést kell készíteni minden vezetési szint számára a változáskezelési funkció által elvégzett munkákról. A jelentésekben az adott szintű vezetés számára releváns összegzettségi szintű információk találhatók, különböző időtartamra összesítve. A jelentéstételnek egy elfogadható, ajánlott gyakorisága: az informatikai szolgáltatási menedzsernek hetente, az informatikai vezetőnek és rangidős felhasználói menedzsereknek havonta, az informatikai döntőbizottságnak negyedévenként. 70

78 Infrastruktúra menedzsment Változáskezelés Normális eljárásokból Változás menedzser Eltelt idô Konfigurációs menedzser A VK kezdeti nyilvántartása Sürgôs VTT vagy VTTD ülés öszehívása VTT vagy VTTD Az érintett erőforrások és a sürgősség felmérése Vissza a normális eljárásokhoz Nem Sürgős Igen Eltelt idô Változtatást megvalósító A változtatás sürg ős előkészítése Eltelt idô Konfigurációs menedzser nyilvántartás módosítása elôrehaladási jelentések Nincs Van id ő a tesztelésre? Van Független teszt Sürgős tesztelés Sikeres a teszt? Nem Igen Változás mendzser A változtatás kivitelezésének koordinálása Eltelt idô Konfigurációs menedzser nyilvántartás módosítása, a felhasználók értesítése Igen A változás m űködik Nem Változás mendzser Helyreállítási tervek koordinációja Változás mendzser A feljegyzések módosításának biztosítása Konfigurációs menedzser a nyilvántartás naprakész állapotra hozása. A dokumentáció rendszerezése Eltelt idô Változás menedzser A változtatás ellenôrzése Vissza a normális eljárásokhoz Nem Siker Igen Zárás Konfigurációs menedzser A VK lezárása A valós életben való megvalósítás 19. ábra: A halasztást nem tűrő változtatások kezelése 71

79 5.2 A változáskezelési funkció bevezetése A funkció megtervezése Infrastruktúra menedzsment Változáskezelés Változásmenedzser kinevezése Az első lépés egy változásmenedzser kinevezése kell legyen, akinek első feladata a változáskezelés funkció megvalósítási javaslatának elkészítése lesz. A változáskezelés szerepének meghatározása Az informatikai vezetésnek a változásmenedzserrel közösen kell meghatároznia, hogy mi legyen a változáskezelési funkció szerepe és terjedelme. Ajánlatos, hogy egy számítógépes támogató eszközre épülő rendszer használjanak, mintsem egy kézi, papíralapú rendszert (habár az utóbbi helyettesítő szerepet tölthet be hardver-kiesés esetén. Kívánatos, hogy a változtatások naplózása és megvalósítása egy integrált konfigurációkezelési rendszer felügyelete alatt történjen, és ennélfogva olyan támogató eszközre van szükség, ami egyszerre segíti a változás- és a konfigurációkezelési feladatok elvégzését. A funkció szerepének ismeretében kerülhet sor a szervezeti egységek létrehozására (VTT, VTTB). A változásmenedzsernek ki kell alakítania a változáskezelési funkció működési szabályzatát is. VTT értekezletek gyakoriságának meghatározása A VTT értekezleteinek a gyakorisága változni fog az üzembe helyezett rendszerek méretének és minőségének a függvényében. Ugyanakkor minél gyakrabban ülésezik e testület, annál kisebb a valószínűsége, hogy a VTT lesz a változáskezelési rendszer szűk keresztmetszete. Az értekezletek közötti idő ne haladja meg a 20 munkanapot, és egy értekezlet ne tartson tovább két óránál. A VTT értekezleteknek legyen egy szokásos napirendje, amelyben szerepelnie kell az alábbi napirendi pontoknak: VTT beavatkozás nélkül elvégzett változások, melyeket az eseményfelügyelet/problémakezelési funkció, illetve a változáskezelési funkció hajtatott végre, az értékelendő változtatási javaslatok, a már értékelt változtatási javaslatok, a már elvégzett változások szemléinek feljegyzései. Ajánlatos a változásokról egy előzetes értesítés küldése a VTT tagjainak, ez ugyanis lehetővé teszi az értékelés előkészítését. Időzítés, függőségek Ajánlatos, hogy azokon a helyeken, ahol még nem működik formális változáskezelési funkció, rögtön kezdjék el bevezetésének tervezését. Hozzávetőlegesen három hónapig tart a tervezés kezdetétől a bevezetés megkezdéséig tartó szakasz. Ez a folyamat hosszabb is lehet, amennyiben egy számítógépes támogató eszköz is beszerzésre és üzembe helyezésre kerül, különösen akkor, ha ez az eszköz integrálja a változás- és konfigurációkezelési tevékenységek támogatását. Ez a kézikönyv olyan változtatásokkal foglalkozik, melyek a működő informatikai infrastruktúrára vagy az alkalmazási szoftverekhez kapcsolódó szolgáltatásokra vonatkoznak. Nem érinti viszont a szervezet egyéb részeit érintő változtatásokat. Az informatikai infrastruktúrát érintő változtatásoknak lehet szélesebb körű kihatása a szervezet egyéb részeire, és fordítva is állhat a helyzet (szervezeti változások is okozhatnak jelentős infrastrukturális ill. szolgáltatásbeli változtatásokat). Ha az első eset fordulna elő, akkor a VK-t be kell mutatni az informatikai vezetőn keresztül aziinformatikai Tervezési Titkárságnak (ITTT), amely az informatikai döntőbizottság nevében a napi tevékenységeket végzi. Az ITTT fogja koordinálni a hatás és erőforrásigény becsléseket, és dönteni fog arról, hogy elvégezhetőke a változtatások. Fordítva, ha a szervezet más részeiben lezajló változtatások hatással bírnak az informatikai infrastruktúrára, akkor ezekkel a VTT foglalkozik majd. Ennek megfelelő eljárásokat kell tervezni a funkció bevezetéséhez. A változtatáskezelési funkció működésének kulcseleme a konfigurációkezelés funkció léte, amely lehetővé teszi a változtatások menedzselésének folyamatát. Egy konfigurációkezelési rendszer 72

80 Infrastruktúra menedzsment Változáskezelés létének az előnyei egyre nyilvánvalóbbá válnak majd, ahogy a kapcsolódási pontokat gyorsabban fel lehet majd ismerni A változáskezelési funkció kiépítése és validálása A változáskezelés bevezetésének feltételei A változásmenedzser lesz a felelős az új rendszer megvalósításának áttekintéséért. A rendszer megvalósításába csak akkor szabad belefogni, ha a kézi/eszközre alapuló, VK-kat dokumentáló rendszer kész, a VTT felállításra került, a VTT megfelelő szintű jogosítványokkal bír, mindenki tudomást szerzett az új eljárásokról és kiképzést kapott belőlük, a megvalósításra kijelölt időpont a lehető legkevesebb hatást gyakorolja az informatikai szolgáltatások minőségére. Megvalósítás utáni audit és szemlézés A változásmenedzsernek rendszeresen át kell tekintenie a változáskezelési feljegyzéseket, azért, hogy trendeket tudjon azonosítani, és hogy lehetővé tegye a változáskezelési rendszerben rejlő bármely probléma vagy hatékonytalanság felfedését. Vizsgálandó: a VK-k száma, az elutasított VK-k száma, a megvalósított változtatások száma, azon változtatások száma, melyeket vissza kellett vonni (azaz helyre kellett állítani az eredeti állapotot a változtatás elvégzése után), a sikertelen változtatások száma, a változtatási naplók. Az eredményesség és hatékonyság szemlézése Amint a változásmenedzsernek figyelemmel kell követnie a változáskezelési feljegyzéseket, hasonlóképpen kell az informatikai szolgáltatási menedzsernek rendszeresen legalább hathavonként szemléznie a funkciót eredményessége és hatékonysága szempontjából. Az első szemlére röviddel a megvalósítás után kerüljön sor annak megállapítása végett, hogy a megvalósítási terveket helyesen hajtották-e végre, és a rendszer az eredeti szándékoknak megfelelően működik-e. A szemlének ki kell mutatnia: az eredetileg (esetleg) gyenge változáskezelésnek az informatikai szolgáltatási minőségre gyakorolt kedvezőtlen hatását, csökkenést az elvégzett változtatásokkal kapcsolatos problémák számában, csökkenést a változtatás utáni kényszerű helyreállítások számában, csökkenést a halaszthatatlan változtatások számában, jogosulatlan (engedély nélküli) változtatások előfordulásának hiányát, kevesebb eltérést az ütemtervek és a változtatások tényleges megvalósítása között, azt, hogy nincsenek magas prioritású VK-k várólistán, csökkenést a VK várólisták méretében, pontos erőforrásigény becslést, a VK-k és az elvégzett változtatások rendszeres szemlézését, olyan VK-ek sikeres megvalósítását, melyek pozitív hatást gyakorolnak a szervezetre, az indokolatlanul elutasított VK-knak alacsony számát. 73

81 Infrastruktúra menedzsment Változáskezelés Az egyezőség auditálása Egyes szervezetek esetleg szükségesnek tarthatják a változáskezelési funkció és az eljárások egyezőségének az auditálását. Ezt az auditot évente legalább egyszer végre kell hajtani. Az alábbiakat kell megvizsgálni: véletlenszerűen választott VK-kat, változtatási feljegyzéseket, emlékeztetőket VTT értekezletekről, változtatási ütemterveket, véletlenszerűen választott VK és kivitelezési feljegyzéseket. Ellenőrizni kell, hogy minden VK megfelelően feljegyzésre, értékelésre került és megfelelő tevékenységeket vont maga után, a változtatási ütemterveket betartották, a VTT ülésein felvetett összes esettel foglalkoztak és megoldották őket, minden változtatási szemlét időben tartottak meg, minden dokumentáció pontos, naprakész és teljes Problémák A változáskezelési rendszer bevezetése és működtetése során rendellenességek, problémák is felléphetnek, mint például: A funkció bevezetésének erőforrásigényeit (pénz, személyzet, idő) alábecsülhetik, és/vagy nem bocsátják rendelkezésre. A szervezet tagjai nem tartják be a változáskezelési eljárásokat. Külső, megbízott szerződéses partnerek nem tartják be az eljárásokat. A VTT tagjai nem képesek, vagy nem akarnak a felterjesztett VK-kal foglalkozni (nem azonosulnak a szerepükkel). A változáskezelési funkció adatait papíron vezetik, ami körülményesnek és szűk keresztmetszetnek bizonyulhat. A halasztást nem tűrő változtatások egy részéről nem kerül információ a feljegyzések közé. A konfigurációkezelés, a gyorssegélyszolgálat és a változáskezelés támogató eszközei között nem lehet, vagy csak körülményesen lehet kapcsolatot teremteni. Ha a funkció hitelét veszti, sokkal nehezebb lesz újra bevezetni! 5.3 Ajánlott irodalom Change Management. IT Infrastructure Library. HMSO nd ed. ISBN A témával foglalkozó Web-oldalak: Szoftverek:

82 6. Szoftver felügyelet és terítés Ahogy a szervezetek egyre inkább függésbe kerülnek az informatikától, számítógépes szoftvereiknek eredményes felügyelete és biztonsága egyre nagyobb fontosságot nyer. A szervezeteknek képessé kell válniuk arra, hogy az informatikai szolgáltatások minőségének feláldozása nélkül tudják kezelni a rendkívül gyakori szoftver változásokat és fejlesztéseket. A szoftvereket sok esetben számos, földrajzilag elszórt helyszínen alkalmazzák, és ezeket a szoftvereket eredményes és gazdaságos módon kell felügyelni. A szoftver felügyelet és terítés (SzFT) funkció kialakítása révén az informatikai szolgáltató egység képessé válik ennek a felügyeletnek az ellátására, és emellett biztosítottá válik a szervezet egyik létfontosságú erőforrásának védelme és integritása. A szoftver felügyelet és terítés (SzFT) a konfigurációkezelés lényeges része. A konfigurációkezelés feljegyzései, melyek a Konfigurációkezelési Adatbázisban (KKAB) kerülnek tárolásra, leírják az informatikai infrastruktúra összetételét és környezetét, beleértve ebbe a szoftver elemek és dokumentációk tervbe vett vagy megvalósított változtatásait is. A SzFT a konfigurációkezelés keretében vagy annak alárendelten felelős a szoftver elemek fizikai tárolásáért, terítéséért és üzembe helyezéséért. A SzFT biztosítja, hogy csak megfelelően kibocsátott és engedélyezett szoftver verziókat vegyenek használatba. E cél elérése érdekében a SzFT felhasználja a Hiteles Szoftver Könyvtárat (röviden: HSzK), amely egy biztonságos szoftver könyvtár, ahol a szoftver konfigurációs elemek (KE) valamennyi verziója tárolásra kerül, akár a fejlesztéstől, akár egy szállítótól vették át. Ezek a KE-ek a HSzK-ban hiteles (definitív), minőségileg ellenőrzött formában találhatók, amelyből a szoftver-kiadások összeállításra, terítésre és üzembe helyezésre kerülnek. Minden szervezetnek őriznie és menedzselnie kell informatikai eszközeit, amelyek szükségesek a szervezet tevékenységének ellátásához. A számítógépes szoftvereket néha nem kezelik igazi, megfogható eszközként, vagyontárgyként. A felügyelet emiatt gyakran laza. Azonban eredményesen és hatékonyan felügyelt szoftverek nélkül a szervezet tevékenysége károsodik, függetlenül a többi informatikai szolgáltatás eredményességétől. A szoftverek könnyen másolhatók és továbbíthatók, egy hozzáértő könnyen módosíthatja őket. Az elosztott rendszerek felé mutató jelenlegi trendek miatt ugyanannak a szoftvernek számos kópiája kerül kiadásra több helyszínre, gyakorta kevés műszaki ismerettel rendelkező felhasználók kezébe. E folyamatokat feltétlenül felügyelni kell, hogy biztosíthassuk az informatikai zökkenőmentes és eredményes alkalmazását a szervezetben. A beszerzett szoftverekhez gyakran jogok és kötelezettségek társulnak, például karbantartási és szerzői jogból adódó (copyright) kötelezettségek. A SzFT segít a szervezetnek e jogok legelőnyösebb felhasználásában, és a kötelezettségek tiszteletben tartásában. Ezeken túl, a PC alapú szoftverek használatának terjedésével, és a hozzájuk kapcsolódó számítógépes vírusok fertőzésének lehetőségével a központi felügyelet egyre fontosabbá válik az informatikai környezet védelmében. A SzFT bevezetésével számos haszon származik: A használt szoftverek jó minőségűek, eredményes tesztelésnek lesznek alávetve, és megfelelő változtatáskezelési technikák szerint felügyelik fejlesztésüket, módosításukat, bevezetésüket. A szoftverek kiadása az éles használatba ellenőrzött módon, a hibák minimálisra csökkentésével történik. A szervezet szoftver eszközeit megfelelően és biztonságosan tárolják. Kialakul az a képesség, hogy a szoftverek nagy arányú/mennyiségű változtatása megvalósítható az éles rendszerekben anélkül, hogy a szolgáltatások színvonalát károsan befolyásolnánk. Távol lévő részlegekben használt szoftverek eredményes és gazdaságos felügyeletét teszi lehetővé egyetlen pontból. Csökkenti a szoftverek illegális használatának vagy másolásának valószínűségét. 75

83 Infrastruktúra menedzsment Szoftver felügyelet és terítés A rendszerben könnyebben megtalálhatóak a szoftverek rossz verziói vagy engedélyezetlen másolatai. A SzFT felelős a következőkért: A vezetés által engedélyezett szoftverek tárolásáért mind a centralizált, mind az elosztott rendszerek számára. A szoftverek kiadásáért az éles környezetbe. A szoftverek távoli helyekre történő terítéséért. A szoftverekhez kapcsolódó szolgáltatások üzembe helyezéséért. Ezek a funkciók vonatkoznak a belső készítésű programokra, a beszerzett alkalmazásokra és segédszoftverekre, a szállítók fejlesztette rendszerekre és PC szoftver csomagokra egyaránt. A SzFT kezeli mindezeket a beszerzéstől vagy fejlesztéstől a tesztelésen át az éles használatig. A SzFT a konfigurációkezelés része, de míg a konfigurációkezelés az informatikai infrastruktúra logikai modelljének fenntartását végzi a konfigurációkezelési adatbázis (KKAB) segítségével, addig a SzFT a szoftverek fizikai kontrolljával, terítésével és üzembe helyezésével foglalkozik, a konfigurációkezelés felügyelete alatt. Amikor tehát új szoftver, vagy meglévő szoftver új verziója kerül a HSzK-ba, akkor a KKAB-ban is tárolni kell a megfelelő adatokat. A változtatáskezelés funkcióval és a folyamattal magával a SzFT vezetője tartja a kapcsolatot, hiszen tagja a Változásügyi Tanácsadó Testületnek (VTT), és résztvevője a kibocsátási irányelvek, politikák kialakítási folyamatának. Fontos, hogy a problémakezelés is információkat kapjon minden új szoftver kiadásról, hogy képes legyen diagnosztizálni a kiadásokkal együtt megjelenő problémákat és hibákat. A SzFT funkció szorosan kapcsolódik a tesztelési funkcióval is. 6.1 A szoftver felügyelet és terítés eljárásai A szoftver felügyelet és terítés ill. a változtatás-kezelési funkció működésében kulcsszerepet játszik a kiadási politika. Ez határozza meg az alkalmazandó kiadási-egység szintet, a delta-kiadások alkalmazhatóságát, a kiadási csomagok lehetőségének kihasználhatóságát, a kiadások gyakoriságát és méretét (változástartalmát), a sürgős kiadások során alkalmazandó eljárásokat, valamint a kiadások sorszámozását A szoftver felügyelet és terítés fő folyamatai A 20. ábrán található folyamatábra felhasználásával áttekinthetjük a SzFT funkció működéséhez szükséges valamennyi eljárást. 1. A folyamat kezdete a szoftver megrendelése vagy fejlesztési megbízás kiadása. Ezt a szoftvert aztán vagy megvásárolják, vagy a fejlesztő csoport készíti el. 2. A szoftver ekkor Minőségi ellenőrzésen megy keresztül, amelyben a SzFT menedzsere is részt vesz, hogy biztosítsa a szoftver érvényességét és integritását. Ha ez az ellenőrzés nem bizonyulna kielégítőnek, kezdeményezik az előforduló hibák kijavítását. 3. Ha az ellenőrzés eredménye megfelelő, a szoftver elfogadását engedélyezik, és bemásolásra kerül a HSzK-ba. 4. Ebben a fázisban előzetes döntést és engedélyt hoznak valamennyi kiadási csomag tartalmáról és időzítéséről, (ez később kerül kifejtésre). Ebben a Változtatáskezelési funkció is részt vesz. Kiadási feljegyzés készül, és a részleteket rögzítik a KKAB-ban. 5. Ha minden oda tartozó (releváns) szoftver elem készen áll, a kiadási csomag kialakításra kerül a teszt-összeállítási környezetben, majd a teszt-környezetbe kerül, tesztelésre. 6. Ha valamilyen oknál fogva a tesztelés eredménye nem bizonyulna elfogadhatónak, vissza kell utalni a fejlesztőnek/szállítónak helyesbítésre, mielőtt a benyújtási folyamatot megismétlik. A tesztelés sikeres befejeztével engedélyt kell adni a csomag éles környezetbe való kiadására. 76

84 Infrastruktúra menedzsment Szoftver felügyelet és terítés 7. A kiadás összeállítása az éles környezetbe a KKAB-ban tárolt dokumentációnak megfelelően történik. 8. Ha elkészült a csomag, terítésre kerül minden számítógépre, ahol szükség van rá. 9. Átállnak a csomag éles használatára. Fontos megjegyezni, hogy e folyamat minden fázisának eredményét meg kell jeleníteni a KKAB-ban. Ha ez nem lehetséges, akkor írásos feljegyzéseket kell tartani a SzFT-nél e követelmény teljesítéséhez. A következő szakaszok részletesebben mutatják be ezeket a fázisokat, és a hozzájuk kapcsolódó tevékenységeket Sürgős kiadások A helyes tesztelés és üzembe helyezés ellenére elkerülhetetlenül szükség van sürgős javításokra a komoly vagy magas prioritású problémák megoldása érdekében. Az ilyen változtatások gyors lefolyása miatt az előzőleg bemutatott helyes, teljes eljárásokat nem lehet követni. A sürgős változások kezelésére szolgáló eljárásoknak azonban biztosítani kell a fokozott óvatosságot. Az első megkeresendő illetékes ilyen esetben a Változtatási menedzser legyen. A Változtatásügyi Tanácsadó Testülettel / Döntőbizottsággal (VTT, ill. VTTDB) egyetértésben döntést kell hozni a változtatás fontosságának értékelésére alapozva, hogy vajon megengedhető-e a kiadás sürgős megvalósítása. Feltéve, hogy a döntés pozitív, a kiadást végrehajtják, amint lehetséges, a készülő ill. tervbe vett kiadások elé helyezve azt. Megjegyzendő, hogy az esetek többségében a sürgősség miatt az ilyen kiadások delta típusúak lesznek. 77

85 Infrastruktúra menedzsment Szoftver felügyelet és terítés Szoftver rendelés és megbízás Szoftver fejlesztése vagy beszerzése Elfogadási ellenõrzések Javítási tevékenységek OK? N I A szoftver elhelyezése a HSZK-ban A csomag tartalmának végsõ jóváhahagyása KKAB A csomag összeállítása a tesztkörnyezetben Mûködésielfogadási tesztelés OK? I N Összeállítás éles környezetben Terítés az éles környezetben Üzembehelyezés az éles környezetben 20. ábra: A SzFT funkció folyamatai Útmutatásként a következőket kell figyelembe venni: MINDIG a szoftver forráskódjának HSzK-ban levő hiteles kiadási (definitive) verzióját kell a sürgős kiadások bázisaként használni. A programozóknál vagy másutt, a HSzK-tól függetlenül tartott másolatokat, bármilyen kényelmes lenne is, SOHA nem szabad használni. A megváltoztatott forráskód egy másolatát, mint új verziót tárolni kell a HSzK-ban, a későbbi változások bázisaként. Minden sürgős kiadást a helyes változtatáskezelési eljárások szerint kell véghezvinni. Valamennyi tevékenységet a konfigurációkezelés felügyelete alatt kell végrehajtani, és követni kell a KKAB-ban. A szoftver verziószámát növelni kell, jelezve a változtatást. A megváltoztatott szoftveren olyan alapos tesztelést kell megvalósítani, amilyet csak lehetséges, a rendelkezésre álló időn belül. 78

86 Infrastruktúra menedzsment Szoftver felügyelet és terítés A gyorssegély-szolgálaton keresztül olyan sok figyelmet kell szentelni az új kiadásra, amennyit csak lehetséges. Valamennyi dokumentációt módosítani kell a változtatás megvalósítása után, amint lehetséges. Legalább ideiglenes dokumentumokat kell kibocsátani a szoftverrel, ám ezt ki kell cserélni, amint az lehetséges. Habár természetüknél fogva a sürgős kiadások nem láthatók előre, és gyakoriságuk sem csökkenthető, a szoftverek gondos ellenőrzésével, tesztelésével és üzembe helyezésével minimumon tarthatjuk előfordulásukat. Sürgős kiadások megvalósítása delta-kibocsátásként A legtöbb helyen támogatják a delta kiadást, és ez a SzFT menedzserének gondos ellenőrzése és adminisztrációja mellett rendkívül hatékony eszköz lehet. A fentiek fényében megfontolandó: A delta kiadások mérete összehasonlítva a normál kiadási egységekkel (amit már meghatároztak), és ezáltal a szükséges erőfeszítések összevetése. A delta kiadások sürgőssége. Azon (a kiadási egység szintje alatti) KE-ek száma, amelyeken megváltoztak a legutóbbi teljes kiadás óta. Ezek nagy száma esetén a teljes kiadás lehet a legkedvezőbb lépés. A delta kiadás miatt szükségszerű nem teljes tesztelés eredményként lehetséges tevékenységbeli nehézségek. A delta kiadású szoftver célja. Például, ha a végrehajtók (célcsoport) a technikailag képzetlen felhasználók, egy teljes kiadás könnyebben kivihető, dacára a szükséges erőforrásoknak A Hiteles Szoftver Könyvtárral kapcsolatos eljárások Szoftver hozzáadása a HSzK-hoz Szoftver hozzáadása a HSzK-hoz pontosan meghatározott és végrehajtott eljárások szerint történik, a HSzK tartalmának védelme érdekében. A következőkkel biztosítható, hogy csak engedélyezett KE-ek kerülhessenek a HSzK-ba: Valamennyi KE-re megbízást vagy rendelést adnak ki. Ezt szigorú, dokumentált eljárással kell felügyelni, amely meghatározza, hogy az egyes szoftver osztályok kitől fogadhatók el. Minden szoftver meg kell feleljen az elvárásoknak, és nem lehet kiegészíteni, hozzáadni valamit, mielőtt a HSzK-ba kerül. Ez különösen fontos a PC-s szoftverek esetében. Valamennyi fejlesztett szoftver minőségét ellenőrizni kell, és formálisan át kell venni. Valamennyi új verziót a helyes megelőző verzióból kell kifejleszteni, amelyet a HSzK tartalmaz, és nem más külső forrás. A verziókon történő minden változtatást engedélyeztetni kell a Változtatáskezeléssel. Minden a HSzK-ba kerülő KE-nek feljegyzésre kell kerülnie a KKAB-ban. Minden kapcsolódó díjat (licencdíj, stb.) meg kell fizetni. Szoftver kiadása tesztelésre és éles használatra Üzemeltetési átvételi tesztet kell végrehajtani a kibocsátandó szoftvereken, amelyek végül az éles környezetbe kerülnek. Valamennyi ilyen tesztkiadást a HSzK-ból kell felépíteni. A SzFT nem engedhet kiadást az éles környezetben való összeállításra, amíg azt sikeresen nem tesztelik és a tesztelési menedzser azt el nem fogadja. A tesztelés valamennyi eredményét naplózni kell, beleértve a hibák számát és súlyosságát. Ha a teszt kielégítően befejeződött, a szoftver kibocsátható az éles környezetbe. Azonban a kibocsátandó szoftvereket nem a teszt-környezetből, hanem a HSzK-ból kell újra összeállítani. Erre azért van szükség, mert semmi sem garantálja, hogy az a szoftver, amely működött a tesztkörnyezetben, működni fog az éles környezetben is. Ezen túl azt is biztosítjuk így, hogy bármely lehetséges elváltozás, ami a tesztkörnyezetben előfordulhat, nem kerülhet át az éles környezetbe az 79

87 Infrastruktúra menedzsment Szoftver felügyelet és terítés üzembeállítás során. Amikor a kibocsátott szoftver kielégítően működik, törölni kell a tesztkörnyezetből Kiadások összeállítására szolgáló eljárások Az új kiadások ütemezése, tartalma és időzítése a VTT felelősségébe tartozik. Mind a változtatási menedzser, mind a SzFT menedzsere tagja lesz a VTT-nek. A javasolt kiadások előzetes időzítését a VTT-nek kell meghatároznia és előre közölnie valamennyi érintett féllel. Új kiadás időzítésekor egy kiadási feljegyzés készül, ami a KKAB-ban bejegyzésre kerül. Ez a feljegyzés elemenként felsorolja a kiadás részét képező valamennyi KE-et, és a későbbiekben az összeállítás során annak ellenőrzésére szolgál, hogy az összetétel nem változott. Ne feledkezzünk meg róla, hogy ha a kiadás tartalmát meg kellene változtatni valamilyen okból, akkor ennek a feljegyzésnek ezt tükröznie kell, és ilyenkor a verziószámot is növelni kell. A kiadások összeállításának folyamata normális esetben a következő tevékenységekből áll: A KKAB-hez való hozzáférés a megfelelő kiadási feljegyzésért. A kiadási feljegyzés alapján a kiadás részét képező KE-ek jelenlegi verzióinak meghatározása. Ellenőrizni kell, hogy a HSzK tartalmazza valamennyi szükséges KE-et. A KE-ek átvitele az összeállítási környezetbe. A tényleges összeállítás elvégzése. Az összeállítási folyamatról feljegyzés készítése és dokumentálása. A tényleges összeállításba beletartozik a házon belül készített modulok forráskódjának lefordítása és összeszerkesztése bármely vásárolt szoftverrel, ami forráskód formában található a HSzK-ban. E folyamat része lehet olyan szoftverek beillesztése is, amelyek már tárgykód formában vannak. Szükség lehet adatbázisok építésére is, feltöltve őket tesztadatokkal. Az operációs rendszer, az adatbázis elemeinek átírása is szükségessé válhat. Mindezeket az elemeket, melyek már átestek a minőségi ellenőrzésen, ki kell másolni a HSzK-ból az összeállítási környezetbe. Nem szabad megfeledkezni arról, hogy minden másolási tevékenységet dokumentáljunk a KKAB-ban, ha a folyamatot meg kell ismételni valamilyen okból. A HSzK struktúrájától és elhelyezkedésétől függően az új kiadás összeállítható közvetlenül a tesztkörnyezetben vagy átvihető egyik gépről/rendszerről a másikra. Ez utóbbi esetben egy vagy több összeállítási környezet lehet szükséges. Ezek a környezetek a HSzK-ból származó éles kiadások összeállítására és tesztelésére használatosak, tökéletesen meg kell egyezniük a teszt és az éles környezettel, bár az olyan elemek, mint pl. egy fordítóprogram (compiler), hiányozhatnak a tényleges éles környezetből. Az összeállított szoftvert az összeállítási környezetben tárolják, terítésre készen (lásd a 3. ábrát). Akár egy vagy több összeállítási környezet szükséges, azok tervezése és méretezése a HSzK-nál leírt módhoz hasonlóan történjék. Egynél több összeállítási környezet szükséges például, ha a szoftver két különböző célrendszerre kerül majd. Az egyik lehet egy PC alapú, a másik egy mini-alapú rendszer, ezért az összeállítási környezetnek különböznie kell, még akkor is, ha a szoftver KE-ek ugyanazok. 80

88 Infrastruktúra menedzsment Szoftver felügyelet és terítés Terítés csomópontok Teszt - csomópont csomópont 1 csomópont 2 Hiteles szoftver könyvtár Összeállító környezetek csomópont 3 Szoftver felügyelet és terítés csomópont csomópont ábra: A szoftverterítés folyamata Kiadás sorszámozás A sorszámot a kiadáshoz annak összeállítása során kell hozzárendelni, a tesztelést megelőzően. Ha a tesztelés elfogadhatatlan hibákat mutatna ki a kiadásban, és ennek eredményeként további változtatásokat kell elvégezni rajta, akkor fontos, hogy ne feledkezzünk meg új kiadási számot adni az új csomaghoz Szoftver terítési és üzembe helyezési eljárások Ahol az összeállítási és a teszt/éles környezet ugyanazon a gépen van, a terítés és az üzembe helyezés felügyelete viszonylag egyszerű. Más esetben azonban szükséges lehet vagy kommunikációs csatorna vagy valamiféle hordozható média alkalmazása a szoftver kiadás célba juttatására. Mindent meg kell tenni, hogy a terítési fázisban sem fizikai, sem technikai elváltozás ne történhessen a szoftverrel (pl. ellenőrző összegek, stb.). A szoftver összeállítása mellett szükséges lehet még további eljárások végrehajtása is, amelyek lehetővé teszik az új szoftver működését, beleértve a régi verzió archiválását, az új adatok bevitelét, stb. Ha ugyanazon szoftver kiadást továbbítjuk nagyszámú részlegbe/helyszínre egyszerre, lényeges lesz mindezen részlegek számára, hogy ugyanazon időben kezdjék el a csomag használatát. Ebben az esetben lépéseket kell tenni ennek a tevékenységnek a felügyeletére. Egy szoftver nagyszámú részlegbe terítéséhez szükséges munkateher nagysága miatt a folyamat elhúzódhat. Ezután a szoftvert a részlegnél altatják, amíg az átállás napja el nem érkezik. Akkor egy alkalmas kapcsoló aktiválhatja a szoftver használatbavételét, ideális esetben a központból irányítva ezt, vagy lehetséges a szoftvert magát úgy kialakítani, hogy a nap és idő paraméterekhez kapcsolódva lépjen működésbe. A fő cél ebben a helyzetben az üzembe helyezési folyamatot olyan egyszerűvé és ezzel együtt üzembiztossá tenni, amennyire csak lehetséges. Némi helyi beavatkozás elkerülhetetlen lesz, de a 81

89 Infrastruktúra menedzsment Szoftver felügyelet és terítés SzFT személyzetének képesnek kell lennie arra, hogy figyelemmel kísérje a folyamatot, és ellenőrizze a sikeres befejezés tényét. Bármilyen eljárást alkalmazzunk is a terítés felügyeletére, emberi beavatkozás szükséges annak ellenőrzéséhez, hogy a szoftver megérkezett-e az adott távoli részlegbe, és minőségét valamint eredetiségét ellenőrizték. A következő tevékenységek tartoznak ide: A központi SzFT személyzetnek értesítenie kell a távoli részleg személyzetét arról, hogy mikorra várható a terített szoftver megérkezése. A távoli részleg személyzetének jelentenie kell a SzFT számára a szoftver megérkezését. A SzFT-nek ellenőriznie kell, hogy valamennyi szoftver megérkezett valamennyi helyszínre úgy, ahogy azt várták. A SzFT-nek általános instrukciókat kell adnia a szoftver üzembeállításának időpontjáról. A távoli részleg személyzetének jelentenie kell a SzFT számára a szoftver üzembe helyezését. A KKAB-ban levő kiadási feljegyzést módosítani kell a fenti lépéseknek megfelelően. A normális változás-felügyeleti eljárások visszaállítási terveket is megkívánnak valamennyi változtatáshoz, és ez alól a szoftver változások sem kivételek. Ha egy új kiadás hibásnak bizonyulna, az előző, bevált verzió normálisan visszaállítják. Azonban olyan esetekben, mint például a kötelező jogszabály-változások, ez esetleg nem lehetséges. Ilyenkor más terveket kell kialakítani, amelyek használhatóbbak, kipróbáltak és praktikusak Szoftverek átdolgozása Különféle okokból időről időre szükséges lehet a meglévő szoftverek átdolgozása. Fontos, hogy ezt a SzFT formálisan felügyelje, és az átdolgozás a HSzK-ban található hiteles kiadási szoftver kódon történjék. A befejezés után az új verzió minőségét ellenőrizni kell, majd a régi verzió mellé kell helyezni a HSzK-ba, ezután ez válik a jelenlegi éles KE-mé. Fontos, hogy ezt a sorrendet kövessük, és hogy a programozóknak és fejlesztőknek ne engedjük a saját forráskód másolataik használatát az új kiadás bázisaként. Lehetséges, hogy másolataik különböznek, elavultak a HSzK verziójához képest, és az eljárások követése teszi lehetetlenné, hogy a KE-ek átsminkelt, helytelen másolatait vigyék be a rendszerbe. Az alkalmazásfejlesztők együttműködése szükséges ahhoz, hogy biztosítsuk mindezek betartását és lehetséges, hogy munkavégzési szokásaikat meg kell változtatni ahhoz, hogy megfeleljenek ezen előírásnak Eljárások vásárolt szoftverek esetére Eljárások nagy és minigépekhez Általánosságban véve a nagygépen vagy minigépen való használatra beszerzett szoftverek esetében az eljárások elég hasonlóak a házon belül fejlesztett szoftvereknél megismertekhez, a következő kivétellel. Vásárolt szoftvereket gyakorlatilag kizárólag tárgykód formában kapunk, azaz nem módosítható formában. Ezt azonban ugyanazokkal az eljárásokkal kell kezelni, mint az összes többi KE esetében. Eljárások PC-khez A PC-s szoftvereket általában mágneslemezen adják át, és licenc megállapodás szabályozza a másolást. Ezért fontos, hogy az eredeti diszket megfelelően tárolják, védjék és ellenőrizzék. Az elhelyezésre tervet kell készíteni. Jegyezzük meg, hogy ez a terület is a (logikai) HSzK része kell legyen. A HSzK-nak való átadást megelőzően a PC-s szoftvert ellenőrizni kell, azt biztosítandó, hogy a szoftver teljes legyen és csak az, amit eredetileg megrendeltünk. A lehetséges vírusfertőzés miatt ebben a fázisban nagyon gondos felügyeletre és minőségi ellenőrzésre van szükség. A SzFT által készített engedélyezett másolatokat egyedileg számozni, és regisztrálni kell a KKAB-ban, az elhelyezési és felelősségi információkkal együtt. Fel kell jegyezni e szoftver státuszának minden 82

90 Infrastruktúra menedzsment Szoftver felügyelet és terítés változását is. Formális ellenőrzésekkel és korlátozásokkal kell biztosítani, hogy a PC-s szoftvert semmilyen módon ne lehessen illegálisan másolni vagy megváltoztatni. A vírusok elsősorban a PC-s szoftverek kalózmásolatain, főleg a játékokon keresztül juthatnak a szervezetekbe. A szervezet gépein a játékok futtatását tiltani, a PC-k használatát pedig szigorúan felügyelni kell, akár olyan módon is, hogy a hardver nem tartalmaz floppy diszk meghajtót. A PC-s szoftverek tényleges üzembe helyezése viszonylag egyszerű/egyértelmű, minthogy pusztán csak egy diszk és egy parancs kiadása szükséges a szoftver betöltéséhez. Azonban, ha a szervezet nagyszámú PC-t használ, az több száz másolat létrehozását jelentené mágneslemezen. Erre a problémára a hálózat alkalmazása lehet a legjobb válasz, vagyis kapcsolat alakítható ki a szoftvernek a megfelelő PC-re való közvetlen letöltéséhez. Ha a szervezet floppy-meghajtó nélküli PC-ket használ, akkor kizárólag ez a módszer alkalmazható. Ennek megvan az az előnye is, hogy sok szoftvert tartalmazó diszk eltűnése előzhető meg a környezetben. Elkerülhető az a lehetőség is, hogy egyes felhasználók helytelenül installálják a szoftvert, néhányuk sikertelenül próbálkozik stb. Mindez olyan szituációhoz vezethetne, hogy a PC-k inkompatibilissé válnának, jelentős problémákat okozva mind a szervezet, mind a SzFT funkció számára Belső készítésű PC szoftverek Fontos, hogy a belső készítésű szoftvereket ugyanazon módon kezeljék és felügyeljék, mint más szoftvereket, és az ellenőrzés feltételei és körülményei ne lazuljanak. Lehetséges, hogy számos ilyen típusú szoftvert csak egy felhasználó használ, és az csak őrá van hatással, emiatt nincs kapcsolódási felülete (interfésze) más felhasználókhoz vagy szoftverekhez a szervezeten belül. Bár ezt is megfelelően felügyelni kell, nyilvánvaló, hogy itt nem szükséges a teljes változás-felügyelet és a naplózási eljárások. Ha azonban a csomagok valamilyen módon kapcsolatba kerülnek más felhasználókkal vagy szoftverrel a szervezetben, a teljes változás-felügyeleti eljárásrendszert alkalmazni kell, és teljes feljegyzést kell tárolni a KKAB-ban Folyamatosan végzendő eljárások, szemlék és audit A legtöbb eljárás már tárgyalásra került. Ez a szakasz összegzi a szükséges folyamatos eljárásokat és a SzFT funkció felügyeletéhez szükséges audit eljárásokat. A HSzK felügyelete Ez a SzFT csoport kizárólagos felelősségi körébe tartozik. Nekik kell biztosítani azt is, hogy csak engedélyezett KE-ek kerüljenek be a HSzK-ba; hogy az megfelelően védett legyen és más személyzet ne érhesse el. Nekik kell biztosítani, hogy a HSzK összes változtatását felügyeljék a konfigurációs technikák felhasználásával, és azok megjelenjenek a KKAB-ban. Ideális esetben a HSzK-ba jutó szoftver a KKAB-t is módosítja. Különösen fontos, hogy minden minőségellenőrzési vizsgálatot elvégezzenek valamennyi a HSzK-ba kerülő szoftveren, különösen a házon belül fejlesztett KE-ek esetében. El kell végezni a HSzK rendszeres archiválását, vagy rögzített időpontban, vagy minden alkalommal, amikor a HSzK változik, a mozgások mennyiségétől függően. Rendszeres karbantartást kell végezni a HSzK-ban. A HSzK méretét figyelemmel kell kísérni, hogy soha ne telhessen meg. A régi verziókat archiválni kell a HSzK-ból, a régebbi archivált verziókat pedig szükség szerint törölni kell. A kiadás kialakítása, terítése és üzembe helyezése Ajánlott egy megvalósítás utáni szemle lefolytatása, ha lehetséges, minden szoftver kiadás esetén. Ha hibák fordulnának elő, azokat nyilvánvalóan ki kell javítani. Éppilyen fontos végrehajtani a SzFT eljárásainak megfelelő változtatását, hogy elkerülhető legyen a hibák újbóli előfordulása. A következő funkciókat kell értesíteni valamennyi szoftver kiadásról, valamint a kiadásoknak a környezetre gyakorolt hatásairól: gyorssegély-szolgálat, számítógép üzemeltetés, 83

91 Infrastruktúra menedzsment Szoftver felügyelet és terítés hálózati felügyelet, problémakezelés. Konfigurációs audit A konfigurációkezelési személyzet hajtja végre a konfigurációk rendszeres auditját. A SzFT személyzete segédkezik nekik ebben a feladatban, lehetővé téve a KKAB és a HSzK összehasonlítását. Ellenőrizni fogják, hogy: A használatban levő verziók engedélyezettek-e? Meg lettek-e változtatva valamilyen módon? A karbantartást megfelelően elvégezték-e? Ezek az ellenőrzések bonyolultnak és munkaigényesnek bizonyulhatnak nagy, elosztott részlegeknél. Meg kell fontolni a szoftverek felügyeletének, ellenőrzésének és auditjának automatikus, a központi csomópontból történő megvalósítását, megkönnyítve e feladat ellátását. Mint minden auditnál, az elvégzett feladatot dokumentálni kell, és valamennyi jelzett problémával kapcsolatban intézkedni kell. Az eredményesség és hatékonyság szemléje Fontos, hogy sor kerüljön magának a SzFT funkciónak a rendszeres auditjára, így biztosítva az eredményes és hatékony szolgáltatást. Egy ilyen szemlét ideális esetben kevéssel a funkció üzembe állítása után kell elvégezni, biztosítandó, hogy a (készített) terveket helyesen megvalósították, és a funkció az elképzeléseknek megfelelően teljesít. A szemléket ezután rendszeresen kell végrehajtani (legalább félévente egyszer), és minden változást a változás-felügyeleten keresztül kell megvalósítani, a minőségi működés érdekében. Szemlézni kell azokat a tényezőket is, amelyek hatnak a SzFT funkció eredményességére és hatékonyságra, például a kiadási politikát változtatni kell a tapasztalatok fényében és a változó külső hatások miatt is. A funkció sikerességét a következőkel lehet mérni: A SzFT funkció felügyelete alatt az ütemezésnek megfelelően, a kiadások költségkorlátokon belül kerülnek összeállításra és üzembe helyezésre. Elfogadhatatlan hibák miatt visszavont kiadások hiánya vagy ritka előfordulása. Ez azt feltételezi, hogy egyes kiadások olyan hibákat tartalmazhatnak, amelyek elfogadhatóak. Az összeállítási hibák ritka előfordulása. A HSzK biztonságos és alapos kezelése, melynek eredményeként nincs jele a HSzK-ban levő olyan elemnek, amely ne lett volna minőségi ellenőrzésnek alávetve. Nincs nyoma olyan átdolgozott szoftvernek, amelynek kialakítása nem a HSzK-ból indult volna ki. Külső szoftverhez kapcsolódó jogi korlátozások betartása. A kiadások pontos terítése valamennyi távoli részleghez. A kiadások üzembe helyezése az előirányzott időpontban. Nincs utalás nem megvalósított vagy engedélyezetlen kiadásokra a távoli részlegeknél. Nincs utalás engedélyezetlen verzió-visszaállításra egyetlen részlegnél sem. Nincs jele engedélyezetlen szoftverek használatának egyetlen részlegnél sem. Nincs jele annak, hogy használaton kívüli szoftverekért licencdíjat fizetnének. Nincs jele pazarló ismétlődéseknek a kiadások összeállításánál. Valamennyi tevékenység pontosan feljegyzésre kerül a KKAB-ban. A kiadások tervezett összeállítása egybevág a ténylegessel. A SzFT számára szükséges informatikai és emberi erőforrások sikeres (folyamatos előzetes) tervezése. 84

92 Infrastruktúra menedzsment Szoftver felügyelet és terítés A HSzK mérete egyezik a helyigénnyel, és minden kapcsolódó karbantartási tevékenység végrehajtanak. 6.2 A SzFT funkció bevezetése A SzFT tervezése A SzFT tervezése Az új SzFT tervezését segítendő meg kell vizsgálni a szoftverek normális haladását a különböző fázisok között a kezdeti fejlesztéstől/beszerzéstől az éles felhasználásig. E folyamat minden szakasza használja a konfigurációkezelési adatbázist (KKAB), ill. abban információkat tárol. Az eljárásokat részletesen lásd a következő pontban! Eljárások A kinevezett SzFT-i menedzsernek számos eljárást kell beüzemelnie, hogy segítse a funkció átfogó céljainak elérését. Ezeknek az eljárásoknak kell biztosítania, hogy a szervezet valamennyi szoftver eszköze minőségileg ellenőrizve, biztonságos felügyelet alatt legyen, és csak megfelelő és engedélyezett kiadások legyenek felhasználhatók az éles környezetben. Ezek az eljárások a funkció követelményeinek/feladatainak valamennyi szempontját/területét fedik, a részleget működtető személyzettől azokig az eljárásokig, amelyeket alkalmazva felügyelik a gondjaikra bízott szoftvereket. Személyzet Számos tényezőt kell figyelembe venni a SzFT funkció személyzettel való feltöltésénél, a személyzeti szintek és a megkívánt képességek tervezésekor. Néhány a fontosabbak közül: A felügyelendő szoftver KE-ek száma és a funkció által kezelendő szoftver változtatások/kiadások mérete, gyakorisága és összetettsége. A számítógépek/részlegek száma, ahová a kiadásokat teríteni kell. A SzFT eljárásait segítő vagy automatizáló támogató szoftver eszközök elérhetősége és szolgáltatási szintje. A SzFT rendkívül fontos része az informatikai struktúrának. Az SzFT az alkalmazásfejlesztés és az éles működtetés közötti "kritikus út" része, és közvetlenül részt vesz az élesben használt szoftverek valamennyi változtatásában. Lényeges, hogy a funkció hatékony és eredményes módon működjék, és a lehető legkisebb mértékben hasson az új vagy megváltoztatott szoftverek bevezetési idejére. Mindezt természetesen ellenőrzött, tervezett és minőségi módon kell elérni, ezért a funkciót ellátó személyzetet gondosan kell kiválasztani, hogy megfelelő technikai háttérrel és informatikai ismeretekkel, valamint a szervezeti struktúra és az azt támogató alkalmazások alapos ismeretével rendelkezzenek. A kiválasztott személyzet valamennyi tagját teljesen ki kell képezni, és naprakész tudással kell ellátni az összes releváns területről. Ide tartoznak: a konfigurációkezelés, nagygépes szoftver architektúrák, alkalmazási struktúrák és használatuk, szervezeti követelmények, támogató eszközök és segédszoftverek. Tudatosítás Számos funkcióra, és azok személyzetére hatással lesz a SzFT funkció bevezetése. Ezen kívül hatni fog olyan más részlegekre is, amelyek kapcsolódnak a házigazda részleggel. Ha a funkció nem felügyeli valamennyi szoftvert, akkor eredményessége jelentős mértékben csökken, ezért lényeges, hogy minden kapcsolódó terület (interfész) értse meg ennek a szolgáltatásnak a helyes használatából eredő hasznokat. Ezeket a hasznokat már részleteztük, és ezt ezen a ponton nyomatékosítani kell az új rendszert használó vagy azzal kapcsolatba kerülő személyzet számára. 85

93 Infrastruktúra menedzsment Szoftver felügyelet és terítés Kiadási politika tervezése Átfogó kiadási politikát (azaz irányelveket) kell kialakítani, hogy keretet adjon a SzFT-nek. Egy átfogó kiadási politika határozza meg a SzFT és a változtatáskezelés működését. Ez a politika, bár lényegében folyamatosan ugyanaz maradhat, rendszeres felülvizsgálatra szorul, hogy alkalmas maradjon az általa támogatott informatikai környezet számára. Az érintett területek közé tartozhatnak az olyan elemek, mint a sürgős kiadások. Különböző szervezeti körülmények között az új vagy módosított szoftverek sürgős kiadását vezérlő szabályokat ki kell igazítani. Az szervezeti igények rendszeres szemléje révén, tekintetbe véve a kiadási politikát, ez a fajta változtatás ellenőrizhető és tervezhető, inkább, mint hogy csupán reagáljanak a változásokra, amelyek túlléphetnek a funkción. IT infrastruktúra 1. Rendszer 2. Rendszer 3. Rendszer 1-1 programcsoport 1-2 programcsoport 2-1 programcsoport 2-2 programcsoport program program modul modul modul 22. ábra: Szoftver lebontás Kiadási egységek megtervezése Az első cél annak eldöntése, hogy melyik a legmegfelelőbb egység-szint valamennyi szoftver elem vagy elem-típus számára. Ez számos tényezőtől függ, mint pl. a használatban levő szoftver-csomagok mérete, a programok típusa, összetettsége, stb. A 22. ábra egy informatikai infrastruktúra négy szintjének egyszerűsített példáját adja. A cél annak eldöntése, hogy ezek közül melyik szinten lesz a kiadási egység. Az egységek itt a RENDSZEREK, amelyek PROGRAMCSOMAGOKBÓL állnak, ezeket PROGRAMOK alkotják, amelyeket viszont MODULOK építenek fel. Ezek közül valamelyik szinten lesz a Kiadási Egység. Kisebb üzembeállításoknál alkalmas lehet az, hogy a kiadási egység a Rendszer szinten legyen. Emiatt, ha egy a rendszer valamely részét alkotó KE megváltozik, a teljes rendszer szoftver csomagot újra ki kell bocsátani. Ez azonban nagy installációk esetében jelentős többletterhet jelenthet. Számításba 86

94 Infrastruktúra menedzsment Szoftver felügyelet és terítés véve az alábbi tényezőket, ugyanezt a gondolatmenetet kell követni annak meghatározásához, hogy vajon a csomag, a program vagy a modul szint illeszkedik-e jobban a szervezet igényeihez. Figyelembe kell venni: A szükséges változtatások mennyiségét, összességében, és valamennyi lehetséges egység szinten. Például egy magas szintű változtatás csupán egy program egyetlen meghatározott moduljában a Modul szintet tenné logikussá kiadási egység szintként. Azonban, ha ez a magas szintű változás a modulok nagy részét vagy összességét érinti, akkor a program lehet a leghatékonyabb szint. A kiadások kialakításához, teszteléséhez, terítéséhez és üzembe helyezéséhez szükséges idő- és erőforrás-mennyiség valamennyi szintre. Ez azt jelenti, hogy minél nagyobb az egység, annál nagyobb SzFT erőfeszítés szükséges a változtatás megvalósításához, emiatt nagyobb lehet a hatás az éles szolgáltatásra. Az üzembe helyezés egyszerűsége. Például, ha a felhasználók felelősek az üzembe helyezésért a saját PC-jükön, akkor kívánatos ennek az eljárásnak az egyszerűsítése és a változások előfordulásának minimumon tartása. Emiatt jobb megoldás lehet a kisebb változtatások visszatartása és periodikus, rendszeres megvalósítása. Ezen kívül, főleg ha a változások kicsik és modul szintűek, jobb teljes programok kiadása, mint egyedi moduloké. A javasolt kiadási egységek és az informatikai infrastruktúra fennmaradó része közti interfészek/kapcsolatok összetettsége. Például, hogy milyen egyszerű az egység leválasztása majd az új egység visszaillesztése a fennmaradó programcsomagokhoz és programokhoz, stb. Természetesen lesz egy határ a változások számában, amely még kielégítően kezelhető egy kiadás esetében; és a kiadás mérete sem haladhatja meg soha azt a mértéket, ami könnyen kialakítható és tesztelhető, elfogadható időtávon belül. Általánosan véve jobb a változásokat a legalacsonyabb, még praktikus szintre korlátozni; tehát egy teljes program szoftver nem kerül teljes kiadásra, ha csak egy vagy néhány modulja változott. Az is valószínű, hogy ha egy modul több programon belül is jelen van, ennek a változtatása esetén túlzott erőfeszítéseket kívánna a tesztelés, kialakítás és kiadás tevékenységsorának elvégzése valamennyi programnál, csupán ennek az egyetlen modulnak a változtatása miatt. Különleges esetben, amikor az informatikai infrastruktúrában lehetségesek a csapongó és gyakori változások, megfelelő megoldást jelenthet, ha a SzFT menedzser a Változtatási menedzserrel együtt a kiadási egységet dinamikusan határozza meg. Ez problémákat jelenthet, de jóval eredményesebb megoldás annál, mint mereven ragaszkodni egy tervhez, ami nem alkalmazható és több problémát okoz, mint amennyit megold. A másik megfontolandó kérdés a kiadási csomagok alkalmazása. Ezt később tárgyaljuk, de látható lesz, hogy a használatuk bizonyosan kihatással lesz a döntésre a kiadási egység méretéről. Nem szabad megfeledkezni arról, hogy a minőségi és az átvételi tesztelés, habár befolyásolja a kiadási egység méretét, lehet, hogy nem értelmezhető az adott kiadási egység szinten. Például, ha használatra kibocsátanak egy egyszerű modult, szükséges lehet a hozzá tartozó teljes programrendszerek tesztelése, esetleg még sok más interfész tesztelése is. Általánosságban véve, a tesztelés azokra az elemekre összpontosítson, amelyek megváltoztak, de a fenti szempontokat is figyelembe kell venni. Delta kiadások Előfordulhat, hogy egy teljes egység kiadása nem indokolt. Ilyen esetekben egy delta kiadás alkalmasabb megoldás lehet. Egy delta kiadás csak azokat a KE-eket tartalmazza a kiadáson belül, amelyek aktuálisan megváltoztak vagy újak a legutóbb kiadáshoz képest, amelyek azonban nem alkotnak teljes kiadási egységet. Az első döntés az, hogy vajon megengedjünk-e delta kiadást egyáltalán, és ha igen, milyen körülmények között. A teljes egység vagy csomag kiadásának legfőbb előnye az, hogy valamennyi összetevő együttesen kerül kialakításra, tesztelésre majd terítésre, és az üzembe helyezés is együttesen történik. Ezzel megelőzhető az elavult verziók lehetősége, vagy a teszteletlen interfészek okozta problémák. 87

95 Infrastruktúra menedzsment Szoftver felügyelet és terítés Még viszonylag kisebb modul változások esetén is egy teljes egység kiadásának legfőbb hátránya azonban a kialakításhoz, teszteléshez, terítéshez és üzembe helyezéshez szükséges idő, erőfeszítés és erőforrás (mind emberi, mind számítógépes) mennyisége. Ezzel szemben elfogadva a delta kiadások átvételének politikáját csökkenthetők a kialakításhoz szükséges erőfeszítések és a terítéshez és üzembe helyezéshez szükséges munka is. Egy lehetséges példa egy egyszerű, kicsi javítás megvalósítása miatt kért kiadás. Ilyen körülmények között nehéz lenne indokolni egy teljes kiadási egységhez szükséges erőfeszítéseket. Természetesen lehetséges lenne elhalasztani a javítást egy későbbi, nagyobb kiadásig. Azonban, ha a javítás fontos és időkorlátok vannak, politikát kell kidolgozni ezzel kapcsolatban. Azt is látható, hogy a sürgős változtatások, melyekkel e fejezet későbbi részében foglalkozunk, gyakran delta típusúak. Csomag kiadások Megfontolandó a kiadások csoportosítása csomagokká. Az egyedi kiadások akár teljes egységek, akár delta kiadások, akár mindkettő összevonhatók. Ezt az a helyzet indokolhatja, amikor egy rendszer vagy programcsomag változtatása más rendszerek változtatását is szükségessé teszi ezeket ugyanis célszerű egy csoportba összevonni. Olyan környezetben, ahol az élesben használt szoftvert rendszeresen változtatják, alkalmas megoldás lehet az egyedi kiadások csoportosítása egy kiadási csomaggá. Ez hosszabb időre lehetővé teszi az éles környezet stabilitását, de másrészről megnöveli a SzFT munkaterhelését a csomagok összerakása és a szükséges tesztelés stb. miatt. A további hasznok: Csökken annak a valószínűsége, hogy régi vagy inkompatibilis szoftverek maradjanak használatban. Biztosított, hogy valamennyi változás egyidejűleg, rendszeres időközönként kerül megvalósításra. A szoftver minden elemének és interfészének átfogó tesztelése lehetséges. Kiadások gyakorisága és változás tartalma Bár a környezet stabilabb lehet, ha a kiadások gyakorisága csökken, azonban nagyobb méretüknél fogva a kiadásokhoz kapcsolódó hibák veszélye nő. Nyilvánvaló, hogy egyes KE változásai megkívánják más KE-ek ugyanabban az időben történő változtatását is. Ennek hatására egyes kiadások nagyobbakká válhatnak, mint ideális esetben lenniük kellene. Valamennyi szoftver és kiadás típusra meg kell határozni a javasolt kiadási gyakoriságot, eltekintve a sürgős kiadásoktól. A kiadásoknak mind a gyakoriságát, mind a változási tartalmát (méretét) meg kell határozni, mérlegelve a szoftver által kínált szolgáltatások megszerzése iránti igényt és a túl gyakori és kicsi változások okozta megnövekedett költségeket és stabilitáshiányt. Azonban van határa az együtt megvalósítható változások mértékének. Sürgős kiadások Meg kell határozni a sürgős kiadásokra vonatkozó eljárásokat. Kiadás sorszámozás Minden kiadáshoz egy sorszámot kell rendelni. Két vagy három szintű rendszer megvalósítása ajánlott, melynek felső szintjei a jelentős kiadások számára, az alsóbb szintek pedig a kisebb kiadások számára szolgálnak. A Hiteles Szoftver Könyvtár tervezése A HSzK a SzFT funkció magja, lényege. Ez egy biztonságos, logikai terület, ahol valamennyi szoftver KE hiteles, engedélyezett kiadási verzióját tárolják és védik. A tényleges HSzK számos valóságos szoftver könyvtárból áll, amelybe beletartozik egy floppy lemez tároló is a PC-s szoftverek számára. Ideális esetben a HSzK a fejlesztéstől, a teszt és az éles fájltárolási területektől elkülönített környezetben található. Elkészítésére tervet kell készíteni, a használatához szükséges eljárásokkal együtt. A HSzK fogja tartalmazni a forráskódot. Ezt azután a kiadások tárgykódjának létrehozásához használják fel. A vásárolt szoftvereket azonban tárgykód formájukban adják, ezért a HSzK-ban is így kell tárolni őket. Figyelmet kell fordítani annak tisztázására, hogy a HSzK-ban a könyvtár melyik része 88

96 Infrastruktúra menedzsment Szoftver felügyelet és terítés milyen típusú kódot tartalmaz. A dokumentációt is a HSzK-ban kell tárolni szöveges fájlként, a könnyű kezelés és hordozhatóság érdekében. Alapvetően fontos, hogy a HSzK az általa támogatott infrastruktúra valamennyi élesben használt szoftverét tartalmazza, biztonságos módon elhelyezve és felügyelve. Egy katasztrófa vagy szoftver sérülés esetén, ami megakadályozza az éles szoftvernek a mentésekből való helyreállítását, a HSzKban levő KE-ek fogják alkotni a helyreállítás alapját. A biztonság érdekében a HSzK elérését kizárólag a SzFT funkció azon személyzetére kell korlátozni, akiknek feladata ellátásához szüksége van rá. A HSzK tartalmát rendszeresen menteni kell, rögzített intervallumonként, vagy lehetőség szerint tartalmának minden felújításakor. A hardver és operációs rendszer környezet Ahogy már korábban említettük, a HSzK-nak ideális esetben olyan hardver/szoftver környezetben kell működnie, amely elkülönül a rendszertől, amelyen a kiadás maga kialakításra kerül. Egy több nagygépből álló részlegnél ezt viszonylag könnyű megvalósítani. Az ilyen jelegű környezetben még az is lehetséges, hogy eltávolítsuk az éles környezettől az összes olyan elemet, mint a forráskód, a fordítóprogramok stb., ami növeli a HSzK biztonságát. Egy kisebb vagy egy géppel rendelkező részlegnél ez nyilvánvalóan nem lehetséges. Ebben az esetben tanácsos egy adott célra elkülönített diszk területet fenntartani a HSzK számára, így a kapcsolódás közte és az infrastruktúra fennmaradó része között kettéválasztható, kivéve azt az időt, amikor a szoftver transzfer folyik. A HSzK méretezése A HSzK-at, mielőtt létrehoznánk, méretezni kell. Ebben részt vesz a HSzK menedzser és a Kapacitástervezési menedzser. Tevékenységük során figyelembe kell venniük nemcsak a meglévő, de a tervezett és jövőbeni igényeket is. Mikor egy már létező szoftvert a funkció átvesz, a méret már értelemszerűen ismert. Új szoftver esetében, a fejlesztés során, a rendszertervezőkkel kell felvenni a kapcsolatot, hogy becslést adjanak a program/modul méretéről. Jövőbeli szoftverek esetén a becslések a következőkön fognak alapulni: a meglévő javaslatokon, a meglévő szoftverek új verzióin, a történeti elemzésekből számított jövőbeli trendeken, a javasolt szervezeti terveken, a lehetséges törvényi/szabályozási változásokon. Amikor e becslések megtörténtek, el kell dönteni, hogy a KE-ek hány verzióját tároljuk a HSzK-ban. Nyilvánvaló, hogy két verzió megduplázza a méretet, három megtriplázza, stb. Legalább két megelőző verzió tárolását érdemes megfontolni a jelenlegi éles verzión kívül. A fájltárolási korlátok ezt megakadályozhatják, ezért a régebbi verziók archiválhatók mágnesszalagra is, azonban ebben az esetben a helyreállítási időt is figyelembe kell venni. A HSzK biztonsága Az éles rendszer karbantarthatósága érdekében biztosítani kell, hogy a HSzK naprakész legyen, és tartalma ne sérülhessen. Bármely romlás esetén az éles vagy a tesztkód mentésekből kísérelhető meg a visszaállítás, fokozott óvatosság mellett. Ennek megfelelő eljárásokat kell megtervezni és kialakítani. Szoftver hozzáadása a HSzK-hoz Pontosan meg kell határozni és ellenőrizni azon eljárásokat, melyek révén szoftvereket adunk hozzá a HSzK-hoz, hogy megvédjük a HSzK tartalmát, és biztosítsuk, hogy csak engedélyezett KE-ek kerülhessenek bele. Ennek keretében meg kell határozni a személyzetre vonatkozó jogosultságokat, a követendő eljárásrendet, valamint a minőségi szemlézés módjait. Szoftver kiadási eljárások tervezése tesztelésre és éles használatra Eljárásokat kell kidolgozni a kibocsátandó szoftverek üzemeltetési átvételi tesztjére, a tesztkiadás a HSzK-ból való felépítésére, az éles környezetben való összeállításra, a tesztelés valamennyi eredményének naplózására. 89

97 Infrastruktúra menedzsment Szoftver felügyelet és terítés Kiadások összeállítására szolgáló eljárások tervezése A szoftver kiadások felépítési eljárásait meg kell tervezni, ki kell alakítani és dokumentálni, a korábban bemutatottaknak megfelelően. Szoftver terítési és üzembe helyezési eljárások tervezése Eljárásokat kell tervezni és kialakítani a szoftver kiadásoknak az összeállítási környezetből a tesztelési és az éles környezet(ek)be való terítésére, és ezekben a környezetekben való használatba állítására. Szoftverek átdolgozására szolgáló eljárások tervezése Eljárások szükségesek a szoftverek átdolgozására. Az átdolgozás csak a HSzK-ban tárolt hiteles kódon történhet, ezért eljárások szükségesek annak megakadályozására, hogy a HSzK-on kívüli forrást használjanak fel, ezen kívül eljárások szükségesek a minőség-ellenőrzésre is. Eljárások meghatározása vásárolt szoftverek esetére A vásárolt szoftverekhez további eljárások bevezetése megfontolandó, a már tárgyalt kétféle környezetre vonatkozóan: Eljárások szükségesek a nagy és minigépekhez a házon belül fejlesztett szoftverekhez hasonló eljárások szükségesek, figyelembe véve, hogy ez esetben tárgykód formáról van szó. Eljárások szükségesek a PC-khez az eredeti diszk megfelelő tárolására, a HSzK-nak való átadására, az ellenőrzésekre, a másolatok kezelésére, az üzembe helyezésre. Belső készítésű PC szoftverek Megfelelő eljárásokkal kell biztosítani, hogy a belső készítésű szoftvereket is ugyanolyan módon kezeljék és felügyeljék, mint más szoftvereket. A kevésbé fontos, egy felhasználó céljaira szolgáló szoftverek jelenthetnek csak kivételt, ezeknél bizonyos eljárások elhagyhatók. A támogató eszközök követelményeinek meghatározása A szervezeten belül a SzFT menedzsernek kell megállapítani, hogy a meglévő szoftverek és a jelenlegi eljárásrendek milyen mértékben elégítik ki funkciójának követelményeit, figyelembe véve a szoftverek felügyeletét és terítését. Ha szükséges, meg kell vizsgálni, hogy mi az, ami külső forrásból elérhető, hogy olyan lehetőségekhez/szolgáltatásokhoz juthassunk, amit a meglévő rendszerek nem nyújtanak. Az ilyen csomagokat gyakran a konfigurációkezelés területére sorolják, tehát ezt is meg kell vizsgálni. Ezután teljes képet lehet kialakítani a SzFT funkciót segítő beszerezhető eszközökről. Az elérhető eszközök által nem fedett területeket ekkor meg lehet vizsgálni az esetleges házon belüli támogató szoftver fejlesztése szempontjából. A meglévő eljárások helyesbítése/módosítása Ha az új SzFT funkció eljárásai meghatározásra kerültek, akkor tisztázni kell a funkción belüli és a más funkciókhoz való kapcsolódásokat (interfészeket), és ahol szükséges, módosítani kell azokat. Ehhez szükség lehet arra, hogy más funkciók megváltoztassák saját eljárásaikat, ezért a SzFT menedzser munkájával együtt jár, hogy eladja a koncepciót és annak előnyeit a többi menedzsernek, megmutatva a hasznokat mind a funkciók, mind az infrastruktúra egésze szempontjából. Ezek az érintett funkciók, pl.: Alkalmazásfejlesztés, Számítógép üzemeltetés, Hálózatok, Változás-felügyelet, Konfigurációkezelés, üzemeltetési átvételi tesztelés. A SzFT eljárásainak dokumentációja Dokumentálni kell mindazokat az eljárásokat, amelyeket a megelőző pontokban tárgyaltunk, valamint azokat, amelyek ezután következnek, beleértve az összeállítást, terítést, a szoftvercsomagok üzembe helyezését. E dokumentációnak tartalmaznia kell a funkció kiadási politikáját és a HSzK felügyeleti és karbantartási eljárásait is. Ezen eljárásokat a szervezetnek szemléznie kell, azt 90

98 Infrastruktúra menedzsment Szoftver felügyelet és terítés biztosítandó, hogy ne befolyásoljanak semmilyen más területet, majd ezután engedélyeztetni kell életbe léptetésüket az informatikai szolgáltatás menedzserrel. E dokumentáció módosítását ellenőrizni kell, a normál változás-felügyeleti eljárások szerint, a megfelelő engedélyeztetésnek alávetve Megvalósítás A megvalósítási terv kialakítása Tervet kell készíteni az új SzFT funkció megvalósításáról. Nem célravezető a szervezet által a kezdetektől tárolt/vezetett teljes KE leltár átvételével próbálkozni. Előnyösebb, ha korlátozzuk a kezdeti részvételi kört, azaz ha csak az új projektek eredményeire koncentrálunk: A HSzK-ban az anyag kezdetben lassan szaporodik, lehetővé téve, hogy megismerkedjenek az új technikákkal és eszközökkel, amelyeknek használatába egy jobban felügyelt működési mód érdekében kezdtek. Ez tisztán elhatárolt kezdési pontot biztosít az új funkció és eljárásai használatára, amit az infrastruktúra személyzete könnyebben elfogadhatónak és alkalmazhatónak talál az ősrobbanás ( big bang ) megközelítéshez képest. Ez a kezdeti tevékenység az új funkcióban az új szoftverek verzióinak első tesztjével együtt folyhat. Mivel a felhasználók ekkor még nem érintettek közvetlenül, a SzFT eljárásainak esetleges hibája az éles üzemeltetésre nincs tényleges hatással, ami jó tapasztalatszerzési lehetőséget jelent. Mindezt szem előtt tartva logikus a funkció indítását egy új projekt határidejével együtt időzíteni. Eljárások Amikor a személyzet, a hardver és a támogató eszközök már rendelkezésre állnak, és a személyzet képzése is befejeződött, a SzFT megvalósításának első fázisa következhet. Először a HSzK és az összeállítási környezet tervezését és létrehozását kell elvégezni. Minden szükséges biztonsági engedélyt ki kell adni, hogy a hozzáférést kizárólag a SzFT személyzetre lehessen korlátozni. Ha ez megtörtént, tesztelni kell a tervezési fázis során már meghatározott kritériumoknak megfelelően, biztosítva, hogy minden rendben legyen. Ezután mindenkit, akit a változás érint, értesíteni kell, és tudatva velük, mikortól kezdve kell átadni az új szoftver KE-ket a SzFT funkciónak a HSzK-ban való elhelyezésre. Meg kell állapodni az új vásárolt szoftverek elhelyezéséről is, ezeket közvetlenül a SzFT funkciónak kell átadni. Ha a már tárgyalt fokozatos megvalósítási megközelítést elfogadták, fontolóra kell venni, hogy a meglévő szoftverek mikor és hogyan kerüljenek a SzFT ellenőrzése alá. Nyilvánvaló, hogy ez függ a kezdeti megvalósítási szakaszok sikerétől, de a terv ne legyen túl ambiciózus, mivel a problémák ebben a fázisban elronthatják a funkcióról addig kialakított kedvező képet. A kiadás-felügyelet megvalósítására valamikor a HSzK létrehozása után kerül sor. Ezen kívül a kiadás felügyeletének eljárásait is tesztelni kell, mielőtt használatukba kezdenének. A fokozatos megközelítéssel ezek az eljárások kipróbálhatók az első új projekttel, amely a teszt környezetben összeállításra kerül. Továbbá, mire a kiadás eléri az éles környezetet, az eljárások teszteltek és sikeresek lesznek, mivel a velük kapcsolatos problémák és hibák azonosíthatók, ahogy a kiadás a tesztkörnyezetbe kerül. Az eredeti állapot helyreállítását biztosító terveket kell készíteni arra az esetre, ha az eljárások lényeges részében hiba történne, ami nem javítható ki a rendelkezésre álló időn belül. Ez jó lehetőség az üzembe helyezési és a terítési eljárások elkülönített tesztelésére, mivel ha az egyik sikertelen (hibázik), a másik még mindig használható. Azonban az első kiadást óvatosan kell megtervezni. (Nem túl jó ötlet úgy dönteni, hogy az első kiadás terítési dátum egyezzék egy a szervezeti infrastruktúra további működéséhez fontos kiadás idejével.) Függőségek Számos feltételnek kell teljesülnie a SzFT megvalósítása előtt: A SzFT nem működhet sikeresen addig, amíg a szolgáltatás-menedzsment más területei nem működnek megfelelően, ideértve a konfigurációkezelést, a változáskezelést és az üzemeltetési 91

99 Infrastruktúra menedzsment Szoftver felügyelet és terítés átvételi tesztelést. Ha ezek a funkciók még nem léteznek, létre kell hozni, és sikeresen üzemeltetni kell őket, mielőtt a SzFT maga működésbe lépne. A személyzetet ki kell képezni az új SzFT-i eljárásokra, valamint a hardver és szoftver eszközök használatára, illetve meg kell ismertetni velük a változtatás- és a konfigurációkezelés alapelveit A HSzK-at és az összeállítási környezetet ki kell alakítani, majd átfogó tesztelésnek kell alávetni. A támogató eszközöket is be kell szerezni és tesztelni. A SzFT funkció valamennyi eljárását és eszközét tesztelni kell, amennyire csak lehetséges, olyan szimulált környezetben, ami az aktuális használatot a lehető legjobban tükrözi Problémák A szoftver felügyelet és terítés funkció kialakításának kezdeményezésekor, illetve a működtetés során a következő nehézségekkel szembesülhetünk: Lehetséges, hogy a régi eljárásokban jártas személyzet nem látja szívesen a változásokat. Ennek ellensúlyozására a figyelemfelkeltő kampány során hangsúlyozni kell az új eljárások hasznosságát. Megkísérelhetik a SzFT eljárásainak megkerülését. Ezt szigorúan kell kezelni, főleg ha engedélyezetlen szoftverek kerülnek a szervezetbe, mivel ezek a vírusok és a rossz szándékú beavatkozások fő forrásai. Sürgős javítások esetén is törekedhetnek a SzFT, a változtatás és a konfigurációkezelés eljárásainak megkerülésére, ami nagy veszélyeket rejt magában. Ellenállhatnak annak is, hogy a HSzK-ból kiindulva hajtsanak végre teljes szoftver összeállítást az éles környezetben, ehelyett csupán átmásolják a szoftvert a teszt környezetből. Osztott rendszereknél komoly gondot okozhat, ha egy szoftver új verziója nem kerül használatba a megfelelő időben. Ez megelőzhető központi, lehetőleg automatikus felügyeleti eszközökkel és rendszeres konfigurációs audittal. A túlzott lelkesedés is gondot okozhat, az új eljárások üzembe helyezésével ugyanis erős lesz a kísértés, hogy ezen eljárásokat kiterjesszék valamennyi szervezeti szoftverre. Ez azonban fáradságos és pazarló is lenne, kezdetben elegendő az új eljárásokat csupán az új kiadásokra alkalmazni. Később, ha a felügyelet alá nem vont szoftverek aránya már kicsi, akkor megfontolandó az eljárások kiterjesztése a meglévő szoftverekre is. Sokan túl kényelmetlennek és költségesnek tekintik a SzFT eljárásait, akár az informatikai vezetés tagjai is. Éppen ezért szükséges tudatosítani, hogy a szoftver változások hatékony és eredményes kezelése nélkülözhetetlen tevékenység. 6.3 Ajánlott irodalom Software Control and Distribution. IT Infrastructure Library. HMSO ISBN A témával foglalkozó Web-oldalak:

100 7. Rendelkezésre-állás menedzsment Csaknem minden nagy szervezet támaszkodik az informatikára tevékenységének ellátásában. Egy felmérés szerint ötből legalább egy szervezet nem lenne képes néhány óránál tovább működni, ha egy jelentős számítógépes kiesés az informatikai szolgáltatások hiányát okozná. Még a kisebb informatikai szolgáltatási zavarok is károsan befolyásolhatják a szervezeti tevékenységeket. A szolgáltatásokat ezért úgy kell megtervezni és fenntartani az indokolható költségeken belül, hogy minimálisra csökkentsük bármely hiba hatását a szervezeti tevékenységre. A rendelkezésre-állás menedzsment feladata, hogy a rendszerek általános rendelkezésre-állását javítsa a felhasználók szolgáltatási igényeinek kielégítése érdekében, a megelőző és a javító karbantartási tevékenység optimalizálása révén. A rendelkezésre-állás menedzsment funkció alapozza meg a felhasználók és az informatikai szolgáltatást nyújtók közötti Szolgáltatási Szint Megállapodásokat (SzSzM). A rendelkezésre-állás menedzsment lényegében az informatikai összetevőket érintő alábbi négy területtel foglalkozik: Megbízhatóság (reliability): egy információtechnológiai összetevő azon képessége, hogy ellásson egy megkívánt funkciót meghatározott körülmények között, egy meghatározott időtartamra. Karbantarthatóság (maintainability): egy számítógépes komponens vagy szolgáltatás azon képessége, hogy meg lehet tartani egy olyan állapotban, vagy vissza lehet állítani egy olyan állapotba, amelyben képes ellátni a megkívánt funkciót. Szolgáltatási képesség (serviceability): szerződéses kikötés, amely meghatározza az informatikai komponens rendelkezésre-állását az adott összetevőket szolgáltató és karbantartó külső szervezettel való megegyezés szerint. Biztonság (security): lehetővé teszi a számítógépes komponensek vagy informatikai szolgáltatások elérését biztonságos körülmények között. A rendelkezésre-állás menedzsment biztosítja, hogy az informatikai szolgáltatások hibáinak száma és időtartama igazolható költséghatárokon belül maradjon a felhasználók számára. Ez az informatikai szolgáltatások nyújtásához használt technológia, a támogató szervezet, a technológiával ellátó szállító és az informatikai szolgáltatások figyelembevételével valósítható meg. A rendelkezésre-állás menedzsment megbecsli a változások hatását a rendelkezésre-állásra és a megbízhatóságra. Információkkal lát el a rendszerek, hardver, szoftver és a karbantartási követelmények költségeinek alátámasztásához, és kulcseleme annak, hogy olyan informatikai szolgáltatásokat nyújtsanak a szervezetben, amelyek kielégítik a felhasználók igényeit. A rendelkezésre-állás megköveteli a vezetés folyamatos figyelmét, hogy ezáltal biztosítsa a felhasználói igények kielégítését, és hogy figyelemmel kísérje azt, hogy a szolgáltatók és karbantartók tevékenysége megfelel-e a szerződésekben foglaltaknak. Az informatikai rendszereket és szolgáltatásokat úgy kell tervezni, hogy megbízhatóak, hibatűrők és karbantarthatók legyenek teljes életciklusuk során, a tervezéstől a megszüntetésükig. Évről évre jobban támaszkodunk az informatikai szolgáltatásokra. Ez a függőség olyan naggyá vált, hogy: a kézi rendszerekre való visszaállás gyakorlatilag lehetetlen, a felhasználók hatékonysága és eredményessége erősen függ az informatikai szolgáltatások rendelkezésre-állásától és megbízhatóságától, a szervezeti felhasználók tevékenysége az informatikán alapul, amely nélkül a szervezet működésképtelen. 7.1 A rendelkezésre-állás menedzsment megközelítése A rendelkezésre-állás menedzsment olyan megközelítés, amely optimalizálja az arányt a megelőző és a javító jellegű karbantartás és a hibák okozta költségek között. Egy meghatározott szintű korrektív és megelőző karbantartás mellett a teljes költség minimumon tartható. Az elsődleges kérdés a hibák okozta költségek és az informatikai szolgáltatásokat nyújtó összetett rendszerek megbízhatóságának 93

101 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment és karbantarthatóságának javítása közti arány optimalizálása. Ami által biztosítható a felhasználók és a szervezet rendelkezésre-állási követelményeinek teljesítése. Az informatikai szolgáltatásokat nyújtó rendszerek megbízhatóságát a következők befolyásolják: az informatikai infrastruktúra összetevők megbízhatósága és karbantarthatósága, ill. a környezet, amelyen e rendszerek alapulnak, a szállítók és külső partnerek, akik a karbantartást végzik, az informatikai szolgáltató szervezet által használt eljárások és eszközök, az informatikai szolgáltatásokat nyújtó informatikai infrastruktúra konfigurációja. Legegyszerűbb esetben az egész informatikai infrastruktúrát és a támogató szervezetet egyetlen szolgáltató biztosítja. A helyzet rendszerint sokkal bonyolultabb és az informatikai infrastruktúra szolgáltatásában és karbantartásában számos szolgáltató vesz részt. A hatékony és eredményes rendelkezésre-állás menedzsment a következő hasznokat eredményezi: az informatikai szolgáltatások javuló minőségét, az új és meglévő informatikai szolgáltatások költség-hatékony nyújtását, az informatikai infrastruktúra javuló menedzselhetőségét, jobb tervezési képességét, az informatikai szolgáltatások biztonságosabb nyújtását. 94

102 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment Felhasználó Felhasználó Felhasználó Felhasználó Felhasználók Szolgáltatási Szint Megállapodások Rendelkezésre állás IT szolgáltatások IT rendszerek IT rendszerek IT szolgáltató részleg Megállapodások Megbízhatóság és karbantarthatóság Szerződések Szolgáltatási kritériumok Szoftver fejlesztés Szoftver karbantartás Egyéb karbantartás Belső szállítók és karbantartók Hardver Alkalmazási szoftver Környezet Telekommunikáció Külső szállítók és karbantartók 23. ábra: A nyújtott informatikai szolgáltatások és a megalapozó szerződések 7.2 A rendelkezésre-állás menedzsment eljárásai A rendelkezésre-állás menedzsment funkciónak két fő felelősségi területe van: Tervezési feladatkör; azaz a rendelkezésre-állás fenntartása az informatikai infrastruktúra változásai és a felhasználói követelmények változásai közepette. Üzemeltetési feladatkör; azaz valós adatok gyűjtése és a követelményeknek való megfelelés figyelemmel kísérése. 95

103 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment Olyan eljárásoknak kell rendelkezésre állniuk, amelyek mindkét felelősségi körnek eleget tesznek. Esemény adatok Diagnosztikai eszközök Biztonság Felhasználói információ Szolgáltatási szintek Valós adatok gyűjtése Rendelkezésre állási követelmények meghatározása Rendelkezésre-állás Menedzsment Adatbázis Adat karbantartás Rendelkezésre állási terv készítése Rendelkezésre állási igény szerinti tervezés Jelentések A követelményeknek való megfelelés figyelése Rendelkezésre állási terv Tervezési kritériumok Változtatási kérelmek Jelentések Eltérési jelentések 24. ábra: A rendelkezésre-állás menedzsment áttekintése A tervezési felelősségi kör magában foglalja a következő feladatokat: Döntés a rendelkezésre-állási követelményekről; az informatikai szolgáltatások rendelkezésreállási követelményeit a szervezeti követelményekből származtatjuk. Olyan eljárásokra és eszközökre van szükség, amelyek biztosítják, hogy minden releváns követelmény az informatikai szolgáltatásokkal kapcsolatban meghatározásra és a szervezettel való egyeztetésre kerüljön. A rendelkezésre-állás tervezése; az informatikai infrastruktúra változtatások kezdeményezése és felbecslése, részvétel az új informatikai szolgáltatások tervezésében és fejlesztésében. Biztonsági szempontok tervezése; a rendelkezésre-állás menedzsment feladata, hogy kimunkálja az informatikai biztonsági irányelveket a rendelkezésre-állás viszonylatában, pl. a szolgáltatások és meghatározó informatikai infrastruktúra összetevők csak a jogosult személyek számára érhetőek el a megfelelő időtartamra és engedélyezett tevékenységekre. A rendelkezésre-állási terv elkészítése; rendszeresen tervet kell készíteni, hogy a rendelkezésre-állással kapcsolatos szervezeti követelmények hosszú távon is teljesíthetőek legyenek. A tényleges üzemeltetési feladatkörbe a következő feladatok tartoznak bele: Tényleges rendelkezésre-állási adatok gyűjtése; az egyedi összetevők tényleges állásidő adatait össze kell gyűjteni. Ezek az adatok más, a rendelkezésre-állás menedzsmenthez kapcsolódó feladatkörök bázisául szolgálnak. 96

104 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment A Rendelkezésre-állás Menedzsment Adatbázis fenntartása; a rendelkezésre-állás menedzsment adatbázis a rendelkezésre-állás menedzsment funkció központi információs tárháza. A követelményeknek való megfelelés nyomon követése; vizsgálni kell azt, hogy az informatikai szolgáltatási szervezetet megfelel-e a SzSzM-ben megállapított Rendelkezésre-állási követelményeknek; és azt, hogy a szállítók/szolgáltatók képesek-e teljesíteni a szolgáltatási kritériumokat. Jelentés a tényleges és az előre jelzett rendelkezésre-állásról. A jelentések egyrészt rendszeresen, másrészt kérés esetén is elkészítendők és terjesztendők Tervezési feladatok Döntés a rendelkezésre-állási követelményekről Az üzemeltetés megkezdése előtt a vezetés által kijelölt terjedelemben meg kell határozni a szervezetnek az informatikai szolgáltatásokkal kapcsolatos tényleges rendelkezésre-állási követelményeit. Ebbe tartozik: Az informatikai szolgáltatás állásidejének definiálása, azaz mikor állíthatja azt a felhasználó, hogy egy informatikai szolgáltatás nem képes ellátni a kívánt funkciót. Szolgáltatási idő meghatározása, azaz mikor kell az informatikai szolgáltatást nyújtani. Megbízhatósági és karbantarthatósági követelmények meghatározása. Biztonsági és jogosultsági követelmények meghatározása. A rendelkezésre-állás tervezése Új informatikai szolgáltatások esetén a rendelkezésre-állás menedzsment funkciónak kell a felhasználói követelményeket specifikációkká lefordítani a rendszerek tervezésének ill. a beszerzésének támogatására. A költségek meghatározó részét képezik e folyamatnak. Meglévő szolgáltatások esetén ugyanezen eljárások használhatók a meglévő összetevők és szerződések kapcsán annak vizsgálatára, hogy mennyire képesek ezek támogatni a szolgáltatási követelményeket. A rendelkezésre-állás javítására két fő lehetőség van: csökkenteni kell a hibánkénti állásidőt, csökkenteni kell az adott időtartamon belüli hibák számát. Az állásidő csökkentésére összpontosítva lehetséges az állásidő csökkentése: a hibák és azok tényleges észlelése között, pl. diagnosztikai eszközök, audiovizuális riasztás révén, az észlelés és a diagnózis között, pl. eredményes híváskezelési eljárásokkal, a diagnózis területén, pl. diagnosztikai eszközök alkalmazásával, teszt környezetekkel, a javítás terén, pl. a moduláris tervezés és az egyértelmű dokumentáció révén, a helyreállítás terén, pl. hatékony mentési/visszaállítási eljárásokkal, a tevékenységek újbóli futtatásának képességével, a hiba és a helyreállítás között, pl. a személyzet készségszintjének fejlesztésével, oktatásával és képzésével, kommunikációs lehetőségek biztosításával. A hibák számának csökkentése elérhető: Hibatűrő technikák alkalmazásával, pl. megengedve a rendszer elemeiben a hibák előfordulását, de közben megszüntetni azok káros hatásait automatikus újraindítási vagy újrafuttatási mechanizmusok révén, diszktükrözéssel. Megduplázott vagy alternatív rendszer elemekkel lehetővé téve, hogy a munkát a rendszer egyik elemétől egy másik rendszer eleme vegye át tartalék telekommunikációs vonalak és munkaállomások révén 97

105 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment Megbízható összetevők segítségével, pl. a rendszer-elemek tesztelésével, a szállítók és termékeik ill. szolgáltatásaik meghatározott megbízhatóság alapján történő kiválasztásával. 98

106 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment A felhasználók kezdeti rendelkezésre állási igényei Rendszer elemzés és tervezés Rendelkezésre állási modellek Elfogadott rendelkezésre állási követelmények Szolgáltatási követelmények meghatározása A megbízhatósági és karbantarthatósági követelmények meghatározása A szolgáltatási kritériumok szerzôdésbe foglalása Teszt és karbantartási program elfogadása Külső szolgáltatók A rendelkezésre-állási követelmények teljesítésének tesztje Belső szolgáltatól A rendelkezésre-állási követelményeknek való megfelelés követése 25. ábra: A rendelkezésre-állás tervezése 99

107 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment Biztonsági szempontok tervezése A kockázat elemzés és menedzsment céljára Nagy-Britanniában a CRAMM módszert ajánlják (CCTA s Risk Analysis and Management Method). Hazánkban az Informatikai biztonsági módszertani kézikönyv (8. sz. ITB ajánlás) használható erre a célra. A CRAMM módszer három szakaszra bomlik, melynek során feltérképezik és értékelik a szervezet informatikai vagyontárgyait (beleértve ebbe hardvert, szoftver és berendezéseket) meghatározzák a szervezet sebezhető pontjait és a veszélyforrásokat ellenintézkedésekre tesznek javaslatot, illetve foganatosítanak. A rendelkezésre-állás menedzsment számára nélkülözhetetlen alapinformációkat szállít a kockázatelemzés. Hasonlóan fontos a kapcsolódás a katasztrófa elhárítás tervezéssel is. A rendelkezésre-állási terv Ajánlatos évente rendelkezésre-állási tervet készíteni. Ez a terv, a kapacitás terv kiegészítőjeként figyelembe veszi az informatikai szolgáltatásokkal szemben támasztott változó követelményeket, és különféle lehetőségek szerint több forgatókönyvet tartalmaz. A terv általában a szolgáltatások szerinti bontásban készül, de természetesen megjelenhet benne az erőforrás szerinti bontás is. Utóbbi léte szükséges lehet a későbbi becslésekhez, így mindenféleképpen el kell készíteni. A terv lényegében megadja a szolgáltatásonként tervezett vagy várható állásidő nagyságát. Mivel a szolgáltatások nagyon különbözőek, nincs pro forma tervjavaslat. A terv szorosan kapcsolódik egyéb funkciók által elkészítendő tervekhez. Az alábbi lista utal arra, hogy mi lehet része egy ilyen tervnek: az informatikai szolgáltatások rendelkezésre állásának visszamenőleges áttekintése, az egyes forgatókönyvek alapfeltételezései, a költség és kapacitásvonzatok az egyes forgatókönyvek esetében, rendelkezésre állási előrejelzések, a tervben javasolt utak mindegyikének elvetéséből eredő negatív következmények. A terv általában két éves időtartamra szól, az első hat hónapra részletesebb bontásban. A tervet a rendelkezésre-állási menedzser készíti el. Első alkalommal segítség lehet, ha csupán a kritikus szolgáltatásokra szorítkozik. Felhívjuk a figyelmet, hogy ebben az esetben is csak objektíven ellenőrizhető célmutatókat érdemes kitűzni! Nincs értelme pl. 99%-os rendelkezésre állásáról beszélni, ha a meglevő adatok birtokában nem dönthető el objektíven, hogy ezt a szintet elérték-e Üzemeltetési feladatok A rendelkezésre-állási adatok gyűjtése Ahhoz, hogy az egyedi összetevők megbízhatósága és karbantarthatósága felügyelhető legyen, az első lépés az egyes komponensek állásidő adatainak gyűjtése. Ezek az adatok felhasználhatók: az informatikai szolgáltatások rendelkezésre-állásának nyomon követésére, annak nyomon követésére, hogy a szállítók megfelelnek-e a szolgáltatási kritériumoknak, az informatikai szervezet által létrehozott vagy karbantartott komponensek minőségének becslésére, a változtatások hatásának becslésére, a terveknek a tényleges eredményekkel való egybevetésére. Előre el kell dönteni, hogy melyik lesz az a legalacsonyabb szintű összetevő, amelyről tényleges állásidő adatokat fogunk gyűjteni. Ajánlatos az adatgyűjtési mechanizmus kialakítását felülről lefelé irányuló (top-down) megközelítéssel megvalósítani. A részletezési szint a következőkön alapulhat: a szállítókkal kötött szerződésekben foglalt szolgáltatási kritériumokon, a KE szint a Konfigurációkezelési Adatbázisban. Az alábbi ábra már korábban szerepelt az ajánlásban, de fontossága miatt megismételjük: 100

108 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment Állásidő Válaszidő Helyreállítási idő Észlelés Javítás Helyreállítás Esemény Diagnózis Visszaállítás Esemény Észlelésig eltelt idő Javítási idő Hibák közti idő idő Rendszer események közti idő 26. ábra: Események és mérőszámok Az állásidő adatok forrásainak elemzése A következő lépés az adatok elemzése, hogy a tényleges állásidő valamennyi összetevőre meghatározható legyen. Ez megtehető: az adatforrások meghatározásával valamennyi összetevőre, pl. diagnosztikai eszközök segítségével, döntéssel azokról a KE-ekről, amelyeknél hiányzik az adatforrás, valamennyi adatforrás értékelésével abból a szempontból, hogy megfelel-e a célnak. A következő adatelemeket kell összegyűjteni: dátum és idő, amikor a komponens nem működik, pl. egy hiba (bekövetkezési) ideje, dátum és idő, amikor a komponens üzemelni kezd, azaz a komponens sikeres helyreállításának ideje. A külső szervezet által szolgáltatott összetevők adatait a releváns szolgáltatási követelményeknek megfelelően kell gyűjteni. Ajánlatos legalább a következő adatokat összegyűjteni: Annak időpontja, amikor a külső szervezetet értesítették (call-out time). Annak időpontja, amikor a külső szervezet átadta a komponenst az informatikai szervezet számára üzemi körülmények között (üzemeltethető állapotban). Azon időadatok, amelyek egyéb szerződéses feltételekhez kötődnek, mint pl. a szolgáltató mérnök a helyszínre kell érjen az értesítést követő két órán belül ezeket szintén gyűjteni kell. Az állásidő adatok hasznos forrásai lehetnek: a hardver szállítója által adott diagnosztikai eszközök, hibanaplók, amelyeket a rendszer és az alkalmazási szoftverekkel szállítottak, speciális célú eszközök, pl. tápfeszültség elemzők, amelyek feljegyzik a feszültség-kimaradások számát és időtartamát, az esemény és probléma felügyeleti rendszer, amint az a gyorssegélyszolgálat és problémakezelés fejezetekben megtalálható. 101

109 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment A Rendelkezésre-állás Menedzsment Adatbázis A Rendelkezésre-állás Menedzsment Adatbázis a rendelkezésre-állás menedzsment funkció központi adattára, amely információkat tárol a következőkről: a tényleges állásidő adatokról az informatikai összetevőkről, a rendelkezésre-állás és a szolgáltatási képesség történeti adatairól, az informatikai szolgáltatások konfigurációjáról (pl. az informatikai szolgáltatások függése az informatikai infrastruktúra különböző összetevőitől), a rendelkezésre-állás és a szolgáltató képesség trendjeivel korreláló, azokkal kapcsolatba hozható releváns adatokról, pl. a csúcsidők, változtatások, stb. A követelményeknek való megfelelés nyomon követése Az esemény felügyelet rendszerben feljegyzett dátum és idő adatokat, amelyek a szolgáltatás felhasználó számára való elérhetetlenségére vonatkoznak, fel kell használni annak ellenőrzésére, hogy vajon az egyedi állásidő adatok, illetve a szolgáltatás állásidejére vonatkozó, az egyedi komponensek állásidejéből számított modellek helyesek-e. Az adatgyűjtés mindkét eredményét, azaz az egyedi összetevőkre és a szolgáltatásra vonatkozó állásidőket be kell mutatni. Egyikük felhasználásával jelentés készítésére lenne csupán lehetőségünk, mindkettő segítségével viszont előre jelezhetjük a változások hatását és a javulásokat. A megfigyelő és jelentéskészítő rendszerek és eljárások A rendelkezésre-állás menedzsment funkcióval való megelégedettség és a funkció eredményessége nagymértékben függ az általa készített jelentések minőségétől. Jellemzően a következőket tartalmazzák e jelentések: a Szolgáltatási Szint Követelményeknek való megfelelés adatait, a rendelkezésre-állási tervet, a szerződött partnerek megegyezéseknek való megfelelési adatait, ad-hoc jelentések és tanulmányokat (egyértelmű eljárásokat kell kialakítani utóbbiak igénylésére). Szemlézés és audit A hatékonyság és eredményesség szemléje A rendszeres szemléknek ellenőrizni kell, hogy: még mindig eredményes és hatékony módon érhetők-e el a Rendelkezésre-állás menedzsmenttől elvárt hasznok, jól vezeti-e a funkciót a Rendelkezésre-állás Menedzser, meghatározásra és kijavításra kerülnek-e a rendelkezésre-állás menedzsment funkció hibái, meghatározásra és végrehajtásra kerülnek-e a nagyobb hatékonyságot és eredményességet lehetővé tévő javítások. A sikeres rendelkezésre-állás menedzsment kritériumai Megfontolandó a következő általános szemle kritériumok alkalmazása: A vezetés elfogadja és megvalósítja-e a rendelkezésre-állás menedzsment funkció ajánlásait? Az informatikai szolgáltatások rendelkezésre-állása kielégítő-e a felhasználók számára? Az informatikai szolgáltatások rendelkezésre-állása megfelel-e a Szolgáltatási Szint Megegyezésben foglaltaknak? A rendelkezésre-állás menedzsment funkció a megfelelő információt szolgáltatja-e a megfelelő időben, a megfelelő embereknek? A rendelkezésre-állás menedzsment funkció üzemeltetési felelősségét tekintve a következő kritériumok alkalmazása megfontolandó: A szolgáltató-képességről szerződésben elfogadott megállapodásoktól (értékektől) való eltérésekről készült jelentések korrektek és időszerűek-e? 102

110 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment A kívánt ad-hoc jelentések pontosak és időben rendelkezésre állnak? Összegyűjtésre kerülnek-e a tényleges állásidő adatok, hogy segítsék figyelemmel kísérni a Szolgáltatási Szint Megállapodásnak való megfelelést és a szállítóknak a szolgáltató-képességi követelményeknek való megfelelését? A rendelkezésre-állás menedzsment funkció tervezési feladatkörének vonatkozásában a következő szemlézési kritériumok használata ajánlatos: Azonnal és helyesen becslik-e meg a változtatási kérelmek (VK) hatását a rendelkezésre-állásra? A Szolgáltatási Szint Megállapodásból fakadó rendelkezésre-állási követelmények teljesítése és követése hatékony és eredményes módon történik-e? A rendelkezésre-állás előrejelzések helyesek-e és megfelelően kerülnek átadásra? Az új rendszerek és szolgáltatások az előre jelzett megbízhatósági és karbantarthatósági szinttel kerülnek-e átadásra? A Rendelkezésre-állás terv időben készül-e, nyilvánosságra hozzák-e, és a tervezési céljára elegendő információval lát-e el? Az informatikai biztonsági irányelv követésre kerül-e? Megjegyzendő, hogy bizonyos hibák nem mindig vezethetők vissza csak a rendelkezésre állás menedzsment funkcióra. 7.3 A rendelkezésre-állás menedzsment funkció bevezetése Ahhoz, hogy kialakítsunk vagy továbbfejlesszünk egy rendelkezésre-állás menedzsment funkciót, a következő fázisokon kell keresztülmenni: kezdeményezni kell egy rendelkezésre-állás menedzsment projektet, és ki kell nevezni a projekt csapatot, megvalósíthatósági tanulmányt kell készíteni, meg kell határozni a rendelkezésre-állás menedzsment funkcióval szemben támasztott követelményeket, meg kell határozni a rendelkezésre-állás menedzsment funkció által követendő eljárásokat, létre kell hozni a rendelkezésre-állás menedzsment funkciót, megvalósítás utáni szemlét kell lefolytatni a kialakított rendelkezésre-állás menedzsment funkcióról, teljesen üzemelő rendelkezésre-állás menedzsment funkciót kell létrehozni, amely képes megfelelni a szükségleteknek. A fenti fázisok közül az első négyet a funkció tervezése összefoglaló névvel illetjük A rendelkezésre-állás menedzsment funkció megtervezése Ha a rendelkezésre-állás menedzsment eredményesen akar működni, akkor a szervezet követelményeinek meg kell felelnie. Emiatt jobb előre megtervezni terjedelmét, céljait, eljárásait és a támogató adatokat, mintsem ezek fokozatos, evolutív, spontán kialakulására hagyatkozni. Döntés a hatókörről és a célokról Az első lépés a rendelkezésre-állás menedzsment funkció terjedelmének és céljainak eldöntése. Jellegzetes célkitűzések lehetnek a következők: Az informatikai szolgáltatások rendelkezésre-állásának megtervezése és ellenőrzése, hogy az megfeleljen a felhasználók követelményeinek. Az informatikai szolgáltatások rendelkezésre-állásának javítása az igényelt minimális szint fölé, az igazolható költségkorlátokon belül. 103

111 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment A rendelkezésre-állási követelmények elérése érdekében szabványok és eljárások javaslása, bevezetése és felülvizsgálata. A SzSzM-ben meghatározott rendelkezésre-állási követelményeknek való megfelelés nyomon követése. A külső szolgáltatók megfelelése a szerződésekben meghatározott szolgáltatási kritériumoknak. Hozzájárulás a hibák megelőzéséhez. A rendelkezésre-állás menedzsment funkció terjedelme nagy, mivel az informatikai szolgáltatások rendelkezésre-állását számos tényező befolyásolja: a hardver, szoftver, hálózati összetevők és a környezeti berendezések megbízhatósága és karbantarthatósága. a hibák kijavításával és megelőzésével foglalkozó üzemeltetési szabványok és eljárások. biztonsági intézkedések, amelyek képesek megelőzni a használatra jogosult személyzetnek való károkozást vagy azok kéréseinek visszautasítását. a szerződésekben foglalt szolgáltatási kritériumok a szolgáltatókkal kapcsolatban. Rendelkezésre-állás Menedzsment Adatbázis kiválasztása A Rendelkezésre-állás Menedzsment Adatbázis funkcionalitása más informatikai infrastruktúra menedzsment adatbázisok segítségével is kiváltható, elérhető. Dönteni kell arról, hogy a Rendelkezésre-állás Menedzsment adatbázisát: a Konfigurációkezelési Adatbázis, a Kapacitás Menedzsment Adatbázis, az előző két funkció adatbázisainak kombinációja, vagy a Rendelkezésre-állás Menedzsment Adatbázis céljára speciálisan beszerzett vagy kifejlesztett adatbázis szolgáltatja-e. A megfigyelő és jelentéskészítő rendszerek és eljárások megtervezése Ahhoz, hogy képesek legyünk nyomon követni a SzSzM-ben meghatározott rendelkezésre-állási követelményeknek való megfelelést és a szállítók megfelelését a szerződésekben kikötött szolgáltatási kritériumoknak, eljárásokat és rendszereket kell kialakítani. Ezek az eljárások és rendszerek szükségesek ahhoz, hogy: A tényleges állásidő adatokból kiszámítható legyen az informatikai szolgáltatás rendelkezésreállása vagy az összetevők szolgáltató képessége. A kiszámított eredményeket validálni lehessen független számítási eljárások felhasználásával, pl. a diagnosztikai eszközök és az esemény-regisztrációs rendszer által gyűjtött adatokból számítva a rendelkezésre-állást. A konfigurációban bekövetkező, a számítási perióduson kívüli változásokat is figyelembe lehessen venni. Jelenteni lehessen az eltéréseket a meghatározott szolgáltatási szintektől. Ugyanezek a szempontok vonatkoznak a jelentési rendszerre és eljárásokra Függőségek A rendelkezésre-állás menedzsment funkció számos más funkciótól függ. A legfontosabbak a következők: A változáskezelés, amely a javítási lehetőségek csatornája és azon változások forrása, amelyek hatását meg kell becsülni. Egy megalapozott változáskezelési gyakorlat, mint pl. a tesztelés és a lehetőség a változások visszaállítására, nagyban hozzájárulhatnak az informatikai szolgáltatások rendelkezésre-állásához A problémakezelés, amely információforrás az ismételten előforduló hibákról és problémák okairól. 104

112 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment A szolgáltatási szint menedzsment és a felhasználói kapcsolattartó funkció, melyek olyan csatornák, amelyeken keresztül a felhasználói követelmények megismerhetők, megtárgyalhatók, nyomon követhetők és szemlézhetők. A kapacitásmenedzsment, amely az olyan infrastruktúra tervek fejlesztője, melyek megvalósíthatóak, megfelelnek a jövő felhasználói követelményeinek, gazdaságosak és költségeik igazolhatóak, ill. melyek segítik a rendelkezésre-állási követelményeken alapuló szolgáltatások kialakításában. A gyorssegélyszolgálat, amely információkat nyújt a hibákról és azoknak a felhasználókra és a szervezetre gyakorolt hatásáról. A számítógép üzemeltetés és hálózat menedzsment, amelyek a hibákról szolgáltatnak információkat. Rendszerint e funkciók felelősek a megelőző karbantartási tevékenységekért is. A szoftverfejlesztés, amely nagy részben meghatározza az informatikai szolgáltatások végső rendelkezésre-állását a szoftverfejlesztési fázis során hozott tervezési döntések által; döntésekkel, amelyek nem csak a szoftverfejlesztést érintik. A kapcsolat a szoftver tervezés és fejlesztés során nagyban hozzájárul az informatikai szolgáltatások megfelelő rendelkezésreállásához. A tesztelő és karbantartó funkciók, amelyek kulcsszerepet játszanak a megfelelő rendelkezésreállás biztosításában az informatikai szolgáltatások teljes életciklusa folyamán. A beszerzés, amely csatornaként szolgál a szállítókkal a szerződések megtárgyalásához, és amelyen keresztül a szolgáltatási kritériumok megszegéseinek eseteit kezelni lehet. A biztonsági funkció. A rendelkezésre-állás egyike az informatikai biztonság három alapelvének, melyek: a megbízhatóság, az integritás és a rendelkezésre-állás. A rendelkezésre-állás menedzsment ezért egyike a megfelelő szintű informatikai biztonság eléréséhez szükséges kulcstényezőknek Az emberi tényező A részleg méretétől függően teljes munkaidős rendelkezésre-állás menedzser nevezhető ki. Kisebb részlegnél ajánlatos a funkciót a kapacitásmenedzsmenttel vagy a szolgáltatási szint menedzsmenttel kombinálni. Nagyon nagy méret esetén további személyzetet kell rendelni a funkcióhoz. A rendelkezésre-állás menedzsmentje és a megelőző probléma menedzsment hasonló feladatok és emiatt a részlegek gyakran megpróbálják kombinálni a két funkciót. Gondosan kell eljárni a rendelkezésre-állás menedzsment és a problémakezelés kombinálásakor. Ha ugyanis a kombinált funkció túl sok időt fordít az esemény-, probléma- és hibafelügyeletre, akkor nem jut elegendő idő a rendelkezésre-állás menedzsment feladatokra. A személyzetnek lényegében két fő készségcsoportra van szüksége: hivatalnoki képességekre, az üzemeltetési felelősség teljesítéséhez, kreatív és interperszonális készségekre a tervezési feladatkör betöltéséhez. A funkció megvalósítása során specializált készségek is szükségesek lehetnek, mint pl. a programozási képesség az adatgyűjtési és jelentéskészítő rendszer készítése céljából. Megfelelő képzettségű személyzet rendelhető hozzá ideiglenes jelleggel a projekt csoporthoz A rendelkezésre-állás menedzsment funkció megvalósítása Két fő összetevőt kell egyidejűleg kialakítani: az eljárásokat, a funkciót támogató automatizált rendszert. Időbe telik, mire a rendelkezésre-állás menedzsment funkció teljesen működőképessé válik, főleg azért, mivel a rendelkezésre-állással foglalkozó előrejelzések minősége az elégséges mennyiségű történeti adaton alapul, amelyet először össze kell gyűjteni. 105

113 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment Dokumentáció A rendelkezésre-állás menedzsment funkció üzemeltetése során alkalmazott eljárásokat dokumentálni kell. Feltétlenül dokumentálandó: hogyan döntenek a felhasználói követelményekről, hogyan gyűjtik a tényleges állásidő adatokat, mikor és hogyan kerül megfigyelésre a rendelkezésre-állás, hogyan kezelik az eltéréseket, hogyan osztják meg a felelősségi viszonyokat, hogyan és mikor készülnek a jelentések és tervek, hogyan kell megfelelni a biztonsági követelményeknek (és hogy lehetséges megszegésük). A rendelkezésre-állás előrejelzése Eljárásokat kell kialakítani: a változások rendelkezésre-állásra gyakorolt hatásának becslésére, a rendelkezésre-állással kapcsolatos változtatások kezdeményezésére, rendelkezésre-állás tervezési tanulmányok készítésére, a rendelkezésre-állási terv készítésére és publikálására, az informatikai szolgáltatások tervezésében és fejlesztésében való részvételre. Rendszerek a rendelkezésre-állás menedzsment számára A Rendelkezésre-állás Menedzsment Adatbázist azonnal üzembe kell helyezni, mihelyt megszületett a döntés az adatgyűjtés részletezettségi szintjéről és az adatbázis-kezelő rendszerről. Az adatgyűjtési módszert a tényleges állásidő adatok meglévő, alkalmas forrásaira kell alapozni. Diagnosztikai eszközök fejlesztendők ki vagy vásárolandók azokhoz az összetevőkhöz, amelyeknél ezek költségei igazolhatóak. Modellező eszközök és modellek üzembe helyezése szükséges, hogy a rendelkezésreállás hatékony és eredményes előrejelzése lehetővé váljon. Megvalósítás utáni szemle és audit A rendelkezésre-állás menedzsment funkció eredményességét és az általa szolgáltatott anyagokat/jelentéseket szemlének kell alávetni. Kétfajta szemle lehetséges: az üzembe helyezés utáni szemle, a funkció kialakítását vagy javítását célzó projektet követően, esetleg annak részeként, rendszeres szemle a már üzemelő funkció hatékonyságáról és eredményességéről. A megvalósítás utáni szemlét a rendelkezésre-állás menedzsment projekt befejezése után néhány hónappal kell végrehajtani. A szemlének ki kell terjednie arra, hogy: milyen jól ment a projekt, pl. időben befejeződött-e, betartották-e a költségkorlátokat, a projekt elérte-e a céljait, milyen a rendelkezésre-állás menedzsment funkció eredményessége és hatékonysága, milyen tapasztalatokat lehet levonni a későbbiekre Problémák Sok szervezetben nem áll rendelkezésre a funkcióhoz szükséges tudás és tapasztalat. Az alábbiak tipikus gondok: Nehéz a funkció költségeit igazolni, hiszen lehetséges, hogy még nem állnak rendelkezésre adatok. Hiányozhat a szükséges elkötelezettség, mind a vezetés, mind az érintett személyzet részéről. Nincsenek megfelelő eszközök az adatok gyűjtésére, ami lehetetlenné teheti a Rendelkezésreállási Adatbázis üzemeltetését. A külső szolgáltatóktól való függés szintje igen magas, és nem alakul ki a kellő partneri viszony. Nehéz, vagy egyáltalában nem sikerül a szervezet valóságos rendelkezésre-állási igényeinek a meghatározása. 106

114 Infrastruktúra menedzsment Rendelkezésre-állás menedzsment Hiányoznak az egyéb funkciók, amelyek segítik a munkát. Elsősorban a konfigurációkezelés és a gyorssegélyszolgálat hiánya, vagy nem jó működése okozhat gondokat. 7.4 Ajánlott irodalom Availability Management. IT Infrastructure Library. HMSO ISBN Locks, M. O.: Reliability, maintability and availability assessment. 2nd ed. ASQC 1995, ISBN A témával foglalkozó Web-oldalak: Eszközök

115 8. Kapacitásmenedzsment A kapacitás menedzsment legfontosabb célkitűzése az informatikai szolgáltatás igényelt szintjének elérése és fenntartása megengedhető és elfogadható költségek mellett. A funkció biztosítja, hogy a jelenlegi hardver erőforrásokat optimális módon használják ki, illetve az időről-időre történő fejlesztéseket befejezzék. A funkció segíti az új rendszerek és kiegészítő hardver elemek költségeinek indoklását, így a szolgáltatások magasabb szintjének elérésében kulcsszerepet játszik. A kapacitás menedzsment felméri a várható igényeket; ezeket összeveti a jövőbeli kapacitásokkal; illetve figyelemmel kíséri a jelenlegi terheléseket és kapacitásokat, és az összegyűjtött információk alapján hosszú távon kiegyensúlyozott informatikai kapacitások létét biztosítja a szervezet tevékenységének támogatása érdekében. A kapacitás menedzsment kulcsszerepet játszik az informatikai szolgáltatási igények megértésében és azok megfelelő szintű szolgáltatásában. A kapacitás menedzsment funkció létrehozása többek között az alábbi előnyökkel jár: minőségi, konzisztens szolgáltatást garantál, ami megfelel a szervezet követelményeinek; segíti az felhasználókat abban, hogy a saját ügyfeleik számára végzett munka jó minőségű legyen; megtakarításokat tesz lehetővé az által, hogy a rendszerek bővítését az előrevetített terhelés és kapacitás alapján tervezi meg; csökkenti az előre nem látható kiadásokat azáltal, hogy a hardver fejlesztéseket előre tervezi; segít az új alkalmazások, illetve a jelenlegieknél elvégzett nagyobb módosítások költségeinek indoklásában; elősegíti a környezet jobb megértését; több időt hagy a tervezésre! 8.1 A kapacitás menedzsment tevékenységei A kapacitás menedzsment eszközei A kapacitás menedzsment számára alapvető fontosságú a mérés, azaz a megbízható adatok rendelkezésre állása. Ezt csak alkalmas szoftvereszközök segítségével lehet elérni. Rendszermonitorozó eszközök Az ilyen eszközök az egész rendszerről gyűjtenek információt, illetve valamilyen csoportosító szempont alapján. A monitorok általában úgy gyűjtik az adatokat, hogy előre meghatározott időpontokban mintát vesznek. A mintavételezés gyakoriságát általában meghatározhatjuk, mondjuk 10 percenként kérünk adatokat. A rendszerről gyűjtött mérőszámok közé tartozhat: a központi egység (CPU) kihasználtságának mértéke, a B/K alrendszer kihasználtságának mértéke, a virtuális memória kihasználtságának mértéke. További fontos szempont: az összes felhasznált CPU idő, a fizikai B/K műveleteknek összes száma, az összesített lapozási arány (paging rate), az összesített fizikai lapozási arány (swapping rate), az átlagos memória kihasználtság. Operációs rendszer szintű naplózás Az alábbi események bekövetkeztét fel kell/lehet feljegyezni Rendszerbe lépés/elhagyás, Futtatott program (job) befejeződése, 108

116 Infrastruktúra menedzsment Kapacitásmenedzsment Program befejeződése, Folyamat befejeződése. Különféle események bekövetkezése esetén gyűjthető adatok: Futtatott program/taszk/folyamat (processz) azonosítója (neve), Összes felhasznált CPU idő, Lapozási (paging) arány, Lekötött/törölt merevlemezes terület nagysága. Tranzakciós monitorok Az ilyen szoftver eszközök olyan keretrendszert adnak, ami egyszerűsíti az on-line rendszerek fejlesztésének a folyamatát. Általában leegyszerűsítik az alábbi feladatok megvalósítását: a hozzáférés jogosultság kezelését, a képernyőkezelést, a többfázisú tranzakciók kezelését, a naplózást, a helyreállítást. Példa néhány tranzakció-kezelő rendszerre: IBM CICS, ICL TPM, DEC ACMS stb. 109

117 Infrastruktúra menedzsment Kapacitásmenedzsment Kapacitás terv Költség tervezési szoftver (költség menedzsment) Szoftver méretezés Szervezeti elôrejelzések Kapacitás menedzsment adatbázis Adatbázis tervezés Szoftver modellezés Adatfeldolgozás (elemzők) Számlázási szoftver (költség menedzsment) Teljesítmény adatbázis Modell generátorok Terhelési teljesítményt nyomonkövetô eszközök Erôforrás használatot nyomonkövetôk Más teljesítmény / biztonsági szoftver 27. ábra: A kapacitás menedzsment eszközkészlete Adatbázis-kezelő eszközök statisztikái Az adatbázis-kezelő eszközök rendszerint két szinten biztosítanak részletes statisztikákat: Rendszerszinten o az adatbázis-kezelő rendszer neve/azonosítója, o a rendszer indításának és lezárásának időpontja, o puffer felhasználás, o összesített lapozási arány. Program/taszk tranzakciós szinten o Taszk/program azonosító, o mért központi egység (CPU) idő, o átlagos memória felhasználás. Hálózati statisztikák A hálózati szinten legfontosabb adat a szabad hálózati sávszélesség nagysága, melyet jellemezhetünk ütközések gyakoriságával (Ethernet esetében), egyéb terheltség mutatókkal. 110

118 Infrastruktúra menedzsment Kapacitásmenedzsment A Kapacitás Menedzsment Adatbázis A Kapacitás Menedzsment Adatbázis (KMA) az alapja a sikeres kapacitás menedzsment funkciónak. Lehet, hogy az egész adatbázis saját fejlesztéssel készül el; lehet, hogy készen kapható termék, vagy akár a két megközelítés keveréke is (ez utóbbi a legvalószínűbb). Logikailag egyetlen adatbázis álljon mindig rendelkezésre! Adattárolás Az adatok megőrzését, időtartamát figyelemmel kell követni, minthogy valószínű, hogy adatok egy hónapnál hosszabb időtartamra történő megőrzése túl költségesnek bizonyulhat mind merevlemez felhasználás, mind mágnesszalag felhasználás tekintetében. A legfontosabb az, hogy a lényeges, mért (telítettségi) mutatók értékeit legalább kétéves idősorban vizsgáljuk! Szervezeti tevékenységgel kapcsolatos adatok Kísérjük figyelemmel azokat az adatokat, melyek befolyásolják a terhelést, mint például: a rendszer használatára jogosult felhasználók számát, a felhasználók számát, a rendszert egyidejűleg használók átlagos számát Jelentések A jelentések két fő fajtája a vezetői és a műszaki jellegű jelentés. Részletes műszaki jelentéseket kell készíteni a problémák és a teljesítmény átfogó vizsgálata során. Vezetői jelentéseket hetente/havonta kell készíteni, melyek az eltelt időszakra vonatkoznak. Az ilyen jelentések legyenek a lehetőségekhez képest minél egyszerűbbek, és lényegre törők. A szakzsargon használatát korlátozzuk a minimálisra, és gondoskodjunk arról, hogy a jelentés a felhasználók számára érthető fogalmakat használjon. Mind a műszaki jellegű, mind a szervezet alaptevékenységéhez kapcsolódó adatok esetében idősorosan kell az adatokat gyűjteni, ami az előrejelzés számára lesz majd fontos kiindulási adat. 111

119 Infrastruktúra menedzsment Kapacitásmenedzsment Pénzügyi adatok Hardver adatok Pénzügyi adatok Szervezeti adatok Műszaki adatok Katasztrófaelhárítási adatok Szolgáltatási adatok Teljesítmény menedzsment Inputok Erôforrás menedzsment Terhelés menedzsment Kapacitás menedzsment adatbázis Igény menedzsment Alkalmazás méretezés Outputok Modellezés SzSzM irányvonalak Jelentések Tuning adatok Elôrejelzések Kapacitás terv 28. ábra: A kapacitás menedzsment elemei Szolgáltatási szint megállapodás Szoros kapcsolattartásra van szükség a kapacitás menedzser és a szolgáltatási szint menedzser között, hiszen a kapacitás menedzsmenttel foglalkozó részleg biztosítja azokat a mérőszámokat, melynek alapján a szolgáltatási szint menedzser el tudja érni azt, hogy a szolgáltatási szinteket el lehessen érni és tartani Költség menedzsment A kapacitás menedzsmenttel foglalkozó részleg feladata annak biztosítása, hogy minden, általa gyűjtött, a költségelszámoló és számlázó rendszerhez szükséges adat rendelkezésre álljon (az érintett rendszerek számára). 112

120 8.1.6 Teljesítmény menedzsment Infrastruktúra menedzsment Kapacitásmenedzsment Tuning Megvalósítás (Változás kezelés útján) Analízis Nyomonkövetés SzSzM küszöbszintek SzSzM alóli kivételek jelentése Kapacitás menedzs adatb. 29. ábra: A teljesítmény menedzsment folyamatai A teljesítmény menedzsment legfontosabb célkitűzése a problémák előzetes felismerése a rendszer folyamatos figyelemmel kisérése (monitorozása) által, miközben az előzetesen egyeztetett teljesítmény szint rendelkezésre állását biztosítják. Megkülönböztetett figyelemmel kell kezelni a válaszidőket. A funkció működéséhez szükséges a Kapacitás Menedzsment Adatbázis. A gyakorlatban indulásképpen a teljesítmény menedzsment a már használatban levő mérési módszerekre és jelentésekre támaszkodik. Az alábbi jelentések különösen fontosak: rendellenesség (exception) jelentés, alsó-felső tűréshatár túllépésének jelentése, teljesítmény kihasználtsági trendek (két éves idősorra), A végső célkitűzés egy teljesen kiegyensúlyozott rendszer elérése, amiben nincsenek szűk keresztmetszetek! Teljesítményhangolás az operációs rendszer szinten Ez a tevékenység a CPU, a memória és a B/K alrendszer eredményes és kiegyensúlyozott használatára irányul, amelynek úgy kell kihasználnia a virtuális memóriakezelő architektúrát, hogy az ne menjen a teljesítmény kárára. Keressük meg a memória rezidens operációs rendszer, a rendszer programok és az alkalmazások optimális egyensúlyát. Megfelelő memória-felhasználási korlátokat jelöljünk ki a programok számára. Alkalmas felhasználási korlátokat (kvótákat) állítsunk fel. 113

121 Infrastruktúra menedzsment Kapacitásmenedzsment Teljesítményhangolás hálózat szinten Ez a tevékenység a számítógépeket összekötő hálózat optimális forgalmának kialakítására koncentrál. A hálózatokat megfelelően kell szegmentálni a szükséges sávszélesség biztosítása érdekében. Ez a terület az elosztott feldolgozás elterjedésével egyre nagyobb jelentőséget nyer. Teljesítményhangolás alkalmazás szinten Ez a tevékenység az alkalmazások fejlesztővel illetve karbantartóival folytatott kapcsolattartásra koncentrál. Feltétlenül közös munka legyen! A vizsgálandó területek: a nem hatékony kódrészek megkeresése, javítása, adatbázis navigáció vizsgálata, kumulált erőforrás-kihasználtság vizsgálata, B/K tevékenységek vizsgálata, CPU használat vizsgálata, adatbázis igénybevétel módjának vizsgálata, egyebek, pl. zárolás (locking) és sorbaállás (queuing) Terhelés menedzsment Egy egyszeri, konkrét terhelés a teljes terhelésnek a része. A terhelés kialakulását, lefolyását, az azt befolyásoló tényezőket ismerni és érteni kell. Ez segíti majd a várható terhelés előrejelzését. A terhelések megismerése Csoportosítsuk a teljes terhelésben szereplő elemeket. Vizsgáljuk meg a szervezeti tevékenységeket, azokat az időpontokat, amikor a munkaterhelés maximális, illetve minimális. Állítsunk össze terhelési katalógust a Szolgáltatási Szint Megállapodásbeli szolgáltatási katalógus segítségével. Válasszuk szét az interaktív és a kötegelt részeket! Valamennyi érintett fél értse a terhelés katalógust! Elemezzük és értsük meg a terhelésben jelentkező trendeket! Készítsünk erőforrásonként kihasználtsági táblázatokat! Tegyük közzé a katalógust, és negyedévente frissítsük a tartalmát! 114

122 Infrastruktúra menedzsment Kapacitásmenedzsment Terhelések osztályozása Terhelési katalógus Jelenlegi terhelések Új terhelések Kapacitás adatbázis Szervezeti igények Csúcsterhelés elemzés Szolgáltatási szint menedzsment Elôrejelzések Modellezés 30. ábra: A terhelés menedzsment folyamatai A terhelések előrejelzése Kizárólag múltbeli trendekre támaszkodni a jövőbeli igények előrejelzése során igen veszélyes. Ez az út csak akkor járható, ha a terhelés jellege pontosan ugyanolyan, mint amilyen a múltbeli volt. A várható terheléseket negyedévente javallott felmérni. Ennek során figyelembe kell venni: a szervezet növekedését/csökkenését, a személyzet létszámában beálló változásokat, a közelmúltbeli igényeket, a legkisebb és legnagyobb terheléseket, új szolgáltatások megjelenését. Az előrejelzések kialakítása során figyelembe veendő: a felhasználóktól származó információk, az informatikai vezetéstől származó információk, az átvitel és az erőforrás-kihasználás idősoros trendjei, a jelenlegi alkalmazások erőforrás-felhasználási táblázatai, az új alkalmazások ismerete, a tervezők tapasztalata Alkalmazások méretezése Ennek az alfunkciónak a célkitűzése az, hogy elősegítse az alkalmazások költségigényének indoklását, illetve előkészítse annak eldöntését, hogy egy igényelt szolgáltatási szint egyáltalán kielégíthető-e. A hardver követelmények elhibázott előzetes felmérése az egyik fő oka annak, hogy olyan sok esetben sikertelen a kielégítő szolgáltatási szintek elérése. A méretezés ennélfogva a fejlesztési 115

123 Infrastruktúra menedzsment Kapacitásmenedzsment életciklus lényeges, el nem választható része, és nem tekinthető a fejlesztési projektre rótt külön teherként. Az első lépések egyike az legyen, hogy szemlézzük a jelenlegi fejlesztési (belső) szabványokat, és vizsgáljuk meg, hogy ezek miképpen illeszkednek bele az alkalmazás-fejlesztési életciklusba. Vegyük figyelembe: a szervezeti funkciót, leírását, a feldolgozás típusát, milyen jellegű a funkció (módosít vagy lekérdez), gyakoriságát, a tranzakciók átlagos számát, a B/K üzenetek átlagos méretét, a logikai hozzáférések számát, a fizikai hozzáférések számát, a tároló igényeket Erőforrás menedzsment A fizikai erőforrások esetében szükséges a megfelelő menedzselés alkalmazása (pl. új hardver vagy az operációs rendszer új változatának üzembe helyezése). A hardver és szoftver leltárok részei lehetnek a Kapacitás Menedzsment Adatbázisnak. Ebbe akár egy konfigurációs diagram is beleérthető, ami a hardver és szoftver erőforrások kiesése következményeinek értékelésére szolgál Igény menedzsment Az igény menedzsment a felhasználói elvárások kezelését fedi. A feladat elsősorban jó kommunikációs készségeket igényel, hiszen a kapacitás menedzsernek az objektív lehetőségek ismeretében kell a felhasználókkal igényeiket és követelményeiket egyeztetnie. Az igény menedzsment munkája alapozza meg az informatikai részleg hosszú távú szavahihetőségét annak elérésével, hogy az igények és a nyújtott szolgáltatások a költséghatárokon belül találkoznak Modellezés A kapacitás menedzsment egyik fontos segítője a modellezés. A kapacitás tervezés során felhasználható technikáknak a légből kapott becslésektől a pilot alkalmazásokon végzett mérésekig terjedő skáláján vannak köztes megoldások is, melyek a vad becsléseknél kevésbé kockázatosak, a pilot alkalmazásokhoz képest viszont kevésbé költségesek. Ilyen módszer: a trendelemzés, az analitikus modellezés, a szimuláció. A trendelemzés a múltbeli adatokból indul ki, és a status quo feltételezése (vagy a környezetre vonatkozó egyéb feltételezés) mellett lehet belőle a jövőbeli adatokra következtetni. Matematikai modellezési eszközök felhasználása esetében beszélünk analitikus modellezésről. Az itt használt eszközök elsősorban az operációkutatás tárgyköréből származó sorbaállás-elmélet eredményére támaszkodnak. A vizsgált rendszerről modellt kell készíteni, melynek részeire feltételezésekkel kell élni. Szimulációs módszerek használata esetében diszkrét eseményeket modelleznek, pl. tranzakciókat. A vizsgált rendszert le kell írni egy alkalmas modell segítségével, majd generálni kell a szimulált input adatokat A kapacitás terv elkészítése A terhelés előrejelzési folyamatnak a végterméke a kapacitás terv lesz, aminek tartalmaznia kell: a szolgáltatás értékelését a ráfordítások fényében az utolsó 12 hónapra, a fontosabb feltételezéseket, a terhelések előrejelzését, a kiegészítő (beszerzendő) hardver és szoftver komponenseket, a frissítések (új verzióra történő áttérések) költségeit, 116

124 Infrastruktúra menedzsment Kapacitásmenedzsment a szolgáltatás várt szintjeit (mérőszámokkal), az összesített költségeket, a kiesések következményeit Szemlézés és audit Teljesítmény menedzsment Néhány szemlézési szempont: A szolgáltatások monitorozásának gyakorisága. Használnak-e valós idejű figyelemmel kísérő technikákat, melyek lehetővé teszik a problémák közvetlen diagnosztizálását és a helyreállítást? Miképp alakul a kihasználtság (ha valós idejű adatok nem állnak rendelkezésre, idősoros adatokat kell használni)? Ne legyenek értelmetlen adatok! Vezetői jelentéstétel Néhány szemlézési szempont: Milyen gyakorisággal készülnek a jelentések? Használnak-e grafikus megjelenítési módokat? Tükröződik-e a szervezet terhelése? Terhelés előrejelzés Néhány szemlézési szempont: Az előrejelzések gyakorisága. Az információgyűjtés módja. A jelentések stílusa (szakzsargon mellőzése!) Kapacitás terv Néhány szemlézési szempont: Terv készítésének gyakorisága Megfelel-e a költségvetés tervezésnek Figyelembe veszik-e? Sikerül-e a megfelelő hallgatóságot megcélozni? Alkalmazások méretezése Néhány szemlézési szempont: Végeznek-e méretezést az új alkalmazásoknál? Tudnak-e a nagyobb változásokról Minden szükséges információ rendelkezésre áll-e A megfelelőség auditálása Egy független, akár külső, akár belső nem-informatikus auditornak át kell tekinteni a kapacitás menedzsment funkció működését legalább évente egyszer. A vizsgálandó kérdések az alábbiak: Eredményes-e a kapacitás menedzsment funkció? Sikeresen tartják-e a kapcsolatot az érintett területekkel? Használnak-e megfelelő monitorozó eszközöket? A teljesítményt vajon rendszeresen és eredményesen kísérik-e figyelemmel? A lényegesebb hangolási tevékenységek eredményeként létrejött hasznokat felmérték-e? Kielégítő-e a kapacitás menedzsment adatbázis tartalma és integritása? A jelentések pontosak-e, rendszeresen készítik-e őket, és nyilvánosságra hozzák-e őket? A terhelés katalógus pontos és naprakész-e? Készítenek-e rendszeresen terhelés előrejelzést? 117

125 Infrastruktúra menedzsment Kapacitásmenedzsment A kapacitás terv megfelel-e a vezetés elvárásainak? A szabványokat és eljárásokat betartják-e? 8.2 A kapacitás menedzsment funkció bevezetése A tervezés tervezése A kapacitás menedzsment bevezetését körültekintő tervezésnek kell megelőznie, ami megalapozza a funkció sikeres bevezetését. Kiinduló tervezés Az első szakasz feladata a jelenlegi helyzet tanulmányozása, melynek megállapításait össze kell vetni a kapacitás menedzsment funkció egyeztetett hivatkozási alapjával. Ez a tevékenység hozzávetőlegesen hat-nyolc hétig tart, és elsősorban a kapacitás menedzser végzi el. A jelenlegi helyzet felmérése. Készítsünk interjúkat a felhasználókkal, az informatikai vezetéssel, a számítógépeket illetve a hálózatot üzemeltető személyzet tagjaival, az alkalmazásfejlesztő csoport képviselőivel azért, hogy értékeljük a szolgáltatást nyújtó és az azt élvező emberek véleményét, nézeteit. Azonosítsuk a mérőszámok fajtáit! A használt mérőszámok felmérése során a szervezet alaptevékenységét jellemző adatok ugyanolyan fontosak, mint a műszaki jellegű adatok. A szolgáltatási szintekben szereplő célkitűzések mérőszámai tipikus példái a szervezet alaptevékenységéhez tartozó adatokra. Tekintsük át az elemzés folyamatát! Vizsgáljuk meg azokat a szoftvereket, melyekre szükség lesz a kapacitások és követelmények elemzése során. Az elemzés kiterjed a teljesítményre, a hardver elemek kihasználtságára és a szervezeti tényezőkre. Az elemzés folyamán használhatunk statisztikai modellezési eszközöket és sorbaállás-elméleti modelleket is. Készítsünk összefoglalót a vezetés számára! A kiinduló tervezés végén jelentést kell készíteni a vezetés számára, ami röviden áttekinti a kapacitás menedzsment funkció bevezetésének szakaszait A kapacitás menedzsment bevezetésének szakaszai Az alábbiakban a kapacitás menedzsment funkció bevezetésének egy tipikus lépés-sorozatát tekintjük át. Az első négy szakasz sorrendjét nem ajánlatos megváltoztatni. A nyomon követő (monitor) és szoftver eszközök szemlézése (amennyiben ez nem történt meg már a kiinduló tervezés során). A teljesítmény menedzsment alfunkció bevezetése. A Kapacitás Menedzsment Adatbázisának (KMA) létrehozása, feltöltése; illetve a fontosabb vezetői jelentések útjának kialakítása. A terhelés menedzsment alfunkció bevezetése. Az új alkalmazások méretezésének bevezetése. A szolgáltatási szint menedzsment funkció bevezetése, illetve a hozzá való kapcsolódás. Költség-elszámolási rend felállítása. Erőforrás menedzsment alfunkció bevezetése. A kapacitás tervezés gyakorlatba vitele. A nyomon követő és a szoftver eszközök szemlézése A nyomon követő (monitor) eszközöket körültekintően értékelni kell abból a szempontból, hogy megfelelnek-e a helyi igényeknek, még mielőtt a választást illetően döntésre jutnánk és a választott eszközt ténylegesen bevezetnék. Fontos, hogy a monitorozó eszköz értékelése és megvásárlása előtt a kapacitástervező ismerje meg a fontosabb fogalmakat és modellezési koncepciókat! 118

126 Infrastruktúra menedzsment Kapacitásmenedzsment Figyelem-felkeltési kampány kezdeményezése A kezdő figyelem-felkeltési kampány elsődleges célpontja a szervezet rangidős vezetése volt. Az alkalmazások méretezése célkitűzéseinek elérése érdekében további kampányra van szükség, melynek célpontjai mind a kapacitások tervezői, mind az alkalmazások méretezői. A kampány során hangsúlyozni kell a két oldal együttműködését az alábbi okok miatt: a kapacitás menedzsment háttere miatt, a kapacitás menedzsment szükségessége miatt, a kapacitás menedzsment előnyei miatt. Szolgáltatási szint megállapodás Szoros kapcsolattartásra van szükség a kapacitás menedzser és a szolgáltatási szint menedzser között, hiszen a kapacitás menedzsmenttel foglalkozó részleg biztosítja azokat a mérőszámokat, melynek alapján a szolgáltatási szint menedzser figyelemmel kísérheti a szolgáltatási szintek elérését és betartását. Személyzet A kapacitás menedzsmenttel foglalkozó emberek számára elsősorban a hálózatok, az üzemeltetés, az alkalmazásfejlesztés területéről származó tapasztalatok és háttérismeretek szükségesek; esetleg némi számviteli ismeretekkel kiegészítve. Fontos a szervezeti alaptevékenység alapos ismerete. A kapacitás menedzsmenttel foglalkozó részleg feladatait két részre bonthatjuk: teljesítmény menedzsment, és kapacitástervezés. Teljesítmény menedzsment A teljesítmény elemzők felelősek a jelenlegi rendszerek folyamatos figyelemmel kíséréséért, hangolásáért illetve a kapacitás menedzsment adatbázis kézbentartásáért. Valószínű, hogy ezek az elemzők rendelkeznek üzemeltetői és/vagy rendszerprogramozói háttérrel. Kapacitástervezés A kapacitás tervező csapat létszáma változni fog az adott környezet mérete és jellege függvényében. Legalább két ember szükséges a kulcstevékenységek ellátásához. Készségek A kapacitástervezőnek műszaki és interperszonális képességek keverékére van szüksége. Ezek közül néhány: jelentéskészítési gyakorlat, előadó-képesség, külsők által készített termékek ismerete, modellezési technikák ismerete, az informatika fontosabb kérdéseinek átfogó ismerete, elkötelezettség, türelem, kommunikációs készségek. Felelősségek A kapacitás tervezői legalább négy területtel foglalkoznak: biztosítják, hogy a szolgáltatási szint megállapodások megvalósíthatóak és betarthatóak legyenek, megvalósítják a figyelemmel kísérés folyamatát, kapcsolatot tartanak az alkalmazásfejlesztőkkel a hardver és szoftver méretezése és szolgáltatási szint megállapodásra gyakorolt hatások felmérése érdekében, értékelik a változások hatását az előre megállapodott szolgáltatási szintekre. 119

127 Infrastruktúra menedzsment Kapacitásmenedzsment Megvalósítás Egy átfogó kapacitás menedzsment funkció felállítása időigényes feladat, várhatólag 18 hónapot vesz igénybe, de ez persze függ a szervezet nagyságától és bonyolultságától. A legjobb a szakaszokra bontott, feszesen követett bevezetési mód, mely mögött az a gondolat húzódik meg, hogy a kapacitás menedzsment munkája megelőző jellegű legyen, és ne szorítkozzon pusztán a válságkezelésre Megvalósítás utáni szemle és audit A kapacitás menedzsment funkció eredményessége és hatékonysága folyamatos, kritikus hangvételű szemle tárgya kell legyen. A kapacitás menedzsment számára két alapvető kérdést kell feltenni: Vajon minőségi szolgáltatásokat nyújtunk a felhasználóinknak? Vajon időben biztosítjuk-e a helyes információt a megfelelő formában? Problémák Ahol nincsen kapacitás menedzsment funkció, az a szervezet nagy valószínűséggel pazarló módon használja fel erőforrásait, illetve nem képes a felhasználók igényeinek következményeit felmérni! Ez pedig gátja a minőségi informatikai szolgáltatások nyújtásának. A funkció bevezetésének és működtetésének sikerességét számos tényező veszélyezteti. Ilyenek: a túlzott elvárások, mert ez mind a felhasználók, mind az informatikai személyzet oldalán csalódottságot eredményezhet, a bevezetés a nem eléggé alapos tervezése; beleértve ebbe az egyeztetett célkitűzések értelmezését, az előállítandó termékek, a költségek, a szükséges személyzet és időhatárok ismeretét, a kommunikációs problémák, melyek megoldásával elősegíthető a jobb együttműködés, az elkötelezettség hiánya; elkötelezettség feltétlenül szükséges a felhasználók, a szervezet vezetése az informatikai vezetés és személyzet részéről. 8.3 Ajánlott irodalom Capacity Management. IT Infrastructure Library. HMSO 2 nd ed ISBN Cady, J. Howarth, B.: Computer System Performance Management and Capacity Planning. Prentice Hall (Sd), 1990, ISBN: Cervone, H. F.: Solaris Performance Administration: Performance Measurement, Fine Tuning, and Capacity Planning for Releases and 2.6. McGraw Hill (Tx) ISBN: A témával foglalkozó Web-oldalak: Szoftverek:

128 9. Költségmenedzsment A költségmenedzsment minden szervezet számára fontos tevékenység. Legyen az informatikai szolgáltatás technikai szempontból bármilyen jó, elégítse ki maximálisan a szervezeti igényeket, mindez mit sem ér, ha elviselhetetlenül magas költségekkel jár együtt. A szervezeti szempontból jó, minőségi informatikai szolgáltatások ismérve az igényeknek megfelelő technikai színvonal és szolgáltatási minőség elfogadható szintű költségek mellett. Az informatikai szolgáltatások menedzsmentje tehát nem csak műszaki, szervezeti és minőségi felügyeletet jelent, hanem pénzügyi felügyeletet is. Ha egy szervezet eredményes kíván lenni, és terveznie kell, akkor részletes ismeretekkel kell rendelkeznie a költségeiről, a felhasznált erőforrásokról és tudnia kell azt is, hogy a termékeit és szolgáltatásait vajon gazdaságosan állította-e elő. Ha mindezeket eredményesen végzik el, akkor a rendszerek által hajtott hasznok az informatikai szolgáltató részleg, illetve a tágabb értelemben vett szervezet számára kézzelfoghatóak lesznek, és a fellépő költségek indoklása egyszerűbb feladat lesz. Működtetése érdekében rendszereket kell létrehozni, melyek segítik a munkájában. Minthogy e rendszerek felállítása általában maga is költségekkel jár, éppen ezért fontos, hogy a megfelelő rendszer kerüljön megvalósításra, és a személyzet értse a helyes használat módját. A költségmenedzsment funkció tervezése talán a leglényegesebb része az új elképzelések sikeres megvalósításának. A funkció során olyan számviteli rendet kell felállítani, ami hitelesen tükrözi a szervezet számára az informatikára fordított költségeket, azok megoszlását. Magyarországon manapság nem tipikus az, hogy egy informatikai szervezeti egység maga építse fel számviteli rendjét, éppen ezért a saját céljait sem tudja megjeleníteni benne. A felhasználók egyre nagyobb mértékben függenek az informatikai szolgáltatásoktól. Napi munkájuk során használják termékeik és szolgáltatásaik eredményes és gazdaságos előállítása érdekében. Minthogy az informatika kezd mindent áthatni, egyre inkább hatást gyakorol a szervezet pénzügyi helyzetére is. A költségmenedzsment a költség-elszámolási és az esetleges számlázási követelmények kialakításával segíti az informatikai szolgáltató részleget abban, hogy képes legyen a szolgáltatások kapcsán felmerülő költségeket hosszú távon is kézben tartani, a szervezeti szükségletekkel összhangban. Mindazok számára, akik informatikai szolgáltatásokat vesznek igénybe, a költségmenedzsment lényeges információkat ad a szervezet számára és arról, hogy mekkora költségek léptek fel tevékenységük kapcsán. Ezenkívül kiindulási alapot ad a számlázási folyamatok számára. A költségmenedzsment szisztematikus megvalósítása az alábbi hasznokkal jár: Felméri az informatika alkalmazásának pénzügyi következményeit a szervezet számára. Ennek ismerete befolyásolni fogja a szervezet viselkedését, illetve cselekvési irányát. Strukturált megközelítési módját adja az informatikai szolgáltatások pénzügyi tervezésének. Lehetővé teszi az informatikai szolgáltatások változtatása és támogatása költségeinek indoklását. Általában a költségelszámolás jobb megértéséhez vezet. A későbbiekben a hasznokat még mélyebben is részletezni fogjuk. 9.1 A költségmenedzsment funkció A költségmenedzsment funkció struktúrája A költségmenedzsment funkció legfőbb célkitűzése egy olyan költség-elszámolási rendszer létrehozása, működtetése és karbantartása, amely a szervezeten belül optimális szinten működik. A költség-elszámolási és a számlázási rendszerek alapelvei viszonylag egyszerűek: A költség-elszámolási rendszert arra használjuk, hogy kimutassuk az informatikai szolgáltató szervezeti egység számára, hogy milyen célból mennyi pénzt költöttek el és fognak elkölteni, a javasolt kiadások vajon elfogadhatóak-e és így a szolgáltatások gazdaságosak-e. 121

129 Infrastruktúra menedzsment Költségmenedzsment A számlázási rendszer az informatikai kiadásoknak a felhasználóktól származó fedezetének a megteremtésével foglalkozik A költségek felosztása Az informatikai szolgáltató szervezeti egység által kifizetendő költségeket több szempont alapján csoportosíthatjuk. Minden szempont mögött más-más indíték rejlik. Beruházások Szétválaszthatjuk a költségeket finanszírozási forrásuk alapján (ez a brit számvitelre jellemző bontás) Beruházási költségek. Ezek általában állóeszközök, pl. számítógépek, épületek, vagy akár szoftver eszközök. A szolgáltatások költségeinek számítása során rendszerint amortizálják ezeket a költségeket. A megfelelő amortizációs eljárást kell kiválasztani (amit a jogszabály lehetővé tesz). Egyéb költségek. Ezek közé tartoznak a napi költségek, mint pl. személyzet, hardver karbantartás, elektromos áram stb. Közvetlen és rezsi költségek A költségeket csoportosíthatjuk az alábbi szempontok alapján is közvetlen költség, azaz hozzá lehet rendelni egy konkrét szolgáltatáshoz vagy folyamathoz, rezsi költség, amit fel kell osztani a szolgáltatások között, pl. a vezetők bére stb. (indirekt költség), transzfer költség, ahol egyezség született arról, hogy ezeket a költségeket a felhasználó fogja viselni. Költséghelyek Ha van közvetlen okozója költségeknek (azaz közvetlen költség), akkor gyakran érdemes ezt követni mélyebb bontásban is. Ilyenkor a költségeket hozzá kell rendelni szabványos költséghelyekhez. Például ilyenek: (hardver) eszközre terhelt költség (ECU, equipment cost unit), ami tartalmazza a berendezés részeinek, karbantartásuknak, működtetésüknek költségeit és egyéb költségeket; szoftverre terhelt költség (SCU, software cost unit) ami tartalmazza a szoftver elemek költségeit, akár vásárolták, akár fejlesztették őket, valamint a karbantartási és más költségeiket; szervezetre terhelt költségek (OCU, organisation cost unit), mindazon költségek melyek az informatikai szolgáltató részleggel kapcsolatosak, mint pl. a személyzet bére, kiképzési költségek stb. elhelyezéssel kapcsolatos költségek (ACU, accommodation cost units), mindazon költségek, melyek az informatikai szolgáltatások biztosításához szükséges elhelyezési és környezeti feltételek biztosításához kellenek, mint pl. elektromos áram, helységbérleti díj stb. átruházandó költségek, (TCU, transfer cost units) minden olyan költség, melyről megállapodás született a felhasználóval, hogy közvetlenül őt fogja terhelni. A költségelszámolásról szóló, széles körben elérhető számviteli kézikönyvek és a szervezet jelenlegi számviteli rendje segíthetnek a költségfelosztás megtervezésében és elvégzésében. A költségekkel kapcsolatos adatok forrásai A következő lépés az adatok forrásainak felderítése, melyek lehetnek részletes költség adatok (pl. főkönyv, költséginformációk a Konfigurációs Menedzsment Adatbázisból, számlák a beszállítóktól), terheléssel kapcsolatos adatok (pl. név, rész, felhasználó, jellemzők, összetevő), erőforrás-felhasználási adatok, a terhelhető erőforrásoknak mind a jelenlegi, mind a várt használata. Ki kell választani azokat a mérési egységeket, melyeket segítségével figyelemmel kísérik és előrejelzik az erőforrások felhasználását. 122

130 Infrastruktúra menedzsment Költségmenedzsment Költségkimutatási módszerek Eljárásokat, rendszereket és módszereket kell meghatározni, amelyek dokumentálják, hogy hogyan, hol és mikor kell a tevékenységekkel és funkciókkal kapcsolatos költségeket elszámolni. A lehetőség szerint minél jobban támaszkodjunk a szervezet jelenlegi irányelveire. A vezetői információk előállításához lehet, hogy többféle költség-kimutatási módszer használata szükséges, melyek, habár azonos adatokat használnak kiindulásképpen, az informatikai költségeket más és más szempontból világítják meg, pl. az informatikai szolgáltatás költségei, lényegében a felhasználók számára nyújtott szolgáltatás költségei, az információs rendszerek költségei, melyek bemutatása hasznos lehet döntéshozatal előtt, pl. frissítés, átdolgozás esetében, minőséggel kapcsolatos költségek, a meghibásodásból eredő költségek, illetve a megelőzés és értékelés költségei, technológiai költségek, ezt az információt jól lehet használni befektetési döntések előtt. A költségek értelmezése alapvető egy eredményes költségmenedzsment funkció bevezetése során. Ha már az összesített költségek ismeretesek, akkor meg kell becsülni az egyes vetített költségeket. Annak érdekében, hogy ellenőrizni tudjuk a vetített költségek nagyságának helyességét, megfelelő monitorozó rendszereket és eljárásokat kell kialakítani A számlázás Számlázás szempontjából megkülönböztethetjük az elszámolási rendszerek három típusát: Önelszámoló számítóközpont, azaz egy autonóm egység, melynek pénzügyi és szervezeti céljait a szervezet jelöli ki. Tipikus célkitűzés lehet a profit maximalizálása, a költségvetés bizonyos százalékának elérése, vagy null szaldó elérése. Költségcentrum, azaz olyan szervezeti egység melynek ismernie kell az összes gazdasági költségeit, demonstrálnia kell, hogy eredményesen és hatékonyan működik, és esetlegesen fedezhetik a költségeit más szervezeti egységek. Olyan szervezeti egység, melynek csak egyszerű elszámolást kell készítenie. Elszámolási módok Az elszámolás módja szerint megkülönböztetjük a következő eseteket: nincs elszámolás, az informatika rezsiköltségként kerül terítésre, elvi számlázás, valóságos, igazi számlázás. Árképzési elvek Valóságos számlázás esetében árakat kell meghatározni. Ehhez az árképzési elv többféleképpen kialakítható, lehet szabvány költség alapú, gördülő rátás, tervezett árbevétel szint számított, kialkudott ár, stb. Felhívjuk a figyelmet, hogy a fenti megközelítések mind-mind más célt szolgálnak, más irányba terelik a felhasználók és szervezet mozgását. A vezetőknek először a célt kell megjelölniük, és csak utána szabad a fenti eszközök közül választani! A költség-elszámolási tervek és jelentések A költségmenedzsment funkciótól elvárt terveket és jelentések sokfélék lehetnek, és (ismételten) a vezetés konkrét céljaitól függnek. Ilyen előírt jelentés lehet például: rendszeres jelentés az informatikai részleg készpénzáramáról (cash flow), rendszeres jelentések a költségfelhasználásról, előírt bontásban, az informatikai részleg eredmény-kimutatása és mérlege, 123

131 Infrastruktúra menedzsment Költségmenedzsment az egyéb tervekben szereplő költséggel kapcsolatos fejezetek, a költség előrejelzések, melyeket az elfogadott informatikai stratégia alapján származtatnak A költségmenedzsment munkáját segítő eszközök A költségmenedzsment esetében az alábbi öt területen lehet szükség eszközök használatára: jelentés készítés, tervezés, speciális alkalmazások, adatbázis (a konfigurációkezeléssel együtt), adatrögzítés. Sok terület van, ahol szükséges az adatok rögzítése. Az adatrögzítő eszközöket az alapadatok bevitelére tervezték, az alábbi területeken: terhelés, kihasználás, szolgáltatási szintek, költségek, erőforrás használat, pl. munkaóra, merevlemezes terület. Az adatbázis kezelő eszköz (ami lehetőség szerint egyezzen meg a konfiguráció kezelés által használt Konfiguráció Kezelési Adatbázissal) a tároló helye az adatrögzítő eszközök által bevitt információknak. Tartalmazza ezenkívül még: az erőforrás, leltári és költség információkat, a leszállítandó termékekről adatokat, a bevételeket. A költségmenedzsmentet támogató eszközök piacán jelenleg számviteli csomagok találhatók nagyobb mennyiségben, melyek gyakran kapcsolatban állnak költség-elszámolási rendszerekkel, viszont nem támogatják a számlázást. Az iparban számos alkalmazást fejlesztettek ki az egyedi igényekhez és követelményekhez illeszkedően. A szoftver eszközök előnye abban rejlik, hogy használatukkal időt takaríthatunk meg. Ugyanakkor, az egyes csomagok nem mindig illeszkednek egy szervezet egyedi igényeihez. Ezen túlmenően egyes csomagok használata mélyebb számviteli ismereteket igényel, ami az erőforrások pazarlásához vezet A költségmenedzsment haszna A költségelszámolás és a számlázás más-más területekhez kötődik, ezért másfajta hasznok származnak létükből, és eltérő problémák merülhetnek fel velük kapcsolatban. A költségelszámolás A költségelszámolás hasznainak értékelése során fontos a költségelszámolás bevezetése mögötti célkitűzések ismerete. A költségelszámolás legfőbb célkitűzése megfelelő részletezettségű vezetői információk előállítása, amelyek lehetővé teszik a döntések meghozatalát, illetve a szervezet eredményes működtetését. A költségelszámolás lehetővé teszi a vezetés számára, hogy: a döntéseit a költségek és az eredményesség szembeállítása alapján hozza, a döntések üzletszerűbb alapon, a szervezeti célokhoz illeszkedően szülessenek meg, olyan információkat mutasson fel, ami jövőbeli beruházásokat indokol, biztonsággal lehessen végrehajtani a tervezést és speciálisan a költségvetés tervezését, ki lehessen aknázni a stratégiai lehetőségeket, értéktöbblettel járó termelékenységet teremtsen. A vezetésnek gyakran kell a beruházások indoklását a többlet erőforrások igénye felől megközelítenie. A fő indok az új és jobb lehetőség. Ide tartoznak a stratégiai lehetőségek, és ez lehetővé teszi a szervezet számára, hogy tervezze terhelését és berendezés igényét. Ezt három fontosabb területen vizsgálják: Lehetővé teszik a szervezet számára, hogy olyan szolgáltatásokat nyújtson, ami az informatika alkalmazása nélkül lehetetlen lett volna. 124

132 Infrastruktúra menedzsment Költségmenedzsment Növelik a szervezet hatékonyságát azáltal, hogy felgyorsítják a jelenlegi szervezeti folyamatokat vagy csökkentik azok erőforrás-használatát. Javítják a szervezet szolgáltatásainak minőségét. A számlázás A szolgáltatásokért való számlázás alapvető célkitűzése az, hogy professzionális (üzleti/piaci jellegű) kapcsolatot építsen fel az informatikai szolgáltatók és felhasználók között. A számlázás számos lehetőséget nyújt a vezetés számára: befolyásolhatják a felhasználók viselkedését, áttekinthető módon fedezhetik az informatikai költségeket, lehetővé teszik a felhasználónak az informatikai szolgáltatók értékelését. A felhasználó maga is kezelheti saját költségeit, és kezdeményezheti a díjköteles szolgáltatás felhasználásának módosítását. 9.2 A költségmenedzsment funkció bevezetése A funkció bevezetését egyeztetni kell a jelenleg működő rendszerekkel, és az eredményt folyamatosan figyelemmel kell kísérni. A legfontosabb szakasz, ami hatást gyakorol a költségmenedzsment funkció zökkenőmentes működésére, az a tervezési szakasz. Ennek jelentőségét sose szabad alábecsülni. A szükséges emberi és időbeli erőforrások rendelkezésre bocsátása csökkenteni fogja a későbbi szakaszokban előforduló problémák számát Tervezés Egy költségmenedzsment rendszer hasznos vezetői információkat ad, melyek segítenek a stratégiai és szervezeti célkitűzések elérésében. Az irányelveket és célkitűzéseket ennélfogva előre ki kell jelölni, és írásba kell foglalni azért, hogy a költség-elszámolási és számlázási rendszerek és a belőlük származó jelentések természetes módon kötődhessenek hozzájuk. A tervezés a költségmenedzsment bevezetésének legfontosabb része, és maga is három főbb szakaszra osztható: kiinduló tervezés, a költség-elszámolási és a számlázási rendszer kifejlesztése, a személyzet kiképzése, a felelősségi körök kijelölése. Kiinduló tervezés A költségmenedzsment rendszereinek megvalósítása előtt fontos az alábbi kérdésköröket áttekinteni, és a megállapításokat egy megvalósíthatósági tanulmány formájában összegezni: Milyen a vezetés tudásalapja; szükséges, hogy a vezetés tisztán értse a költségelszámolás/számlázás alapvető szerepét egy informatikai szolgáltató részleg esetében. Ezt még a tervezés terjedelmének kijelölése előtt tisztázni kell. Mik a célkitűzések; mérjük fel a vezetésnek a költségmenedzsment funkcióval kapcsolatos célkitűzéseit. Megbeszélések alapján fogalmazzuk meg a szervezet követelményeit. Mik az elvárt hasznok; értékeljük és számszerűsítsük a költségmenedzsment bevezetéséből származó hasznokat. A jelenlegi rendszerek ismerete; gyűjtsünk össze minden adatot a jelenleg létező költségmenedzsment tevékenységekről minden egyes területen. Derítsük fel a jelenlegi felelősségi köröket, illetve használatban levő eszközöket. Vizsgáljuk meg annak lehetőségét, hogy hogyan lehetne a hasznos adatokat és eljárásokat az új funkció részévé tenni, tekintsük át az információs folyamokat. A figyelemmel követés (monitoring) helyzete; keressük meg a rendelkezésre álló, vagy könnyen elérhető monitorozó vagy számviteli eszközöket. A pénzügyi gyakorlat; ismerjük meg a jelenlegi gyakorlatot; meg kell keresni a pénzügyi kapcsolódási pontokat a teljes szervezethez. 125

133 Infrastruktúra menedzsment Költségmenedzsment A megvalósíthatósági tanulmány befejezte után világos kell legyen, hogy a költségmenedzsment milyen szerepet tölthet be a szervezetben. Ezt az információt jelentés formájában kell a vezetés tudomására hozni. A jelentésben szerepeljen: vázlatos leírás (terms of reference) a javasolt funkcióra, alapelvek, melyek a megvalósítandó költség-elszámolási és számlázási rendszerre vonatkoznak, a megvalósítandó költség-elszámolási és számlázási rendszer áttekintése, beleértve ebbe a határidőket, a költségeket és minőségi kritériumokat, a szervezet számára hajtott hasznok áttekintése és a költségmenedzsment funkció költségindoklása. Kiemelten fontos azon jelenlegi alapelvek megerősítése, vagy olyan ajánlások elkészítése, melyek összefüggésben állnak a jövőbeli költségmenedzsment funkcióval, és a költség-elszámolási és számlázási rendszerrel. A vezetésnek döntésre kell jutnia az alábbi kérdésekben: Kötelezik-e a felhasználókat arra, hogy az informatikai szolgáltatásokat a belső informatikai szolgáltató részlegtől szerezzék be, vagy jogosultak arra, hogy máshonnan szerezzék be ezeket, esetleg maguk is elláthatják őket? Mi a szervezet álláspontja és milyen ajánlások léteznek a költségelszámolásra, előrejelzésre, költségvetés tervezésre vonatkozólag? Fog-e számlázni az informatikai szolgáltató részleg a szolgáltatásaiért, és ha igen, akkor milyen elv szerint teszi ezt (elvi számlázás, igazi számlázás, szükséges e felhasználói magatartás alakítása, stb.)? Milyen típusú lesz az informatikai szolgáltató részleg működtetése (költségcentrum, önelszámoló, egyszerű elszámoló)? Milyen legyen az árképzési elv, azaz szabvány költség alapú, gördülő rátás, tervezett árbevétel szint alapján számított, kialkudott ár, stb.? Milyen költségek tartoznak az informatikai funkcióhoz és milyen költségfelosztást fognak alkalmazni? A fenti kérdések megválaszolásához a lehető legkorábban meg kell szerezni vezetői elkötelezettséget, minthogy mind a költség-elszámolási, mind a számlázási rendszer tervezése, kifejlesztése és működtetése nagymértékben függ az adandó válaszoktól. A költség-elszámolási rendszer megtervezése Ha a vezetés elfogadta a funkciót bevezető projekt tervét és ajánlásait, akkor a költség-elszámolási rendszer részletekbe menő tervezéséhez kell hozzáfogni. Az informatikai költségelszámolás vezetői információkat biztosít az informatikai kiadásokról, és kapcsolja ezeket a terhelésekhez és a nyújtott szolgáltatásokhoz. A költség-elszámolási rendszer megtervezéséhez a következő lépéseket kell végrehajtani: határozzuk meg az előállítandó terveket és jelentéseket, határozzuk meg a költségek felosztását, azonosítsuk a felhasználandó adatforrásokat, határozzuk meg a költség-elszámolási módokat! A költségekkel kapcsolatos adatok forrásainál ki kell választani azokat a mérési egységeket, melyeket segítségével figyelemmel kísérik és előrejelzik az erőforrások felhasználását. A költségek értelmezése alapvető egy eredményes költségmenedzsment funkció bevezetése során. Ha már ismeretesek az összesített költségek, akkor meg kell becsülni az egyes vetített költségeket. Annak érdekében, hogy ellenőrizni tudjuk a vetített költségek nagyságának a helyességét, megfelelő monitorozó rendszereket és eljárásokat kell kialakítani. A számlázási rendszer tervezése Amennyiben az informatikai szolgáltató részlegnek szándékában áll az általa nyújtott szolgáltatásért ellenértéket kérni, a következő lépés annak meghatározása, hogy miképp fognak a felhasználók 126

134 Infrastruktúra menedzsment Költségmenedzsment fizetni az általuk felhasznált informatikai szolgáltatásokért, és egyáltalán mely szolgáltatásokért kell majd fizetni. Azaz: meg kell határozni a számlázás céljait, meg kell fogalmazni a számlázási elveket, ki kell jelölni azokat a tételeket (szolgáltatásokat), melyekért a felhasználónak fizetni kell (díjköteles tételek), meg kell becsülni a díjköteles tételek felhasználásának nagyságát, ki kell jelölni az árkalkuláció módszereit, meg kell határozni a díjköteles tételek árait. A számlázás céljai és elvei Meg kell fogalmazni a számlázás céljait: Fedezni akarjuk az informatikával kapcsolatos kiadásokat? Szeretnénk befolyásolni a felhasználókat? Csak tudatni akarjuk velük az általuk felhasznált szolgáltatások értékét? Versenyzünk azon felhasználók megrendeléseiért, akik választhatnak a belső és külső szolgáltató között? A számlázás céljai és az informatikai szolgáltató részleg autonómiájának foka alapján meg kell fogalmazni a számlázási elveket: Vajon az informatikai szolgáltatások ingyenesek-e? Az informatikai szolgáltatások bekerülési adatait kapják a felhasználók? A felhasználókkal akarjuk fedeztetni az összes informatikai költséget? Előre kijelölt jövedelmezőséget akarunk elérni? Maximalizálni kívánjuk-e a profitot? A számlázás céljaiból és alapelveiből származtatható a használandó árkalkulációs módszer. A díjköteles tételek A számlázás minden módszerének vannak előnyei és hátrányai, ezért fontos annak eldöntése, hogy melyik módszer használata lesz egy adott szervezetben a legeredményesebb. Ez kapcsolatban áll azzal, hogy a vezetés milyen kifinomultságot vár el a költségmenedzsment funkciótól. Ha a szükséges információkat megszereztük, akkor ki kell jelölni azokat a tételeket, melyek díjkötelesek, azaz használatukért az informatikai szolgáltató részleg (pénzbeli) ellenértéket vár el. A díjköteles tételeknek rendelkezniük kell az alábbi tulajdonságokkal: Azonosítható Érthető Mérhető Becsülhető mind a felhasználó, mind az informatikai szolgáltató számára. a felhasználó számára. Ha a felhasználónak fizetnie kell olyan tételekért, amelyeket nem ért meg, akkor a számlázás céljait nem lehet elérni, és a felhasználók fogyasztási szokásait nem lehet a kívánatos irányba befolyásolni. mind a felhasználó (legalább elvileg), mind az informatikai szolgáltatás számára. a felhasznált tételek nagyságát vagy a felhasználó, vagy az informatikai szolgáltató részleg meg tudja előre becsülni, így aztán az informatikai szolgáltató részleg a számlázási alapelveknek megfelelően árakat tud számítani a tételre. Szemlék betervezése A költség-elszámolási és számlázási rendszerek kialakítása és üzembe helyezése után további információkra van szükségük a kellő színvonal eléréséhez. Éppen ezért a rendszereket a kezdettől fogva a szemlék szükségességének szem előtt tartásával kell megtervezni. Néhány olyan terület, ami igényli a folyamatos szemléket: a költségek és költségek fedezetének figyelemmel követése, üzemeltetés és karbantartás tervezése, hardver és szoftver függőségek követése, elvek és célkitűzések meghatározása. 127

135 Infrastruktúra menedzsment Költségmenedzsment A személyzet kiképzése és felelősségi körük kijelölése A költségmenedzsment minden sikeres vezetési struktúra lényegi része. Fontos a felső vezetés elkötelezettségét és direkt irányítását megszerezni a funkció megvalósításához. Ha a vezetés megegyezett az ajánlásokban (azaz a költség menedzsment funkció céljaiban), a felelősségi köröket ki kell jelölni és a megfelelő képzésben kell részesíteni az érintetteket. A vezetés céljait és elvárásait mindig figyelembe kell venni. A vezetésnek információt kell kapni a költségmenedzsment funkció bevezetésével kapcsolatos minden lényeges fejleményről, és naprakész információkkal kell rendelkezniük a számlázási folyamat tervezéséről. A várt kiadások költségvetését ismerni kell ahhoz, hogy a kapcsolódó tevékenységek esetében is becsülni lehessen. Ez befolyásolja az eredményes működtetéshez szükséges adminisztráció és személyzet költségeit. Felelősségi körök A költségmenedzsment funkció csak akkor tud működni, ha a szervezeten belül a megfelelő felelősségi köröket tisztázzák és kijelölik. A költségelszámolással és számlázással kapcsolatos alapelvekért rendszerint a felső vezetés felel, így ők biztosíthatják, hogy a szervezet célkitűzései érvényesülnek. Személyzet Fontos annak kijelölése, hogy milyen szervezeti keretek között (milyen személyzettel) hozzák létre a költségmenedzsment funkciót. Ez meghatározza az elkülönült felelősségi köröket, a helyes információátadási csatornákat, és végső soron a szükséges személyzet nagyságát, amellyel eredményesen működtethetik a költség-elszámolási és számlázási rendszert. Képzés A képzés a költségmenedzsment bevezetésének egyik legalapvetőbb kérdése. Ha mindenki a megfelelő tudásszinttel rendelkezik, akkor a rendszer működtetése jóval egyszerűbb. A személyzet minden tagjának ismernie kell az informatikai költségelszámolás kérdéseit, és értenie kell a kapacitás menedzsmenthez is. A képzési igényeket fel kell mérni, és ennek alapján a szükséges oktatást biztosítani kell, azaz a képzéseket tervszerűen kell végezni. Meg kell jegyezni azt, hogy az oktatásnak folyamatosnak kell lennie, és a személyzet rendszeres továbbképzése kiemelten fontos egy eredményes költségmenedzsment funkció működtetésében A funkció megvalósítása A költségmenedzsment funkció sikeres bevezetéséhez négy tényező járul hozzá: A tervezésnek tiszta és jól meghatározott struktúrát kell adnia mind a költség elszámolási, mind a számlázási rendszer jövőbeli céljaira, a termékeire, a költségeire és a személyzeti háttérre vonatkozólag. Ezenkívül reális és pénzügyileg elfogadható határidőket kell megszabnia. A helyesen időzített és eredményes kommunikáció felhívja a figyelmet a tervre, és áttekinthetővé teszi a struktúrát. Ennélfogva az eredményes kommunikáció elvezet a nagyobb együttműködési hajlandósághoz és a kiváló eredményekhez. Az elkötelezettség léte a felhasználók, a rangidős vezetés, a pénzügyi vezetés, az informatikai vezetés és személyzet részéről alapvetően fontos. Reális célkitűzésekre van szükség, a költség-elszámolási és számlázási rendszereket úgy kell kialakítani, hogy a megfelelő részletezettségű szintű információkat nyújtsa, anélkül, hogy túlzott elvárásokat keltenénk. A funkció kiépítéséhez szükséges időt biztosítani kell. Amikor a költségmenedzsment bevezetésének terveit a vezetés elfogadta, megfelelő keretet kell teremteni ahhoz, hogy a funkció eredményesen megvalósítható legyen. Annak érdekében, hogy mindenki, aki részt vesz a funkció megvalósításában, ismerje a kommunikációs csatornákat, fontos a helyes eljárások kialakítása. Ez jóval könnyebben kezelhető munkakörnyezetet eredményez, hiszen ha valamilyen probléma merülne fel, vagy egyéb fejlemények történnének, akkor mindenki tudni fogja, hogy milyen eljáráshoz kell folyamodni. Három területet kell megvizsgálni: fejlesztés, tesztelés, megvalósítás (üzembe helyezés). 128

136 Infrastruktúra menedzsment Költségmenedzsment Fejlesztés A költségekkel kapcsolatos adatokat pontosan fel kell jegyezni, minél hamarabb. A fejlesztés lényegében négy területre kell koncentráljon: Kódrendszerek a költségmenedzsment funkció éves ciklusban dolgozik, melynek során az egyes rendszereknek képesnek kell lenniük a szükséges adatok összegyűjtésére. A rendszerelemeket és a kapcsolódási pontokat meg kell vizsgálni a várható követelmények szempontjából, és egy letisztázott kódrendszert kell kialakítani. Adatbevitel tisztázzuk, milyen adatokat kell gyűjteni és miért. Tervezés, szolgáltatás, teljesítmény és költségek ezekről a területekről rendszerint gyűjteni kell adatokat. Gondoskodjunk arról, hogy ez rendszeresen, rutinjelleggel történjen. Munkalap A követelmények azonosítása és kijelölése után a kapcsolódási pontokon a kapacitás menedzsmenthez, a szolgáltatási szint menedzsmenthez, az informatikai szolgáltatás menedzsmenthez, az adott funkció számviteli rendjéhez illeszkedő űrlapokat kell megtervezni. Az alapadatokból a vezetői információkat előállító automatikus rendszereket is meg kell tervezni, és ki kell fejleszteni. Eljárások A fejlesztési szakasz részeként, a funkció üzemeltetési eljárásait ki kell dolgozni, és dokumentálni kell őket. Ezenkívül felhasználóknak oktató, hivatkozási és felhasználói kézikönyveket kell készíteni. A precíz és letisztult dokumentáció és az eljárások biztosítják azt, hogy a költségmenedzsment és a költség-elszámolási és számlázási rendszerek megvalósítása gyorsabban és problémáktól mentesen történik. Tesztelés A tesztelést kivitelezhető és pontos volta érdekében három alszakaszra bontjuk: Egységek tesztelése, ami arra irányul, hogy az egyes rendszerkomponensek működésének helyességéről önmagukban meggyőződjünk. Programok tesztelése, aminek feladata annak ellenőrzése, hogy a rendszer komponensek az egyes kapcsolatokban helyesen működnek-e. A teljes funkció tesztelése, ami akkor fejeződik be, ha minden rendszerkomponens a megfelelő kapcsolatokban helyesen működik, és a rendszer az előírt követelményeket teljesíti. Néhány jó tanács A tervezés és bevezetés folyamatát megkönnyítendő, álljon itt még néhány jó tanács: A tervezési szakasz legyen mindenki számára érthető, aki részt vesz a megvalósítás folyamatában. Mozgósítható tartalékokat kell kijelölni szükség esetére, a függőségeket fel kell tárni és a teljes megvalósítás becsült időigényét ismerni kell. Figyelemfelkeltő kampányt kell rendezni, biztosítandó, hogy minden érdekelt értesüljön az újonnan bevezetendő költségmenedzsment funkcióról, illetve a költség-elszámolási és számlázási rendszerekről. A dokumentációnak pontosnak kell lennie, és el kell jutnia a megfelelő helyekre. A felhasználói környezetet és a kapcsolódó adatfolyamokat elő kell készíteni a szükséges eszközökkel együtt a szükséges időre. Pilot projektet és/vagy parallel projektet kell indítani, és figyelemmel kísérni, ezáltal megbizonyosodván arról, hogy a szervezet eléri célkitűzéseit. Az eltéréseket fellépésük után nyomban korrigálni kell A megvalósítás utáni szemlézés és auditálás A kezdeti időszak után szemlét kell tartani. Ez fogja megerősíteni, hogy a tervek és a vezetői jelentések funkcionálisan helyesek, és a szervezeti célkitűzések szolgálatában állnak. Amennyiben a megvalósítás nem lenne kielégítő, szükséges lehet változtatások foganatosítása. Amint a szemléről 129

137 Infrastruktúra menedzsment Költségmenedzsment készült jelentést befejezik, és azt a vezetés elfogadja, a megvalósítási szakaszt le kell zárni, és a megvalósítás utáni szakaszba lépünk. A költségmenedzsment éves ciklusra alapul, amely előre tervez és költségvetést készít hozzá. Minden rendszer esetében szükséges a folyamatban levő, mindennapos feladatok értékelése. Ha alapvető változásokra lenne szükség a rendszerben, akkor azokat az éves ciklushoz kell igazítani, hogy a pénzügyi vezetés eredményes lehessen. Minden eljárást figyelemmel kell kísérni, hogy eredményesen látja-e el a funkcióját, illetve milyen problémák léptek fel. Kisebb helyreigazításokat azonnal el lehet végezni, melyek a funkció és a funkció alá tartozó rendszerek zökkenő mentesebb működéséhez vezetnek. A költségmenedzsment funkciót különösen két fő területen kell nagy figyelemmel kísérni: nyilvánvalóvá teszi-e, hogy a tervezési kritériumok kielégítésre kerültek verifikálható-e, hogy a szervezet célkitűzéseit elérték. Az alábbiak rávilágítanak a főbb kérdésekre: o vajon a terveket és költségvetéseket időre elkészítették-e és alkalmasak-e az eredeti céljukra, o a meghatározott jelentéseket elkészítik-e a kitűzött időpontra, és mennyire pontosak ezek, o kiadják-e a számlákat, bevételezik-e a fizetségeket a megfelelő helyekről és időben, o a raktári előrejelzések jók és naprakészek-e, o minden költséget elszámolnak-e, o tartanak-e éves belső és külső auditokat, o elérik-e a szervezeti célkitűzéseket (havonta, negyedévente, évente)? Szemle Minden költségmenedzsment rendszer esetében szükséges a folyamatos szemlézés. Ha megfelelő adatokat gyűjtenek, akkor a problémák idejekorán napvilágra kerülnek. Ez lehetővé teszi a változtatásokat tervezését, és a jobbítások eredményes kivitelezését. Újabb célkitűzéseket egyszerű lesz bevezetni, mert egy jól strukturált funkció működik. A funkció szemlézését konstruktív eljárásként kell felfogni, és éppen ezért minden pozitív fejleményt is fel kell jegyezni! Auditálás Minden költségmenedzsment rendszer esetében lényeges, hogy auditálásra kerüljön. Másképpen fogalmazva ez azt jelenti, hogy a szervezetnek alaposan meg kell vizsgálnia a rendszert, és képesnek kell lennie működésének verifikálására. Fontos tudnivaló, hogy a költségmenedzsment funkció több különböző módon auditálható, melyek mindegyike más-más nézőpontból vizsgálja ugyanazt a funkciót. A minőségügyi audit esetében az a kérdés, hogy pl. a költségmenedzsment funkcióban vannak-e minőségügyi eljárások, és ha igen, elérik-e azok a kívánt hatásukat a funkció minőségének javítása terén? Egy másik kérdés ebben az esetben pl. az, hogy a költségmenedzsment funkció hozzájárul-e az informatikai szolgáltatások minőségéhez, és ez eredményesen és hatékonyan történik-e? A pénzügyi audit esetében az a kérdés, hogy pl. a költségmenedzsment funkció eljárásai összhangban vannak-e a teljes szervezet számviteli és pénzügyi eljárásaival? Pontosan követik-e ezeket az eljárásokat? A költségmenedzsment funkció eredményesen és hatékonyan dolgozik-e? Hozzájárul-e az informatikai szolgáltatások és az informatikai szolgáltató részleg eredményes és hatékony voltához? Az auditot mind belső, mind külső auditorok végrehajthatják. Az audit segít annak ellenőrzésében, hogy a költségmenedzsment funkció követi-e a meghatározott eljárásokat, és ezt eredményesen és hatékonyan teszi-e. Az informatikai szolgáltatások vezetésnek azonban nem szabad csupán az auditokra hagyatkozniuk. A költség menedzsernek feladata saját auditok végrehajtása és annak ellenőrzése, hogy a költségmenedzsment funkció és rendszerei megfelelően, eredményesen és hatékonyan működnek. 130

138 Infrastruktúra menedzsment Költségmenedzsment Problémák A legfontosabb problémák a költségelszámolás területén merülnek fel, mert ez még mindig új gondolat az informatikai szolgáltatások menedzsmentje területén. A kulcsproblémák: A költséginformációk hiánya; a lényeges költséginformáció gyakran strukturálatlan formájú, nehéz előállítani vagy nem is létezik. A tervezési információk hiánya; egy eredményes és hatékony költségmenedzsment rendszer rendkívüli mértékben függ a tervezési információktól, melyet más funkcióknak kell előállítaniuk az informatikai szolgáltató részlegen belül, vagy éppen a felhasználók adják őket. Ilyen például a kapacitás menedzsment információi a várható terhelésekről és a rendelkezésre álló erőforrásokról. Hasonlóképpen, a szolgáltatás menedzsment szolgáltatási szint megállapodásokat fog elkészíteni, melyek figyelembe veszik a szolgáltatás követelményeit és a számlázási rendet. A kellőképpen képzett személyzet hiánya; a számviteli és informatikai tudással és tapasztalattal egyidejűleg rendelkező személyek ritkák, mint a fehér holló. Az irányultság hiánya; lehetséges, hogy a szervezetnek a számvitellel kapcsolatos alapelvei, a stratégiája és célkitűzései nem tisztultak le és nem dokumentáltak; ennélfogva a költségmenedzsment funkció és rendszereinek megvalósítása gondokkal fog küzdeni. Az elfogadás hiánya, leggyakrabban a költség-elszámolási és számlázási rendszer lehetőségeinek és hasznainak fel (és el) nem ismerése vezet ide. A vezetői elkötelezettség hiánya; ami kifejeződhet az ajánlások és jelentések gyenge fogadtatásában, saját külön számviteli rendszerek és listák létezésében, nyilvánosságra juthat abban, hogy nem a teljes érintett személyzet kapja meg az eljárások leírását, vagy gyakoriak a kisebb változtatások, stb. A cél hiánya; a költség-elszámolási és számlázási rendszereket olyan módon kell megtervezni és működtetni, hogy a rendszerek működtetési költsége ne haladja meg az általuk létrehozott információk értékét, másrészt ez az információ legyen annyira pontos, hogy a rendszertől elvárt hasznok valóban létezzenek. A célkitűzéseknek tisztának kell lenniük, már csak azért is, hogy megválaszolhassuk az alapkérdést: Miért is csináljuk ezt? 9.3 Ajánlott irodalom Cost Management for IT Services. IT Infrastructure Library. HMSO, 5 th ed ISBN

139 10. Katasztrófa elhárítás tervezés Még a legkifinomultabb biztonsági intézkedésekkel sem zárhatjuk ki teljesen egy szervezet informatikai szolgáltatásainak véletlenszerű vagy esetleg szándékosan okozott kiesését. Habár egy teljes kiesés kockázata kicsi, de létezik, utólag pedig már nem mentség, hogy a katasztrófa bekövetkeztének az esélye egy volt a millióhoz. Ennélfogva fontos, hogy az informatikai rendszerek kiesésének hatásait értékeljük. A következmények változhatnak a költségek és az okozott kényelmetlenség tekintetében, attól függően, hogy mekkora időre esik ki, illetve mennyire kritikus a szolgáltatás. Képesnek kell lennünk a szolgáltatás helyreállítására a katasztrófa bekövetkezte után, hogy a szervezeti alaptevékenységek folytatását garantálni lehessen. Milyen következménye lehet egy informatikai katasztrófának? Információvesztés A kommunikáció megszakadása A biztonság megsérülése A kritikus alkalmazások leállása Az ügyfelek megbecsülésének elvesztése Az alapvető tevékenységek megszakadása Egy rendszerkiesés bekövetkezte utáni helyreállítás részletes és körültekintő tervezést igényel, és ez általában nem kis feladat. Egy hatásos helyreállítási terv elkészítése megköveteli a különböző területek, részlegek, szolgáltatások és szolgáltatók együttműködését. A tervezés során figyelmen kívül hagyott elemek azonban alááshatják az egész terv használhatóságát, ezért fontos a gondos, jól előkészített és megfelelően menedzselt tervezési folyamat. Összességében elmondható, hogy minden olyan információs erőforrás esetében, amelyet a szervezet vezetése a stratégia (küldetés) és a működés szempontjából kritikusnak tart, amelyeknek az elvesztése elfogadhatatlan negatív hatásokkal járna, megfelelő, írott formájú, költség-hatékony katasztrófa-elhárítási tervet kell készíteni, amely lehetővé teszi a szervezet szempontjából kritikus tevékenységek folytatását egy katasztrófa bekövetkezte esetén. Ezt a tervet rendszeresen tesztelni kell, és biztosítani kell rendszeres frissítését, érvényességét A katasztrófa elhárítási terv szükségessége Ahogy az információtechnológia használatától való függőség egyre nő a kormányzati, közszolgálati szektorban is, egyre fontosabb, hogy a szolgáltatásokat egy előre meghatározott, megállapodott minőségben nyújtsák. Minden esetben, amikor a szolgáltatás színvonala csökken, vagy éppenséggel nem áll rendelkezésre, a felhasználók nem tudják elvégezni mindennapi munkájukat. Az informatikától való függőség trendje várhatóan megmarad, és egyre növekvő mértékben fogja befolyásolni a felhasználókat és a vezetést. Ezért alapvetően fontos, hogy a szolgáltatásokat zökkenőmentesen tudjuk nyújtani. Rendszerkiesések a tapasztalatok szerint előfordulhatnak, ezért kell felkészülnünk arra, hogy az igényeknek megfelelő határokon belül helyre tudjuk állítani az eredeti szolgáltatási színvonalat. A katasztrófa elhárítási terv létéből származó legnagyobb haszon tehát az informatikai szolgáltatásokkal kapcsolatos kockázati szint csökkenése. Ezenkívül ez a terv: megalapozza az informatikai rendszerek ellenőrzött helyreállításának a képességét, csökken a kieső idő, ezáltal a felhasználók számára a szolgáltatások nagyobb mérvű folytonossága érhető el, a szervezet életében minimális lesz a megszakítás, költségek szempontjából a leghatékonyabb megoldás alkalmazását teszi lehetővé. A kormányzati közszolgálati szervek függősége az informatikai rendszerektől egyre nagyobb. Az alaptevékenységek ellátásának színvonalát nem lehet veszélyeztetni, tehát védeni kell az informatikai rendszereket. Ennélfogva fontos feladat a katasztrófa-elhárítás tervezés. Ennek keretében: Fel kell becsülni az informatikai szolgáltatások elvesztésének hatását. Meg kell határozni a kritikus informatikai szolgáltatásokat és alkalmazásokat, amelyeknek üzemelniük kell. 132

140 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés Meg kell határozni azt az időtávot, amely alatt a szolgáltatásokat vissza kell állítani. Meg kell határozni a szolgáltatások fenntartására/helyreállítására szolgáló eszközöket. Olyan katasztrófa-elhárítási tervet készíteni, amely lehetővé teszi egy katasztrófa-helyzet kezelését, ill. a szolgáltatások helyreállítását. A katasztrófa elhárítási funkció lehetővé teszi, hogy egy esetleges katasztrófa bekövetkezte után az informatikai szolgáltatásokat ellenőrzött módon, egy előre megállapított szolgáltatási szinten helyreállítsák, oly módon, hogy előre meghatározzák a helyreállítás során érvényes személyi felelősségeket, illetve az ellátandó tevékenységeket. A katasztrófa elhárítási terv tartalmazza mindazokat az információkat, melyek szükségesek az informatikai szolgáltatások helyreállításához egy esetleges katasztrófa bekövetkezte után. A terv arra is világos útmutatást fog adni, hogy hogyan, és mikor kell használni. A katasztrófa elhárítás tervezése sok időt, erőfeszítést igényel, nagy költségvonzattal jár és a vezetés számára gyakran nehéz átlátni, hogy pontosan mit is kap ezért cserébe. Ezen okból a felső vezetésnek elkötelezettnek kell lennie a katasztrófa elhárítás tervezése iránt, lehetőség szerint minél magasabb szinten. A számítógépes eszközök és a kapcsolódó berendezések védelme életbevágó fontosságú, ugyanakkor a szervezetnek tudatában kell annak is lennie, hogy nem csak ezekre kell figyelmet fordítani! Katasztrófa elhárítási tervet kell készíteni a teljes szervezetre, amely olyan elemeket fog tartalmazni, mint: az egyedi személyzet gyakorlatától és tapasztalataitól való függőség, irodák, elhelyezés, telefonok stb., papír alapú eljárások, szállítási igények. Más és más függőségek léphetnek fel az egyes szervezeteknél. Igen gyakran ezek annyira beépülnek a mindennapok gyakorlatába, hogy fel sem ismerik és nem is védik őket. Az informatikai katasztrófa elhárítási tervnek kapcsolódnia kell a szervezet egészéhez, a másutt rendelkezésre álló katasztrófa elhárítási tervekhez. Ahol ilyen, a szervezeti alaptevékenységekre fókuszáló terv még nem lenne, az informatikai katasztrófa elhárítási terv léte gyakran felveti készítésük szükségességét, hiszen rámutat a gyengeségekre. A katasztrófa elhárítás keretében az alábbi, vészhelyzet esetében védelmet igénylő infrastrukturális tételekkel kell foglalkozni: hardver terminál-alapú rendszerek telekommunikációs hálózatok szoftver adatbevitel/előkészítés számítógépes papír stb. igények A katasztrófa-elhárítás tervezés megvalósítása A katasztrófa-elhárítás tervezés fő lépései a következők: 1. A projekt előkészítése, a felsővezetés támogatásának elnyerése 2. A tervező csapat kialakítása, az alapelvek tisztázása 3. Fel kell mérni a jelenlegi rendszereket, szolgáltatásokat, informatikai eszközöket, meg kell határozni a prioritásokat 4. Azonosítani kell a fenyegetéseket, meg kell határozni bekövetkezésük valószínűségét, értékelni kell a kockázatot. 5. Meg kell vizsgálni a meglévő eszközöket és képességeket a biztonsággal, a katasztrófa megelőzéssel és elhárítással kapcsolatban, meg kell határozni a szükséges kockázatmenedzsment eszközöket. 6. Tervet kell készíteni katasztrófa-szituáció esetére a helyreállítás menedzseléséhez 133

141 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés 7. Ki kell képezni a személyzetet a terv alkalmazására 8. Tesztelni kell a tervet 9. A katasztrófa-elhárítási tervet karban kell tartani A projekt előkészítése Az előkészítő szakasz célja egy jelentés elkészítése a vezetés számára arról, hogy miért szükséges egy katasztrófa elhárítási terv készítése, mekkora erőforrásigényekkel jár ez, mekkora a becsült költségigénye, és mikorra készíthető el. A jelentés elkészítéséhez hivatkozási alapot (terms of reference) kell készíteni, ami rögzíti: jelen szakaszbeli feladatok célját, ki felelős a feladatok elvégzéséért, a csapat rendelkezésére álló erőforrásokat, a szükséges kiinduló információk körét, az elvárt végeredményt, a határidőket. Az előkészítés legfőbb lépései a következők: 1. A katasztrófa-elhárítási terv készítésének elhatározása 2. A szervezeti tevékenység megértése 3. Előzetes terv készítése a menedzsmentnek 4. A meglévő belső rendszerek és szolgáltatások részletes felmérése 5. A külső szolgáltatások, eszközök számbavétele 6. A szolgáltatások kiesésének hatáselemzése (Business Impact Analysis) 7. A terv hiányából fakadó jogi következmények felmérése 8. A rendelkezésre álló lehetőségek áttekintése 9. Külső tanácsadók bevonása 10. A biztonsági és környezeti feltételek ellenőrzése 11. Támogató keresése a felsővezetés köréből 12. Az előzetes terv prezentálása 13. Költségvetés készítése 14. A jóváhagyás megszerzése A tervezés kezdeti szakaszában javallott a kulcsfontosságú területek vezetőinek megnyerése és a tevékenységbe való bevonása. Ezután könnyebb a felsővezetés aktív támogatásának megszerzése is. A projekt csapat összeállítása A hivatkozási alapban történő megegyezés és a vezetés beleegyezése után össze kell állítani a projekt csapatát, amely elkészíti a tervet, és részt vesz annak kivitelezésében, valamint a katasztrófa esetén a helyreállítási tevékenységekben is. A csapatot a katasztrófa elhárítás funkció menedzsere vezeti. A csapat munkájában részt vesznek az informatikai szolgáltatási funkciók egyéb képviselői, beleértve ebbe a szolgáltatási szint menedzsert, az alkalmazásfejlesztők és a felhasználók képviselőit, ezenkívül adminisztratív és pénzügyi képviselőket is. A tervezéshez felhasználhatók belső munkatársak, auditorok, külső szakértők, ill. katasztrófa-elhárítással foglalkozó szervezetek tanácsadói is. Szükség lehet speciális ismeretekre is, úgymint: kapacitástervezőkre, hálózati szakértőkre, irodai szolgáltatások ismerőire, auditorokra, biztonsági tisztekre, beszerzési és szerződéskötésben jártas szakemberekre. A katasztrófa elhárítási menedzser a projekt csapat vezetője, és ő felel a csapat tevékenységeiért. A projekt csapat felelős a terv elkészítéséért, aminek minden olyan információt tartalmaznia kell, ami 134

142 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés szükséges lehet az előre megállapodott szolgáltatási szint helyreállításához vészhelyzet bekövetkezte esetén. A terv elkészítése során a csapat használhatja a rendelkezésére álló eszközöket. Ha a munka kihatna más területekre is, akkor azok képviselőit is be kell vonni, ilyen módon biztosítva, hogy a szükséges erőforrások rendelkezésre állnak. A szervezet következő részeinek kell információkkal hozzájárulniuk a tervhez szolgáltatások vészhelyzetben adminisztráció helyi környezeti kérdések adminisztráció egészségügyi és biztonsági kérdések adminisztráció / üzemorvos a személyzet jóléte adminisztráció/szakszervezet biztonság az informatikai funkció biztonsági tisztje szolgáltatási és terhelési prioritások szolgáltatási szint menedzser, felhasználók programfuttatás alkalmazás menedzserek üzemeltetési előírások üzemeltetés szerződések adminisztráció Szintén a csapat felel a katasztrófa-elhárítással kapcsolatos szerződések és megállapodások megfogalmazásáért, életbe léptetéséért. Az előkészítő szakasz időzítése Az előkészítő szakasz időtartama az alábbi tényezőktől függ: az informatikai rendszer bonyolultságától, a futtatott szolgáltatások és alkalmazások számától, az interjúalanyok számától, a személyzet rendelkezésre állásának mértékétől és tapasztalatától, a kockázatmenedzselési módszerekkel való ismeretség (pl. CRAMM) fokától, a tanácsadók minőségétől és rendelkezésre állásától (ha igénybe veszik őket), a vezetés, a szervezeti biztonsági vezető és/vagy az audit funkció válaszidejétől (amennyi idő alatt a javaslatokra reagál). 135

143 Kockázatelemzés és menedzsment Infrastruktúra menedzsment Katasztrófa elhárítás tervezés Hivatkozási alap Információ források Elôzetes jelentés Kockázat elemzés SzSzM-ek Biztonsági felelős vezető Katasztrófaelhárítási tervre szerzôdôk Katasztrófaelhárítási terv készítése Elfogadás elôtti terv tesztelése Teszt elfogadása Katasztrófaelhárítási tervre vonatkozó szerzôdések felállítása A terv szétosztása A személyzet képzése Személyzeti tudatosító szemináriumok SzSzM-ek módosítása 31. ábra: Az implementációs szakasz Ezután indulhat az előkészítő szakaszbeli fő tevékenység, ami felöleli az informatikai szolgáltatások elemzését, az alkalmazások kritikusságának elemzését, a kockázat értékelést, a katasztrófa elhárítási tervbeli alapváltozat kiválasztását. A kockázat értékelés és menedzsment területén Nagy-Britanniában használatos a CCTA Risk Analysis Management Method (CRAMM) módszere. A CRAMM tételesen felsoroltatja az informatikai rendszer sebezhető pontjait, a rá leselkedő veszélyeket, és javaslatokat tesz ellenintézkedésekre. A veszélyforrások közé tartoznak a tűz, víz vagy természeti csapás által okozott károk, tudatos rombolás és eltulajdonítás, rendszer szoftver, hardver, áram vagy egyéb környezeti kiesés. 136

144 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés Szoftver (24%) Víz (9%) Sztrájk (7%) Áram (21%) Tûz (36%) Épület (3%) 32. ábra: Az informatikai katasztrófák okainak aránya A katasztrófa megelőzés alapeszközei meglehetősen egyszerűek. Ilyenek pl. a beléptetési eljárások, a tűzjelző és tűzoltó eljárások, az adat és szoftver védelmi eljárások, a személyzet valamilyen okból történő kiesése esetén életbe lépő eljárások, a karbantartó eljárások (pl. környezet-felügyelő berendezés üzemeltetése). A CRAMM számos ellenintézkedést ajánl a kockázatok csökkentésére. Ezek körének kijelöléséhez szükséges: a szolgáltatások elemzése, pl. kötegelt, tranzakciós, irodai. Ezeknek az információknak a szolgáltatási szint megállapodásokban szerepelniük kell. Az egyes alkalmazások kritikusságának értékelése, és az elfogadható kiesés mértékének meghatározása. A kritikusságot prioritási szint szerint sorolják, pl. n órán belül el kell hárítani, n napon belül el kell hárítani, nem kritikus. Ha egyes rendszereket nem tekintünk kritikusnak, akkor megoldás lehet, hogy vészhelyzetben kisebb gépeken futassuk őket. Az előkészítő szakaszban el kell végezni: a tervezett katasztrófa elhárítási terv és az ellenintézkedések pénzügyi értékelését, alternatív módszerek keresését, melyek több különböző, elvben elfogadható szolgáltatási szintet biztosítanak, az egyes javaslatok előnyeinek és hátrányainak felmérését, a katasztrófa elhárítási csapat nagyságának, illetve a szükséges személyzet számának becslését. A CRAMM A CRAMM átfogó megközelítés a kockázatelemzés és kezelés feladatkörére. A kockázatelemzés feladata az eszközök meghatározása, elemzése (a fizikai pl. hardver és más jellegűeket pl. adatok egyaránt figyelembe véve), majd a fenyegetések (amelyek lehetnek véletlenszerű és szándékos eredetűek) szintjének tisztázása ezen eszközökkel kapcsolatban, végül az eszközök kapcsán a sérülékeny, sebezhető pontok azonosítása és meghatározása. E három tényező: az eszközök értéke, a fenyegetések és a sebezhetőségi szintek révén kalkulálható az eszközökkel kapcsolatos kockázat. A kockázat menedzsment feladatköre az eszközök sebezhetőségének csökkentése a megfelelő ellenintézkedések megvalósításával. Az ellenintézkedések több módon segíthetnek: csökkenthetik a fenyegetés előfordulásának lehetőségét, csökkenthetik a bekövetkezett esemény hatását, észlelhetik az esemény bekövetkeztét, ill. segíthetnek a helyreállításban. 137

145 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés A kockázatelemzés és menedzsment fő elemei: Az eszközök meghatározása és értékelése az informatikai rendszerek fizikai és adat összetevőinek azonosítása és értékelése révén meghatározhatók a sérülékeny pontok, amelyeknél a fenyegetések bekövetkeztekor negatív következmények lépnének fel. A fenyegetések felbecslése a szándékos, akaratlan vagy véletlen eredetű, az informatikai rendszerek működését károsan befolyásoló események bekövetkezési valószínűségének megállapítása. A sebezhetőség felbecslése annak meghatározása, hogy az informatikai rendszerek milyen mértékben érzékenyek a felmért fenyegetésekre. Kockázatbecslés a kockázati szintet a fenyegetések és a sérülékenység mértéke, valamint az eszközök értéke határozza meg. Ellenintézkedések kiválasztása biztonsági ellenintézkedések kiválasztása, amelyek igazolható költségek mellett képesek a kockázat elfogadható szintre való csökkentésére. Az ITB biztonsági módszertani ajánlása Az Informatikai Tárcaközi Bizottság 1994-ben kiadott 8. sz. ajánlása részletesen bemutatja az informatikai biztonsági koncepció (IBK) kialakításának lépéseit. Az infrastruktúra menedzsment keretében bevezetendő katasztrófa elhárítás tervezés céljára ez a követendő módszertan hazánkban. Ehelyütt csupán az IBK kialakítási lépéseinek rövid áttekintését bocsátjuk közre, a teljesség igénye nélkül. Az IBK kialakításának folyamata 4 eljárási szakaszra, ezen belül 12 lépésre bontható. Az első szakaszban a szervezet szempontjainak megfelelően kiválasztják és behatárolják a vizsgálódások tárgyát. Ehhez meg kell határozni, mely informatikai alkalmazások védelme indokolt értékük, szervezeti jelentőségük alapján. A második szakaszban fel kell tárni mindazokat a fenyegető tényezőket, amelyek az első szakaszban kiválasztott informatika-alkalmazásokra veszélyesek lehetnek. Ennek során kell megvizsgálni az egyes informatikai rendszerek gyenge pontjait. A harmadik szakaszban a fenyegető tényezőknek az informatikai rendszerekre gyakorolt káros hatásait értékelik, azaz meghatározzák a fennálló kockázatokat. A negyedik szakaszban ellenintézkedéseket választanak ki a fenyegető tényezők kezelésére, és értékelik hatásukat. Ennek során döntendő el, mely intézkedések vehetők figyelembe, és milyen maradványkockázatok viselhetőek el. Minden egyes szakasz lezárásakor a felelős vezetőt tájékoztatni kell az elért eredményekről. Az egyes szakaszok eredményei a további munka alapját képezik. Az utolsó szakasz befejeződését követően az IBK-t a felsővezetésnek hivatalosan el kell fogadnia. Az IBK kialakításának részletesebb bemutatása 12 lépésben tehető meg. Egyes lépések megismétlésére szükség lehet a visszacsatolás érdekében. Az első lépésben feltérképezzük az informatikai alkalmazásokat és a feldolgozandó adatokat. A második lépés során meghatározzuk a feltárt alkalmazások és adatok védelmének céljait. Ehhez szükséges, hogy az öt alapfenyegetettség szempontjából értékeljük ezeket az alkalmazásokat és adatokat. Az értékelés alapján kiválaszthatók azok az alkalmazások, amelyek jó kockázatviselő képességűek. A harmadik lépésben meg kell vizsgálni, mely fenyegető tényezőknek van jelentősége a fenti rendszerelemek szempontjából. Az ötödik lépésben minden egyes fenyegető tényezőt meghatározunk, amelyek az informatikai alkalmazásokat veszélyeztethetik. A hatodik lépésben a fenyegetett rendszerelemekhez un. kárértéket rendelünk, amely az informatika-alkalmazás értékéből vezethető le. A hetedik lépésben megbecsüljük azt a gyakoriságot, amellyel a kár bekövetkezte valószínűsíthető. 138

146 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés A nyolcadik lépés során a kárból és a gyakoriságból levezetjük a kockázatot. A kilencedik lépésben olyan intézkedéseket választunk ki, amelyekkel elviselhető mértékűre csökkenthetők a kockázatok. A tizedik lépésben megvizsgáljuk, hogyan hatnak ezek ez intézkedések egymásra, a kockázatokra, a költségekre és a szervezet működésére. A tizenegyedik lépésben az intézkedésekkel kapcsolatos költségek és hasznok viszonyát kell megvizsgálni. Az utolsó, tizenkettedik lépésben megvizsgáljuk, hogy a fennmaradó kockázat elviselhető-e. Ennek során a meglévő kockázatokat vetjük össze a várható kockázattal. A vagyontárgyak azonosítása A meglévő hardver/szoftver készlet felmérése az egész tervezési folyamat alapjául szolgál. Átfogó listát kell készíteni a szervezet hardver és szoftver eszközeiről funkciónként, alkalmazásonként és szolgáltatások szerint. Fel kell mérni a meglévő eszközöket, a szervezet rendszereinek valamennyi összetevőjét: a számítógépes hardver összetevőket, a főbb rendszereket és azok összetevőit, a szoftver és adatvagyont a belső telekommunikációs eszközöket és szolgáltatásokat, az alkalmazott kommunikációs médiákat, adatkommunikációs eszközöket, kábel-rendszereket, fizikai háttérszolgáltatásokat. Meg kell határozni mindezen felszerelések védelmi prioritásait. A fenyegetések azonosítása A fenyegetések felmérésekor fontos, hogy ne csupán az informatikai funkció közvetlen környezetét vizsgálják, hanem a tágabb értelemben vett környezetet, mivel a katasztrófák okainak több mint a fele külső, a számítóközponton kívüli eredetű. A rendszereket alkotó komponensek felmérését követően meg kell határozni azokat a pontokat, amelyeket a legnagyobb kockázat fenyegeti. A kockázati pontok felmérésében a legfontosabb szempontok: A szolgáltatás, eszköz fizikai biztonsága: védelmet jelentenek a beléptetési rendszerek, védelmi rendszerek zárt körű tévélánccal. A belépési pontok: pl. telekommunikációs szolgáltatások esetében egyetlen belépési pont jelentős kockázati tényezőt jelent, mivel bármilyen tűz-, víz- stb. kár esetén a szolgáltatások megbénulását okozhatja. A külső szolgáltatókkal összekötő kapcsolati pontok is sérülékenyek lehetnek, a diverzifikálás itt is jó megoldás lehet. Környezeti tényezők, amelyek jelentősek az üzemeltetésben (elektromos hálózat, tűzvédelem, vízkár elleni védelem, képzés, változtatások kontrollja és menedzsmentje). A megelőzésre kell törekedni a gyenge pontok felmérésével, hogy mind a környezeti tényezők, mind az emberi hiba okozta katasztrófákat meg lehessen előzni. Kockázat elemzés és értékelés A szolgáltatások vizsgálatát követően eseteket kell összegyűjteni hasonló szolgáltatásokat érintő katasztrófákról. Gondosan és objektíven fel kell mérni a kockázatokat, illetve hatásukat a szervezet tevékenységére. Hogy lehet megelőzni a kieséseket? A hangsúlynak a megelőzésen és nem a helyreállításon kell lennie! Az elemzést a kockázat (a bekövetkezés valószínűsége) és az esetleges kár lehetséges mértékének függvényében kell elvégezni: Ha a lehetséges kár és a kockázat mértéke alacsony, csak minimális erőforrásokra van szükség a megelőzéshez. 139

147 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés Ha a lehetséges kár és a kockázat mértéke közepes, az már jelentős ráfordításokat követel meg a megelőzéshez. Ha a lehetséges kár csekély, de a kockázat mértéke magas, közepes mértékű ráfordításokra lesz szükség a megelőzéshez. Ha a lehetséges kár jelentős, de a kockázat mértéke csekély, közepes mértékű ráfordításokra lesz szükség a megelőzéshez. Ha a lehetséges kár jelentős, a kockázat mértéke pedig közepes, közepes mértékű ráfordításokra lesz szükség a megelőzéshez. Ha a lehetséges kár és a kockázat mértéke egyaránt magas, jelentős ráfordításokra lesz szükség a megelőzéshez. A szolgáltatások kiesésének hatáselemzése a következő lépésekből áll: A lehetséges kockázatok (veszélyforrások) meghatározása Az esemény bekövetkezte valószínűségének megállapítása Az esemény hatásának, költségeinek felbecslése Milyen megoldások lehetségesek az esemény bekövetkeztekor a szolgáltatás helyreállítására, vagy a katasztrófa bekövetkeztének megelőzésére? Milyen sokáig akadályozza az esemény a tevékenység ellátását? Mekkorák a probléma elhárításának költségei? Melyek a prioritások (mely kockázatokat kell minimalizálni elsőként?) Mennyi időt igényel a javítás megvalósítása? Mindehhez természetesen átfogó képet kell alkotni az informatikai szolgáltatásokról, valamennyi gyenge pontot meghatározva. A következmények felbecslésekor pedig fontos, hogy a szervezeten kívül, a partnereknél, ügyfeleknél jelentkező károkat is figyelembe vegyük. Meg kell vizsgálni, hogy az egyes szervezeti egységek mennyi ideig képesek funkcionálni a szolgáltatások nélkül, ill. minimális vagy csökkentett szolgáltatások mellett. Kockázatmenedzsment a lehetséges eszközök A katasztrófa elhárító csapat az alábbi, vészhelyzet esetében védelmet igénylő infrastrukturális tételekkel kell foglalkozzon (beleértve azt, is hogy mi a teendő kiesés esetén) hardver terminál-alapú rendszerek telekommunikációs hálózatok szoftver adatbevitel/előkészítés számítógépes papír stb. igények. Az alternatívák értékelése: valamennyi reális katasztrófa-elhárítási alternatívát értékelni kell rendelkezésre állás, megbízhatóság, a használat könnyűsége, a költségek és a jogi ill. működési korlátok szerint. Hardver A szolgáltatás kiesésének két fő hardver oka lehet: részegység kiesése, a teljes rendszer elvesztése katasztrófában. Részegységek kiesése és következményei kockázatának csökkentési módjaival a rendelkezésre állás menedzsment foglalkozik. Ilyen intézkedés pl. az ellenőrzések, a sérülékeny és kulcsfontosságú komponensek azonosítása és duplikálása, a rendszeres karbantartás. További megelőző eszköz lehet: tűz-/víz-/nyomásjelző, megszakítás-mentes tápegységek, generátorok, riasztók. Bizonyos katasztrófával szembeni ellenálló képességet ki lehet alakítani alkalmas duál processzorok használatával, amelyek akár 1,5 km távolságra is lehetnek egymástól, és üvegszálas alapú hálózati kapcsolatban állnak. Ez jobb megoldás lehet, mint a különálló rendszerek használata. 140

148 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés Terminál-alapú rendszerek A csapat a következő eseményekre kell felkészüljön: a központi számítókapacitás (gép) kiesése, terminál kontroller kiesése, terminál kiesése. A központi számítókapacitás kiesése esetében egy előre meghatározott időkorláton túl a katasztrófa elhárítási tervet kell végrehajtani. Ez egy vészhelyzetben felhasználható tartalék rendszer igénybevételét jelentheti egy tartalék telephelyen. Egy másik lehetőség egy kisebb gépről korlátozott szolgáltatások nyújtása. A terminál kontroller (vagy hálózat esetében terminál szerver) kiesése szinten katasztrofális lehet, mert az összes hozzá kapcsolódó terminál működésképtelenné válik. Ezt ki lehet küszöbölni a terminálok megosztásával a klaszter kontrollerek között. Egy terminál kiesését pótolni lehet egy közeli tartalék terminállal, vagy készenlétben levő tartalék terminállal, amivel ki lehet cserélni a meghibásodott eszközt. Telekommunikációs hálózatok A telekommunikációs hálózatok esetében a katasztrófa elhárítás tervezés nagyrészt annak kérdése, hogy mennyire tervezték a hálózatot katasztrófatűrőnek. Az összes vonal elvesztésétől oltalmazandó, megfontolható a vonalak többszörözése különböző telefon-alközpontok között, vagy többszörözhetjük a vonalakat ugyanazon a központon át is. A telekommunikációs szolgáltatónál levő sztrájk ellen úgy védekezhetünk, hogy lehetőség szerint több szolgáltatót veszünk igénybe, ezáltal megosztjuk a kockázatot. Az egyedi vonalak kiesése megoldható alternatív úttal, egy alkalmas eszközzel, vagy a terminálok lokális üzemmódban történő használatával, amikor olyan eszközre írunk, melynek tartalma áttöltésre kerül az éles rendszerbe egy későbbi időpontban. Szoftver Ahol csak lehet, kipróbált rendszereket és alkalmazásokat futtassunk, melyeket a saját környezetünkben teszteltünk. A belső, házi fejlesztéseket minőségellenőrzésnek kell alávetni, és elfogadási teszten kell átesniük, mielőtt még éles üzembe kerülnének. Minden egyes szoftver elemet egy megfelelő, lehetőleg távoli és biztonságos helyre kell másolni, a szükséges dokumentációval és üzemeltetési / helyreállítási útmutatókkal együtt. Bizonyosodjunk meg arról, hogy a vásárolt vagy fejlesztett szoftver ténylegesen fut a tartalék telephelyen. Szemlézzünk és teszteljünk rendszeresen. Bölcs dolog annak ellenőrzése is, hogy a szoftver licenc alkalmas-e a másik telephelyen történő futtatásra Adatbevitel/előkészítés Járható utak az adatelőkészítő egység elvesztése esetén az alábbiak: használjunk egy irodát, használjunk egy másik helyszínt (készenléti vagy kölcsönösségi alapon), válaszuk szét a szolgáltatást több részre, esetleg különböző épületekben. Érdemes megjegyezni, hogy az adatbeviteli részleget jól lehet használni adat tárolásra és előkészítésre akkor is, amikor központi számítógép kiesik. Az adatokat át lehet majd konvertálni mágneses adathordozókra, amikor a számítógép újra üzemképes állapotba került. A katasztrófa elhárítási tervnek részletes utasításokat kell tartalmaznia az input és output anyagok szállításáról. Számítógépes papír stb. igények. A katasztrófa elhárítási tervnek figyelembe kell vennie a szervezet különleges papírkezelési igényeit, mint például hőkötés, szétválasztás, lyukasztás vagy borítékolás. Elégséges mennyiségű speciális papíranyag kell rendelkezésre álljon biztonságos helyen. Környezet Elhelyezés Amennyiben a felhasználók és az informatikai szolgáltatók azonos épületben vannak elhelyezve, akkor a szervezeti szintű katasztrófa elhárítási tervben szerepelnie kell a felhasználók vészhelyzetben 141

149 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés történő elhelyezésének. Nincs értelme a számítástechnikai szolgáltatások helyreállításának, ha nincsenek felhasználók, akik használnák azokat. Katasztrófa esetén vészhelyzeti irányító központot (emergency control centre) kell kialakítani, ahonnan minden kommunikációt és tevékenységet irányítanak. Ebből a központból koordinálják majd a helyreállítási tevékenységeket. A vészhelyzeti irányító központban rendelkezésre kell álljanak a katasztrófa elhárítási terv példányai, ezenkívül minden olyan eszköz, ami a helyreállítási tevékenységek adminisztrációjához és irányításához szükségesek (asztal, telefon stb.) A tartalék telephelyen elégséges és megfelelő irodai elhelyezést kell biztosítani annak a személyzetnek a számára, amely üzemelteti a számítógépeket. A telephelyen legyen meg a szükséges bútorzat, berendezések, telefonok stb. Fontoljuk meg a több műszakban dolgozók számára alvási lehetőségek biztosítását, különösen akkor, ha csak korlátozottan van elérhető szálláslehetőség. Ne feledkezzünk el a személyes higiéniai és étkezési igények kielégítéséről sem! Elektromos áram Az áram kimaradási és világítási problémák a kieséseknek kb. 20%-át okozzák. Ezek kiküszöbölése érdekében az alábbiak valamelyikével élhetünk: tartalék generátorokat használunk, megszakítás-mentes tápegységeket használunk, motor alternátorokat használunk. Ha az ezek által nyújtott szint nem elégséges a folyamatos üzemhez, akkor a rendszer helyreállításához világos utasításokat kell elkészíteni. A tartalék telephelyen ellenőrizni kell, hogy vajon biztosítja-e a szükséges minőségben a kellő mennyiségű áramot, amit a rendszer igényel. Légkondicionálás Az elektromos áram biztosításához hasonlóan a légkondicionálás is lényeges része (lehet) a számítógépek elhelyezésének. Ha szükséges változtatás a jelenlegi helyszínen, akkor szakértőket kell hívni, és a tanácsukat kell kérni, hogy mekkora kapacitásra van szükség, és azt hogyan lehet a legjobban biztosítani. A katasztrófa elhárítás szemszögéből nézve a légkondicionáló rendszernek elégséges ellenálló képességgel kell rendelkeznie ahhoz, hogy lehetővé tegye egyes részeinek javítását, cseréjét vagy karbantartását, anélkül, hogy ez komolyabban befolyásolná a környezetet. Ez elérhető a felszerelések alkalmas csoportosításával a központi egységnél illetve néhány, szabad egységgel, némi tartalék kapacitás biztosítása árán. A légkondicionáló berendezéseket rendszeresen kell tesztelni, a tartalék áramszolgáltató rendszerrel együtt. Mielőtt a tartalék telephelyet kijelölnék, meg kell győződni arról, hogy a légkondicionálás megfelel az ott üzembe helyezendő hardver követelményeinek. Katasztrófa elhárítási alapváltozatok Az alapváltozatok az alábbiak semmit sem teszünk (do nothing), kézi helyettesítő eljárásokat alakítunk ki (clerical backup), kölcsönösségi egyezményt kötünk (reciprocal arrangement), erőd megközelítés (fortress approach), hideg indítású fix megközelítés (cold start fixed centre), hideg indítású szállítható megközelítés (cold start portable), meleg indítású külső megközelítés (hot start external), meleg indítású belső megközelítés (hot start internal), meleg indítású szállítható megközelítés (hot start mobile). A vezetésnek kell kiválasztania azt az alapváltozatot, aminek alapján készül majd a tényleges katasztrófa elhárítási terv. A vezetést ebben segíthetjük egy megvalósíthatósági tanulmány elkészítésével. Általánosságban elmondható, hogy egy előkészített alternatív telephely üzembe állítása órát igényel. (Természetesen a különféle változatok más-más időigénnyel bírnak.) 142

150 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés Az alábbiakban röviden áttekintjük az egyes alapváltozatokat. Semmit sem teszünk Ez egy veszélyekkel terhes változat, hiszen ha egy szervezet úgy gondolja, hogy tovább tud működni bizonyos informatikai szolgáltatások nélkül, akkor fel kell tennie azt a kérdést, hogy minek használja őket egyáltalában. A semmit sem teszünk kockázata az, hogy bármi bekövetkezhet. Kézi helyettesítő eljárásokat alakítunk ki Ez a változat gyakran nem megfelelő, minthogy nem áll rendelkezésre elégséges számú és képzettségű személyzet, akik működtetni tudnának egy helyettesítő rendszert, éppen az informatikai szolgáltatásoktól való függőség miatt. Kölcsönösségi egyezményt kötünk Ebben a változatban két, kompatibilis eszközöket használó szervezet megegyezik, hogy bármelyik a másik számára szükség esetén pótolja kieső szolgáltatást. Ez a megközelítés nem túl népszerű a gyakorlatban, minthogy a felek gyakran úgy találják, hogy adott esetben ez a saját működésük rovására menne. A tesztelés is jelentős gondokat okoz. Erőd megközelítés Ennek a megközelítésnek az a célja, hogy a lehetséges kockázatokat a minimálisra csökkentsük az informatikai szolgáltatások folyamatos elérhetősége érdekében. E változatban nincs alternatív telephely, ezzel szemben jelentős összegeket költhetnek az eredeti telephely minél biztonságosabbá tételére, a berendezések többszörözése által, környezeti felügyeleti és fizikai biztonsági intézkedések foganatosítása által. Hideg indítású fix megközelítés Ebben az esetben egy üres számítógép termet tartunk fenn, mely rendelkezik a szükséges áram, egyéb környezeti feltételekkel és telekommunikációs lehetőségekkel. Általában éves díjat kell fizetni a terem adott időtartamú igénybevételéért. A felhasználónak kell gondoskodnia a felszerelésekről. Hideg indítású szállítható megközelítés A telephely szállítható a számítógépek számára, helyét a felhasználó előre határozza meg, gyakran egy parkolóban. A szükséges telephelyi nagyságot az igényelt konfigurációhoz igazítják. A felhasználónak kell gondoskodnia a felszerelésekről ebben az esetben is. Meleg indítású külső megközelítés Ez a szolgáltatás olyan telephelyet biztosít, ami az igényekkel teljesen megegyező számítógépes együttes rendelkezésre állását garantálja. Ennek költségei függnek majd az igényelt processzorok számától az igényelt perifériák számától és típusától a szoftverektől az igényelt időtartamtól Vannak olyan cégek (Nagy-Britanniában), akik ilyen szolgáltatást ajánlanak, általában több előfizetőnek, akik megosztják a költségeket. Az előfizetők száma korlátozott, úgy 25 körüli. A létesítmény igénybevételi ideje rendszerint korlátozott. Meleg indítású belső megközelítés Ez az az eset, amikor a szervezet saját maga gondoskodik meleg indítású alternatív telephelyről. Ez kedvelt változat, mert a vészhelyzetre fenntartott telephelyet alkalmazás-fejlesztésre lehet használni, vagy tesztelésre és kiképzésre, amikor éppen nincs éles használatban. Ez feltételezi, hogy a fejlesztés stb. egy katasztrófa bekövetkezte után nem elsődleges fontosságú. Minthogy ez nem feltétlenül igaz, a kérdést előre meg kell vizsgálni. Ajánlatos ezt a telephelyet a központi telephelytől távol üzemeltetni. Meleg indítású szállítható megközelítés Ebben az esetben egy külső szolgáltató vállalkozik arra, hogy az adott helyre előre rögzített rendszert fog leszállítani adott időn belül. A gépeket általában konténerben szállítják a színhelyre, ami tartalmazza a szükséges környezeti feltételeket biztosító berendezéseket is. A felhasználónak kell egy olyan biztonságos helyet találnia, ahol a konténert el lehet helyezni, és az hozzáfér az elektromos hálózathoz és a telekommunikációs csatornákhoz. 143

151 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés A tervezés és kockázatmenedzsment egyéb tényezői Kapcsolat az informatikai infrastruktúra menedzsment egyéb funkcióival Mindazon eljárások, elvek, melyek az informatikai szolgáltatások zökkenőmentes nyújtását biztosítják a normál telephelyen, érvényben kell hogy maradjanak a tartalék telephelyen is. Annak garantálása érdekében, hogy a helyes gyakorlatot betartsák a tartalék telephelyen is, szükséges az alábbi vezetői tevékenységek és felügyeleti szintek aktív részvétele: szolgáltatási szint menedzsment, rendelkezésre állás menedzsment, kapacitás menedzsment, biztonság felügyelet, konfiguráció és változtatás menedzsment, probléma menedzsment, gyorssegély szolgálat. Eljárások a tartalék telephelyen Valószínű, hogy a tartalék telephelyen az eredeti rendszereknek nem pontos tükörképét találjuk. Ezért feltételezhető, hogy az üzemeltetők a normál eljárásoktól eltérő módon fognak dolgozni. A személyzet számára írásos utasításokat kell előre kiadni, és ezeket ki kell próbálni a katasztrófa terv tesztelése során. Biztonság A fizikai biztonsági intézkedések mértéke legalább olyan szintű kell legyen, mint a normál telephelyen (ha ugyan nem magasabb!) A biztonsági intézkedések szintje a végzett munka jellegétől függ. A biztonsági tiszt (security officer) feladata annak biztosítása, hogy a szükséges szintű biztonságot elérjék. Minden értékes adatot el kell menteni azért, hogy szükség esetén visszatölthető legyen. A mentéseket biztonságos és felügyelt helyen kell tartani. Ahol tűzbiztos szekrényekben tartják a mentéseket, körültekintően kell megválasztani a szekrények helyét. Hasonlóan fontos a szekrénykulcsok pótpéldányának biztonságos tárolása, lehetőség szerint nem a normál telephelyen. Ha páncélszekrényben tartanánk egy mentést, legyen listánk arról, hogy mi van a mentésen. A mentések különálló tárolása fizikailag biztonságos helyen történjen, ha az lehetséges, teljesen elkülönült épületben. A mentésekhez gyorsan kell hozzáférni vészhelyzet bekövetkezte esetén. Vannak olyan szolgáltatók, akik gondoskodnak a mágneses és papíros adathordozók gyűjtéséről, tárolásáról és szükség esetén történő visszajuttatásáról. Bizonyosodjunk meg arról, hogy a szolgáltató biztonsági intézkedései, környezeti körülményei és referenciái legalább olyan jók, mint a saját telephelyünké. Szállítás A katasztrófa elhárítási tervben eljárásoknak kell szerepelnie arról, hogy miképp szállítják a személyzetet a tartalék telephelyre. A tervben meg kell határozni azt is, hogy a mentések miképp jutnak el a biztonságos tároló helyről a tartalék telephelyre. Visszatérés normál állapotra Természetesen szükséges a normál telephelyre történő visszatérés tervezése, bár a visszatérésig szükséges idő nagyban függ a károk nagyságá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 állapothoz történő visszatérést engedélyező döntés része kell legyen az (eredeti) napi gyakorlat felülvizsgálata, hogy az eredeti katasztrófa ismételt bekövetkeztét el lehessen kerülni A katasztrófa elhárítási terv tartalma Jól átgondolt, gondosan kialakított és alaposan tesztelt terv kell ahhoz, hogy a szolgáltatások katasztrófa-helyzetben visszaállíthatók legyenek. Azonban nincs általánosan alkalmas terv, hanem szervezetenként változik, minden esetben egyedi. A terv annyira jó, amennyire a mögötte levő erőfeszítések értékesek. El kell kerülni, hogy a terv csupán kötelezően megírandó dokumentum legyen: tesztelni kell. 144

152 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés Tevékenység-sorozat katasztrófa esetén: 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 E tevékenységsorozat menedzselésére szolgál a katasztrófa-elhárítási terv, amelynek a következő főbb területekre kell kiterjedni: 1. Adminisztratív elemek (a terv céljainak meghatározása, a projekt definiálása, a szolgáltatások kiesésének hatáselemzése, a megelőzési stratégiák meghatározása, a kritikus alkalmazások meghatározása, a helyreállítási stratégiák definiálása. A főbb célok: az emberi élet védelme, a szervezet kárainak minimalizálása, a helyreállítási képesség maximalizálása, az ügyfelek, fogyasztók elismerésének megtartása). 2. Az akcióterv alapelvei és eljárásai. (Politikák a terv céljáról, terjedelméről, az érintett egységekről, utalások a kapcsolódó előírásokra, a felelősségek meghatározása. Eljárások az esemény észlelésére, a lehetséges katasztrófa-helyzetek meghatározása, kárbecslési elvek, ellátandó feladatok, az alaptevékenység visszaállítása, migrációs és helyreállítási eljárások.) 3. Tesztelés (biztosítani kell a rendszeres tesztelést és felülvizsgálatot a terv teljes tartalmi és szervezeti kiterjedésében). 4. A terv karbantartása (revíziók, frissítések és karbantartási kérdések). 5. Képzés (az alkalmazottak, vezetők, külső szolgáltatók képzésének alapelvei). 6. Függelékek (a legfontosabb nyilvántartások, térképek, szerződések, instrukciók, kérdőívek, értesítendők listája, eszkalációs listák, stb.). A CCTA ajánlása A katasztrófa elhárítás terv tartalmazza mindazon információkat, melyekre szükség van egy esetleges katasztrófa utáni helyreállításhoz. A brit Central Communication and Telecommunication Agency az alábbi pro forma tartalmat ajánlja. Adminisztráció informatikai infrastruktúra informatikai infrastruktúra menedzsment és eljárások Személyzet Biztonság Tartalék telephely. Visszatérés normál üzemeléshez Az egyes fejezetek tartalmát az alábbiakban ismertetjük. Adminisztráció Ez a fejezet arról tartalmaz információkat, hogy mikor és hogyan kell a tervet használni, melyek a foganatosítandó intézkedések, kik az érintett felelős személyek és hol lesz a tartalék telephely. Ezen belül külön alfejezet tartalmazza a terv módosítását dokumentáló adatokat (ki, mikor, mit változtatott) az esemény naplót, mikor mit történt, és milyen intézkedés követte a katasztrófa elhárítási csapatok, és tagjainak megnevezését (pl. irányítók, biztonságiak, üzemeltetés, telekommunikációsok, adatbeviteliek stb.) 145

153 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés mikor és hogyan kell a tervet életbe léptetni értesítendő személyek listáját, elérési adatokkal azok listáját, akik rendelkeznek a terv egy példányával a tartalék telephelyek felsorolását, elérési adataikkal Informatikai infrastruktúra Ez a fejezet sorolja fel a tartalék rendszerbeli hardver, telekommunikációs és szoftver elemeket, és/vagy a szükséges újrarendelési eljárásokat. Ide tartozik az összes érintett külső partnerrel kötött szerződés és egyezmény felsorolása is, ami segíti a helyreállítási és elhárítási tevékenységeket. Ezen belül külön alfejezet tartalmazza az érintett szerződéses szolgáltatók neveit, a szolgáltatás megnevezését, elérési adatokat, azon szerződések másolatait, melyek közvetlenül érintik a helyreállítást, a terv hatókörébe eső konfigurációs elemek felsorolását, az üzemeléshez szükséges minimális erőforrásszintet. Informatikai infrastruktúra menedzsment és eljárások Ez a fejezet tartalmazza azokat az utasításokat, amelyek végrehajtása által a szolgáltatásokat újra biztosítani lehet. A szolgáltatási szint megállapodások azon részei szerepelnek ebben a fejezetben, melyek a szükségállapot során nyújtandó szinteket rögzítik. Ezen belül külön alfejezet tartalmazza a tartalék telephelyen betartandó informatikai infrastruktúra menedzsment eljárásokat (pl. változáskezelés, problémamenedzsment stb.), az érintett szolgáltatási szint megállapodások másolatait, a tartalék telephelyre vonatkozó üzemeltetési kézikönyvet (rendszerindítás, lezárás, mentés, környezet stb.), a tartalék telephelyen történő feldolgozásban követendő ütemezést, a tartalék telephelyen dolgozók munkaköri leírását, beleértve ebbe a részletes utasításokat, a tartalék telephelyen történő adatbevitelre vonatkozó előírásokat és eljárásokat, a tartalék telephelyen történő output előállítására vonatkozó eljárásokat, a tartalék telephelyen követendő, helyettesítő vagy kiegészítő manuális eljárásokat. Személyzet Ez a fejezet nevesíti azokat a személyeket, akiket a tartalék telephelyre kell szállítani, a rendelkezésükre biztosított szállás-lehetőségekkel (ha ez szükséges) együtt. Ezen belül külön alfejezet tartalmazza a tartalék telephelyre eljuttatandó személyek névsorát, az új elérési adatokat, a szállások felsorolását (típus, elérési és egyéb adatok). Biztonság A fejezet leírja az eredeti telephelyi bomba és tűzzel kapcsolatos utasításokat. Ezen belül külön alfejezet tartalmazza bomba vagy tűzriadó esetén követendő eljárásokat, elsősegély-nyújtási eljárások leírását, külső értesítendő szervezetek és személyek felsorolását (pl. rendőrség, tűzoltóság, gázművek, csatornázási művek, biztosítótársaság stb., a tartalék alkatrészeket/eszközöket tároló raktárak felsorolását (elérési adatok), a tartalék alkatrészeket/eszközök tételes felsorolását (raktáranként). Tartalék telephely Ez a fejezet tartalmazza a tartalék telephely helyét, azoknak az embereknek a nevét, akikkel ott kapcsolatba kell lépni, a személyzet rendelkezésére álló lehetőségeket és szolgáltatásokat, és a személyzet szállításával kapcsolatos rendelkezéseket. Ezen belül külön alfejezet tartalmazza a tartalék telephely helyét, címét, hogyan lehet odajutni, 146

154 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés a tartalék telephelyen kapcsolat-felvételi személyek neveit, a tartalék telephelyen elérhető szolgáltatások listáját (pl. parkolási és étkezési lehetőségek), a tartalék telephelyen betartandó biztonsági előírásokat (beléptetési eljárások, hozzáférés jogosultság stb.), a tartalék telephelyre történő szállítást lebonyolító járművek listáját, a tartalék telephelyre szállítandó személyek névsorát (kit, honnan, hova, mikor). Visszatérés normál üzemeléshez Itt fel kell sorolni mindazon tényezőket, melyek befolyásolhatják a normál üzemmódra történő visszaállást, valamint a visszatérés során elvégzendő tevékenységeket A megvalósítás menete A katasztrófa elhárítási terv elfogadását a felső vezetés aláírásával kell hitelesíteni. A katasztrófa elhárító csapatnak kell gondoskodnia arról, hogy minden kapcsolódó szerződés rendben legyen, szét kell osztania a terv példányait, és gondoskodni kell biztonsági másolatokról, külön tárolva azokat, intézkednie kell a szükséges képzésekről, meg kell szerveznie a terv formális ismertetését az érintett személyzet számára, egyeztetnie kell a szolgáltatási szint menedzserrel, hogy a változtatások bekerültek a szolgáltatási szint megállapodásokba, és a felhasználók megértették és elfogadták azokat, gondoskodniuk kell a terv rendszeres teszteléséről és frissítéséről. A terv másolatai Az elfogadott tervet egy távoli helyen és a vészhelyzeti irányító központban kell tárolni, úgy, hogy egy katasztrófa bekövetkeztekor fel lehessen használni. Másolatokat kell eljuttatni a biztonsági tisztnek, az informatikai audit csoportnak, az informatikai szolgáltatások vezetőjének vagy kijelölt helyettesének, az üzemeltetés tagjainak és a további érintetteknek. Minthogy a terv bizalmas és /vagy titkos információkat tartalmazhat, biztonságos helyen kell őrizni. Kiképzés A személyzetnek ismernie kell, hogy milyen szerepet kapott a katasztrófa elhárítási tervben, és hogy feladatát hogyan kell ellátnia. Azt is figyelembe kell venni, hogy katasztrófa-szituációban az ember nem szokott olvasgatni. Ahol egyéni és speciális készségek vannak, ott kereszt-képzéssel (egymás oktatásával) kell ezeket közkinccsé tenni. A személyzetnek az a része, amely katasztrófa bekövetkeztekor időlegesen más helyszínen kell dolgoznia, nem szenvedhet pénzügyi hátrányokat emiatt. A terv tesztelése Teszteket kell lefolytatni a terv elkészülte után, majd a későbbiek során rendszeresen, legalább évente. A tesztelés során a terv részeit szárazon (emulálva) kell végrehajtani, különös figyelmet fordítva az esetleges változásokra. Gyakorlati teszteket kell végrehajtani a tartalék telephelyen, ahol az érintett személyzet ténylegesen elvégzi a munkákat. A teszteknél előre meg kell határozni azokat a kritériumokat, amelyek alapján kijelenthető, hogy a tervek megfelelnek a jelenlegi helyzetnek, működőképesek és a személyzet felkészült. A projekt csapatnak rendszeresen felül kell vizsgálnia a terv tartalmát, különösen az éves teszt után, illetve egy katasztrófa bekövetkezte után. A szemlékkel kell elérni azt, hogy a katasztrófa elhárítási tervet karbantartják, tartalma naprakész és megfelel jelenlegi követelményeknek. Figyelmet kell fordítani azokra a változásokra, amelyek a tesztek és a szemlék között történtek meg. A katasztrófa elhárító csapat felelőssége a változások következményeinek az értékelése, és annak biztosítása, hogy az érintett tervek is módosításra kerülnek. 147

155 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés A funkció bevezetésének időzítése és validálása Minden informatikai rendszer, amihez nincsen katasztrófa elhárítási terv, kockázatosnak minősül. Éppen ezért minél hamarabb munkához kell látni. Az új rendszereket eleve a katasztrófákkal szembeni ellenálló képesség jegyében kell tervezni. Egy működőképes katasztrófa elhárítási terv kidolgozásához szükséges idő nagysága függ a személyzet tapasztalatától és képzettségétől, illetve a rendelkezésükre álló eszközöktől. A terv egyes részeinek elkészítése figyelemre méltóan sok időt emészt fel, különösen a vállalkozókkal kötött szerződések esetében. A munkának ez a része minél hamarabb kezdődjön el! Függőségek A katasztrófa elhárítási terv eredményes voltához szükséges az, hogy alaposan dolgozzák ki, kimerítően teszteljék, a szerződések megfelelőek, egyeztetettek és elfogadottak legyenek a teljes szervezetben, és a teljes személyzet legyen elkötelezett a terv iránt. A szolgáltatási szint megállapodásokban rögzíteni kell minden olyan változást, ami beáll a megállapodott követelményekben vészhelyzet bekövetkezte esetén. A kulcsembereket, különösen azokat, akik a terv megvalósításával foglalkoznak, meg kell kérdezni, hogy van-e bármilyen utazási, munkával kapcsolatos, rendelkezésre állási gondjuk, azaz bármi, ami akadályozhatja őket a munkájuk végzésében a tartalék telephelyen. Ezeket a kérdéseket a tervek elkészítésének lehető legkorábbi szakaszában kell feltenni. A tervben szerepelnie kell egy olyan eljárásnak, amivel a felhasználókat értesíteni lehet bármilyen, a szolgáltatásokban beálló változtatásokról a tartalék telephelyen. Költségek Mint említettük, egy katasztrófa elhárítási terv elkészítésének igen magas lehet a költségvonzata. Az előkészítő szakasz során fel kell becsülni ezeket. A legfontosabb költségek, melyek felmerülnek a katasztrófa elhárítási terv bevezetése során, az alábbiak: a terv elkészítésének költsége és ideje, a terv elkészítéséhez szükséges szoftver csomag(ok) költsége, a kockázat menedzsment javaslatainak megvalósításából adódó költségek (pl. további berendezések), a választott alapváltozat futó költségei, ami a mérettől és egyéb tényezőktől függ, a terv karbantartásának a költségei, a terv tesztelésének és szemlézésnek a költségei. Az elkötelezettség megszerzése Már a projekt kezdeti szakaszában javallott egy figyelemfelkeltő kampány lefolytatása. A figyelemfelkeltő kampány kezdő lépése lehet egy kérdőív szétküldése a vezetőkhöz, amely rámutat az informatikai szolgáltatásoktól való függőségükre. Hasznos lehet katasztrófákról szóló híradások terjesztése is. Eredményes lehet olyan kihívó kérdéseket közzétenni valamilyen szervezeti fórumban, mint pl. a következő: Mit tenne, ha holnap munkába jövet azt tapasztalná, hogy nem engedik az épületbe, mert az leégett? Meg kell szerezni a vezetés elkötelezettségét az informatikai igazgató, az informatikai szolgáltatás vezetője, a szolgáltatási szint menedzserek és a rangidős felhasználói vezetők részéről: nekik évente legalább egyszer a kézjegyükkel kell ellátni egy egyezséget, melyben tanúbizonyságát adják, hogy: ismerik a katasztrófa elhárítási terv tartalmát, elégedettek a terv teszteltségével, bizonyosak abban, hogy a terv a gyakorlatban is beválik. Ez a módszer felhívja a rangidős vezetés figyelmét a katasztrófa elhárítás tervezésére, és segít abban, hogy a tervet rendszeresen teszteljék. A megvalósítás utáni lépések A tervet teljességében kell tesztelni és szemlézni, a vezetés részvételével. A vezetésnek teljesen elégedettnek kell lennie a terv tartalmával, 148

156 Infrastruktúra menedzsment Katasztrófa elhárítás tervezés elégedettnek kell lennie a terv megfelelő tesztelésével, bizonyosnak kell lennie abban, hogy a terv a gyakorlatban beválik majd. A lehetséges problémák A projekt csapat erőforrásokkal történő ellátása és finanszírozása problémákhoz vezethet, ugyanakkor a katasztrófa elhárítási terv létrehozásának a jelentőségét nem lehet alábecsülni. Ahol nincsen katasztrófa elhárítási terv, az a szervezet veszélyben van! Előfordulhat, hogy a szervezet nem kötelezi el magát kellőképp a funkció üzemeltetése mellett. Ilyen esetben hívjuk a vezetés figyelmét a katasztrófa-elhárítás elmulasztásából adódó veszélyekre. Gyakran probléma, hogy a katasztrófa elhárítással foglalkozó csapatot nem látják el a megfelelő erőforrásokkal. A pénzügyi problémák elkerülése érdekében a költségvetés tervezés során külön figyelmet kell szentelni a katasztrófa elhárításnak. Ha a terv tesztelése alatt az éles rendszert is üzemeltetni kell, akkor lehet, hogy a személyzet létszáma nem elégséges Ilyen esetben a hétvégi (munkaidőn túli) tesztelést ajánljuk Ajánlott irodalom Bates, R. J. Jr.: Disaster Recovery Planning. Networks, Telecommunications, and Data Communications. McGraw-Hill, 1992, ISBN Contingency Planning. IT Infrastructure Library. HMSO ISBN CCTA Risk Analysis and Management Methodology Contingency Planning and Disaster Recovery: Protecting Your Organization's Resources. ISBN: A témával foglalkozó Web-oldalak: /security/bas-user/sld102.htm raw.rutgers.edu/raw/iia/edprods/a6055_bk.htm bilbo.isu.edu/security/fmangr/sld041.htm

157 11. Szolgáltatási szint menedzsment A szolgáltatási szint menedzsment az a folyamat, amely során a felhasználók és az informatikai szolgáltató részleg között létrejött írásos megállapodás vagy szerződés segítségével menedzselik az informatikai szolgáltatások minőségét. Ez a szerződés meghatározza az egyes felekre háruló felelősséget, és kötelezi az informatikai szolgáltatót, hogy előre meghatározott szintű minőségben és mennyiségben szolgáltasson mindaddig, amíg a felhasználó fenntartja igényét az elfogadott korlátok között. Ez a technika előfordul a magyar közszolgálatban is bár nem feltétlenül informatikai közegben -, ahol szervezeti egységek megállapodást kötnek egymással. A Szolgáltatási Szint Megegyezés (SzSzM) kulcsfontosságú a felhasználók és a szolgáltatási szint menedzser között az ügyfél-szolgáltató kapcsolat kialakításában. A SzSzM meghatározza a fogyasztók elvárásait és a szolgáltatási szint menedzser ill. a fogyasztók kötelezettségeit, valamint kölcsönösen elfogadott alapot határoz meg a szolgáltatások minőségének méréséhez. Ez hosszú távon segítséget jelent az informatikai szolgáltatások eredményesebb vezetéséhez. Alkalmazása költségmegtakarítást jelent, mert kiegyensúlyozottabb, a szervezeti prioritásoknak megfelelő szolgáltatások biztosítását teszi lehetővé, és mivel csökkenti a felhasználók és az informatikai szolgáltatók között a szolgáltatási szintekről kialakuló viták és konfliktusok megoldásához szükséges időt ahhoz képest, amire formális megegyezés nélkül amúgy szükség lenne. A múltban a szolgáltatások nyújtása főként az informatikai szolgáltató részleg felügyelete alatt állt, ahol az adatfeldolgozó osztály igyekezett a megfelelő szolgáltatási szintet biztosítani a felhasználók számára. A szolgáltatási szint menedzsment feladata, hogy segítse az informatikai szolgáltató egységet megfelelni a szervezeti szükségleteknek, a növekvő felhasználói igényekhez is igazodó minőségi informatikai szolgáltatások követelményének (ami egyre fontosabb, ahogy az informatikai mindinkább mindent áthatóvá és meghatározóvá válik). A szolgáltatási szint menedzsment létéből eredő előnyök a következők: A szolgáltatási szint menedzser felelős lesz egy meghatározott, konzisztens és ellenőrizhető szolgáltatási szabvány eléréséért. A felhasználó az informatikai funkcióval egyensúlyt teremthet a látszólag szükséges szolgáltatások szintje és nyújtásuk költségei ill. a szolgáltatás komplexitása között. A Szolgáltatási Szint Megállapodás (SzSzM) hosszú távon pozitív költség-haszon arányt eredményez, mivel a szervezet képessé válik a ténylegesen szükséges informatikai erőforrások pontosabb meghatározására. A szolgáltatásfejlesztő programok javuló szolgáltatási minőséghez vezetnek, növelve a felhasználók termelékenységét. A viták gyorsabban és objektívebben oldhatók meg. Az informatikai szolgáltatások többé nem szembesülnek előre nem látható igényekkel. A megállapodás szorosabbá teszi a kapcsolatot a felhasználó és a szolgáltató között. A szolgáltatási szint menedzsmentnek az informatikai funkció lényeges részévé kell válnia minden olyan szervezetben, amely arra törekszik, hogy elérje céljait, és hatékonyan alkalmazza a technológiát. A szolgáltatási szint menedzsment az informatikai szolgáltatások minőségének és mennyiségének menedzselési folyamata a változó szervezeti és felhasználói igényeknek megfelelően, tárgyalások eredményeképp létrejött megállapodások szerint. A szolgáltatások minősége a szolgáltatás rendelkezésre állása, megbízhatósága, teljesítménye és növekedési kapacitása, a felhasználói támogatás szintje, a katasztrófa-elhárítás tervezési és a biztonsági megoldások alapján határozható meg. A szolgáltatások minősége kifejezhető a kielégítő funkcionalitás minimális szintje szerint is. A SzSzM-nek mindezeket kezelnie kell A szolgáltatási szint menedzsment folyamata A szolgáltatási szint menedzsment tárgyalások, meghatározások, szerződéskötések, megfigyelések és szemlék folyamata azon felhasználói szolgáltatások szintjével kapcsolatban, melyek szükségesnek bizonyultak és költségeik is indokolhatók. E tárgyalások eredménye a Szolgáltatási Szint Megegyezés, 150

158 Infrastruktúra menedzsment Szolgáltatási szint menedzsment ami írásos megállapodás vagy szerződés az informatikai szolgáltató és a felhasználók között, amely dokumentálja az informatikai szolgáltatások kölcsönösen elfogadott szintjeit. A folyamat részei a következők: A szolgáltatások felmérése és ennek alapján szolgáltatási katalógus összeállítása. Tárgyalások eredményeként a felhasználói vezetés és az informatikai szolgáltatás menedzsment megegyezésre jutnak a szolgáltatási szint szükségletekről, és üzemeltetési követelményekké alakítják ezeket a követelményeket, majd ennek megfelelően alakítják a szerződéseket a szállítókkal és karbantartókkal. A meghatározott követelményeket szolgáltatási szint megállapodásban dokumentálják Figyelemmel kísérik, szemlézik a szolgáltatási szinteket, és jelentéseket készítenek A szolgáltatási szintek elérésében tapasztalt problémák megoldása érdekében beavatkozásokat javasolnak Biztosítják, hogy a szolgáltatási szint megállapodások rendszeresen felújításra kerüljenek a változó üzleti igényeknek és felhasználói követelményeknek megfelelően. A SzSzM-ben leírtak jogi értelemben természetesen nem kötelezők, de ha a szervezet kihelyezi informatikai szolgáltatásokat (outsourcing), akkor ez a megállapodás a szolgáltatásokról kötött polgárjogi szerződés részévé válhat. A Szolgáltatási Szint Megegyezés jellemzően legalább a következőkre terjed ki: a szolgáltatási időszakra (service hours), a szolgáltatások elérhetőségére (service availability), a felhasználói támogatás szintjeire (user support level), a reagálási képességre (responsiveness), a funkcionalitásra (functionality), a katasztrófa-elhárításra (contingency). Csak olyan elemeknek kell a megállapodásba kerülnie, amelyek megfigyelhetők és mérhetőek. Ez a megállapodás kijelöli mind az informatikai részlegre, mind a felhasználóra háruló felelősséget. Egyrészt arra kötelezi az informatikai szolgáltató funkciót, hogy elfogadott minőségű szolgáltatásokat kínáljon, másrészt az elfogadott határok közé korlátozza a felhasználók szolgáltatások iránti igényeit. Ez formális és üzleti jellegű kapcsolatot tesz lehetővé, hasonlót, mint a kiskereskedő és vásárlója között. 151

159 Infrastruktúra menedzsment Szolgáltatási szint menedzsment Felhasználók Felhasználó Felhasználó Felhasználó Felhasználó Szolgáltatási szint megállapodás(ok) IT szolgáltató részleg Szolgáltatások Rendszer Szerződések Szállítók és karbantartók Hardver Alkalmazási szoftver Környezet Telekommunikáció 33. ábra: Szolgáltatási megállapodások Amint az ábrán is látható, a felhasználó szolgáltatási szint menedzsment és a szolgáltatók (szállítók) közti kapcsolat hasonlít a vásárló kiskereskedő nagykereskedő kapcsolathoz, abban az értelemben, hogy a kiskereskedő által a fogyasztó számára nyújtott szolgáltatások nagymértékben függnek a nagykereskedő szolgáltatásaitól. Ez esetben a szolgáltatási szint menedzsmentnek kell felelősséget vállalnia a felhasználó által tapasztalt bármely problémáért, a korábban említett kiskereskedő példájához hasonlóan. Ez azonban szükségessé teszi, hogy az informatikai infrastruktúra összetevőinek esetleges külső szállítóival és karbantartóival kötött szerződések megfelelően alátámasszák a felhasználói szükségleteket, ezeknek tehát lehetőség szerint szolgáltatási minőségi elemeket is tartalmazniuk kell A szolgáltatási szint menedzsment bevezetése Tervezés Amikor megszületett a döntés a szolgáltatási szint menedzsment bevezetéséről, lényeges, hogy a bevezetés felügyelt és ellenőrzött módon történjen. E döntés előtt a felső vezetés számos akadállyal 152

160 Infrastruktúra menedzsment Szolgáltatási szint menedzsment szembesülhet, amelyeket meg kell vizsgálni és leküzdésük érdekében meg kell győzni az érintetteket, a szolgáltatási szint menedzsment nyújtotta hasznok elfogadtatásával. A szolgáltatási szint menedzser kinevezése A Szolgáltatási Szint Megállapodással kapcsolatos tárgyalásokért és menedzsment tevékenységekért felelős szolgáltatási szint menedzsert kell kinevezni vagy kell kijelölni, a funkció (informatikai szolgáltató egység) terjedelmétől függően. Tipikusan több funkcionális informatikai menedzser visel részleges felelősséget a szolgáltatási szintekért, főként az üzemeltetés területén. Az, hogy a szerepet egy olyan személyre bízzák-e, aki már valamely más szerepkört is betölt, függ az ellátandó szolgáltatástól és a pozícióhoz kapcsolódó felelősségtől is. Valószínűtlen, hogy egy adminisztratív vagy felügyelő pozícióban levő személynek meglenne a kellő tapasztalata e poszt betöltéséhez. A kinevezés kulcseleme az, hogy a megfelelő személy már a szolgáltatási szint menedzsment bevezetésének kezdetétől fogva elkezdhesse munkáját, rendelkezzen a megfelelő jogosultsággal és kapacitással a felhasználókkal való Szolgáltatási Szint Megállapodási tárgyalások folytatásához, és legyen elfogadott személy valamennyi fél számára. A Szolgáltatási Szint menedzsernek felelősséget kell vállalnia valamennyi problémáért, amelyet a felhasználók észlelnek, ugyanolyan módon, ahogy a kereskedő is köteles foglalkozni a fogyasztó problémáival, anélkül, hogy közvetlenül a nagykereskedőre hárítaná a probléma orvoslását. A tervezés fontossága Az informatikai szolgáltató és a felhasználó közötti kapcsolat stabilizálásához nélkülözhetetlen a szolgáltatás szintjében való megegyezés. A szolgáltatási szint menedzsment előnyei indokolhatók a szervezeti szükségletekkel de akár józan megfontolásokkal is. Emiatt a szervezetek gyakorta túl gyorsan igyekeznek Szolgáltatási Szint Megállapodást kialakítani, gondos tervezés és a következmények megfontolása nélkül. A SzSzM elhamarkodott bevezetése azonban szinte bizonyosan negatív következményekkel jár, mivel a megalapozó háttér nélkül a minőségi szolgáltatások nem biztosíthatók, a megállapodások sorozatos megszegése hiteltelenséghez vezet, hosszú távon akadályozva a minőségi szemlélet meghonosodását és az informatika hatékony és eredményes felhasználását. Figyelemfelkeltő kampány Ahhoz, hogy a felhasználók, az informatikai és a felső vezetés egyaránt elkötelezetté váljon, meg kell ismertetni velük a Szolgáltatási Szint Megállapodáshoz kapcsolódó reális elvárásokat és a belőle származó előnyöket. A figyelemfelkeltő kampány célja, hogy kialakítsa a szolgáltatások menedzsmentjéhez szükséges új magatartásmódot és segítse annak terjedését, és összefogja valamennyi résztvevőt, elkerülve, hogy egyetlen specifikus területre összpontosítana. Ha szükséges, a külső partnereket, szállítókat is be kell vonni a folyamatba. A közszolgálati, kormányzati szférában a figyelemfelkeltő kampány nem feltétlenül olyan átfogó és nagyléptékű, mint egy piaci szervezet esetében. Azonban alapvetően fontos annak a filozófiának az elfogadása, hogy a megfelelő szintű szolgáltatást kell nyújtani a megfelelő áron valamennyi fél számára, már a Szolgáltatási Szint Megállapodás tárgyalásai, megvalósítása és menedzselése előtt is. A figyelemfelkeltő kampány eredménye végső soron az, hogy még a Szolgáltatási Szint Megállapodások létrejötte vagy kivitelezhetetlenné válása előtt rámutat a hatásokra, amelyeket a megállapodás a felekre és a szervezet egészére gyakorol. Az SzSzM előkészítése Az esetek nagy részében a Szolgáltatási Szint Megállapodások magas szintű kötelezettségvállalást jelent az informatikai funkció számára. Ez túl ambiciózus vagy meggondolatlan informatikai funkciók esetében gyakran lehetetlen célok felvállalását jelenti. A közös hiba az, hogy az adott szervezetnél meglévő infrastruktúra és környezet nem képes támogatni a megállapodást és az informatikai szolgáltatások minőségének menedzsmentjét. A környezet értékelése A Szolgáltatási Szint Megállapodás előkészítésének első lépése a jelenlegi informatikai funkció meghatározása és értékelése: 153

161 Infrastruktúra menedzsment Szolgáltatási szint menedzsment osztályonként, szolgáltatásonként, egyéb, alkalmas bontásban, Az eredmények alapján fel lehet becsülni a Szolgáltatási Szint Megállapodás lehetséges hatását a jelenleg nyújtott szolgáltatásokra. Ez az adatgyűjtés valójában a szolgáltatónál lefolytatott audit. A jelenlegi üzemeltetési és technikai menedzserek ezt a folyamatot fenyegetőnek találhatják, és védekezően reagálhatnak. Pedig az audit nem azért folyik, hogy egyéneket hibáztasson, hanem hogy védje a szervezet és a tulajdonosok érdekeit. Talán az lehet itt a siker kulcsa, hogy emlékeztessük mindazokat, akik az üzemeltetési és a technikai támogató részlegben dolgoznak, hogy ők is érintettek, érdekhordozói (részesei) a szervezetnek. Tehát a szervezet, mint egész által élvezett előnyök számukra is hasznot jelentenek, nem utolsósorban a munkahelyi biztonság miatt, amelyet egy sikeres szervezet nyújthat. Bár időigényes, mégis lényeges a környezet értékelése. A kulcsterületek: A funkció/osztály kulcsembereinek bevonása. A részleg tapasztalatainak áttekintése. A munkamódszerek vizsgálata és tesztje. A készségszintek vizsgálata. A személyzet magatartásmódjának megfigyelése és szem előtt tartása. Az információ elemzése Osztály Az összegyűjtött adatokból kirajzolódik a kép a felelősségi viszonyokról az informatikai struktúrában. Világossá válnak az erősségek és a gyengeségek, mint a funkciók lehetséges fejlesztési területei. Ez a kezdőpontja annak, hogy összevessük a szolgáltatásokat a lehetséges követelményekkel. Ez lehetőséget jelent arra is, hogy szemlézzük, és esetleg átstrukturáljuk a funkciót a teljes elemzés alapján. Harmadszor, az adott területen belüli emberi erősségek is lemérhetők a szükséges új készségek és szerepek megszerezhetőségével együtt. Szolgáltatás Valamennyi szempontot meg kell vizsgálni, hogy valós képet nyerjünk a rendszeren szimultán futó szolgáltatásokról. Fontoljuk meg pl. a következőket: Az adatok időben megérkeznek? Az ütemezést betartják? Hány újrafuttatásra van szükség hibák vagy késések következtében? Mi történik a változtatásokkal? Mi történik a problémákkal? Az adat mikor kerül biztosításra? Léteznek katasztrófa-elhárítási tervek és tesztelik-e azokat? Milyen nagygépes támogatás létezik főidőben? Ha túljutottunk ezen a fázison, közös szekciót lehet összehívni a felhasználói közösséggel, hogy egy külső szakértő segítségével bemutassák nézeteiket és vélekedésüket a szolgáltatásról. Bár az értékelési fázis célja, hogy mérje a belső szolgáltatást, ez összekapcsolható azzal, hogy a becsléseket és a felhasználói véleményeket kevésbé szubjektívvé tesszük. Szolgáltatásokat segítő eljárások Szükség van arra, hogy számba vegyük a meglévő támogató eljárásokat (amilyen pl. a gyorssegélyszolgálat), hogy összehasonlíthassuk a jelenlegi teljesítményt azzal a jövőbeni szolgáltatás iránti kereslettel, ami a Szolgáltatási Szint Megállapodással jön létre. A szolgáltató kultúra kialakítása azt jelenti, hogy hangsúlyt helyezünk a felhasználóval való törődésre és a szolgáltató készségekre. Fontos átgondolni, hogy a meglévő fizikai, emberi és pénzügyi erőforrások megfelelnek-e a jövőbeni hasznosítási és a karbantartási igényeknek. Az installációk már használhatnak részben automatizált vagy kézi rendszereket. A kulcs valamennyi támogató folyamatnál, hogy integrált jelentéseket és pontos teljesítmény adatokat nyújtsanak. 154

162 Infrastruktúra menedzsment Szolgáltatási szint menedzsment Az eredmények bemutatása Az értékelő tevékenységet validálni kell, és teljes szemlének kell alávetni, mielőtt a felsővezetésnek bemutatnánk. Nem szabad elárasztani a hallgatóságot túl sok adattal, inkább a következtetésekre és ajánlásokra kell hangsúlyt helyezni. Ez az a választási pont, amikor el kell dönteni, hogy a Szolgáltatási Menedzsment funkció és a Szolgáltatási Szint Megállapodás kialakítása folytatódik-e vagy sem, és hogy stabilizálják a jelenlegi környezetet vagy egy fejlesztési programot alakítanak ki a becslések eredményeként, ami segít abban, hogy megfeleljenek a jövőbeli szolgáltatási követelményeknek? A felső vezetésnek válaszolnia kell a kérdésre: Ebben a fázisban a szolgáltatási szint menedzsment még mindig jó ötletnek látszik, vagy inkább veszedelmesnek? A működési költségek ebben a fázisban alacsonyak. Ezen értékelések elmulasztásának költsége viszont jóvátehetetlen, ha a szolgáltatási szint menedzsmentet helytelenül alakítják ki. Ahogy egy jó ételnél vagy egy sikeres csoport építésénél, itt is az előkészítés az, ami számít. A meglévõ szolgáltatások katalógusa Fontos, hogy a szolgáltatási szint menedzser jól átlássa és megértse a funkció szolgáltatásait, ismerje azok jellemzőit, és minden szükséges információval rendelkezzen a felhasználókról. Ennek érdekében valamennyi szolgáltatási jellemzőt dokumentálni kell egy szolgáltatási katalógusban. A szükséges információknak két forrása lehet: Az informatikai funkción belülről származó információk a meglévő szolgáltatásokról annak futása során (és előrejelzések a jelenleg fejlesztés/teszt alatt álló szolgáltatásokról). A felhasználók igényei ezekre a szolgáltatásokra. A szolgáltatás azonosítása, követése és módosítás megkönnyítése céljából a szolgáltatási katalógust egy táblázatkezelő vagy adatbázis csomagban kell tárolni, a megfelelő interfésszel a többi informatikai infrastruktúra eszközhöz. A felhasználói/megegyezési struktúra tervezése A Szolgáltatási Katalógus(ok) elkészültével szolgáltatási szint menedzser számára lehetővé válik a tárgyalások kezdeményezése az informatikai funkció és a felhasználók között, a felhasználók és felhasználók között a megosztott szolgáltatásokról, és így tovább. (A felhasználók közé mindazokat számíthatjuk, akik az informatikai szolgáltatásokat használják, beleértve az informatikai fejlesztői csoportot. A szolgáltatások közé tartozik az egyszerű alkalmazói programoktól a szervezeti szintű rendszerekig minden informatikai alkalmazás.) A szolgáltatási szint menedzsernek meg kell határoznia (definiálnia) a megfelelő informatikai szolgáltatásokat, mielőtt tárgyalásba kezdene róluk. A meglévő szolgáltatások meghatározásával a Szolgáltatási Szint Menedzser releváns információhoz jut, ami képessé teszi, hogy tervet készítsen a felhasználók csoportosításáról, lemérje az egyes megállapodások terjedelmét és meghatározza a szerződő feleket. Mindez a felhasználókkal való párbeszéd alapját képezi. A Szolgáltatási Szint Megállapodás dokumentuma megjelenítheti a megtárgyalt és elfogadott követelményrendszert a következő módon: egy meghatározott szolgáltatás vagy egy meghatározott felhasználó, vagy felhasználók logikai csoportja, figyelembe véve az általuk használt valamennyi szolgáltatást. A szervezetek a megkísérelhetik a megállapodások hatókörének meghatározását a következő kritériumok közül egy vagy több alkalmazásával: Földrajzi elhelyezkedés, Szervezeti funkció, A megfigyelés (monitoring) könnyűsége, Az eljárási mód. Ha egy az egyhez kapcsolat került meghatározásra az informatikai funkció és egy egyedi szolgáltatás felhasználója között, akkor egyszerűbb lesz a tárgyalás a szolgáltatási szint követelményekről, mivel semmilyen harmadik fél sem vesz részt közvetlenül a folyamatban. Másrészről, ha a szolgáltatáson 155

163 Infrastruktúra menedzsment Szolgáltatási szint menedzsment többen osztoznak (pl. egy on-line szolgáltatás), akkor a Szolgáltatási Szint Menedzsernek valamennyi féllel egyeztetnie kell, és nem folytathat egyedi vagy zártkörű tárgyalásokat. Hagyományosan a felhasználók mindig abban a hitben vannak, hogy az ő szolgáltatásaik a legfontosabbak, nem sokat törődve a többi felhasználóval. A tipikus problémahelyzet a következő: "Az "A" felhasználó késő éjszakáig dolgozni akar, de ezzel feltartja a "C" felhasználó kötegelt futtatását." Ki dönt ilyen esetben? Rendszerint az, aki hangosabban kiabál. Ezzel az esetleges megoldással szemben a Szolgáltatási Szint Megállapodások és tárgyalások lehetővé teszik, hogy a döntés egy objektív szemponton alapulhasson a szervezeti igényein. Tárgyalás a felhasználókkal Ha a megállapodások struktúrájában megegyezésre jutottak a felhasználókkal (ami nagyon időigényes és iteratív folyamat), a tartalmi és érték-elemek tervezésére is sor kerülhet a felhasználókra vonatkozóan. Rendszerint a jelenleg nyújtott szolgáltatás színvonala a kiindulópont, de ha ez nem elfogadható, akkor követelmény célokat kell meghatározni. Mindkét esetben kezdettől fogva figyelembe kell venni a jövőbeni szolgáltatási szint követelménybeli változásokat. A céloknak reálisnak és elérhetőnek kell lenniük, és számításba kell venniük a javulásokhoz szükséges pótlólagos beruházásokat és a kapcsolódó folyamatos (üzemeltetési) költségeket is. A szolgáltatási szint menedzsernek a feladata értékelni a felhasználók szolgáltatási szint követelményeinek hatásait és költségeit. Ehhez modellező eszközök alkalmazása javallott. Ez egy iteratív folyamat lesz, amely csak akkor vezet elfogadott szolgáltatási követelményekhez, ha valamennyi résztvevő elégedett, mivel korrekt egyensúlyt teremtettek a követelmények, a költségek és az okozott komplexitás között. Az elfogadott szolgáltatási szint garantálásához korlátozni kell az elvégezhető munkamennyiséget, a terhelést. Erről megegyezésre kell jutni a felhasználóval. Elveket kell kialakítani arra az esetre, ha e korlátozásokat túllépnék. Fontos, hogy legyen némi rugalmasság a korlátozások terén. 156

164 Infrastruktúra menedzsment Szolgáltatási szint menedzsment Szolgáltatási Szint Megállapodás Felhasználó csoport A Felhasználó csoport B Felhasználó csoport C Felhasználó csoport D Szolgáltatás 1 Szolgáltatás 2 Szolgáltatás 3 Szolgáltatás 4 Felhasználó csoport A Felhasználó csoport B Felhasználó csoport C Felhasználó csoport D Szolgáltatás 1 Szolgáltatás 2 Szolgáltatás 3 Szolgáltatás 4 Szolgáltatási Szint Megállapodás 34. ábra: SzSzM változatok A SzSzM kerete, váza Elvében a SzSzM kiváló eszköz; gyakorlatban azonban gyakran több problémát okozhat, mint amennyit megold. A rosszul összeállított vagy megvalósított megállapodások komoly zavart képesek okozni, amint az gyakran meg is történik. A cél az, hogy javítsuk a szolgáltatás színvonalát és nem az, hogy romboljuk az informatika és a fogyasztók/felhasználók közötti kapcsolatokat. A SzSzM struktúrája és tartalma az egyes szervezetek munkamódszereitől és követelményeitől függ. A SzSzM keret előkészítése fontos projektként kezelendő, és mind az informatikai, mind a felhasználók részéről hozzájárulást igényel. A folyamat időigényes és költséges lehet. A megállapodás vázát a következők szerint kell tervezni: Valamennyi kitételt (megállapodási pontot, klauzulát) figyelemmel kell kísérni (monitoring). Valamennyi kitételt karban kell tartani. Valamennyi kitételnek mérhetőnek kell lennie. Ha az SzSzM egy kitétele nem mérhető, akkor azt világosan meg kell állapítani, máskülönben azt feltételezhetnék, hogy a SzSzM valamennyi részlete megfigyelésre kerül. A Szolgáltatási Szint Megállapodás tartalma Még egyszer hangsúlyozzuk, hogy a SzSzM tartalma a szervezethez és annak kultúrájához kell illeszkedjék. Valamennyi mérhető elem része kell legyen a megegyezésnek. A SzSzM keret 157

165 Infrastruktúra menedzsment Szolgáltatási szint menedzsment elkészíthető a tárgyalások számára, lehetővé téve ezáltal a szolgáltatási szint menedzsment számára, hogy megállapodásonként feltérképezze a releváns értékeket. A váz felhasználható részleges SzSzM kialakításához is egy felhasználó specifikus igényeinek kielégítésére. Szükség lehet új kitételekkel való kiegészítésre is, új berendezés vagy szoftver, valamely fogyasztó egyedi igényei vagy egy új rendszer követelményeinek való megfelelés miatt. A vázat az új követelményeknek megfelelően kell kiterjeszteni. Kikötés 1 Kikötés 2 Kikötés 1 Kikötés 3 Kikötés 3 Kikötés 4 Kikötés 4 Kikötés 5 Kikötés 7 Kikötés 6 Kikötés ábra: SzSzM kikötések központi kezelése Bár minden SzSzM különbözik, a CCTA ajánlásai szerint a következőket ajánlatos tartalmaznia: Címlap beleértve: A megállapodás köre (terjedelme) Aláírások/jóváhagyások A következő szemle dátuma vagy a SzSzM érvényességi periódusa A korábbi változtatások dátumai A szolgáltatások leírása: A funkciók rövid bemutatása Az alkalmazások A főbb tranzakciótípusok Szolgáltatási időszak leírása (service hours szolgáltatási órák): Időszakok, melyekben a szolgáltatások elérhetőségét tervezik Speciális feltételek a hétvégi és egyéb időszakokra Karbantartás (housekeeping), tervezett rendszerkarbantartás A szolgáltatási időszakkal kapcsolatos változtatási kérések eljárásainak leírása A szolgáltatások rendelkezésre állása (elérhetősége): A szolgáltatási időszakban tervezett rendelkezésre állás %-ban 158

166 Infrastruktúra menedzsment Szolgáltatási szint menedzsment Az elviselhető szolgáltatási hibák maximális száma A hibánkénti minimális állásidő A hibák következtében újrafuttatandó kötegelt feladatok maximális száma, az összes feladat %- aként bemutatva Mérési periódus (napi, heti, havi, elmúlt négy heti) A korlátozások és speciális körülmények részletezése Az elérhető terminálok minimális száma Támogatási szintek: A gyorssegély-szolgálat adatai, eljárásai, teljesítménykritériumai A támogatás elérhetőségének időszaka Az igénybe vehető támogatás rövid leírása Felhasználói útmutatók, ki kapja és teríti őket Teljesítmény: Célzott áteresztő képesség (throughput rate) Válaszidő célok Átfutási idő célok Mérési periódus (napi, heti, havi, elmúlt négy heti) Az elfogadott minimális funkcionalitás leírása Az esetleges szolgáltatási díjak leírása A változási kontroll eljárások Katasztrófa-elhárítási tervek Az előre látható növekedés Korlátozások: A tranzakciók maximális száma Az egyidejű felhasználók maximális száma A regisztrált felhasználók számának bármely maximuma Központi nyomtatási szolgáltatások: Elérhetőségi időszak Printerfajták, papírfajták Korlátozások Központi nyomtatás szétosztása Elérhetőségi időszak Az elosztási központ helye A postázási szolgáltatás leírása Felhasználói képzés: A képzési lehetőségek leírása A SzSzM változtatási módja: A SzSzM módosításainak változtatási kontroll eljárásai Ismételten hangsúlyozzuk: csak akkor értelmes egy kitételt az SzSzM részévé tenni, ha az abban foglaltak objektív módon ellenőrizhetők! Pusztán a tartalomjegyzék szépsége és teljessége kedvéért nem érdemes és nem szabad "minta SzSzM-et" aláírni. A megalapozó szerződések szemléje A Szolgáltatási Szint követelményekről való megállapodásokat szállítási és karbantartási szerződésekkel kell alátámasztani, az alábbiakban kifejtett módon. Ezeknek a szerződéseknek megfelelően szigorúaknak kell lenniük, hogy támogassák a felhasználó követelményeit. Az igények kielégítéséből fakadó potenciális költségnövekedést mind az informatikai, mind a felhasználói menedzsmentnek igazolnia kell. 159

167 Infrastruktúra menedzsment Szolgáltatási szint menedzsment Egy tizedmásodpercnyi válaszidő javulás miatti költségnövekménnyel szembeállíthatunk-e közvetlenül számszerűsíthető hasznot vagy a felhasználó javuló képességét a további bevételek generálására, teljesítményjavításra, újabb fogyasztók megnyerésére? Terv a szolgáltatások figyelésének javítására A figyelési (monitorozási) lehetőségeket szemlézni kell, és terveket kell készíteni a javításukra. Ajánlatos a következő szakaszokban felsorolt elemeket figyelemmel kísérni, mivel mind centralizált, mind elosztott rendszerben relevánsak. Rendelkezésre állás és megbízhatóság A rendelkezésre-állás annak az időnek az aránya, amely alatt a szolgáltatás ténylegesen elérhető a felhasználó számára az elfogadott szolgáltatási időn belül. (Az elfogadott szolgáltatási időszakot a SzSzM tartalmazza). Rendelkezésre állás (%) = rendelkezésre állási idő / elfogadott szolgáltatási időszak (Pl. ha egy szolgáltatás a 40 órás szolgáltatási periódusban 39 órán keresztül áll rendelkezésre, akkor a rendelkezésre állás ez esetben 97.5%). Egy szolgáltatás elérhető lehet néhány felhasználó számára, miközben másoknak nem áll rendelkezésre valamilyen összetevő hibája következtében. Tehát minden felhasználó egyénileg érzékeli a rendelkezésre állást. Szolgáltatási hibának azt nevezzük, amikor egy szolgáltatás egy része vagy egésze nem áll rendelkezésre, vagy valamely felhasználó számára elérhetetlennek érzékelhető, vagy ha a szolgáltatás az elfogadható funkcionalitás szintje alá kerül. Ennek oka lehet program hiba vagy sérülés az adatokban. A túl hosszú válaszidő, vagy a komoly használati problémák is elérhetetlenné teszik a szolgáltatást. Ennek kapcsán a következőket kell megfigyelni: Az elért teljes szolgáltatási rendelkezésre állás az elfogadott szolgáltatási időszakon belül. Az elért teljes szolgáltatási elérhetőség a teljes szolgáltatási időszakon belül (beleértve a szerződéses órákat és valamennyi kiterjesztést). A terminál rendelkezésre állás, ami figyelhető egyedi terminál szinten vagy az alábbiakban bemutatott formulaként, amely tág értelmezéssel egyetlen értékbe tömöríti az általános terminál elérhetőséget. Alkalmazható a VKE percek (vagy órák) (vizuális kijelző egység) koncepciója, ami azoknak a perceknek a számát jelöli, amikor a szolgáltatás nem elérhető, megszorozva az érintett VKE-ek számával. Pl. ha egyetlen VKE rossz, és egy órán belül kerül megjavításra, akkor az 60 VKE percet jelent, míg egy hálózati hiba, ami 200 távoli terminál használhatatlanságát eredményezi, bár két percen belül megtörténik a javítása, mégis 400 VKE percnyi elérhetetlenséget eredményez. A bruttó elérhetőséget kiszámíthatjuk az alábbi képlettel: (Teljes beütemezett VKE percek az elvesztett VKE percek száma) osztva a teljes beütemezett VKE percek számával A szolgáltatási hibák száma. A hibánkénti állásidő mértéke. A hibák miatt újrafuttatandó feladatok száma. Rendelkezésre-állási korlátozások, pl. a tranzakciók maximális száma, az egyidejű felhasználók száma stb. Nyomtatási szolgáltatások: papírfajta, elérési idő. Új felhasználók számára kötelező képzések. Teljesítmény A teljesítmény figyelése kiterjed a válaszidőkre, a kötegelt feladatok átfutási idejére, az átviteli arányra. 160

168 Infrastruktúra menedzsment Szolgáltatási szint menedzsment A figyelő eszközöket úgy kell kialakítani, hogy olyan jelentéseket készítsenek, melyek megfelelnek a fogyasztói/megegyezési struktúrának, hogy csökkentve ezáltal a kézi beavatkozás szükségességét. A válaszidő az az idő, amely egy interakciót elindító billentyűleütés és az eredmény első karakterének a képernyőn való megjelenése között eltelik. Természetesen vannak olyan kérdések, amelyeknél a válasz csak akkor hasznosítható, ha teljes válasz megérkezett! Az áteresztő képesség a rendszer által egységnyi idő alatt elvégzett munka összege, a megállapodás által meghatározott perióduson belül. Ez számos módon kifejezhető, pl. tranzakció szintű interakciók száma egy hét alatt, az óránként elért vagy módosított rekordok száma, stb. Funkcionalitás A javasolt osztályozási skála a legsúlyosabbtól (9) a legcsekélyebb szintig (0) terjed: 9 rossz eredményeket ad, de nem mindig tapasztalható, 8 az adatok többségét rongálja, visszaállításra nincs lehetőség, 7 az adatok többségét rongálja, de visszaállításra vagy újrabevitelre lehetőség van, egészen 0-ig csekély probléma, amely később kezelhető, és nincs szervezeti/működési hatása. Nyomtatás/papírkezelés Minden központilag nyomtatott outputról feljegyzést kell készíteni, akárcsak az elvégzett papírkezelési tevékenységről. Ez különösen ott fontos, ahol az elszámolási algoritmus tartalmazza ezt a tevékenységet. Elszámolás Valamennyi informatikai erőforrást figyelni és használatukat számlázni kell, hogy lehetővé váljon az elszámolás vagy az elvi számlázás. Ez értékes vezetői információkat nyújt, és még hatékonyabb erőforrás-használatot tesz lehetővé. Tervek minőségfejlesztési programra és a munkateher növekedésre A szolgáltatási szint menedzsment alapul szolgál a szolgáltatás minőségének minimális költségek melletti javítására terveket kell készíteni ilyen fejlesztési programokra is! A munkateher növekedésének fényében meg kell vizsgálni és előre jelezni a szolgáltatási szintek alakulását, a növekedést és a szükséges befektetéseket tervet kell készíteni a növekedésre. Elszámolási politika kialakítása Fontolóra kell venni a legalább tájékoztató jellegű számlázást, ha ez még nincs bevezetve. Ezáltal tudatosíthatóvá válnak a költségek, és az erőforrások is jobban menedzselhetők. A számlázási rendszer részleteinek szerepelniük kell a szolgáltatási szint megállapodásban. Politikát kell kialakítani a szükséges költségek, beruházási szükségletek kezelésére (pl. ki fizesse egy új felhasználó szolgáltatásainak kialakítását?). Ehhez kapcsolódik a kereslet menedzsment, amely kifejezést azokra a technikákra használják, amelyekkel a számítógépes erőforrások iránti lehetséges igényeket befolyásolják valamely meghatározott időben (pl. pangó időszakokban kevesebbet számlázni a szolgáltatásokért, csúcsidőszakban viszont növelni a díjakat, korlátozásokat bevezetni a túlterhelés megelőzésére). 161

169 Infrastruktúra menedzsment Szolgáltatási szint menedzsment Támogató eljárások/folyamatok Rendelkezésreállás menedzsment Üzemeltetés menedzsment Kapacitás menedzsment Hálózat felügyelet Katasztrófa - elhárítás tervezés Szolgáltatási szint menedzsment Gyorssegély szolgálat Probléma kezelés *Biztonsági menedzsment Változtatás menedzsment Konfigurációkezelés 36. ábra: A szolgáltatási szint menedzsment részei A Szolgáltatási Szint Menedzsernek ügyelnie kell arra, hogy ne fogadjon el túl ambiciózus SzSzM-t túl hamar. Számos megfelelően támogatott (teljesen üzemelő) folyamatnak (szolgáltatás-menedzsment funkciónak) kell alátámasztania a SzSzM-t. Mechanizmus szükséges a változások, a problémák, a kapacitás, az elérhetőség kezelésére (lásd az ábrát!), és ki kell alakítani a felhasználói támogatás módjait. Az egyéb függőségek közé tartozik a megfelelő figyelő és modellezési eszközök alkalmazása és a felső vezetés ill. a személyzet nagyfokú elkötelezettségének kialakítása. Az időzítés tekintetében elmondható, hogy az előkészítő tevékenységekre 2-6 hónap szükséges a szolgáltatási szint menedzser kinevezésétől számítva, a szervezet méretétől, a megállapodások számától és a rendelkezésre álló létszámtól függően. A teljes időszükséglet a szolgáltatások kiterjedtségétől és összetettségétől is függ Megvalósítás Az implementációs fázis során kulcsfontosságú, hogy hivatalosan nyilvánosságra hozzuk a megegyezés részleteit és a követendő eljárásokat mindazon személyzet számára, akik a korábban leírt funkciókért felelősek. Pl. a felhasználókkal tudatni kell, hogy az ő napi kapcsolati rendszerük az informatikai szolgáltatásokkal azok minősége tekintetében a gyorssegélyszolgálat. Természetesen a szolgáltatási kultúrának idő kell a rögződéshez a szervezeti kultúrában. Lehetséges, hogy a felhasználó továbbra is a rendszerelemzőhöz fordul a kérdéseivel. A fontos az, hogy a teljes informatikai személyzet rendelkezzen egy belső SzSzM-sel, ami kimondja, hogy a szolgáltatások minőségével kapcsolatban a gyorssegély-szolgálathoz kell fordulni. Hangsúlyozzuk, hogy ez azt jelenti, hogy nem csak a fogyasztó, hanem a szolgáltató személyzet körében is oktatásra van szükség! A Szolgáltatási Szint Menedzser teljes felelősséggel tartozik azért, hogy a SzSzM-ek megfelelően dokumentálásra és megvalósításra kerüljenek. A megállapodás menedzselése tekintetében ajánlott, hogy a SzSzM speciális szoftvercsomagot használjon a Szolgáltatási Szint Megegyezés teljes kontrolljára és adminisztrációjára. Mikor a legjobb egy Szolgáltatási Szint Megegyezést megvalósítani? Erre a kérdésre nincs egyetlen, üdvözítő válasz. A kellő elkötelezettség minimális feltétele a sikernek, legalább a szolgáltatási szint menedzsernek hinnie kell benne, hogy sikerülni fog! Az előkészítő feladatok, mint a például a gyorssegélyszolgálat bevezetése, valószínűleg akár 6 hónapnyi időt is igénybe vesznek a beszerzés, üzembe helyezés és a kinevezések miatt. Ez változhat attól függően, hogy milyen a tevékenység 162

170 Infrastruktúra menedzsment Szolgáltatási szint menedzsment mérete és természete, illetve, hogy a szerződések létrejöttek-e és megfelelőek-e. Feltehetőleg nem járunk messze az igazságtól, amikor az SzSzM, mint mechanizmus "zöldmezős" bevezetési idejére hónapot becslünk Problémák A következő problémák léphetnek fel a megállapodások elsietett megkötése miatt: A szolgáltatási szint menedzsment fegyelmezettségre kötelezi a felhasználót és az informatikai szolgáltatási személyzetet (ahelyett, hogy üzlet-vezérelte lenne) konzisztens szolgáltatási minőség és kölcsönös megértés szükséges e nehézség feloldására. A kulturális változás szétválasztja a két oldalt, kihangsúlyozva a mi és ők attitűdöt. A felhasználók úgy érzik, ez egy újabb informatikai eredetű erőltetett ötlet. A fogyasztók nem tudják meghatározni Szolgáltatási Szint követelményeiket, emiatt informatikai specialisták segítségére szorulnak akiknek ezt normális feladatkörük részének kell tekinteniük. A szolgáltatási szint menedzser számára nehéz lehet a követelmények költségvonzatainak meghatározása, ehhez támogató eszközök és háttér kell. A megfelelő automatikus tervező, monitorozó és jelentő rendszerek nem mindig állnak rendelkezésre valamennyi szolgáltatásra. A szolgáltatási szint menedzserek túl becsvágyó célokat fogadnak el a szolgáltatások javítására, mielőtt még a megalapozó folyamatok rendelkezésre állnának. Számos törekvés, kezdeményezés vakvágányra futhat a nem megfelelő tervezés következtében, a legtöbb probléma a helyes magatartás kialakításának hiányából fakad, mivel a résztvevők nem ismerik fel, hogy a szervezeti igények kielégítéséhez együttes munka szükséges! 11.3 A szolgáltatási szint menedzsmenthez kapcsolódó tevékenységek Szolgáltatási szint követés Ez a szolgáltatási szint menedzser elsődleges funkciója, és megkívánhatja eszközök alkalmazását. Fontos, hogy az információt objektív módon gyűjtsük. A szolgáltatási szint menedzsernek kell eljárnia esetenként vagy a fogyasztó, vagy az informatikai szolgáltatás nevében, és emiatt mindkét fél előtt fenn kell tartania hitelességét, és részrehajlástól mentesen kell tevékenykednie. Az információt rendszeres időszakonként, a figyelési statisztikákból, a gyorssegélyszolgálat jelentéseiből, az eltérésjelentésekből, stb. kell gyűjteni a szolgáltatási szint menedzser számára, hogy a szolgáltatás szintje értékelhető és dokumentálható legyen. Ha éppen egy tényleges, vagy fenyegető eltérés tapasztalható a Szolgáltatási Szint Megegyezéstől, akkor a szolgáltatási szint menedzsernek meg kell vizsgálnia a körülményeket. Az elvégzendő elemzés kiterjed a többi szolgáltatási támogató folyamatra is, abból a célból, hogy a minőségi probléma valós oka meghatározó legyen, és teljes képet lehessen kialakítani. Megfelelő ajánlásokat kell kialakítani, és beavatkozásokat kell végrehajtani a problémák újbóli előfordulását megakadályozandó. Bármely javaslatról, amely befolyásolhatja a Szolgáltatási Szintet vagy más szolgáltatások szintjét, tárgyalni kell a felhasználókkal, és a Szolgáltatási Szint Megegyezést hivatalosan módosítani kell. Napi jelentéseket és összesítéseket kell összeállítani és bemutatni az érintett feleknek rendszeres időszakonként. A felhasználókkal hetente kell ülést tartani, a megfelelő informatikai támogató személyzettel és azok vezetőivel naponta, és más informatikai vezetőkkel hetente. Ezt az ütemezést változtatni lehet, amikor problémák jelentkeznek, vagy ahol a személyzet elérhetősége miatt csökkenteni kell a gyakoriságot A szolgáltatási minőség szemléje Hosszabb távú (6 havi, 12 havi, éves) jelentések szükségesek trendelemzési célra, és információ generálására a Szolgáltatási Szint Megegyezés szemléjéhez és újratárgyalásához. Mindazokat az elemeket, amelyek megfigyelendők a SzSzM meghatározásai szerint, figyelni kell, és a jelentéseknek 163

171 Infrastruktúra menedzsment Szolgáltatási szint menedzsment nem csak az elért szintet kell jelezniük, hanem a SzSzM-ban rögzített célértékeket is. Minden SzSzMbeli elemre reflektálni kell a jelentésben, tipikusan: Rendelkezésre állás (elérhetőség) a mérési periódus során, %-ban kifejezve, az elérhetetlenség mértékével együtt (mint a szolgáltatási állásidő és a szolgáltatások leállásának száma stb.). Átlagos csúcsidőszaki válaszidő a mérési időszakban. A funkcionalitási hibák száma minden egyes szolgáltatásnál, a súlyosság szintje szerint felsorolva. Az az idő, amíg mindegyik rendszer az elfogadható minimum szintje alatt üzemelt funkcionális problémák, eltérések miatt. A csúcsidőszaki felhasználók átlagos száma. A csúcsidőszaki tranzakciós ráta a periódusban. Biztonság-megsértési (betörési) kísérletek. Gyorssegély-szolgálati statisztikák. A Szolgáltatási Szint Menedzsernek havonta üléseznie kell a felhasználói felső vezetéssel, hogy szemlézzék a szolgáltatás minőségét. Ezen ülések napirendjének része kell legyen: A szolgáltatási teljesítmények szemléje A szolgáltatáshoz kapcsolódó problémák szemléje Az észrevehető szolgáltatási trendek meghatározása Megegyezés a szolgáltatások kisebb változtatásaiban Változások kezdeményezése bármely eljárásban. Ha eltéréseket tapasztalnának a megállapodás szerinti szintektől, akkor a szolgáltatási szint menedzsernek és a felhasználói vezetésnek közösen kell elemeznie az eseményt, kielégítő magyarázatot kell találnia a történtekre, javító célzatú javaslatokkal együtt. Ez sokkal eredményesebb, mint büntetési kitételeket foglalni a megállapodásba Szolgáltatás-fejlesztési programok A SzSzM egyik fő célja a szolgáltatások minőségének javítása, illetve a meglévő szint fenntartása a növekvő igények közepette, minimalizálva a költségeket. Ehhez minőségfejlesztő programokra van szükség. Ennek érdekében meg kell vizsgálni a jelenlegi statisztikákat, és meg kell határozni azokat a tényezőket, amelyek a legtöbb gondot okozzák, és amelyeket leginkább javítani kell. Fokozatos, érzékelhető javulásra kell törekedni Szolgáltatási szint megállapodások szemléi A SzSzM-eket rendszeresen felül kell vizsgálni, legalább hathavonta, mindazokat a felhasználókat bevonva, akik részesei voltak az eredeti tárgyalásoknak. A szolgáltatási szint menedzsernek meg kell vizsgálnia a SzSzM-eket, mielőtt változtatásokat tervezne. Figyelembe kell venni a terhelés növekedését, hogy a jövőbeni célok elérhetőek legyenek a SzSzM teljes életciklusa során. Figyelembe kell venni, hogy bármely SzSzM-beli változás hatással lehet más megállapodásokra. A megállapodások változtatását tehetik szükségessé a következők: olyan valós változások, mint az új hardver, szoftver vagy terminálok működésbe állítása, az előbbi módosításokból adódó változások (több felhasználó ellátásának képessége, nagyobb tranzakciós ráták), szükségessé válhat a szolgáltatási időszak bővítése vagy korlátozása, ambiciózusabb célok válhatnak szükségessé, ha a korábbiakat rendszeresen túlhaladják, a tranzakciók szintjében vagy az üzleti forgalomban bekövetkezett növekedés miatt a szolgáltatási minőség már nem elfogadható. 164

172 Infrastruktúra menedzsment Szolgáltatási szint menedzsment A céloknak való megfelelés auditja Az eljárásoknak való megfelelést auditálni kell legalább évente, független auditor segítségével, és ha problémák jelentkeznének, akkor folyamatos alapon. A következő elemeket kell megvizsgálni: Szolgáltatási Szint Megegyezések, szolgáltatási teljesítmény feljegyzések, naplók, jelentések, szemléző ülések jegyzőkönyvei, feljegyzései, tevékenysége, jelentései, szabványok és eljárás-dokumentációk Számos elem kezelhető mérföldkőként, pl.: a SzSzM tárgyalások befejezése, a szolgáltatási teljesítmény szemlék, a SzSzM szemléi, jelentések készítése. Ellenőrizni kell a feljegyzéseket mindezekről az elemekről, biztosítandó, hogy pontosan és ütemezés szerint legyenek teljesítve. Egyes szervezetek a Szolgáltatási Szint Megegyezés független auditját igénylik. Ennek évente kell történnie, vagy szükség szerint, az implementáció korai szakaszaiban. Az auditor vizsgálni fogja a SzSzM szempontjait és főként a következőket: a monitorozás/megfigyelés megfelelő-e, a jelentések szabatosak és pontosak-e, a felhasználói szemlék konstruktívak voltak-e, az ülések során meghatározott problémákat megvizsgálták-e és történt-e beavatkozás, a probléma elhárítást dokumentálta-e a problémakezelés, a felhasználók elégedettek-e a megoldásokkal (elhárítással) Ajánlott irodalom Service Level Management. IT Infrastructure Library. HMSO, 6 th ed ISBN A témával kapcsolatos Web-oldalak: Példa SzSzM-ek: Eszközök

173 12. Szoftver támogató eszközök Az infrastruktúra menedzsment feladatainak ellátása manapság szinte lehetetlen valamilyen támogató eszköz használata nélkül, már csak a kezelendő elemek számossága miatt is. Az informatikai szervezetek a klasszikus fejlesszünk vagy vásároljunk dilemma előtt álltak és állnak, amire általánosságban senki sem tud persze választ adni, pusztán a az egyes megoldások előnyeit és hátrányait lehet felsorolni. Mindenesetre egy ilyen támogató eszköz beszerzésének indoklása nem egyszerű feladat, mert hatása elsődlegesen az informatikai szervezet munkájára van, míg a kiszolgált szervezet által ellátott hatósági és/vagy irányítási feladatra csak áttételesen hat. Egy eszköz kifejlesztése pedig felettébb kétséges vállalkozás, figyelembe véve annak költségvonzatait. Az informatika robbanásszerű fejlődésének köszönhetően a kilencvenes évekre megjelentek a piacon azok nagy integráltsági fokú, testre szabható szoftver eszközök, melyek több funkciót képesek egyidejűleg támogatni. Ezen eszközöket szokás a rendszer-felügyeleti szoftver megnevezéssel illetni, ilyenre példa manapság a Tivoli TME 10 és a Unicenter TNG. Ezeknek az eszközök alkalmasak heterogén, földrajzilag szétszórt informatikai infrastruktúra logikailag központi felügyeletére. Szép számban születtek az egyes funkciók részterületeire koncentráló alkalmazások is, amit jól illusztrálnak az egyes funkciókat ismertető fejezetek után az eszközök felsorolása, amely semmi esetre sem készült a teljesség igényével, pusztán kitekintésre ad alkalmat. Az alábbiakban példaként felsorolt eszközök is csak illusztráció célját szolgálják. A támogató eszközök eredeti, kiinduló funkciójuk szerint lehetnek a hálózatmenedzsment munkáját támogató, az aktív hálózati elemek esetében lényegében konfigurációkezelési feladatot ellátó eszközök a szoftver felügyeletet és terítést támogató eszközök (pl. Microsoft Systems Management Server) a gyorssegély-szolgálati és problémakezelési tevékenységeket támogató eszközök (pl SupportMagicSQL) a kapacitás tervezés tevékenységeket támogató eszközök (pl. BMC Patrol) A terület szépsége, hogy bármelyik funkció felől is közelítjük meg, lehetőség marad nagyobb integráltsági fokú rendszer kiépítésére, a szerves fejlesztésre. A következő alfejezetekben olyan követelményeket fogunk felsorolni, amelyeket egy informatikai szervezet figyelembe vehet akár egy eszköz beszerzésénél (a tender kiírásban), akár belső fejlesztéseiben. A követelmények felsorolása közel sem teljes körű, tekintse azokat az Olvasó példaértékűnek 12.1 Rendszer szintű követelmények A rendszer támogassa a konfigurációkezelés, gyorssegély-szolgálat, problémakezelés, változáskezelés és a szoftver felügyelet és terítés tevékenységeit. A probléma, változtatás és konfigurációkezelési rendszerek adatintegritásának fenntartása érdekében a rendszer legyen képes naplózni az adatbázisában végzett módosításokat. A rendszer legyen képes heterogén számítástechnikai környezet kezelésére, beleértve ebbe a személyi számítógépek lokális hálózatait, középkategóriás gépeket. A rendszer támogassa a kliens-szerver architektúrát A rendszer tegye lehetővé a decentralizált elemek központi menedzsmentjét. Egy adatot csak egyszer kelljen bevinni a rendszerbe. Legalább ötvenen tudják egy időben használni a rendszert. A rendszer legyen képes összesen legalább kb. 100, 000 konfigurációs elem tárolására. A rendszer adatbázisa legyen relációs és rendelkezzen SQL felülettel. A rendszer támogassa a konfigurációs elemek teljes életciklusának a követését (beszerzéstől a leírásig) 166

174 Infrastruktúra menedzsment Szoftver támogató eszközök A rendszer támogassa az informatikai rendszerekben végzett adatmentési és visszaállítási tevékenységeket. A rendszer legyen testre szabható (a képernyőket, menüpontokat, meződefiníciókat lehessen alakítani a felhasználó igényeinek megfelelően). A rendszer adattartalma legyen testre szabható (felhasználható által meghatározott mezők segítségével). A súgót legyen lehetséges kiterjeszteni a testre szabott, illetve újonnan előállított részeire a rendszernek. A rendszerben legyen lehetséges ad-hoc lekérdezések összeállítása. A rendszerbeli mezők tartalmát (beleértve ebbe a megjegyzés mezőket) lehessen kulcsszavak szerint lekérdezni. Lehessen felhasználó által meghatározott formátumú riportokat létrehozni a rendszer adatbázisából (legyen hozzá jelentés-generáló eszköz). A riportokban tetszőleges, a rendszer adatbázisában szereplő mezőt lehessen lekérdezni. A riportokat magukat is lehessen tárolni. A riportokat lehessen minta alapján (Query by Example) elkészíteni Biztonsági követelmények A rendszerben legyen felhasználó/jelszó szintű beléptetési eljárásrend. A rendszer tartalmazza a rendszer-felügyeleti tevékenységeket végző személyzet adatait, a munkák nyomon követhetősége érdekében. A rendszer tegye lehetővé a csoportokba sorolását a számukra biztonsági szempontok alapján engedélyezett funkcionalitás szerint (pl. rendszer adminisztrátor, korlátlan jogú felhasználó, korlátozott felhasználó, csak olvasásra jogosult felhasználó) A kritikus funkciók végrehajtatását lehessen naplózni (ki, mit, mikor indított el a rendszerben) A rendszer adatbázisában legyen rekord szintű a védelem. A rendszer igény szerint (a felhasználó beállítása szerint) naplózza a benne történt összefüggő változtatásokat (full audit trail capability) 12.3 Felhasználói felülettel kapcsolatos követelmények A rendszer felhasználói felülete legyen elérhető grafikus felhasználói felületről. A rendszer menüpontjai legyen egységesek és szabványosak a rendszer különböző alrendszereiben. Ahol az addig bevitt adatokból egyértelmű, a rendszer automatikusan töltse ki a származtatható részeket (pl. szállító neve alapján címe, telephelye stb.). Környezetfüggő súgó segítse a rendszer használatát. Lehessen az input adatokat automatikusan validálni Konfigurációkezelés Legyen képes tetszőleges számú hardver, szoftver kommunikációs elemtípus tárolására. A konfigurációs elemeknél lehessen teljes leírást és kapcsolatokat rögzíteni. Lehessen bárkód-olvasóhoz, mint adatbeviteli eszközhöz kapcsolni. Az eszköz akadályozza meg a konfigurációs elem (KE) státuszának módosítását, illetve új KE létrehozását, amennyiben az engedélyezés nélkül történne. Az eszköz a lehetőségekhez képes kényszerítse ki a változások befejezésekor azok regisztrálását a konfigurációkezelési adatbázisban (KKAB). Minden egyes KE státusz, amit egy változás érint, automatikusan módosuljon, amikor a változás megvalósítása befejeződött. 167

175 Infrastruktúra menedzsment Szoftver támogató eszközök Amikor szoftver átvisznek egyik helyről a másikra (pl. éles üzemből archiválják), akkor a KKAB tartalma automatikusan módosuljon. Hardver változások automatikusan vezetődjenek át a KKAB-ba. Csomag kibocsátás esetén a KKAB tartalma automatikusan módosuljon. A teljes rendszertől a csomagkibocsátásig változó bonyolultságú KE-ket legyen képes kezelni az eszköz. Tegye lehetővé a KE-k közötti hierarchikus és hálózatos kapcsolatok leírását. Legyen egyszerű az új KE felvitele, valamint a régi KE-k törlése. Az eszköz támogassa új KE felvitelénél a kapcsolatok automatikus kitöltését. Legyen lehetséges különböző modellszámú, verziószámú és másolatszámú KE felvitele és kezelése. Legyen lehetséges kapcsolódó KE-k automatikus azonosítása. KE komponens verziószám változásánál legyen lehetséges a KE verziószám automatikus változtatása. KE módosítási történetének legyen képes kezelni az eszköz. KE termékmérföldköveket kezelje az eszköz Gyorssegélyszolgálat A gyorssegély-szolgálati alrendszer álljon kapcsolatban a konfigurációkezelési alrendszerrel. A bejelentéseket lehessen konfigurációs elemekhez kötni. Támogassa a gyorssegély-szolgálat két- és háromszintű modelljét. A gyorssegély-szolgálati alrendszer álljon kapcsolatban a problémakezelő alrendszerrel. A bejelentéseket lehessen problémákhoz kötni. Tegye lehetővé, hogy az esemény jellemzői (szimptómái) alapján hasonló eseményeket és megoldásuk módját a felhasználó (gyorssegély-szolgálati operátor) megtekintse. Elektronikus bulletin (hirdetőtábla) lehetősége legyen meg. Lehessen eszkalációs modelleket felépíteni a rendszerben. Az eszkalációs modellek paraméterei között szerepeljen az esemény súlyossága, illetve a bejelentéstől eltelt idő. Ha egy adott típusú problémával x idő belül nem történik semmi, akkor azt az adott modell előírásai szerint automatikusan eszkalálni kell. A rendszer gondoskodjon a lezáratlan és lezárt bejelentések statisztikáiról. A rendszer legyen képes a rendelkezésre-állás alapadatainak a követésére (pl. MTTR, MTBF) 12.6 Problémakezelés A felvitt problémákat lehessen felhasználó által meghatározott súlyossági és sürgősségi osztályokba sorolni. Lehessen a felvitt problémákat osztályokba rendszerezni. A szerződések nyomon követése érdekében a rendszer legyen képes az egyes beszállítók tevékenységét nyomon kísérni. Az eszköz az eseményeket automatikusan illessze a problémákhoz és ismert hibákhoz. Problémafeljegyzéseket automatikusan generáljon. Más forrásból származó adatok bevitelének a lehetősége legyen meg. Adatok továbbításának a lehetősége további vizsgálat céljából, előre meghatározott helyekre. A vizsgálat menetének nyomon követése legyen lehetséges. Előre meghatározott határok elérése után tegye az eszköz lehetővé az események vagy problémák eszkalációját (a súlyossági kód figyelembevételével). 168

176 Infrastruktúra menedzsment Szoftver támogató eszközök Lehessen egyes funkciókat letiltani, pl. esemény lezárás. Problémákat és ismert hibákat számlálja. Elemző és jelentést segítő eszközök álljanak rendelkezésre. A rendszer (elektronikus úton) értesítse a problémával foglalkozó személyeket, amikor a problémát számukra kiszignálják. Arról is kapjanak értesítést, ha az eddig rájuk bízott problémát (automatikusan) eszkalálják. A rendszer tegye lehetővé a problémák besorolása alapján azok automatikus kiszignálását. Az automatikus eszkaláció legyen képes mind az elektronikus posta, mind a személyhívó használatára. A rendszer legyen képes a már diagnosztizált problémákból ún. tudásbázis felépítésére, karbantartására Változáskezelés Az eszköz a változtatás kérelmeket (VK) és probléma jelentéseket (PJ) egyszerű formában tárolja. Legyen lehetséges a VK-k, PJ-k és a KE-k közötti kapcsolat felderítése. Adott KE-n végrehajtandó változtatás által érintett egyéb KE-k automatikus azonosítása legyen lehetséges. Az eszköz adja meg a KE tulajdonosának automatikusan elküldött kérés lehetőségét, melyben felkérik, hogy becsülje meg a változás hatását és erőforrásigényét. Elemző és jelentést segítő eszközök álljanak rendelkezésre. Az arra feljogosított személyek számára legyen lehetőség VK bevitelére a termináljukról/személyi számítógépükről. A rendszer legyen képes világosan nyomon követni az engedélykiadás és a megvalósítás egyes lépcsőit. Tegye lehetővé a rendszer, hogy az érintett személyzet (változáskezeléssel foglalkozó személyzet, tesztelők, stb.) szöveges kiegészítéssel láthassák el a változási feljegyzéseket. A felvitt változtatási kérelmeket lehessen felhasználó által meghatározott súlyossági és sürgősségi osztályokba sorolni. Lehessen az engedélyezett változtatási kérelmek kivitelezése határidejét figyelni. Legyen lehetőség az eredeti állapot helyreállításának követésére. Automatikusan jelezze a rendszer, ha a VK-k közül bármelyik valamilyen oknál fogva túllépne egy előírt időtartamot. Jelezze a rendszer automatikusan, hogy szükséges az üzembe helyezett változtatások szemlézése. Hozzon létre a rendszer automatikusan vezetői jelentéseket és trend elemzéseket. Az eszköz tegye lehetővé a változtatások automatikus ütemezését Szoftver terítési és felügyeleti követelmények A rendszer legyen képes letölteni szoftver komponenseket szerver(ek)ről a kliensekre. A rendszer legyen képes ellenőrizni, hogy egy kliensen csak azok és csak azok a szoftverek találhatók, melyeket a rendszerben engedélyeztek. A rendszer legyen képes kliens munkaállomás beviteli eszközeinek az átvételére. Kövesse a rendelkezésre álló és a kiosztott licenceket. 169

177 Infrastruktúra menedzsment Szoftver támogató eszközök 12.9 Kapacitástervezési követelmények A rendszer kövesse az össze operációs és adatbáziskezelő szintű paraméter értéket, előre beállított mintavételi gyakorisággal. A rendszer figyelmeztessen arra, ha valamely paraméter (erőforrás rendelkezésre álló értéke) kritikus szint fölé vagy alá megy. A rendszer legyen képes grafikusan megjeleníteni a paraméterek értékeit. A rendszer legyen öntanuló. Építsen fel tudásbázist Költségmenedzsment követelmények A rendszer kapcsolódjon az alkalmazott számviteli/pénzügyi rendszerhez. Legyen képes az amortizáció számolására, aggregálásra. 170

178 13. Kifejezésszótár Állásidő (Downtime): az az időtartam, amely alatt egy informatikai szolgáltatás nem képes ellátni a kívánt funkciót az elfogadott szinten. Áteresztő képesség (Throughput): a rendszer által egységnyi idő alatt elvégzett munka összege, a megállapodás által meghatározott perióduson belül. Ez számos módon kifejezhető, pl. tranzakció szintű interakciók száma egy hét alatt, az óránként elért vagy módosított rekordok száma, stb. Átruházandó költségek, (TCU, Transfer Cost Units): minden olyan költség, amelyről megállapodás született a felhasználóval, hogy őt fogja közvetlenül terhelni. Azonosítás (Identification): az informatikai infrastruktúra minden összetevőjének specifikálása és azonosítása. Azonosítási szint (Identification Level): a teljes infrastruktúra konfigurációs elemekre való lebontásának legalsó szintje, amelyet a nyilvántartás (követés) bonyolultsága és a konfigurációkezelés tevékenységeihez szükséges információ mélysége határoz meg elsősorban. Beruházási költségek (Capital Costs): általában állóeszközök, pl. számítógépek, épületek, vagy akár szoftver eszközök beszerzésekor felmerül költségek. CRAMM (CCTA s Risk Analysis and Management Method): kockázat elemzési és menedzsment technika, amely Nagy-Britanniában ajánlott módszertan. Delta kiadás (Delta Release): olyan kiadás, amely csak azokat a KE-eket tartalmazza a kiadáson belül, amelyek ténylegesen megváltoztak vagy újak a legutóbb kiadáshoz képest, tehát nem cseréli ki valamennyi KE-et a kiadási egységen belül. Akkor kerül alkalmazásra, ha egy teljes egység kiadása nem indokolt. Egyéb költségek (Revenue Costs): ezek közé tartoznak a napi költségek, mint pl. személyzet, hardver karbantartás, elektromos áram, stb. Éles környezet (Live Environment): a számítógépes rendszerek azon részei, ahol a tényleges szolgáltatásokat nyújtó szoftverek üzemelnek. Éles összeállítási környezet (Live Build Environment): a kiadás sikeres tesztelése után a HSzK-ból ismételten kimásolt elemek forráskódjának lefordítása és összeszerkesztése történik itt, majd az összeállított szoftvert tárolásra kerül, terítésre készen. Elhelyezéssel kapcsolatos költségek (ACU, Accommodation Cost Units): mindazon költségek, melyek az informatikai szolgáltatások biztosításához szükséges elhelyezési és környezeti feltételek biztosításához kellenek, mint pl. elektromos áram, helységbérleti díj, stb. Ellenőrzés (Control): annak felügyelete, hogy a változtatásokat csak a megfelelő hatóságok jóváhagyásával valósíthassák meg az arra jogosult személyek. Elnevezés (Naming): egyedi KE-ek azonosítására szolgál. Az egyes KE előfordulásokat egyedileg meg kell tudni különböztetni a KE név és a másolatszám/sorozatszám segítségével. Elvi számlázás (Notional Charging): azt a számlázási módszert nevezik így, amelynél a felhasználók kimutatást kapnak az általuk használt informatikai szolgáltatások költségeiről, de tényleges ellentételezés nem történik. Esemény (Incident): olyan váratlan jelenség, amely károsan hat az informatikai szolgáltatásokra. Ez a hatás a súlyostól a felhasználó számára észrevehetetlen szintig terjedhet. Esemény feljegyzés (Incident Record, EF): egy nem várt, az informatikai szolgáltatás normális üzemelését akadályozó esemény (technikai zavar) részletes adatainak rögzítése. Eseményfelügyelet (Incident Control): az események azonosítása, regisztrálása, besorolása majd kezelése, amíg az érintett szolgáltatás vissza nem állítható a normál állapotba. Másodlagos feladata az eseményekkel kapcsolatos adatok gyűjtése, amelyek az okok tisztázásában segítenek. Eszkaláció (Escalation): ha egy esemény kapcsán nem sikerül kielégítő fejleményeket elérni (azaz nem tudják lezárni az eseményt), akkor azt pontosan meghatározott eljárások szerint tovább kell adni (felterjeszteni) a megfelelő szakértő csoporthoz. 171

179 Infrastruktúra menedzsment Kifejezésszótár Eszközre terhelt költség (ECU, Equipment Cost Unit): tartalmazza a berendezés részeinek, karbantartásuknak, működtetésüknek költségeit és egyéb költségeket. Felhasználói támogatás szintje (User Support Level): a felhasználóknak nyújtott gyorssegélyszolgálat, tanácsadás, stb. jellemzői, rendelkezésre állása. Felhasználó (User): mindazok, akik az informatikai szolgáltatásokat használják, beleértve az informatikai fejlesztői csoportot. A szolgáltatások közé tartozik az egyszerű alkalmazói programoktól a szervezeti szintű rendszerekig minden informatikai alkalmazás. Fontosabb esemény (Major Incident): olyan események, amelyeknél a felhasználói közösségre gyakorolt hatás foka rendkívül magas, vagy az esemény okozta szolgáltatás kiesésének időtartama jelentős. Gyorssegélyszolgálat (Help Desk): infrastruktúra menedzsment funkció, amely azonnali segítséget ad a felhasználóknak, ha a szolgáltatás nem az elvárt módon (rendellenesen) működik, vagy az ismeretek hiánya miatt a felhasználó nem képes feladatát elvégezni. A szolgálat ezen túlmenőn központi gyűjtőhelye (single point of contact) az informatikára épülő rendszerekben vélelmezett hibák és hiányosságok bejelentésének. Hálózat felügyelet (Network Control): az informatikai szolgáltatásokkal kapcsolatos hálózat üzemeltetéséért felelős csoport az informatikai egységen belül. Helyreállítási idő (Resolution Time): valamely informatikai szolgáltatás vagy információtechnológiai komponens hibája esetén a normál működés állapotába történő visszaállítás ideje. Katasztrófa-elhárítási terv (Contingency Plan): A katasztrófa elhárítási terv tartalmazza mindazokat az információkat, melyek szükségesek az informatikai szolgáltatások helyre állításához egy esetleges katasztrófa bekövetkezte után. A terv arra is világos útmutatást fog adni, hogy hogyan, és mikor kell használni. Hiba (Fault): olyan körülmény, amelynek hatására egy informatikai rendszer valamely funkcionális eleme nem képes a kívánt funkció ellátására. Hiba-felügyelet (Incident Control): a problémák megoldása, az a folyamat, amely során nyomon követik az ismert hibák azonosítását, feljegyzését, klasszifikációját, amíg a változáskezelés funkció (Change Management) egy változtatás sikeres megvalósításával megoldja őket. Hibák közti átlagidő (Mean Time Between Failures, MTBF): egy informatikai szolgáltatás vagy komponens helyreállításától a vele kapcsolatos következő hiba előfordulásáig átlagosan eltelt idő. Elvárt élettartamként is definiálható. Rendszeresemények közti átlagidő (Mean Time Between System Incidents, MTBSI): egy informatikai szolgáltatás két egymást követő hibájának előfordula közt átlagosan eltelt idő. Javítási átlagidő (Mean Time to Repair, MTTR): egy esemény megjelenésétől a helyreállításig eltelt átlagos idő. Hiteles és megbízható kiadási kópia (definitive authorised and trusted copy): szoftverek, amelyeket minőségi ellenőrzés után, szervezetileg jováhagyva a Hiteles Szoftver Könyvtárban tárolnak. Hiteles szoftver könyvtár (Definitive Software Library, HSzK): egy biztonságos szoftver könyvtár, ahol valamennyi szoftver konfigurációs elem (KE) minden verziója tárolásra kerül, hiteles (definitív), minőségileg ellenőrzött formában, bázisul szolgálva a szoftver-kiadások összeállítási, terítési és üzembe helyezési folyamatoknak. Igény menedzsment (Demand Management): a felhasználói elvárások kezelésére szolgáló tevékenység a kapacitáskezelés funkción belül. Informatikai (IT) infrastruktúra (IT Infrastructure): a szervezet, a számítógépek, a hálózat, a hardver elemek, a szoftver elemek, illetve a szoftverrel kapcsolatos telekommunikáció, melyeken az alkalmazói rendszerek és az egyes informatikai szolgáltatások ráépülnek és futnak. Informatikai szolgáltatás (IT Service): információtechnológián alapuló rendszerek által működtetett kapcsolódó funkciók rendszere, amely egy vagy több szervezeti tevékenységet támogat. Bár számos hardver, szoftver, telekommunikációs elem alkotja, a felhasználó számára koherens és önálló entitásként érzékelhető. Informatikai szolgáltatás lehet valamely egyszerű alkalmazás, pl. 172

180 Infrastruktúra menedzsment Kifejezésszótár egy főkönyvi rendszer elérése, de lehet egy komplex, számos alkalmazást tömörítő csomag, pl. irodaautomatizáció. Informatikai szolgáltatás-vezető (IT Service Manager): az informatikai szolgáltatási egység vezetője és a szolgáltatás minőségéért felel. Egyenrangú az alkalmazásfejlesztési vezetővel és pénzügyi és adminisztrációs vezetővel. Ismert hiba (Known Error): a problémák vizsgálatokat és a sikeres diagnosztizálást követően ismert hibákká alakíthatók, tehát azonosításra kerülnek azok a KE-ek, amelyek valamely probléma okozói, és amelyek cseréjével az adott típusú további zavarok megszüntethetők. Ismert hiba feljegyzés (Known Error Record, IHF): valamely probléma tényleges okának sikeres meghatározását rögzítő feljegyzés, amely jelzi a hibát okozó KE-et. Jogosultsági feljegyzés (Authorisation Record, JF): a változtatás megvalósíthatóságát és a megvalósításra felhatalmazott adatait dokumentáló feljegyzés a KKAB-ban. Kapacitás menedzser (Capacity Manager): a kapacitás menedzsmenttel foglalkozó részleg vezetője. Kapacitás menedzsment (Capacity Management): infrastruktúra menedzsment funkció, amelynek legfontosabb célkitűzése az informatikai szolgáltatás igényelt szintjének elérése és fenntartása megengedhető és elfogadható költségek mellett. Kapacitás Menedzsment Adatbázis (Capacity Management Database, KMA): az alapja a sikeres kapacitás menedzsment funkciónak, azokat az adatokat tartalmazza, melyek befolyásolják a terhelést. Kapacitás terv (Capacity Plan): A terhelés előrejelzési folyamat végterméke. Karbantarthatóság (Maintainability): egy informatikai komponens vagy szolgáltatás azon képessége, hogy meg lehet tartani egy olyan állapotban, vagy vissza lehet állítani egy olyan állapotba, amelyben képes ellátni a megkívánt funkciót. Katasztrófa elhárítás tervezés (Contingency Planning): lehetővé teszi, hogy egy esetleges katasztrófa bekövetkezte után az informatikai szolgáltatásokat ellenőrzött módon, egy előre megállapított szinten helyreállítják, oly módon, hogy előre meghatározzák a helyreállítás során érvényes személyi felelősségeket, illetve a követendő tevékenységeket. Kereslet menedzsment (Demand Management): mindazok a technikák, amelyekkel a számítógépes erőforrások iránti lehetséges igényeket befolyásolják valamely meghatározott időben, (pl. pangó időszakokban kevesebbet számlázni a szolgáltatásokért, csúcsidőszakban viszont növelni a díjakat, korlátozásokat bevezetni a túlterhelés megelőzésére). Kiadás sorszámozás (Release Numbering): a kiadáshoz a tesztelést megelőzően az összeállítás során hozzárendelt sorszám, amely a kiadás azonosítására szolgál. Kiadási csomag (Package Release): az egyedi kiadások csoportosítása egy kiadási csomaggá, ami együttes tesztelést és terítést tesz lehetővé. Kiadási egység (Release Unit): az a szint vagy összetettség, amelynél egy adott szoftver típus kiadásra kerül, ez lehet akár teljes rendszer, programcsomag, program vagy csupán modul (e szoftver lebontási szintek közül az, amely legjobban illeszkedik a szervezet igényeihez egy változtatás tényleges megvalósításakor). Kiadási politika (Release Policy): ez határozza meg a SzFT és a változtatáskezelés működését a kiadási egységekkel, a delta kiadásokkal, a csomag-kiadásokkal, a kiadások gyakoriságával és változástartalmával ill. a sürgős kiadások kérdésével kapcsolatos irányelvek megfogalmazásával. Kibocsátás vagy kiadás (Release): egy tervezett módosításhoz, változtatáshoz tartozó új és megváltoztatott konfigurációs elemek, melyeket együtt tesztelnek és egyszerre visznek be az élő üzemeltetési környezetbe. Kibocsátási feljegyzés (Release Record, KF): valamely kibocsátást alkotó KE-ek leírása, a megvalósítás adataival (a kibocsátás által érintett KE-ek, a hatás jellegének leírása) együtt. Konfiguráció kezelés (Configuration Management): infrastruktúra menedzsment funkció, amelynek feladata valamennyi informatikai infrastruktúra összetevő és a kapcsolódó dokumentációk 173

181 Infrastruktúra menedzsment Kifejezésszótár folyamatos konfigurációkezelési kontroll alá vonása, ezáltal a változtatások, események és problémák kezelésének lehetővé tétele. Konfigurációkezelési Adatbázis (Configuration Management Database, KKAB): a konfigurációkezelést támogató számítógépes eszköz, általában egy relációs adatbázis, amely a rugalmas és kiterjedt vizsgálatokat tesz lehetővé. Részletes adatokat tartalmaz a KE-ek tulajdonságairól és történetükről, illetve a közöttük levő fontosabb kapcsolatokról. Konfigurációmenedzser (Configuration Manager): felelős a konfigurációkezelési funkció működéséért. Konfigurációs elem (Configuration Item, KE): az informatikai infrastruktúra összetevői, azaz a hardver és szoftver összetevők, a hálózati elemek, a dokumentáció és az informatikai infrastruktúrával kapcsolatos valamennyi más elem (pl. változtatási kérelmek), amelyek a konfigurációkezelés ellenőrzése alatt állnak. A KE-ek mérete, típusa, komplexitása rendkívül változatos, egy teljes informatikai rendszertől egy egyszerű szoftver modulig vagy hardver alkatrészig terjedhet. Költségcentrum (Utility Cost Centre): olyan szervezeti egység, melynek ismernie kell az összes gazdasági költségét, demonstrálnia kell, hogy eredményesen és hatékonyan működik, de a költségeit a szervezet fedezi. Költségmenedzsment (Cost and Charging Management): infrastruktúra menedzsment funkció, amely lehetővé teszi az informatikai szolgáltatásokat biztosító részleg számára, hogy kezelni tudja költségeit, illetve a felhasználók és szolgáltatók közötti piaci jellegű kialakítását szolgálja azáltal, hogy a szolgáltatásokért megfelelő díjat számít fel. Közvetlen költség (Direct Cost): olyan költség, amit hozzá lehet rendelni egy konkrét szolgáltatáshoz vagy folyamathoz. Küszöbérték (Threshold): valamely problémából vagy ismert hibából eredő események előfordulási számának előre meghatározott korlátja, vagy egy megoldatlan esemény, probléma ill. ismert hiba kapcsán definiált időkorlát, amely után eszkalációt kell végrehajtani. Másolatszám vagy sorozatszám (Copy Number): az azonos specifikációjú KE-ek, szoftver másolatok meg különböztetésére szolgál. (Egy KE meghatározott másolatát azonosítja.) Megbízhatóság (reliability): egy informatikai összetevő azon képessége, hogy ellásson egy megkívánt funkciót meghatározott körülmények között, egy meghatározott időtartamra. Modell számozás (Model Numbering): a nagyobb változásokat jelezik új modellszámokkal. Osztályozás (Classification): események, problémák és ismert hibák formális azonosításának folyamata eredetük, tüneteik és okaik alapján. Önelszámoló számítóközpont (Computer Services Business Centre): olyan autonóm szervezeti egység, melynek pénzügyi és szervezeti céljait a szervezet jelöli ki. Tipikus célkitűzés lehet a profit maximalizálása, a költségvetés bizonyos százalékának elérése, vagy nullszaldó elérése; Összeállítási környezet (Build Environment): a kiadás sikeres tesztelése előtt vagy az éles kiadás előtt a HSzK-ból ismételten kimásolt elemek forráskódjának lefordítása és összeszerkesztése történik itt. Probléma (Problem): vagy egy egyedi, jelentős hatású esemény, amelynek hatása nagymértékben rontja a felhasználók számára nyújtott szolgáltatás minőségét; vagy megegyező tüneteket mutató események sorozata, amelyek valamilyen közös, de ismeretlen eredetű okra vezethetők vissza. Probléma feljegyzés (Problem Record, PF): egy jelentős esemény alapján, vagy több kisebb súlyú, hasonló tüneteket mutató esemény sorozatos bekövetkezése alapján azonosított körülmények leírása, amelyek valamely ismeretlen eredetű hibára utalnak. Probléma kategorizációs kód (Problem Categorization Code): a problémák/ismert hibák okait azonosító strukturált kód, fő célja, hogy lehetővé tegye a problémáknak és okaiknak elemzését. 174

182 Infrastruktúra menedzsment Kifejezésszótár Probléma menedzser (Problem Manager): a számítógép-üzemeltetésnek, a hálózat-felügyeletnek és a gyorssegély-szolgálatnak segédkező, az optimális szolgáltatási szint biztosításában meghatározó szerepet játszó személy, aki probléma és a hibafelügyeletért felelős. Probléma-felügyelet (Problem Control): feladata az események kiinduló okának megkeresése, hogy ezáltal lehetővé váljon az események újbóli előfordulásának megelőzése. A problémák azonosításának, feljegyzésének, osztályozásának, vizsgálatának és megoldásának folyamata egészen a sikeres diagnózisig, azaz az ismert hibává alakításig. Problémakezelés (Problem Management): a szervezeti informatikai szolgáltatásokkal kapcsolatos zavarokkal eseményekkel, problémákkal és ismert hibákkal foglalkozó infrastruktúramenedzsment funkció, amely szisztematikus és fegyelmezett megközelítést ad az informatikai szolgáltatásokat érintő problémák kezelésére, azonosítására, diagnosztizálására és felügyeletére. Rendelkezésre-állási arány (Availability Ratio): annak az időnek az aránya, amely alatt a szolgáltatás ténylegesen elérhető a felhasználó számára az elfogadott szolgáltatási időn belül. (Az elfogadott szolgáltatási időszakot a SzSzM tartalmazza). (Pl. ha egy szolgáltatás a 40 órás szolgáltatási periódusban 39 órán keresztül áll rendelkezésre, akkor a rendelkezésre állás ez esetben 97.5%). Rendelkezésre állás (%) = rendelkezésre állási idő / elfogadott szolgáltatási időszak. Rendelkezésre-állás menedzsment (Availability Management): infrastruktúra menedzsment funkció, melynek feladata, hogy a rendszerek általános rendelkezésre-állását javítsa a felhasználók szolgáltatási igényeinek kielégítése érdekében. A szolgáltatásokat úgy tervezi meg és tartja fenn az indokolható költségeken belül, hogy minimálisra csökkentse bármely hiba hatását a szervezeti tevékenységre. Rendelkezésre-állás Menedzsment Adatbázis (Availability Management Database, RMAB): a rendelkezésre-állás menedzsment funkció központi adattára. Rendszer monitorozó eszközök (System Monitors): az egész rendszerről gyűjtenek információt, illetve valamilyen csoportosító szempont alapján Rezsi költség (indirect cost overhead): mindazok a költségek, amelyeket fel kell osztani a szolgáltatások között, pl. a vezetők bére, stb. Státusz követés (Status Accounting): a KE-ekkel kapcsolatos történeti és jelenlegi adatok feljegyzése, karbantartása. Súlyossági kód (Severity Code): megmutatja az egyes problémák hatásának mértékét az informatikai szolgáltatások minőségére. Az erőforrás-allokáció fontos tényezője. Sürgős kiadás (Urgent Release): sürgős javításokhoz, a komoly vagy magas prioritású problémák megoldásához szükség lehet a normál menetrendet be nem tartásával megvalósított változtatásokra. Számozás (Numbering): két vagy három szintű számozási rendszer jellemző, amelynek felső szintje a nagyobb változások, az alsó szint pedig a kisebb változások jelölésére szolgál, és a KE elnevezése mellett az azonosítás fő eleme. Szervezeti alaptevékenységet segítő gyorssegélyszolgálat (Business Support Help Desk): nem a technikai zavarok kezelésével, hanem a szolgáltatások használatával összefüggő felhasználói kérdésekkel foglalkozik. Szervezetre terhelt költségek (OCU, organisation cost unit): mindazon költségek melyek az informatikai szolgáltató részleggel kapcsolatosak, mint pl. a személyzet bére, kiképzési költségek, stb. Szoftver felügyelet és terítés (Software Control and Distribution, SzFT): infrastruktúra menedzsment funkció, amely a konfigurációkezelés keretében vagy annak alárendelten felelős a szoftver elemek fizikai tárolásáért, terítéséért és üzembe helyezéséért. Szoftverre terhelt költség (SCU, Software Cost Unit): tartalmazza a szoftver elemek költségeit, akár vásárolták vagy akár fejlesztették őket, valamint a karbantartási és más költségeiket. Szolgáltatási hiba (Service Failure): amikor egy szolgáltatás egy része vagy egésze nem áll rendelkezésre, vagy valamely felhasználó számára elérhetetlennek érzékelhető, vagy ha a 175

183 Infrastruktúra menedzsment Kifejezésszótár szolgáltatás az elfogadható funkcionalitás szintje alá kerül. Ennek oka lehet program hiba vagy sérülés az adatokban. A túl hosszú válaszidő, vagy a komoly használati problémák is elérhetetlenné teszik a szolgáltatást. Szolgáltatási időszak (Service Hours): azok az időszakok, melyekben egy meghatározott informatikai rendszer vagy szolgáltatás elérhető a felhasználó számára. Ezt az SzSzM rögzíti. Szolgáltatási katalógus (Service Catalogue): a szervezet számára nyújtott informatikai szolgáltatások kérdéses csoportjáról valamennyi szolgáltatási jellemzőt dokumentálja. Szolgáltatási szint követelmény (Service Level Requirements): a felhasználók által kinyilvánított szolgáltatási szint iránti igény. Szolgáltatási képesség (Serviceability): szerződéses kikötés, amely meghatározza az informatikai komponens rendelkezésre-állását az adott összetevőket szolgáltató és karbantartó külső szervezettel való megegyezés szerint. Szolgáltatási szint megállapodás (Service Level Agreement): írott megállapodás (szerződés) a felhasználói közösség és az informatikai szolgáltató egység között, amely dokumentálja az elfogadott szolgáltatási szintet valamely informatikai szolgáltatás kapcsán. Tipikusan kiterjed a szolgáltatási időszakra, a szolgáltatás rendelkezésre állására, a felhasználói támogatás szintjére, a terminál válaszidőkre, a különféle korlátozásokra, a funkcionalitásra, a katasztrófaszituáció esetén nyújtandó szolgáltatási szintre. Tartalmazhatja a biztonsági és az esetleges számlázási elveket is. Szolgáltatási szint menedzsment (Service Level Management): az a folyamat, amelynek során a felhasználók és az informatikai szolgáltató egység között létrejött írásos megállapodás vagy szerződés segítségével menedzselik az informatikai szolgáltatások minőségét. Ez a szerződés meghatározza az egyes felekre háruló felelősséget, és kötelezi az informatikai szolgáltatót, hogy előre meghatározott szintű minőségben és mennyiségben szolgáltasson, mindaddig, amíg a felhasználó fenntartja igényét az elfogadott korlátok között. Teljes kiadás (Full Release): olyan kiadás, amely lecseréli valamennyi KE-et a kiadási egységen belül, függetlenül attól, hogy azok ténylegesen megváltoztak-e vagy sem a legutóbb kiadáshoz képest. Teljesítmény menedzsment (Performance Management): a kapacitás-menedzsment részeként legfontosabb célkitűzése a kapacitás-problémák előzetes felismerése a rendszer folyamatos figyelemmel kisérése (monitorozása) által, miközben az előzetesen egyeztetett teljesítmény szintet rendelkezésre állását biztosítják. Terhelés menedzsment (Workload Management): az a tevékenység a kapacitás-menedzsmenten eblül, amely a terhelés kialakulását, lefolyását, az azt befolyásoló tényezőket kiséri figyelemmel, hogy megismerje és értse a befolyásoló tényezőket, és segíthesse a várható terhelés előrejelzését. Termékbázisok (Baselines): egy adott KE-nek és az alkotóinak adott időpontbeli állapotát, jellemzőit, összetételét rögzíti további tevékenységek számára. Teszt-környezet (Test Environment): itt történnek az éles kiadás terítése előtti tesztelések az éles környezethez hasonló körülmények között. Teszt-összeállítási környezet (Test Building Environment): HSzK-ból származó tesztelésre váró kiadások összeállítására (forráskódjának lefordítása és összeszerkesztése) használatos. Transzfer költség (Transfer Cost): olyan költség, amely esetében egyezség született arról, hogy ezeket a felhasználó fogja viselni Üzemeltetési híd (Operations Bridge): egyetlen üzemeltetési funkcióba integrált (együtt elhelyezett) számítógépes üzemeltetés, gyorssegély-szolgálat és hálózat-felügyelet. Válaszidő (Response Time): az az idő, amely egy interakciót elindító billentyűleütés és az eredmény első karakterének a képernyőn való megjelenése között eltelik. Természetesen vannak olyan kérdések, amelyeknél a válasz csak akkor hasznosítható, ha teljes válasz megérkezett Változáskérelmi életciklus (Change Request Life Cycle): a változtatási kérelem értékelésének és megvalósításának folyamata, amelyet a változtatáskezelés funkció felügyel. 176

184 Infrastruktúra menedzsment Kifejezésszótár Változáskezelés (Change Management): infrastruktúra menedzsment funkció, amely az információtechnológiai infrastruktúrát érintő változtatások kezdeményezésének, értékelésének, jóváhagyásának, megvalósításának és szemlézésének a felügyeletére és menedzselésére ad mechanizmust. Változásmenedzser (Change Manager): személyes felelősséggel bír a változtatásokkal kapcsolatos kérdések intézéséért, elsősorban koordinatív jelleggel. Változásügyi Tanácsadó Testület (Change Advisory Board, VTT): az informatikai szolgáltató szervezeti egység, az informatikai alkalmazás-fejlesztést végző szervezeti egységek és a rangidős felhasználók képviselőiből álló testület, amely felbecsüli minden egyes változtatás kérelem (VK) hatásait és erőforrásigényeit, szervezeti és technikai hatásait, meghatározza prioritásukat, valamint javaslatot tesz a megvalósítás időpontjára és a szükséges erőforrások biztosítására. Változtatási kérelem (Request for Change, VK): az informatikai infrastruktúra valamely részeit érintő, a változtatásmenedzsernek benyújtott változtatási igény, amelyet naplózni kell a konfigurációkezelési rendszer eszközeivel, egyedi azonosítóval ellátva. Variáns (Variant): máskülönben ugyanolyanként kezelhető KE-ek kissé különböző verziói. Egy ilyen kissé eltérő verziónak különböző verziószáma lesz. Verifikáció (Verification): olyan szemle (audit), amely összehasonlítja a tényleges KE-eket a konfigurációkezelési adatbázisban feljegyzett hivatalosan elfogadott állapottal. Verzió számozás (Version Numbering): a KE kisebb változtatása esetén az eredeti név megtartása mellett módosítják a verziószámot. A variánsok például a hasonló KE-mel azonos nevet viselnek, de attól különböző verziószámot kapnak. VTT Döntőbizottság (Change Advisory Board Executive Committee, VTTB): a sürgős értékeléseket elvégző testület, amelynek a változásmenedzser, a problémamenedzser, a szolgáltatási szint menedzser és egy rangidős felhasználói menedzser a tagja. 177

185 178