Systemdrift for udviklere: monitorering, deploy, backup og incidents i praksis

Hvad er systemdrift for udviklere?

Systemdrift for udviklere er arbejdet med at holde software tilgængelig, sikker og gendannelig i produktion. Det handler om monitorering, sikre deploys, backup og håndtering af incidents, så brugerne mærker så lidt som muligt til fejl og nedbrud.

Hvor udvikling ofte fokuserer på nye features, fokuserer systemdrift på hverdagens driftloop: måle, ændre, reagere og forbedre.

Typisk er rollerne fordelt mellem udvikling, operations/IT, DevOps- og SRE-profiler, men som udvikler slipper du ikke uden om driftbegreberne. Selv hvis du “bare” pusher til en serverless host, har du stadig ansvar for, at din kode kan overvåges, rulles tilbage og gendannes.

En enkel måde at se det på:

• Før produktion: design, udvikling, test.
• Idet du deployer: driftsansvaret starter. Hvordan opdager du fejl? Kan du rulle tilbage?
• I produktion: monitorering, incident response, løbende forbedringer.

DevOps og SRE er i høj grad forsøg på at flette udvikling og systemdrift sammen, så de samme teams både bygger og driver systemet. Uanset label har du brug for de samme kernebegreber: observability, deployment, backup, recovery og en plan for incidents.

Observability: se hvad systemet laver indefra

Observability er evnen til at forstå, hvad der sker i et system, ud fra de signaler det udsender: metrics, logs og traces. God observability gør det muligt at opdage fejl hurtigt og forklare, hvad der faktisk gik galt.

Det er lidt forskellen på at se bilens check engine-lampe (klassisk monitorering) og at have adgang til hele motorens sensordata (observability). Med observability kan du ikke bare se, at der er noget galt, men også hvorfor.

Tre grundsignaltyper: metrics, logs og traces

Observability er ikke bare at samle data, men at gøre den søgbar, korrelerbar og knyttet til alerts. En CPU-graf uden kontekst hjælper ikke meget, når en bestemt kunde ikke kan logge ind.

Hvis du vil dykke mere ned i, hvordan gode logs faktisk vinder over mavefornemmelser, er der en praktisk introduktion i denne guide til observability og logs.

Hvad skal man monitorere?

Som udvikler bør du som minimum monitorere tilgængelighed, fejlrate, svartider, ressourceforbrug og kritiske afhængigheder. Det er de signaler, der både afslører akutte problemer og langsom forværring, før brugerne råber op.

En enkel baseline kan se sådan her ud:

• Tilgængelighed (uptime): kan API’et, websitet eller jobkøen svare? Brug health checks og ping/endpoints.
• Fejlrate: hvor mange requests ender i 5xx, timeouts eller uventede exceptions?
• Latency og throughput: hvor hurtigt svarer systemet, og hvor meget trafik håndterer det?
• Ressourcer: CPU, RAM, disk, database connections, kølængder.
• Kritiske afhængigheder: database, betalingsgateway, mail/SMS, tredjeparts-API’er.

Hvornår skal noget udløse en alarm?

Ikke alle metrics skal give en alarm. Nogle ting er kun til grafer og debugging.

• Alarm-kandidater:
  • Høj fejlrate i produktion (f.eks. mange 5xx i træk).
  • Signifikant øget latency på vigtige endpoints.
  • Health check fejler på kritiske services.
  • Disk næsten fyldt, eller database nær max connections.
  • Backup-job, der fejler gentagne gange.
• Graf-kandidater:
  • Detaljerede CPU-svingninger.
  • Cache hit rate.
  • Individuelle feature-flags eller mindre vigtige jobkøer.

For mange alarmer giver alarmtræthed: ingen reagerer på pageren, fordi den altid larmer. Start med få, skarpe alerts, der kræver en konkret handling. Senere kan du arbejde med SLI’er og fejlbudgetter – der er en god, jordnær introduktion i artiklen om fejlbudgetter og nedbrud en søndag aften.

Deploy, release og rollback: hvad er forskellen?

