Kunden påstår fejl i jeres software: sikring af produktion

Forside · Gennemgået oktober 2026 · Af John Nielsen

Når en kunde påstår, at jeres software har en fejl, der har kostet penge, er den naturlige reaktion at finde og rette fejlen hurtigst muligt. Gør det, men fastfrys først tilstanden: den kørende version, konfigurationen, logs og de relevante data. Efter rettelsen kan ingen længere vise, hvordan systemet så ud, da fejlen skete, og det rammer begge parter. Artiklen er skrevet til udviklingshuse og softwareleverandører.

Den bredere plan for et projekt i krise er beskrevet i bevaringsplan for et IT-projekt, og sikring af en hel leverance ved overdragelse står i leverancens tilstand. Her er fokus det konkrete øjeblik, hvor en fejl er påstået i et system i drift.

Hvorfor før rettelsen

En fejl i produktion er en tilstand, ikke bare en kodelinje. Den opstår af kombinationen af en bestemt build, en bestemt konfiguration, bestemte data og ofte en bestemt belastning. Rettelsen ændrer mindst én af disse. Hvis kunden senere hævder, at fejlen var der længe før, eller at den skyldtes jer og ikke kundens egen brug, skal begge påstande kunne efterprøves mod tilstanden, som den var.

Det gælder også, når I selv mener, at fejlen ligger hos kunden. En fastfrosset tilstand er jeres bedste dokumentation for, at fx en forkert konfiguration eller mangelfulde inddata var årsagen.

Det, der skal fastfryses

Versionen. Notér præcist, hvilken build der kører: commit-id, build-nummer, tag og artefaktets hashværdi. Kontrollér på serveren, ikke kun i deployværktøjet, da manuelle rettelser i drift sker oftere end nogen indrømmer.

Konfigurationen. Miljøvariabler, konfigurationsfiler, feature flags, tredjepartsintegrationer og deres versioner. Hemmeligheder som adgangsnøgler skal ikke kopieres i klartekst til sagen; notér i stedet, hvilke der fandtes, og hvornår de sidst blev ændret.

Databasen. Skema, migreringsstatus og de rækker, fejlen handler om. Ofte er en konsistent kopi af hele databasen den sikreste løsning; se konsistent sikring af en database.

Logs og overvågning. Applikationslogs, fejlrapportering, APM-spor og infrastrukturlogs fra perioden. Mange tjenester har kort opbevaring, så eksportér straks. Hvordan overvågningsdata bruges som bevis, står i monitoreringsdata som bevis.

Historikken. Kildekoden med fuld historik, ticket-systemet og CI/CD-kørslerne for de builds, der har været i drift i perioden. git bundle create med --all giver en samlet fil med alle referencer og de commits, de peger på, og git bundle verify kontrollerer filen bagefter. En bundle indeholder ikke arbejdskopi, stash eller lokal konfiguration, så tag dem med separat, hvis de er relevante.

Hvem har adgang til produktionen?

Det afhænger af driftsmodellen, og den afgør, hvem der kan sikre hvad:

I drifter selv (SaaS eller hosting hos jer): I har adgangen, men også interessen. Sikr efter en skriftlig fremgangsmåde, og del hashværdier med kunden med det samme.
Kunden drifter (on-premises eller kundens cloud): I har måske kun supportadgang. Bed om, at kunden sikrer, eller aftal en fælles sikring. Rør ikke ved kundens miljø uden aftale, ud over det, der er nødvendigt for at holde det kørende.
Tredjepart drifter: Logs og snapshots ligger hos driftsleverandøren og skal bestilles derfra, ofte med kort frist.

Ret fejlen uden at slette sporene

Når tilstanden er fastfrosset, kan rettelsen laves. Gør det på en måde, der efterlader et klart spor:

Ret på en separat gren med en commit-besked, der henviser til sagen.
Kør rettelsen gennem den normale pipeline, så testresultater og deploy er logget.
Bevar den fejlbehæftede build som artefakt, så fejlen kan genskabes senere.
Notér tidspunktet for deploy af rettelsen, så tidslinjen viser et klart før og efter.

