DevOps er i praksis disciplinen, der gør softwareleverancer sikre, gentagelige og målbare fra kode til drift. Derfor rammer det forbi det vigtigste, når rollen som DevOps Engineer reduceres til Jenkins, Kubernetes, Terraform og en håndfuld cloud-certificeringer.
DevOps er praksissen med at forbinde udvikling, drift, automatisering, sikkerhed og feedback, så teams kan levere ændringer hurtigere uden at miste kontrol over stabilitet og risiko. Rollen som DevOps Engineer ligger derfor mellem software engineering, cloud-infrastruktur, release management og produktionsdrift. Den kræver teknisk bredde, men også en forståelse for flow, ansvar, dokumentation og samarbejde.
Opdateret for 2026: Denne vejledning bruger danske jobkrav som kontekst og henviser til kilder som Microsoft Learn, AWS-dokumentation, CNCF-rapporter samt danske løn- og jobdatakilder som Jobindex og Glassdoor DK som steder, hvor aktuelle stillingsopslag og lønintervaller bør kontrolleres. Der angives ikke faste løntal her, fordi de ændrer sig hurtigt efter region, branche, anciennitet, cloud-platform og vagtansvar.
Hvad laver en DevOps Engineer i praksis?
En DevOps Engineer bygger og forbedrer de systemer, som gør det muligt for udviklingsteams at levere software til produktion med færre manuelle trin. Det kan være CI/CD-pipelines, containerplatforme, infrastructure as code, secrets management, miljøstyring, deployment-strategier, overvågning, alarmering og incident-håndtering.
I danske organisationer ses rollen ofte i softwarevirksomheder, fintech, energi, offentlig digitalisering, konsulenthuse, SaaS-virksomheder og større enterprise-miljøer med både cloud og eksisterende systemer. En mindre virksomhed kan forvente, at én person både skriver pipelines, vedligeholder cloud-infrastruktur og hjælper udviklere med deployment-fejl. En større organisation vil oftere placere DevOps Engineers i platform teams, cloud enablement teams eller produktteams med tydeligere ansvarsgrænser.
Det er derfor misvisende at se DevOps som en ren værktøjsrolle. En pipeline, der bygger kode, har begrænset værdi, hvis den ikke håndterer testkvalitet, rollback, miljøkonfiguration, logning, adgangsstyring og omkostninger. Arbejdsgivere kigger i stigende grad efter kandidater, der kan forklare, hvorfor en løsning er valgt, ikke kun demonstrere at den virker.
De færdigheder der bør komme først
Den mest praktiske beslutning i starten er at vælge én primær cloud og én primær leveringsstak. En kandidat, der forsøger at lære Azure, AWS, Google Cloud, Jenkins, GitHub Actions, Azure DevOps, GitLab CI, Kubernetes, Helm, Argo CD, Terraform og Bicep på én gang, ender ofte med overfladisk viden. De første måneder bør bruges på en sammenhængende stak, hvor kode, infrastruktur, pipeline, deployment og drift hænger sammen.
For en udvikler er den naturlige første mile typisk CI-tests, containerisering og kontinuerlig deployment. Udvikleren har allerede forståelse for kode, branching, pull requests og testbarhed, men mangler ofte dybere viden om netværk, runtime-miljøer, identitet og produktion. For en sysadmin er rækkefølgen ofte modsat: start med infrastructure as code, cloud-netværk, Linux eller Windows-drift, logging, metrics og traces, og byg derefter stærkere forståelse for applikationslevering. For data- og ML-profiler ligger den første mile ofte i reproducérbare pipelines, orkestrering, Docker og Kubernetes-baserede kørselsmiljøer.
De tekniske kerneområder går igen på tværs af platforme. En DevOps Engineer skal kunne arbejde med Git, scripting i eksempelvis Bash eller PowerShell, mindst ét programmeringssprog, containerisering med Docker, grundlæggende Kubernetes-begreber, CI/CD, cloud-identitet, netværk, secrets, testautomatisering, observability og sikkerhed tidligt i leveringsprocessen. I danske jobopslag ses særligt Terraform eller Bicep, GitHub Actions eller Azure DevOps, Kubernetes-eksponering, cloud-erfaring og praktisk forståelse for sikkerhed som tilbagevendende krav.
En realistisk læringssti fra fundament til selvstændig drift
En person med erfaring fra softwareudvikling, systemadministration eller cloud-drift kan ofte blive junior-funktionel i DevOps-opgaver efter tre til seks måneders fokuseret arbejde. Det betyder ikke, at personen er klar til at eje kritisk produktion alene. Selvstændig drift kræver flere gentagelser med incidents, releases, cost management, sikkerhedsgennemgange og samarbejde med udviklingsteams.
- Fundament: Lær Git-flow, Linux- eller Windows-serverforståelse, netværksgrundlag, scripting, Docker og grundlæggende cloud-ressourcer.
- Levering: Byg en pipeline, der tester, scanner, bygger et container-image og deployer til et kontrolleret miljø.
- Infrastruktur: Beskriv miljøet med Terraform eller Bicep, så netværk, compute, identities og konfiguration kan genskabes.
- Drift: Tilføj logging, metrics, tracing, dashboards, alarmer og en enkel runbook for fejlscenarier.
- Skalering: Arbejd med Kubernetes, GitOps, policy-as-code, omkostningsstyring og release-strategier som blue-green eller canary.
Et stærkt porteføljeprojekt bør samle disse dele i ét repo i stedet for at sprede dem på ti små demoer. En dansk arbejdsgiver får mere ud af at se en containeriseret applikation med IaC, CI-tests, CD, observability med OpenTelemetry, miljøvariabler, secrets-håndtering, begrænsede cloud-omkostninger og en kort driftsbeskrivelse end af en liste over værktøjer uden sammenhæng. README-filen bør forklare arkitekturvalg, trade-offs og hvordan løsningen fejlsøges.
En anonymiseret SMV-case kan se sådan ud: et mindre produktteam har en Node.js- eller .NET-applikation, der tidligere blev deployet manuelt til en cloud-tjeneste. Et realistisk DevOps-bidrag er at containerisere applikationen, oprette en pipeline, automatisere staging-miljøet med Terraform, tilføje health checks og skrive en rollback-procedure. I et enterprise-miljø kan den tilsvarende case handle om at standardisere pipelines, oprette fælles moduler, definere adgangsmodeller og gøre audit-spor tydelige for compliance.
Et enkelt CI/CD-eksempel
Følgende eksempel viser en lille GitHub Actions-pipeline, som tester en applikation og bygger et container-image. Den er ikke tænkt som en færdig produktionspipeline, men som et læsbart mønster, der viser struktur, automatisering og kvalitetssikring tidligt i processen.
Example — CI-pipeline med test og container-build
name: ci
on:
pull_request:
branches:
- main
push:
branches:
- main
jobs:
test-and-build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Build container image
run: docker build -t devops-portfolio-app:${{ github.sha }} .
Det vigtige er ikke selve syntaksen, men rækkefølgen og intentionen. Kode hentes, afhængigheder installeres reproducerbart, tests kører før image-build, og image-navnet bindes til et commit-id. I en mere moden løsning ville næste trin være sårbarhedsscanning, signering, push til registry, deployment til et miljø og overvågning efter release.
Certificeringer: hvornår AZ-400 og AWS DevOps giver mening
Certificeringer kan hjælpe, men de bør ikke være startpunktet alene. En kandidat uden praktiske projekter vil sjældent overbevise ved kun at have læst eksamensmål. Omvendt kan en relevant certificering gøre erfaring lettere at afkode for en arbejdsgiver, især når CV’et skal gennem HR, rekruttering eller en teknisk screening.
Den enkleste beslutningsramme er at vælge certificeringsvej efter den cloud, som bruges i jobbet eller porteføljeprojektet. På Azure-siden validerer AZ-400, Microsoft Certified: DevOps Engineer Expert, færdigheder inden for CI/CD, source control, security, compliance, infrastructure as code, monitoring og samarbejde. På AWS-siden dækker AWS Certified DevOps Engineer – Professional, DOP-C02, tilsvarende temaer i AWS-kontekst, blandt andet automatisering, resilient drift, monitorering og deployment. Begge veje giver mest mening, når de kobles til reelle projekter, ikke isoleret eksamenslæsning.
Et træningsforløb kan være relevant, når kandidaten allerede har valgt platform og har brug for struktur omkring eksamensmål, laboratorieøvelser og tidsplan. Readynez kan i den sammenhæng bruges som en struktureret vej til certificeringsforberedelse, men selve karriereskiftet afhænger stadig af praktisk erfaring, portefølje og evnen til at forklare tekniske valg.
DevOps, SRE og Platform Engineering er ikke det samme
DevOps beskriver en arbejdsform og ofte en rolle, der forbinder udvikling og drift. SRE, Site Reliability Engineering, har stærkere fokus på pålidelighed, service level objectives, incident response, error budgets og automatisering af driftsarbejde. Platform Engineering handler om at bygge interne platforme, som gør det nemmere for udviklere at deploye, observere og drive software uden at skulle forstå alle underliggende detaljer.
Flere danske teams bevæger sig mod interne developer platforms, fordi klassisk DevOps kan blive for personafhængigt. Når hvert produktteam selv skal vælge pipeline, cloud-moduler, secrets, deployment-model og observability, opstår der hurtigt variation, sikkerhedsrisiko og langsommere onboarding. Et platform team forsøger i stedet at levere standardiserede byggesten, skabeloner og selvbetjening, så udviklingsteams kan bevæge sig hurtigere inden for aftalte rammer.
GitOps passer ind i denne udvikling, fordi ønsket tilstand beskrives i Git, mens et værktøj som Argo CD eller Flux synkroniserer miljøet. Det giver sporbarhed og rollback-muligheder, men kræver disciplin omkring repo-struktur, secrets, adgangsrettigheder og review-processer. GitOps løser ikke uklare ejerskaber; det gør dem snarere mere synlige.
Portefølje og jobsøgning i Danmark
En god DevOps-portefølje skal være nem at gennemgå på kort tid. GitHub-profilen bør have få, velbeskrevne repositories med klare README-filer, arkitekturbeskrivelse, kommandoer til lokal kørsel, forklaring af CI/CD, sikkerhedsovervejelser og kendte begrænsninger. Det er bedre at skrive ærligt, at et miljø er forenklet for at styre cloud-omkostninger, end at lade som om en demo er en produktionsplatform.
Til interviews bør kandidaten kunne gennemgå et konkret release-flow fra commit til produktion og forklare, hvor kvalitet, sikkerhed og rollback er indbygget. Typiske case-øvelser handler om at debugge en fejlet pipeline, forklare hvorfor en deployment fejler i Kubernetes, designe en enkel cloud-infrastruktur, håndtere secrets eller beskrive, hvordan et team bør reagere på en produktionsincident. Skriftlighed betyder mere, end mange forventer: runbooks, beslutningsnoter og incident-resuméer viser modenhed.
Almindelige faldgruber er at lære værktøjer uden arkitekturforståelse, ignorere logs, metrics og traces, springe sikkerhedsscanning over eller mangle en plan for rollback. En anden fejl er at gøre alt for komplekst. Hvis en simpel webapplikation kræver et stort Kubernetes-setup uden begrundelse, kan det signalere værktøjsfokus frem for problemløsning.
Sådan bygges en holdbar vej ind i DevOps
Den mest effektive vej ind i rollen er at vælge en stak, bygge et realistisk projekt, dokumentere beslutningerne og koble læringen til enten AZ-400 eller AWS Certified DevOps Engineer – Professional, hvis certificering passer til den valgte platform. Readynez kan være et relevant næste skridt for kandidater, der ønsker struktureret certificeringsforberedelse, men den afgørende forskel ligger i at kunne demonstrere fungerende levering, drift og forbedring i praksis.
DevOps-karrieren belønner teknisk nysgerrighed, men også evnen til at reducere friktion for andre. Den kandidat, der kan gøre releases mere stabile, fejl lettere at finde, miljøer lettere at genskabe og teams tryggere ved ændringer, står stærkere end den kandidat, der blot kan nævne flest værktøjer. For a deeper dive, see Løft din cybersikkerhedskarriere: Den omfattende guide til.
