On-Call og Vagtplaner

On-call er den operationelle konsekvens af DevOps-princippet "you build it, you run it": teams, der ejer deres egen kode i produktion, skal også være tilgængelige, når den fejler. En on-call-rotation definerer, hvem der er ansvarlig for at reagere på alarmer uden for normal arbejdstid, typisk i en uge eller to ad gangen, med mulighed for at eskalere til andre, hvis problemet er uden for deres kompetence. Det er en direkte forlængelse af samarbejdet mellem Dev og Ops.

De mest almindelige rotationsmodeller er primær/sekundær, hvor sekundær backer op, hvis primær ikke reagerer inden for en fastsat tid, og follow-the-sun for globalt distribuerede teams, hvor vagten flyttes til den tidszone, der aktuelt har normal arbejdstid. Skyggevagter, hvor nyere medarbejdere følger en erfaren kollega uden selv at have alarmansvar, er en effektiv onboarding-metode, der opbygger tillid til systemet, før man står med det fulde ansvar alene.

Alarmkvalitet afgør, om on-call er bæredygtigt eller en kilde til udbrændthed. Alarmer bør være symptombaserede og handlingskrævende, som beskrevet under monitoring best practices: en alarm, der ikke kræver en handling lige nu, hører til på et dashboard, ikke i en pager. Alert fatigue, hvor for mange lavværdi-alarmer sløver reaktionsevnen, er en af de hyppigste årsager til at kritiske alarmer overses. Google SREs anbefaling om maksimalt to til tre reelle hændelser per vagt er en god tommelfingerregel for, hvornår et alarmsystem trænger til oprydning.

Eskaleringspolitikker definerer, hvad der sker, når den primære vagthavende ikke reagerer: efter hvor lang tid går alarmen videre til sekundær, og derefter til teamlederen. Værktøjer som PagerDuty, Opsgenie og VictorOps håndterer denne logik, integrerer med Slack og Teams, og giver et revisionsspor over, hvem der blev alarmeret hvornår, og hvor lang tid der gik, før nogen reagerede. Den tid indgår direkte i MTTR (mean time to recovery), en af de fire DORA-metrics, der måler et teams operationelle modenhed.

Bæredygtighed kræver mere end gode værktøjer. Kompensation for on-call-tid, uanset om det er løn, afspadsering eller en kombination, signalerer at arbejdet værdsættes. Retten til fri efter en nat med flere alarmer bør være skrevet ind i teamets aftaler, ikke overladt til den enkeltes vurdering. Uden den slags rammer ender on-call med kun at ramme de mest pligtopfyldende medarbejdere hårdest, og de brænder ud først.

On-call-belastning bør måles løbende, ikke kun vurderes anekdotisk. Nøgletal som antal alarmer per vagt, andelen der reelt krævede en handling, og time-to-acknowledge viser, om et system er sundt, eller om det er ved at glide ud af kontrol. En stigende trend i antal alarmer over flere måneder er et tidligt varsel om teknisk gæld, der bør prioriteres, før det fører til udbrændte medarbejdere eller til at folk begynder at ignorere pageren.

Follow-the-sun-modellen bruges typisk af globalt distribuerede organisationer med teams i flere tidszoner, hvor ansvaret for on-call overdrages ved slutningen af den lokale arbejdsdag i stedet for at have én person vågen om natten. Det kræver en solid overdragelsesproces: den afgående vagt skal dokumentere igangværende issues, og den tiltrædende vagt skal kunne læse konteksten hurtigt. Uden en struktureret overdragelse mister man den kontinuitet, modellen ellers giver.

Kompensation for on-call varierer stort på tværs af organisationer og lande, men fælles for de bæredygtige modeller er, at tiden anerkendes eksplicit, uanset om det sker som et fast tillæg, betaling per alarm, eller kompenserende fridage. Organisationer, der behandler on-call som en usynlig, uformel forventning uden kompensation, oplever typisk højere udskiftning blandt de mest erfarne medarbejdere, fordi de er dem, der oftest bliver kaldt ind, når noget virkelig går galt.

Kulturen omkring on-call smitter direkte af på rekruttering og fastholdelse. Kandidater spørger i stigende grad direkte ind til vagtordninger under jobsamtaler, og et team med et dårligt ry for on-call-belastning har sværere ved at tiltrække erfarne folk, uanset hvor konkurrencedygtig lønnen ellers er.

Værktøjsvalget afhænger af organisationens størrelse og budget. PagerDuty er markedsledende med det mest modne økosystem af integrationer, men prissættes per bruger og kan blive dyrt for store organisationer. Opsgenie, nu en del af Atlassian, er ofte billigere og integrerer tæt med Jira. Mindre teams klarer sig fint med simplere løsninger indbygget i overvågningsplatforme som Grafana OnCall, der er gratis for op til et vist antal brugere.

Runbooks er on-calls vigtigste værktøj under selve hændelsen. En god runbook beskriver konkrete diagnosticeringstrin og handlinger for kendte fejlscenarier, så den vagthavende ikke skal genopfinde en løsning klokken tre om natten. Runbooks skal testes og opdateres, ligesom koden de dokumenterer, og bør være tilgængelige selv hvis de systemer, de beskriver, er nede.

Hver hændelse, der vækker nogen, bør ende med en blameless postmortem, der identificerer, om alarmen var korrekt kalibreret, om runbooken var opdateret, og om noget kunne automatiseres væk. On-call er ikke et mål i sig selv, men et nødvendigt sikkerhedsnet, indtil systemerne er robuste nok til at klare sig selv. Det mest modne tegn for et on-call-system er, når antallet af alarmer falder måned for måned, fordi hver hændelse omsættes til en systemforbedring i stedet for at gentage sig.