Kattavien telemetriakäytäntöjen liiketoiminnalliset hyödyt

Pasi Huuhka | 04.12.2020
Lukuaika 8 min

Vuosien varrella erilaisten applikaatioiden kanssa työskennellessäni olen huomannut, että niin asiakkailla kuin kehittäjillä on taipumusta vähätellä hyvin mietittyjen metriikka- ja logituskäytäntöjen tärkeyttä tuotekehitysprosessissa. Näiden implementointia pidetään usein viimeisenä asiana ennen tuotteen lanseerausta, kun suurin osa budjetista on jo käytetty. Ongelma näkyy varsinkin projektityössä, jossa työn raamit on määritelty  jo ennen kuin edes ongelman ratkaisemista aloitetaan.

Tällainen ajattelutapa on kuitenkin helppo ymmärtää. Kuten monen muunkin DevOps-ajattelutavan prosessin kanssa, telemetrian hyödyntäminen ja arvon louhiminen voi viedä suhteellisen paljon aikaa, ennen kuin konkreettiset tulokset näkyvät projektin sisällä. Miksi haluisimme käyttää aikaa dashboard-näkymien tai hälytyslogistiikan rakentamiseen? Mehän näemme jos tuotteemme antaa 503-virheitä!

Joku voisi myös argumentoida, että optimisointi pitäisi aloittaa siitä, mikä sattuu eniten. Vaikka olenkin osittain samaa mieltä tuon väitteen kanssa, on harmillisen usein tilanne se, että puutteellinen monitorointi huomataan vasta silloin, kun jotain on jo mennyt pahemmin pieleen.

Tässä postauksessa yritän avata muutamia näkökulmia siitä, miten laaja-alainen ja kattava telemetria sekä tuotettu palaute auttavat kehitysprojektia toimimaan ketterämmin, julkaisemaan koodia useammin, johtamaan nopeampaan pääsyyn markkinoille ja ehkä jopa muuttamaan tiimisi kehityskulttuuria parempaan suuntaan.

Data pitää applikaatiosi pystyssä

Katarina Engblom, Microsoftin Suomen One Commercial Partner-organisaation johtaja, sanoi osuvasti alkuvuodesta julkaistussa Ikkunastudio-podcastin jaksossa, että ”Datan omistajuus kuuluu toimitusjohtajalle”. Mielestäni tämän ajattelun ei pitäisi päteä pelkästään liiketoimintadataan, vaan myöskin teknisen datan keräyskäytäntöjen standardisointiin organisaatiossa. On erityisen tärkeää tuoda kaikki samalle pohjatasolle, samalla kun tiimien itsehallitsemiskykyä implementaatioyksityiskohdissa korostetaan ja kannustetaan.

Ikävä kyllä liian usein realiteetti on, että osuudet jopa organisaation tärkeimmistä arvovirroista eivät tuota minkäänlaista liiketoiminnalle näkyvää teknistä pohjadataa. Pahimmissa tapauksissa ongelmatilanteessa järjestelmän palautusajat voivat olla katastrofaalisia, kun hyvää tapaa paikallistaa ongelmaa ei ole.

Peukkusääntönä teknisten tiimien olisi tärkeä varmistaa, että heiltä löytyy yhteisesti noudatettava tapa paikantaa ongelmat niiden juureen, eikä vain suoraan käynnistää koneita tai kontteja uudelleen. Tätä vastaan toisaalta väittää ajattelutapa, jossa pilvinatiivissa maailmassa tie toimivaan applikaatioon on mieluummin tappaa rikkinäinen worker-node ja pystyttää tilalle uusi, miettimättä niinkään hajonneen kappaleen kohtaloa. Saavuttaaksesi molempien ajattelutapojen hedelmät, on ainoa tapa yhdistää telemetriadatan keräys sekä rikkinäisten nodejen erottelu syrjään myöhempää vianselvitystä varten.

