Oppryddingsjau på Team Sanntid — OPS-uka i oktober

DevOps-toget har ankommet mange store og mindre organisasjoner, og de fleste i dag har adoptert denne praksisen i en eller annen form eller grad. Praksisen gjelder som regel i kontekst av autonome produktteam, der teamet har ansvar for både Dev og Ops av sine produkter og tjenester. Team Sanntid i Ruter er intet unntak.

I oktober 2021 ble team Sanntid i Ruter enige om å kjøre en hel uke med kun OPS-oppgaver. I dette innlegget deler vi litt om hvordan vi organiserte arbeidet, hva vi gjorde konkret og hva vi lærte. God lesing!

Hva var bakgrunnen for OPS-uka? Hvordan kom vi på det?

Selv om teamet har som prinsipp å kontinuerlig forbedre DevOps-praksis, merket vi over tid at backloggen av OPS-oppgaver vokste og begynte å plage oss i hverdagen. Noen rotårsaker:

• Nedprioritering av OPS-oppgaver av ulike årsaker som leveransefrister og andre høyt prioriterte oppgaver.
• Voksende teknisk gjeld, som f.eks utdaterte dependencies, spesielt i de mikrotjenestene som ikke trenger funksjonell endring på en stund.
• Større løft på etablerte løsninger og rutiner f.eks knyttet til overvåkning, funksjonell innsikt og Continous Delivery som krever utforskning og påvirker felles verktøy og hver enkelt mikrotjeneste.

Hvordan forberedte vi oss for uka?

Vi definerte 6 områder med oppgaver fordelt i to kategorier: 1) per applikasjon og domene og 2) på tvers av domener.

Fokusområder for Ops-uka, gruppert per applikasjon og domene, og på tvers

Vi brukte metrikker før og etter endringene for å holde oversikt over progresjonen i løpet av uken.

Hvordan sørget vi å få utbytte av uka?

Vi startet uka med en gjennomgang der vi tydeliggjorde bakgrunnen for DevOps-uka og hva vi ønsket å oppnå med den. Dette var viktig for å skape felles forståelse og eierskap til utfordringene og løsningene i hele teamet.

Deretter jobbet vi individuelt eller i små grupper. Noen fikk ansvar for forbedringer i hver mikrotjeneste (prioritering av tjenester skulle gjøres individuelt, basert på funksjonell kritikalitet og metrikker på teknisk gjeld og lignende) og andre jobbet med oppgaver på tvers av domener.

På slutten av uken presenterte vi resultatene og erfaringene fra hele teamet og diskuterte nye måter å løse noen av de store utfordringene vi står ovenfor, som f.eks hvordan vi kan redusere forsinkelse på prosessering av Kafka-meldinger ved restart av tjenester.

Hvilke konkrete resultater fikk vi?

Vi innså ganske raskt at én uke ikke var tilstrekkelig for å løse alle utfordringene vi hadde planlagt. Likevel fikk vi gjort et godt løft innenfor de fleste områdene. Her er noen eksempler:

• Redusering av teknisk gjeld i mikrotjenestene som f.eks oppgradering av avhengigheter, fjerning av deprecated dependencies, produsering av testrapport, sørge for at standard metrikker produseres (som forenkler overvåkning og varslinger).
• Sørget for at README-filer i mikrotjenestene inkluderer autogenererte diagrammer (som et minimum). Dette kan du høre mer om på JavaZone 2021 Automatisert visualisering av dataflyt og konsumenter/produsenter i Kafka.
• Identifisert nye måter å redusere forsinkelser på prosessering av meldinger ved restarts av mikrotjenester som har tilstand og leser/skriver til Kafka.
• Skapt bedre forståelse i hele teamet på hvilken retning vi ønsker å gå mot og hvor viktig det er med kontinuerlig arbeid med OPS-oppgaver.

Hva lærte vi av uka?

• Vi trenger å styrke kultur og fokus på kontinuerlig arbeid med OPS-oppgaver, slik at vi holder teknisk gjeld på et akseptabelt nivå.
• Det er viktig at vi gjør kontinuerlig refaktorering på tjenester som det gjøres funksjonelle endringer i, men likevel ikke glemme de andre som ikke har like høy endringstakt. Jo lenger vi venter, desto mer gjeld må vi betale på én gang neste gang vi skal gjøre en endring.
• Det er lærerikt og motiverende når hele teamet gjør en felles innsats for å forenkle sin egen og hverandres hverdag, og man kan gjøre det i fred og ro uten push på utvikling av nye features. Spesielt gjelder dette for oppgaver som er litt større og krever utforskning med prøving og feiling. Kanskje bør vi kjøre slike dedikerte uker hvert kvartal?

Hvem er Team Sanntid?

Vi leverer sentrale tjenester for sanntidsdata i Ruters digitale plattform. Kort fortalt har vi ansvar for utveksling av sensordata mellom kjøretøy og Ruter, estimering av avgangstider som vises på ulike kundeflater (mobil, web, skjermer ombord, holdeplasser) og informasjon om neste holdeplass(er) på skjermene ombord. Teamet består av 13 personer fordelt inn i flere sub-team med ansvar for tjenester innenfor et avgrenset funksjonelt domene. Sentral teknologi-stack er Kafka, Kubernetes og MQTT som kjører i AWS.

Ruter er et felles administrasjonsselskap for kollektivtrafikken i Oslo og deler av Viken (tidligere Akershus fylke), les mer om Ruter her.