Dienstag, 2:14 Uhr nachts. Ein Alert feuert: Die Latenz des Checkout-Service überschreitet das SLO von 200 Millisekunden. Bevor Sarah, die diensthabende DevOps Engineerin, ihr Laptop aufklappt, hat das AIOps-System bereits den Root Cause identifiziert: Ein Memory Leak in der neuesten Deployment-Version. Grafana zeigt die Anomalie rot markiert, K8sGPT hat einen Rollback-Vorschlag als Draft-PR erstellt. Sarah prüft den Vorschlag, bestätigt mit einem Klick. Vier Minuten später läuft alles wieder.
Vor zwei Jahren hätte Sarah selbst die Logs durchsuchen, den Fehler eingrenzen und den Rollback manuell ausführen müssen. 30 Minuten statt vier. KI hat ihre Arbeit nicht ersetzt, aber beschleunigt. Dieses Muster zieht sich durch den gesamten Beruf: Mehr Tempo, gleiche Verantwortung.
Dieser Artikel ordnet ein, wie KI die Infrastrukturarbeit verändert, welche neuen Konzepte den Beruf prägen und warum die Rolle nicht verschwinden wird, auch wenn sich alles um sie herum verändert.
KI-Tools im Arbeitsalltag: Was funktioniert wirklich?
GitHub Copilot führt den Markt für KI-Coding-Assistenten mit 20 Millionen Nutzern und 42 % Marktanteil [1]. Ursprünglich für Anwendungscode gedacht, generiert Copilot mittlerweile auch Terraform-Module, Kubernetes-Manifeste, Ansible-Playbooks und Dockerfiles. Die Qualität schwankt: Für Standard-Konfigurationen brauchbar, für komplexe Multi-Resource-Module mit Abhängigkeiten unzuverlässig.
K8sGPT ist das spezialisierteste Tool im Infrastrukturbereich. Es analysiert Kubernetes-Cluster, identifiziert Probleme und schlägt Lösungen in natürlicher Sprache vor [2]. Crash-Loops, fehlende ConfigMaps, falsche Resource-Limits: K8sGPT findet diese Probleme schneller als manuelles Debugging. Aber: Es erklärt Symptome, nicht immer Root Causes.
Datadog und Grafana haben KI-gestützte Anomalieerkennung integriert. Statt statische Schwellenwerte zu definieren (CPU > 90 Prozent = Alert), erkennen die Systeme Abweichungen vom normalen Verhalten. Das reduziert False Positives und hilft bei der Früherkennung, bevor Nutzer betroffen sind.
Wo hilft KI wirklich und wo versagt sie?
KI funktioniert gut bei: YAML-Generierung, Standard-Terraform-Ressourcen, Log-Analyse, Anomalieerkennung, Vorschläge für K8s-Troubleshooting. Alles, was Muster erkennen und aus vorhandenen Daten lernen kann.
KI versagt bei: Architekturentscheidungen für verteilte Systeme. Multi-Region-Failover-Strategien. DSGVO-konforme Datenarchitektur. Kosten-Nutzen-Abwägungen für Migrationen. Incident Response unter Zeitdruck mit unvollständigen Informationen. Blameless Postmortems moderieren. Alles, was Kontext, Geschäftsverständnis und menschliches Urteilsvermögen erfordert.
Neben Copilot existiert eine wachsende Zahl spezialisierter Tools. Cursor, der KI-native Code-Editor, hat sich für Infrastructure-as-Code-Arbeit als produktive Alternative etabliert [3]. Amazon Q zielt auf Enterprise-Kunden mit AWS-Integration. Die Veracode-Studie aus 2025 zeigt allerdings: 45 % des KI-generierten Codes besteht grundlegende Sicherheitstests nicht [4]. Im Infrastrukturbereich wiegt das besonders schwer, weil ein falsch konfigurierter Security Group Ingress direkte Angriffsvektoren öffnet.
Claude Code und ähnliche KI-Agenten gehen einen Schritt weiter als reine Code-Completion, weil sie ganze Workflows automatisieren können: Terraform-Module schreiben, planen, anwenden und die Ergebnisse validieren, alles in einer einzigen Interaktion. Für Routineaufgaben wie das Anlegen eines neuen Microservice mit zugehörigem K8s-Deployment, Service und Ingress spart das tatsächlich Zeit. Für die Migration einer bestehenden Produktionsumgebung mit historisch gewachsenen Abhängigkeiten und undokumentierten Sonderfällen fehlt den Agenten der Kontext, den nur ein Mensch mit Erfahrung im jeweiligen System mitbringen kann.
Meine ehrliche Einschätzung nach einem Jahr Arbeit mit KI-Tools im Infrastrukturbereich: Die Produktivitätssteigerung liegt bei 15 bis 25 Prozent für erfahrene Engineers, die den generierten Code beurteilen und korrigieren können. Für Juniors ist der Produktivitätsgewinn geringer, weil sie mehr Zeit mit der Prüfung des Outputs verbringen und Fehler schlechter erkennen. Die größte Gefahr: blindes Vertrauen in generierte Konfigurationen, die syntaktisch korrekt, aber sicherheitstechnisch problematisch sind.
Welche Skills werden in fünf Jahren irrelevant?
Nicht jede Technologie, die heute zum Arbeitsalltag gehört, wird in fünf Jahren noch relevant sein. Manuelle Server-Provisionierung ist bereits weitgehend obsolet, aber einige aktuelle Technologien stehen ebenfalls vor dem Abstieg, und wer seine Lernzeit falsch investiert, verliert wertvolle Monate an sterbende Ökosysteme.
Puppet und Chef befinden sich im sichtbaren Niedergang. Beide Configuration-Management-Tools stammten aus der Ära, in der Server jahrelang liefen und regelmäßig konfiguriert werden mussten. In einer Welt aus kurzlebigen Containern und immutabler Infrastruktur löst sich ihr Kernproblem auf: Statt Server zu konfigurieren, baut man neue Container und ersetzt die alten. Ansible hält sich besser, weil es flexibler einsetzbar ist, aber auch sein Marktanteil schrumpft zugunsten von Terraform und Kubernetes-nativen Ansätzen.
Jenkins verliert seit Jahren Marktanteile an GitHub Actions, GitLab CI und Cloud-native Alternativen wie Tekton. Die Plugin-Architektur, einst Stärke, ist zur Achillesferse geworden: Sicherheitslücken in Plugins, Inkompatibilitäten nach Updates, eine Groovy-basierte DSL, die niemand freiwillig liest. Wer heute noch tief in Jenkins investiert, sollte parallel Erfahrung mit moderneren CI/CD-Systemen aufbauen, um den Anschluss nicht zu verlieren, denn viele Unternehmen migrieren aktiv weg von Jenkins.
Docker Swarm spielt im Enterprise-Bereich kaum noch eine Rolle, auch wenn Mirantis Support bis 2030 zugesichert hat. Kubernetes hat den Orchestrierungskrieg gewonnen, und Docker Inc. selbst konzentriert sich auf Developer-Tooling und KI. Klassisches Monitoring mit Nagios und Zabbix wird von Prometheus und Grafana verdrängt. Und reine Bash-Scripting-Skills für Automatisierung weichen Python und Go, weil beide Sprachen besser testbar, wartbar und in bestehende Ökosysteme integrierbar sind.
Platform Engineering: Die Evolution des Berufsbilds
Gartner prognostiziert, dass bis Ende 2026 rund vier Fünftel der großen Software-Engineering-Organisationen eigene Platform-Teams betreiben werden [5]. Das ist keine Ablehnung von DevOps, sondern seine konsequente Weiterentwicklung.
Die Grundidee: Statt jedem Entwicklerteam eigene Infrastruktur-Expertise abzuverlangen, baut ein Platform-Team eine interne Entwicklerplattform (IDP), die Selbstbedienung ermöglicht. Entwickler deployen über ein Portal oder CLI, ohne Kubernetes-Manifeste schreiben zu müssen. Backstage von Spotify ist das bekannteste Open-Source-Framework dafür [6]. Humanitec und Port bieten kommerzielle Alternativen.
„You Build It, You Run It“, das Mantra der Bewegung, wird dabei nicht abgeschafft, sondern differenziert. Entwicklerteams bleiben verantwortlich für ihre Services, aber die Plattform abstrahiert die Komplexität der darunterliegenden Infrastruktur. Das halte ich für die wichtigste Verschiebung im Berufsbild der letzten Jahre.
Für Infrastrukturspezialisten bedeutet Platform Engineering: weniger Ticket-basierte Infrastrukturarbeit, mehr Produktentwicklung. Die Plattform selbst wird zum Produkt, mit internen Entwicklern als Kunden. Das erfordert neue Fähigkeiten: Produktdenken, UX-Sensibilität für Developer Experience, API-Design für Self-Service-Interfaces. Wer diese Kombination beherrscht, wird zur gefragten Fachkraft.
Wie sieht eine Internal Developer Platform konkret aus?
Eine typische IDP besteht aus vier Schichten, die aufeinander aufbauen und gemeinsam den gesamten Entwicklerzyklus von der Code-Änderung bis zum produktiven Deployment abdecken. Die unterste Schicht ist die Infrastruktur: K8s-Cluster, Infrastrukturressourcen, Netzwerke, Datenbanken, alles per Terraform oder Crossplane provisioniert. Darüber liegt die Orchestrierungsschicht: ArgoCD oder Flux für GitOps, Tekton oder GitHub Actions für CI/CD, Vault für Secrets Management.
Die dritte Schicht ist der Service-Katalog: Backstage (oder eine kommerzielle Alternative wie Port oder Humanitec) als zentrales Portal, in dem Entwickler neue Services anlegen, Dokumentation finden und den Status ihrer Deployments sehen können, ohne dafür K8s-Manifeste von Hand schreiben oder Terraform-States verstehen zu müssen. Die oberste Schicht ist die Developer-Experience-Schicht: CLI-Tools, IDE-Plugins, Slack-Bots, die den Entwicklern ermöglichen, mit der Plattform zu interagieren, ohne das Portal öffnen zu müssen.
Das halte ich für die spannendste Entwicklung im Berufsbild seit der Einführung von Kubernetes: Platform Engineers denken nicht in Tickets, sondern in Produktmetriken wie Adoption Rate, Time-to-First-Deploy und Developer Satisfaction Score, also Kennzahlen, die messen, ob die Plattform ihren internen Kunden tatsächlich hilft oder nur ein weiteres System ist, das niemand freiwillig benutzt.
DevSecOps: Sicherheit gehört in die Pipeline
Die NIS-2-Richtlinie der EU, die seit Oktober 2024 in den Mitgliedstaaten umzusetzen ist, verschärft die Anforderungen an IT-Sicherheit in kritischen und wichtigen Sektoren [7]. Deutschland hat die Umsetzungsfrist deutlich überschritten und das NIS2-Umsetzungsgesetz erst im Dezember 2025 in Kraft gesetzt. Für Infrastrukturspezialisten bedeutet das: Sicherheit ist kein nachgelagerter Prüfschritt mehr, sondern integraler Bestandteil jeder Pipeline.
Shift-Left Security heißt die Devise. Container-Images scannen mit Trivy oder Snyk, bevor sie deployed werden. Dependencies auf bekannte Schwachstellen prüfen mit Dependabot oder Renovate. Infrastructure-as-Code-Templates gegen Security-Policies validieren mit OPA/Gatekeeper oder Checkov. Policy-as-Code macht Sicherheitsregeln reproduzierbar und versionierbar.
DevSecOps-Kompetenz wird zum Gehaltsverstärker. Wer Sicherheit und DevOps kombiniert, bedient eine Nachfrage, die schneller wächst als das Angebot an Fachkräften. Die DSGVO, NIS-2, der AI Act der EU: Regulierung wird nicht weniger, und jemand muss sie in Infrastruktur übersetzen.
Ein konkretes Beispiel aus der Praxis: Ein mittelständischer Versicherer in Köln führte 2025 eine vollautomatisierte Security-Pipeline ein, die bei jedem Push Container-Images mit Trivy scannt, Terraform-Pläne mit Checkov validiert und Secrets mit dem GitLeaks-Scanner prüft, bevor der Merge-Request überhaupt reviewbar wird. Die Implementierung dauerte drei Monate. Danach sank die Zahl der Security-Incidents in Produktion um 60 %, und die BaFin-Audits liefen deutlich reibungsloser, weil jede Sicherheitsprüfung als Git-Commit nachvollziehbar war.
Für den Arbeitsmarkt bedeutet das: Wer neben Kubernetes und Terraform auch Trivy, OPA und OWASP-Grundlagen beherrscht, qualifiziert sich für Positionen, die zehn bis 20 % über dem Marktdurchschnitt liegen. Die Kombination aus Infrastructure-Automatisierung und Security-Know-how ist in der DACH-Region besonders gefragt, weil die regulatorischen Anforderungen hier strenger sind als in vielen anderen Märkten.
FinOps: Warum Infrastrukturkosten zur Teamaufgabe werden
98 Prozent der Organisationen managen mittlerweile ihre KI-Ausgaben als Teil von FinOps, neun Zehntel integrieren SaaS-Kosten [8]. Cloud-Kosten sind nicht mehr nur ein Thema für das Controlling, sondern für die Teams, die die Infrastruktur provisionieren.
Ops-Fachleute sehen die Kosten ihrer Entscheidungen direkt: Ein überdimensionierter EKS-Cluster kostet 3.000 Euro pro Monat zu viel. Eine vergessene Dev-Umgebung läuft Monate ohne Nutzer. Spot-Instances statt On-Demand sparen 60 bis 90 Prozent, erfordern aber Architekturänderungen. Tools wie Kubecost, Infracost und die nativen Kostenmanagement-Dienste der Hyperscaler machen diese Transparenz möglich.
FinOps ist noch kein Pflichtskill, aber ein Differenzierungsmerkmal. Wer in Bewerbungsgesprächen erklären kann, wie man Cloud-Kosten um 30 Prozent senkt, ohne die Zuverlässigkeit zu beeinträchtigen, hebt sich von der Masse ab. Die FinOps Foundation verzeichnet exponentielles Wachstum bei Mitgliedschaften und Zertifizierungen [8].
Drei FinOps-Tools haben sich in der Praxis durchgesetzt. Kubecost, dessen Open-Source-Kern OpenCost CNCF-Incubation-Status hat, zeigt Infrastrukturkosten auf Namespace-, Deployment- und Pod-Ebene an. Die Open-Source-Version reicht für die meisten Teams. Infracost verfolgt einen anderen Ansatz: Es integriert sich direkt in die CI/CD-Pipeline und kommentiert jeden Terraform-Pull-Request mit den geschätzten monatlichen Kostenänderungen. Bevor ein Engineer eine m5.2xlarge-Instanz provisioniert, sieht das gesamte Team im PR die monatlichen Mehrkosten von 280 Euro. Das verändert die Diskussionskultur.
CAST AI geht noch weiter und automatisiert das Right-Sizing für K8s-Workloads komplett. Das Tool analysiert die tatsächliche Ressourcennutzung, schlägt optimale Instance-Typen vor und migriert Workloads bei Bedarf automatisch auf Spot-Instances. Unternehmen berichten von Einsparungen zwischen 50 und 65 Prozent bei den Compute-Kosten [8]. Der ROI dieser Tools ist messbar und oft enorm: Infracost kostet in der Team-Version ab rund 50 Dollar pro Monat, spart aber bei einem typischen AWS-Setup mehrere tausend Euro allein durch bewusstere Ressourcenwahl. Kubecost amortisiert sich in Unternehmen mit mehr als 5.000 Euro monatlichen Infrastrukturausgaben fast immer innerhalb des ersten Monats.
Wie sieht ein konkretes Kostenoptimierungsprojekt aus?
Ein Beispiel aus der Praxis: Ein mittelständisches E-Commerce-Unternehmen mit 15 Microservices auf AWS EKS zahlt monatlich 28.000 Euro an Infrastrukturkosten. Der erste Schritt ist eine Bestandsaufnahme mit Kubecost, das die Kosten pro Namespace, Deployment und sogar pro Container aufschlüsselt. Ergebnis: Drei Dev-Umgebungen laufen rund um die Uhr, obwohl sie nur während der Arbeitszeiten genutzt werden.
Maßnahme eins: Karpenter als Cluster-Autoscaler einsetzen, der Nodes automatisch auf Spot-Instances provisioniert und die Workloads intelligent auf die günstigsten verfügbaren Instanztypen verteilt, was allein die Compute-Kosten um 40 Prozent senkt. Maßnahme zwei: Dev-Umgebungen per CronJob nachts und am Wochenende herunterfahren, Ersparnis weitere 3.000 Euro monatlich. Maßnahme drei: Right-Sizing der Resource Requests und Limits basierend auf tatsächlicher Nutzung statt auf großzügigen Schätzungen. Gesamteffekt nach drei Monaten: 28.000 Euro runter auf 17.500 Euro, eine Reduktion um 37 Prozent bei gleicher Verfügbarkeit.
Karrierepfade: Wohin führt DevOps nach dem Senior-Level?
Die Karriereleiter im Infrastrukturbereich verzweigt sich nach dem Senior-Level in drei Richtungen: technische Vertiefung, Führung oder Spezialisierung.
Der Wechsel in eine Architektur-Rolle bedeutet: weniger Hands-on, mehr Entscheidungen mit langfristiger Tragweite. Welche Infrastrukturstrategie verfolgt das Unternehmen? Wie sieht die Plattform in drei Jahren aus? Welche Tools standardisieren wir? Architekten beeinflussen Teams, ohne direkt Code zu schreiben.
Der Weg ins Management erfordert Soft Skills, die im technischen Alltag weniger gefragt sind: Einstellungsgespräche führen, Budgets verhandeln, Karriereentwicklung für Teammitglieder planen. Nicht jeder gute DevOps Engineer wird ein guter Manager. Die ehrliche Selbsteinschätzung, ob man Menschen oder Systeme lieber optimiert, spart später Enttäuschung.
Freelancing als dritter Pfad bietet finanzielle Freiheit bei gleichzeitigem Verlust der Teamanbindung. Erfahrene Freelancer mit Kubernetes- und Cloud-Spezialisierung erzielen Stundensätze von 100 bis 150 Euro in der DACH-Region, wobei Migrationsprojekte und Platform-Aufbau die lukrativsten Auftragsarten darstellen, weil sie lange Projektlaufzeiten von sechs bis zwölf Monaten mit sich bringen und somit die Akquiselücken zwischen Projekten minimieren.
Mein Eindruck nach Gesprächen mit Dutzenden von Infrastrukturprofis in verschiedenen Karrierestufen: Die zufriedensten arbeiten in Rollen, die technische Tiefe mit strategischem Einfluss verbinden. Staff-Engineer-Positionen oder Architektenrollen, in denen man sowohl Code schreibt als auch Architekturentscheidungen für das Unternehmen trifft, treffen genau diesen Punkt.
Warum der Beruf nicht verschwindet
Vier Gründe, warum Infrastrukturspezialisten auch in fünf Jahren gefragt sein werden.
Erstens: Die Infrastrukturkomplexität steigt. Multi-Cloud, Edge Computing, K8s-Föderationen, Hybrid-Cloud-Architekturen. Jede neue Abstraktionsschicht erfordert Menschen, die sie verstehen und betreiben.
Zweitens: Regulierung wird strenger. DSGVO, NIS-2, AI Act, branchenspezifische Anforderungen von BaFin bis TGA. Compliance in Infrastruktur übersetzen ist menschliche Arbeit, die kein Algorithmus übernehmen kann.
Drittens: Verantwortung lässt sich nicht automatisieren. Wenn ein Produktionssystem ausfällt, braucht es jemanden, der entscheidet: Rollback oder Hotfix? Kunden informieren oder warten? Eskalieren oder selbst lösen? Diese Entscheidungen erfordern Kontext, Erfahrung und die Bereitschaft, Verantwortung zu übernehmen.
Viertens: KI erzeugt neue Infrastrukturbedürfnisse. ML-Pipelines brauchen GPU-Cluster, Modell-Serving braucht Autoscaling, Training braucht Spot-Instances und Storage-Management. Jede KI-Anwendung in Produktion generiert Infrastrukturarbeit. Die Technologie, die angeblich Infrastrukturjobs bedroht, schafft gleichzeitig neue.
Ein fünfter Punkt, der selten genannt wird: die wachsende Bedeutung von Observability in verteilten Systemen. Microservice-Architekturen mit 50, 100 oder 200 Services erzeugen Datenmengen, die ohne spezialisierte Infrastruktur nicht beherrschbar sind. Traces, Metriken, Logs: Jemand muss die Systeme bauen und betreiben, die diese Datenflut sinnvoll aufbereiten und in Echtzeit analysierbar machen, damit Entwicklerteams Probleme schnell eingrenzen können, statt stundenlang in Logfiles zu suchen.
Dazu kommt ein Trend, der noch wenig Aufmerksamkeit bekommt: die Demokratisierung von Infrastrukturwissen. Platform Engineering ermöglicht es Entwicklern, Infrastruktur über Abstraktionen zu nutzen, ohne sie im Detail verstehen zu müssen. Das verschiebt die Anforderungen an die Infrastrukturspezialisten nach oben: Einfache Provisionierungsaufgaben werden weniger gebraucht, dafür steigt die Nachfrage nach Architekten, die diese Plattformen entwerfen und betreiben können.
Meine persönliche Einschätzung nach Beobachtung des Marktes über die letzten Jahre: Die Jobtitel werden sich ändern, die Aufgaben nicht. Ob jemand in fünf Jahren als Platform Engineer, Cloud Infrastructure Architect oder Internal Developer Experience Lead arbeitet, spielt keine Rolle, denn die Kernaufgabe bleibt dieselbe: dafür sorgen, dass Software zuverlässig, sicher und kosteneffizient in Produktion läuft. Solange Unternehmen Software betreiben, brauchen sie Menschen, die die Infrastruktur verstehen und verantworten. An dieser Grundwahrheit ändert auch die fortschrittlichste KI nichts.
Was sich ändern wird: das Kompetenzprofil. Reine Tool-Expertise reicht in fünf Jahren nicht mehr aus, weil KI die Routine-Konfigurationsarbeit zunehmend übernimmt. Was bleibt und an Wert gewinnt: Systemdenken, Architekturverständnis, Security-Bewusstsein, Kostenkompetenz und die Fähigkeit, technische Entscheidungen im Kontext geschäftlicher Anforderungen zu treffen. Die besten Investitionen für die eigene Karriere sind deshalb nicht die nächste Zertifizierung, sondern ein tiefes Verständnis verteilter Systeme und die Bereitschaft, Verantwortung für das Gesamtsystem zu übernehmen, nicht nur für die eigene Pipeline.
Fazit
KI beschleunigt den Arbeitsalltag bei repetitiven Aufgaben: YAML-Generierung, Log-Analyse, Anomalieerkennung. Platform Engineering verschiebt den Schwerpunkt von Ticket-basierter Infrastrukturarbeit zu Produktentwicklung. DevSecOps und FinOps erweitern das Kompetenzprofil.
Der Beruf wird anspruchsvoller, nicht überflüssig. Wer heute als DevOps Engineer einsteigt, investiert in einen Beruf mit stabiler Nachfrage und wachsendem Verantwortungsbereich. Die größte Gefahr ist nicht KI, sondern Stillstand: Wer aufhört zu lernen, wird in drei Jahren irrelevant.
Sarah aus der Einleitung hat das verstanden. Das AIOps-System nimmt ihr Routinearbeit ab. Die freigewordene Zeit nutzt sie, um die interne Entwicklerplattform weiterzubauen. Weniger nächtliche Feuerwehr, mehr strategische Infrastrukturarbeit. So sieht die Zukunft der Branche aus: nicht weniger Arbeit, sondern andere.
Quellen
[1] TechCrunch: GitHub Copilot Crosses 20M Users, Juli 2025 (https://techcrunch.com/)
[2] K8sGPT: AI-Powered Kubernetes Troubleshooting (https://k8sgpt.ai/)
[3] Cursor: The AI Code Editor (https://cursor.com/)
[4] Veracode: GenAI Code Security Report, Juli 2025 (https://www.veracode.com/)
[5] Gartner: Top Strategic Technology Trends 2026, Platform Engineering (https://www.gartner.com/)
[6] Backstage by Spotify (https://backstage.io/)
[7] Europäische Kommission: NIS-2-Richtlinie (https://digital-strategy.ec.europa.eu/en/policies/nis2-directive)
[8] FinOps Foundation: State of FinOps Report 2026 (https://www.finops.org/)