DevOps-tiimillä viitataan tuote- tai asiakastiimin, jolla on riittävä ymmärrys ja kokemus infrapuolen asioista, ja jolla on sujuva mahdollisuus konsultoida kokenutta erityisasiantuntijaa näissä asioissa. Tavoitteena on kulttuuri, jossa sama tiimi kantaa vastuun niin rakentamastaan kokonaisuudesta, ajoympäristöstä kuin teknisestä hyvinvoinnista.
Miten tällaiseen tavoitetilaan päästään? Mistä asioista syntyy toimiva DevOps-tekeminen ja mitä organisaatiolta vaaditaan onnistumiseen?
DevOps-tiimin hyödyt
DevOps-tekemisessä yritys ei siilouta infrapuolen osaamista omaan irralliseen tiimiin, vaan yrityksen osaamisen, käytäntöjen ja toimintamallien kehittämistä edistää sisäinen metatiimi. Infrapuolen työ ja työkalut muistuttavat entistä enemmän ohjelmoitsijan vastaavia, mikä mahdollistaa yhtenäisemmät työskentelytavat ja läpinäkyvämmän yhteistyön.
Kun tiimi pystyy itse tulkitsemaan infran tilan ja tekemään siihen nopeasti muutoksia, se saa palautetta toiminnastaan myös nopeammin. Tästä syntyy entistä parempi palautelooppi, jossa muutosnopeuden tuomat edut luovat positiivista kiihtyvyyttä ja merkittävää kilpailuetua.
DevOps-mentaliteetti
DevOps-mentaliteetin mukaan asiakastiimin tulee olla itse vastuussa projektinsa eri osa-alueista, eikä näitä osa-alueita ole ulkoistettu toiselle organisaation alueelle. Tiimin jäsenillä on entistä enemmän niin sanotusti oma lehmä ojassa.
Työn keskittäminen ja hajauttaminen, kuten myös erikoistuminen ja yhteinen vastuu eivät ole kiveen hakattuja linjanvetoja, vaan ne seuraavat sekä teknologioiden ja trendien syklejä että asiakkuuksien tarpeita.
Mitä on DevOps-kulttuuri? Millainen on hyvä kehittäjäkokemus? Onko infran sujuvassa hallinnassa kyse lopulta kehittäjien palvelemisesta? Kyse on lopulta yhteistyön kultivoinnista ja asioiden oppimisesta. Devaajille ei tarvitse tuoda toimenpiteitä lautasella, vaan heitä voi opettaa kykeneviksi kehittämään sekä ylläpitämään ajoympäristöjään.
DevOps-kulttuuri sisältyy väkisinkin organisaation ympäröivään kulttuuriin. DevOps-kulttuuri tarvitsee onnistuakseen riittävän ymmärryksen ja tuen ympäröivältä organisaatiolta tai se saattaa kaatua turhautumiseen.
Tiimin rakentaminen
Tiimillä tarkoitamme kahta asiaa, asiakastiimiä ja sisäistä “metatiimiä”, jossa tietyn osa-alueen ammattilaiset jakavat tiedon, opit ja käytännöt yli asiakastiimien. Oli kyseessä konsulttifirma, tuotetalo tai mikä tahansa, uskomme että tiedonkulun vapaus ja mahdollistaminen on nykypäivänä tärkeä kilpailuetu työn tulosten ja asiantuntijoiden työssä viihtyvyyden näkökulmasta.
DevOps-tiimi on tiimi, joka tekee sovelluskehitystyötä sekä palveluiden ja infran kehitystä sekä huolenpitoa, yhdessä. Aiemmin mainittu metatiimi vastaa konkreettisten asioiden sijaan ennemminkin asiakastiimien tuesta ja asioiden kehittämisestä. Asiakastiimillä voidaan tässä tapauksessa tarkoittaa myös tuotetiimiä tai mitä tahansa jonkin kokonaisuuden parissa toimivaa ryhmää.
Tiimin abstraktio täytyy huomioida, kun tähdätään toimivaan DevOps-tiimiin ja -kulttuuriin. Missä vaiheessa asiat lakkaavat henkilöitymästä tai missä vaiheessa yhden henkilön aikataulu, rippijuhlat tai katsastusaika lakkaa olemasta relevantti asia viikon työtä suunnitellessa? Vasta kun yksilön aikataulut eivät ole onnistumisen suhteen kriittisiä, voimme puhua tiimistä.
Etätyöskentely on nostanut esille yhdessä tekemisen tärkeyttä ja siiloutumisen haasteita. Kommunikaatio, tiimityö ja etenkin DevOps- tai Ops-erityisasiantuntijan normaali tiimin jäsenyys korostuvat etäaikoina. Asynkroninen kommunikaatio onnistuu paremmin, jos konteksti on yhteinen. Muuten tarvitaan useammin yhteisiä, tiettyyn aikaan sidottuja palavereita. Etäaikana etusijalla on aikaansaaminen, eikä paikallaolo. Kukaan ei ole vahtimassa käytettyä aikaa, vaan sitä, miten paljon kukin saa aikaan työpäivän tai työviikon aikana.
Tulevaisuuden teknologiat ja tiimin osaaminen
Ohjelmistokehityksessä on saavutettu vuosikausia sitten piste, jossa työtä alettiin tehdä aiempaa hallitummin ja hyväksi todettuja konventioita noudattaen. Uudet alustat ja palvelutyökalut ovat mahdollistaneet DevOps-rintamalla samankaltaista kehitystä.
Palveluita voi nykypäivänä konfiguroida selkokielisesti irrallaan konkreettisesta palvelimesta tai alustasta. Näitä konfiguraatioita voi käsitellä kuin mitä tahansa koodia. Tämä saattaa äkkiseltään kuulostaa “nice to have”-jutulta, mutta lopulta uudet työkalut mahdollistavat kehitystyöstä tuttuja asioita, kuten ympäristön muutosten reviewit, tuotantoonviennit sekä laajempaa ja parempaa automatisointia ja kokeilemisen mahdollisuutta.
Samat työkalut mahdollistavat entistä paremmin ympäristöjen eristämisen toisistaan. Eristetty ympäristö tarkoittaa ymmärrettävämpää ympäristöä. Sen voi siirtää ja monistaa. Sen sisällä voi testata asioita pelkäämättä, että jokin instanssi jossain päin pilveä tai konesalia keikahtaa. Ennen kaikkea ymmärrettävä kokonaisuus on helpompi hallita ja muuttaa.
Erilaiset konfiguraatiot tuovat mukanaan toistettavuuden edun ja varmuuden siitä, mikä ympäristön todellisuuden tila on. Tämä lisää varmuutta toimintaan ja uskallusta tehdä muutoksia olemassaolevaan. Ympäristöt eivät ole enää niin uniikkeja tai kuumottavia, eivätkä riippuvaisia palvelinkohtaisista oikuista.
Lisäksi nykyaikaiset työkalut mahdollistavat, että infrastruktuuria voi kohdella samoin periaattein kuin ohjelmistoa. Kehittäjä voi tehdä totutulla ohjelmointikielellä infraa sen sijaan että opettelee uutta palvelukohtaista konfiguraatiokieltä.
Tämä lisää toimintavarmuutta ja etenkin tiimin itsevarmuutta, joka lisää nopeutta. Nopeus lisää mahdollisuuksia ja parantaa onnekkaiden sattumusten todennäköisyyksiä.
Uudenlaisen tekemisen mahdollistaminen
DevOps-tekemisen malli on jatkossa entistä enemmän samanlaista kuin ohjelmistokehityksen malli; palvelimella kikkailun sijaan tiimillä on versiohallinta ja sen tuomat review-käytännöt sekä pipelinet ja deployaus-käytännöt. Omasta näkökulmastani infrapuolen asiat kohtaavat samantyylisen renesanssin kuin ohjelmistokehitys vuosikausia sitten.
Tiimirakenteen muutos, oppimisen ja kokeilemisen ajattelutapa sekä kollaboratiivista työtä mahdollistavat teknologiat luovat puitteet uudenlaiselle tekemiselle. Uudenlaisessa tekemisessä yhteistyö on tiiviimpää tiimin sisällä, eikä niinkään organisaation eri osastojen välillä.
Todellisen DevOps-tiimin jäsenellä on oma lehmä ojassa, nimittäin hän ei halua rakentaa palvelua, jota joutuu itse öisin stressaamaan. Kun “joku muu” ei ole vastuussa öisistä katastrofeista, muuttuu mielenkiinnon taso laajemmaksi. Tästä syntyy siten sekä vastuunkantoa että henkistä omistajuutta.
Tiimi voi itsekseen määrittää rakentamansa palvelun ajoympäristön, ja tehdä siihen muutoksia ilman “konesalin asiantuntijaa”, koska muutoksia on mahdollista ajaa eri ympäristöihin testattavaksi paljon helpommin. Tiimi saa itse määrittää, minkä kokoisia muutoksia se tekee, miten priorisoi ja täten vaikuttaa omaan reaktiokykyynsä. Tiimistä ja tiimiläisistä tulee autonomisia toimijoita, jotka ovat vähemmän riippuvaisia muista osastoista. Tämä lisää hallinnan tunnetta ja draivia.
Tiimin itsevarmuus kasvaa entisestään, kun se saa asioita aikaan, eikä sen tarvitse turvautua erilliseen henkilöön kuin erikoistapauksissa. Tämä vähentää epäröintiin kulunutta aikaa ja kuormaa sekä kasvattaa nopeutta entisestään.
Nopeudella on kerrannaisvaikutuksia. Viiveiden poistuminen johtaa siihen, että palautetta muutoksista saadaan nopeammin, ja seuraava parannus tai kokeilu voidaan tehdä nopeammin. Muutosten nopeus mahdollistaa parempia tuloksia.
Avaimet onnistuneeseen DevOps-tiimiin
Kävin puhumassa hiljattain Wakarun järjestämässä tapahtumassa siitä, miten rakennetaan toimiva DevOps-tiimi. Lopputuloksena syntyi kiteytys: organisaatiolta tarvitaan sopivaa mentaliteettia tiimin rakentamiseen, uudehkojen teknologioiden omaksumista sekä niiden yhteen tuomista järkevin toimintamallein ja menetelmin.