Undgå hotfixes direkte på serveren. De kan være fristende i en akut situation, men de efterlader ingen historik og gør det svært at vise, hvilken kode der kørte hvornår.

Genskab fejlen i en kopi

En fejl, der kan genskabes i et isoleret miljø med den fastfrosne build, konfiguration og en kopi af data, er langt stærkere dokumentation end en forklaring. Notér testmiljøets opsætning, og gem input, output og logs fra genskabelsen. Kan fejlen ikke genskabes, er det også et resultat, der skal dokumenteres, sammen med hvad der blev forsøgt.

Hvor det er muligt, bør byggeprocessen være reproducerbar, så samme kildekode og byggemiljø giver en identisk artefakt. Så kan det vises, at den build, der testes, er den samme, som kørte i drift. Hvordan CI/CD-data tolkes, står i CI/CD-logs og testdokumentation.

Typiske faldgruber

Deployværktøjet og serveren er uenige. Kontrollér den faktisk kørende kode, fx ved at hashe filerne på serveren.
Logrotation. Fejlens tidspunkt kan allerede være roteret ud. Hent arkiverede logs og centrale logkopier.
Tidszoner. Applikationslogs, database og overvågning kan bruge forskellige tidszoner. Afklar det, før tidslinjen bygges.
Persondata. En kopi af produktionsdata kan indeholde kundens persondata. Aftal håndtering og adgang, før kopien tages.
Egne rettelser i perioden. Har andre udviklere ændret konfiguration undervejs, skal det fremgå af tidslinjen.
Automatiske opdateringer. Afhængigheder, containerbilleder og cloudtjenester kan være opdateret automatisk i perioden. Notér versionerne, også af det, I ikke selv har bygget.

Del sikringen med kunden

En sikring, som kun den ene part kender, skaber mistillid. Send kunden en kort oversigt over, hvad der er sikret, hvornår, og med hvilke hashværdier, mens rettelsen stadig er under arbejde. Tilbyd, at kundens egen IT eller en sagkyndig kan få adgang til kopierne efter aftale. Det koster lidt tid, men det fjerner senere indsigelser om, at materialet er tilpasset.

Hvis kunden selv har data, der belyser fejlen, fx skærmbilleder, eksporter, fejlmeddelelser eller egne logs, så bed om dem tidligt og registrér, hvordan de er modtaget. Kundens materiale er ofte indsamlet af brugere uden tidsstempler eller metadata, og det skal fremgå af tidslinjen, så det ikke vejer tungere, end det kan bære.

Dokumentation

Før en handlingslog fra det øjeblik, påstanden kommer: hvem sikrede hvad, hvornår, fra hvilket system, med hvilken metode og hvilken konto. Gem hashmanifestet adskilt fra produktionsmiljøet, og notér, hvem der har adgang til kopierne. Beskriv også, hvad der bevidst ikke blev sikret, fx hemmeligheder eller persondata uden relevans, og hvorfor. Det gør det lettere for en sagkyndig senere at vurdere, om materialet er fuldstændigt nok til at besvare spørgsmålene.

Hvad sikringen kan og ikke kan vise

Sikringen kan vise, hvilken version og konfiguration der kørte, hvad loggene registrerede, og om fejlen kan genskabes. Den kan ikke i sig selv vise, om fejlen er en kontraktmæssig mangel, eller om den var kendt og accepteret. Det afhænger af kravspecifikation, aftaler og ticket-historik, som parterne og deres rådgivere må vurdere.

Når kunden har bestridt fejlen, eller når en tvist er sandsynlig, kan en uvildig sikring styrke dokumentationen, fordi den ikke er foretaget af en part. Nielco IT sælger ikke produkter og har ingen leverandørpartnerskaber.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: AI-kodeassistenter i kildekodetvister · SBOM og byggeartefakter som dokumentation

→ Uvildig IT-sagkyndig med forensic-baggrund · For udviklingshuse · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik