Myten om fullstack DevOps-ingenjören

Jag tror inte det finns en sann fullstack DevOps-ingenjör i dagens värld. Inte för att folk saknar ambition — utan för att fältet är för brett och för djupt. Det är inte ett misslyckande, det är en naturlig konsekvens av att komplexiteten har exploderat.

Vad 'DevOps' faktiskt täcker idag

• Molnarkitektur och infrastruktur (Azure, AWS, GCP)
• CI/CD och leveransflöden (GitHub Actions, Azure DevOps, GitLab CI)
• Containers och orkestreringsplattformar (Kubernetes, OpenShift, Helm)
• IaC och policy-as-code (Terraform, Bicep, OPA)
• DevSecOps och supply chain security (SBOM, SAST, Cosign, SLSA)
• Observabilitet och SRE-praktiker (Prometheus, Grafana, OpenTelemetry)
• Identitet och åtkomstkontroll (Keycloak, Entra ID, RBAC)
• Nätverksarkitektur och zonsegregering
• Plattformsteknik och developer experience
• Förändringsledning och teknisk adoption

En människa kan ha bredd inom alla dessa men djup i kanske tre till fyra. Det är inte ett problem — det är verkligheten. Problemet uppstår när roller eller kunder förväntar sig hela listan.

Det jag gör är att ha tillräckligt djupt kunnande inom leveransflöden, plattformsarkitektur och säkerhet för att kunna navigera helheten — och veta när jag behöver specialisthjälp. Det är en annan sorts kompetens: systemtänk och omdöme, inte omniskiens.

Vad det innebär för uppdrag och team

I praktiken betyder det att de bästa DevOps-satsningarna jag sett har kombinerat en person med helhetssyn med specialister för djupet. En platform engineer som förstår säkerhetskedjans logik men samarbetar med en security engineer för SBOM-detaljer och en SRE för SLO-design.

Det handlar om att bygga rätt team — inte om att hitta en enda person som kan allt.