Näin lisäät antifragiliteettia DevOpsin avulla

Kun kaikkia tällä hetkellä velvoitetaan työskentelemään kotoa käsin, järjestelmämme ja prosessimme joutuvat uudenlaiseen paineeseen. Yhdessä yössä olemme siirtyneet toimistoissa rinnakkain työskentelystä etätyöhön ja yksin työskentelyyn. Työskentelytapojemme järjestelmätason haavoittuvuudet, jotka olivat aiemmin näkyvillä mutta jäivät huomaamatta, ovat nyt paljastuneet.

Toimistolla kaikki oli helposti saatavilla. Yhtäkkiä kriittisten tietojen ja järjestelmien, kuten projektidokumentaation, lähdekoodin, testitapausten ja testiympäristön, käyttöön pääsyssä on ongelmia. Pysähdy hetkeksi miettimään, miten nämä on dokumentoitu ja jaettu organisaatiossasi. Jos tarvitsisit niitä juuri nyt, miten pääsisit niihin käsiksi? Entä muut tiimiläiset? Onko heillä pääsy niihin?

Antifragiliteetti vs. robustius

Jos käytössäsi ei ole järjestelmiä häiriötilanteiden hallintaan, odottamaton tapahtuma, kuten covid-19-pandemia, voi pysäyttää ohjelmistokehityksen kokonaan. Tämä johdattaa meidät antifragiliteetin ja robustiuden kysymykseen.

Puutteellisesti dokumentoitu ja ylläpidetty järjestelmä on hauras viinilasin tavoin: molemmat kestävät vain vähän rasitusta. Organisaatiot, jotka olisivat ehkä pystyneet selviytymään yhden tai kahden työntekijän poissaolosta, joutuvat nyt toimimaan tilanteessa, jossa poissa on huomattavasti useampia. Hauras järjestelmä rikkoutuu.

Näin voi käydä myös näennäisesti ”robusteille” järjestelmille, sillä antifragiliteetti ja robustius eivät ole synonyymeja. Vaikka robusti järjestelmä kestää enemmän rasitusta kuin hauras järjestelmä, molemmilla on kiinteä yläraja rasituksen sietämiselle. Antifragili järjestelmä sen sijaan vahvistuu altistuessaan yhä suuremmalle rasitukselle. Tämä ei tarkoita, ettemmekö haluaisi robustia järjestelmää – totta kai haluamme! – mutta se, mitä todella haluamme, on antifragiliteetti.

Antifragiliteetin rakentaminen

DevOps valmistaa organisaatiosi kohtaamaan kuormittavia tilanteita, mikä on olennainen osa antifragiliteetin rakentamista. Joka kerta, kun selviydyt onnistuneesti kriisistä ja hyödynnät opit organisaation tai järjestelmien kehittämiseen, antifragiliteettisi kasvaa. DevOpsin käytännöt auttavat rakentamaan järjestelmän, joka on sekä robusti että vahvistuu reagoidessaan kriiseihin.

Miltä tämä sitten näyttää käytännössä? Miten DevOpsin avulla tehdään olemassa olevasta kehitysorganisaatiosta antifragilimpi? Huomioon on otettava kolme keskeistä asiaa: ohjelmistotuotantolinja, sitä käyttävät ihmiset ja sen suorituskyvyn monitorointi.

1. Tuotantolinja

Antifragiliteetin edellytys on keskitetty alusta, jossa kaikki olennaiset työkalut ovat koko tiimin tiedossa. Jos yksittäinen tiimin jäsen ei ole käytettävissä, hänen työnsä on helppo ottaa haltuun, koska kaikki tuntevat työkalut. Tämä helpottaa resurssien uudelleenkohdentamista.

Organisaatiosi tarvitsee ohjelmistotuotantolinjan, joka mahdollistaa dokumentaation luomisen välttämättömänä sivutuotteena. Kaikkien vaatimusten ja työnkulkujen tulisi sisältyä dokumentaatio- ja tikettienhallintaratkaisuihin. Lähdekoodin, ympäristöjen ja testitapausten tulisi olla versionhallinnassa, ja binäärien erillisissä repositorioissa.

Jos jokainen tiimi käyttää omia työkalujaan ja noudattaa omia käytäntöjään, antifragiliteettia on todella vaikea rakentaa koko organisaatioon. Yhtenäinen, hyvin rakennettu tuotantolinja on suunnittelultaan antifragili, ja se on ensimmäinen asia, joka kannattaa rakentaa. Kun jokainen tiimin jäsen voi muuttaa ja parantaa tuotantolinjaa häiriön ilmetessä, jokainen muutos parantaa järjestelmän kykyä kestää tulevien häiriöiden aiheuttamaa rasitusta.

2. Ihmiset

Kun käytössäsi on keskitetty tuotantolinja, sinun on varmistettava, että kaikilla on pääsy kaikkeen tarvitsemaansa. Varmista myös, että se on optimoitu tekemään kehittäjien työstä mahdollisimman helppoa.

Ensinnäkin tämä tarkoittaa, että jokaisen projektin vaatimuksissa ja työnkuluissa on hyödynnettävä tuotantolinjalla saatavilla olevia työkaluja. Keskitetyn alustan rakentamisessa ei ole järkeä, jos yksittäisten projektien annetaan sen jälkeen ottaa käyttöön uusia työkaluja, jotka eivät näy muulle organisaatiolle. Silloin suuri osa hyvästä työstä on tehty tyhjäksi ja antifragiliteetti heikentyy. Joissakin tapauksissa, esimerkiksi testauksen ja käyttöönottojen automatisoinnissa, työkalujen joustavuus on kuitenkin tarpeen. Haasteena on löytää oikea tasapaino yhteisten ratkaisujen ja tietyille tiimeille räätälöityjen ratkaisujen välillä.

