Infrastruktúra menedzsment

Miniszterelnöki Hivatal Informatikai Helyettes Államtitkár Titkársága Informatikai Tárcaközi Bizottság ajánlásai

Infrastruktúra menedzsment 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

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.

2

Á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 egy-egy 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 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.

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: 3

• • •

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ég-haté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 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:

4

•

•

•

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.

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.

5

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.

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.

6

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.

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.

7

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últból 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. 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.

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.

8

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! 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

9

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.

Tervezés 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. 2. 3. 4. 5. 6. 7. 8.

Megvalósíthatósági tanulmány Kezdeményezés Specifikációs szakasz Termékkiválasztás és átfogó tervezés Fejlesztés és egyezıség ellenırzése (validálás) Implementáció Megvalósítás utáni szemle É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.

10

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 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

11

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. Függıségek Megalapozó folyamatok Sok elem szükséges az IT infrastruktúra menedzsment sikerese tervezéséhez. Az egyes infrastruktúra-menedzsment 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.

12

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.

13

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 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 mindmind 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.

14

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. 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

3 és 6 hónap között (kifinomult, alapos szolgáltatás)

Változáskezelés

1 és 3 hónap között, beleértve a támogató eszközök beszerzését

Konfigurációkezelés

4 és 12 hónap között, az ötlettıl a megvalósításig

Problémakezelés

2 és 4 hónap között

Szoftverfelügyelet és terítés

Hetek, feltéve hogy a konfigurációkezelés funkció már mőködik

15

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.

16

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.

17

•

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. 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.

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 projekt-menedzsment 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?

18

• • • •

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. 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úra-komponensek 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.

19

3. á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 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.

20

•

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 KEek, 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ó.

21

4. á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 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 KEbı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

22

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

23

címkét. Gondot kell 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 KE-ek 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.

24

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.

•

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.

25

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 KEre é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ı, 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.

26

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.

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. Felügyelet

27

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íjmegújítási dátumokról és költségekrıl; stb.).

28

• •

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 KKABban. 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á, 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 KEmel 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:

29

•

•

•

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. 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.

30

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 KK-nek 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. 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?

31

• • • • • • •

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.

Ajánlott irodalom Configuration Management. IT Infrastructure Library, CCTA. HMSO 1990. ISBN 0 11 330530 3 A témával foglalkozó Web-oldalak: http://www.opengroup.org/public/tech/sysman/xcti.htm http://www.laiso.redstone.army.mil/laiso/mmss/cmis/cmis.htm http://www.airtime.co.uk/users/wysywig/cmp.htm http://www.cs.colorado.edu/users/andre/configuration_management.html http://www.usb-muc.com/whitepap.htm http://www.bcs.org.uk/siggroup/sg57.htm Eszközök http://www.intersolv.com/index.html http://www.sei.cmu.edu/publications/documents/90.reports/90.tr.011.html http://www.arlut.utexas.edu/~spiwww/ConfMgt/CMPolicy.html Néhány példa: http://cliffie.nosc.mil/~NAPDOC/docprj/cm-plan/act2.html http://cliffie.nosc.mil/~NAPDOC/docprj/cm-plan/toc.html http://cliffie.nosc.mil/~NAPDOC/docprj/cm-concept/index.html

32

http://ptsun00.cern.ch/~ruggier/AtlasSE/URD/URD.1.0/html/URD-95.html http://esdftp.belvoir.army.mil/cmcdmis.htm http://www.inel.gov/gis/eris/appf.html http://apu.edu/~bmccarty/curricula/cs525/scmp.html http://www.abelia.com/swcmcrse.htm http://www.ee.ryerson.ca:8080/~mkuchta/formis/frameref/layers/manage/revision.htm

33

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ás-megosztá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.

34

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ó. 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ély-szolgá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.

35

5. ábra. A gyorssegély-szolgálat áttekintése.

36

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), 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.

37

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.

38

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.

39

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. 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élyszolgá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 40

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. 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:

41

• • • •

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élyszolgálat számára, és vannak-e kapcsolódó terveik. A személyzet kiképzési naplójának ellenırzését.

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é.

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.

42

•

Információk új alkalmazásokról és szolgáltatásokról, kibocsátásáról, változásokról a hardverelemekben.

új

szoftver

verziók

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ély-szolgá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élyszolgá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?

43

• • •

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 hálózati/felhasználói területen? Elemezzük a tevékenységeket és a hálózati naplókat.

a

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élyszolgá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ó.

44

8. ábra. Egyszerő, központosított gyorssegély-szolgálat Többfunkciós, központosított gyorssegély-szolgálat

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.

45

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élyszolgálati egységek. Ez 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.

