DevOps on termi, josta puhutaan nykyaikana paljon. Maailman muuttuessa se nähdään mahdollistajana pärjätä tulevaisuudessa. Mutta mitä se pitää sisällään? DevOpsille ei ole olemassa yhtä virallista määritelmää ja etsimällä voikin löytää useita teemoja ja periaatteita aiheen ympäriltä. Käymme tässä blogissa läpi DevOpsin eri näkökulmat yhdestä kuuteen ja lopussa kerromme oman näkemyksemme DevOps-matkan alkuaskelista.
Yksi termi - DevOps
DevOps muodostuu sanoista development (kehitys) ja operations (tuotannon operointi) ja niillä on perinteisesti tarkoitettu IT-kehityksen kahtiajakoa; kehitys haluaa viedä tuotantoon uusia ominaisuuksia ja tuotannon operointi haluaa pitää tuotantoympäristön vakaana. Tästä kahtiajaosta on muodostunut kitkaa ja byrokratiaa, joka on hidastanut ja monimutkaistanut tehtävien valmistumista ja arvon saamista asiakkaalle. DevOps pyrkii poistamaan näitä raja-aitoja ja saamaan kaikki puhaltamaan yhteen hiileen. Nykyisin ajattelu on laajentunut kattamaan myös liiketoiminnan, tietoturvan ja monet muut asiakasarvon tuottamiseen sisältyvät toiminnot. Ei siis puhuta enää puhtaasti IT-osaston toiminnasta vaan DevOpsin toimintamalleista hyötyvät kaikki.
Kaksi lyhennettä
Yksi tunnetuimmista näkökulmista DevOpsiin on CALMS joka palastelee DevOpsin erilaisiin teemoihin (kulttuuri, automaatio, lean, mittaus, jakaminen). Tässä näkökulmassa korostetaan arvon tuottoa asiakkaalle, työn virtauksen parantamista läpi organisaation, tiedon jakamista sekä yhteistyötä ja turvallista jatkuvan oppimisen kulttuuria. Tätä tuetaan työn ja kehityksen automatisoinnilla ja mielekkäällä visualisoidulla mittaroinnilla, jotka tukevat päivittäistä työtä ja jatkuvaa parantamista. Scaled Agile Framework on muokannut lyhennettä muotoon CALMR. Siinä jakaminen on osa kulttuuria ja mittaamista, jolloin viitekehyksessä on nähty tärkeämpänä korostaa nopeaa toipumiskykyä ongelmatilanteista ja vähäriskisiä julkaisuja.
Kolme tapaa
DevOpsin kolme tapaa on tiivistelmä ylätason tavoitteista joihin DevOpsilla pyritään. Tämän ajattelutavan mukaisesti pitää ensin optimoida työn virtaus eli saada kehitysideat kulkemaan mahdollisimman sujuvasti kehityksen läpi tuotantoon asiakkaiden käytettäväksi. Sen jälkeen yritetään nopeuttaa oppimista eli palautesyklejä prosessin sisällä ja loppuasiakkaalta. Ja lopuksi tavoitellaan toimintaympäristöä, jossa on turvallista tehdä kokeiluja ja ottaa riskejä, sekä annetaan aikaa oman työn parantamiselle. Näkökulma antaa hyvän ohjenuoran sille mistä kannattaa lähteä liikkeelle DevOps tekemisessä: ymmärrä ja visualisoi nykyinen työ ja kokonaiskuva sekä paranna työn virtausta. Lisää tietoa tästä lähestymistavasta löytyy kirjoista Phoenix Project ja DevOps Handbook.
Neljä pilaria
Neljä pilaria on Effective DevOps -kirjan näkökulma tehokkaaseen DevOpsiin. Ensimmäisissä pilareissa keskitytään ihmisten väliseen toimintaan. Yhteistyön onnistuminen vaatii ihmisten välistä yhteenkuuluvuuden tunnetta, empaattisuutta ja luottamusta. Nämä luovat pohjan seuraavalle pilarille - työkaluille. Jos otetaan käyttöön vain työkaluja eikä huolehdita yhteisen tekemisen kulttuurista, menetetään tehokkuutta ja nopeutta, jota DevOpsilla usein tavoitellaan. Viimeisenä pilarina on toiminnan skaalaaminen eli yhteistyön, yhteenkuuluvuuden ja työkalujen käyttö laajemmin eri puolilla organisaatiota sen elinkaaren eri vaiheissa.
Viisi ihannetta
Viisi ihannetta on jatkojalostettu versio kolmesta tavasta ja se on esitelty Phoenix Project -kirjan sisarkirjassa Unicorn Project. Tämän ajattelutavan mukaisesti järjestelmät, prosessit ja organisaatiot on rakennettava niin, että ne ovat mahdollisimman yksinkertaisia ja toisistaan riippumattomia. Sen jälkeen voidaan keskittyä työn ja sen virtauksen parantamiseen turvallisessa työympäristössä, jossa ongelmista voidaan keskustella avoimesti. Asiakaskeskeisyys tässä tarkoittaa sitä, että suurin panostus pitää laittaa organisaation omille asiakkaille suoraa asiakasarvoa tuottaviin järjestelmiin ja muut, kuten esimerkiksi HR-järjestelmät, voidaan ulkoistaa toisille toimijoille. Viisi ihannetta nostaa esiin myös tärkeät onnistumista tukevat osa-alueet, joiden tärkeyttä ei aina muisteta: ilo, päivittäisen työn parantaminen ja psykologinen turvallisuus.
Kuusi periaatetta
DevOps Agile Skills Associationin (DASA) näkökulma DevOpsiin juontaa organisaatioihin, niiden haasteisiin ja niissä työskenteleviin ihmisiin sekä miltä DevOps näyttää katsottaessa näiden yksilöiden päivittäistä työtä. Periaatteet lähtevät arvon tuottamisesta asiakkaalle ja päätyvät tuottavuuden parantamiseen automatisoinnin avulla. Onnistumiseen tarvitaan asiakaskeskeisyyttä, yhteistä päämäärää ja vastuunottoa kokonaisuudesta. Tarvitaan myös näitä tukevat ketterät tiimit, lyhyet palautesyklit ja jatkuva parantaminen. Automatisointi on tarkoituksella periaatteiden viimeisenä, sillä ilman muiden periaatteiden tukea työkaluista ei saada parasta tehokkuutta irti.
Yhteenveto
DevOps on paljon muutakin, kuin ohjelmiston testauksen, kokoonpanon ja julkaisun automatisointia. Jos keskitytään vain työkaluihin ja unohdetaan yrityksen kulttuuri ja ihmiset, ei voida saavuttaa kaikkia DevOps-ajattelun mahdollistamia hyötyjä. Koska ohjelmistokehitysputken automatisointi on vain pieni osa DevOpsia, on hyvä huomata, että sen periaatteita voi hyödyntää helposti myös muissa toiminnoissa.
Mutta mistä kannattaa lähteä liikkeelle? Tärkeintä on kirkastaa ensin mihin DevOpsin käyttöönotolla pyritään. Yritys, joka arvostaa kustannusten ja resurssien tehokkuutta, lähtee liikkeelle eri DevOpsin osa-alueista kuin yritys, joka arvostaa nopeaa arvontuottoa asiakkaalle. Lähtökohdista riippumatta on kuitenkin aina ymmärrettävä matkan määränpää, nykytilan kokonaiskuva, kipupisteet ja pullonkaulat. Näiden jälkeen voidaan tavoitetta kohti kulkea askel kerrallaan, palautesyklien ja oppimisen kautta.
