Bruce Lee DevOpsista: Hallitse työkalusi, toimita parempaa ohjelmistoa

Kaiken kaikkiaan kamppailulajien harrastaja voi kadottaa näkyvistään tarvittavat perusteet ja vaadittavan tarkkuuden. Useampien potkutekniikoiden harjoittelu on hyödytöntä, ellet ole kehittänyt jo osaamiasi potkuja tasolle, jolla niistä on todella hyötyä.

Uusien asioiden harjoittelu olemassa olevien taitojen hiomisen sijaan tarkoittaa, että kamppailulajien harrastaja tuhlaa arvokasta harjoitteluaikaansa. Voi jopa olla parempi käyttää aika täysin toiseen urheilulajiin kuin antaa sen viedä huomiota päätavoitteesta: kehittyä kamppailulajeissa.

En jätä itseänikään tämän ulkopuolelle. ”Oletko nähnyt Wu Dangin kahdeksan kuolemattoman miekkatekniikan, ’Ba Xian Jianin’? Minun on ehdottomasti opittava se!” Kun tällaisia ajatuksia tulee mieleeni, tarvitsen lähelleni ystävän, joka muistuttaa minua Bruce Leestä.

10 000 potkun vastine teknologiayrityksissä

Useimmissa moderneissa DevOps - ja kehitystiimeissä uusia työkaluja otetaan käyttöön liian nopeasti ja ilman riittävää harkintaa, usein asiakkaille näkyvän tuotteen kustannuksella. Aikaa ja resursseja on rajallisesti, ja niiden käyttäminen väärään asiaan vaikuttaa suoraan tuotteen laatuun.

Todellinen esimerkki on tiimi, joka ajoi muutamaa hyvin pientä palvelua virtuaalikoneilla. Ne olivat pieniä Python-skriptejä Docker-konteissa vakaalla Ubuntulla. Käytännössä kuka tahansa, jolla oli perustiedot Ubuntusta ja Pythonista, pystyi tekemään ylläpidon ja päivitykset nopeasti.

Eräänä päivänä tiimi päätti siirtää nämä palvelut Kubernetesiin pilveen vain siksi, että Kubernetes on mahtava. Tätä varten otettiin käyttöön lisää automaatiokerroksia työkaluilla, joita tiimissä ei tunnettu laajasti. Jotta Kubernetesin hienoja ominaisuuksia voitiin hyödyntää, virtuaalikoneet korvattiin Virtual Scale Setillä ja kahdennetulla verkkotallennuksella, mikä toi tiimin työkalukokonaisuuteen melko paljon Azurea. Palveluiden ja Kubernetesin optimaalista monitorointia varten oletusmonitoroinnin taustajärjestelmä korvattiin, mikä lisäsi jälleen yhden tiimille ennestään tuntemattoman tietokannan.

Tässä vaiheessa pienten palveluiden ongelman ratkaiseminen vaati edelliseen versioon verrattuna niin paljon lisäosaamista, että syntyi käytännössä osaamissaarekkeita: useimmilla tiimin jäsenillä ei yksinkertaisesti ollut aikaa päästä ajan tasalle. Jatkokehitys hidastui, ja vianmäärityksestä tuli vakava haaste, johon kului tunteja tai päiviä.

Kaikki tämä ilman ilmeistä hyötyä tuotteelle ja tuottavuuden romahtamisen kustannuksella.

Toinen hyvin tyypillinen kuvio liittyy Jenkinsiin: Kuvittele yritys, jossa käytetään aina suosittua Jenkinsiä tyypillisessä, vanhentuneessa asennuksessa. Tiimi päättää siirtyä GitHubiin, mutta koska vanhat pipelinet ovat monimutkaisia, kaikkia ei koskaan ehditä siirtää. Käytössä on siis nyt kaksi pipeline-järjestelmää. Jossain vaiheessa muutama muu tiimi siirtyy GitHubista Azure DevOpsiin, ja tämä kannustaa hipsteritiimiä perustelemaan oman ratkaisunsa käyttöönottoa. Kukaan ei ole koskaan kuullut siitä, mutta sen väitetään ratkaisevan kaikki ongelmat, koska se on uusi, pieni ja kiiltävä.