Ydinajatuksena on, että jos dataa tietyn osan toiminnasta ei kerätä ja seurata, ei myöskään ole mahdollista varmentaa, että se toimii halutulla tavalla. Tästä johtaen voimme myös huomata, että mitä aikaisemmin dataa aletaan keräämään, sitä paremmin pystymme arvioimaan muutoksien vaikutuksen applikaation toimintakykyyn tai toiminnallisuuteen.

Ongelmista on hankalaa saada kiinni ilman telemetriaa

Pohjatasolla niinkin yksinkertainen asia, kuin telemetriapalvelun kuten Application InsightsStatsD tai Prometheus lisääminen järjestelmääsi antaa jo suoraan oletuksena valtavan määrän datapisteitä kerättäväksi. Jäljelle jää vain selvittää, mitä näistä kyetään käyttämään hyödyksi tuottamaan sellaista näkymää järjestelmän toimintaan, jonka perusteella voidaan tehdä muutoksia tilanteen parantamiseksi. Edellä mainitut työkalut ovat äärimmäisen kyvykkäitä, ja mahdollistavat myös räätälöityjen ajastimien ja laskureiden luonnin vain yhden koodirivin vaivalla.

Samaa käytäntöä pitäisi myös noudattaa kaikissa järjestelmäsi ympäristöissä. Vaikka tuotantoa vastaavan liikenteen tuottaminen kehitysympäristöissä onkin usein hankalaa, jo pienikin määrä voi johtaa bugin löytämiseen ennen kuin se johtaa ongelmiin. Tätä liikenteen puutetta voi tiettyyn pisteeseen asti helpottaa implementoimalla end-to-end-tyylistä testausta niille osa-alueille, jotka vastaavat applikaation päätoiminnoista.

Telemetrian seuraaminen myös pitää applikaatiosi pystyssä. Puppetin 2015 luoman State of DevOps-raportin mukaan yritykset, jotka ovat ottaneet yhteneväiset ja kattavat telemetriakäytännöt työkalupakkiinsa ovat 168 kertaa nopeampia palauttamaan järjestelmänsä toimintakykyisiksi verrattuna niihin yrityksiin, jotka eivät tätä tee. Vuoteen 2019 mennessä tämä aukko vastaavien yritysten välillä on vain kasvanut, ja DORA:n Accelerate State of DevOps report paljastaakin, että Elite Performers-ryhmän yrityksien palautusaika-aika (Mean time to recover, ”MTTR”) on alle yhden tunnin, kun taas Low Performers -ryhmän yrityksillä samaan kuluu keskiarvolta viikosta kuukauteen.

Yritykset, jotka ovat ottaneet yhteneväiset ja kattavat telemetriakäytännöt työkalupakkiinsa ovat 168 kertaa nopeampia palauttamaan järjestelmänsä toimintakykyisiksi verrattuna niihin yrityksiin, jotka eivät tätä tee.

Koodin tuotantoon vientien säännöllisyys kertoo samanlaista tarinaa. Vaikka monitorointi / monitoroinnin integrointi toisten työkalujen kanssa ei yksinään selitä eroja tässä mittarissa yritysten välillä, ovat ne mahdollistavia tekijöitä kehittyneempien DevOps-kyvykkyyksien rakentamisessa. Esimerkkejä näistä voisivat olla vaikkapa kaaostestaus ja automaattiset järjestelmän parantumiskeinot, jotka molemmat omat omiaan parantamaan kehitystiimien luottamusta automaattiseen julkaisuprosessiin.

Ketä varten lopulta kehität?

Monessa projektissa, joista olen keskustellut alan ihmisten kanssa, tietyn featuren valmiusmäärittely jää helposti tasolle ”tekeekö feature sen toiminnallisuuden, jonka haluamme sen tekevän?”. Erityisesti tämä tuntuu vaivaavan liiketoimintasovellusten kehitystiimejä.

