Vad gör en DevOps – i praktiken

Vad gör en DevOps

DevOps finns för att korta vägen från idé till stabil drift. Rollen binder ihop utveckling, drift och säkerhet så att produktförändringar kan släppas ofta, säkert och reversibelt. Nedan är en rak genomgång av vad en DevOps faktiskt gör, vad rollen inte är, och vilka resultat du kan förvänta dig.

Varför rollen behövs

Utan DevOps fastnar team mellan silos: utveckling bygger, drift får ta smällen i produktion. DevOps sätter process, verktyg och standarder som gör att kod går att bygga, testa, släppa, övervaka och rulla tillbaka med få händer och låg risk.

Vad en DevOps gör – vecka in och vecka ut

• CI/CD och release-automation
  Bygger pipelines för build, test, säkerhetskontroller och driftsättning. Inför release-strategier (blue/green, canary), feature flags och snabb rollback.
  Effekt: fler releaser med lägre risk. 
• Infrastruktur som kod
  Sätter upp och versionerar miljöer med t.ex. Terraform/Bicep. Standardiserar nätverk, identitet, databaser, köer och lagring.
  Effekt: förutsägbara miljöer, snabb provisioning och enklare revision. 
• Observability och SLO:er
  Definierar service-nivåmål (latens, fel, “freshness”), bygger dashboards och larm (Application Insights, Grafana/Prometheus, Log Analytics).
  Effekt: kortare MTTR och färre överraskningar i produktion. 
• Säkerhet i flödet
  Integrerar secrets-hantering (Key Vault/Vault), policies i kanten (API-gateway), och automatiska kontroller i pipelines (SAST/SCA, container-scan).
  Effekt: färre säkerhetsluckor – utan manuella checklistor i efterhand. 
• Kostnad och kapacitet (FinOps-lins)
  Sätter budgetar/alerts, följer kostnad per tjänst/order/event, hittar enkla vinster (scale-to-zero, rätt storlek på resurser, cache).
  Effekt: lägre “idle spend” och tydlig enhetsekonomi. 
• Incidenthantering och post mortems
  Tar ledning när något brister: isolerar, rullar tillbaka, roterar nycklar, kommunicerar, dokumenterar lärdomar och fixar grundorsak.
  Effekt: snabb återhämtning och bestående förbättringar. 

Vad en DevOps inte är

• Inte “den som trycker på deploy-knappen” åt andra. 
• Inte “nattens brandkår” utan mandat att förändra orsakerna. 
• Inte en flaskhals. DevOps skapar standardvägar (“golden paths”) så att teamen kan släppa själva – säkert. 

Resultat och KPI:er (mät på utfallet, inte på buller)

• Lead time for change: commit → produktion (mål: timmar/dagar, inte veckor). 
• Deployment frequency: hur ofta ni vågar släppa (mål: ofta, små batcher). 
• Change failure rate: andel releaser som orsakar incident (mål: nedåt). 
• MTTR: tid att återställa vid fel (mål: minuter/timmar, inte dagar). 
• Komplettera med verksamhetsnära mått: tid till uppdaterat pris/lager, andel ordrar utan manuell hantering, kostnad per 1 000 events. 

Tre konkreta exempel

1. Kampanj 00:00 utan magont
   DevOps lägger prisändringar som events genom kö, sätter SLO “freshness ≤ 60s”, aktiverar feature flag exakt 00:00 och har rollback-plan. Resultat: rätt pris i kanaler på minuten, noll handpåläggning. 
2. Ny marknad på dagar – inte veckor
   Infrastruktur som kod för nya miljöer, standardiserad CI/CD-mall och policyer i API-kanten. Resultat: snabb onboarding och samma säkerhetsnivå överallt. 
3. Incident: dubblettordrar
   DevOps inför idempotensnycklar i kanten, larm på onormala retries och playbook för replay. Resultat: dubbletter nära noll och kortare MTTR. 

Vanlig verktygsstack (exempel)

• CI/CD: GitHub Actions, Azure DevOps, ArgoCD 
• Infra som kod: Terraform, Bicep, Helm 
• Körmiljöer: Kubernetes/AKS, Functions/Serverless, container registry 
• Säkerhet: Key Vault/Vault, API Management/gateway, OIDC/OAuth2, SAST/SCA 
• Observability: Application Insights, Log Analytics, Grafana/Prometheus, OpenTelemetry 

(Poängen är inte exakt verktyg – det är att flödet är automatiserat, spårbart och säkert.)

Samarbete: så funkar DevOps med andra roller

• Med utveckling: sätter standardmallar, quality gates och release-mönster; coachar team att äga drift-signalerna. 
• Med arkitektur: översätter målbild (säkerhet, isolering, kostnad) till körbar kod och policies. 
• Med säkerhet (DevSecOps): flyttar kontroller till pipelines och kant – från “efterkontroll” till “automatisk grind”. 
• Med affär/produkt: översätter KPI:er till driftmål (ex. “pris/lager uppdaterat ≤ 60s”). 

30–60–90 dagar: så märks rollen

0–30 dagar – Lägesbild och baslinje

• Inventerar pipelines, miljöer, hemligheter och larm. 
• Sätter 2–3 SLO:er och en första dashboard. 
• Snabbvinster: automatisera release för ett prioriterat system, få bort “manuella steg”. 

31–60 dagar – Stabilitet och fart

• Inför standardiserad CI/CD-mall (build, test, säkerhetskontroller, deploy). 
• Flyttar hemligheter till Key Vault, inför rotationsrutin. 
• Sätter upp rollback/canary och bas-runbooks för incidenter. 

61–90 dagar – Skala och sänk kostnad

• Infra som kod för centrala resurser; miljöer i version. 
• FinOps: budget/alerts och första kostnadsgrafen per tjänst/flöde. 
• Förankrar arbetssätt: post mortems utan skuld, prio på grundorsaker. 

Vanliga fel som sänker effekten

• “DevOps-teamet deployar åt oss.” → Flaskhals. Låt teamen släppa via standardvägar. 
• Säkerhet efteråt. → Flytta kontroller till pipeline/kant, annars läcker det ändå. 
• Ingen mätning. → Utan SLO/KPI famlar man; börja enkelt och iterera. 
• Allt special. → Standardisera 80 %, gör undantag där det krävs. 

När passar profilen extra bra?

• Ni släpper sällan för att ni är rädda för driftstörningar. 
• Ni har toppar (kampanjer/lanseringar) där manuella steg spricker. 
• Ni saknar sikt: svårt att säga vad som är långsamt och varför. 
• Kostnaden känns hög men ingen kan peka ut vad som kostar. 

Summering

En DevOps gör leverans snabb, säker och mätbar: pipelines ersätter handpåläggning, infra beskrivs som kod, säkerhet flyttas in i flödet och driften får tydliga mål och larm. Resultatet syns i DORA-mått (lead time, deployment frequency, change failure rate, MTTR) och – viktigast – i färre avbrott och snabbare väg till värde.