10. ábra. Elosztott gyorssegély-szolgálat Jellemzıi: • • • •

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

46

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? 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,

47

• •

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 e-mail, az intranet is szóba jöhet, mint lehetséges megoldás. Fontoljuk meg a 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.

48

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ófaterv). 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, e-mail). Definiálni kell a lehetséges eseményekhez tartozó

49

súlyossági szinteket, és az ezeknek megfelelı válaszidıket. Eszkalációs eljárást kell tervezni, ehhez az eszkalációs küszöböket (kritériumokat) világosan meg kell határozni. • • • •

Kódolási rendszer (a hibákra vonatkozó strukturált kód, 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.

50

• • •

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 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

51

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élyszolgá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, 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

52

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élyszolgá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.

53

• •

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!

Ajánlott irodalom Help Desk. IT Infrastructure Library. HMSO, 1995. ISBN 0 11 330522 2 Computer Support Directory: Voice, Fax, and Online Access Numbers; Adler, Bill, Jr./ Fraser, Kristy. McGraw-Hill; 1995. ISBN: 007000482X Effective User Support : How to Manage the IT Help Desk; Bruton, Noel. McGraw Hill Text; 1996 ISBN: 0077079531 Microsoft Sourcebook for the Help Desk : Techniques and Tools for Support Organization Design and Management; Microsoft Corporation, Staff. Microsoft Press; 1995. ISBN: 1556159277 Running an Effective Help Desk : Planning, Implementing, Marketing, Automating, Improving, Outsourcing; Czegel, Barbara. QED Publishing; 1995. ISBN: 0471025445 Virtual Help Desk: Strategic Management Center; Thomas, Andrew H. International Thomson Computer Press; 1995. ISBN: 185032204X A témával foglalkozó Web-oldalak: http://www.HelpDeskInst.com/ http://www.hdibooks.com/toc.htm http://www.helpdesk.com/useful.html http://www.bruton.win-uk.net/ http://www.rgu.ac.uk/~sim/research/helpdesk/keyfact.htm http://www.hug.co.uk/ http://www.duke.edu/~pverghis/hdeskfaq.htm http://www.bayon.com/cstar/ecomp/support.htm Példák: http://www.leeds.ac.uk/ucs/UserSupport/HelpDesk/helpdesc

54

http://www.ucc.uconn.edu/~helpdesk/index.html http://www.hiteclabs.co.uk/sla.htm http://www.hiteclabs.co.uk/sla2.htm Szoftverek és szolgáltatások: http://www.helpdesk.com/ http://www.helpdesksys.com/ http://www.helpstar.com/home.htm

55

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.

56

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 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.

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

57

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.

11. ábra: Az eseménykezelési folyamat áttekintése Támogatás és osztályozás Amint riasztás megtörtént, • •

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 58

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 valamennyi tevékenységnél, és megköveteli a megfelelı eredmények pontos rögzítését. A 12. ábra egy tipikus folyamatot mutat be. Hiba feloldás és helyreállítás Mint korábban hangsúlyoztuk, az események többsége a klasszifikációs (osztályozási) fázis után közvetlenül a hibaelhárításhoz kerül helyreállítás céljából. A maradékot diagnosztizálni kell, ennek sikere esetén a hibát megoldják, vagy áthidaló megoldással teszik lehetıvé a normál vagy az elfogadható informatikai szolgáltatások helyreállítását. A problémakezelési rendszernek lehetıvé kell tennie valamennyi esemény és tevékenység feljegyzését a hiba feloldási és helyreállítási fázisban. Az esemény zárása A problémakezelési folyamat e szakaszát felügyelni kell, hogy csak a feljogosított személyek köre vehessen részt benne. Az esemény feljegyzésének és osztályozási kód besorolásának (amennyiben annak már meg kellett történnie) végsı szemléjét követıen az eseményt zárni kell. Valamennyi eseményhez tartoznia kell egy osztályozási kódnak, amely jelzi az esemény kiinduló okát. Esemény-figyelés és követés Legyen szó akár egyszerő, akár összetett eseményrıl, a felügyeleti rendszernek lehetıvé kell tenni az események figyelését és követését életciklusuk minden fázisa során. A folyamatnak részese lehet akár egy, akár több csoport; a hibák lehetnek a felhasználó által észlelhetetlenek vagy a teljes felhasználói közösségre hatást gyakorlóak. Az esemény életciklusa néhány perctıl a néhány órán át akár (ritkán) napokig is terjedhet. Számos elintézetlen esemény létezhet egyidejüleg. A probléma-felügyeleti rendszernek lehetıvé kell tennie az események figyelését és követését azok életciklusa során. A gyorssegélyszolgálat munkatársai látják el ezt a feladatot a kulcsadatok felhasználásával (pl. a hatás kód, a felhasználó (bejelentı) azonosítója, a konfigurációs elem kódja).

59

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ély-szolgálat. Kívánatos, hogy rendelkezésre álljon olyan elektronikus eszköz,

60

amellyel ez a felügyeleti szekció segítséget kérhet a megfelelı személyzettıl az informatikai szervezeti egység más részlegeibıl. A problémakezelést kell a felügyeleti szekción kívüli elsı választható segélykérési ponttá tenni, kivételként kezelve a szállítót, amely közvetlenül szerzıdhetett a berendezési hibákkal kapcsolatos kérések megoldására. A problémakezelési személyzet vizsgálja meg a hozzá továbbított eseményeket, a legfıbb célnak tekintve azt, hogy a normális szolgáltatást visszaállítsa olyan gyorsan, amint csak lehetséges. A specialista szakértelemért idıben kell folyamodni, megfelelıen az elıre definiált eszkalációs eljárásnak. A bonyolultnak tőnı eseményeknél az idı kritikus tényezı. Biztosítani kell a változáskezelési eljárásoknak való megfelelést, amikor a megfelelı megoldás vagy az áthidaló eljárás végrehajtásra kerül. Az esemény lezárása a normális szolgáltatás helyreállításával történik meg. A jelentısebb események felügyelete Jelentısebb események azok, amelyeknél a felhasználói közösségre való kihatás különösen nagy, vagy ahol a zavar idıtartama, még ha csak a felhasználók egy viszonylag kis arányára is, hosszúvá válik. Ezeknek az eseményeknek magas prioritást kell kapniuk. Eljárások szükségesek a vezetés folyamatos informálásához. A probléma-menedzser felelıs formális ülések összehívásáért, melyeken meg kell jelennie az informatikai szolgáltatások vezetésének és a PK funkció, a speciális támogató személyzet, a gyorssegély-szolgálat valamint a szállítói támogatás kulcsembereinek. Az ülésen szemlézni kell az elırehaladást, és meg kell határozni a legjobb cselekvési irányt. A probléma-menedzser közvetlen és átfogó felelısséggel tartozik a jelentıs eseményekért, és az ilyen üléseken vezetı szerepet játszik.

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

61

problémakezeléssel foglalkozó személyzetet az eseményekkel való elárasztástól. A következı (13.) ábra bemutatja a probléma azonosítás folyamatát. A probléma súlyosságának elemzése Egy új probléma azonosítását követıen azonnal meg kell becsülni súlyosságát. Súlyossági kódrendszert kell kialakítani, amely megfelel a szervezet igényeinek. A súlyossági kódolás lehetıvé teszi az erıfeszítések hatékony allokációját, és ez a kódolási rendszer biztosítja a szabványos megközelítést. Az erıforrások elosztása A súlyossági kódolás valamint az eredményes, hatékony és kontrolláltan megvalósított személyzet-elosztás szükségképpen egy eredményesebb és költséghatékonyabb struktúrához vezet. Minél magasabb a súlyossági besorolás, annál nagyobb hangsúlyt helyeznek a személyzet kijelölésére, míg egy kisebb súlyossági kód esetében várakozni lehet, amíg megfelelı személyzet áll rendelkezésre. Ezzel megelızhetı az erıforrások rossz elosztása valamint elkerülhetı a túlzott lelkesedés és a ráfordítások többszörözése. Az azonos jellegő események is befolyásolhatják az allokációt, amint például nagy számban kapcsolódó, kis súlyossági kódú események is megkívánhatják az azonnali beavatkozást. Ez a helyzet kézben tartható oly módon, hogy az események eszkalációjához küszöbértéket használnak: egy elıre meghatározott számú azonos jellegő esemény elıfordulásakor eszkalálni kell. Probléma vizsgálat és diagnózis A probléma vizsgálatának folyamata hasonlít az eseményeknél bemutatotthoz és hasonló rendszer eszközöket kíván az elırehaladás, az eredmények és a támogató szerepek rögzítéséhez. A vizsgálat célja a diagnózis, ami gyakran eljárásbeli és nem eszközökbıl (KE) eredı hibákat fed fel. Sajnos az ilyen típusú hiba nem jut el automatikusan az ismert hiba státuszba és emiatt nem mindig követik nyomon. Egy ál-feljegyzés valamely szabálytalan eljárásra lehetıvé teszi az ismert hibává való konverziót, ami azután nyomon követhetı a hiba-felügyeleti rendszeren. A probléma-felügyeleti tevékenység Bizonyos jelentıs problémák közvetlenül azonosíthatók a hozzájuk kapcsolódó elsı esemény vizsgálata során. Ebben az esetben a probléma-feljegyzés rögtön elıállítható, de nem szabad megfeledkezni a megfelelı esemény feljegyzés módosításáról sem, az új probléma-feljegyzés megfelelı adatának felhasználásával. Az események feljegyzései alapján azonosíthatóak az újabb problémák. Szemlét kell tartani minden lezárt eseménynél, amely nincs összefüggésben ismert problémával vagy hibával. Ha ez a szemle nem képes kapcsolódó problémát találni, új probléma-feljegyzést kell elıállítani. Minden problémát súlyossági kóddal kell megjelölni, és a részletes vizsgálat elıtt meg kell bízni a vele foglalkozó személyzetet a PK-en belülrıl. A kijelölt személy viseli a felelısséget a problémáért és minden kommunikáció fókuszpontja ill. a probléma megoldására irányuló tevékenység koordinátora lesz.

62

13. ábra Az esemény besorolási/összevetési folyamat 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 63

területek személyzetének és a szállítóknak. Fontos, hogy a megfelelı eljárásokat pontosan kövessük.

Hiba-felügyelet A hiba-felügyeletrıl általában A hiba-felügyelet az a folyamat, amely során nyomon követik az ismert hibákat, amíg a változáskezelés funkció egy változtatás sikeres megvalósításával megoldja ıket. Ebbe tartozik a konfigurációs elem változtatása az ismert hiba megszüntetése és ezáltal a probléma megoldása érdekében. A hiba-felügyelet hidat képez a fejlesztési és az éles környezet között. Ezt a folyamatot jobban összefoglalhatjuk a változtatási kérelem életciklus leírásával (lásd a vonatkozó fejezetet is) •

• •

• • • •

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ásmegvaló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 hiba-felügyelet eljárásai alapvetıen megegyeznek mind az éles, mind a fejlesztési környezetben, és a szükséges támogató eszközök is ugyanazok. A 14. ábra mutatja, hogy az éles és a fejlesztési környezet hiba-felügyelete ciklikus kapcsolatban van. Az együttes munka és a két környezet problémakezelési rendszerének integrációja lehetıvé teszi a szituáció ideális módon való kezelését. Az éles üzemeltetés során lelt hibák eredményeként VK-ek győlnek össze. A kiadási stratégia számításba veszi a kiadás végsı kialakítását, hogy tartalmazhassa az elfogadott változásokat a rendszer lehetıségeinek módosításához és/vagy kiterjesztéséhez. A fejlesztı személyzet tudatában van valamennyi ismert hibának és problémának, amely a kiadási csomaggal kapcsolatos. İk törölhetnek ismert hiba feljegyzéseket amennyiben kijavították ıket, de

64

ú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.

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 65

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émamenedzser rendszeres jelentéseket kap a változáskezeléstıl a hiba megoldásának elırehaladásáról. Figyelni kell, hogy a hiba megoldásának elırehaladása megfelel-e a Szolgáltatási Szint Megállapodásokban (SzSzM) rögzített követelményeknek. Ez jellemzıen meghatározza, hogy súlyossági szintenként bizonyos számú megoldatlan hibánál nem lehet több egyetlen mérési intervallumban sem (pl. az elmúlt 4 hétben). Ha egy súlyossági szinten a hibák száma elér egy elıre meghatározott küszöböt, ami valószínőleg a SzSzM megszegéséhez vezet, el kell indítani a felterjesztési (eszkalációs) folyamatot. A probléma megoldását jelentı változtatások sikeres megvalósítása után a problémakezelés formálisan zárja az ismert hiba feljegyzést. Minden ismert hibához tartozó hibaelhárítási feljegyzést karban kell tartani a problémakezelési rendszerben. Ez az adat azután elérhetı események és a problémák összevetése céljából, iránymutatást ad jövıbeni vizsgálatokhoz események megoldása vagy áthidalása során, és felhasználható vezetıi információk szolgáltatásához. Külsı felelısség Megfontolandó szabvány hiba feljegyzések kialakítása specifikus eszközönként (KE) vagy eszköz-kategóriánként, a rutin jellegő hardver hibák azonosítása érdekében. Ezek használandók a hibaarány gyors mutatójának követésére, bár több információt, mint pl. a hibák közötti átlagidı (MTBF) és az állásidı, az esemény adatokból származtatnak. A szállító által karbantartott termékekkel kapcsolatos hibákat a problémakezelési funkció vagy valamelyik specialista csoport azonosíthatja, és továbbítja a megfelelı szállító illetékes funkciójához, mint megoldásra váró problémát. Nyilvánvaló, hogy az informatikai szervezeti egységtıl nem várható el ugyanolyan szintő közvetlen felügyelet egy szállító által karbantartott szoftver hibájának megoldása felett, mint saját eszközök esetében. Nagyon formális eljárások alkalmazhatók. A szállító által adott segítséget figyelni kell, biztosítandó, hogy a válasz elfogadható idın belül maradjon. Ahol a szoftver karbantartási célokat - pl. a javításig eltelı átlag és maximum idı - és a kapcsolódó informatikai infrastruktúra megbízhatósági és szolgáltató képességi szinteket szerzıdésben vagy licenc feltételekben határozták meg, ennek megszegése esetén kezdeményezni kell a vállalatnál a probléma orvoslását. A karbantartási célok specifikálásának lehetıségére már a szoftver beszerzésekor gondolni kell, fıleg ha versenyeznek az üzletért. Megjegyzendı, hogy a külsı eredető szoftverek hibáinak megoldásához szükséges változtatások éppúgy a változáskezelési eljárások alanyai, mint a belsı termékek. Sok hardver hiba kiigazítását az esemény-felügyelet végzi, és nem a hiba-felügyelet ill. a változáskezelés. A hardver-javítást végzıknek ilyen esetben értesíteni kell a problémakezelést és a változáskezelést. Azonban minden változás a hardver specifikációban a normál változáskezelési eljárás alá tartozik.

66

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émamenedzser 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 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émamenedzsernek 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.

67

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.

68

Szállítói kapcsolatok Az eredményes problémakezelési rendszer megléte kölcsönösen elınyös az informatikai divízió és a szállítói számára egyaránt. Szövetkezni kell a szállítók és a legalsó szintek személyzetével, és meg kell próbálni túljutni a rendszerrel kapcsolatos nehézségeken. Ha formális kapcsolat létezik a az informatikai divízió és a szállító problémakezelési rendszere között, akkor rendszeres közös auditokkal lehet figyelemmel kísérni a pontosságot. Kérni kell a szállítót, hogy elıre figyelmeztessen minden szándékolt változtatásra a rendszerében. A személyzet elkötelezettsége és az eljárások használata Fennáll a veszélye annak, hogy a "családiasság felületességet szül", amint a problémakezelési rendszer használata rutinná válik. Az eljárások megfelelı betartását rendszeres ellenırzésekkel kell biztosítani. Verziókiadási stratégia és változtatáskezelés fejlesztése Figyelemmel kell kísérni a fejlesztési környezethez kapcsoló interfészek eredményességét és pontosságát, fıként az ismert hibák adatainak átadásával kapcsolatban. Meg kell bizonyosodni arról, hogy a problémakezelési és a változáskezelési rendszerek kompatibilisek és kölcsönösen segítik egymást. Rendszeres audit Rendszeres auditot kell elıkészíteni valamennyi problémakezelési tevékenységre és eljárásra vonatkozóan. Ezen auditok célja annak megerısítése, hogy a problémakezelés és a támogató csoportok betartják az elfogadott eljárásokat. Célja ezenkívül: • • • • • • •

•

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.

69

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.

A problémakezelés megvalósítása

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:

70

•

•

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 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.

71

16. ábra. Problémakezelés és támogatás Döntés a problémakezelés szervezeti struktúrájáról

72

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élyszolgá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 73

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. 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

74

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. 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.

75

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ély-szolgá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.

76

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élyszolgá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. 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 testreszabás magában foglalja a kódfejlesztést és a rendszerparamé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

77

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ózatfelü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ény-kó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 rendszer interfészekre. Nem szabad megfeledkezni a rendszer adminisztrációs és helyreállítási funkciókról. Teljesítmény tesztre van szükség a feldolgozási arány és válaszidı célok eléréséhez. Amennyire csak lehetséges, próbáljuk ki és ellenırizzük probléma/hiba adatokat felhasználó jelentéseket és ellenırizzük ezek integritását is.

a a a a

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

78

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 tesztspecifiká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

79

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. 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.

Ajánlott irodalom Problem Management. IT Infrastructure Library. HMSO 1990. ISBN 0 11 330527 3 A témával foglalkozó Web-oldalak: http://www.stonehouse.net/pmm01.htm http://gnats.cern.ch/ http://www2.hp.com/pso/frames/services/datasheet/ds-problem.html

80

http://www.loria.fr/~molli/cm/cm-FAQ/problem_top.html Eszközök: http://www.proactive-sv.com.au/PM1.htm http://www.loria.fr/~molli/cm/cm-FAQ/cm-problem-9.html http://www.loria.fr/~molli/cm/cm-FAQ/cm-problem-6.html

81

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.

82

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.

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, 83

•

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. 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:

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ú

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.

2

Közepes prioritású Nincs komoly kihatása, de javítása nem várhat a következı

0

84

változat vagy módosítás kibocsátásáig. Közepes prioritást kap a VTT elıterjesztésekben. Alacsony prioritású

3

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

2

3

Kis 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.

Közepes hatású

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.

Alapvetı hatású

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.

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.

85

18. ábra. A változtatások kezelése

86

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 üzembehelyezett/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 mondottuk, 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

87

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 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.

88

19. ábra. A halasztást nem tőrı változtatások kezelése

89

A változáskezelési funkció bevezetése

A funkció megtervezése 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.

90

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 VKt be kell mutatni az informatikai vezetın keresztül az informatikai 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ık-e 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 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

91

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.

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.

92

• • • •

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!

Ajánlott irodalom Change Management. IT Infrastructure Library. HMSO 1991 2nd ed. ISBN 0 11 330525 7 A témával foglalkozó Web-oldalak: http://www.helpdesksys.com/products.htm#Products http://www.continuus.com/Semintr4/sld003.html Szoftverek: http://www.truesoft.com/html/truechange_slide_presentation.html http://www.psgroup.com/snapshot/1997/ss109708.htm http://www.pdl-sdl.co.uk/changema.htm http://www.sequeluk.com/alchemist/manage.html http://homepage.tinet.ie/~brendancunniffe/y2k1.htm

93

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:

94

•

• • •

• • •

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. 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.

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 deltakiadá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.

95

A szoftver felügyelet és terítés fı folyamatai Az 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. 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. 96

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,

97

• • • • • • •

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. 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.

98

•

• • • • •

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 üzembeállítás során. Amikor a kibocsátott szoftver kielégítıen mőködik, törölni kell a teszt-kö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 KEet. 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.

99

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 teszt-kö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.

100

21. á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 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.

101

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 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.

102

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. 103

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, 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.

104

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 HSZKban 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. A HSZK mérete egyezik a helyigénnyel, és minden kapcsolódó karbantartási tevékenység végrehajtanak.

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

105

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. politika tervezése tervezése

106

Á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.

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. 107

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 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ó

108

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. 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.

109

•

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 HSzKban 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 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 HSzK-ban 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

110

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.

111

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. 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 HSzKon 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

112

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 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.

113

•

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 á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.

114

•

• •

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.

Ajánlott irodalom Software Control and Distribution. IT Infrastructure Library. HMSO 1990. ISBN 0 11 330537 0 A témával foglalkozó Web-oldalak: http://www.tivoli.com/redbooks/html/sg244948/4948fm.htm#ToC

115

http://ptsun00.cern.ch/~ruggier/AtlasSE/URD/URD.1.0/html/URD-95.html http://esdftp.belvoir.army.mil/cmcdmis.htm http://www.inel.gov/gis/eris/appf.html http://apu.edu/~bmccarty/curricula/cs525/scmp.html http://www.abelia.com/swcmcrse.htm http://www.ee.ryerson.ca:8080/~mkuchta/formis/frameref/layers/manage/revision.htm http://www.hsrd.ornl.gov/~lfz/rpchklst/cmproprv.htm

116

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:

117

• • •

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.

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 é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.

118

23. ábra: A nyújtott informatikai szolgáltatások és a megalapozó szerzıdések

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:

119

• •

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.

Olyan eljárásoknak kell rendelkezésre állniuk, amelyek mindkét felelısségi körnek eleget tesznek.

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.

120

•

•

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. 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épeseke 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:

121

• •

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 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.

122

25. ábra: A rendelkezésre-állás tervezése Biztonsági szempontok tervezése

123

A kockázat elemzés és menedzsment céljára Nagy-Britanniában a CRAMM módszert ajánlják (CCTAs 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,

124

• • •

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:

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.

125

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égkimaradá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ó.

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

126

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? 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:

127

• • • • • •

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.

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.

128

• • • • •

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. 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.

129

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. 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

130

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. 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

131

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. 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.

Ajánlott irodalom Availability Management. IT Infrastructure Library. HMSO 1992.

132

ISBN 0-11-330551-6 Locks, M. O.: Reliability, maintability and availability assessment. 2nd ed. ASQC 1995, ISBN 0-87389-293-3 A témával foglalkozó Web-oldalak: http://www.cs.uwyo.edu/~mishra/research/availability.html http://www.telecoms-mag.com/marketing/articles/oct96/tysdale.html Eszközök http://sis.cdc.com/integration/enterprise/availability.html http://www.storage.ibm.com/storage/software/sms/avlmgmt.htm http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/crm/crm_ug/ug_ch5.htm http://www.candle.com/mod03/mod03-PA-fst.html http://www2.candle.com:82/products/availability http://www.tivoli.com/redbooks/html/sg244948/4948fm.htm#ToC

133

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!

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,

134

•

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, 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.

135

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.

136

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.

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.

137

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).

138

Teljesítmény menedzsment

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

139

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.

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 kapcsolattartásra koncentrál. Feltétlenül közös munka legyen!

karbantartóival

folytatott

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!

140

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, 141

• •

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 é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ásfejleszté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.

142

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, 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: 143

• • •

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éke? 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? A kapacitás terv megfelel-e a vezetés elvárásainak? A szabványokat és eljárásokat betartják-e?

144

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. 145

•

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! 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

146

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.

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?"

147

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.

Ajánlott irodalom Capacity Management. IT Infrastructure Library. HMSO 2nd ed. 1994. ISBN 0 11 330544 3 Cady, J. - Howarth, B.: Computer System Performance Management and Capacity Planning. Prentice Hall (Sd), 1990, ISBN: 0131684930 Cervone, H. F.: Solaris Performance Administration: Performance Measurement, Fine Tuning, and Capacity Planning for Releases 2.5.1 and 2.6. McGraw Hill (Tx) 1998. ISBN: 0070117683 A témával foglalkozó Web-oldalak: http://alpha.fdu.edu/~alkis/cp/cp.html Szoftverek: http://www.bgs.com/best1.htm http://www.sysload.com http://www.midrangecomputing.com/announcements/!0214prs/moment1.htm http://www.bgs.com/unix.htm http://www.as.ibm.com/asus/performance.html

148

http://www.pc.ibm.com/us/server/capmgr/demo1/cm2.html http://www.landmark.com/PROFSVCS/PS2a2.html http://www.unisys.nl/pp/115/index.htm http://ww1.systems.digital.com/DDic.nsf/AllDocuments/92E378B766EA68FB8025641E006 F4191 http://wint.decsy.ru/du/DEC_UNIX/SYSMAN/POLYC_C7/PPA/PCAPA_TN.HTM http://www.decus.org/libcatalog/description_html/v00314.html http://www.tivoli.com/redbooks/html/sg244948/4948fm.htm#ToC

149

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.

150

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. 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 Költséghelyek Költséghelyek

151

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. 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:

152

•

•

•

Ö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 nullszaldó 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, 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.

153

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. 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.

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 154

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.

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ég-indoklása.

155

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égelszá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égelszá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

156

fognak a felhasználók 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ó mind a felhasználó, mind az informatikai szolgáltató számára. Érthetı 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. Mérhetı mind a felhasználó (legalább elvileg), mind az informatikai szolgáltatás számára.

157

Becsülhetı 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.

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

158

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).

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

