Oletko sulkenut DevOpsin äärettömän silmukan käyttöönoton jälkeen?

Voimmeko sulkea DevOpsin äärettömän silmukan IT-palvelunhallinnalla?

"Epäselvyyden muurilla" on kaksi puolta. Toinen suuntautuu kehitykseen ja toinen operointiin. Kun tämä muuri kuvataan, näemme yleensä virtauksen kehityksestä operointiin, mutta harvoin päinvastaiseen suuntaan.

DevOps kuvataan kuitenkin täysin eri tavalla: äärettömänä silmukkana, joka havainnollistaa alueet, jotka meidän on katettava, sekä kyvykkyydet, joita tuote- tai palveluorganisaatiolla tulee olla. Kuten kaikki tiedämme, DevOpsissa on kyse "epäselvyyden muurin" purkamisesta ja Devin ja Opsin yhteistyön muuttamisesta. Tavoitteena on rakentaa kulttuuri, jossa Dev ja Ops tekevät yhteistyötä tuottaakseen usein arvoa luovaa ja laadukasta koodia koko discover-vaiheesta jatkuvaan palautteeseen asti.

Mutta vastaa rehellisesti: keskitymmekö todella riittävästi siihen, mitä tapahtuu Deploy-vaiheen jälkeen? Jääkö meiltä huomaamatta paljon Opsin ja Devin väliseen vuorovaikutukseen liittyviä asioita?

Tässä blogissa käsitellään DevOps-silmukan yhdistämistä, Ops-puoleen keskittymistä ja sitä, miten se voi tukea tuoteidean kartoittamista. Käyn myös läpi, miten IT-palvelunhallinnan (ITSM) avulla voidaan saada tietoa keinoista tarjota asiakkaille laadukkaita ja arvokkaita palveluita.

Mitä operoinnilla tarkoitetaan DevOpsissa?

Jos kysyisit tätä kymmeneltä ihmiseltä, saisit todennäköisesti kymmenen erilaista vastausta. Itse tiivistäisin sen käytännöksi ja kyvykkyydeksi varmistaa, että kaikki käyttöön otettu on hallittua, saatavilla, oikein mitoitettua ja riittävän tietoturvallista.

Kuka tekee mitä operate-vaiheessa?

Kun koodi on otettu käyttöön tuotannossa ja sen on varmistettu toimivan, operointitiimit vastaavat siitä, että kaikki pysyy saatavilla. Toteutustapa vaihtelee tarjottavien palveluiden arkkitehtuurin mukaan. Onko kaikki omassa konesalissa vai koostuuko palvelu eri osien infrastructure-as-a-service- (IaaS) ja platform-as-a-service- (PaaS) ratkaisuista? Onko operointitiimi oma, ulkoistettu, yhdessä tuotettu vai usean toimittajan muodostama?

Sillä ei varsinaisesti ole väliä, mutta eri sidosryhmien väliseen yhteistyöhön ja odotusten hallintaan on kiinnitettävä huomiota.

Tärkeää on varmistaa, että saamme kaikilta osapuolilta tarvittavat tiedot päätöksentekoon ja tehtävien priorisointiin. Haluamme esimerkiksi pystyä tekemään päätöksiä, joilla vältetään teknisen velan kertyminen, sekä varmistaa, etteivät ympäristön muutokset häiritse tarjottuja palveluita.

Tässä Devin ja Opsin yhteistyö on ratkaisevan tärkeää oikeiden päätösten tekemiseksi ja tuoteidean kartoittamisen tukemiseksi. Markkinoilla on paljon erilaisia DevOpsin operate-vaiheessa käytettäviä työkaluja. Kukin niistä tuottaa erilaista dataa ja tietoa eri tavoin sekä eri tarkoituksiin.

ITIL4:ssä, joka on ITSM-viitekehys, on tähän aiheeseen liittyviä periaatteita:

• Tee yhteistyötä ja edistä näkyvyyttä

• Pidä asiat yksinkertaisina ja käytännöllisinä

Meidän on varmistettava, että operointityökalujen tuottama data ja tieto ovat sidosryhmien saatavilla ja helposti käytettävissä – olipa kyseessä tuotepäällikkö, tuotesuunnittelija tai tuotteen pääinsinööri. Näin he pystyvät hallitsemaan ja kehittämään palveluita paremmin.

Organisaationa haluat myös varmistaa, että päätökset tehdään oikealla tasolla. Operatiiviset päätökset tulisi tehdä mahdollisimman lähellä operointitiimiä, mielellään tiimin sisällä. Tämä auttaa tiimiä toimimaan itsenäisemmin ja ketterämmin. Jos tavoittelet nopeaa IT-palvelunhallintaa, poista mahdollisimman paljon hukkaa, kuten tehtävien siirtelyä ja odottamista. Luota tiimeihisi, työskentelivätpä ne Devin, Opsin tai DevOpsin parissa.

Miten havainnoimme?

