Konfiguraationhallintajärjestelmä

Konfiguraationhallintajärjestelmä (Configuration Management System, CMS) on konfiguraationhallinnan tukijärjestelmä, jolla hallitaan suuria ja monimutkaisia IT-järjestelmiä ja -infrastruktuureja. Konfiguraationhallintajärjestelmä koostuu kaikista organisaation sisällä olevista rakenneosista ja niiden välisistä suhteista. Nämä rakenneosat sisältävät muun muassa tarkentavaa tietoa IT-infrastruktuurin osista kuten tietoa ohjelmista, työasemista, palvelimista tai dokumenteista. Esimerkkinä tästä voisi olla työasema-rakenneosa, joka sisältäisi tietoa valmistajasta, mallista, tyypistä (tehokannettava, kevyt kannettava), tietoa lisensseistä ja huoltosopimuksista, sekä muuta dokumentaatiota kuten palvelutasosopimuksia ja ulkoisia tai sisäisiä hankintasopimuksia (Office of Government Commerce, 2007).

Käytännössä konfiguraationhallintajärjestelmä pitää sisällään useita eri tietovarastoja (konfiguraatiotietokantoja), jonne organisaatiokohtaista tietoa tallennetaan. CMS voi ottaa tietonsa monesta eri fyysisestä CMDB:stä, sekä useista muista tietolähteistä.

CMS tyypillisesti pitää sisällään kaikkia IT-infrastruktuurin rakenneosia ja tietoa muista lähteistä, jotka voidaan yhdistää liiketoiminnan eri osa-alueita kiinnostavien näkymien muotoon (Office of Government Commerce, 2007).

9 2.1.3 Konfiguraatiotietokanta

Konfiguraatiotietokannat pitävät sisällään kaikki organisaation konfiguraation rakenneosat, joilla on merkitystä liiketoiminnalle. Konfiguraatiotietokannan tehtävänä on pitää kirjaa organisaation kaikista IT-komponenteista, niiden versioista ja tiloista sekä niiden välisistä suhteista. Konfiguraatiotietokannan olomuodot vaihtelevat organisaatioiden välillä. Yksinkertaisimmillaan konfiguraatiotietokanta voi koostua paperilomakkeista, laskentataulukoista tai sharepoint-listoista. Alla olevassa kuvassa (Kuva 2) on esitetty yksinkertainen Excelillä toteutettu CMDB.

Kuva 2. Esimerkki Excel-pohjaisesta CMDB:stä (ServiceNow, 2018b).

Hieman monimutkaisempi versio konfiguraatiotietokannasta koostuisi esimerkiksi useammasta fyysisestä tietokannasta, jotka yhdessä muodostaisivat loogisen kokonaisuuden organisaation IT-infrastruktuurista. Konfiguraatiotietokannan tyyppisiä tietokantoja käytetään myös mm. kehitysosastojen toimesta ohjelmamoduulien versionhallintaan (Office of Government Commerce, 2005).

10

2.1.4 Konfiguraation rakenneosa ja perustaso

Konfiguraation rakenneosa on jokin konfiguraationhallinnan kontrollissa oleva palvelun komponentti, omaisuus, fyysinen artefakti tai muutospyyntö, joka liittyy IT-infrastruktuuriin komponenttiin tai johonkin muuhun liiketoiminnan tärkeään osaan.

Rakenneosat voivat olla hyvin erilaisia. Oli sitten kyse isoista käsitteistä kuten esimerkiksi palveluista tai järjestelmistä tai pienemmistä käsitteistä kuten ohjelman yksittäisestä moduulista tai pienestä laitteiston osasta. Konfiguraation rakenneosia voidaan yhdistää ja hallita esimerkiksi julkaisun muodostamiseksi. Konfiguraation rakenneosien käsitteleminen on tarkkaa. Niitä käsitellessä tulisi niiden valintakriteerit, yhdistettävyys, luokittelu ja tunnistaminen olla toteutettu siten, että ne olisivat helposti hallittavissa ja jäljitettävissä koko palvelun elinkaaren ajan. Konfiguraation rakenneosia on eri tyyppisiä, kuten (Office of Government Commerce, 2007; Office of Government Commerce, 2002a)

 palvelun elinkaaren konfiguraation rakenneosat

 palvelun konfiguraation rakenneosat

 organisaation konfiguraation rakenneosat

 sisäiset konfiguraation rakenneosat

 ulkoiset konfiguraation rakenneosat

 rajapinnan konfiguraation rakenneosat.

Palvelun elinkaaren konfiguraation rakenneosalla tarkoitetaan rakenneosaa, joka kohdistuu johonkin tiettyyn palvelun elinkaaren (palvelustrategia, palvelusuunnittelu, palvelutransitio, palvelutuotanto, palvelun jatkuva parantaminen) vaiheeseen.

Konfiguraation perustaso (Configuration Baseline, CB) on jonkin tuotteen, palvelun tai IT-infrastruktuurin konfiguraatio, joka on katselmoitu huomioiden, että jatkoaktiviteetin perustasoa voidaan muuttaa vain muutosprosessien kautta.

