Et forsøk på å løse “hvem eier den tjenesten der?” med noen tommelfingerregler og backstage 👍👎
Vi har alle vært der
“Det vi trenger er en oversikt over tjenestene våre”, sier den ene. En av de andre sier: “Jeg tror vi har noe liggende i confluence om det. Kanskje vi kan bruke den og friske opp litt?” I virkeligheten ligger det sikkert flere sånne oversikter i confluence. Og noen excel-ark. Og kanskje noen word-tabeller. Drøssevis av greier.
Jeg har lyst til å dele noen tanker og erfaringer rundt eierskap, noen enkle regler for å kanskje få gjøre det lettere å få til og et forsøk på å få has på den hersens utdaterte oversikten.
Del 1: Ei det
Diskusjonen dukka opp fordi tjeneste X ikke funker. Noen tenkte at Team Vollgrav (oppdikta navn) var ansvarlig, men de trodde Team Borgtårn holdt i tøylene. Det viser seg til slutt at ved forrige omorganisering glemte man å fordele litt ansvar. Man ble enige om det meste, men et par tjenester var vanskelig å lande og med tiden glemte man de også litt. En av tjenestene er det jo de fra det gamle Team Bro (som nå ikke eksisterer lenger) som hadde. Det er jo de folka som kunne det. Men det viser seg jo at de driver med andre ting, Team Bro er jo historie for lengst.
Det er ikke bare én gang jeg har havna i en eller annen variant av det her. Det er ikke med vilje, men det skjer likevel. Resultatet er tjenester som enten sier pang og går i stykker, eller kanskje de er potensielle sikkerhetsrisikoer. Man må uansett bruke masse energi på å gå opp eierskapet når noe dukker opp, siden det ikke ble tatt i den originale runder av ansvarsfordeling.
Reglene
Så! Hvordan kommer vi dette til livs? Hvordan får vi tydelig eierskap og folk til å bry seg og føle at de må ta tak i ting? At det ikke er noen andre som gjør det. Jeg har tro på at det gir et bedre klokkeklart bedre produkt i den andre enden. Grunnene er for mange til å gå inn på her, men tenk på din egen organisasjon og hva det gjør/hadde gjort.
Personlig har jeg troa på noen prinsipper jeg har lært og kjemper for.
1. Det er én, og bare én eier (som er et team)
Hvis flere eier noe, så eier ingen det. I hvert fall når det kommer til vedlikehold. Da tenker man alltid at “de andre” tar det. Men også for koden ellers. Det er ingenting i veien for å samarbeide, men hvis noen andre hele tiden gjør endringer man ikke ser, skjønner eller forstår føler man ikke voldsomt eierskap for den koden. Da slutter man å bry seg. Kanskje forfaller ting. En og bare en.
2. Du kan ikke gi fra deg ansvaret uten at det overleveres til noen andre
Den neste regelen er for å unngå “orphans”: Tjenester uten eiere. Kanskje man har bytta navn og ansvarsområder for teamene? Vel da må de eksisterende tjenestene fordeles til andre/nye team. Ja, alle sammen. Nei, det passer kanskje ikke like bra inn i den nye oppdelingen, men det må fordeles likevel. Nei, det kan ikke plasseres hos flere teams. Én og bare én.
3. Det går bra å ha noe man ikke skjønner eller kan helt
Hvis man skal fordele ting på denne måten vil man ha noen ting “ingen” kan eller vil ha. Hva gjør man da? Jeg synes bare man skal fordele dem, jeg. Det er litt skummelt å eie noe man ikke kan. Samtidig, det at du kjenner på den følelsen betyr også at du føler på et eierskap. Riktignok et vondt ett, men for organisasjonen er det sunt. Noen bryr seg. Du bryr deg. Det er bra! Så får man ta tak i det når man må forholde seg til den. Kanskje be om litt hjelp, lære litt av de som satt med det en gang. Vi er jo kollegaer, tross alt!
Da vi slipper at tjenestene våre faller mellom to stoler og blir glemt. Vi slipper at det koster masse energi å gå opp eierskap i ettertid. Vi bygger eierskap. Og det tenker jeg er bra det.
Del 2: Ut med excel-arket og inn med Backstage
For de som kjenner backstage.io så tenker man gjerne utviklerportal. Det er det også - faktisk en ganske kul en! I jakten på gode utviklerverktøy tok vi dette i bruk hos en kunde jeg sitter på. Har du ikke sett på det anbefaler jeg å ta en titt. Vi tar en lynrask titt på tjenesteeierskap her, men hvis konsepter som å “samle dokumentasjonen og gjøre den mer tilgjengelig” eller “god templating av nye repoer” er ting du synes høres spennende ut bør du absolutt ta en titt!
Men her skal jeg snakke om bare en liten del av det. Nemlig owner-feltet i speccen. Kan dette få has på de utdaterte oversiktene?
Hos oss settes owner til github-teamets navn. Backstage importerer allerede en del fra github-organisasjonen, inkludert teamene. Det trenger vi ikke vedlikeholde.
En catalog-fil i backstage ser typisk ut som noe slikt:
Det spennende feltet her er altså owner. Fyller vi inn dette i repoene våre i github får vi ting som dette i backstage:
Hvorfor gir dette en bedre oversikt enn excel?
Vel, det er ikke sikkert det er det. Det gjenstår å se om dette hjelper på å løse det eller ikke. Men! Erfaringene vi har fått er:
- Det er digg å ha denne definisjonen kodenær og ikke i separate dokumentasjons-systemer (som confluence). Det er lett å endre og et eventuelt utdatert eierskap synliggjøres, så man får lyst til å rydde opp i det.
- Når medlemmer i team forandrer seg gjør vi jo det i github og det reflekteres automatisk i backstage. Digg.
- Det er lett å lage en liste med “NO-OWNER” tjenester som er synlig og gjør litt vondt.
Én og bare én. Og ett sted hvor eier defineres. Ett sted å lete når du vil finne ut hvem som sitter med noe. Ett sted å se hva du er ansvarlig for. Og ikke minst én eier av tjenesten.
Så får vi se om vi se om en stund om vi får bukt med tvetydig eierskap eller om vi har laget en ny type excel-ark da.