Aloitetaan kysymyksellä: miksi havainnoimme? Jos vastaus on vain "haluamme monitoroida sovelluksemme suorituskykyä", se ei auta ITSM:n eikä DevOpsin näkökulmasta. Meidän on oltava selvillä siitä, mitä aiomme tehdä havainnoista saamallamme tiedolla sekä siitä, kuka voi ja tulee käyttämään sitä.

Meidän on myös pystyttävä vastaamaan siihen, oliko saamamme tulos hyvä, huono vai odotettu. Havainnoinnin ja monitoroinnin pääasiallinen tarkoitus on parantaa havainnoitavaa kohdetta, mukaan lukien korjata rikkoutuneet asiat.

Jatkuva parantaminen on keskeinen kyvykkyys Leanissa, DevOpsissa ja ITSM:ssä. Siksi meidän on varmistettava, että havainnointiin käyttämämme työkalut tuottavat olennaista tietoa kehityskohteiden tunnistamiseksi. Tämä tieto on ratkaisevan tärkeää tuotepäälliköille, tuotesuunnittelijoille ja tuotteen pääinsinööreille, jotka vastaavat palveluidemme jatkuvasta kehittämisestä.

Haluamme antaa heille edellytykset toimia havainnoinnin avulla tunnistettujen poikkeamien perusteella, jotta emme jätä hyödyntämättä teknologian kehitysmahdollisuuksia, tarvittavia muutoksia toimintatapoihin, työkaluihin tai kumppaniyhteistyöhön.

Mitä siis havainnoimme DevOps-ympäristössä? Kun tarkastelemme DORA-raportin mittareita, se kattaa seuraavat:

• Käyttöönottojen tiheys (kuinka usein ohjelmistotiimi vie muutoksia tuotantoon)

• Muutoksen läpimenoaika (aika, joka kuluu commitoidun koodin saamisesta toimimaan tuotannossa)

• Muutosten epäonnistumisaste (häiriöiden, palautusten ja epäonnistumisten osuus kaikista käyttöönotoista)

• Palvelun palautumisaika (aika, joka kuluu palvelun palauttamiseen tuotannossa häiriön jälkeen)

Kaksi viimeistä kohtaa liittyvät tiiviisti ITSM:ään. Ensimmäinen liittyy ITILin muutoksenhallinnan ja häiriönhallinnan käytäntöihin, jälkimmäinen häiriönhallintaan. Tämä tarkoittaa, että meidän on seurattava häiriöitä ja muutoksia tuotantoympäristössä sekä kyettävä yhdistämään ne toisiinsa, jotta saamme ITILin laatua mittaavan KPI:n muutosten aiheuttamista häiriöistä. Osan tästä voi automatisoida integroimalla CI/CD-putken muutoksenhallintaan esimerkiksi Jira Service Managementissa.

Mitä muuta meidän on seurattava, jotta voimme parantaa asiakkaillemme tarjoamiamme palveluja? Lista voisi olla hyvin pitkä, mutta entä käyttäjätuen vuorovaikutus, saatavilla olevien palvelutoimintojen käyttöaste ja tuotteen käyttäjäkokemus?

Tuoteorganisaatioille on ratkaisevan tärkeää mitata eri ominaisuuksien käyttöä ja sitä, kuinka usein ihmiset käyttävät vakiopalvelua, jotta ne voivat löytää uusia kehitysmahdollisuuksia. Product managerit, product designerit ja tuotteen pääkehittäjät tarvitsevat keinoja tunnistaa, mikä luo arvoa loppukäyttäjille, jotta backlogista voidaan poistaa kaikki toiminnot, jotka eivät tuota asiakasarvoa.

Joidenkin tutkimusten mukaan ei ole epätavallista, että kolmannes backlogista ei tuota arvoa loppukäyttäjille. Ne ovat vain hukkaa, joka vie tilaa arvoa tuottavilta asioilta.

Yleinen virhe monitoroinnin ja havainnoinnin parissa työskenneltäessä on, että poikkeamien juurisyiden eri ulottuvuuksia ei huomioida. ITILissä on jatkuvaan parantamiseen tiiviisti liittyvä käytäntö nimeltä ongelmanhallinta, jonka tavoitteena on hallita toistuvia laatuongelmia, kuten häiriöitä. Ongelmien juurisyitä selvitettäessä on tärkeää analysoida niitä neljästä ulottuvuudesta:

• Organisaatiot ja ihmiset

• Informaatio ja teknologia

• Kumppanit ja toimittajat

• Arvovirrat ja prosessit

Teknologia- ja tuoteorganisaatioissa juurisyyanalyysi kattaa usein vain informaation ja teknologian. Tämä rajoittaa merkittävästi kykyä löytää todellinen juurisyy, poistaa se ja parantaa palvelun laatua. Jos analyysi ei kata kaikkia ulottuvuuksia, samanlaiset teknologiset poikkeamat todennäköisesti toistuvat yhä uudelleen.

Miten voimme hyödyntää jatkuvaa palautetta?

Suuri osa Opsissa keräämistämme tiedoista ja datasta voidaan koota raporteiksi ja dashboardeiksi dataohjattua toimintaa varten tai analysoida tekoälyn avulla. Tarvitsemme kuitenkin myös yhteistyö- ja keskustelufoorumeita, jotta voimme oppia toisiltamme. Hyvä tapa tähän on järjestää asiakastukitiimien ja Dev- sekä Ops-tiimien säännöllisiä tapaamisia ajatusten jakamiseksi ja hyvien monialaisten suhteiden rakentamiseksi. Tämä luo puolestaan yhteistyön ja läpinäkyvyyden kulttuuria, jotka ovat ITSM:n, Agilen, Leanin ja DevOpsin perusperiaatteita.

Toiminnan ja havainnoinnin aikana löydetyt asiat on arvioitava, priorisoitava ja dokumentoitava, jotta ne tukevat product discoveryyn ohjautuvia palautesilmukoita. Data on jäsennettävä informaatioksi ja täydennettävä kontekstilla, jotta siitä syntyy päätöksenteon pohjaksi tarvittavaa tietoa. Mahdollisuudet on esitettävä, arvo tunnistettava, riskejä hallittava ja kaiken on oltava valmiina product discoveryn arvioitavaksi, priorisoitavaksi ja päätettäväksi.

Silmukan sulkeminen

Tässä viimeisessä vaiheessa olemme mielestäni edenneet pitkälle DevOpsin äärettömän silmukan sulkemisessa deploymentista product discoveryyn. Kaikkiin organisaatioihin sopivia yleispäteviä tai taianomaisia ratkaisuja ei tietenkään ole. Jokainen organisaatio voi kuitenkin tunnistaa ja ottaa askelia kohti kokonaisvaltaista DevOps-toimintamallia, joka on tiiviisti integroitu ITSM-käytäntöihin ja Opsin tekemään työhön.

Ensimmäinen askel on arvioida ja tunnistaa vahvuutenne ja heikkoutenne toimintatavoissa, työkaluissa ja kulttuurissa.

Yhteenveto harkittavista toimenpiteistä

Yhteistyö ja vuoropuhelu

Kokoa eri tiimit – asiakastuki, kehitys ja Operations – jakamaan näkemyksiä ja rakentamaan monialaisia suhteita. Luo yhteistyön ja läpinäkyvyyden kulttuuri ITSM:n, Agilen, Leanin ja DevOpsin perusperiaatteiden pohjalta.

Jäsennelty datan muuntaminen

Muuta raaka operatiivinen data jäsennellyksi ja merkitykselliseksi informaatioksi sekä lisää siihen kontekstia, jotta syntyy päätöksenteon pohjana käytettävää tietoa.

Priorisointi ja arviointi

Arvioi ja priorisoi toiminnasta saadut havainnot, jotta vain tärkein palaute etenee product discovery -vaiheeseen.

Integroi palaute tuotteen kehityksen alkuvaiheeseen

Luo tapoja hyödyntää Observesta ja jatkuvasta palautteesta saatavaa tietoa tuotteen kehityksen alkuvaiheessa arviointiin, priorisointiin ja päätöksentekoon. Näin toimintavaiheissa opittua hyödynnetään uusia ominaisuuksia tai parannuksia arvioitaessa.

Jatkuva havainnointi ja monitorointi

Käytä havainnointityökaluja, jotka tarjoavat olennaista tietoa kaikille DevOpsin äärettömässä silmukassa toimiville (erityisesti operointitiimin insinööreille, tuotepäälliköille, tuotesuunnittelijoille ja tuotekehityksen pääinsinööreille). Anna tiimeille mahdollisuus reagoida havainnoinnin avulla tunnistettuihin poikkeamiin ja parannuskohteisiin.

Juurisyyanalyysi

Varmista, että teet kattavan juurisyyanalyysin huomioimalla kaikki neljä ITIL4:ssä määriteltyä ulottuvuutta:

• Organisaatiot ja ihmiset

• Informaatio ja teknologia

• Kumppanit ja toimittajat

• Arvovirrat ja prosessit

Älä rajaa tarkastelua vain teknologiseen ulottuvuuteen. Kun kaikki ulottuvuudet huomioidaan, tiimit voivat ymmärtää ja ratkaista kaikki taustalla olevat ongelmat kokonaisvaltaisesti.

Tee jatkuvasta parantamisesta osa organisaatiosi DNA:ta

Havainnoinnin ja monitoroinnin ensisijainen tarkoitus on parantaa havainnoitavaa jatkuvasti. Varmista, että tämä ajattelutapa on osa organisaatiosi DNA:ta, ja kannusta tiimejä hyödyntämään palautetta ennakoivasti, jotta tuotetta voidaan parantaa jatkuvasti.

Integroi ja kehitä analysointikyvykkyyksiä

Varmista, että työkalusi on integroitu, jotta toimenpiteiden ja mittareiden automatisointi on mahdollista. Yksi esimerkki on CI/CD-putken integrointi ITSM-työkaluusi, jotta voit hyödyntää ITILin muutoksenhallintakäytäntöä.

Sulje palautesilmukka

Viestitä, viestitä, viestitä. Varmista, ettei operointitieto jää siiloihin, vaan virtaa Operatesta Product Discoveryyn ja sulkee DevOpsin äärettömän silmukan.