Konfiguraation perustason keskeisenä ajatuksena on kirjata konfiguraation rakenne, sisältö ja yksityiskohdat sekä esittää kaikki siihen liittyvät CI-yhteydet.

Konfiguraation perustason määrittäminen mahdollistaa (Office of Government Commerce, 2007)

11

 tärkeän tapahtuman merkitsemisen palvelun kehitysvaiheessa

 palvelukomponentin rakentamisen määritetyistä syötteistä

 tietyn version muuttamisen tai uudelleen rakentamisen myöhemmällä ajanjaksolla

 kaikkien tärkeiden komponenttien yhdistämisen muutosta tai julkaisua varten

 konfiguraatioiden auditointien tai perumisien perusteiden tarjoamisen.

2.1.5 Kriittiset menestystekijät ja suorituskykymittarit

Kriittiset menestystekijät (Critical Success Factors, CSF) määrittävät palvelunhallinnan tärkeimmät hallittavat kohteet (strategisesti, teknisesti ja organisaatio- tai prosessitasolla), jotta saavutettaisiin kontrolli kaikista organisaation IT-prosesseista (Sallé, 2004). Konfiguraationhallinnan kriittisiä menestystekijöitä ovat (Office of Government Commerce, 2007; Office of Government Commerce, 2002b;

Brooks, 2006)

 tiedon kerääminen ja ylläpitäminen

 potentiaalisten epäonnistumisen kohtien tunnistaminen

 oikeellisen tarkkuuden määrittäminen

 konfiguraationhallinnan tukeminen automatisoidulla teknologialla

 IT-omaisuuksien hallinnointi

 IT-palveluiden tukeminen

 palveluiden taloudellinen toimittaminen

 muiden ITSM-prosessien tukeminen

 asiakastyytyväisyys.

Keskeiset suorituskykymittarit (Key Performance Indicators, KPI) ovat yleensä mitta jostain kriittisestä menestystekijästä, jonka avulla voidaan mahdollisesti parantaa jotain tiettyä prosessia. Keskeiset suorituskykymittarit ovat yleensä ytimekkäitä ja mitattavia elementtejä jonkun prosessin suorituskyvystä suhteessa siihen, kuinka hyvin prosessi saavuttaa sille annetut tavoitteet (Sallé, 2004). Konfiguraationhallinnan suorituskykyä tulisi tarkkailla, raportoida ja jatkuvasti parantaa, jotta palveluomaisuuksien ja konfiguraatioiden kustannuksia ja suorituskykyä voitaisiin

12

paremmin optimoida. Tätä varten seuraavia keskeisiä suorituskykymittareita tulisi hallita (Office of Government Commerce, 2007; Office of Government Commerce, 2002b; Brooks, 2006)

 CI-komponenttien korjaamiseen ja palauttamiseen kuluva aika

 palveluhäiriöiden lukumäärä

 virheellisten rakenneosien tunnistamisen ja palveluiden palauttamisen taso

 häiriöiden ja virheiden vaikutukset rakenneosiin

 auditointien lukumäärä ja taso

 konfiguraatiotiedon laadun ja oikeellisuuden taso

 ihmisten aiheuttaman virheellisen konfiguraatiotiedon lukumäärä

 häiriöiden ja ongelmien tunnistamiseen kuluva aika ja resurssit

 valtuuttamattomien muutosten lukumäärä

 oikein auditoitujen rakenneosien lukumäärä

 väärästä CI-tiedosta johtuvien palveluvirheiden lukumäärä

 asiakastyytyväisyyden taso suhteessa palveluihin ja laitteistoon

 kadonneiden ja kopioituneiden rakenneosien lukumäärä

 huoltokustannusten ja lisenssimaksujen budjetissa pysyminen

 rakenneosien ja konfiguraatiotietokannan ylläpitämiseen menevät kulut

 virheellisestä konfiguraatiotiedosta johtuvien muutosten epäonnistumisien lukumäärä

 väiriöiden selvittämiseen kuluva aika

 tarkemmat tulokset riskianalyysiauditoinneilla

 käyttämättömien lisenssien lukumäärä

 huonosta CMDB-tiedosta seuranneiden epäonnistuneiden muutosten lukumäärä

 luvattomien konfiguraatioiden lukumäärä

 häiriöiden lukumäärä johtuen väärin dokumentoiduista rakenneosista

 konfiguraatiotietokannan virheistä johtuneiden

palvelutasosopimusrikkomusten määrä

 muutospyynnöt, joihin ei ole päivitetty CI-tietoja

13

 virheellisten konfiguraation rakenneosien prosentuaalinen osuus.

Taulukossa 1 on annettu esimerkki konfiguraationhallinnan kriittisistä menestystekijöistä, avainsuorituskykyindikaattoreista ja mittareista.

Taulukko 1. Esimerkki häiriönhallinnan CSF-KPI-Mittari -taulukosta (ServiceNow, 2018a, mukaillen) SLA:n puitteissa prioriteetti tasoittain

Taulukossa 2 esitetään kysymyksiä, joita tulisi pohtia, kun rakennetaan CSF-KPI-Mittari -taulukkoa.

