19 suomalaisyrityksessä tehdyt DevOps-arvioinnit osoittavat, etteivät edes yleisesti käytetyt DevOps-käytännöt ole vielä kovin yleisiä. Toimiala on silti etenemässä oikeaan suuntaan DevOpsin käyttöönotossa.
Paul Kuhalampi
Paul is a passionate Senior DevOps Consultant with a simple aim to step out of his comfort zone whenever possible. He enjoys orienteering, among other sports, as well as occasional travelling.
Tutkimaton elämä ei ole elämisen arvoista. DevOps-arviointi antaa yritykselle selkeän kuvan siitä, missä vaiheessa sen DevOpsin käyttöönotto on, mitä toimia tarvitaan ja missä järjestyksessä tavoitteisiin päästään.
Tämä analyysi perustuu 19 suomalaisessa yrityksessä vuosina 2016–2018 tehtyihin DevOps-arviointeihin. Yritykset toimivat seuraavilla aloilla: media, rakentaminen, raskas teollisuus, ohjelmistot, tietoliikenne, sähkö, lääketiede sekä terveydenhuolto ja eläkeala.
DevOps-arvioinnit toteutettiin osana Eficoden DevOps Development Plan -palvelua.
Mikä DevOps-arviointi on?
DevOps-arvioinnin tuloksena yritykselle laaditaan DevOps Development Plan, joka sisältää priorisoidut toimenpide-ehdotukset. Arviointi on kattava kartoitus yrityksen DevOps-kyvykkyyksistä. Siinä analysoidaan käytössä oleva teknologia, haastatellaan kehitystiimiä ja johtoa sekä tutkitaan prosesseja. Lopputuloksena on räätälöity roadmap analysoiduille tiimeille ja johdolle suunnatut ylemmän tason suositukset.
Arvioitavia DevOpsin keskeisiä osa-alueita ovat muun muassa:
Organisaatio
DevOpsissa on kyse siilojen purkamisesta. Ihannetilanteessa organisaatiorakenne mahdollistaa kehitysorganisaation kaikkien osa-alueiden yhteistyön, koska tiimit ovat monialaisia ja pystyvät toimimaan itsenäisesti.
Automaatio
Automaatio vähentää ihmisten tekemää työtä määrittelemällä kaiken koodina. Näin skriptit ja työkalut voivat hoitaa ohjelmistokehityksen toistuvat tehtävät, ja ihmiset voivat keskittyä arvon luomiseen. Automatisoidut prosessit voivat myös muuntaa asiakaspalautteen, kehitysmetriikat, laadunvarmistuksen, liiketoiminta-arvoa koskevat tiedot ja muut datan merkityksellisiksi koontinäytöiksi.
Prosessit
Ohjelmistokehitysmenetelmät on optimoitu, ja hukkaa syntyy mahdollisimman vähän. Kehitys ja käyttöönotto sujuvat kitkattomasti. Uusien versioiden päivittäminen ja vanhaan versioon palauttaminen on helppoa.
Kulttuuri
Kokeileminen kannustaa uusiin toimintatapoihin, ja uusien ideoiden ehdottamisen kynnys on matala. Viestintä johdon kanssa on avointa ja mutkatonta, ja jokainen virhe nähdään oppimismahdollisuutena.
Jokainen näistä osa-alueista kattaa suuren määrän käytäntöjä, kuten muuttumattomat palvelinympäristöt, automatisoidun laadunvarmistuksen, tuotteen päästä päähän -vastuun sekä eri tiimien välisen hämmennyksen muurin purkamisen.
Osa käytännöistä on ollut laajasti käytössä IT-alalla jo vuosikymmeniä, kun taas osa syntyi vasta muutama vuosi sitten. Paras tilanne saavutetaan, kun käytäntö juurtuu syvälle päivittäiseen työhön.
Kuinka laajasti DevOps-käytäntöjä oli otettu käyttöön 19 suomalaisessa yrityksessä?
Tutkimukseni osoitti, että edes kaikkialla itsestään selvinä pidettyjä käytäntöjä, kuten versionhallintaa ja helposti saatavilla olevaa dokumentaatiota, ei käytetä kaikkialla.
Yhteenveto 19 DevOps-arvioinnista
Kuva 1: Yhteenveto analysoiduista DevOps-arvioinneista
Arvioitujen yritysten DevOps-kypsyydessä oli selviä eroja. (Katso kypsyysarviot kahdesta viimeisestä sarakkeesta.)
Yleisimmät DevOps-käytännöt
Yleisimmin käytettyjä käytäntöjä ovat versionhallinta (12:ssa 19 yrityksestä) ja Scrum-käytännöt (10:ssä 19 yrityksestä). Molemmat ovat olleet merkittävä osa modernia ohjelmistokehitystä jopa pidempään kuin DevOps-käsite on ollut olemassa (termi DevOps otettiin käyttöön vuonna 2009).
Kohtalaisen yleisiä DevOpsille ominaisia käytäntöjä olivat versionhallinnan commitien käynnistämä Continuous Integration -alusta sekä kokeilukulttuuri. Molemmat havaittiin noin kolmanneksessa yrityksistä.
Puutteita DevOps-käytännöissä: laadunvarmistus
Laadunvarmistuksen automatisointi sekä laadun sisäänrakentaminen laatupoorteilla ja koodauskäytännöillä on erittäin tärkeä askel. Se mahdollistaa DevOpsin lupaaman nopeuden ja laadun.
Huomasin silti, että vain harvat organisaatiot todella käyttivät näitä käytäntöjä. Suurin osa testauksesta ja koodin validoinnista tehtiin edelleen manuaalisesti, jolloin ne olivat alttiita inhimillisille virheille.
Eniten havaintoja tehtiin QA-kategoriassa
Kuva 2: Koodiryhmien kokonaismäärät kussakin koodin kypsyysmallin kategoriassa. Ehdotukset, keltainen: Eficoden arvioinnin aikana tekemät ehdotukset. Hyvällä mallilla, vihreä: asiat, joiden todettiin olevan hyvällä mallilla arvioinnin aikana. Nykytila, sininen: ongelmakategorian ja hyvällä mallilla -kategorian yhteenlaskettu määrä, joka kuvaa asioita, joiden parissa tällä hetkellä työskennellään.
Tästä näet, että eniten havaintoja tehtiin QA-kategoriassa.
Arviointien jälkeen QA-kategoriassa tehtiin kuitenkin vähiten toimenpiteitä
Alla oleva kuvaaja ei käsittele itse arviointeja. Se perustuu sen sijaan haastatteluihin, jotka toteutin hyvän aikaa arviointien jälkeen. Se näyttää, mihin arviointien osa-alueisiin oli tartuttu. Vihreä tarkoittaa, että toimenpide toteutettiin kokonaan.
Kuva 3: Kussakin kypsyysmallin kategoriassa toteutettujen ehdotusten määrä (perustuu jonkin ajan kuluttua arvioinnin jälkeen tehtyihin haastatteluihin). Kokonaan ja osittain toteutetut ehdotukset ovat osin päällekkäisiä, sillä jotkut haastateltavat totesivat, ettei ”mikään ole koskaan täysin valmista”, eivätkä siksi halunneet merkitä toteutuksia kokonaan valmiiksi.
Tässä kuvaajassa analysoidaan arvioinnin jälkeen toteutettuja toimenpiteitä. Mihin kategorioihin organisaatio on keskittynyt saatuaan DevOps Development Plan and Roadmapin?
Kuten näet, vaikka annoimme eniten ehdotuksia QA-kategoriaan, siinä on edistytty vähiten kaikista osa-alueista.
Tämä voi johtua siitä, että muut kategoriat on helpompi toteuttaa. Päädyin siihen johtopäätökseen, että muissa kategorioissa oli enemmän helposti saavutettavia hyötyjä, kun taas QA-kategoria sisälsi ehdotuksia, joiden toteuttaminen vaatii paljon resursseja. Kun kuitenkin ottaa huomioon, miten tärkeää laatu on ohjelmistoille kautta linjan, johtopäätös on huolestuttava.
Kokonaisvaltaiset DevOps-muutokset eivät koostu pelkästään nopeista voitoista ja ad hoc -ratkaisuista, vaan niissä on pidettävä kokonaiskuva mielessä. Vain siten DevOpsin hyödyt voidaan saavuttaa osana organisaation päivittäistä toimintaa.
Toimialojen väliset erot
Vertailin myös ohjelmistoalalla toimivia organisaatioita muihin toimialoihin.
Kuva 4: Ongelmakoodien keskimääräinen määrä toimialoittain. Y-akselilla mainitut ”koodit” viittaavat open coding/axial coding -nimiseen data-analyysimenetelmään, jossa data pilkotaan osiin ja etsitään toistuvia käsitteitä. Menetelmä auttaa hahmottamaan käsitteiden ja kategorioiden välisiä yhteyksiä.
Tässä näemme, että ohjelmistoyritykset suoriutuvat QA:ssa heikommin kuin muut toimialat. Kun ohjelmisto on yrityksen päätoimiala, painopiste on mahdollisimman nopeassa toimituksessa, jolloin QA-näkökohdat voivat jäädä sivuun. Testauskäytännöt eivät välttämättä kehity samaa tahtia muiden nopeutta lisäävien tekijöiden kanssa.
Toisaalta esimerkiksi terveydenhuolto- tai kaivosteollisuudessa ohjelmistoja ei tarvitse päivittää yhtä usein. Tuotteiden elinkaaret ovat pidempiä, joten aikaa jää parempien laatupoorttien ja käytäntöjen kehittämiseen.
Ero näkyy myös ympäristöjen ja julkaisujen kategoriassa. Ohjelmistoyritykset ovat tässä edellä, sillä vakaan ja nopeasti kehittyvän ohjelmiston rakentaminen edellyttää vahvaa perustaa, joka syntyy vakaista ympäristöistä ja julkaisusykleistä. Jos yritys pitää ohjelmistoaan edelleen toissijaisena tuotteena, se saattaa tulla toimeen vanhentuneella infrastruktuurilla.
DevOps kokonaisuutena ei ole yhtä yleinen kuin sen osat
DevOps-arvioinnit osoittavat, että DevOps kokonaisuutena ei ole yhtä yleinen kuin sen yksittäiset osat. On epäselvää, pyrkivätkö yritykset kokonaisvaltaiseen DevOps-muutokseen, joka edellyttää syvällistä kulttuurista yhteistyötä koko organisaatiossa, vai valitsevatko ne sen sijaan vaiheittaisia ad hoc -muutoksia.
Yhden työkalun käyttöönotto ei tuo kaikkia DevOpsin lupaamia hyötyjä. Tämä voi olla itsestäänselvyys, mutta jatkuvat pienet muutokset parantavat ohjelmistokehityksen tehokkuutta tasaisesti.
Miksi yritykset teettivät DevOps-arvioinnin?
Organisaatioiden syyt DevOps-käytäntöjensä arviointiin vaihtelivat. Yleisin syy oli tarve skaalata toimintaa sekä kasvattaa nopeutta ja laatua. Erään yrityksen CTO kertoi, että organisaation oli kasvettava ja että he halusivat varmistaa nykyisten ohjelmistokehityskäytäntöjensä skaalautuvuuden.
Millaista DevOps-arviointiin osallistuminen on?
Arvioinnista jäi hyvä jälkimaku, ja se antoi tiimin työnkululle vauhtia. Saimme etsimämme eli ulkopuolisen näkökulman käytäntöihimme. Se vahvisti uskoa siihen, että tapamme toimia on menossa oikeaan suuntaan.
Kaikki haastatellut yritysten edustajat kokivat DevOps-arvioinnit hyödyllisiksi.
Arviointien tavoitteena on tarjota rehellinen ja totuudenmukainen yleiskuva arvioidun organisaation tilanteesta.
Kun tulokset valmistuivat ja ne käytiin läpi, ne olivat todella ”raakarehellisiä”. Tuloksia ei kaunisteltu lainkaan, minkä ansiosta ymmärsimme, että organisaatio on vasta hyvien ohjelmistokehityskäytäntöjen alkuvaiheessa.
DevOps-käytännöt ovat yleisesti ottaen yleistymässä, ja kaikki 19 haastattelemaani suomalaista yritystä kokivat DevOpsin hyödylliseksi. Oli rohkaisevaa nähdä, että arvioidut yritykset toteuttivat suositeltuja toimenpiteitä.
Tämä kirjoitus perustuu vuonna 2018 tekemääni pro gradu -tutkielmaan.
- DevOps
Subscribe to our newsletter
Related blogs