Tässä vaiheessa Jenkins on yhä ongelma, joka vaatii täsmälleen saman verran panostusta, ja lisäksi tiimit ovat luoneet osaamissaarekkeita ja esteitä.

Pitäisikö meidän sitten kaikkien palata Perliin?

Voisimme täyttää satoja sivuja esimerkeillä, ja ne kaikki tuntuisivat tutuilta.

Uusien ohjelmointikielten lisääminen tekniseen kokonaisuuteen, uusien monitorointityökalujen lisääminen, uusien pilvipalveluntarjoajien lisääminen, uusien automaatiotyökalujen lisääminen, siirtyminen yhdestä teknologiakokonaisuudesta toiseen, koska uuden luvataan olevan parempi, vaikka et oikeasti tiedä sitä. Lista on pitkä.

En kannata sitä, että käytetään vain Perliä Unixissa siksi, että sillä yhdistelmällä kaikki työt tulevat tehdyiksi. Se olisi liian äärimmäistä. Monissa tapauksissa teknologiakokonaisuuden laajentaminen tai siirtyminen uuteen kokonaisuuteen ei kuitenkaan tuota toivottuja tuloksia tai aiheuttaa ei-toivottuja sivuvaikutuksia. On myös myönnettävä, että nuo vanhan koulukunnan Perl/Unix-osaajat tuntevat ympäristönsä aivan jokaista nurkkaa myöten – harva muu voi väittää samaa.

Olen työskennellyt useissa yrityksissä, joissa teknologiakokonaisuus oli eri syistä hyvin rajallinen. Sen seurauksena ihmiset ymmärsivät koodia, infrastruktuuria ja tuotetta yli tiimirajojen. Ne olivat ainoat aidosti Agile-yritykset, joita olen nähnyt.

Konsulttina yksi lakmustesteistäni organisaation kypsyyden arviointiin on tarkastella käytössä olevien työkalujen määrää. Käytetäänkö pientä työkalujoukkoa niin tehokkaasti kuin niistä on mahdollista saada hyötyä? Vai vallitseeko työkalujen hallitsematon sekamelska? Vastaus sijoittuu tietenkin jatkumolle. Tosielämässä mikään ei ole mustavalkoista.

Miksi uusia työkaluja ei kannata lisätä

Lyhyt lista asioista, jotka voivat heikentyä, kun teknologiakokonaisuuteen lisätään jotain uutta, sisältää monimutkaisuuden, tuottavuuden, ylläpidettävyyden, tiimin keskittymisen ja tiedon jakamisen.

Monimutkaisuus: modernin ohjelmistokehityksen hiljainen tappaja

Monimutkaisuus heikentää tuottavuutta nopeammin kuin huono koodi. DevOps-työkaluketjun on vaarallisen helppo antaa kasvaa niin suureksi, ettei kukaan enää ymmärrä sitä kokonaisuudessaan. Uusi työkalu ei tule ilman piilokustannuksia. Uudet vaatimukset infrastruktuurille, uudenlaiset tietokannat, uudet build-järjestelmät, uudet paketinhallintatyökalut, osaamisen rakentaminen, vanhojen työkalujen käytöstä poistaminen ja datan migraatio – nämä kaikki ja paljon muuta ovat uuden työkalun itsensä lisäksi piilokustannuksia.

Joku on sanonut, että monimutkaisuuden vähentäminen on jokaisen seniorikehittäjän tärkeintä työtä, ja se on täysin totta. Useimmat modernit yritykset ovat hävinneet taistelun monimutkaisuutta vastaan eivätkä enää hallitse sitä. Se tekee niistä hitaita, heikentää vakautta, pidentää vianmääritystä ja tekee kaikesta kehityksestä kallista. Ratkaisuksi lisätään yleensä muutama uusi monimutkaisuuskerros, vaikka pitäisi vähentää monimutkaisuutta.

Tuottavuus: uuden työkalun käyttöönoton piilokustannus

Uuden työkalun käyttöönotolla on ilmeinen kustannus: se vie aikaa.