Taulukko 2. Kysymyksiä CSF-KPI-Mittari -taulukon rakentamiseen (ServiceNow, 2018a, mukaillen)

Kysymys Perusteltu vastaus

Miksi häiriönhallinta on tärkeää ja mitä se

kertoo meille? Se mahdollistaa kyvyn häiriöiden

käsittelemiseen oikeassa priorisoidussa järjestyksessä, se takaa parantuneen häiriönhallintaprosessin sekä paremman asiakastyytyväisyyden.

Miten sitä voidaan mitata ja analysoida? Tarkastelemalla häiriöraportteja prioriteettimallia ja SLA:n sovittuja suoritusaikoja vasten.

Kuinka usein häiriönhallintaprosessia tulisi mitata?

Aluksi viikottain, sitten kuukausittain.

Kriittisten asiakkaiden kohdalla mittausta voidaan suorittaa useammin.

Kuinka tuloksia tulisi esitellä ja jakaa? Esittelyssä tulisi käyttää taulukoita ja graafeja, jakamisessa pitäisi huomioida tarkempi häiriöiden analysoiminen.

Kuinka tulosten analysointi voisi auttaa jatkuvan parantamisen prosessia?

Tunnistamalla heikkoja kohtia prioriteettimallissa tai tarpeissa esimerkiksi SLA:n tarkentamiseksi.

Kuinka suoriutumisen mittareita voidaan

asettaa ja tarkastella? Määritellään suoriutumisen mittarit SLA:ssa ja tarkastellaan niitä sen mukaisesti.

2.1.6 Definitiivinen mediakirjasto

Definitiivinen mediakirjasto (Definitive Media Library, DML) on turvallinen kirjasto, joka sisältää kaikki tallennetut ja suojellut lopulliset versiot kaikista media-rakenneosista. Sinne tallennetut kopiot ovat alkuperäisiä versioita rakenneosista, jotka ovat menneet laadunvarmistuksen tarkastusten läpi. Definitiivinen mediakirjasto

14

koostuu yhdestä tai useammasta kirjastosta tai tiedontallennusalueesta sisältäen alkuperäiset kopiot kaikista ostetuista ja organisaation sisällä kehitetyistä ohjelmistoista sekä erilaisista dokumentaatioista elektronisessa muodossa (Office of Government Commerce, 2007).

Definitiivisen mediakirjaston käsitteeseen sisältyy myös fyysinen tallennuspaikka kaikille alkuperäisille kopioille, jotta kyseiset kopiot selviäisivät esimerkiksi mahdollisen tulipalon syttyessä ja tulipalon tuhotessa elektronisen definitiivisen kirjaston. Konfiguraationhallinta kontrolloi vain sallitun median sisällytystä definitiiviseen kirjastoon. Tämä sallittu media definitiivisessä kirjastossa luo perusteet julkaisun- ja käyttöönotonhallinnalle. Definitiivisen mediakirjaston konfiguraation suunnittelussa tulisi ottaa seuraavia asioita huomioon (Office of Government Commerce, 2007)

 käytettävät laitteistot ja ohjelmisto, fyysinen sijainti ja tiedotusvälineet

 tallennusalueiden ja fyysisen median käytäntöjen nimeäminen

 definitiivisen kirjaston tukemat ympäristöt

 turvallisuusjärjestelyt koskien muutoksia, dokumentaatioita ja ohjelmistoja sekä näihin liittyvät varmuuskopiot sekä palauttaminen

 definitiivisen kirjaston ulottuvuus

 säilytyksen ja arkistoinnin ajanjaksot

 auditoinnin prosessit

 definitiivisen kirjaston virheiltä ja epäoikeutetuilta muutoksilta suojaavat prosessit

 definitiivisen kirjaston kapasiteettisuunnitelmat ja kasvun tarkkailu.

2.2 Konfiguraationhallinnan suunnittelu ja hallinta

Konfiguraationhallinnan pääaktiviteetteja ovat (Office of Government Commerce, 2005):

15

 Suunnittelu. Määrittää strategian, käytännöt ja prosessin tavoitteet, tiedon analysoinnin, työkalujen ja resurssien löytämisen, rajapintojen luomisen, projektit sekä toimittajat.

 Tunnistaminen. Määrittää prosessit, joilla tietokantaa pidetään ajan tasalla.

Näihin prosesseihin kuuluu tietomallin kehittäminen komponenttien ja niiden välisten suhteiden, tilojen ja dokumentaation tallentamiseksi sekä prosessit uusille rakenneosille ja niiden muutoksille.

 Hallinta. Konfiguraatiotietokannan ajantasaisuuden varmistaminen oikeutettujen CI-lisäysten, tallennuksien ja valvonnan avulla. Hallinta varmistaa, että CI-muutoksia ei tapahdu ilman asianmukaisia toimenpiteitä.

 Rakenneosien tilojen valvonta. Nykyisten ja menneiden tilojen tallentaminen rakenneosien elinkaarten aikana esimerkiksi tilojen muutosten tunnistamiseksi. Esimerkkejä tiloista ovat ”Kehityksessä”, ”Testattavana”,