Deploy, release og rollback er tre forskellige trin i at ændre et system: deploy er den tekniske installation, release er når brugerne får adgang til ændringen, og rollback er at rulle tilbage til en tidligere stabil version, hvis noget går galt.

Deploy vs. release

• Deploy: at flytte kode/artifakter til et miljø (staging eller produktion). Det kan være at bygge og pushe et Docker-image, udrulle en ny version på din host osv.
• Release: at gøre funktionaliteten synlig for brugerne. Fx ved at slå et feature flag til eller skifte trafik til en ny version.

Du kan deploye uden at release (rulle ny kode ud, men lade den være “skjult”), og du kan forberede en release ved at have koden klar i produktion, men slukket med feature flags.

Rollback: din nødudgang

Rollback er planen for, hvordan du går tilbage til en tidligere version, hvis noget fejler. Uden en realistisk rollback-plan er hvert deploy et lotteri.

Typiske mønstre:

• Blue-green deploy: du har to identiske miljøer, blå og grøn. Du deployer til det inaktive, tester det, og skifter trafik derover. Rollback er blot at skifte tilbage.
• Canary release: du sender først en lille del af trafikken til den nye version, måler fejl/latency, og skalerer gradvist op.
• Feature flags: du kan slå nye features til og fra uden redeploy.

Her hjælper en stabil CI/CD-pipeline meget. Automatiserede tests og reproducerbare builds gør det både nemmere at deploye og at rulle tilbage. Hvis du vil se et konkret eksempel på at slippe for manuelle deploy-kliks, er der en realistisk gennemgang i casen om at lade GitHub stå for deploys og den mere generelle introduktion til CI/CD i lille skala.

Backup: sikkerhedskopier, der faktisk kan bruges

Backup er en sikkerhedskopi, du kan bruge til at gendanne data og systemer efter tab, fejl eller angreb. Pointen er ikke at have en kopi, men at kunne komme tilbage til en fungerende tilstand.

Backup hører til i kategorien “korrigerende foranstaltninger”: noget går galt, og du bruger backup til at rette op. Uden backup (og uden test af backup) bliver ellers små fejl hurtigt til permanente skader.

Hvad skal typisk i backup?

I en typisk webapp eller SaaS-løsning bør du som minimum tænke over:

• Database: alle data, som ikke kan genskabes let.
• Uploadfiler: brugeruploads, billeder, dokumenter, vedhæftninger.
• Konfiguration og secrets: environment-variabler, API-nøgler, certifikater. Her skal du kombinere backup med stærk adgangskontrol.
• Infrastruktur-konfiguration: IaC-filer, pipelines, scripts, licenser, nøgler.
• Migrationshistorik: så du kan genskabe database-schema, hvis du skal bygge env’et op fra bunden.

Derudover er det relevant at tænke på beskyttelse mod ransomware og utilsigtet sletning. Det kan fx ske ved at have backup, som ikke kan overskrives (WORM-lignende egenskaber) og ved at adskille backup-miljø og produktionsmiljø.

En backup er først rigtig værdifuld, når du har verificeret, at du kan gendanne den. Det kræver planlagte restore-tests, helst i et separat miljø.

Backup, snapshot, replication og disaster recovery: hvad er forskellen?

Backup, snapshot, replication og disaster recovery løser forskellige behov: backup fokuserer på datagendannelse, snapshots på hurtige punktkopier, replication på løbende spejling, og disaster recovery på at genetablere hele eller store dele af infrastrukturen.

Sammenligning i praksis

En simpel beslutningslogik

• Hvis du primært vil kunne gendanne data efter sletning, fejl eller ransomware: fokus på robust backup med passende retention.
• Hvis du vil kunne rulle hurtigt tilbage efter en farlig ændring: brug snapshots som ekstra sikkerhed før store deploys.
• Hvis du vil minimere datatab ved nedbrud: overvej replication mellem zoner eller regioner.
• Hvis systemet ikke må være helt dødt i længere tid (fx kritiske forretningssystemer): planlæg et disaster recovery-setup, der beskriver, hvordan du bringer hele platformen op et andet sted.

For små webapps er en kombination af fornuftig backup og enkelte snapshots før større ændringer ofte et realistisk minimum. For mere kritiske systemer giver det mening at diskutere replication, failover og decideret DR-setup. Overvejelser om RPO og RTO (nedenfor) hjælper dig med at vælge niveau.

RPO og RTO: hvor meget må du miste, og hvor længe må du være nede?

RPO handler om hvor meget data du kan tåle at miste, og RTO handler om hvor længe systemet må være nede, før det bliver uacceptabelt.

• RPO – Recovery Point Objective: det maksimale datatab, du accepterer. Hvis din RPO er 1 time, siger du i praksis: “Vi kan leve med at miste op til 1 times nye data i værste fald.”
• RTO – Recovery Time Objective: den maksimale nedetid, du accepterer. Hvis din RTO er 2 timer, er målet at være oppe igen senest 2 timer efter en alvorlig hændelse.

Et konkret eksempel

Forestil dig en mindre SaaS-løsning:

• Kunderne bruger systemet i dagtimerne, men sjældent om natten.
• Det vil være irriterende, men til at leve med, at miste op til 15 minutters data.
• Det vil være alvorligt, hvis systemet er helt nede i mere end 4 timer i arbejdstiden.

Her kunne en realistisk startvurdering være:

• RPO: 15 minutter → kræver hyppige backup-snapshots eller logbaseret backup.
• RTO: 4 timer → kræver dokumenteret restore-proces, testede scripts og måske warm standby-infrastruktur.

Pointen er ikke at ramme et “rigtigt tal”, men at bruge RPO/RTO som værktøj: hvor meget skal du investere i backup, replication og DR for at risiko og konsekvenser hænger sammen med virkeligheden?

Sådan håndterer du en incident i praksis

En incident er en hændelse, der påvirker service, brugere eller sikkerhed og kræver aktiv håndtering. Det kan være alt fra langsomme svartider til totalnedbrud eller datalæk.

Et enkelt incident-workflow

Et praktisk workflow kan opdeles i fem trin:

1. Detection: noget opdages via alerts, monitorering, supporttickets eller sociale medier.
2. Triage: du vurderer alvor (severity) og omfang: hvor mange brugere er ramt, og hvor slemt er det?
3. Mitigation: du stopper blødningen: skalerer ned en feature, slår et flag fra, laver midlertidig rate limiting, laver rollback osv.
4. Recovery: du bringer systemet tilbage i normal drift, evt. ved brug af backup eller failover.
5. Postmortem: du analyserer årsagen, og hvad der skal ændres i kode, infrastruktur, tests eller processer.

Mini-runbook eksempel

Eksempel: du deployer en ny version af din API, og kort efter stiger 5xx-fejlraten voldsomt.

• Detection: alert på fejlrate slår ud.
• Triage: du ser, at alle POST-requests mod /orders fejler, og mange brugere rammes.
• Mitigation: du beslutter at lave rollback til forrige version via din CI/CD-pipeline.
• Recovery: efter rollback falder fejlrate til normalt niveau. Du kommunikerer kort status til relevante interessenter.
• Postmortem: du gennemgår logs og ser, at en databaseændring ikke var kompatibel med eksisterende data. Konklusion: bedre migrationsproces, ekstra tests og måske en mere forsigtig tilgang til databaseændringer og fælles migrationspraksis i teamet.

En simpel runbook er bare en tjekliste: “Hvis X sker, gør vi A, B, C, og vi kontakter person Y.” Jo mere kritisk systemet er, desto vigtigere bliver det, at processen er aftalt på forhånd og ikke opfindes midt i branden.

NIS2, Datatilsynet og hvad de betyder for driftsteamet

NIS2 og Datatilsynet stiller krav til sikkerhed, rapportering og gendannelse, men den konkrete pligt afhænger af virksomhedens rolle, sektor og risikoprofil. Som udvikler behøver du ikke være jurist, men du bør kende de tekniske konsekvenser.

Datatilsynet: backup og sikkerhed

GDPR og Datatilsynet fokuserer bl.a. på, at persondata skal beskyttes mod tab, ændring og uautoriseret adgang. Tekniske konsekvenser for drift er fx:

• Backup som sikkerhedsforanstaltning: du skal kunne genetablere adgang til persondata inden for en passende tidshorisont i forhold til risiko.
• Restore-tests: det er ikke nok at sige, at du tager backup; du skal vide, at du kan gendanne dem.
• Adgangskontrol: kun de nødvendige personer skal have adgang til backup og logs, især hvis de indeholder persondata.
• Logging og sporbarhed: du skal kunne se, hvad der er sket, hvis noget går galt.

NIS2 og kritiske tjenester

NIS2 gælder ikke automatisk for alle, men for visse sektorer og “vigtige” eller “særligt vigtige” tjenester. Hvis din organisation er omfattet, vil det stille skærpede krav til bl.a.:

• Systematisk monitorering og hændelsesdetektion.
• Hændelsesindberetning til relevante myndigheder ved alvorlige sikkerhedshændelser.
• Dokumenterede processer for backup, restore, change management og incident response.
• Ledelsesansvar for at sikre, at foranstaltningerne faktisk er på plads.

Oversat til hverdagen betyder det, at drift og udvikling skal kunne vise: “Sådan opdager vi problemer, sådan begrænser vi dem, sådan gendanner vi, og sådan dokumenterer vi det bagefter.” Der er en mere generel introduktion til governance og sikkerhed i guiden om IT- og cybersikkerhed governance i praksis.

Selv hvis du ikke er omfattet af NIS2, er meget af den samme disciplin sund praksis: bedre monitorering, klare runbooks, testet backup og dokumenterede beslutninger.

Driftloopet: sådan hænger monitorering, deploy, backup og incidents sammen

Systemdrift for udviklere er et loop: monitorering opdager problemer, deploy skaber ændringer, incidents kræver reaktion, backup muliggør gendannelse, og postmortems forbedrer systemet til næste runde.

Et simpelt driftloop i 6 trin

1. Byg og test: du udvikler en ændring og sikrer med tests, at den ser fornuftig ud lokalt og i staging.
2. Deploy og release: koden rulles ud til produktion via CI/CD. Du bruger gerne feature flags eller canary for at begrænse risikoen.
3. Monitorering og observability: metrics, logs og traces viser, hvordan systemet opfører sig efter ændringen: latency, fejlrate, ressourceforbrug osv. Hvis noget skrider, får du alerts.
4. Incident response: hvis en ændring eller udefrakommende faktor skaber problemer, følger du din incident-proces: triage, mitigation (fx rollback eller throttle), recovery.
5. Backup og recovery: hvis noget er gået rigtigt galt (datatab, korruption, ransomware), bruger du backup, snapshots eller DR-setup til at gendanne til en acceptabel RPO/RTO.
6. Postmortem og forbedringer: du dokumenterer, hvad der skete, og hvad der skal ændres: bedre tests, mere robust arkitektur, tydeligere alerts, stærkere rate limiting, smartere deploystrategi osv.

Loopet kører hele tiden, også når der ikke er dramatiske incidents. Hver deployment og hver mindre fejl er en mulighed for at gøre næste runde lidt mindre smertefuld.

Når du designer nye features eller ændrer arkitekturen, er det værd at spørge:

• Hvordan opdager vi, at denne del er nede eller langsom?
• Hvordan kan vi slå den fra eller rulle den tilbage, hvis den fejler?
• Hvilke data risikerer vi at miste, og hvad er vores RPO her?
• Hvordan vil vi gendanne, hvis netop denne del bliver kompromitteret?

Meget af det kan du tænke ind allerede når du bygger koden: robust API-design, fornuftig error-håndtering, idempotente webhook-endpoints, gennemtænkt rate limiting og forudsigelige migrations. Der ligger fx konkrete eksempler i guiderne om robuste Express-API’er i produktion, rate limiting i praksis og webhook-endpoints der overlever virkeligheden.

Når du først begynder at se systemdrift som et loop og ikke som brandslukning, bliver meget af det her mindre skræmmende og mere som almindelig, iterativ udvikling – bare med lidt mere alvor, når noget går galt.