I mange softwarehuse opdager kunderne fejlen før teamet, og den udvikler, der bor tættest på sin telefon, løser den om aftenen uden at nogen har aftalt det. Det fungerer, så længe produktet er lille og folk er friske. Når kunderne bliver afhængige af produktet, skal tre ting være aftalt: hvad der overvåges, hvem der vækkes, og hvordan en hændelse følges op, så den samme fejl ikke kommer igen. Et lille team kan sagtens have det på plads med enkle midler. Det svære er at gøre ordningen rimelig for dem, der skal leve med den.
Overvåg det, kunden mærker
Overvågning er automatisk måling af, om produktet virker. Der findes to slags, og den første er den vigtigste.
Målinger set fra kunden. Kan man logge ind? Kan kerneflowet gennemføres? Hvor lang tid tager det? Hvor mange forespørgsler ender med fejl? Bliver en af dem dårlig, har I et problem, uanset hvad resten af systemet siger.
Målinger af maskineriet. Hukommelse, disk, databaseforbindelser, køer. De er nyttige til at finde årsagen og til at se noget komme, men de skal sjældent vække nogen.
Logning er den tredje del. Logs er det spor, produktet efterlader, og de er det, I læser, når noget er gået galt. Gode logs viser, hvad der skete, hos hvilken kunde og hvornår, og de indeholder ikke adgangskoder eller flere persondata end nødvendigt, se persondata i produktet.
Alarmer, der er værd at vågne til
Den almindeligste fejl er for mange alarmer. Når telefonen bipper hver nat om noget, der løser sig selv, holder folk op med at reagere, og så drukner den rigtige alarm. Sæt tre krav til hver alarm, der må vække et menneske:
- Kunder er berørt nu, eller bliver det inden for kort tid.
- Der er noget, personen kan gøre.
- Det kan ikke vente til i morgen.
Alt andet går til en fælles kanal eller en opgaveliste, som ses i arbejdstiden. Gennemgå alarmerne en gang om måneden, og slet eller ret dem, der ikke førte til handling. Skriv en kort vejledning til hver alarm: hvad den betyder, og hvad man først skal prøve. Så kan andre end den, der byggede systemet, tage vagten.
En vagt, teamet kan holde til
Vagt (on-call) betyder, at en navngiven person kan kontaktes uden for arbejdstid. Spørg først, om I har brug for det. Har kunderne brug for produktet om natten? Har I lovet det i en SLA? Hvis ikke, kan en ordning med dækning i de udvidede arbejdstider være nok, og det skal så stå klart for kunderne.
Har I brug for vagt, så skal den være aftalt:
- Rotation på en plan, der er kendt i god tid, og som ikke hviler på én person.
- En stedfortræder, hvis den første ikke svarer.
- Klare regler for hviletid dagen efter en urolig nat.
- Aftaler om kompensation, som er et spørgsmål til overenskomst, ansættelsesaftale og eventuelt advokat.
Fem udviklere kan bære en vagt. To kan næppe, og én kan slet ikke, uanset hvor engageret personen er. Hænger vagten på stifteren, er det et nyt argument for at komme videre, se hvad slipper stifteren først. Køb af vagtdækning hos en driftspartner er en mulighed, som behandles i hvem ejer driften.
Når hændelsen er i gang
En driftshændelse er en uplanlagt afbrydelse eller forringelse af produktet. Det hjælper at fordele tre roller, også i et lille team:
- Hændelsesleder. Holder overblikket, beslutter og fordeler arbejdet, så folk ikke arbejder oven i hinanden.
- Fejlretter. Finder og løser problemet, helst uden afbrydelser.
- Kommunikatør. Skriver til kunder og ledelse, se beskeder til kunderne under nedbrud.
Målet i første omgang er at få produktet op igen. Årsagen må vente, hvis en tilbagerulning eller genstart kan bringe kunderne tilbage. Før en kort log undervejs: klokkeslæt, hvad man så, og hvad man prøvede. Den gør opfølgningen meget lettere.
Når det ikke er en driftshændelse
Viser det sig undervejs, at nogen kan have skaffet sig adgang eller angrebet produktet, er det en anden proces. Stop, gem spor, og gå videre efter jeres plan for sikkerhedshændelser. Beslutningerne er ledelsens, og de første timer efter en sikkerhedshændelse gennemgår dem. Der kan også være pligter til at underrette myndighederne, se 24 timer til ENISA. Teamet skal have det ene spørgsmål med i hovedet: Kan det her være andet end teknik, der fejler?
Opfølgning uden skyld
Efter en hændelse skrives en kort evaluering, som fagfolk kalder en postmortem. I Googles bog om driftsarbejde er det et skriftligt dokument om hændelsen og dens følger, om det, der blev gjort, og om årsager og næste skridt. Bogen lægger vægt på, at den skrives uden at pege på enkeltpersoner, for systemer og processer kan rettes, og folk, der frygter straf, holder oplysninger tilbage. Hvordan dagen efter forløber, står i produktet var nede.
Aftal på forhånd, hvad der udløser en evaluering, fx synlig nedetid over en vis grænse, tab af data, eller at overvågningen ikke opdagede fejlen. Det sidste punkt overses tit, og netop den hændelse, kunden fandt først, er den mest lærerige.
Det skal I lade være med
· At lade alle alarmer gå til alle.
· At lade den mest pligtopfyldende udvikler bære vagten, fordi ingen har spurgt.
· At bruge en evaluering til at finde en syndebuk.
· At lukke hændelsen uden en ejer af opfølgningen.
Det skal I kræve af den eksterne
- ☐ En kort liste over målinger set fra kunden med en ansvarlig.
- ☐ Regler for, hvornår en alarm må vække nogen.
- ☐ En vagtplan, teamet har været med til at lave.
- ☐ En skabelon til hændelseslog og evaluering.
- ☐ En klar grænse mellem driftshændelser og sikkerhedshændelser.
Kilder
- Google: Site Reliability Engineering, kapitlet Postmortem Culture: evaluering uden skyld, og hvad der udløser en.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Hver release er en risiko · Backup af et SaaS-produkt
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