Lisäksi piilokustannuksia syntyy kasvavasta kognitiivisesta kuormasta, sillä lisääntynyt monimutkaisuus pakottaa kehittäjät jakamaan huomionsa useaan asiaan. Ylläpitokustannukset kaksinkertaistuvat, dokumentaation lukemiseen kuluva aika kaksinkertaistuu, ja kehittäjien on muistettava, milloin mitäkin työkalua käytetään ja missä mikäkin data sijaitsee. Nämä ovat pieniä asioita, mutta ne kasaantuvat.

Ajatellaan tyypillistä yritystä, jolla on useita tietopankkeja. Joka kerta, kun tietoa ei löydy, koska sitä etsitään väärästä työkalusta, tuottavuus heikkenee suoraan. Lisäksi on vaarana, että toteutetaan väärä asia.

Tuottavuus voi todella hidastua, kun järjestelmän monimutkaisuus kasvaa liian suureksi.

Ylläpidettävyys: Jos se ei ole kenenkään vastuulla, se hajoaa.

Jonkun on ylläpidettävä työkalua. Se voi olla sisäinen tiimi, tai yrityksesi voi ulkoistaa ylläpidon toiselle yritykselle. Joka tapauksessa uuden työkalun ylläpidosta syntyy suoria aika- ja rahakustannuksia, eivätkä ne ole katoamassa lähiaikoina. Vaikka kyse olisi SaaS-ratkaisusta, sen sulkeminen tarpeen mukaan on käytännössä vain teoreettinen vaihtoehto, kun se on integroitu kehitystyönkulkuun.

IT Opsilla on huono maine siitä, että se tekee ylläpitokustannukset näkyviksi vaatimalla selkeästi resursseja jokaiselle ylläpidettävälle järjestelmälle. Se on itse asiassa hyvä asia! Jos kenelläkään ei ole työkalusta kokonaiskuvaa ylläpitoa, säännöllisiä hallintatehtäviä tai päivityksiä varten, on vain ajan kysymys, milloin kiiltävän uusi työkalu muuttuu suureksi ongelmaksi. Vaikka jollakulla olisi kokonaiskuva, hänelle on silti varattava aikaa työkalun parissa työskentelyyn.

Tyypillinen tilanne, jossa tuotteen innokas puolestapuhuja ajaa työkalun käyttöönottoa ja päätyy sen ainoaksi ylläpitäjäksi, päättyy huonosti, kun henkilö lähtee yrityksestä tai siirtyy toiseen tiimiin. Kun joku sanoo voivansa ylläpitää uutta työkalua sivutyönä, se on selvä varoitusmerkki siitä, että tulevaisuudessa jokin räjähtää käsiin.

Tiimien fokus: Yksinkertaisuus pitää tiimit samalla kartalla.

Esimerkiksi yksi build-järjestelmä tai yksi monitorointijärjestelmä tarkoittaa, että siihen kiinnitetään aina huomiota. Ongelmat ja päivitystarpeet havaitaan ja hoidetaan niiden ilmetessä. Heti kun tällaisia järjestelmiä on useita, kehittäjät ja johto alkavat etsiä tapoja välttää epäsuosittua korjaustyötä ja toteuttavat mieluummin ominaisuuksia toisessa työkalussa. Datan päivittäminen unohtuu, datan keräämiseen tarkoitetut ajot kuluttavat resursseja, vaikka niitä ei enää tarvita, ja tuottavuutta menetetään, kun kehittäjät joutuvat vaihtamaan fokustaan työkalusta toiseen. Ehkä vielä pahempaa on, että erityisesti monitorointi- ja tiedonjakotyökalujen kohdalla johtajat voivat tehdä vääriä päätöksiä, koska he keskittyvät vain pieneen määrään työkaluja ja hakevat vastauksensa väärästä työkalusta.

Tämän ongelman yksi osa-alue on omistajuus. Työkalulla on oltava tiimi, ei yksittäinen henkilö, joka vastaa sen hallinnasta, päivityksistä ja yleisistä käyttötapauksista. Tiimin on seurattava käyttöä tarkasti ja varmistettava, ettei työkalua käytetä sovitun ja määritellyn käyttötarkoituksen ulkopuolella. Ilman tällaista vastuutiimiä työkalun käyttö alkaa hajautua, ja ajan myötä sillä katetaan kaikenlaisia epäsäännöllisiä käyttötapauksia. Tämä aiheuttaa paljon hämmennystä koko kehitystiimissä ja vaikeuttaa ylläpitoa.

