I de fleste små softwarehuse er driften aldrig blevet besluttet. Den tilfaldt den udvikler, der satte serveren op, og siden er opgaverne vokset: opdateringer, overvågning, backup, kundesager og et skrøbeligt natjob, kun én kender. Så længe det går godt, opdager ingen det. Når produktet vokser, bliver driften en rolle, der skal have en ejer, og spørgsmålet er, hvem det skal være. Der er tre realistiske modeller for et lille team, og de kræver hver sit. Valget afhænger mindre af tekniske hensyn end af, hvor stort teamet er, og hvad I har lovet kunderne.
Hvad driften består af
Skriv opgaverne ned, før I diskuterer organisering. Listen er længere, end de fleste tror:
- Overvågning, alarmer og vagt.
- Sikkerhedsopdateringer af servere, databaser og afhængigheder.
- Backup og øvelser i gendannelse.
- Udrulning af nye versioner og vedligehold af pipelinen.
- Kapacitet, skalering og cloudregningen.
- Adgange, nøgler og certifikater.
- Hændelser og opfølgning.
- Kundesager, der kræver en teknisk person.
Markér ud for hver opgave, hvem der gør den i dag, og om det er aftalt. Tomme felter og samme navn hele vejen ned er begge tegn på, at noget skal ændres.
Model 1: Udviklerne driver selv
Udviklerne, der bygger, driver også det, de bygger. Metoden kaldes DevOps, og i et lille team er den ofte den bedste. Den, der har skrevet koden, mærker følgerne, og det giver bedre software.
Det kræver:
- At platformen er enkel, gerne med administrerede tjenester, så I ikke selv passer databaser og servere.
- At udrulning og overvågning er automatiseret.
- At driftsopgaver er med i planlægningen.
- At mindst tre eller fire kan tage vagten.
Modellen bryder sammen, når kapaciteten forsvinder i driftsopgaver, og nye funktioner går i stå, eller når al drift lander på den ene, der kan det. Tegnet er, at én person bliver spurgt om alt.
Model 2: En driftsperson eller platformsudvikler
Når driften fylder, giver det mening med en ansat med fokus på den. Titlerne varierer, fx DevOps-ingeniør, driftsansvarlig eller platform engineer. En platform engineer bygger værktøjer og rammer, så udviklerne kan arbejde selvstændigt.
Forskellen er vigtig. Skal personen tage imod alt det, udviklerne ikke vil, er resultatet en flaskehals med en anden titel. Skal personen gøre driften lettere for alle, stiger værdien. Skriv det ind i rollebeskrivelsen.
Det kræver:
- Nok opgaver til et fuldt job, ellers keder en dygtig person sig.
- En plan for stedfortræder, for én person kan ikke have vagt alene.
- En ejer af retningen, så platformen ikke bliver en privat byggeplads.
Model 3: En driftsleverandør
En specialiseret leverandør står for hele eller dele af driften, typisk overvågning, vagt, patching og backup.
Det passer, når I har brug for vagt uden for arbejdstid og er for få til at dele den, eller når kunderne stiller krav, I ikke selv kan leve op til. Det passer dårligere til et produkt, der ændrer sig hver uge, hvor fejl kræver indsigt i koden.
Det kræver:
- En klar grænse mellem leverandørens ansvar og jeres.
- Vejledninger, så leverandøren ved, hvad den skal gøre ved alarmer.
- Adgang til jeres konti på jeres betingelser. Konti og koder skal ejes af jer, se ejerskab af kode og konti.
- En person hos jer, der følger op og kan stille krav.
Den sidste er den, der overses. Købt drift fjerner ikke behovet for en ejer. Ansvaret for, hvad I lover kunderne, bliver hos jer. Samspillet mellem ledelse og leverandør får I forklaret under IT-ledelse og IT-leverandøren.
Mange ender med en blanding, fx at udviklerne ejer applikationen, mens en leverandør tager nattevagten for de grundlæggende alarmer. Det virker, når grænsen er skrevet ned.
Hvornår det næste skridt er nødvendigt
Se efter disse tegn:
- Driften tager en stor og voksende del af udviklernes tid.
- Samme person bliver ringet op igen og igen.
- Kunderne kræver en oppetid eller en dækning, I ikke kan levere, se SLA og oppetid.
- Hændelser gentager sig, fordi ingen har tid til opfølgningen, se produktet var nede.
- Opdateringer udskydes, fordi de altid taber til nye funktioner.
Ét af tegnene er et signal om at tage en samtale. Flere samtidig tyder på, at modellen er vokset fra jer.
Hold support fra at afbryde udviklerne
Kundesager er ofte det, der for alvor spiser udviklernes dag. En enkelt afbrydelse koster mere end de minutter, den tager, fordi tankerne skal samles igen. Tre tiltag hjælper:
- Faste niveauer. Support løser det, de kan. Kun det, der kræver kodekendskab, går videre.
- Skiftende ansvar. Én udvikler ad gangen tager kundesager i en uge, resten arbejder uforstyrret. Det giver også alle kendskab til de fejl, kunderne møder.
- Værktøjer til support. Lad supporten slå oplysninger op og løse de hyppigste sager selv, så de ikke behøver en udvikler. Når samme sag kommer tredje gang, skal den bygges væk.
Kanalen skal også være klar. Kommer kundesager ind via direkte beskeder til udviklere, ved ingen, hvad der foregår. Saml dem i ét system.
Beslutningen
Hvem der ejer driften, er et spørgsmål for ledelsen. Vælg model, skriv ansvaret ned, og se på det igen en gang om året. Den tekniske ejer skal kunne svare for opgaverne uden nødvendigvis at udføre dem selv, og den rolle kan tages af en fractional CTO.
Nielco IT tager den slags opgaver som en del af den tekniske ledelse, med vægt på ansvar, leverandører og team, mens selve driftsarbejdet og koden ligger hos jeres folk eller driftsleverandør. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Det skal I lade være med
· At lade driften hvile på den, der ikke siger nej.
· At købe drift og tro, at ansvaret dermed er flyttet.
· At ansætte en driftsperson til alt det, udviklerne ikke vil.
· At lade udviklerne tage kundesager direkte fra alle kanaler.
Det skal I kræve af den eksterne
- ☐ En liste over driftsopgaver med navngivne ejere.
- ☐ En anbefaling om model ud fra team, produkt og kundekrav.
- ☐ En skriftlig grænse mellem jer og en eventuel leverandør.
- ☐ En plan for support, der beskytter udviklernes tid.
- ☐ Tydelige tegn på, hvornår modellen skal ændres.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Når én udvikler kender hele koden · Backup af et SaaS-produkt
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