Vaikkakin tämän tyylinen suunnittelu voi varmasti johtaa toimivaan tuotteeseen, se jättää huomioimatta kaksi tärkeää aspektia: Miten luotettava kyseinen feature tarvitsee olla, ja kuinka voimme varmentaa käyttäjien tyytyväisyyden siihen. Käyttäjien tyytyväisyys on tunnetusti hankala tarkentaa tiettyihin asioihin, mutta tähän auttaa huomattavasti Service Level Objective-ajattelu (SLO).

Lainaten ja kääntäen Googlen The Site Reliability Workbook”-kirjaa:

SLO asettaa luotettavuuden kohdetason palvelun käyttäjille. Tämän kohdetason ylittyessä lähes kaikkien käyttäjien pitäisi olla tyytyväisiä palvelun toimintaan (olettaen, että he ovat muuten tyytyväisiä sen toiminnallisuuksiin). Sen alittuessa taas käyttäjät ovat alttiita alkaa tekemään valituksia, tai jopa lopettamaan koko palvelun käytön täysin. Lopulta, käyttäjien tyytyväisyys on se, millä on merkitystä – tyytyväiset käyttäjät käyttävät palvelua, tuottavat organisaatiolle liikevaihtoa, ovat vähemmän vaativia asiakaspalvelutiimejä kohtaan ja suosittelevat palveluasi ystävilleen. Pidämme palvelumme luotettavina, jotta asiakkaamme pysyisivät tyytyväisinä.

Kun olemme määrittäneet sopivan SLO:n, meidän pitää selventää kaksi asiaa: palvelutason indikaattorit (Service Level Indicators, SLI), jotta voimme ymmärtää pääsemmekö SLO:n asettamiin tavoitteisiin, sekä saada sidosryhmien hyväksyntä noudattaa sovittua kohdetasoa. Näin varmistamme, että meillä on mandaatti priorisoida korjaustoimenpiteitä, jos haluttu taso ei täyty.

SLI:t ovat yksinkertaisuudessaan datapisteitä, jotka päätämme olevan tärkeitä asiakkaidemme käyttökokemukselle. Esimerkiksi voitaisiin ajatella seuraavia:

  • Latenssi – Miten nopeasti featuremme lataa?
  • Saavutettavuus – Miten suuri prosentti kutsuista palauttaa onnistuneen http-koodin?
  • Laatu – Miten suuri prosentti sivulatauksista palauttaa oikeat kuvat, eikä placeholder-kuvia?
  • Ajantasaisuus – Miten suuri prosentti sivunlatauksista palauttaa dataa, joka on ajantasaisempaa kuin 5 minuuttia?
  • Oikeellisuus – Miten suuri prosentti datan käsittelyputkeen syötetystä tavarasta palauttaa oikeita tuloksia?

Näiden lisäksi voitaisiin myös käyttää muita käytönseurantatyökaluja, kuten Microsoftin Clarity, jotta voisimme ymmärtää käyttäjiämme paremmin. Kuten tekstistä on nyt tähän asti varmaankin jo selvinnyt, ainoa tapa tälläiseen ajattelutapaan siirtymiseen on ensin kerätä haluttua dataa järjestelmistämme.

Loppujen lopuksi sovelluksen käyttäjät ovat pitkässä juoksussa yksi tärkeimmistä asioista sovelluksen kokonaisuutta ajatellessa. Vaikka voitaisiinkin väittää, että tämä on totta vain asiakkaile suunnatulla sovelluksella (koska sisäisten työkalujen käyttämistä ei usein pysty lopettamaan tuosta noin), pitää sisäisten sovellusten kanssa muistaa myös SLOista kiinnipitämisen mahdollistamat käyttäjien tehokkuushyödyt, jotka voivat johtaa suuriinkin rahallisiin hyötyihin isossa kuvassa. Totta kuitenkin on, että tuota rahallista arvoa on hankalampaa mitata, varsinkaan lyhyellä ajanjaksolla.

Kohti parempaa työkulttuuria

Kaksi DevOps-ajattelun ydinajatusta (ainakin omasta mielestäni) ovat tiimien voimaannuttaminen – mahdollistaen heille kyvyn toimia itsenäisesti ja mahdollisimman pienellä määrällä byrokratiaa – ja avoin näkyvyys organisaation sisällä. Tämä ei koske vain teknisiä tiimejä, vaan samaten myös liiketoimintaa ja tukifunktioita.