159

•

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égelszá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 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.

160

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ásmá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?

161

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.

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?"

Ajánlott irodalom Cost Management for IT Services. IT Infrastructure Library. HMSO, 5th ed 1995. ISBN 0 11 330547 8

162

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,

163

• • •

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. 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ófahelyzet 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:

164

• • • • • •

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 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. 2. 3. 4. 5. 6. 7.

A katasztrófa-elhárítási terv készítésének elhatározása A szervezeti tevékenység megértése Elızetes terv készítése a menedzsmentnek A meglévı belsı rendszerek és szolgáltatások részletes felmérése A külsı szolgáltatások, eszközök számbavétele A szolgáltatások kiesésének hatáselemzése (Business Impact Analysis) A terv hiányából fakadó jogi következmények felmérése

165

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 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

166

•

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).

Kockázatelemzés és menedzsment

31. ábra. Az implementációs szakasz

167

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.

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,

168

• •

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. 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

169

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ı. 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.

170

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:

171

• • • • • •

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. 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:

172

• •

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. 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ı telefonalkö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

173

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 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!

174

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 24-48 órát igényel. (Természetesen a különféle változatok más-más idıigénnyel bírnak.)

175

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

176

• •

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ásfejleszté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. 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

177

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. Tevékenység-sorozat katasztrófa esetén: 1. Az esemény bekövetkezte 2. Az esemény felismerése