Eräs yritys huomasi olevansa lähellä repositoryjen tallennustilarajaa, koska pilvirepositoryilla ei ollut selkeää omistajaa eikä niiden käyttöön ollut selkeitä ohjeita. Yksi tiimi oli ladannut niihin suuren määrän binääritiedostoja. Tilanteen korjaaminen ja binääritiedostojen siirtäminen Artifactoryyn tuli paljon kalliimmaksi kuin Artifactoryn käyttäminen alun perin.

Tiedon jakaminen: Yhteinen ymmärrys on yksilöllistä asiantuntemusta parempi.

Tieto uuden työkalun käytöstä ja ylläpidosta on jaettava ja pidettävä ajan tasalla kaikissa asiaankuuluvissa tiimeissä. Tämä voi näkyä suoraan kustannuksina tai tehtävien viivästymisinä, mutta kustannus on aina olemassa.

Uusi ohjelmointikieli on erityistapaus: Hyvä kehittäjä pääsee alkuun minkä tahansa uuden kielen kanssa muutamassa päivässä, mutta sujuvuuden saavuttaminen vie silti kuukausia tai vuosia. Siihen asti eteen tulee aikaa vieviä refaktorointitehtäviä, kun uuden kielen koodia mukautetaan vastaamaan nykyisiä laatustandardeja ja parhaita käytäntöjä.

Kysymykseen siitä, miten uutta työkalua käytetään yhdessä nykyisten työkalujen kanssa, on vastattava huolellisesti. Muuten villin lännen kaltainen käyttö voi vaikeuttaa tai jopa estää datavirtojen seurannan. Ajatellaan yllä olevaa binääriesimerkkiä: Git-repository ei selvästikään ole niille hyvä käyttökohde. Monet uudet työntekijät joutuivat käyttämään lisäaikaa asian selvittämiseen kantapään kautta. Datan sijainnin tutkiminen kesti kauemmin, koska dataa ei säilytetty ilmeisessä paikassa, ja tallennustilarajojen monitoroinnin – jos se olisi ollut käytössä – olisi pitänyt tietää kahdesta tallennustyypistä.

Mutta tekoäly korjaa sen!

Tämä näkemys on suosittu monissa yrityksissä, jotka ovat hävinneet taistelun monimutkaisuutta vastaan, mutta se on myös väärä. Tekoälyn lisääminen kaaoksen päälle tarkoittaa lopulta vain uuden, entistä vähemmän hallittavan monimutkaisuuskerroksen lisäämistä. Jos monimutkaisuus on kasvanut pisteeseen, jossa yksikään ihmistiimi ei enää pysty ymmärtämään, mitä tapahtuu, istut tikittävän aikapommin päällä.

Arvostan suuresti tekoälytyökalujen käyttöä päivittäisessä työssäni ja suosittelen käyttämään niitä monimutkaisuuden hallintaan ja vähentämiseen sen sijaan, että sitä lisättäisiin sokeasti.

Näin pysyt fokusoituneena

Kun joku haluaa lisätä uuden työkalun työkalukokonaisuuteesi, pysähdy ja kysy:

• Tarvitsemmeko sitä todella?

• Mitkä ovat kokonaiskustannukset, mukaan lukien ylläpito ja oppimiskäyrä?

• Voimmeko saada riittävän hyviä tuloksia hyödyntämällä nykyisen työkalun ominaisuuksia?

• Mikä on todellinen hyöty tuotteelle?

Kysy sitten jonkin ajan kuluttua samat kysymykset jokaisesta jo käytössä olevasta työkalusta ja karsi työkalukokonaisuuttasi kuten Bruce Lee harjoitteli potkujaan: keskittymällä siihen, mikä todella toimii taistelussa.

Kun otat uuden työkalun käyttöön, tee ensin MVP (ei POC) ja esitä itsellesi kysymykset vasta MVP:n jälkeen. Saat todennäköisesti uusia oivalluksia, ja on hyvin mahdollista, että huomaat, ettet tarvitse uutta työkalua.

Lopeta 9 999,9 potkun harjoittelu ja keskity siihen yhteen, joka todella toimii taistelussa.