CV-guide för DevOps-ingenjör: Vad rekryterare faktiskt letar efter 2026

DevOps-ingenjörskonst är en av de snabbast rörliga rollerna inom teknik, och CV-problemet är bedrägligt svårt. Verktygskedjan förändras ständigt – vad som var banbrytande för tre år sedan (rena Jenkins-pipelines, monolitiska VM-driftsättningar) är nu grundkrav eller aktivt utgångna. Samtidigt är de faktiska kompetenserna som gör en stor DevOps-ingenjör – systemtänkande, en bias mot automatisering, ägarskap av tillförlitlighet end-to-end – svåra att demonstrera i en teknikstacklista.

Resultatet är att de flesta DevOps-CV:n ser identiska ut: en vägg med verktygsnamn arrangerade i kategorier, följt av bullet-punkter som läser som konfigurationsanteckningar. Rekryteringschefer vill se ingenjörsomdömet bakom verktygsvalen, inte bara bevis på att du har använt verktygen.

Den här guiden hjälper dig att skriva ett CV som visar båda.

Vad rekryterare söker efter

1. Molnplattformsdjup, inte bara bredd. AWS, Azure och GCP har var och en distinkta ekosystem. Rekryteringschefer som söker en cloud-native roll vill se att du känner plattformen på djupet – inte att du berört alla tre på ytnivå. Om din starkaste plattform är AWS, visa specifiken: EC2, EKS, RDS, Lambda, IAM-policyer, Control Tower. Generisk "AWS-erfarenhet" är meningslös; "hanterade en multi-konto AWS-organisation med 15 konton med Control Tower och Terraform" är specifik.

2. Infrastructure-as-Code-kompetens. Terraform är grundkrav 2026. Pulumi vinner mark. Ansible är fortfarande relevant för konfigurationshantering. Om du har skrivit produktions-Terraform-moduler, hanterat fjärrtillstånd i S3 med DynamoDB-låsning eller byggt återanvändbara moduler publicerade till ett privat register, säg det uttryckligen. IaC är nu central för DevOps-identiteten.

3. Container- och orkestreringsserfarenhet. Kubernetes är inte längre valfritt. Anställningsteam vill veta om du har opererat Kubernetes i produktion, hanterat klusteruppgraderingar, skrivit Helm-charts från grunden, implementerat RBAC-policyer eller arbetat med service mesh-lager som Istio eller Linkerd. Att köra ett kluster i ett laboratorium för ett personligt projekt är inte samma sak som att hantera nodautoskalning för en produktionsarbetsbelastning.

4. CI/CD-pipeline-ägarskap. GitHub Actions har i stor utsträckning ersatt äldre verktyg för greenfield-projekt, men Jenkins, GitLab CI, CircleCI och Buildkite dominerar fortfarande i enterprise-miljöer. Visa att du byggde eller avsevärt förbättrade pipelines – reducerade byggtider, introducerade parallellism, lade till säkerhetsskanningssteg (Trivy, Snyk, Checkov) eller migrerade från en plattform till en annan.

5. Observerbarhets- och tillförlitlighetsarbete. Mätvärden, loggar, spår – de tre pelarna i observerbarhet. Prometheus och Grafana, ELK/EFK-stackar, Datadog, New Relic, Honeycomb – vilket använde du, i vilket sammanhang och vilket beslut drev observerbarhetsdata? Bonuspoäng för SLI/SLO-definitioner och incidentpostmortemserfarenhet.

Viktiga färdigheter att lyfta fram

Moln och infrastruktur:

• AWS (EC2, EKS, ECS, Lambda, RDS, S3, CloudFront, Route 53, IAM, VPC)
• Terraform/OpenTofu, Pulumi, CloudFormation
• Kubernetes: Helm, Kustomize, ArgoCD, Flux, klusterhantering
• Nätverk: VPN:er, VPC-peering, service meshes, ingress-kontroller

CI/CD och automatisering:

• GitHub Actions, GitLab CI, Jenkins (deklarativa pipelines), Buildkite
• Artefakthantering: ECR, Artifactory, Nexus
• Integration av säkerhetsskanning: Trivy, Snyk, Checkov, tfsec
• Hemlighethantering: HashiCorp Vault, AWS Secrets Manager, SOPS

Observerbarhet:

• Prometheus + Grafana + Alertmanager
• ELK-stack (Elasticsearch, Logstash, Kibana) eller OpenSearch
• Datadog, New Relic, Dynatrace
• Distribuerad spårning: Jaeger, Tempo, OpenTelemetry

Skriptning och utveckling:

• Bash, Python (särskilt boto3, subprocess-baserad automatisering)
• Go för verktyg värderas allt mer
• Git, grenstrateger, GitOps-arbetsflöden

Starka kontra svaga bullets

DevOps-CV:n lider av konfigurationsanteckningssyndromet – bullets som beskriver vad ett system gör, inte vad du byggde, fixade eller förbättrade.

Svag: Satte upp Kubernetes-kluster på AWS med EKS. Stark: Designade och deployade ett produktions-EKS-kluster över 3 tillgänglighetszoner för en 40-mikrotjänst-applikation, implementerade Cluster Autoscaler och Karpenter för nodprovisionering – reducerade infrastrukturkostnader med 28 % jämfört med den tidigare fasta kapacitetskonfigurationen med 99,95 % drifttid under 6 månader.

Svag: Underhöll CI/CD-pipelines med GitHub Actions. Stark: Omstrukturerade en 45-minuters monolitisk GitHub Actions-build till en parallell matrixpipeline med delade cachelager och återanvändbara arbetsflöden; reducerade genomsnittlig bygg-till-deploy-tid från 47 minuter till 11 minuter över 12 tjänster.

Svag: Hanterade molninfrastruktur och hjälpte till med kostnadsreducering. Stark: Ledde en 3-månaders AWS-kostnadsoptimieringsinitiativ med Cost Explorer och Compute Optimiser – identifierade och rätt-storleksanpassade 60 överprovisionerade EC2-instanser, migrerade 8 arbetsbelastningar till Graviton2 och introducerade S3 Intelligent-Tiering; uppnådde en minskning på 14 000 kr/månad i molnutgifter.

Vanliga misstag som kostar dig intervjuer

1. Att leda med en teknologidump. Att öppna ditt CV med en 40-punkts kompetensmatris signalerar att du vill bli hittad via nyckelordsmatchning, inte att du har något intressant att säga om hur du använder de kompetenserna. Sätt en fokuserad professionell sammanfattning först och låt kompetensssektionen bekräfta vad erfarenhetssektionen redan demonstrerat.

2. Att göra anspråk på verktyg utan djupsignaler. Att skriva "Kubernetes" i en kompetenslista när du bara kört ett lokalt Minikube-kluster är en risk – varje decent teknisk intervjuare kommer att undersöka det. Antingen kvalificera påståendet ("Kubernetes i produktionsarbetsbelastningar") eller var beredd att gå på djupet.

3. Inga tillförlitlighetsmätvärden. DevOps handlar i grunden om tillförlitlighet. Om du har förbättrat drifttid, reducerat MTTR, nått SLO-mål eller reducerat felfrekvenser, hör de siffrorna hemma på ditt CV. Ett DevOps-CV utan tillförlitlighetssiffror väcker frågan om du mätte något alls.

4. Att ignorera säkerhet. DevSecOps är inte ett buzzword 2026 – det är en förväntan. Nämn säkerhetsskanning, hemlighethantering, least-privilege IAM-policyer eller arbete med leveranskedjesäkerhet om du har gjort det. Roller som inte uttryckligen ber om det värderar det ändå.

Hur du anpassar ditt CV för varje ansökan

DevOps-roller varierar dramatiskt. En plattformsingenjörsposition på ett fintech scale-up prioriterar Kubernetes-operatörutveckling, IaC i skala och verktyg för utvecklarupplevelse. En traditionell ops-tung roll på ett stort enterprise kan prioritera incidenthanteringsprocess, ITIL-bekantskap och äldre systemmigrering. Ett startup vill ha någon som äger allt från dag ett.

Läs jobbannonsen noggrant för de signalerna och justera din betoning därefter. Ett en-storlek-passar-alla DevOps-CV kommer konsekvent att underprestera ett anpassat, för att klyftan mellan vad varje roll faktiskt behöver är stor.

NextCV hanterar detta genom att läsa jobbbeskrivningen och dra de mest relevanta delarna av din bakgrund in i skarpare fokus för just den rollen. Om du söker till både ett startup och ett enterprise på samma vecka bygger AI:n varje version kring vad den arbetsgivaren bryr sig mest om – snarare än att lämna dig att göra den analysen manuellt för varje ansökan.

Avslutande tankar

De bästa DevOps-CV:na läser som arkitektoniska beslutsdokument: opinionerade, specifika och kopplade till resultat. Visa tänkandet bakom verktygsvalen, namnge de siffror som berättar tillförlitlighetshistorien och gör det klart att du äger de system du arbetar med snarare än att bara operera dem. Det är CV:t som ger den tekniska telefonskärmen.