178

3. 4. 5. 6. 7. 8. 9.

Beavatkozás az esemény megállítására A katasztrófa-elhárítási csapat riasztása A károk enyhítése A helyreállítási folyamat megindítása Az alaptevékenység visszaállítása Tényleges helyreállítás 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.

179

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.) 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

180

• •

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, 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.

181

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ófaszituá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. 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

182

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,

183

• •

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 Ajánlott irodalom Bates, R. J. Jr.: Disaster Recovery Planning. Networks, Telecommunications, and Data Communications. McGraw-Hill, 1992, ISBN 0--7-004128-8 Contingency Planning. IT Infrastructure Library. HMSO 1990. ISBN 0 11 330524 9 CCTA Risk Analysis and Management Methodology Contingency Planning and Disaster Recovery: Protecting Your Organization's Resources. ISBN: 1-56607-986-1 A témával foglalkozó Web-oldalak: http://www.drj.com/groups/mcpf.htm 192.101.126.8/security/bas-user/sld102.htm http://www.disasterplan.com http://www.contingencyplanexpo.com/register_step1.cf raw.rutgers.edu/raw/iia/edprods/a6055_bk.htm bilbo.isu.edu/security/FMANGR/sld041.htm

184

http://www.it-research.net/de/reports/catalog/ccontige.htm http://www.dir.state.tx.us/oops/ctgyplan/index.html#contents http://www.drj.com/index.shtml http://www.disaster-resource.com/articles/96takemu.htm http://www.drj.com/new2dr/newbies.htm http://www.valstar.co.uk/services/serve5.html http://www.corelan.com/contingency.html http://www.mdis.com/a_profserv/profserv_consult/main_ps_contingency.html http://www.p-and-e.com/disaster.htm http://www.cprefg.com/index2.htm http://bps.digital.co.uk/planning.htm http://www.cti.com/Whiteprs/disaster.htm http://www.cti.com/Whiteprs/disaster.htm http://www.rothstein.com/wwwboard/messages/244.html http://www.y2ktimebomb.com/Computech/Management/sdvs9804.htm http://www.erols.com/steve451/impact.htm http://www.y2ktimebomb.com/PP/RC/rc9806.htm http://www.ownworld.demon.co.uk/conting.htm http://idf.mitretek.org:8080/mdy2k/general/y2krisk/index.htm http://idf.mitretek.org:8080/mdy2k/general/reports.asp