Miten näkyvyyttä sitten voi parantaa? Nyt kun sinulla on telemetriaa järjestelmästäsi, seuraava askel on valjastaa se näkyväksi kenelle tahansa, ketä se voi kiinnostaa. Asiakkaille, Vierailijoille, Kehittäjille, Ylläpitäjille, Liiketoiminnalle? Kaikille. Luonnollinen tapa tehdä tämä on luoda dashboard-näkymiä, jotka yhdistävät liiketoimintadataa sekä teknistä dataa. Lisäksi voidaan näyttää ennustavaa tietoa, kuten esimerkiksi odotettuja toimintakyvyn väliaikaisia heikkenemisiä tulevan koodijulkaisun jälkeen.

Näiden dashboard-näkymien (ja alla olevan datan) avaaminen kaikille tuo lukuisia hyötyjä:

  • Viestit katsojille, että sinulla ei ole mitään piilotettavaa keneltäkään. Samalla kasvatat yleistä kiinnostusta projektiasi kohtaan, ja kannustat osallistumista kaikilta organisaation sisällä.
  • Korotat mahdollisuuksiasi löytää vaikeasti nähtäviä bugeja: Ehkäpä henkilö liiketoiminnan puolelta huomaa jotakin outoa, mitä tekniset tiimit eivät ole osanneet huomioida. Esimerkiksi ”aiemmin myydyin tuotteemme ei saa enää liikennettä samaan tapaan”.
    • Mahdollistat nopeamman palautteen saamisen tuotetiimeillesi siitä mikä toimii, ja mikä ei. Tämä johtaa nopeampaan iterointiin ja parannuksiin.
  • Korostat kulttuuria, jossa ei syytellä muita, mahdollistaen päätösten teon oikean datan ja tieteellisen päättelyn pohjalta.
  • Saat uuden tavan viestiä huoltokatkoista ja ongelmista
  • Voit liittää liiketoiminnan KPIt, SLOt ja SLI:t suoraan näkymiin, ja pystyt käyttämään tätä dataa parempaan päätöksentekoon työn priorisoinnissa

Tiedät olevasi hyvässä tilanteessa, kun SLO:si on määritelty ja seurattu, ja samalla aikaa pystyt varmentamaan mahdollisuutesi päästä niiden asettamiin tavoitteisiin lyhyellä aikavälillä sekä ylläpitää sitä pitkällä aikavälillä. Tämä avaa uusia tapoja käyttää kehitystiimisi aikaa, esimerkiksi automatisoimaan manuaalisia tai toistettavia tehtäviä (eliminating toil) tai kehittämään uusia toiminnallisuuksia.

Pitkässä juoksussa nämä parannukset voivat olla oleellinen tekijä vähentämään työntekijöidesi stressiä ja mahdollisuuksia burnouttiin. Samaten sana kulttuuristasi kiirii eteenpäin, tuoden mukanaan halukkaita rekrykandidaatteja organisaatiollesi.

Yhteenveto

Postauksesta tuli lopulta hieman paasaavampi kuin olin ajatellut, mutta pähkinänkuoressa ajatukseni voi kiteyttää seuraavasti:

  1. Telemetria on elintärkeää, suoraan projektin tai tuotteen kehityksen alkutaipaleelta.
  2. Vaikka oikeiden asioiden mittaamiselle on vaikeaa asettaa tarkkaa rahallista arvoa, se on lähes taatusti omiaan puskemaan organisaatiosi sovelluskehitystoimintatapoja parempaan tuottavuuteen.
  3. Avoin datan saatavuus on olennaista organisaatiokulttuurin muuttamiseen, ja toimii vastavoimana siilojen rakentumiselle.

Resursseja jatkolukemiseksi

The DevOps Handbook

The Site Reliablity Workbook

The Unicorn Project