”Varastossa”, ”Tuotannossa” sekä ”Lopetettu”.

 Vahvistus. Konfiguraatiotietokantaa auditoimalla vahvistetaan tallennettujen rakenneosien olemassaolo ja tietokannan oikeellisuus.

 Raportointi. Tiedon tarjoaminen muille prosesseille sekä rakenneosien kehityksistä ja trendeistä raportoiminen.

Konfiguraationhallinnan suunnittelussa tulisi ainakin seuraavat asiat ottaa huomioon (The art of service, 2007)

 konfiguraationhallinnan tavoitteet, ulottuvuus ja päämäärä

 standardit, käytännöt ja prosessit, jotka liittyvät konfiguraationhallintaan ja tulisi ottaa huomioon

 roolit ja vastuut konfiguraationhallinnan sisällä

 rakenneosien yksilöinti

 kaikki konfiguraationhallintaprosessin suorittamiseen liittyvät asiat, jotka liittyvät rakenneosien tunnistamiseen, kontrollointiin, tilojen määrittämiseen, auditoimiseen ja vahvistamiseen

 rajapintojen kontrollointi muiden osa-alueiden kuten muutoksenhallinnan ja jakelunhallinnan kanssa

16

 konfiguraationhallintajärjestelmän kattavuuden ja sen rajapintojen määrittäminen ja suunnitteleminen.

Tilojen kirjaamisessa ja raportoinnissa, rakenneosan elinkaari luokitellaan eri vaiheisiin. Esimerkiksi julkaisu menee elämänsyklissään seuraavat vaiheet läpi:

rekisteröity, hyväksytty, asennettu ja peruttu. Tilaraportit antavat tietoa nykyisistä ja menneistä CI-tiedoista sekä tilamuutoksista. Erilaisia konfiguraatioraportteja tarvitaan konfiguraationhallinnassa. Raportit voivat liittyä yksittäisiin rakenneosiin tai kokonaisiin palveluihin. Tällaiset raportit voivat koostua muun muassa: rakenneosista ja niiden perustasoista, nykyisistä tiloista ja muutoshistoriasta, valtuuttamattomista rakenneosista tai epäoikeutetuista laitteistojen tai ohjelmistojen käytöistä (Bon et al., 2007).

Vahvistamisessa ja auditoinnissa konfiguraationhallinta tekee auditointeja, jotta vältettäisiin ristiriitaisuudet dokumentoitujen perustasojen ja todellisten konfiguraatioiden välillä. Kaikki poikkeukset, jotka havaitaan auditoinnin yhteydessä, tulisi dokumentoida ja niistä tulisi raportoida eteenpäin. Korjaustoimenpiteet tapahtuvat muutoksenhallinnan johdosta. Auditointeja suoritetaan esimerkiksi:

CMDB:ssä tapahtuvia muutoksia ennen ja niiden jälkeen, sattumanvaraisesti ja valtuuttamattomien rakenneosien löytämisien jälkeen (Bon et al., 2007).

2.3 Konfiguraationhallinnan tietokannat

Konfiguraationhallintajärjestelmän käyttötarkoitus on monipuolinen. Esimerkki tästä voisi olla konfiguraationhallintajärjestelmän sisällä oleva tieto, jota käytetään finanssipuolen omaisuudenhallintajärjestelmälle tarkkojen omaisuudenhallintaprosessien raportoimiseksi. Konfiguraationhallintajärjestelmä sisältää tietoa rakenneosista ja niiden välisistä suhteista sekä kaikista niihin liittyvistä häiriöistä, ongelmista, tunnetuista virheistä ja julkaisudokumenteista.

Konfiguraationhallintajärjestelmään voidaan sisällyttää myös muuta organisaatiota koskevaa tietoa kuten tietoja työntekijöistä, toimittajista, asiakkaista ja käyttäjistä (Office of Government Commerce, 2007). Konfiguraationhallintajärjestelmä koostuu

17

yleensä neljästä kerroksesta: Esittelykerros (joka sisältää eri näkymiä eri ryhmille), tiedon prosessointikerros (raporttien ja kyselyiden luominen), tiedon integraatiokerros (tiedon koonti ja järjestäminen) ja tietokerros (sisältää tietoa eri lähteistä kuten konfiguraatiotietokannasta, havainto- ja inventointityökaluilta tai projektitietoa) (Bon et al., 2007).

Konfiguraationhallintajärjestelmä voi saada tietoa useammasta fyysisestä konfiguraatiotietokannasta, jotka yhdessä muodostavat federoidun konfiguraatiotietokannan (Federated Configuration Management Database, FCMDB).

Muina tietolähteinä konfiguraationhallintajärjestelmä käyttää esimerkiksi definitiivisiä mediakirjastoja. Konfiguraationhallintajärjestelmä pyrkii siihen, että sen tietokannoissa olisi mahdollisimman paljon liiketoiminnan kannalta olennaista ja päivitettyä tietoa, ilman kahdennuksia. Palveluiden kehittyessä niiden elinkaaren aikana kehittyy myös niiden konfiguraatiotieto. Tämä tieto yhdistetään integroiduiksi tietueiksi, jota eri sidosryhmät käyttävät koko palvelun elinkaaren ajan. Tämän takia konfiguraationhallintajärjestelmän tulee rakentua oikeanlaisen tiedon ympärille toimittaakseen muille palvelunhallintaprosesseille tilanteeseen sopivat kysely- ja raportointityökalut käytettäväksi (Office of Government Commerce, 2007).

Nykypäivän isoissa ja monimutkaisissa järjestelmissä ei organisaatioiden ole järkevää ylläpitää vain yhtä konfiguraatiotietokantaa, koska tämän skaalautuvuuden rajat tulisivat nopeasti vastaan. Tämän takia organisaatioiden olisi järkevää pitää osaa rakenneosatiedoistaan paikallisesti tallennetuissa paikoissa ja loppuja tietojaan etäisellä tallennuspaikalla. Tiedon tallennuspaikan ei tulisi näkyä loppukäyttäjälle, vaan tietoon pitäisi päästä käsiksi nopeasti ja vaivattomasti yhden rajapinnan kautta (Keel et al., 2007). Alla olevassa kuvassa (Kuva 3.) on mallinnettu IT-infrastruktuuri, joka voidaan lisätä konfiguraatiotietokantaan.

18

Tulostin

Tietokone-1

Tietokone-2 Tietokone-3

Tietokone-4

Tietokone-5

Kannettava tietokone-2

Tietokone-7

Tietokone-8 Tietokone-9 Tietokone-10 Tietokone-11

Palvelin

Kannettava tietokone-1

Kannettava tietokone-3

Modeemi

Käyttäjä

Reititin

Kuva 3. Esimerkki IT-infrastruktuurin mallintamisesta (Servicetonic, 2018, mukaillen).

Monilla organisaatioilla on jo käytössään tiettyjä elementtejä konfiguraationhallinnasta, kuten arkistot dokumenteista, laskentataulukoita tai paikallisia tietokantoja, joita voidaan käyttää konfiguraationhallintajärjestelmässä.

Konfiguraatiotietokantojen lataamiseksi ja ylläpitämiseksi tulisi kehittää automatisoituja prosesseja, joilla voitaisiin vähentää virheiden määrää sekä optimoida kustannuksia. Erilaisia työkaluja kuten havainnointityökaluja, auditointityökaluja ja verkonhallintatyökaluja voidaan käyttää, jotta konfiguraatiotietokannat saataisiin täytettyä. Näitä työkaluja voidaan myös käyttää konfiguraatiotiedon vertaamiseen konfiguraationhallintajärjestelmän ja tuotantoympäristön välillä (Office of Government Commerce, 2007).

Koska muut ITSM-prosessit (kuten häiriön-, ongelman-, muutoksen-, julkaisun-, palveluntason- ja saatavuudenhallinta) hyödyntävät konfiguraatiotietokannan tietoa, tulee tiedon, jolla konfiguraatiotietokanta toteutetaan (konfiguraatiotietokannan ulottuvuus), olla tarkasti määritetty. Tämän määrittämiseksi tulisi organisaatioiden miettiä, mitkä kaikki asiat sisällytetään konfiguraatiotietokannan ulottuvuuteen.

19

Otetaanko kaikki laitteisto kuten tulostimet, näytöt, näppäimistöt tai henkilökunta mukaan? (Office of Government Commerce, 2005). Konfiguraatiotietokantaa ei tulisi nähdä pelkästään tietokantana, joka sisältää tietoa organisaation rakenneosista, vaan ratkaisuna, joka mahdollistaa kriittisten liiketoimintafunktioiden toteuttamisen IT:n tuella (BMC Software, 2005).

Konfiguraatiotietokanta on paljon muuta kuin vain tietokanta, johon tallennetaan tietoa eri laitteistojen ja ohjelmistojen rakenneosista. Todellinen konfiguraatiotietokanta on meta-tietokanta tai tietokantojen tietokanta. Se tarjoaa kontekstia IT-infrastruktuurin sisällön kuvauksien kartoittamiseen, jotka on tallennettu muihin tietokantoihin. Jotkut organisaatiot pitävät konfiguraatiotietokantoinaan Excel-taulukoita, itse luotuja relationaalisia tietokantoja tai Visiolla luotuja kaavioita, kun taas todellinen konfiguraatiotietokanta on definitiivinen. Toisin sanoen, konfiguraatiotietokannan sisällä olevaa tietoa ei tulisi tarvita varmistaa tai todentaa.

Konfiguraatiotietokannan tarkoituksena on olla uskottava lähde konfiguraation rakenneosille (Marquis, 2007).

Konfiguraatiotietokanta täytetään erilaisilla rakenneosilla, jotka voivat olla esimerkiksi: fyysisiä artefakteja, IT-omaisuutta, -palveluita ja näiden komponentteja, turvallisuuskomponentteja tai dokumentaatiota kuten palvelutasosopimus, proseduureja, ohjekirjoja, teknisiä määrittelyjä, organisaatiokarttoja, lisenssejä, ihmisiä ja projektisuunnitelmia. Konfiguraatiotietokannassa sijaitsevat rakenneosat sijaitsevat fyysisesti jossain muualla. Konfiguraatiotietokantaan lisättävät rakenneosat sisältäisivät versionumeron, julkaisupäivän, tekijän sekä muun tarpeellisen tiedon (Office of Government Commerce, 2005; Bon, 2006).

Konfiguraatiotietokannan tarkkuuden parantamiseksi tulisi kaikki siihen liittyvät virheet tunnistaa ja laskea. Varmin tapa löytää virheitä olisi tehdä pistotarkistuksia tai tieto-auditointeja konfiguraatiotietokannalle. Toisin sanoen konfiguraatiotietokannassa olevaa tietoa verrataan muihin tietoihin (kuten havainnointityökalun tietoihin) virheiden löytämiseksi (Klosterboer, 2007). Kuvassa (Kuva 4.) on listattu konfiguraatiotietokannan virheiden havainnointikeinoja.

20

Kuva 4. Virheiden aktiivinen etsiminen konfiguraatiotietokannasta (Klosterboer, 2007, mukaillen).

Pistokokeen otoskoon tulisi kattaa 5 prosenttia tietokannan koosta. Jos virheitä ei löydetä, voidaan tätä otoskokoa pienentää ja jos virheitä löydetään, voidaan sitä kasvattaa, kunnes virheitä aiheuttavat syyt löydetään. Joka kerta kun muutosta ehdotetaan, tulisi arvioida miten muutos vaikuttaa konfiguraatiotietoihin. Usein muutoksen ehdotuksen yhteydessä mahdollisia virheitä paljastuu konfiguraatiotietoa tarkastellessa. Yleensä häiriön ilmetessä sitä hoitavat henkilöt paneutuvat syvälle organisaation tiettyyn osa-alueeseen. Tällöin olisi hyvä panostaa löydösten vertaamiseen CMDB-tietoja vasten. Mitä useampi henkilö tuntee olevansa vastuussa konfiguraatiotietokannan tarkkuudesta, sitä tarkempi se tulee olemaan (Klosterboer, 2007).

Kaikki rakenneosista johtuvat häiriöt on mahdollista paikantaa nopeasti konfiguraatiotietokannassa olevan tiedon perusteella, koska sen sisälle on tallennettu IT-infrastruktuurin rakenneosat ja niiden väliset suhteet. Konfiguraatiotietokannassa sisältävästä tiedosta voidaan luoda palveluraportteja, joita voidaan käyttää esimerkiksi

21

palveluiden parantamiseksi. Esimerkkinä tästä voisi olla yhden palvelun rakenneosien seuraaminen konfiguraatiotietokannassa, joka voisi mahdollisesti paljastaa meille, että kyseinen palvelu ei olisi täysin konfiguraatiotietokannan ulottuvuuden sisällä (jotain rakenneosaa esimerkiksi tarjottaisiin ulkoisen toimittajan puolesta, eikä sitä olisi kirjattu konfiguraatiotietokantaan). Tämä kyseinen palvelu ei olisi täysin tuettu ja sen puuttuvat rakenneosat tulisi liittää konfiguraatiotietokantaan ja sen ulottuvuuteen (Office of Government Commerce, 2005).

Kun konfiguraatiotietokannan laajuus on määritetty oikein, voidaan määrittää rakenneosien elinkaarten elementit. Tärkeä päätös tässä vaiheessa on päättää, että otetaanko keskeneräiset rakenneosat konfiguraatiotietokantaan vai ei. Mukaan ottaminen takaisi paremman kontrollin rakenneosia koskeviin muutoksiin ja niiden siirtyminen tuotantoympäristöön sujuisi sulavammin. Toisaalta tämä kuormittaisi rakenneosien tilojen valvontaa ja mahdollisesti laajentaisi konfiguraationhallinnan ulottuvuutta suhteessa tuotteen elinkaareen (Office of Government Commerce, 2005).

Konfiguraatiotietokannan avulla organisaatiot pystyvät paremmin kohdistamaan IT-resurssejaan tukemaan liiketoimintojensa tarpeita. Konfiguraatiotietokanta auttaa organisaatioita hallitsemaan IT-infrastruktuuria asiakaskeskeisestä näkökulmasta, koska konfiguraatiotietokannasta saatava tieto auttaa pitämään tarjottujen palveluiden tason optimaalisella tasolla. Konfiguraatiotietokannan avulla varmistetaan rakenneosien kontrollointi ja saavutetaan valmius auditoinnille. Näin konfiguraatiotietokanta luo pohjaa muiden IT-palvelunhallintaprosessien toteuttamiselle ja käyttöönotolle (BMC Software, 2005).

2.4 Hyödyt muille palvelunhallintaprosesseille

Konfiguraationhallinnan tarkoituksena on tukea muita palvelunhallintaprosesseja kuten häiriön-, ongelman-, muutoksen-, riskien- ja julkaisunhallintaa tarjoamalla tarkkaa ja oikeellista tietoa konfiguraatioista ja niiden dokumentaatioista (The art of service, 2007).

22

