Konfigurációkezelés

1. Konfigurációkezelés Miniszterelnöki Hivatal Informatikai Koordinációs Iroda Informatikai Tárcaközi Bizottság 15. ajánlása (ITIL) alapján

2. Konfigurációkezelés • Ahogy az informatikai rendszerek egyre nagyobbak és összetettebbek lesznek, és az infrastruktúra változásai egyre gyakoribbak és egyre nehezebben kezelhetők, úgy növekszik az igény egy funkcióra, amely az infrastruktúra felügyeletét, kontrollját teszi lehetővé: ez a konfigurációkezelés. • Számos szervezet már működteti a konfigurációkezelés valamilyen formáját. Ez rendszerint papír alapú nyilvántartás. Dr. Molnár Mihály

3. 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. Dr. Molnár Mihály

4. A konfigurációkezelés szükségessége • hogy tudjuk: milyen informatikai vagyon van a szervezet birtokában, • az eszközök hol találhatóak, • az eszközöknek mekkora az értéke, • az eszközöket mire használják, • 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. Dr. Molnár Mihály

5. A konfiguráció kezelés funkciói • 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 konfigurációs elemmel 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 konfigurációs elemek és a konfigurációkezelési adatbázisban (KKAB) feljegyzett hivatalosan elfogadott állapot között. Dr. Molnár Mihály

6. A konfigurációkezelés funkció tervezése • Konfigurációmenedzser kinevezése • ki kell nevezni 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. Dr. Molnár Mihály

7. A személyzet létszámának megállapítása • A konfigurációs csoport az informatikai infrastruktúra mellett fejlesztési projektekért is felelős lesz-e? • A csoport felelős lesz-e a változás kezelésért és/vagy a szoftver felügyelet és terítésért? • A hardver/hálózat üzembe helyezési feladatok és az átvételi felelősség is a csoport feladatkörébe tartozik-e majd? • Mekkora az informatikai infrastruktúra mérete, milyen szinten kell ellenőrzést gyakorolni, és hogy ezáltal milyen számú konfigurációs elem van? • Milyen a támogató eszközök alkalmazhatósága? • A szoftver változások és kiadások, és a hardver/kommunikációs felszerelések változásainak mértéke, gyakorisága és komplexitása milyen? • Ahol személyzet nem áll rendelkezésre vagy nem kellőképpen képzett, valamiféle kiegészítő készségfejlesztő tréning szükséges, áthidaló megoldásként. Ha a konfigurációkezelésbeli szerepek kombinálódnak más területek szerepeivel, (mint a változáskezelés), képzés szükséges e területekhez tartozó ismeretanyagokból is. Dr. Molnár Mihály

8. A konfigurációkezelés és a projekt feladata • 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 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: • a disztribúció és használat céljaira, • vészhelyzetben való felhasználás céljából, • 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. Dr. Molnár Mihály

9. A kontrollálandó infrastruktúra összetevői • 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 fontos kérdése annak eldöntése, hogy milyen szintig gyakorolják a felügyeletet Dr. Molnár Mihály

10. Konfigurációkezelési adatbázis (KKAB) • A KKAB-nak tartalmaznia kell a konfigurációkezelési elemek 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. Dr. Molnár Mihály

11. 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ű Konfigurációs elemnek, é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 Konfigurációkezelési adatbázist. Dr. Molnár Mihály

12. csomag: pl. VIR • csomag: pl. Pü. Verzió számok Funkcionális modul Dr. Molnár Mihály

13. A Konfigurációs Elemek lebontása “szülő/gyermek” • 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. • 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. Dr. Molnár Mihály

14. Elnevezési szabályok tervezése • 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. Dr. Molnár Mihály

15. 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ó naprakészségére. • A megfelelő adatokat a tároló médián is fel kell tüntetni Dr. Molnár Mihály

16. A konfigurációs elemek regisztrációjának tervezése • Eljárásokat kell tervezni és létrehozni az új és jelenlegi Konfigurációs elemek Konfigurációkezelési felügyelet alá vonásához, adataiknak a KKAB-ba való felviteléhez. Fontos, hogy a Konfigurációkezelés bevezetésétől fogva új Konfigurációs elem kontroll nélkül ne kerülhessen az éles környezetbe. Dr. Molnár Mihály

17. Az elosztott felügyelet • Ha a Konfigurációkezelési rendszer elosztott informatikai infrastruktúrát ellenőriz sok helyszínnel, megfontolandó a Konfigurációkezelési 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 Konfigurációs elemek jobb fizikai kontrollja lehetséges az egyes helyszíneken alkalmazott KK személyzet segítségével. Dr. Molnár Mihály

18. A konfigurációs auditok tervezése • Tervet kell készíteni a rendszeres konfigurációs auditról, amely ellenőrzi, hogy a Konfigurációkezelési AB (KKAB) adatai konzisztensek-e a tényleges Konfigurációs elemekkel. 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. Dr. Molnár Mihály

19. A konfigurációkezelés pozitív hatása • Csökken: • 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. Dr. Molnár Mihály

20. A konfigurációkezelés megvalósítása • Megvalósítási terv, • Működtetési terv, • Menedzsment kijelölése, • Megvalósítás, • Üzembe helyezés, • Tesztelés és kiképzés, • A megvalósítás nyilvánossá tétele, • Konfigurációs adatbázis feltöltése. • Átállás az új rendszerre, • Megvalósítás utáni szemlék, auditok. Dr. Molnár Mihály

21. 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. Dr. Molnár Mihály

22. A konfigurációkezeléshez kapcsolódó eljárások • 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 konfigurációs eleméről és lehetséges verzióiról, • a Konfigurációs elemek státuszáról, • valamennyi Konfigurációs elem tulajdonosáról, • az elemek közötti kapcsolatokról. Dr. Molnár Mihály

23. A konfigurációkezelés négy alapfunkciója 1. • 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. 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 • 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. Dr. Molnár Mihály

24. A konfigurációkezelés négy alapfunkciója 2. • 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! Dr. Molnár Mihály

25. Ajánlott irodalom • Configuration Management. IT Infrastructure Library, CCTA. HMSO 1990. ISBN 0 11 330530 3 Dr. Molnár Mihály

26. 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 Dr. Molnár Mihály

27. 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 • 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 Dr. Molnár Mihály