19 suomalaisyrityksessä tehdyt DevOps-arvioinnit osoittavat, että edes yleisesti tunnetut DevOps-käytännöt eivät ole vielä kovin laajassa käytössä. Toimiala on kuitenkin 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ä toimenpiteitä tarvitaan ja missä järjestyksessä, jotta tavoitteisiin päästään.
Tämä analyysi perustuu 19 suomalaisessa yrityksessä vuosina 2016–2018 tehtyihin DevOps-arviointeihin. Yritykset toimivat seuraavilla toimialoilla: media, rakentaminen, raskas teollisuus, ohjelmistot, tietoliikenne, sähkö, lääketiede sekä terveydenhuolto/eläkeala.
DevOps-arvioinnit tehtiin osana Eficoden DevOps Development Plan -palvelua.
Ensiksi: mikä DevOps-arviointi on?
DevOps-arvioinnin tuloksena syntyy yritykselle DevOps Development Plan, joka sisältää priorisoidut toimenpide-ehdotukset. Arviointi on kokonaisvaltainen kartoitus yrityksen DevOps-kyvykkyyksistä. Siinä analysoidaan käytössä olevaa teknologiaa, haastatellaan kehitystiimiä ja johtoa sekä tutkitaan prosesseja. Lopputuloksena on analysoiduille tiimeille räätälöity tiekartta ja yrityksen johdolle ylemmän tason suositukset.
Arvioitavia DevOpsin peruspilareita ovat muun muassa:
Organisaatio
DevOpsissa on kyse siilojen purkamisesta. Parhaassa tapauksessa organisaatiorakenne mahdollistaa kehitysorganisaation kaikkien osa-alueiden yhteistyön, sillä tiimit ovat monialaisia ja pystyvät työskentelemään itsenäisesti.
Automaatio
Automaatio vähentää ihmisten manuaalista työtä määrittelemällä kaiken koodina. Tällöin skriptit ja työkalut voivat hoitaa ohjelmistokehityksen toistuvat osat, ja ihmiset voivat keskittyä arvon luomiseen. Automatisoidut prosessit voivat myös muuntaa asiakaspalautteen, kehitysmetriikat, laadunvarmistuksen, liiketoiminta-arvoa koskevat tiedot ja muut datan merkityksellisiksi näkymiksi.
Prosessit
Ohjelmistokehitysmenetelmät on optimoitu ja hukkaa syntyy mahdollisimman vähän. Kehitys ja käyttöönotto sujuvat kitkattomasti. Uusien versioiden käyttöönotto ja vanhaan versioon palauttaminen on helppoa.
Kulttuuri
Kokeileminen kannustaa uusiin työskentelytapoihin, ja uusien ideoiden esittämisen kynnys on matala. Viestintä johdon kanssa on avointa ja mutkatonta, ja jokainen virhe nähdään oppimismahdollisuutena.
Jokainen näistä kategorioista 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 epäselvyyden muurin purkamisen.
Osa käytännöistä on ollut IT-alalla laajassa käytössä jo vuosikymmeniä, kun taas osa syntyi vasta muutama vuosi sitten. Parhaassa tapauksessa 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 joillekin itsestään selvät käytännöt, kuten versionhallinta ja helposti saatavilla oleva dokumentaatio, eivät ole käytössä 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
Käytetyimpiä käytäntöjä ovat versionhallinta (12:ssa yrityksessä 19:stä) ja Scrum-käytännöt (10:ssä yrityksessä 19:stä). Molemmat käytännöt ovat olleet merkittävä osa modernia ohjelmistokehitystä jopa pidempään kuin DevOps-konsepti on ollut olemassa (termi DevOps lanseerattiin vuonna 2009).
Kohtalaisen yleisiä DevOpsille ominaisia käytäntöjä olivat versionhallinnan commitien käynnistämä Continuous Integration -alusta sekä kokeilukulttuuri. Molempia havaittiin noin kolmanneksessa yrityksistä.
Puutteita DevOps-käytännöissä: laadunvarmistus
Laadunvarmistuksen automatisointi sekä laadun rakentaminen osaksi kehitystä laatupoorteilla ja koodauskäytännöillä on erittäin tärkeä vaihe. Se mahdollistaa DevOpsin lupaaman nopeuden ja laadun.
Huomasin kuitenkin, että vain harvat organisaatiot todella käyttivät näitä käytäntöjä. Suurin osa testauksesta ja koodin validoinnista tehtiin edelleen manuaalisesti, mikä altistaa inhimillisille virheille.
Eniten havaintoja tehtiin QA-kategoriassa
Kuva 2: Koodiryhmien kokonaismäärä kussakin koodin kypsyysmallin kategoriassa. Ehdotukset, keltainen: Eficoden arvioinnin aikana esittämät ehdotukset. Tavoitteessa, vihreä: arvioinnissa tavoitteessa oleviksi todetut asiat. Nykytila, sininen: ongelmakategorian ja tavoitteessa olevan kategorian yhteenlaskettu määrä, joka kuvaa parhaillaan työstettäviä asioita.
Tästä näet, että eniten havaintoja tehtiin QA-kategoriassa.
Arviointien jälkeen QA-kategoriassa tehtiin kuitenkin vähiten toimenpiteitä
Alla oleva kaavio ei koske arviointeja itseään, vaan perustuu haastatteluihin, jotka tein hyvän aikaa arviointien jälkeen. Se näyttää, mihin arviointien osa-alueisiin ryhdyttiin toimenpiteisiin. Vihreä tarkoittaa, että toimenpide toteutettiin kokonaan.
Kuva 3: Toteutettujen ehdotusten määrä kussakin kypsyysmallin kategoriassa (perustuu jonkin aikaa arvioinnin jälkeen tehtyihin haastatteluihin). Kokonaan ja osittain toteutetut ehdotukset ovat osittain keskenään vaihtokelpoisia, sillä jotkut haastateltavat totesivat, ettei ”mikään ole koskaan täysin valmista”, eivätkä siksi halunneet merkitä toteutuksia kokonaan tehdyiksi.
Tässä kaaviossa tarkastellaan arvioinnin jälkeen tehtyjä toimenpiteitä. Mihin kategorioihin organisaatio on keskittynyt saatuaan DevOps Development Planin ja Roadmapin?
Kuten näet, vaikka annoimme eniten ehdotuksia QA-kategoriaan, siinä on edistytty vähiten kaikista osa-alueista.
Tämä voi johtua siitä, että muiden kategorioiden toimenpiteet on helpompi toteuttaa. Päädyin siihen johtopäätökseen, että muissa kategorioissa oli enemmän helposti saavutettavia hyötyjä, kun taas QA-kategorian ehdotukset vaativat toteuttamiseen paljon resursseja. Kun ottaa huomioon, kuinka tärkeää laatu on ohjelmistoille kaikilla osa-alueilla, johtopäätös on huolestuttava.
Kokonaisvaltainen DevOps-transformaatio ei koostu pelkästään nopeista voitoista ja ad hoc -ratkaisuista, vaan siinä 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 muilla toimialoilla toimiviin organisaatioihin.
Kuva 4: Ongelmakoodien keskimääräinen määrä toimialoittain. Y-akselilla mainitut ”koodit” viittaavat avoimeksi koodaukseksi/aksiaaliseksi koodaukseksi kutsuttuun data-analyysimenetelmään, jossa data pilkotaan osiin ja tunnistetaan toistuvia käsitteitä. Tämä auttaa muodostamaan yhteyksiä käsitteiden ja kategorioiden välille.
Tässä näemme, että ohjelmistoyritykset suoriutuvat QA:ssa muita toimialoja heikommin. Kun ohjelmistot ovat toimialasi ydin, keskityt toimittamaan mahdollisimman nopeasti, jolloin QA-näkökohdat voivat jäädä taka-alalle. Testauskäytännöt eivät välttämättä kehity samaa vauhtia kuin muut nopeutta lisäävät tekijät.
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.
Eroja näkyy myös ympäristöjen ja julkaisujen kategoriassa. Ohjelmistoyritykset ovat tässä edellä, sillä vakaan ja nopeasti kehittyvän ohjelmiston luominen edellyttää vahvaa perustaa, jonka tarjoavat vakaa ympäristö ja julkaisusyklit. Jos yritys pitää ohjelmistoaan edelleen toissijaisena tuotteena, se saattaa tulla toimeen legacy-infrastruktuurilla.
DevOps kokonaisuutena ei ole yhtä yleinen kuin sen osat
DevOps-arvioinnit osoittavat, ettei DevOps kokonaisena käsitteenä ole yhtä yleinen kuin sen osat. On epäselvää, pyrkivätkö yritykset täysimittaiseen DevOps-transformaatioon, joka edellyttää syvällistä kulttuurista yhteistyötä koko organisaatiossa, vai valitsevatko ne sen sijaan ad hoc -luonteisia, vaiheittaisia muutoksia.
Yhden työkalun käyttöönotto ei tuo kaikkia DevOpsin lupaamia hyötyjä. Mutta – ja tämä voi olla itsestään selvää – kun pieniä muutoksia tehdään jatkuvasti, ohjelmistokehityksen tehokkuus paranee tasaisesti.
Miksi yritykset teettivät DevOps-arvioinnin?
Organisaatioiden syyt DevOps-käytäntöjensä arviointiin vaihtelivat. Yleisin syy oli kasvun skaalaaminen samalla, kun nopeutta ja laatua parannetaan. Erään yrityksen CTO kertoi, että organisaation piti kasvaa ja että he halusivat varmistaa nykyisten ohjelmistokehityskäytäntöjensä skaalautuvuuden.
Millaista DevOps-arviointiin osallistuminen on?
The audit left a good aftertaste and gave momentum to the team’s workflow. We gained what we were looking for, which was a viewpoint into our practices. It cemented the faith that our way of doing things was heading in the right direction.
Kaikki haastatellut yritysedustajat kokivat DevOps-arvioinnit hyödyllisiksi.
Arviointien tavoitteena on antaa rehellinen ja totuudenmukainen yleiskuva arvioitavan organisaation tilanteesta.
When the results came in and were reviewed, they really were on the "brutally honest" level. The results were not romanticised at all which allowed us to understand that the organisation is in early stages of good software development practices.
DevOps-käytännöt ovat yleisesti yleistymässä, ja kaikki 19 suomalaista yritystä, joiden kanssa keskustelin, pitivät DevOpsia hyödyllisenä. Oli rohkaisevaa nähdä, että arvioidut yritykset toteuttivat suositeltuja toimenpiteitä.
Tämä kirjoitus perustuu vuonna 2018 kirjoittamaani pro gradu -tutkielmaan.
- DevOps
Subscribe to our newsletter
Related blogs