Jotta häiriöitä voidaan kirjata oikein, häiriönhallintaa (Incident Management, IM) suorittavat henkilöt, esimerkiksi palvelupisteen (Service Desk, SD) ammattilaiset tarvitsevat pääsyä CI-tietoihin rakenneosan fyysisen sijainnin ja omistajan tunnistamiseksi, jotta tunnetut virheet tai ongelmat voitaisiin linkittää tiettyyn rakenneosaan. Sama koskee asiakkaiden, palveluiden ja palvelutasosopimusten liittämistä tiettyihin rakenneosiin (Office of Government Commerce, 2005).

Ongelmanhallinta (Problem Management, PB) tarvitsee CMDB-tietoa ja rakenneosia, jotta se voisi linkittää ongelmat ja tunnetut virheet niitä aiheuttaviin rakenneosiin sekä analysoida niitä. Muutoksia ja virheitä löydetään, kun konfiguraatiotietokannassa sijaitsevaa konfiguraatiotietoa verrataan IT-infrastruktuurissa sijaitsevaan todelliseen konfiguraatioon (Office of Government Commerce, 2005).

Muutoksenhallinta (Change Management, CM) tunnistaa toimenpantujen muutosten vaikuttavuutta konfiguraatiotietokannan avulla. Muutoksenhallinta valtuuttaa muutokset ja liittää muutokset niihin liittyviin rakenneosiin. Muutoksenhallinnan vastuulla on myös muutospyyntöjen tallentaminen ja täten sillä on suurin vastuu konfiguraatiotietokannan päivityksiin liittyen. Muutoksenhallinta on tärkeä onnistuneen konfiguraationhallinnan kannalta (kuten myös toisinpäin) (Office of Government Commerce, 2005; Johnson et al., 2007).

Jakelunhallinta (Release Management, RM) tarjoaa tietoa rakenneosien versioista ja niiden tiloista kuten julkaisusuunnitelmia sekä tietoa toteutetuista muutoksista.

Julkaisunhallinta tarvitsee konfiguraationhallinnalta tietoa rakenneosien tiloista, sijainneista tai lähdekoodien sijainneista definitiivisessä mediakirjastossa muutoksien toteuttamiseksi (Office of Government Commerce, 2005).

Palvelutasonhallinta (Service Level Management, SLM) tarvitsee tietoa palveluista ja niiden välisistä yhteyksistä IT-infrastruktuurin rakenneosiin. SLM-tietoa voidaan tallentaa konfiguraatiotietokantaan ja linkittää siihen liittyviin rakenneosiin.

Palvelutaso voidaan tallentaa sitä vastaaviin palvelu-tyyppisiin rakenneosiin, laitteiston komponentteihin tai ohjelmisto-rakenneosiin (Office of Government Commerce, 2005).

23

Taloushallinto (Financial Management, FM) tarvitsee tietoa palveluista ja rakenneosista, esimerkiksi tunnistamaan mikä osasto käyttää mitäkin prosessointipalveluita tai että kenellä on hallussaan joku tietty tietokone. Se yhdistää tämän tiedon palvelutasosopimuksessa sijaitsevan tiedon kanssa veloitettavien kulujen määrittämiseksi. Tällä prosessilla myös monitoroidaan komponentteja ja IT-omaisuutta kuten lisenssejä (Office of Government Commerce, 2005).

Saatavuudenhallinta (Availability Management, AM) tarvitsee konfiguraatiotietokannassa olevaa tietoa rakenneosista, tunnistaakseen mitkä rakenneosat ovat yhteydessä mihinkin palveluun ja tehdäkseen komponentin vikaantumisen vaikutusanalyysin (Component Failure Impact Analysis, CFIA).

Saatavuudenhallinta tekee suunnitelmia muutoksille tunnistettujen heikkouksien parantamiseksi. Konfiguraationhallinta tarjoaa tietoa palvelun koostumuksesta ja sen jokaisesta elementistä (Office of Government Commerce, 2005).

IT-palveluiden jatkuvuudenhallinta (IT Service Continuity Management, ITSCM) käyttää konfiguraatioiden perustasoja konfiguraatiotietokannassa tarkentaakseen katastrofista palautumisen vaatimuksia ja varmistaakseen, että nämä konfiguraatiot ovat saatavilla katastrofista palautumisen yhteydessä. Laadunvarmennustarkastuksen läpäisseitä alkuperäisiä kopioita kaikista organisaation rakenneosista säilytetään sekä fyysisessä että elektronisessa DML:ssä palautumista varten (Office of Government Commerce, 2005; Office of Government Commerce, 2007).

Kapasiteetinhallinta (Capacity Management, CM) tarvitsee tietoa konfiguraatiotietokannasta suunnitellakseen IT-infrastruktuurin optimointia, jakaakseen työtaakkaa ja kehittääkseen kapasiteettisuunnitelman (Office of Government Commerce, 2005).

Tietoturvan hallinta (Information Security Management, ISM) vaatii, että konfiguraatiokannassa oleva tieto on oikeellista ja riittävästi suojeltu korruptioilta tai muutoksien vaikutuksilta. Konfiguraationhallinta auttaa tietoturvan hallintaa tarjoamalla oikeellista tietoa rakenneosista, joita voidaan käyttää hyödyksi kun järjestelmien, palveluiden ja palvelukomponenttien hyväksyttäviä riskitasoja

