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)
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:
É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:
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.
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:
A megfelelõ mennyiségû adattal feltöltött és karbantartott KKAB nélkülözhetetlen vizsgálati, elemzési szolgáltatásokat nyújt (pl. egy kiadási csomag KE komponenseinek és verziójuknak a listázása, változások által érintett KE-ek meghatározása, adott KE-hez kapcsolódó valamennyi változtatási kérelem listázása, egy adott szállítótól adott periódusban vásárolt KE-ek, stb.).
A lehetséges komponensek sokfélesége miatt gondosan kell megtervezni a KK funkciót, és figyelmet kell fordítani a KKAB céljára ajánlott szoftverre, annak lehetõségeire és korlátjaira.
A KKAB-nak tartalmaznia kell a KE-ek közötti valamennyi kapcsolatot. Mechanizmussal kell szolgálni a változtatási kérelmek (VK), az esemény feljegyzések (EF), a probléma feljegyzések (PF) és az ismert hiba feljegyzések (IHF) összekapcsolására a hivatkozott konfigurációs elemmel.
A konfigurációs elemek azonosítási szintjének tervezése
Alaposan meg kell fontolni, hogy milyen szintig azonosítjuk a konfigurációs elemeket. Ha a teljes informatikai infrastruktúrát tekintjük a legmagasabb szintû KE-nek, és azt bontjuk tovább kisebb összetevõkre, majd azokat még további, kisebb komponensekre, akkor nyilvánvalóvá válik, hogy dönteni kell, mi lesz a legalacsonyabb azonosított szint. Még akkor is el kell dönteni ezt, ha nem fogjuk azonnal a legalsó szinthez tartozó adatokkal feltölteni a KKAB-t, mivel így költséges reorganizációktól kímélhetjük meg magunkat. Kielégítõ megoldást jelent egy olyan azonosítási szint, ahol a legkisebb egység még önállóan üzembe helyezhetõ, cserélhetõ vagy módosítható.
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 KE-bõl. Itt kompromisszumot kell kötnünk: a variánsok használata révén kevesebb KE-et kell kezelni, és könnyebb a közösen kezelendõ KE-ek azonosítása hibák kezelése vagy változtatások megvalósítása során. Ez a módszer viszont jelentõsen növeli a KK rendszer összetettségét. Általános szabályként tekinthetõ, hogy ha egy KE egy másik KE kissé módosított változatának tekinthetõ, és az egyiket érintõ problémák valószínûleg hatnak a másikra, vagy az egyiken végrehajtott változtatásnak a másikon is meg kell történnie, akkor a variáns használata megfontolandó. Máskülönben ezek különbözõ KE-ként kezelendõk.
Elõírások
Döntés szükséges a verziók alkalmas számozási rendszerérõl. Két vagy háromszintû számozási rendszer ajánlható, amelynek felsõ szintje a nagyobb változások, az alsó szint pedig a kisebb változások jelölésére szolgál. Ha egy KE-et megváltoztattak valamilyen módon, meg szokás tartani az eredeti nevet, de a verziószámot megváltoztatják. A nagyobb változásokat új modellszámokkal kell jelezni. Az azonos specifikációjú KE-ek, szoftver másolatok a másolatszámmal vagy sorozatszámmal különböztethetõk meg.
Az összes egyedi KE azonosítására elnevezési konvenciót kell kialakítani. Ez a konfiguráció-menedzser feladata. Az egyes KE elõfordulásokat egyedileg meg kell tudni különböztetni a KE név és a másolatszám/sorozatszám segítségével.
Megjegyzendõ, hogy a verziószám a KE-nek az ugyanolyanként kezelhetõ, de megváltoztatott verzióját is azonosítja. Ugyanannak a KE-nek több mint egy verziója létezhet együtt egyidejûleg. A variánsok a hasonló KE-mel azonos nevet viselhetnek, de attól különbözõ verziószámot kell kapniuk.
A másolatszám egy KE meghatározott másolatát azonosítja. Ha különbözõ másolatok azonos nevet viselnek, a másolatszám a név lényeges részének tekintendõ, hogy semelyik két másolat ne lehessen azonos.
Az elnevezési szabályok tervezésekor nagyon fontos elegendõ figyelmet fordítani a lehetséges jövõbeni növekedésre. Az elnevezési konvenció kialakításakor a következõ szempontokat érdemes figyelembe venni:
A konfigurációs elemekrõl feljegyzendõ tulajdonságok tervezése
A tervezés lényegi részeként adatgyûjtést kell végezni, hogy megszerezzük a szükséges információkat az attribútumokról. A különféle KE kategóriáknál különbözni fognak a feljegyzendõ tulajdonságok. A döntést a feljegyzendõ tulajdonságokról a KKAB is befolyásolhatja. Meg kell tervezni a szükséges adatok összegyûjtését is. Általában van már valamilyen adat (nyilvántartás) a szervezet birtokában, ami felhasználható.
Termékbázisok tervezése
A termékbázisok egy adott KE (és az alkotó KE-ek) adott idõpontbeli állapotának, jellemzõinek, összetételének rögzítése, amely biztos kiindulási alapul szolgálhat beszerzésekhez, továbbfejlesztésekhez, hibás változtatás esetén a visszaállításhoz. Ilyenek pl. a csomagkiadások feljegyzései vagy a hardver-specifikációk.
A konfigurációs elemek címkézésének tervezése
Valamennyi KE-et a megfelelõ módon el kell látni a KE névvel, verziószámmal, modell számmal, másolatszámmal a könnyû azonosítás lehetõvé tétele érdekében. Ahol a KE hardver eszköz, fizikai címkét kell használni, míg szoftverek esetében a fájl fejének kell tartalmaznia a címkét. Gondot kell 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.
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:
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.
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û gyermek-betegségeket. A szoftverek üzembe helyezése után rögtön a szükséges kiképzés kezdõdhet. A tesztelést a képzéssel kombinálva kétszeres hasznot érhetünk el és két legyet ütünk egy csapásra.
A megvalósítás nyilvánossá tétele
A megvalósítás részét kell képeznie egy figyelemfelkeltõ kampánynak is, hogy a személyzetben tudatosítsa az új KK eljárások bevezetésének idõpontjait. Minden érintettel tudatni kell, hogy milyen változások várhatók és azok hogyan érintik õket. Meg kell gyõzni õket arról, hogy a funkció valóban hasznos a szervezet számára, és nem csupán egy rájuk kényszerített ötlet. A meggyõzés eszközeként szolgálhatnak a témáról tartott szemináriumok, prezentációk, a szervezetben terjesztett tájékoztató dokumentumok.
A konfigurációs adatbázis feltöltése
Ezután következhet a KE-ek részletes adatainak a KKAB-ba való bevitele, a már korábban tárgyalt fokozatos módon, biztosítva, hogy az újonnan az informatikai infrastruktúrához adott elemeket ne lehessen figyelmen kívül hagyni. Ebbe beleértendõk a még nem implementált VK-ek. Ha ezek kerülnek elõször az adatbázisba, akkor minden új vagy kapcsolódó változás az új eljárások alanya lesz, beleértve a jóváhagyást és az implementációt. A történeti feljegyzések várhatnak egy késõbbi, nyugodtabb idõpontig. Más szóval inkább minden új KE-re és VK-re fordítsuk a figyelmünket, mintsem a létezõ feljegyzésekre. A feltöltés fáradságos, idõigényes tevékenység, ezért szükséges lehet átmeneti segítség igénybevétele (adatrögzítõk alkalmazása).
Átállás az új rendszerre
Az új rendszerre való átállás csupán embereket kíván, akik elkezdik használni az új eljárásokat. Eszközök és procedúrák alkalmazása a folyamat automatizálására kimutatja vagy akár meg is elõzheti a korábbi gyakorlat továbbélését. Hangsúlyt kell helyezni arra, hogy minden új elem hozzáadása az új eljárásokon keresztül történjen.
A megvalósítás utáni szemlék és audit
A konfigurációkezelésnek a változáskezelésben, problémakezelésben, az informatikai eszközök felügyeletében játszott pozitív szerepének kimutatásában a következõ mérõszámok feljegyzése segíthet:
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.
A KK bevezetése során természetesen hibákat lehet elkövetni, mint például: