DevOps-ingeniør: har en lille virksomhed brug for en?

De fleste små og mellemstore virksomheder har ikke brug for en DevOps-ingeniør. Har du én eller få webapps med almindelig trafik, kan managed hosting og en fullstack-udvikler der sætter automatisk udgivelse, backup og overvågning op, dække det meste af det en DevOps-ingeniør ellers ville lave. Behovet opstår først for alvor når du har mange systemer, flere udviklingsteams eller krav om oppetid døgnet rundt.

Jeg er selv fullstack-udvikler og ikke DevOps-specialist. Derfor har jeg også skrevet et afsnit om hvornår du skal vælge en specialist frem for en som mig.

Den korte version

Min tommelfingerregel: ligger du i midterkolonnen på alle rækker, er en fast DevOps-ingeniør overdimensioneret. Ligger du i højre kolonne på to eller flere rækker, så læs afsnittet om hvornår du faktisk har brug for en specialist. Vil du først have overblik over hvilke roller der findes, kan du starte med min guide til typer af udviklere og hvad de laver.

Hvad DevOps egentlig dækker

DevOps er en sammentrækning af development (udvikling) og operations (drift). Ideen er at de samme folk, eller i hvert fald folk der arbejder tæt sammen, står for både at bygge softwaren og at holde den kørende. AWS beskriver DevOps som en kombination af kultur, praksis og værktøjer der gør en organisation i stand til at udvikle og udgive software hurtigere (AWS: What is DevOps?).

I praksis dækker DevOps typisk de her områder:

• CI/CD (continuous integration og continuous delivery): koden testes automatisk hver gang en udvikler lægger en ændring op, og udgives automatisk når testene er grønne.
• Infrastruktur: servere, databaser, netværk og domæner, gerne beskrevet i kode så opsætningen kan genskabes.
• Overvågning og logning: besked når siden er nede eller fejlene stiger, og logs der viser hvad der skete.
• Sikkerhed og opdateringer: styresystem, PHP- eller Node-versioner, certifikater og pakker holdes opdateret.
• Backup og gendannelse: kopier af dine data og en afprøvet plan for at få dem tilbage.
• Skalering: flere ressourcer når trafikken stiger, færre når den falder.

Forskningsprogrammet DORA måler hvor godt softwareteams udvikler og driver software med fem nøgletal, blandt andet hvor ofte de udgiver og hvor hurtigt de kommer på fode efter en fejlslagen udgivelse (DORA: software delivery metrics). Sådan bør en lille virksomhed også tænke på DevOps: målet er ikke en titel på lønlisten, men at du kan udgive ændringer uden frygt og hurtigt rette op når noget går galt.

Hvad en DevOps-ingeniør laver, og hvad det koster

En DevOps-ingeniør bygger og vedligeholder det maskinrum som udviklerne arbejder i. Det kan være pipelines til test og udgivelse, cloudmiljøer hos AWS, Azure eller Google Cloud, containere (pakker med en app og alt det den skal bruge for at køre), Kubernetes (et system der styrer mange containere på tværs af servere), adgangsstyring og vagtordninger.

Rollen er mest værd når der er mange udviklere at hjælpe. I en virksomhed med 30 udviklere kan én person der gør udgivelser hurtigere og sikrere, spare mange timer hver uge. I en virksomhed med én webapp og én udvikler er der sjældent 37 timers infrastrukturarbejde om ugen.

Prisen er ikke lav. Ifølge brugerindberetninger på LønRadar lå medianlønnen for en DevOps-ingeniør i Danmark på omkring 60.000 kr. om måneden inklusive pension i juli 2026 (LønRadar: DevOps engineer løn). Dertil kommer de øvrige udgifter ved en ansættelse, fx rekruttering, udstyr, ferie og oplæring. Tallene bygger på selvindberetninger, så brug dem som et groft pejlemærke.

Der er også en praktisk risiko. Én DevOps-ingeniør i en lille virksomhed er ofte den eneste der forstår opsætningen. Bygger vedkommende en avanceret infrastruktur og siger op bagefter, står du med en opsætning der er dyrere at overtage end dit behov nogensinde krævede.

Hvorfor managed hosting og en fullstack-udvikler ofte er nok

Managed hosting betyder at en platform tager sig af serverne for dig. Du skal ikke selv installere styresystem, webserver og database, holde dem opdateret eller forny certifikater. Tilbage er den del af DevOps der handler om din egen applikation, og den kan en erfaren fullstack-udvikler sagtens dække.

Der findes to typer managed hosting som jeg typisk peger på til webapps:

• Fuldt administrerede platforme. Laravel Cloud sætter selv servere op, bygger og udgiver koden, holder platformen opdateret og skalerer med trafikken. Til Next.js-frontends er Vercel det tilsvarende valg. Du betaler for bekvemmeligheden og får til gengæld mindre kontrol.
• Serveradministration på din egen cloudkonto. Med fx Laravel Forge vælger du selv udbyder, fx Hetzner, DigitalOcean eller AWS, og beholder fuld adgang til serveren. Forge står for opsætning, udgivelser uden nedetid, gratis SSL-certifikater, databasebackup og overvågning af serveren.

Begge typer lader dig vælge et datacenter i EU, hvilket gør det enklere at holde styr på hvor dine data ligger.

Arbejdsdelingen ser typisk sådan ud: platformen tager serverne. Udvikleren tager pipelinen, testmiljøet, backupplanen, fejlrapporteringen og opdateringer af framework og pakker. Du har adgangene og træffer beslutningerne. Om én udvikler kan bære hele projektet, har jeg skrevet mere om i indlægget om hvornår én fullstack-udvikler er nok.

Ulempen er at du bliver afhængig af platformen. Hæver den priserne, eller mangler den noget du får brug for, skal du flytte. Det er overkommeligt så længe koden ikke er bundet tæt til platformens særlige funktioner.

Sådan dækker du DevOps uden at ansætte nogen

Her er de trin jeg anbefaler for en virksomhed med én eller få webapps. For en enkelt app tager det groft regnet nogle dage at få det på plads.

1. Vælg managed hosting frem for en server du selv skal passe. Medmindre du har en særlig grund, skal ingen i din virksomhed logge ind på en server for at opdatere software. Vælg et datacenter i EU.
2. Læg koden i et repository (kodearkiv) som du ejer, fx en GitHub-organisation i virksomhedens navn. Domæne, hosting og andre konti skal også stå i dit navn.
3. Automatiser test og udgivelse. Hver ændring skal køre gennem automatiske tests, fx med GitHub Actions, og først udgives når de er grønne. Ingen skal kopiere filer op på en server i hånden.
4. Hav et testmiljø (staging). Det skal ligne produktion så meget som muligt, så du kan afprøve ændringer før dine kunder ser dem.
5. Sæt backup op, og test gendannelsen. Tag daglig backup af databasen, og gem den et andet sted end selve serveren. En backup du aldrig har prøvet at gendanne, er et håb og ikke en plan.
6. Sæt overvågning og fejlrapportering op. Brug en oppetidstjeneste der giver besked når siden er nede, og et værktøj som Sentry eller Flare der fanger fejl før brugerne skriver til dig. Aftal hvem der modtager beskederne.
7. Planlæg opdateringer. Platformen tager styresystemet, men framework og pakker skal opdateres løbende, fx hver måned, så du ikke ender med et stort og risikabelt spring.
8. Skriv en kort driftsmanual. Én side er nok: hvor ligger koden, hvem har adgang til hvad, hvordan udgives der, hvor ligger backup, og hvem gør hvad ved et nedbrud.

Hvornår du faktisk har brug for en specialist

Der er situationer hvor managed hosting og en fullstack-udvikler ikke rækker. Jeg anbefaler at du henter en DevOps-specialist ind når:

• Du har mange tjenester der skal spille sammen, fx mikrotjenester, køer og flere databaser fordelt på flere miljøer.
• Flere udviklingsteams udgiver kode hver dag og venter på hinanden. Så kan en fælles platform til udgivelser spare mange timer.
• Nedbrud koster dig penge hvert minut, og nogen skal kunne reagere om natten. Det kræver en vagtordning med flere personer, ikke én udvikler med telefonen på natbordet.
• Du skal igennem revision eller certificering, fx ISO 27001, eller du er omfattet af EU's NIS2-direktiv og skal kunne dokumentere dine processer.
• Din cloudregning er blevet så stor at det betaler sig at have nogen til at optimere den.
• Du skal køre på egne servere eller i et privat datacenter af juridiske eller kontraktlige grunde.

Et tydeligt advarselstegn er når dine udviklere bruger mere end en dag om ugen på servere, udgivelser og brandslukning i stedet for på selve produktet. Så er infrastrukturen blevet et arbejde i sig selv, og nogen bør have ansvaret for det.

Mellemvejene mellem ingen og en fastansættelse

Selv da er en fastansættelse ikke det eneste svar. Tre mellemveje passer ofte bedre til en mindre virksomhed:

• En freelance DevOps-konsulent til en afgrænset opgave, fx at designe infrastrukturen eller rydde op i en opsætning, mens din faste udvikler står for driften bagefter.
• En driftspartner med administreret drift og vagtordning, hvor du betaler en fast pris om måneden.
• En fractional CTO, altså en teknisk chef på deltid, der kan træffe de større tekniske valg og vurdere om du har brug for mere.

Uanset hvilken vej du vælger, så kræv de samme grundting som i de otte trin ovenfor: infrastruktur i dit navn, dokumentation og en plan for overdragelse. En specialist der efterlader en udokumenteret opsætning, har kun flyttet risikoen, ikke fjernet den.

For at være ærlig om min egen rolle: jeg bygger og vedligeholder webapps, sætter pipelines, backup og overvågning op og holder systemer opdateret. Jeg designer ikke store Kubernetes-klynger, og jeg tilbyder ikke vagt døgnet rundt. Har du brug for det, er en specialist eller en driftspartner det rigtige valg.

Næste skridt

Kan du krydse alle punkter af, har du grundlaget for det DORA måler: du kan udgive ofte og sikkert og komme hurtigt på fode igen når noget går galt. Og du har gjort det uden at ansætte nogen. Mangler du flere af punkterne, er det første skridt sjældent en ny stilling. Det er en udvikler der sætter det op og tager ansvar for det bagefter.

Den løbende del, fra opdateringer til nedbrud, går jeg mere i dybden med i min komplette guide til drift og vedligehold af webapps. Overvejer du om du skal have en leverandør der løser opgaver, eller en der tager medansvar for driften, så læs mit indlæg om teknisk partner eller leverandør. Hvordan jeg selv arbejder med drift, opdateringer og nye funktioner, kan du se på siden om vedligehold og videreudvikling af webapps.

Ofte stillede spørgsmål

Hvad er forskellen på DevOps og almindelig IT-drift?+

IT-drift handler typisk om virksomhedens egne computere, netværk, mail og licenser, mens DevOps handler om den software du selv udvikler og driver. En IT-driftspartner kan sjældent sætte en pipeline op til din webapp, og en DevOps-ingeniør tager sig sjældent af medarbejdernes bærbare. Mange små virksomheder har brug for begge dele, men ofte fra hver sin leverandør.

Har vi brug for Docker og Kubernetes?+

Docker kan være nyttigt, også i små projekter, fordi det sikrer at udviklingsmiljøet ligner produktion. Kubernetes er sjældent nødvendigt for en virksomhed med én eller få webapps. Det er bygget til at styre mange containere på tværs af mange servere, og det kræver løbende vedligehold. Managed hosting løser de fleste af de samme problemer med langt mindre arbejde.

Hvad koster managed hosting til en typisk webapp?+

For en mindre webapp ligger hosting groft regnet fra et par hundrede til et par tusinde kroner om måneden, afhængigt af trafik, databasestørrelse og hvor meget platformen gør for dig. Fuldt administrerede platforme koster mere pr. ressource end en server du selv administrerer, men sparer timer til opsætning og opdateringer. Den største udgift er ofte udviklerens tid.

Kan jeg hyre en DevOps-ingeniør til en enkelt opgave?+

Ja, og for mange mindre virksomheder er det den bedste løsning. En freelance DevOps-konsulent kan fx designe infrastrukturen, sætte en pipeline op eller gennemgå sikkerheden i en eksisterende opsætning. Sørg for at opgaven slutter med dokumentation og en overdragelse til den udvikler der står for den daglige drift, så du ikke bliver afhængig af konsulenten.