Det nærmer seg nemlig jul med stormskritt, og man gleder seg til familietid, Harry Potter-maraton og mest av alt lange late fridager. De aller fleste team går inn i julen med sterkt redusert, eller ingen bemanning. Noen krysser fingerene og håper på at alt går bra, noen har kodefrys ukesvis i forkant av ferien, mens noen har vaktordninger hvis noe skulle gå alvorlig galt.

Det er i denne ventetida man bør rigge seg for senkede skuldre, og at alle skal ha en følelse av trygghet og felles forståelse for hvordan ferieavvikling påvirker det å ha tjeneste kjørende i det man ønsker god jul og sier “sees til neste år” til kollegaene. Her er mine tanker om hva man burde ha snakket om før man åpner de siste lukene i kalenderen og lukker laptopen for sesongen.

Hva er risikoene?

Det finnes mange forskjellige tjenester i tech-verdenen. Det strekker seg fra komponentsystem til bank- og helsetjenester, og man må erkjenne at fallhøyden kan være ganske vidt forskjellig på det man holder på med. Det viktigste er at man er klare over hva som står på spill hvis noe går galt.

Hvor mye er tjenesten i bruk i julen?

Julen er en høytid der trafikkbildet kan endre seg drastisk sammenlignet med resten av året. For noen tjenester betyr julen en markant økning i trafikk.
Tenk på alle som ligger hjemme på sofaen og surfer på nett, flytter penger mellom kontoer før årsskiftet, eller strømmer julefilmer på TV-en. Dette er aktiviteter som typisk øker når folk har mer ledig tid. Andre kan derimot oppleve et etterlengtet avbrekk med nesten ingen trafikk, som for eksempel B2B-løsninger eller interne verktøy.

Analyser fjorårets data for å få noe representativt. Se på trafikkmønsteret fra tidligere juleferier. Hvor mange brukere hadde dere? Når var toppene? Var det spesielle dager som skilte seg ut? Har dere ikke data fra i fjor så kan man bruke helgene i desember som referanse for å forutse hvordan trafikken vil utvikle seg gjennom julen. Det er nødvendig at man har en idé og en forståelse av hvordan trafikkbildet ser ut.

Trafikk forteller ikke hele historien

Trafikkmengde er bare én del av bildet når vi vurderer kritikaliteten til en tjeneste inn mot juleferien. Noen tjenester har kanskje lite trafikk, men hver transaksjon kan være ekstremt viktig. Tenk deg en betalingsløsning som bare brukes av noen få kunder på julaften, men der hver transaksjon representerer betydelige verdier eller kritiske tjenester.

Det er derfor avgjørende å gjøre en risikoanalyse av ulike feilscenarier. Da er det lurt å spørre seg:

• Hva skjer hvis en transaksjon feiler? Kan den enkelt kjøres på nytt?
• Finnes det automatiske retry-mekanismer for viktige meldinger?
• Vil nedetid bety tapte inntekter eller kritiske tjenester for brukerne?
• Hvor lang nedetid kan tjenesten tåle før det blir et reelt problem?

Nedetid, feil og bugs

Det er nyttig å prioritere de ulike feiltypene på forhånd. Det er stor forskjell på om kjernesystemets database krasjer (potensielt katastrofe), eller om en knapp vises med feil farge på Safari (irriterende, men sjelden kritisk).
Lag gjerne en prioritert liste over mulige feilscenarier, og bestem på forhånd hvilke som krever at noen agerer umiddelbart, hvilke som bør løses ved første anledning og hvilke som kan vente til normal arbeidstid.

Husk at selv små kosmetiske feil også kan være problematiske hvis de hindrer brukere i å fullføre viktige oppgaver. En feilplassert knapp kan blokkere hele brukerreisen i verste fall. Vurder derfor både teknisk alvorlighetsgrad og brukeropplevelse når dere kategoriserer.

Varsling og monitorering

Varsling er ironisk nok nøkkelen til en avslappet juleferie. Når du vet at systemet gir beskjed om noe går galt, blir det lettere å legge bort telefonen (som jeg spår blir kanskje årets største utfordring 🙄) og faktisk nyte eviglange familieselskaper uten å måtte sjekke statusen hvert tiende minutt. Hvis man har vaktordning, bidrar dette også til at disse heltene kan nyte julen litt ekstra.

