Konfiguraationhallinnan hyödyt riskienhallinnalle ulkoistetussa IT-palvelunhallinnassa ja hajautetussa IT-ympäristössä: Tapaustutkimus Savon Voima Oyj
Tuukka Miettinen
Pro gradu -tutkielma
Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede
Huhtikuu 2018
ii
ITÄ-SUOMEN YLIOPISTO, Luonnontieteiden ja metsätieteiden tiedekunta, Kuopio Tietojenkäsittelytieteen laitos
Tietojenkäsittelytiede
Opiskelija, Tuukka Miettinen: Konfiguraationhallinnan hyödyt riskienhallinnalle ulkoistetussa IT-palvelunhallinnassa ja hajautetussa IT-ympäristössä: Tapaustutkimus Savon Voima Oyj
Pro gradu -tutkielma, 87 s., 1 liite (1 s.)
Pro gradu -tutkielman ohjaajat: FT Marko Jäntti ja Tietotekniikan Insinööri Niko Pehkonen
Huhtikuu 2018
Liiketoimintojen IT-ympäristöiden monimutkaistuessa ja pirstaloituessa nousevat riskienhallinta ja konfiguraationhallinta tärkeiksi prosesseiksi näiden ilmiöiden hallitsemiseksi. Konfiguraationhallinnan pitäessä yllä tietoa kaikista IT- infrastruktuurin osista ja niiden välisistä yhteyksistä riskienhallinta taas pyrkii tunnistamaan kaikki liiketoimintaa koskevat riskit, niiden vaikutukset ja niiden hallintakeinot. Molempia prosesseja on vaikea ylläpitää korkealla tasolla ja tämän saavuttamiseksi tulee organisaatiossa sitoutuminen prosessien suorittamiseksi koskettaa kaikkia. Aikaisempaa tutkimusta molemmista prosesseista itsessään on tehty, mutta niiden yhteisvaikutuksen merkitystä ei ole laajasti tutkittu. Tämän Pro Gradu -tutkielman tarkoituksena on selvittää konfiguraationhallinnan hyödyt riskienhallinnalle.
Tutkimuksessa käytettiin tapaustutkimusta sekä kahta teorialukua tunnistamaan sekä riskienhallinnan että konfiguraationhallinnan hyötyjä. Tapausorganisaationa toimi Savon Voima Oyj, jonka konfiguraationhallinnan ja riskienhallinnan nykytilanteet, haasteet ja kehitysideat kartoitettiin tutkimuksen ensivaiheessa. Aineistoa näiden kartoittamiseksi kerättiin puolistrukturoitujen haastatteluiden, keskeytysriskien kartoituksen palaverin sekä muun Savon Voima Oyj:n aineiston avulla. Tämän jälkeen tulokset ristiintaulukoitiin, jotta kriittisimmät haasteet ja kehitysideat organisaation sisällä tunnistettaisiin.
Tutkimuksen tuloksena tunnistettiin konfiguraationhallinnan ja riskienhallinnan nykytilanteet, haasteet ja kehitysideat. Näiden tulosten pohjalta pystyttiin tunnistamaan konfiguraationhallinnan hyödyt riskienhallinnalle ja luomaan interventiokeinoja niiden toteuttamiseksi. Interventiokeinoja olivat:
prosessikaavioiden, tarkempien riskiarvioiden ja jatkuvuussuunnitelmien luominen.
Lisäksi esitettiin liiketoimintatason CMDB:n idea. Tämän tutkimuksen tuloksia hyödynnettiin Savon Voima Oyj:n prosessien parantamisessa.
Avainsanat: ITIL, IT-palvelunhallinta, konfiguraationhallinta, riskienhallinta, tapaustutkimus
ACM-luokat (ACM Computing Classification System, 2012 version): Applied computing, Enterprise computing, IT governance
iii
UNIVERSITY OF EASTERN FINLAND, Faculty of Science and Forestry, Kuopio School of Computing
Computer Science
Student, Tuukka Miettinen: The benefits from Configuration Management to Risk Management in a outsourced IT Service Management and in a fractured IT environment: Case Study Savon Voima Oyj
Master’s Thesis, 87 p., 1 appendix (1 p.)
Supervisors of the Master’s Thesis: PhD Marko Jäntti and B.Eng Niko Pehkonen April 2018
As IT environments for different types of businesses get more complicated and fractured, organizations need good Configuration Management and Risk Management to manage them properly. While Configuration Management is responsible for keeping track for all the parts of the IT environment and all their connections, Risk Management is responsible for identifying all the risks, their impacts and ways of controlling them associated with the business of the organization. It’s hard to maintain a high level of performance regarding both of these processes and it can only be achieved if the whole organization is committed to executing these processes properly.
There have been studies conserning both of these processes individually but there has been a lack of research regarding the benefits of executing them together. The purpose of this Master’s Thesis is to find out the benefits that Configuration Management has for Risk Management.
Case study and two theory chapters where used to discover the benefits of Risk Management and Configuration Management. The case organization for this research was Savon Voima Oyj which current states, challenges and development ideas for Configuration Management and Risk Management where found in the first stage of the study. The research material used to find these answers was collected from semi- structured interviews, from a risk mapping meeting and from the other research materials available at Savon Voima Oyj. After this, the results were cross tabulated to find the most critical challenges and development ideas within the organization.
As a result of this study, the current state, challenges and development ideas for Configuration Management and Risk Management where found. From these findings, we identified the benefits that Configuration Management provided to Risk Management defines intervention methods to do so. The intervention methods included: a flowchart, a more precise risk assessment process and the creation of contingency plans. Finally, an idea for a business level CMDB was also formed. The results from this study can’t be used for creating theory or generalization and can only be used to improve the processes in question at Savon Voima Oyj.
Keywords: ITIL, IT Service Management, Configuration Management, Risk Management, Case Study
CR Categories (ACM Computing Classification System, 2012 version): Applied computing, Enterprise computing, IT governance
iv
Esipuhe
Tämä tutkielma on ohjattu ESR-rahoitteisen Tuottavuutta ja Digitaalisia Palveluita Liiketoiminnan Avuksi -hankkeen (S21138) aikana keväällä 2018. Tutkielmassa tutkittiin Savon Voima Oyj:n konfiguraationhallinnan hyötyjä riskienhallinnalle tapaustutkimuksen keinoin. Tutkielman ohjaajana toimi FT Marko Jäntti ja Savon Voima Oyj:n ohjaajana ICT- ja digitalisaatiopäällikkö Niko Pehkonen, joita haluan kiittää jatkuvasta opastuksesta ja kannustuksesta IT-maailman pariin. Lisäksi haluan kiittää Savon Voima Oyj:n työkavereitani, perhettäni ja ystäviäni jatkuvasta tuesta tämän koko prosessin aikana.
Kuopiossa 27.04.2018
_________________________
Tuukka Miettinen
v
Lyhenneluettelo
AM Availability Management. Saatavuudenhallinta. (ITSMF, 2014).
BCM Business Continuity Management. Liiketoiminnan jatkuvuudenhallinta.
(Hunnbeck et al., 2011).
BIA Business Impact Analysis. Liiketoiminnan vaikutusanalyysi.
(Hunnbeck et al., 2011).
CFIA Component Failure Impact Analysis. Komponentin vikaantumisen vaikutusanalyysi. (Hunnbeck et al., 2011).
CI Configuration Item. Konfiguraation rakenneosa. (ITSMF, 2014).
CM Capacity Management. Kapasiteetinhallinta. (ITSMF, 2014).
CM Change Management. Muutoksenhallinta. (ITSMF, 2014).
CM Configuration Management. Konfiguraationhallinta. (ITSMF, 2014).
CMDB Configuration Management Database. Konfiguraatiotietokanta.
(ITSMF, 2014).
CMS Configuration Management System. Konfiguraationhallintajärjestelmä.
(ITSMF, 2014).
CM Configuration Model. Konfiguraatiomalli. (ITSMF, 2014).
COBIT Control Objectives for Information and related Technology. Tiedon ja siihen liittyvän teknologian kontrollitavoitteet. (ITSMF, 2014).
CSF Critical Success Factor. Kriittinen menestystekijä. (ITSMF, 2014).
DML Definitive Media Library. Definitiivinen mediakirjasto. (ITSMF, 2014).
vi
ERMC Enterprise Risk Management Committee. Riskienhallintakomitea.
(Information Systems Audit, Control Association & Isaca, 2012a).
FCMDB Federaded Configuration Management Database. Federoitu
konfiguraatiotietokanta. (Office of Government Commerce, 2007).
FM Financial Management. Taloushallinto. (Office of Government Commerce, 2005).
GDPR General Data Protection Regulation. Tietosuoja-asetus. (SFS, 2015).
IM Incident Management. Häiriönhallinta. (ITSMF, 2014).
ISM Information Security Management. Tietoturvan hallinta. (ITSMF, 2014).
ISO International Organisation for Standardization. Kansainvälinen standardointiorganisaatio. (ITSMF, 2014).
ITIL Information Technology Infrastructure Library. Kokoelma parhaita käytäntöjä IT-palveluiden hallintaan ja johtamiseen. (ITSMF, 2014).
ITSCM IT Service Continuity Management. IT-palvelun jatkuvuudenhallinta.
(Hunnbeck et al., 2011).
ITSCP IT Service Continuity Plans. IT-jatkuvuussuunnitelma. (Hunnbeck et al., 2011).
ITSM IT Service Management. IT-palvelunhallinta. (ITSMF, 2014).
KB Knowledge Base. Tietämyskanta. (ITSMF, 2014).
KM Knowledge Management. Tietämyksenhallinta. (ITSMF, 2014).
KPI Key Performance Indicator. Keskeinen suorituskykymittari. (ITSMF, 2014).
KRI Key Risk Indicator. Avainriskimittari. (Davies et al., 2006).
M_o_R Management of Risk. Riskienhallinta. (Hunnbeck et al., 2011).
vii
ORA Operational Risk Assessment. Operationaalisten riskien arviointi.
(McKim, 2017).
PB Problem Management. Ongelmanhallinta. (ITSMF, 2014).
RA Risk Assessment. Riskien arviointi. (Hunnbeck et al., 2011).
RFC Request For Change. Muutospyyntö. (ITSMF, 2014).
RM Release Management. Jakelunhallinta. (ITSMF, 2014).
RM Risk Management. Riskienhallinta. (Hunnbeck et al., 2011).
SE Software Ecosystem. Ohjelmiston ekosysteemi. (Bosch, 2009).
SLA Service Level Agreement. Palvelutasosopimus. (ITSMF, 2014).
SLM Service Level Management. Palvelutasonhallinta. (ITSMF, 2014).
SPL Software Product Line. Ohjelmiston tuotantolinja. (Bosch, 2009).
SO Service Operation. Palvelutuotanto. (Mosimann, 2007).
viii
Sisällysluettelo
1 Johdanto ... 1
2 Konfiguraationhallinta IT-palvelunhallinnassa ... 4
2.1 Konfiguraationhallinnan ydinkäsitteet ... 7
2.1.1 Konfiguraatiomalli ... 7
2.1.2 Konfiguraationhallintajärjestelmä ... 8
2.1.3 Konfiguraatiotietokanta ... 9
2.1.4 Konfiguraation rakenneosa ja perustaso ... 10
2.1.5 Kriittiset menestystekijät ja suorituskykymittarit ... 11
2.1.6 Definitiivinen mediakirjasto ... 13
2.2 Konfiguraationhallinnan suunnittelu ja hallinta ... 14
2.3 Konfiguraationhallinnan tietokannat ... 16
2.4 Hyödyt muille palvelunhallintaprosesseille ... 21
2.5 Konfiguraationhallinnan haasteet ... 24
3 Riskienhallinta IT-palvelunhallinnassa ... 28
3.1 Riskienhallinnan ydinkäsitteet ... 29
3.1.1 Riskienhallinnan tehtävät ja tukitoimet liiketoiminnalle .. 30
3.1.2 Riskienhallintakomitea ... 31
3.1.3 Riskien arviointi ... 31
3.1.4 Komponentin vikaantumisen vaikutusanalyysi ... 33
3.1.5 Avainriskimittari ... 33
3.1.6 Liiketoiminnan vaikutusanalyysi ... 34
3.1.7 IT-jatkuvuussuunnitelma ... 35
3.1.8 Operationaalisten riskien arviointi ... 35
3.1.9 Kriittiset menestystekijät ja suorituskykymittarit ... 36
3.2 Riskienhallinnan suunnittelu ja hallinta ... 37
3.3 Riskienhallinnan hyödyt muille palvelunhallintaprosesseille ... 39
3.4 Riskienhallinnan haasteet ... 41
4 Tutkimusmenetelmät ... 44
4.1 Tutkimusasetelma ... 44
4.1.1 Tutkimusongelma ja tutkimuskysymykset ... 45
4.1.2 Tutkimusaineisto ... 46
4.1.3 Tutkimusmenetelmät ... 47
4.2 Savon Voima Oy ... 49
4.3 Tiedonkeruumenetelmät ... 51
4.4 Tiedon analysointi ... 53
5 Konfiguraationhallinnan hyödyt riskienhallinnalle ... 54
5.1 Konfiguraationhallinnan nykytilanne Savon Voima Oyj:llä ... 54
5.2 Konfiguraationhallinnan haasteet Savon Voima Oyj:ssä ... 56
5.3 Konfiguraationhallinnan kehitysideat ... 61
5.4 Riskienhallinnan nykytilanne Savon Voima Oyj:llä ... 63
5.5 Riskienhallinnan haasteet Savon Voima Oyj:llä ... 66
ix
5.6 Riskienhallinnan kehitysideat ... 68
5.7 Konfiguraationhallinnan hyödyt riskienhallinnalle ... 70
6 Pohdinta ja yhteenveto ... 77
Viitteet ... 81
Liite 1: Haastattelulomake ... 87
1
1 Johdanto
Konfiguraationhallinnan (Configuration Management, CM) tarkoituksena on tunnistaa ja ylläpitää kaikkien tunnistettujen palvelukomponenttien eheyttä.
Konfiguraationhallinnan hyötyjä ovat muun muassa se, että konfiguraationhallintaa tarvitsevat konfiguraation rakenneosat (Configuration Item, CI) tunnistetaan ja ne säilötään yhteen paikkaan, konfiguraatiotietokantaan (Configuration Management Database, CMDB). Kaikki toimenpiteet, jotka suoritetaan rakenneosille, on suoritettu kontrolloidusti (sama pätee myös tehtyihin muutoksiin). Konfiguraationhallinta takaa järjestelmien, palveluiden ja palvelukomponenttien oikeellisuuden ja julkaistujen omaisuuksien konfiguraatioiden hallinnan (ISO/IEC, 2012a).
Vaikka konfiguraationhallinta on kuvattu prosessina varsin kattavasti parhaiden IT- palveluiden hallinnan ja johtamisen käytäntöjen kokoelmassa (Information Technology Infrastructure Library, ITIL), sitä ei tulisi käyttää ainoana ohjenuorana.
Konfiguraationhallinta IT-palvelunhallinnassa (IT Service Management, ITSM) vaatii usein asioiden yhdistämistä monista eri viitekehyksistä, standardeista ja malleista.
Siksi organisaatioiden tulisi valita omiin tarpeisiinsa sopivimmat käytännöt.
Konfiguraationhallintaa kehittäessä voidaan hyödyntää mm. seuraavien viitekehysten ja standardien sisältämien osien yhdistämistä: ITIL, COBIT, ISO 20000 ja ISO 15504- 08. Lisäksi voidaan käyttää palvelunhallinnan ulkopuolisia standardeja ja parhaita käytäntöjä optimaalisen konfiguraationhallinnan saavuttamiseksi, kuten tuotteenhallinnan ja ohjelmistotekniikan käytäntöjä ja malleja (Sahibudin et al., 2008).
Hyvä esimerkki ulkopuolisesta parhaasta käytännöstä olisi ohjelmiston tuotantolinja (Software Product Line, SPL). Ohjelmiston tuotantolinjan tarkoituksena on rakentaa organisaation sisällä uudelleen käytettäviä komponentteja tuleviin ohjelmistoihin ja palveluihin. Täten ei työtä tarvitse aloittaa alusta vaan voidaan käyttää olemassa olevia komponentteja hyödyksi uuden kehitysprojektin alkaessa. Tämä metodi on mahdollistanut monien yritysten liikevaihdon positiivisen kasvun.
2
Kun organisaatio päättää laajentaa alustansa ulkopuolelle, siirtyy organisaatio ohjelmiston tuotantolinjasta ohjelmiston ekosysteemiksi (Software Ecosystem, SE).
Metodissa ohjelmistoa tai palvelua ei kehitetä pelkästään sisäisesti, vaan käytetään ulkoisia kehittäjiä näiden kehittämiseksi. ”Ekosysteemi” syntyy ohjelmiston tai palvelun luoneen organisaation tietoverkosta, ulkopuolisista kehittäjistä, jakelijoista ja kuluttajista. Sekä ohjelmiston tuotantolinja että ekosysteemi luovat organisaation tuotteille hyvän mahdollisuuden konfiguraation vaihtelevuuteen komponenttien jakamisen ja vapaan kehityksen takia. Syitä siirtyä ohjelmistojen ekosysteemiin ovat esimerkiksi organisaation havainnot siitä, että tiettyä tuotetta ei pystytä kehittämään tarpeeksi nopeasti tai tarpeeksi alhaisilla kustannuksilla organisaation sisällä sekä asiakkaiden tarve räätälöidä tuotteita (Bosch, 2009).
Hyvin toteutetun konfiguraationhallinnan avulla voidaan tunnistaa käytössä olevia IT- komponentteja, rakenneosien versioita ja käyttöaikoja, palvelutrendejä, rakenneosien päivitysten ja poistojen tarpeita, käytettyjä lisenssejä ja niitä koskevia tarpeita, päivitys/huoltotoimenpiteiden tarpeita sekä standardoinnin tiloja koskien koko IT- infrastruktuuria (Office of Government Commerce, 2005). Konfiguraationhallinnan käytännön tuloksia ovat CI-arkistot, auditointiraportit, CI-muutosten lokikirjat sekä CI-tilojen raportit, jotka saadaan luotua muutospyyntöarkistoista, julkaisujen muistiinpanoista sekä CI-auditointien aikatauluista (ISO/IEC, 2012a).
Riskienhallinnan (Risk Management, RM) tarkoituksena on jatkuvasti tunnistaa, analysoida, arvioida, käsitellä ja tarkkailla riskejä. Onnistuneen riskienhallinnan lopputuloksena riskit on tunnistettu, tunnistetut riskit on kategorisoitu, arvioitu ja priorisoitu, jotta resurssit osataan jakaa oikein korkeimman prioriteetin riskin hoitamiseksi. Riskit ja näiden hoito- ja ennaltaehkäisykeinot ilmoitetaan eteenpäin, arvioituja riskejä tarkkaillaan ja oikeanlaisia hoitokeinoja käytetään jotta vältytään pahimmilta arvioiduilta riskeiltä tai ne korjataan jo ennen kuin niistä muodostuu riski (ISO/IEC, 2012a). Kuten muidenkin IT-palvelunhallintaprosessien kohdalla, ei myöskään riskienhallintaa tulisi ottaa käyttöön yhden standardin tai käytännön pohjalta tai ainoana prosessina. Riskienhallinnan hyödyllisiä standardeja ja käytäntöjä ovat: ITIL, M_o_R, ISO 31000, ISO/IEC 27001 ja Risk IT (Hunnbeck et al., 2011).
3
Konfiguraationhallinnan aikaisemmat tutkimukset ovat keskittyneet konfiguraationhallinnan suunnitteluun (Ying et al., 2009), konfiguraationhallinnan yhdistämiseen COBIT:n ja ISO/IEC 27002 -standardin kanssa (Sahibudin et al., 2008) ja konfiguraationhallinnan käyttöönottamiseen (Klosterboer, 2007). Riskienhallinnan aikaisemmat tutkimukset ovat taas keskittyneet riskienhallinnan ja tiedonhallinnan (Knowledge Management, KM) yhteen integroimiseen (Thalmann et al., 2014), avainriskimittarien (Key Risk Indicators, KRI) rooliin operationaalisessa riskienhallinnassa (Davies et al., 2006) ja operationaalisten riskien arvioimiseen (Operational Risk Assessment, ORA) (McKim, 2017).
Tämän tutkielman tavoitteena on kartoittaa konfiguraationhallinnan ja riskienhallinnan nykytilanteet, haasteet ja kehitysideat Savon Voima Oyj:llä sekä tunnistaa konfiguraationhallinnan hyödyt riskienhallinnan parantamiseksi. Tuloksena syntyi interventiokeinoja, jotka voidaan ottaa käyttöön organisaation sisällä, parantaen riskienhallintaprosessia. Tutkijan tavoitteena on parantaa Savon Voima Oyj:n ITSM- prosesseja luomalla uusia toimintatapoja organisaation sisällä. Tutkimuksen tavoitteena ei ole yleistävän teorian tai tutkimuksen luominen, vaan Savon Voima Oyj:lle tutkimuksen tekeminen tapaustutkimuksen keinoin.
Tutkielma koostuu johdannon lisäksi viidestä muusta luvusta. Luvussa 2 esitellään konfiguraationhallinnan teorialuku, luvussa 3 luodaan riskienhallinnan teorialuku, luvussa 4 määritetään tutkimusmenetelmät tälle tutkimukselle, luvussa 5 tutkitaan tapaustutkimuksen avulla konfiguraationhallinnan hyötyjä riskienhallinnalle ja luvussa 6 pohditaan tutkimuksen tuloksia, niiden vaikutuksia Savon Voima Oyj:n sisällä ja luodaan yhteenveto tutkimuksesta. Tutkimusprosessin tavoitteena on luoda interventiokeinoja, joilla konfiguraationhallinta voi tukea riskienhallintaa. Tutkimus on hyvin ainutlaatuinen, sillä konfiguraationhallinnan ja riskienhallinnan välisestä suhteesta ei ole tehty laajasti tutkimusta ja siksi, koska Savon Voima Oyj:n fyysisien komponenttien että IT-ympäristön voisi sanoa olevan hajautettu ja Savon Voima Oyj on myös ulkoistanut IT-palvelunhallintansa näin luoden varsin ainutlaatuisen toimintaympäristön tutkimuksen tekemistä varten.
4
2 Konfiguraationhallinta IT-palvelunhallinnassa
IT-palvelunhallinnassa konfiguraationhallinnan tarkoituksena on (Office of Government Commerce, 2007):
Tunnistaa ja hallita konfiguraatioiden rakenneosia sekä kaikkia niihin liittyviä olennaisia komponentteja ja suhteita.
Pitää kirjaa konfiguraatioiden rakenneosista sekä säilyttää rakenneosien oikeellisuutta koko palvelun elinkaaren ajan varmistaen, että vain oikeutettuja muutoksia tehdään ja oikeanlaisia komponentteja käytetään.
Suojella konfiguraatioiden rakenneosien oikeellisuutta koko palvelun elinkaaren ajan.
Varmistaa konfiguraatioiden oikeellisuus tarkalla ja eheällä konfiguraationhallintajärjestelmällä.
Konfiguraationhallinnan tavoitteina ovat virheettömät palveluiden konfiguraatiot;
konfiguraatioiden, kapasiteetin ja resurssien optimointi; tarkan konfiguraatiotiedon tarjoaminen oikeiden ratkaisujen tekemiseksi sekä liiketoiminnan ja asiakkaiden tavoitteiden tukeminen. Konfiguraationhallinnan päämäärinä ovat palveluiden ja IT- infrastruktuurin määrittäminen sekä kontrollin ja tarkan konfiguraatiotiedon ylläpitäminen näiden tukemiseksi (Office of Government Commerce, 2007).
Konfiguraationhallinnan alaisuuteen kuuluvat varmistukset siitä, että kaikki osa-alueet palvelusta, järjestelmästä tai tuotteesta on hallittu riittävän hyvin, jotta kaikki tehdyt muutokset ovat mahdollisimman kontrolloituja. Konfiguraationhallinta myös varmistaa, että kaikki julkaisut on tehty oikein. Se luo loogisen mallin kaikista palveluista, omaisuuksista ja infrastruktuurista pitämällä yllä tietoa niiden kaikkien suhteista toisiinsa (Office of Government Commerce, 2007). Kuvassa 1 on esitetty esimerkki loogisesta konfiguraatiomallista.
5
Kuva 1. Esimerkki loogisesta konfiguraatiomallista (Office of Government Commerce, 2007, mukaillen).
Konfiguraationhallinta tuo lisäarvoa liiketoiminnalle, sillä optimoimalla konfiguraatioita parannetaan yleistä palvelutasoa sekä samalla optimoidaan huonosti hallituista omaisuuksista johtuvia riskejä ja kuluja kuten palvelukatkoksia, sanktioita, ylimääräisiä lisenssimaksuja ja epäonnistuneita auditointeja. Vastaavasti konfiguraationhallinnan hyötyjä ovat muutosten ja julkaisujen parempi suunnittelu, ennustaminen ja julkaiseminen, häiriöiden ja ongelmien parempi ratkominen, palvelutasojen ja takuiden parempi toimitus sekä lakien, sääntöjen, velvollisuuksien ja standardien parempi noudattaminen. Hyvin toimivan konfiguraationhallinnan avulla muutokset ja jakelut voidaan tunnistaa, suunnitella ja toimittaa tuotantoon paremmin.
Muita lisähyötyjä ovat: palveluiden riittävän tason takaaminen, jäljitettävyys ja helpompi palveluiden hinnoittelu (Office of Government Commerce, 2007).
Konfiguraationhallinnan tavoitteena on tarjota luotettavaa ja ajantasaista tietoa IT- infrastruktuurista. Tämä tieto yleensä saadaan isojen IT-projektien tuotoksina. Tieto koostuu tarkoista konfiguraation rakenneosista sekä niiden välisistä yhteyksistä. CI- tietoa käytetään suunnitteluun, päätöksen tekemisen tukemiseksi ja muutosten
6
hallitsemiseksi. Nämä yhteydet luovat pohjan vaikuttavuuden arvioinnille, sillä konfiguraationhallinta tarkistaa, että IT-infrastruktuuriin tehdyt muutokset on tehty oikein ja valtuutetusti. Lisäksi konfiguraationhallinta varmistaa, että rakenneosien suhteet ja IT-komponenttien tilat on kirjattu oikein, minkä johdosta organisaatiolla on käytössään oikeat versiot kaikista sen rakenneosistaan (Office of Government Commerce, 2005; Bon, 2006).
Konfiguraationhallinnan hyötyjä ovat muun muassa (Office of Government Commerce, 2005):
IT-komponenttien parempi hallittavuus. Koska jokainen IT-palvelu koostuu yhdestä tai useammasta rakenneosasta, on tärkeää, että konfiguraationhallinta valvoo kaikkia sen ulottuvuuteen kuuluvia rakenneosia.
Laadukkaiden IT-palveluiden tarjoaminen asiakkaille.
Konfiguraationhallinta tukee käyttäjiä, helpottaa ongelmien tunnistamisessa ja korjaamisessa, muutosten käyttöönottamisessa sekä kaksoiskappaleiden vähentämisessä.
Toimiva ongelmien ratkominen. Konfiguraationhallinta toimii suurena apuna viallisten rakenneosien löytämisessä sekä hallitsee kaikkia viallisille rakenneosille tehtyjä muutoksia tai korvauksia.
Muutosten parempi käsittely. Konfiguraationhallinta luo pohjan toimivalle vaikutusanalyysille, joka taas vaikuttaa muutosten parempaan prosessointiin.
Laitteistojen ja ohjelmistojen parantunut kontrolli. Laitteisto- ja ohjelmistopakettien julkaisut voidaan yhdistää, jotta kokonaisuutta pystyttäisiin testaamaan etukäteen. Testaus- ja jakelusuunnitelmien luomisessa voidaan käyttää konfiguraatiotietokantaa hyödyksi. Lisäksi konfiguraatiotietokanta sisältää tietoa luotettavista ohjelmistojen versioista varmuuskopiointia varten.
Parempi turvallisuus. Tuotantoympäristössä olevia versioita hallinnoimalla saadaan tietoa rakenneosille tehdyistä oikeutetuista muutoksista sekä käytössä olevista ohjelmistoversioista. CI-tietoa voidaan myös käyttää hyödyksi lisenssien valvomisessa.
7
Laillisten vaatimusten noudattaminen. Auditoinneilla voidaan helposti tunnistaa ohjelmistojen laittomat kopiot, kun ohjelmistoja verrataan CMDB:ssä oleviin CI-tietoihin. Täten konfiguraationhallinta voi mahdollisesti estää uusien virusten pääsemisen organisaation sisälle. Lisäksi auditointi mahdollisesti vähentää laittomien ja saastuneiden ohjelmistojen pääsemistä organisaation sisälle työntekijöiden toimesta, kontrollin ja sanktioiden takia.
Kustannusten tarkempi suunnittelu. Konfiguraationhallinta voi auttaa kustannusten paremmassa suunnittelussa konfiguraatiotietokannassa olevan CI-tiedon avulla koskien esimerkiksi huoltokustannuksia, sopimuksia tai lisenssejä.
Tuki saatavuuden- ja kapasiteetinhallinnalle. Nämä prosessit luovat analyyseja ja edistävät palveluiden suunnittelua korrektin konfiguraatiotiedon avulla.
Pohja hyvälle IT-palveluiden jatkuvuudenhallinnalle. Katastrofin sattuessa konfiguraatiotietokannalla on tärkeä rooli palveluiden palautumisessa sekä palautumista vaativien rakenneosien löytämisessä.
2.1 Konfiguraationhallinnan ydinkäsitteet
Konfiguraationhallinta sisältää monia ydinkäsitteitä, jotka ovat tärkeitä ymmärtää, jotta saataisiin kokonaiskuva kyseisestä palvelunhallintaprosessista. Aliluvussa 2.1.1 käsitellään konfiguraatiomallia, aliluvussa 2.1.2 konfiguraationhallintajärjestelmää, aliluvussa 2.1.3 konfiguraatiotietokantaa, aliluvussa 2.1.4 konfiguraation rakenneosaa ja perustasoa, aliluvussa 2.1.5 kriittisiä menestystekijöitä ja suorituskykymittareita sekä aliluvussa 2.1.6 definitiivistä kirjastoa.
2.1.1 Konfiguraatiomalli
Konfiguraationhallinnan määränpäänä on luoda konfiguraatiomalleja (Configuration Model, CM) organisaation IT-infrastruktuurista sekä sen kaikista palveluista, omaisuuksista, rakenneosista ja näiden välisistä yhteyksistä. Konfiguraatiomalli taas vuorostaan tukee muita palvelunhallintaprosesseja taaten näille pääsyn tärkeään ja
8
oikeelliseen tietoon. Tätä tietoa taas käytetään hyödyksi esimerkiksi häiriöiden selvittämisessä, ongelmien syiden etsimisessä ja niiden vaikuttavuuden arvioinnissa, esitettyjen muutosten arvioimisessa, palveluiden muuttamisessa, uusien palveluiden luomisessa, teknologisissa uudistuksissa ja ohjelmistopäivityksissä.
Lisäksi konfiguraatiomalleja voidaan hyödyntää julkaisu- ja kehityspakettien luomisessa, palveluomaisuuksien siirtämisessä sekä omaisuuksien optimoimisessa.
Konfiguraationhallinta siis luo loogisen mallin organisaation infrastruktuurista ja kaikista sen palveluista joita muut IT-palvelunhallinnan osat sitten käyttävät (Office of Government Commerce, 2007).
2.1.2 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)
CSF
Ylläpidä IT-palvelun laatua
KPI #1
Kohdistettu prosenttimäärä ajallaan selvitettyjä häiriöitä prioriteetin mukaan
Mittari
Häiriöt, jotka on ratkaistu 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 IT-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
Muutoksenhallinta
Tuotantoympäristö IT-strategian
kehittäminen Liiketoiminnan
arvioiminen
Asiakkaiden hallinta
Palvelusuunnit- telu
Palvelutason- hallinta
Saatavuuden hallinta
Kapasiteetin hallinta
Kulujen hallinta
Häiriönhallinta Käyttöpalvelun hallinta
Ongelman hallinta
Rakenna ja testaa
Julkaise tuotantoon CMDB:n
datan päivitys CMDB-
kysely
Kustannus dataa CI-
attribuutit ja -suhteet
CI- attribuutit ja -suhteet
Työnumero Muutostietue
Kustannusdataa
Muutospyyntö Työnumeron
status
CMDB- kysely CMDB:n
datan päivitys
CMDB- kysely
CMDB:n datan päivitys
Kustannusdataa CI- attribuutit ja -suhteet
CI- attribuutit ja -suhteet Palvelun
mittaridataa
Kustannusdataa CMDB:n
datan päivitys
CMDB- kysely Resurssien
toimintakyvyn dataa Komponenttien
käyttödataa Palvelun toimintakyvyn
dataa CI- attribuutit ja -suhteet CMDB-
kysely CMDB:n
datan päivitys Kustannusdataa
Laukaisija Syöte/tuotos
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 automaatioteknologiat ja monimutkaisuuden tasot koskien niitä. Kaikkia näitä voidaan kontrolloida enemmän tai vähemmän, mutta varmaa on se, että jokainen muutos, joka tapahtuu IT-ympäristössä, tulee olla kirjattuna konfiguraatiotietokantaan (Klosterboer, 2007).
Epäonnistumiset työkalujen integroimisessa. On olemassa hyviä laitteistoja ja ohjelmistoja löytäviä työkaluja sekä integroituja työkaluja, jotka mahdollistavat häiriö- ja muutosrekisterien linkittämisen konfiguraatiorekistereihin. Haaste työkaluihin liittyen on siinä, että pitäisi löytää tai rakentaa työkalu, joka löytää tietoa, siirtää sen varastoon, linkittää sen muiden palvelunhallintaprosessien tietoihin ja mahdollistaa sen noutamisen ja visualisoinnin varastosta. Ongelma siis on siinä, että on tarve suodattaa löydettyä tietoa sekä samalla liittää se löytämättömään tietoon.
Lisäksi turvallisuuskysymykset nousevat näiden työkalujen haasteiksi. Kuinka saada tietoa laitteistoista ja ohjelmistoista koko organisaation kautta, jos palomuurit estävät työkaluja toimimasta tiettyyn pisteeseen asti näin ollen estäen tiedon siirtymistä muihin organisaation osiin. On äärimmäisen tärkeää että organisaatio valitsee käytettävät työkalunsa varovaisesti, tietäen tasan tarkkaan mikä näiden työkalujen funktionaalisuus on ja mitä rajoituksia niillä on (Klosterboer, 2007).
Manuaaliset attribuutit. Manuaalisten attribuuttien käyttämistä tulisi välttää, jos vain mahdollista, koska niiden ylläpitäminen voi vaatia liikaa panosta sekä samalla avautuu mahdollisuus tehdä inhimillisiä virheitä, joita voi olla vaikea huomata. Kaikki manuaalisesti täytetyt attribuutit tulisi merkata epäilyttäväksi ja niitä tulisi auditoida usein, jotta saavutettaisiin mahdollisimman pieni virheellisyys.
Konfiguraatiotietokannan suurimpia virheellisiä tietueita ovat juuri manuaalisesti
27
täytetyt attribuutit, joten niiden määrä pitäisi pitää mahdollisimman vähäisenä (Klosterboer, 2007).
Muita haasteita konfiguraationhallinnan suorittamisessa voi olla muun muassa ihmisten vakuuttaminen siitä, että he eivät voi kiertää konfiguraationhallintaprosesseja (esimerkiksi lataamalla luvattomia ohjelmia työkoneelle tai laiminlyömällä konfiguraatioiden attribuuttien täyttämistä), riittävien taloudellisten resurssien saaminen, tiedon liiallisen määrän kerääminen (koska sitä on saatavilla paljon) sekä johdon hyväksyntä ja tuki liittyen konfiguraationhallinnan käyttöönottamiseen ja suorittamiseen (Bon et al., 2007). Lisäksi haasteita luovat heterogeenisen infrastruktuurin ja pilviympäristön hajauttava vaikutus (koska infrastruktuuri on hajautettu, tarkoittaa tämä useita eri käyttöjärjestelmiä, laitteistoja ja ohjelmistoja, jotka taas vaativat omia hallintatyökalujaan ja asiantuntijoitaan) sekä järjestelmien ylläpitotiimien erikoistumisesta johtuva nopeuden ja tehokkuuden väheneminen (Komarek et al., 2015).
