Mitä on DevOps?
DevOps on ohjelmistokehityksen käytäntöjä jotka auttavat organisaatioita mukautumaan markkinoiden tarpeisiin toimittamalla arvokasta ohjelmistoa nopeammin ja korkeammalla laadulla. Vaikka DevOpsiin liittyy monia teknisiä konsepteja, olisi virhe nähdä DevOps pelkästään teknologisena muutoksena. Suurimmat haasteet, joita yritykset kohtaavat DevOpsin yhteydessä, liittyvät usein organisaatioon ja kulttuuriin.
Innovaatio syntyy jakamisen, turvallisuuden ja riskinottamisen kulttuurissa – eikä mikään teknologiainvestointi voi korvata puutteellista kulttuuria. Johto ja johtoryhmät voivat sen sijaan kannustaa sellaiseen käyttäytymiseen joka edistää teknistä huippuosaamista, psykologista turvallisuutta ja jatkuvaa parantamista.
Lue Johan Abildskovin blogi aiheesta Mitä on DevOps.
Kulttuuri voittaa strategian joka kerta
Kuvittele itsesi seuraavaan tilanteeseen: organisaatiossa on juuri sattunut häiriötilanne, ja yrität selvittää, mikä meni pieleen. Sen sijaan, että etsisit syyllistä toisesta henkilöstä tai ryhmästä, keskity siihen, kuinka vastaavanlainen tilanne voidaan estää tulevaisuudessa.
Ron Westrum, joka on luonut organisaatiokulttuurien tyypittelyn, kuvaa organisaation kulttuurin olevan kuin yksilön persoonallisuus. Kuten persoonallisuus ohjaa yksilön käyttäytymistä, organisaation kulttuuri määrittää, miten ihmiset reagoivat haasteisiin ja mahdollisuuksiin. Suuret johtajat rakentavat järjestelmän, jossa kulttuuri voi kehittyä, ja ottavat aktiivisen roolin sen muokkaamisessa. Vaikka johto ei tietoisesti ohjaisi kulttuuria, järjestelmä muotoutuu palkintojen, rangaistusten, resurssien jakamisen ja symbolisten tekojen kautta.
Westrumin kulttuurityypitys ennustaa sekä ohjelmistojen toimituskykyä että liiketoiminnan tuloksia. Lisäksi sen mittaaminen on helppoa, mikä mahdollistaa konkreettisten toimenpiteiden johtamisen kyselytulosten perusteella – tehden siitä tehokkaan työkalun kulttuurimuutoksen ohjaamiseen oikeaan suuntaan.
Keskustelemme tästä yksityiskohtaisemmin yhdessä DevOps Sauna-podcastin jaksossa..
Oletko ketterä vain nimellisesti?
Ketteryydessä ohjelmistokehityksessä itsenäiset tiimit saavat valtuudet työskennellä itsenäisesti kohti yhteisiä tavoitteita. Tämä voi kuitenkin vaatia työtä, riippuen toimialastasi ja yrityksesi koosta. Usein organisaatiot palaavat hallitumpiin rakenteisiin alkuvaiheen Agile-innostuksen jälkeen. Jos näin on, kehitetäänkö ohjelmistosi todella ketterästi?
Kokemuksemme mukaan (josta olemme keskustelleet DevOps Sauna -podcastin jaksossa Miten ohjelmistokehityksen johtajat näkevät DevOpsin ja ketteryyden), ylimmällä johdolla on usein puutteellinen käsitys siitä, mitä ketteryys oikeasti tarkoittaa.
Ulkoisen tahon hyväksyntä ei aina ole paras tapa edetä, sillä lisääntyvä kontrolli ja riskienhallinta voivat vähentää innovaatiota ja tuottavuutta. Tiukasti säännellyillä aloilla merkittävät muutokset toimintoihin eivät usein johda nopeuteen ja laatuun. Muutoshyväksyntäprosessit monimutkaistuvat ajan myötä, mikä pidentää palautesyklejä ja hidastaa markkinoille pääsyä.
DevOpsin ansiosta muutoshyväksyntälautakunnat (CAB:t) voivat tänä päivänä valmentaa ja laatia strategioita paremmin kuin aiemmin. CAB:n tulisi myös varmistaa, että prosessi on läpinäkyvä ja keskittyy optimoimaan toimintaa, jotta asiakkaille voidaan tuottaa arvoa tehokkaammin.
Konsolidoi työkalut alustatiimien avulla
Useiden järjestelmien kautta lippujen ja vaatimusten hallinta lisää ylimääräistä työtä ja aiheuttaa ongelmia, kuten virheitä, uudelleentyöstämistä ja epäjohdonmukaisuuksia. Tämän ratkaisemiseksi vaatimusten tulisi toimia yhdistävänä tekijänä, joka linkittää liiketoimintatavoitteet ja sitouttaa kaikki sidosryhmät. Vaatimusten tehokas integrointi lisää läpinäkyvyyttä tuotekehitysprosesseissa.
Avain on yhdistää liiketoimintamittarit vaatimustenhallinnan työnkulkuun, mikä voidaan saavuttaa konsolidoimalla työkalut alustatiimin avulla, joko omassa organisaatiossa tai palveluna. Seuraamalla vaatimuksia joka vaiheessa julkaisuun asti DevOpsin automaatio ja muut edut tulevat selkeämmin esille mittareiden kautta. Lisäksi jäljitettävyyden huomioiminen etukäteen tukee suunnitelmallisesti auditointeja ja säädösten noudattamista, tarjoten vankan kehyksen tarvittavien standardien ja määräysten täyttämiseksi.
Lue lisää alustatiimien roolista organisaatiossasi ja alustakehityksestä yleisesti alustakehityksen oppaastamme.
Dataohjautuvuus on mielentila
DevOps tekee liiketoimintamittarien yhdistämisestä insinööriosaston työhön huomattavasti yksinkertaisempaa. Tämä on tärkeää, sillä et voi parantaa jotain, mitä et pysty näkemään. Data on arvokasta vain, jos se johtaa toimenpiteisiin, ja oikean kielenkäytön avulla dataohjautuva päätöksenteko voi ohjata yritystä oikeaan suuntaan.
Esimerkiksi:
“Tee OSTA-painikkeesta vaaleanpunainen, jotta se kiinnittää enemmän huomiota ja kasvattaa myyntiä.”
Sen sijaan suosi hypoteesiksi muotoiltuja väittämiä, kuten:
“Uskomme, että tekemällä OSTA-painikkeesta vaaleanpunaisen, se kiinnittää enemmän huomiota ja kasvattaa myyntiä.”
Tämä selventää, että kyseessä on kokeilu: meidän on mitattava, validoitava ja päätettävä, mitä haluamme säilyttää. Vaaleanpunainen painike saattaa jostain tuntemattomasta syystä jopa laskea myyntiä, mutta ilman dataohjautuvaa ajattelutapaa emme voi tietää, mikä ongelman aiheutti.
Kuuntele lisää aiheesta DevOps Sauna -podcastimme jaksosta, jossa käsittelemme, kuinka DevOps voi olla avain nopeuden ja skaalautuvuuden parantamiseen.
Tavoittele jatkuvaa toimitusta kaikessa mitä teet
Jatkuva toimitus koostuu joukosta teknisiä käytäntöjä, joiden tavoitteena on toimittaa muutoksia käyttäjille turvallisesti, nopeasti ja kestävästi. Se keskittyy ohjelmistoarkkitehtuuriin, automaatioon ja terveiden teknisten käytäntöjen edistämiseen.
Automaatiolla on keskeinen rooli jatkuvassa toimituksessa – olipa kyse testauksesta, käyttöönotosta tai rakennusprosesseista. Tavoitteena on vähentää toistuvia tehtäviä, antaa insinööreille enemmän valtaa ja tietotaitoa sekä parantaa työtyytyväisyyttä. On kuitenkin tärkeää muistaa, että vaikka automaatio on tehokasta, se voi lisätä työkuormaa, jos sitä ei hallita oikein. Lean-tuotannon käytännöistä inspiroituneena huomion tulisi olla jatkuvassa parantamisessa, arvovirran optimoinnissa ja hukkaan menevän työn minimoinnissa.
Automaation ylläpitäminen voi myös olla haastavaa ja vaatia huomattavia resursseja. Suosittelemme hyödyntämään valmiita COTS-työkaluja (Commercial Off-The-Shelf), kuten Atlassianin Jiraa ja Confluencea, Dockeria, GitHubia, GitLabia tai Kubernetesia, jotka on kehitetty ja joita tukevat suuret yhteisöt ja yritykset. Vakiintuneiden ratkaisujen hyödyntäminen, olipa kyseessä kaupalliset tai avoimen lähdekoodin vaihtoehdot, voi säästää aikaa ja resursseja verrattuna omien ratkaisujen rakentamiseen alusta alkaen.
Tutustu artikkeliin, jossa käsitellään jatkuvaa toimitusta tarkemmin.
Rakenna kehittäjäyhteisösi versionhallinnan ympärille
Muutosten hallinta nopeasti kehittyvässä ohjelmistotuotteessa voi olla haastavaa. Versionhallinta on keskeisessä roolissa, jotta versioiden väliset erot voidaan ymmärtää ja jäljitettävyys varmistaa. Kuten Microsoft selittää oppaassaan, Git on noussut globaaliksi versionhallinnan standardiksi, jota yli 90 % maailman kehittäjistä käyttää avoimen lähdekoodin työkaluna lähdekoodin hallintaan.
Ohjelmistojärjestelmät ovat monimutkaisia ja koostuvat useista eri komponenteista, jotka on otettu käyttöön moninaisissa kokoonpanoissa. Siksi on olennaista tallentaa sovelluksen lähdekoodi sekä testiautomaatio, infrastruktuuri ja käyttöönoton putki versionhallintaan.
Versionhallintajärjestelmät integroituvat usein tehtävänhallintatyökaluihin, kuten Jira Softwareen, mikä helpottaa kattavan jäljitys- ja auditointiketjun luomista sekä varmistaa, että muutokset dokumentoidaan ja perustellaan asianmukaisesti. Hyvin toteutettu versionhallinta avaa myös oven uusille käytännöille, kuten automatisoidulle tietoturvatestaukselle, koodin laadun tarkistuksille ja vertaisarvioinneille, mikä parantaa ohjelmistokehitysprosessin kokonaislaatua.
Monitoroinnista toimenpiteisiin
Sovellusten nykytilan tunteminen mahdollistaa dataan perustuvan päätöksenteon. Esimerkiksi aktiiviset bugit työpöytäsovelluksessa tai verkkopalvelun käytettävyysaika voidaan havaita ennakolta. Tavoitteena on estää tilanteet, joissa asiakkaan täytyy ilmoittaa ongelmasta insinööreille.
Seuranta voi johtaa toimenpiteisiin ja ennakoivaan toimintaan seuraavasti:
-
Mittaamalla, mikä oletetaan olevan sovellustesi normaalitila
-
Hälyttämällä poikkeamista
-
Tunnistamalla hälytysväsymys
-
Käyttämällä syyllistämättömiä jälkipuheita (blameless post-mortem) toistuvien ongelmien välttämiseksi.
Muista: seurannan ja havainnoinnin tulisi olla osa sovelluksen suunnittelua. Puppetin State of DevOps-raportti osoittaa, että tiimit, jotka voivat itse konfiguroida seurantaansa, ovat todennäköisemmin huippusuorittajia.
Laadunvarmistus on enemmän kuin portinvartija
Perinteisissä ohjelmistokehitysmalleissa testaus ja laadunvarmistus ovat erillään ohjelmistotiimeistä, mikä aiheuttaa jännitteitä kehittäjien ja laadunvarmistuksen välillä. Kehittäjät saattavat tuntea olevansa hyökkäyksen kohteena, kun laadunvarmistus puuttuu heidän valmiiksi katsomaansa työhön, vaikka tavoite onkin parantaa tuotteen laatua.
Tämän dynamiikan parantamiseksi organisaatioiden tulisi omaksua yhteistyöhenkinen lähestymistapa ja sijoittaa laadunvarmistustiimit helpottavaan rooliin. Heidän tulisi jatkuvasti tarkastella tiimien käyttämiä automatisoituja testejä varmistaakseen, että ne pysyvät ylläpidettävinä ja tehokkaina. Testaajat voivat auttaa myös tarjoamalla testidataa ja optimoimalla putkistojen nopeutta.
Modernit menetelmät, kuten käyttäytymispohjainen kehitys (Behavior-Driven Development, BDD), mahdollistavat tehokkaat automatisoidut hyväksymistestit luonnollisella kielellä. Ne eivät vaadi koodaustaitoa, mikä tekee testien tarkoituksen ymmärtämisestä helpompaa myös sidosryhmille. BDD:n avulla laajempi joukko voi osallistua laadunvarmistuskeskusteluihin ja vaikuttaa yksittäisiin testitapauksiin.
Kiitos korkean tason QA-automaation ja sen integroinnin jatkuvan toimituksen putkeen, QA-asiantuntijoilla on enemmän aikaa keskittyä harvemmin tehtyihin tehtäviin (esim. ei-funktionaaliseen testaukseen, tutkimusperusteiseen testaukseen jne.), mikä tehostaa kehitysprosessia ja takaa korkealaatuisemmat ohjelmistojulkaisut. Yhteistyötä edistämällä ja automaatiota hyödyntämällä organisaatiot voivat saavuttaa tehokkaampia ja vaikuttavampia laadunvarmistuskäytäntöjä, jotka hyödyttävät koko ohjelmistokehityksen elinkaarta.
Lue blogistamme viidestä kirjasta, jotka kannattaa lukea jatkuvan laadunvarmistuksen merkityksen ymmärtämiseksi.
Tee tietoturvasta olennainen osa toimitusputkeasi
Kyberuhat ovat vakava riski organisaatioille, sillä tietoturvaloukkaukset voivat aiheuttaa merkittäviä taloudellisia ja maineeseen liittyviä vahinkoja. Henkilötietojen vuotaminen tai IT-järjestelmien lukkiutuminen voi johtaa liikevaihdon menetykseen ja heikentää brändin arvoa. Korkean suorituskyvyn DevOps-tiimit ovat ratkaisseet turvallisuuden ja innovaation välisen ristiriidan edistämällä yhteistyötä tietoturva-asiantuntijoiden ja kehitystiimien välillä, varmistaen, että tietoturva on olennainen osa toimitusputkea.
Tietoturva-asiantuntijat ovat keskeisessä roolissa tarjoamalla ennalta hyväksyttyjä kirjastoja ja prosesseja, jotka mahdollistavat “secure by design” -tuotteiden luomisen sen sijaan, että tietoturvaa yritettäisiin lisätä jälkikäteen. Integroimalla tietoturva kehitysputkeen ja hyödyntämällä automatisoituja tietoturvaskannaustyökaluja yritykset voivat suojautua paremmin kyberuhilta samalla kun ne säilyttävät korkean innovaatiotason. Lisäksi tietoturva-asiantuntijoiden mukaan ottaminen jo kehitystyön alkuvaiheessa varmistaa, että uhkamallit huomioidaan jo ennen ohjelmointiin käytettävää aikaa, jolloin tekniset ratkaisut ovat kestäviä jo niiden luomisvaiheessa.
Lue Darren Richardsonin blogi, jossa käsitellään kyberturvallisuuteen liittyviä uhkia ja varotoimia, jotka jokaisen alalla toimivan tulisi tuntea.
DevOps-muutokset muuttavat merkittävästi organisaatioiden työskentelytapoja, mutta ne eivät ole kertaluonteisia matkoja, joilla on selkeä määränpää. DevOps-asiantuntijat kehittyvät jatkuvasti osana yrityskulttuuriaan ja työmenetelmiään, omaksuen parannukset jatkuvana ja ajan myötä tapahtuvana prosessina.
Tämän tason saavuttamiseksi saattaa kuitenkin olla tarpeen tehdä määrätietoisia ponnisteluja, jotta nykyisiä toimintatapoja voidaan muuttaa. Tätä vaihetta kutsumme DevOps-digitaalimuutokseksi, jonka tavoitteena on integroida DevOps-käytännöt organisaation päivittäisiin toimintoihin ja tehdä siitä mukautuva asiakkaiden tarpeisiin ja alan edistysaskeleisiin.
Ei ole olemassa yhtä kaikille sopivaa ratkaisua onnistuneen ketterän ja DevOps-muutoksen toteuttamiseen. Jokainen organisaatio on ainutlaatuinen, eikä mikään “valmis pakettiratkaisu” sovi universaalisti kaikille. Muutosprosessi vaatii räätälöidyn lähestymistavan, jossa huomioidaan organisaation erityiset haasteet, tavoitteet ja olemassa olevat käytännöt. Harri Pendolin käsittelee tätä aihetta tarkemmin blogissaan Kolme tasoa, joilla muutos on toteutettava.
Omaksumalla ketterän DevOps-muutosstrategian ja sopeutumalla jatkuvasti muutoksiin organisaatiot voivat saavuttaa huipputason DevOps-suorituskyvyn ja luoda jatkuvan parantamisen ja innovoinnin kulttuurin.
Roadmap
Vaikka jokainen organisaation DevOps-muutos on ainutlaatuinen ja vaatii räätälöinnin, monet muutokset käyvät läpi laajalti samankaltaisia vaiheita. Muutoksen suunnitelma tai DevOps-muutos-tiekartta voi tarjota yleisen viitekehyksen, jonka organisaatiot voivat mukauttaa omiin tarpeisiinsa.
Johto
-
Tietoisuus
-
Tiekartta
-
Investoinnit
Organisaatio
-
Kehittäjäalusta
-
Käytäntöyhteisöt
-
Tiimirakenteet
Tiimit
-
Itsepalvelu
-
Kehittäjäkokemus
-
Jatkuva toimitus.
On tärkeää rakentaa vankka perusta, jotta DevOpsin käyttöönotto voidaan juurruttaa organisaatiokulttuuriin kestävästi ja skaalautuvasti. Aloita terveellisen kulttuurin luomisella, joka omaksuu muutoksen ja jota tukevat läpinäkyvät muutoshyväksyntäprosessit, perusautomaatio, huolellinen seuranta ja versiohallinta. Nämä luovat edellytykset DevOpsin onnistuneelle toteutukselle digitaalisen transformaation yhteydessä.
Olemme käsitelleet organisaatiokulttuureja syvällisemmin alla olevassa blogissa.
Yhteisöt käytäntöjen ympärillä ja yhteisöjen rakentajat
Tämä tarkoittaa ammattilaisten kokoamista yhteen yhteisen kiinnostuksen kohteen ympärille, jolloin he tekevät yhteistyötä ja keskittyvät kehittämään osaamistaan ja taitojaan. Yhteisöjen rakentaminen ja ylläpitäminen on tehokas tapa skaalata DevOps toimintaa.
Näistä yhteisöistä kehittyy itsenäisiä ryhmiä, jotka tarjoavat arvokasta ohjausta organisaation tavoitteille ja ovat keskeisiä teknisen osaamisen ylläpitämisessä ja kehittämisessä. Tällaisia yhteisöjä rakentamalla organisaatio vahvistaa sopeutumiskykyään uudelleenjärjestelyihin ja tuotevaihteluihin. Yhteisöjen tukeminen kuitenkin edellyttää sekä alkuvaiheen että jatkuvia investointeja. Yhteisöt menestyvät, kun ne keskittyvät jaettuihin intohimoihin, perustuvat vapaaehtoisuuteen ja dynaamisuuteen sekä edistävät yhteisen tiedon kasvua.
On tärkeää ymmärtää, että käytäntöyhteisöjä johdetaan eri tavalla kuin perinteisiä osastoja. Niiden tulisi määrittää olemassaolonsa selkeän tarkoituksen ja johdon tuen varassa. Tällainen voimaannuttaminen lisää autonomiaa ja luo ympäristön, jossa tieto ja innovaatiot voivat kukoistaa.
Käytäntöyhteisöissä voi esiintyä monenlaista sisäistä johtajuutta, kuten:
- Ajatusjohtaja
-
Henkilö, joka järjestää tapahtumia ja kokouksia
-
Henkilö, joka dokumentoi käytäntöjä.
Näitä sisäisiä johtajia kutsumme “yhteisön rakentajiksi.” He ovat erityisen tärkeitä käytäntöyhteisön alkuvaiheessa, kun sitä vasta perustetaan. Saattaa olla, että organisaatiossasi on jo käytäntöyhteisö, vaikka sitä ei tiedosteta.
DevOps-muutoksen aikana yhteisön rakentajat voivat luoda kiireellisyyden tunnetta. He kehittävät käytäntöyhteisöjään ja ottavat niissä johtavia rooleja.
Esimerkkejä käytäntöyhteisöistä:
-
DevOps-muutoksen käytäntöyhteisö
-
Tietoturvan käytäntöyhteisö
-
Alustakehityksen käytäntöyhteisö
Kuuntele lisää aiheesta DevOps Sauna -podcastimme jaksosta, jossa kerromme palvelumuotoilun työkaluista käytäntöyhteisöjen tukemisessa.
Kun DevOps kohtaa designin
Digitaalisten palveluiden menestys riippuu huolellisesta suunnittelusta, joka yhdistää käyttäjäkokemuksen, käyttäjäpolut ja brändäyksen insinööriosaston työhön. Samoin kuin ohjelmistot kehittyvät jatkuvasti, myös suunnittelun on mukauduttava ja parannuttava ajan myötä. Ohjelmistojen käsittely elävänä kokonaisuutena korostaa ajantasaisten kirjastoiden merkitystä suunnittelijoille ja kehittäjille. Vanhentuneisiin ratkaisuihin luottaminen voi johtaa ongelmiin.
Yhteinen kirjasto edistää suunnittelu- ja kehitystiimien välistä yhteistyötä, helpottaen sujuvaa vuorovaikutusta ja tiedonvaihtoa. Suunnittelu- ja kehitysprosessien yhdistäminen voi yhdessä DevOps-käytäntöjen, kuten automaation, kanssa johtaa nopeisiin tuotejulkaisuihin ja lyhyempään markkinoillepääsyaikaan.
Jatkuva muutos pilvipalveluiden ja DevOpsin avulla
Organisaatiot, jotka hyödyntävät DevOps-käytäntöjä, huomaavat pystyvänsä toimittamaan laadukkaampia ohjelmistoja nopeammin – vapauttaen tiimeille aikaa uusien ominaisuuksien kehittämiseen ja liiketoiminnan tulosten parantamiseen. Onnistunut pilvipalveluiden käyttöönotto tuo lisäksi etuja, kuten skaalautuvuutta, saatavuutta ja kustannustehokkuutta, ja helpottaa uusien teknologioiden, innovaatioiden ja kokeilujen hyödyntämistä.
Näiden molempien osa-alueiden hallitseminen antaa yrityksille tarvittavaa ketteryyttä selviytyä, tarjoten DevOpsin nopeuden, laadun ja tehokkuuden edut yhdessä pilvipalveluiden kustannustehokkuuden ja innovointikyvykkyyden kanssa.
Lue oppaastamme “Hyödynnä DevOpsia ja pilvipalveluita parhaalla mahdollisella tavalla”, kuinka nämä lähestymistavat tukevat toisiaan.
DevOps ei ole enää valinnainen – se on välttämätön. Se, mikä aiemmin oli kilpailuetu, on nyt alan standardi, ja DevOps sekä digitaaliset transformaatiot ovat välttämättömiä ohjelmistoalan yrityksille menestyäkseen.
Vaikka teknologia ja työkalut ovat keskeisiä osia DevOpsissa, olisi virhe olettaa, että ne tarjoavat täydellisen ratkaisun. Valmista tuotetta ei ole saatavilla, sillä DevOpsia ei voi ostaa valmiina pakettina. Sen sijaan keskeisten sidosryhmien ja päätöksentekijöiden on otettava vastuu tarvittavien kulttuurimuutosten ajamisesta organisaation ylimmältä tasolta alkaen. Oikeiden työkalujen ja lähestymistavan yhdistelmä on välttämätön, jotta yritykset voivat saavuttaa täyden DevOps-potentiaalinsa.
Pysy ajan tasalla - tilaa uutiskirjeemme!
Saat opettavaista sisältöä ja viimeisimmät uutiset Eficodelta suoraan meiliboksiisi.
