Natten er overstået, produktet kører, og alle er trætte. Det er fristende at lægge det bag sig, men de næste par dage afgør, om nedbruddet ender som en dyr erfaring eller bare en dyr nat. Tre ting skal ske: Teamet skal have ro, de største kunder skal have et ordentligt svar, og I skal skrive ned, hvad der skete, og hvad der ændres. Rækkefølgen er vigtig, for en evaluering holdt af udmattede mennesker bliver dårlig, og et svar til kunderne uden fakta bliver værre.
Denne artikel handler om driftshændelser, altså fejl i teknik, ændringer eller kapacitet. Kan årsagen være et angreb, gælder en anden proces, se de første timer efter en sikkerhedshændelse.
De første timer efter
Tag vare på dem, der har arbejdet. Giv folk fri til at sove, og sæt en anden på vagten det næste døgn. Takker I teamet, så gør det konkret og før evalueringen.
Sikr sporene, mens de er friske. Få loggen fra hændelsen samlet, gem chatbeskeder og grafer, og noter tidspunkter. Hukommelsen forsvinder hurtigt, og der skal være en fælles tidslinje at arbejde ud fra.
Kontrollér også, at produktet faktisk er rask. Er data rigtige? Er alle baggrundsjob kørt færdig? Har en midlertidig løsning efterladt noget, der skal ryddes op? Mange gentagne nedbrud skyldes en nødløsning, ingen fik fjernet.
Luk hændelsen på statussiden med en afsluttende besked, se hvad I skriver til kunderne under et nedbrud.
Evaluering uden skyld
Hold evalueringen inden for et par dage, mens detaljerne står klart. Googles bog om driftsarbejde beskriver metoden som en skriftlig gennemgang af hændelsen, dens påvirkning, handlingerne, årsagerne og opfølgningen, og den fremhæver, at alle antages at have handlet i god tro ud fra det, de vidste. Grunden er praktisk. Systemer og processer kan rettes, og når folk er bange for at få skylden, holder de netop de oplysninger tilbage, I har brug for.
Den, der trykkede på knappen, er derfor den, der ved mest. Spørgsmålet er aldrig “hvem gjorde det?”. Spørgsmålet er, hvorfor det kunne lade sig gøre, og hvorfor ingen opdagede det i tide. Det kræver, at ledelsen selv holder sig til det. En direktør, der spørger “hvem”, ødelægger metoden på ét møde.
Gå igennem disse spørgsmål:
- Hvad skete der, og hvornår? En tidslinje fra første tegn til fuld genopretning.
- Hvem blev berørt, og hvor længe?
- Hvordan opdagede vi det? Var det overvågningen eller en kunde?
- Hvad gjorde vi, og hvad virkede?
- Hvorfor skete det? Bliv ved med at spørge, indtil svaret handler om noget, der kan ændres.
- Hvad var heldigt? Det er ofte der, den næste hændelse ligger gemt.
- Hvad ændrer vi, hvem gør det, og hvornår?
Punkt 5 er det sværeste. “En udvikler lavede en fejl” er sjældent det sidste svar. Hvorfor blev fejlen ikke fanget af test? Hvorfor kunne ændringen gå direkte i produktion? Hvorfor tog det tid at rulle tilbage? De svar peger på noget, I kan rette, se hver release er en risiko.
Svaret til de største kunder
Kunderne skal høre fra jer, før de spørger. Hvem der skriver, afhænger af relationen. Til de største bør en navngiven person, gerne direktøren, ringe eller skrive personligt. Andre får den fælles besked.
En god efterfølgende besked er kort:
- Hvad skete der, set fra kunden, og hvor længe?
- Hvad var årsagen, i et sprog uden fagord?
- Er kundens data berørt?
- Hvad har I ændret, og hvad vil I ændre?
- Hvem kan kunden kontakte?
Undgå både selvforsvar og beskyldninger i teksten. En leverandør kan have været årsagen, men valget af leverandør og mangel på reserve var jeres. Gem de tekniske detaljer til dem, der beder om dem. En kunde med en IT-afdeling vil ofte gerne have selve evalueringen i en renskrevet udgave. Fjern personnavne og oplysninger, der kan misbruges.
Har I en SLA, skal det gøres op, om aftalen er brudt, og hvad den udløser. Tag initiativet selv. Tvivl om aftalens betydning er et spørgsmål til advokat, mens målingerne er jeres egne, se SLA og oppetid.
Har nedbruddet ramt data, skal I vurdere, om det er en anden type sag. Er personoplysninger tabt eller utilgængelige, er det ikke længere en ren driftssag, og I skal tale med den, der ejer databeskyttelsen.
Hvad der ændres
En evaluering uden opfølgning er spildt. Hold listen kort. Tre gennemførte opgaver er mere værd end femten, der aldrig bliver lavet. Opdel i:
- Straks. Rettelsen af den konkrete fejl og oprydning af nødløsninger.
- Denne måned. Overvågning, der skulle have fanget det, eller en vejledning, der manglede.
- I køreplanen. Ændringer i arkitekturen, der skal prioriteres mod andet arbejde.
Giv hver opgave et navn og en dato, og følg op på et fast møde. Ledelsen skal se listen, og det er ledelsens ansvar, at opgaverne får plads frem for at tabe til nye funktioner. Kan I se, at samme type fejl kommer igen, er det et tegn på noget større, fx at driften mangler en klar ejer, se hvem ejer driften.
Når nedbruddet er større end teknikken
Efter et alvorligt nedbrud spørger ledelsen ofte, om noget mangler i organisationen. Spørgsmålet er rimeligt. Det kan være, at ingen har overblikket, at viden er samlet hos én, eller at drift aldrig har været nogens opgave. Tag spørgsmålet op, når pulsen er faldet, og brug evalueringen som grundlag. Hvordan samme overvejelse tager sig ud bredere i ledelsen, findes under efter en alvorlig IT-hændelse.
Det skal I lade være med
· At holde evalueringen, mens folk stadig er trætte.
· At lade en personlig fejl blive årsagen på papiret.
· At love kunderne, at det aldrig sker igen.
· At lukke sagen, før opfølgningen er fordelt.
Det skal I kræve af den eksterne
- ☐ En skriftlig evaluering med tidslinje, årsag og opfølgning.
- ☐ Et udkast til svaret til de største kunder.
- ☐ En kort liste over ændringer med ejere og datoer.
- ☐ Opfølgning på et fast møde, indtil listen er lukket.
- ☐ En ærlig vurdering af, om hændelsen peger på noget større.
Kilder
- Google: Site Reliability Engineering, kapitlet Postmortem Culture: evaluering uden skyld.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Overvågning, vagt og driftshændelser · Backup af et SaaS-produkt
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