185

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

186

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, 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.

187

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.

188

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 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

189

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: • • •

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.

190

• • •

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. Az eredmények bemutatása

191

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

192

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 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.

193

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:

194

• • •

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 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.

35. ábra. SzSzM kikötések központi kezelése

195

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 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

196

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. 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?

197

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.

198

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.

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

199

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). Támogató eljárások/folyamatok

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.

200

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élyszolgá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 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 12-16 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. 201

• •

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!

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és-jelenté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 nem csak az elért szintet kell jelezniük, hanem a SzSzM-ban rögzített célértékeket is. Minden SzSzM-beli 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.

202

• • • • • •

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,

203

•

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ó.

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, 6th ed. 1995. ISBN 0 11 330521 4 A témával kapcsolatos Web-oldalak: http://www.summitonline.com/service/serv-title.html http://www.ngc.com/product_info/slm/updates/web_demo/current/slm.htm http://www.summitonline.com/service/ser-list.html

204

http://www.aptia.com/whitepapers.html http://www.netplexgroup.com/services/manage/SLMwhite.htm http://www.npsinc.com/projects/networksla.htm http://www.dantel.com/news/slawhi3/slawhi3.html Példa SzSzM-ek: http://www-tradoc.army.mil/dcsim/daps1.htm http://www.manap.org/sla.html http://www.ocs.mq.edu.au/OSWP/7c.html http://itexpress.ucdavis.edu/service/sla.html http://www.his.ucsf.edu/~gjv/stddsktp.html http://lrc.pcc.edu/final/Sample.html http://www.ocs.mq.edu.au/OSWP/7b.html Eszközök http://www.summitonline.com/products/service/ http://www.corecom.com/external/vnreport/vnrpt5.html http://www.corecom.com/external/vnreport/vnrpt9.html http://www-fr.cisco.com/warp/public/769/nslms4.html http://www.3com.com/products/dsheets/400365a.html http://www.hp.com/pso/frames/services/datasheet/ds-slmgmt.html http://espweb.teubner.com/frames/espover/sla.htm

205

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

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.

206

•

• • • • • • • • • • • • • • •

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) 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)

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

207

• • •

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. 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.

208

•

• •

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)

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 nyomonkövetése érdekében a rendszer legyen képes az egyes beszállítók tevékenységét nyomonkí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). 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 szené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.

209

• • •

• • • • • • •

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.

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.

210

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): specifikálása és azonosítása.

az

informatikai

infrastruktúra

minden

összetevıjének

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 (CCTAs 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.

211

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, ES): 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. 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ély-szolgá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.

212

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ó. Rendszer-esemé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. egy fıkönyvi rendszer elérése, de lehet egy komplex, számos alkalmazást tömörítı csomag, pl. irodaautomatizáció.

213

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

214

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 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.

215

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. Probléma menedzser (Problem Manager): a számítógép-üzemeltetésnek, a hálózatfelü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úra-menedzsment 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.

216

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.

217

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 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ásmenedzsmenten eblül, amely a terhelés kialakulását, lefolyását, az azt befolyásoló tényezıket

218

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. 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.

219

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.

220