Jeg tenkte å beskrive min definisjon av hva som jeg mener er viktig med Observability ved å fortelle en liten historie.

Jeg var «Observability Manager» i det norske selskapet SuperOffice i fire år. Der bygget jeg Observability-området og endte opp med noe helt annet enn jeg hadde sett for meg da jeg startet. Det hele startet som et tradisjonelt Observability prosjekt; instrumentere kildekoden, finne områder i applikasjonen som oppførte seg rart, gav brukerne feilmeldinger, og så videre. Vi etablerte en «squad» med løsningsarkitekter og utviklere som annenhver uke satt seg sammen med meg og brukte Observability løsningen til å prioritere hva de skulle jobbe med relatert til teknisk forbedring av plattformen den neste sprinten.

En genistrek vi gjorde var at vi satt opp et dashboard foran kontorene til ledelsen. Når det så var ting vi ikke syntes fikk nok prioritet til å fikses, så endret vi dette dashboardet til å fokusere på de områdene, vise med klare tall og kundenavn hvorfor det var viktig å fikse problem X eller Y. Dette dashboardet ble da stadig en møteplass der man diskuterte grafene og ble enige om at her måtte man prioritere.

Så etter et års tid begynte vi å få svært god kontroll på den tekniske kvaliteten til SuperOffice. Da begynte jeg å se meg om etter andre områder de enorme datamengdene vi hadde kunne brukes. Jeg så for eksempel at når vi lanserte en ny funksjon, så kunne jeg lage et dashboard som viste ikke bare om den nye funksjonen fungerte som den skulle, men også hvilke av SaaS kundene våre som tok den i bruk, hvor mange brukere hos hver kunde og om de fortsatte å bruke funksjonen. Dette gjorde at jeg etterhvert fikk faste statusmøter med alle mulige deler av organisasjonen, ikke bare utvikling og drift. Igjen var dette dahboardet i gangen viktig, jeg endret innholdet i dette etter hver sprint slik at vi viste både teknisk og bruksdata på skjermen, og diskusjonene med en kaffekopp i hånden gikk plutselig på tvers av interessegrupper i bedriften.

Vi investerte ikke i veldig dyre Observability-verktøy, vi baserte oss på Azure Application Insights med en god del definering av custom events, Power BI for presentasjonslag og noen API'er fra andre styringssystemer for å sammenstille tekniske data med forretningsdata.

Vi brukte også Digital Experience Monitoring til å ha proaktive, simulerte sluttbrukermålinger på morgenkvisten hver eneste dag med Apica Synthetic Monitoring.

Resultatet ble en løsning som gav verdi til hele organisasjonen, utvikling, drift, salg, marked og ikke minst som styringsverktøy til ledergruppa. Det viktigste var egentlig ikke verktøy-valgene vi gjorde, men prosessene vi etablerte og at vi fant et bredt bruksområde for det vi samlet inn av data slik at vi skapte verdi.

Kanskje du ikke skal investere mye i Observability idag, eller i imorgen, men det er bare å forberede seg med en gang, så her er tre tips:

• Start smått med å sikre at dere bruker åpne nok verktøy for metrikker, hendelser og logger idag. Fokuser på sluttbrukermålinger! Dere vil trenge dem rundt neste sving når Observability-verktøyene har landet etter den første hype-bølgen og blir obligatorisk hyllevare hos IT-avdelingen.
• Når du har måledata, sett et ekstra fokus på forretningsverdi. Ikke la deg blende av verktøyleverandørenes eksempler på exception-logging og trege metodekall. Bruk operasjonelle data til å vise noe som gir verdi til forretningen, altså de som sitter på pengesekken.
• Følg med på min Observability-nyhetsbot på Mikrobloggen eller i ukessammendraget jeg legger ut på LinkedIn på fredager. Det er mye gull i bloggposter fra de forskjellige verktøy-leverandørene så lenge du tar salgsbudskapene med en klype salt

Var dette interessant? Les også min forklaring av Digital Experience Monitoring.