God monitorering er en hygienesak, og som hygiene er dette noe man må holde ved like. Det er fort gjort at det sklir litt ut i blant og havner litt lengre ned på lista i en hektisk arbeidshverdag. Nå før jul er det perfekte tidspunktet for å ta en liten julevask.

Her er mine klare anbefalinger for varsler:

• Informasjonsrike varsler: Relevant informasjon som relevant tjeneste, antall feil, oppsummering av feilmelding og lenke til loggene bør være lett tilgjengelig. Gjerne som en del av varselet.
• Riktig terskelverdier og støyreduksjon: Balanser mellom for mange varsler, som skaper støy og varslingstretthet, og for få som kan la kritiske problemer gå uoppdaget. Det gir ingen mening å vente på 100 feil over 5 minutter hvis man forventer at 3 personer besøker tjenesten. Sørg også for at monitorene grupperer relaterte problemer. Ingen vil 60 varsler tilknyttet samme underliggende problem.
• Tilpass etter sesongtrafikk: Som vi har vært innom må trafikkbildet i julen hensyntas. Sett realistiske terskler basert på forventet trafikk.

Når uhellet først er ute

Hvis telefonen plutselig plinger på, er oddsen for at du er den eneste på jobb ganske høy. Nøkkelpersoner er på ferie, responstiden øker, og kritiske endringer kan bli stående på vent. Med litt forberedelse så kan man rigge de heltene som er på vakt til å bli en skikkelig one-man-army 🦸.

Det enkle er ofte det beste

I noen tilfeller kan det være helt greit å stenge ned tjenesten, få ut et banner om nedetid og kjøpe seg litt mer tid til å komme med en løsning. I en vanlig hverdag kan man sparre, få hjelp, og bruke styrken av et helt team for å problemløse. I julen stiller man ofte alene.

Lag en plan-b for hvordan man på best mulig måte får satt tjenestene i stabilt sideleie. Man kommer seg langt hos brukerene med en god feilmeldingsside som kan skrus på gjennom et feature-flag. Gjør feilmeldingen justerbar og pynt den gjerne med juletema 🎄.

Og så var det å få ut fiksen:

De aller fleste utviklingsteam har etablerte rutiner for hvordan en review-prosess (les; fagfellevurdering) skal gjennomføres. I en normal hverdag sikrer dette kvalitet, reduserer trikkefaktor og at kodeendringer blir dobbel eller trippelsjekket før de settes i produksjon.

I juleferien oppstår det imidlertid et litt spesielt problem: Det kan være svært vanskelig å få godkjenninger av kodeendringer, så veien fra fra versjonskontroll til produksjon kan plutselig få en bråstopp.

En litt kontroversiell løsning, kan være å midlertidig justere godkjenningsprosessen. Dette betyr ikke at man skal fjerne all kvalitetssikring, men heller tilpasse prosessen til feriebemanningen. Dette kan innebære:

• Redusere eller fjerne påkrevde godkjenninger (🤠)
• Utpeke dedikerte personer med godkjenningsansvar i ferieperioden
• Etablere tydelige kriterier for hvilke endringer som kan følge en forenklet prosess og hva som krever at man kaller inn forsterkninger

Det er smart å balansere behovet for raske løsninger mot risikoen dette medfører, spesielt i en periode med redusert bemanning. Det er nesten like bra å ha en post-merge review pluss en liten fix-up, hvis kvalitet er en bekymring. Det er bedre å få ut en fiks kjapt, enn å la det stå å ulme.

Og det viktigste til slutt

Vær pragmatiske og vær forberedte. Det er ikke alltid det er krise, men ved å kartlegge risiko, sørge for god monitorering og ha en klar plan hvis uhellet skulle være ute, kan det føles trygt og godt å gå inn i juleferien. Både deg som utvikler som skal se Chevy Chase henge julepynt på taket, og produkttrio som endelig skal skal vise appen til svigermor og forklare hva de driver med.

Og husk: Selv om disse tipsene er spesielt nyttige i juleferien, kommer de godt med resten av året også.

God sjau og god jul, når den tid kommer! 🎅