Työkalujen yhdenmukaisuudesta on huolehdittava, ja niiden käyttöön on sovellettava korkeaa automaation tasoa. Tavoitteena tulisi olla, että kaikki kriittinen projektidokumentaatio tallennetaan versionhallintaan ”koodina” ja on avoimesti koko tiimin saatavilla. Helposti skaalautuvien pilviympäristöjen sekä testiautomaation tulisi olla käytettävissä Continuous Deliveryn tukemiseksi. Automaatiokoodi parantaa robustiutta toimimalla omana dokumentaationaan ja vähentää erillisen kirjallisen dokumentaation tarvetta – dokumentointi jää usein tekemättä.

Myös hyvän näkyvyyden tulisi olla keskeinen ominaisuus – ei vain oman kehitystyön, vaan myös muiden tekemisen osalta. Tilannetiedot tulisi kerätä automaattisesti tuotantolinjalta ilman manuaalista raportointia. Monissa yleisesti käytetyissä työkaluissa tämä on valmiina ominaisuutena.

Kun teet jokaisen tiimin jäsenen työstä mahdollisimman helppoa, lisäät antifragiliteettia. Kun tuotantolinja on helposti saavutettavissa ja mahdollisimman monet manuaaliset tehtävät on automatisoitu, kriisiin sopeutuminen on helppoa sen ilmaantuessa. Häiriöiden tapahtuessa organisaatio voi myös arvioida suunnanmuutoksia ja parantaa edelleen kykyään kestää rasitusta.

3. Monitorointi

Antifragiliteetin rakentaminen edellyttää jatkuvaa parantamista ohjelmistotuotannossa. Mutta mihin kehitystoimet kannattaa kohdistaa? Mistä tiedät, missä mahdolliset heikot kohdat ovat? Siksi tarvitset monitorointia. Se on DevOpsin kolmas osa-alue, jonka avulla voit tehdä järjestelmästäsi entistä sietokykyisemmän.

On tärkeää seurata, miten ohjelmistoa rakennetaan, mutta yhtä olennaista on seurata myös sen käyttöönottoa ja todellista käyttöä tuotannossa. Kehityksen seuranta auttaa näkemään, mitkä projektit ja henkilöt noudattavat sovittuja toimintatapoja. Se antaa myös tietoa kehittyvistä hyvistä toimintatavoista ja parhaista käytännöistä, joita voidaan soveltaa muissa projekteissa. Kun jokainen projekti omaksuu muiden projektien vahvuudet, ne vahvistuvat tasavertaisesti. Tämä korjaa monia yksittäisiä heikkouksia koko organisaatiossa ja lisää antifragiliteettia.

Opsin monitorointi toimii ennakkovaroitusjärjestelmänä tunnistamalla ongelmat ennen kuin ne karkaavat hallinnasta. Ongelmat on luonnollisesti parempi havaita itse kuin saada niistä tieto käyttäjiltä. Käyttöönotot kannattaa integroida monitorointityökaluihin ja lokianalyysiin, jotta saat kattavasti tietoa tuotteen tilasta. Riittävän monitoroinnin avulla voit usein tunnistaa ongelmaketjun juurisyyn sen sijaan, että hoitaisit vain yksittäisen ongelman oireita. Tämäkin lisää merkittävästi antifragiliteettia.

Tuotantoon viennin jälkeen kannattaa seurata käyttäjien toimintaa, kun he saavat käyttöönsä uusia ominaisuuksia. Lisääkö uusi ominaisuus liikennettä, konversioita ja lopulta liikevaihtoa? Tuotannosta kerättyä dataa voidaan hyödyntää yhdessä design-ajattelun, A/B-testauksen ja käyttäytymispsykologian kanssa tulevien julkaisujen optimointiin.

Kuinka antifragili organisaatiosi on?

Nykyisen covid-19-epidemian odottamattomuus tarkoittaa, että monet organisaatiot selvittävät parhaillaan reaaliajassa, kuinka antifragileja ne ovat. Kriisistä selviytyvillä on hyvät valmiudet vastata myös tuleviin tapahtumiin. Monella tapaa kyseessä on äärimmäinen stressitesti ja erinomainen – vaikkakin ei-toivottu – oppimismahdollisuus.

Antifragiliteetin rakentamisessa on kyse siitä, miten reagoimme kriiseihin. Kun keskität ohjelmiston tuotantolinjan keskeiset työkalut ja käytät helposti saatavilla olevaa, yhteistä työkalukokonaisuutta, olet jo matkalla kohti antifragiliutta. On kuitenkin virhe ajatella, että keskitetty järjestelmä ratkaisee yksin kaikki ongelmat. Ilman omistautunutta ylläpitoa keskitetty järjestelmä heikentää antifragiliteettia, koska koko organisaatio on riippuvainen yhdestä huonosti ylläpidetystä järjestelmästä. Joidenkin työkalujen valinnassa on myös tehtävä poikkeuksia. Olennaista on olla joustava tilanteen niin vaatiessa.

Myös kulttuuri on elintärkeää. Kun annat tiimin jäsenille paremmat edellytykset toimia ja kannustat jatkuvan parantamisen tapoihin, koko järjestelmästä tulee hieman antifragilimpi jokaisen pienenkin ongelman myötä.