DevOps-Engineer Skill-Roadmap für 2026

DevOps ist 2026 Platform Engineering plus SRE plus ein übrig gebliebener Ruf als „CI/CD-Person“, den manche Unternehmen noch haben. Diese Roadmap deckt den modernen Stack ab — Kubernetes, Terraform, Observability, SLOs, Secrets — plus einen 12-Monats-Plan, um ein einstellbarer DevOps-/Platform-Engineer zu werden.

Viele Unternehmen nennen die Rolle nicht mehr „DevOps“ und heute „Platform-Engineer“, „SRE“ oder „Infrastructure-Engineer“. Die Arbeit überschneidet sich stark. Wenn Sie ein Kubernetes-Cluster betreiben, Terraform schreiben können, das keine Credentials leakt, CI/CD ausliefern, das Entwickler tatsächlich mögen, und auf einen 3-Uhr-nachts-Page reagieren können, ohne es schlimmer zu machen, finden Sie eine Stelle unter mindestens einem dieser Titel.

Wer ist ein DevOps-Engineer im Jahr 2026

Ein DevOps-/Platform-Engineer verantwortet den Weg vom Code in die Produktion. Konkret:

• Entwirft und pflegt CI/CD-Pipelines, die Entwickler nutzen können, ohne Tickets zu erstellen.
• Verantwortet Cloud-Infrastruktur als Code — Terraform/Pulumi, mit reviewbaren PRs und einem State Store, der keine Daten verliert.
• Betreibt das Produktions-Kubernetes-Cluster (oder das Serverless-Äquivalent) und ist dafür On-Call.
• Verantwortet Observability: Metriken, Logs, Traces, Alerts, Runbooks, Error Budgets.
• Verwaltet Secrets, IAM, Netzwerkrichtlinien und die langweiligen Teile der Sicherheit, für die sich sonst niemand meldet.

Junior DevOps: schreibt eine GitHub Action, debuggt eine Pipeline. Mid-Level: verantwortet die Infra eines Services End-to-End, inklusive seiner Dashboards. Senior: entwirft die Plattform, auf der mehrere Teams bauen, setzt die SLOs, treibt den Incident-Review-Prozess voran.

Core-Stack — was man wirklich lernen sollte

Soft Skills und Systemdenken

• Developer-Empathie. Die Plattform, die Sie bauen, ist für andere Engineers. Wenn sie Tickets erstellen müssen, um sie zu nutzen, haben Sie die falsche Plattform gebaut.
• Blameless-Postmortem-Disziplin. Ausfälle sind systemisch. Gehen Sie mit gutem Beispiel voran: stehen Sie zu Ihrem Anteil am Fehler, fokussieren Sie auf systemische Fixes.
• Kostenbewusstsein. Cloud-Rechnungen geraten schnell außer Kontrolle. Ein Senior DevOps-Engineer reduziert in den meisten Unternehmen binnen Monaten nach Eintritt 20–30 % der Rechnung.
• Langweilig ist gut. Langweilige Infrastruktur ist zuverlässige Infrastruktur. Widerstehen Sie dem Drang, das neueste Tool zu verwenden.
• Dokumentation als Gewohnheit. Runbooks, Architekturdiagramme, Decision Records. Der Engineer, der dokumentiert, besitzt die Schicht.

Empfohlener 3-/6-/12-Monats-Plan

Monate 1–3: Linux + Docker + Cloud-Grundlagen

• Werden Sie auf der Kommandozeile sicher. Richten Sie ein Homelab oder einen Free-Tier-Cloud-Account ein.
• Lernen Sie Docker richtig: Multi-Stage-Builds, Netzwerke, Volumes, Compose.
• Wählen Sie eine Cloud. Deployen Sie einen kleinen Service manuell. Lernen Sie IAM, VPC und grundlegendes Networking.

Monate 4–6: Kubernetes + IaC

• Betreiben Sie ein Kubernetes-Cluster (k3s, kind oder managed). Deployen Sie eine echte App mit Ingress, Secrets und Persistent Volumes.
• Lernen Sie Terraform. Verwalten Sie Ihr Cluster, Ihr DNS, Ihren Secrets Store mit Code.
• Richten Sie eine CI/CD-Pipeline ein (GitHub Actions oder GitLab CI), die baut, testet und in Ihr Cluster deployt.
• Lesen Sie „The Phoenix Project“ und das „Google SRE Book“ (kostenlos online).

Monate 7–12: Observability, SRE, Interviews

• Binden Sie Prometheus + Grafana + Loki + Alertmanager auf Ihrem Cluster an. Bauen Sie ein echtes Dashboard.
• Definieren Sie ein SLO für Ihre App und ein Error Budget. Führen Sie ein Chaos-Experiment durch, das es aufbraucht.
• Üben Sie DevOps-System-Design: entwerfen Sie eine CI/CD-Plattform, eine Logging-Pipeline, ein Multi-Region-Deployment.
• Bewerben Sie sich mit einem Portfolio, das ein GitHub-Repo mit vollständigem IaC, CI/CD und Dashboard-Screenshots enthält.

Side-Projects zum Bauen

• Eine vollständige GitOps-Plattform in einem Repo. Terraform fürs Cluster, ArgoCD für Apps, Prometheus-Stack für Observability. Zeigt alles zusammen.
• Ein Multi-Environment-IaC-Layout. Dev/Staging/Prod mit Workspace- oder Verzeichnis-Trennung, Drift-Erkennung, Plan-on-PR. Zeigt eine realistische Struktur.
• Ein (kleiner) Kubernetes-Operator. Schreiben Sie einen Controller für eine Custom Resource. Zeigt Tiefe jenseits von Oberflächen-kubectl.
• Ein Kostenoptimierungs-Writeup. Nehmen Sie eine echte oder simulierte Rechnung und zeigen Sie die Schritte, sie um 30 % zu senken. FinOps wird zunehmend Teil der Rolle.

SLOs, Error Budgets und On-Call-Sanity

Die SRE-Praktiken, die Senior DevOps-Engineers von „baut Pipelines“-Engineers trennen, kommen aus einem mentalen Wandel: Sie können Zuverlässigkeit und Feature-Velocity nicht gleichzeitig maximieren, also müssen Sie den Trade-off explizit machen.

• Wählen Sie einen SLI pro Service. Verfügbarkeit für eine API. End-to-End-Latenz für einen kritischen Nutzerflow. Job-Erfolgsrate für einen Worker. Wählen Sie einen, der auf die Nutzererfahrung abbildet, nicht auf interne Metriken.
• Setzen Sie das SLO auf dem richtigen Niveau. 99,9 % klingt vernünftig, bis Sie merken, dass das 43 Minuten Downtime-Budget pro Monat sind. 99,99 % sind 4 Minuten pro Monat, und auf dem Niveau können Sie nicht wöchentlich deployen.
• Nutzen Sie das Error Budget. Wenn Sie dieses Quartal 30 Minuten Downtime-Budget haben, verbrauchen Sie 20 davon für riskante Deploys. Sprengen Sie das Budget, frieren Sie Feature-Deploys bis zum nächsten Fenster ein.
• Runbooks schlagen Helden. Jeder Alert verweist auf ein Runbook mit den ersten drei Diagnose-Kommandos. Der On-Call-Engineer, der diesen Service nie angefasst hat, sollte nicht um 3 Uhr nachts den Experten paging müssen.
• Page actionable, nicht informativ. Ein Alert, der keine menschliche Aktion erfordert, sollte nicht pagen. Verschieben Sie ihn auf ein Dashboard, einen Wochenbericht oder löschen Sie ihn. Pager-Fatigue ist der stille Killer der On-Call-Qualität.
• Blameless Postmortems. Die Action Items fokussieren auf das System, nicht auf die Person. „Engineer X hat ohne Staging deployt“ ist keine Root Cause; „die Pipeline erlaubte ein Prod-Deploy ohne grünes Staging“ schon.
• Game Days. Planen Sie einen pro Quartal, brechen Sie absichtlich etwas im Staging, führen Sie den Incident durch. Die Fähigkeit des Incident Command verfällt ohne Übung schnell.

In Senior-Interviews ist die Frage selten „kennen Sie K8s“. Sie lautet „führen Sie mich durch den letzten Produktions-Incident, den Sie geleitet haben“. Halten Sie die Zeitleiste, die Diagnoseschritte, den Sofort-Fix und die systemische Änderung bereit.

Wie Sie die DevOps-Stelle bekommen

• Lebenslauf-Keywords. Kubernetes, Terraform, AWS oder GCP, CI/CD-Tool, Prometheus, Grafana, OpenTelemetry, Helm, GitHub Actions, ArgoCD falls relevant.
• Ein Repo, in dem alles verdrahtet ist. Das aussagekräftigste einzelne Artefakt — eine deploybare, dokumentierte Plattform.
• Interview-Runden: Linux-/Networking-Troubleshooting, System Design (eine CI/CD- oder Observability-Pipeline bauen), Behavioral mit On-Call-Geschichten, manchmal ein Take-home (ein Terraform-Modul schreiben).
• Die Troubleshooting-Runde. Oft live: „hier ist ein kaputtes Kubernetes-Deployment, repariere es“. Üben Sie an absichtlich kaputten Clustern.
• Die On-Call-Geschichte. Halten Sie 4–5 Incident-Geschichten bereit. Was kaputtging, wie Sie es fanden, was Sie änderten, welcher systemische Fix folgte.

FAQ