24

arvioidaan (ISO/IEC, 2012b). Konfiguraationhallinnan riippuvuudet ja hyödyt suhteessa muihin IT-palvelunhallintaprosesseihin on kuvattu kuvassa (Kuva 5.).

Konfiguraationhallinta

Kuva 5. Konfiguraationhallinnan hyödyt muille ITSM-prosesseille (Ying et al., 2009, mukaillen).

2.5 Konfiguraationhallinnan haasteet

Kaikista ITIL:n palvelunhallinnanprosesseista konfiguraationhallintaa voidaan pitää yhtenä vaikeimmista prosesseista ottaa käyttöön ja suorittaa oikein. Myös digitalisaation myötä nopeasti muuttuvat IT-ympäristöt ja liiketoiminnan muuttuvat

25

tarpeet tuovat konfiguraationhallinnalle lisähaasteita esimerkiksi uusien palveluiden ja näiden rakenneosien syntymisien kasvavasta tahdista, joka näkyy taas tiedon suurenemassa määrässä. Tiedon valtavan määrän hallinta onkin yksi konfiguraationhallinnan suorittamisen suurista haasteista. Tästä johtuen joutuvat palvelunhallinnan ammattilaiset miettimään esimerkiksi seuraavaa kysymystä: Miten CI-tieto olemassa olevista järjestelmistä saadaan siirrettyä uuteen ITSM-järjestelmään?

Jopa pienillä yrityksillä on tuhansia yksilöllisiä tietueita ja niiden välisiä suhteita seurattavanaan, ja isoilla yrityksillä tietueiden määrä nousee miljooniin. Tämä tiedon määrä itsessään luo haasteita konfiguraatiotietokannan luomiselle ja toteutumiselle.

Mitä tietueita lasketaan mukaan? Mitä teknologista tietämystä tarvitaan tietueiden laskemiseksi ja vielä oikeassa järjestyksessä? Miten tietueet kategorisoidaan, jos potentiaalisia kategorisointeja on useita erilaisia? Tästä käy selväksi, että konfiguraatiotietokannan luominen ja ylläpitäminen on haastavaa tiedon määrän ja sen kategorisoinnin takia (Klosterboer, 2007).

Hyvänä esimerkkinä tästä on 15.12.2014 uutisoitu artikkeli Elisan kaivinkonetapauksesta Ruotsissa (Tivi, 2014). Kun kaivinkone ”nirhaisi”

runkokaapelin, syntyi siitä jälkiseurauksia nettiyhteyden tarjoamiseen johtuen virheellisestä konfiguraatiotiedosta. Inhimillisen virheen takia varayhteys ei lähtenytkään automaattisesti päälle, vaan se piti käynnistää manuaalisesti. Tästä koitui pidennetty palveluhäiriö Elisalle. Elisa korjasi palveluhäiriön, pyysi anteeksi asiakkailtaan ja lupasi tulevaisuudessa parantaa konfiguraationhallintaansa. Toinen esimerkki tästä on 02.05.2011 uutisoitu tapaus Amazonin pilvipalveluiden vioista ja sen aiheuttaneesta konfiguraatio-ongelmasta. Pilvipalvelut hidastuivat ja jotkin ylläpidetyt verkkopalvelut, kuten Foursquare ja Reddit kaatuivat tai vastasivat hitaasti.

Tämä johtui siitä, että tietoliikenne ohjattiin vahingossa kulkemaan pienemmän kapasiteetin yhteyksien kautta. Asiakaskuntaa tyydyttääkseen Amazon julkaisi 5700 sanaisen dokumentin tapauksesta, joka vastaanotettiin hyvin asiakkaiden keskuudessa (Tivi, 2011).

26

Dynaamiset ympäristöt. IT-ympäristöjen jatkuvat muutokset ja näiden muutosten hajaantunut luonne luovat omat haasteensa konfiguraationhallinnalle. Erilaisia muutoksia voivat olla käyttäjien asentamat ohjelmat työkoneilleen tai organisaation yhteiselle, jaetulle kiintolevylle, huolto- ja päivitysjulkaisut koskien kaikkia organisaation ohjelmistoja ja laitteistoja, tekniikan vanhentumisesta johtuva tarve uudistaa laitteistoa nykyaikaisemmaksi ja projekteista syntyvät uudet

Dynaamiset ympäristöt. IT-ympäristöjen jatkuvat muutokset ja näiden muutosten hajaantunut luonne luovat omat haasteensa konfiguraationhallinnalle. Erilaisia muutoksia voivat olla käyttäjien asentamat ohjelmat työkoneilleen tai organisaation yhteiselle, jaetulle kiintolevylle, huolto- ja päivitysjulkaisut koskien kaikkia organisaation ohjelmistoja ja laitteistoja, tekniikan vanhentumisesta johtuva tarve uudistaa laitteistoa nykyaikaisemmaksi ja projekteista syntyvät uudet

In document Konfiguraationhallinnan hyödyt riskienhallinnalle ulkoistetussa IT-palvelunhallinnassa ja hajautetussa IT-ympäristössä : tapaustutkimus Savon Voima Oyj (sivua 17-0)