Donnerstag, 2:47 Uhr nachts. Markus schreckt hoch. Sein Telefon vibriert, PagerDuty meldet einen Critical Alert: Mehrere Pods im Kubernetes-Cluster des Payment-Service sind gleichzeitig abgestürzt, die Fehlerrate schnellt auf fast ein Viertel. Markus arbeitet seit vier Jahren als DevOps Engineer bei einem Fintech-Unternehmen in München. Er öffnet das Laptop, prüft die Grafana-Dashboards, findet einen Out-of-Memory-Fehler in der letzten Deployment-Version. Rollback über ArgoCD. Acht Minuten später läuft alles wieder.
Am nächsten Morgen sitzt Markus im Daily Standup. Er erzählt vom nächtlichen Vorfall, niemand macht ihm Vorwürfe. Stattdessen: ein kurzes Postmortem, Root-Cause-Analyse, ein Jira-Ticket für bessere Memory-Limits. Danach beginnt sein regulärer Tag: Terraform-Module für eine neue Staging-Umgebung schreiben, eine GitHub-Actions-Pipeline für das Data-Science-Team aufsetzen, mit dem Security-Team über Container-Scanning diskutieren.
Wer nach dem täglichen Berufsbild eines Infrastrukturspezialisten fragt, bekommt selten diese Antwort. Stellenanzeigen listen Kubernetes, Terraform und AWS auf. Die Realität ist breiter, chaotischer und vor allem kommunikativer, als die meisten Tools-Listen vermuten lassen. Dieser Artikel beleuchtet, was den Beruf tatsächlich ausmacht, welche verwandten Rollen es gibt und welche Mythen sich hartnäckig halten.
DevOps, SRE, Platform Engineer: Wo liegt der Unterschied?
Diese Jobtitel werden in Stellenanzeigen oft austauschbar verwendet, beschreiben bei genauem Hinsehen aber unterschiedliche Schwerpunkte. Die Grenzen sind fließend, die Unterscheidung hilft trotzdem bei der Berufswahl.
DevOps Engineer ist der breiteste dieser Begriffe. Er beschreibt sowohl eine Kultur als auch eine konkrete Stellenbeschreibung. Die Wurzeln liegen im Jahr 2008, als Patrick Debois und Andrew Shafer sich auf der Agile Conference in Toronto über die Kluft zwischen Entwicklung und Betrieb austauschten. Den eigentlichen Begriff „DevOps“ prägte Debois im Oktober 2009, als er die erste DevOpsDays-Konferenz in Gent organisierte [9]. Seit den frühen 2010er-Jahren hat sich daraus ein eigenständiges Berufsbild entwickelt, das heute in praktisch jedem mittleren bis großen IT-Unternehmen existiert.
Site Reliability Engineering stammt von Google. Ben Treynor Sloss formulierte es so: SRE ist das, was passiert, wenn man einen Software-Ingenieur mit der Aufgabe betraut, ein Betriebsteam zu leiten [1]. Der zentrale Unterschied: SREs arbeiten mit Fehlerbudgets. Wenn ein Service 99,95 Prozent Verfügbarkeit als SLO hat, darf er pro Monat rund 22 Minuten ausfallen. Ist das Budget aufgebraucht, werden keine neuen Features deployed, bis die Stabilität wiederhergestellt ist. Das klingt nach einer Kleinigkeit. In der Praxis verändert es die gesamte Dynamik zwischen Entwicklung und Betrieb.
Warum die Unterscheidung in der Praxis verschwimmt
Bei Zalando nennen sich die Teams Platform Engineering, bei der Deutschen Telekom heißt dieselbe Tätigkeit Cloud Operations. Viele mittelständische Unternehmen in der DACH-Region kennen weder SRE noch Platform Engineering als separate Rolle. Dort heißt alles „DevOps“ und umfasst den gesamten Bereich von CI/CD bis Monitoring. Das ist weder falsch noch schlecht, aber es bedeutet: Wer eine solche Stelle antritt, sollte vorab klären, welche konkreten Aufgaben dahinterstecken.
Gartner prognostiziert, dass bis Ende 2026 rund vier Fünftel der großen Software-Engineering-Organisationen eigene Platform-Teams betreiben werden [2]. Gleichzeitig zeigt der DORA State of DevOps Report 2024, dass Elite-Performer ihre Deployments 182-mal häufiger durchführen als Low-Performer [3]. Hinter diesen Zahlen stecken Menschen, die Pipelines bauen, Cluster verwalten und mitten in der Nacht auf Alerts reagieren. Ob sie sich DevOps Engineer, SRE oder Platform Engineer nennen, hängt mehr von der Unternehmenskultur ab als von der tatsächlichen Tätigkeit.
Wie sieht ein typischer Arbeitstag aus?
Der Morgen beginnt mit einem Blick auf die Monitoring-Dashboards. Hat die Nachtschicht des Alerting-Systems Anomalien gemeldet? Laufen alle Deployments der Nacht sauber durch? Grafana, Datadog oder ein selbstgebautes Dashboard auf Basis von Prometheus zeigen den Zustand der Infrastruktur. Wenn alles grün ist, geht es weiter zum Daily Standup.
Das Standup ist keine Formalität. Hier erfährt Markus, dass das Frontend-Team morgen einen neuen Image-Service ausrollen will. Er muss dafür die Terraform-Konfiguration des CDN anpassen und einen neuen S3-Bucket provisionieren. Gleichzeitig braucht das Data-Team eine neue PostgreSQL-Instanz in der Staging-Umgebung. Priorisierung gehört zum Alltag.
Der Großteil des Tages besteht aus Infrastructure as Code. Terraform-Module schreiben, Kubernetes-Manifeste anpassen, Helm-Charts aktualisieren. Dazwischen: Pull Requests reviewen, die ein Kollege für eine Pipeline-Änderung eingereicht hat. Code-Reviews für Infrastruktur unterscheiden sich grundlegend von Application-Code-Reviews. Ein vergessenes Resource-Limit in einem Kubernetes-Deployment kann den gesamten Cluster destabilisieren. Ein falsch konfigurierter Ingress öffnet Ports, die geschlossen sein sollten.
Am Nachmittag verschiebt sich der Fokus. Markus bereitet ein Upgrade des Kubernetes-Clusters von Version 1.33 auf 1.34 vor. Solche Upgrades klingen harmlos, aber deprecated APIs können laufende Workloads brechen, wenn niemand die Changelog-Einträge gelesen hat. Also prüft er mit kubectl und dem Tool kubent, welche Manifeste betroffen sind, schreibt eine Migration-Checkliste und stimmt das Wartungsfenster mit dem Product Owner ab. Zwischendurch pingt ihn ein Junior-Entwickler auf Slack an, weil ein Docker-Build seit 40 Minuten hängt. Layer-Caching war falsch konfiguriert. Fünf Minuten Pair-Debugging, Problem gelöst.
Gegen 16 Uhr dann der Moment, den jeder Infrastrukturspezialist Engineer kennt: Ein Deployment läuft schief. Das Data-Team hat einen neuen Cronjob deployed, der in der Staging-Umgebung problemlos lief. In Produktion verursacht er plötzlich tausende Datenbankverbindungen pro Sekunde, weil der Connection-Pool nicht limitiert war. Die RDS-Instanz bei AWS erreicht ihr Connection-Limit, andere Services können keine Queries mehr absetzen. Markus sperrt den Cronjob per kubectl, fährt die Datenbankverbindungen manuell runter und schreibt ein Postmortem-Ticket. Der eigentliche Fix dauert drei Zeilen YAML. Das Aufräumen, die Kommunikation und die Dokumentation kosten zwei Stunden.
Wie viel Zeit verbringen DevOps Engineers mit Programmieren?
Weniger als die meisten erwarten. Eine IDC-Studie von 2025 zeigt, dass Entwickler nur ein Sechstel ihrer Arbeitszeit mit eigentlicher Anwendungsentwicklung verbringen [4]. Der Rest verteilt sich auf Security (gut ein Achtel), CI/CD-Implementierung (zwölf Prozent), Monitoring (ebenfalls zwölf Prozent), Deployment und weitere Aufgaben wie Anforderungsdefinition und Qualitätssicherung. Bei Infrastrukturspezialisten dürfte der Anteil reiner Codierarbeit noch niedriger liegen, weil Konfiguration, Troubleshooting und Abstimmung mit anderen Teams den Alltag dominieren. Python und Bash sind unverzichtbar. Aber wer acht Stunden am Tag Code schreiben möchte, wird in dieser Rolle nicht glücklich.
Eine ehrliche Aufschlüsselung der Wochenarbeitszeit sieht bei vielen Ops-Spezialisten so aus: Montags Planungsmeetings und Sprint-Review, dienstags und mittwochs Terraform und Pipeline-Arbeit, donnerstags ein halber Tag Dokumentation und Wissenstransfer, freitags Incident-Review und Verbesserungen an den Runbooks. Dazwischen immer wieder ungeplante Unterstützung für andere Teams.
Was unterscheidet einen guten von einem mittelmäßigen DevOps Engineer?
Die technischen Grundlagen beherrschen viele. Terraform schreiben, Pipelines bauen, Container deployen. Das lässt sich lernen. Der Unterschied zeigt sich in mehreren Bereichen, die schwerer zu trainieren sind.
Erstens: Urteilsvermögen unter Unsicherheit. Ein mittelmäßiger Engineer googelt bei einem Incident den Fehlercode und folgt der erstbesten Stack-Overflow-Antwort. Ein guter analysiert zuerst die Metriken, bildet eine Hypothese und testet gezielt. Bei einem Out-of-Memory-Fehler etwa prüft er, ob der Speicherverbrauch graduell gestiegen ist (Memory Leak) oder sprunghaft (Konfigurationsfehler). Das spart im Ernstfall Stunden, weil die Lösung beim ersten Versuch sitzt.
Zweitens: Ownership über den gesamten Lifecycle. Gute Infrastrukturspezialisten schreiben nicht nur die Pipeline, sondern überwachen auch, ob sie nach einem Quartal noch funktioniert. Sie bauen Alerts für ihre eigene Infrastruktur. Sie dokumentieren ihre Entscheidungen, damit der nächste Kollege nicht raten muss, warum eine bestimmte Netzwerkkonfiguration so und nicht anders aussieht.
Drittens: die Fähigkeit, Nein zu sagen. Mittelmaß heißt: jede Anfrage sofort umsetzen. Gut heißt: Rückfragen stellen. Braucht das Data-Team wirklich einen eigenen Kubernetes-Cluster oder reicht ein Namespace? Muss der neue Service tatsächlich auf AWS Lambda laufen oder passt er besser in die bestehende ECS-Infrastruktur? Solche Entscheidungen verhindern technische Schulden, die sich über Monate aufbauen und irgendwann als Incident zurückkommen.
Warum Kommunikation wichtiger ist als jedes Tool
Der größte Irrtum über den Beruf: Er sei rein technisch. In Wahrheit ist die Rolle eine Übersetzungsleistung zwischen Welten, die unterschiedliche Sprachen sprechen. Entwickler denken in Features und Releases. Der Betrieb denkt in Stabilität und Kosten. Das Management denkt in Deadlines und Budgets. Wer zwischen diesen Welten vermittelt, muss alle Perspektiven verstehen.
Blameless Postmortems sind das Paradebeispiel. Nach jedem größeren Vorfall setzen sich die Beteiligten zusammen und analysieren, was schiefgelaufen ist. Nicht um Schuldige zu finden, sondern um Systeme zu verbessern. Google hat diese Praxis populär gemacht [1], und sie hat sich in der gesamten Branche als Standard etabliert. Ein Postmortem zu moderieren erfordert diplomatisches Geschick: Fakten sammeln, ohne Schuldzuweisungen zuzulassen. Verbesserungen vorschlagen, ohne Teams zu überfordern. Deadlines setzen, ohne unrealistisch zu werden.
Ein konkretes Beispiel aus der DACH-Region: Bosch begann 2019 damit, seine Automotive-Software-Entwicklung auf Automatisierungsprinzipien umzustellen. Das betraf über 30.000 Softwareentwickler weltweit [7]. Die technische Umsetzung war nicht das Hauptproblem. CI/CD-Pipelines lassen sich aufsetzen, Container-Infrastruktur lässt sich beschaffen. Die eigentliche Herausforderung lag in der Kultur. Abteilungen, die seit Jahrzehnten in Silos arbeiteten, sollten plötzlich gemeinsam Verantwortung für Deployments übernehmen. QA-Teams, die bisher am Ende der Kette getestet hatten, sollten Shift-Left praktizieren und Tests in die Pipeline integrieren. Die Infrastrukturspezialisten bei Bosch verbrachten laut internen Berichten in der Anfangsphase mehr Zeit in Workshops und Schulungen als an der Tastatur. Das klingt ineffizient. Aber ohne diese Kulturarbeit hätten die besten Pipelines der Welt nichts genutzt, weil niemand sie genutzt hätte.
Meine Erfahrung: Die besten Leute in dieser Rolle, die ich kennengelernt habe, zeichnen sich nicht durch ihre Terraform-Kenntnisse aus. Terraform kann man lernen. Was sie auszeichnet, ist die Fähigkeit, einem genervten Backend-Entwickler zu erklären, warum sein Deployment fehlgeschlagen ist, ohne herablassend zu wirken. Oder dem CTO in fünf Sätzen klarzumachen, warum die Cloud-Rechnung um zwei Fünftel gestiegen ist und was dagegen hilft.
On-Call und Incident Response: Was bedeutet Rufbereitschaft?
On-Call gehört bei den meisten solchen Positionen zum Vertrag. Typische Modelle in Deutschland: Eine Woche Bereitschaft pro Monat, Reaktionszeit 15 bis 30 Minuten bei Critical Alerts. Vergütung variiert stark. Manche Unternehmen zahlen eine Pauschale von 200 bis 500 Euro pro Bereitschaftswoche, andere rechnen die Stunden einzeln ab. Einige, gerade Startups, erwarten Rufbereitschaft ohne zusätzliche Vergütung.
Aus arbeitsrechtlicher Sicht in Deutschland gilt Rufbereitschaft grundsätzlich als Ruhezeit, solange man nicht aktiv arbeitet. Bereitschaftsdienst am Arbeitsplatz dagegen zählt als volle Arbeitszeit. Seit einem EuGH-Urteil von 2021 (C-518/15) kann Rufbereitschaft allerdings ebenfalls als Arbeitszeit gelten, wenn die Freizeit erheblich eingeschränkt ist, etwa durch sehr kurze Reaktionszeiten oder häufige Einsätze. Wer einen solchen Vertrag unterschreibt, sollte die On-Call-Regelung vorab klären. Das halte ich für einen der am meisten unterschätzten Verhandlungspunkte bei Gehaltsgesprächen.
PagerDuty, OpsGenie und Grafana OnCall sind die verbreitetsten Alerting-Tools. Sie eskalieren Alerts nach definierten Regeln: Erst der primäre On-Call, dann der sekundäre, dann das gesamte Team. Gut konfiguriertes Alerting ist eine Kunst, denn zu viele Alerts führen zu Alert Fatigue, wo kritische Meldungen im Rauschen untergehen. Zu wenige Alerts bedeuten, dass Probleme erst auffallen, wenn Kunden sich beschweren.
Drei Mythen über DevOps Engineers
Mythos 1: DevOps ist nur ein modernerer Name für Systemadministration
Systemadministratoren verwalten Server, installieren Software, konfigurieren Netzwerke. Infrastrukturspezialisten tun das auch, aber sie automatisieren diese Tätigkeiten mit Code. Der Unterschied liegt nicht in den Aufgaben, sondern in der Methode. Ein Sysadmin klickt im AWS-Dashboard einen Load Balancer zusammen. Ein Ops-Spezialist schreibt ein Terraform-Modul, das denselben Load Balancer reproduzierbar und versioniert erstellt. Wenn das Modul einmal steht, braucht der nächste Load Balancer wenige Minuten statt mehrere Stunden.
Der tiefere Unterschied: Systemadministratoren reagieren auf Tickets. Ein Server braucht mehr Speicher, also wird aufgestockt. Diese Fachleute denken proaktiv. Sie bauen Autoscaling-Regeln, die den Speicher automatisch anpassen, bevor ein Ticket entsteht. Laut dem Puppet State of DevOps Report 2016 haben Organisationen mit ausgereiften Automatisierungspraktiken knapp ein Viertel weniger ungeplante Arbeit als solche ohne [10]. Der klassische Sysadmin ist nicht verschwunden. Aber sein Aufgabenfeld hat sich verschoben: weg vom manuellen Eingreifen, hin zur Automatisierung mit Code.
Mythos 2: KI wird DevOps Engineers bald ersetzen
GitHub Copilot generiert brauchbare Terraform-Snippets. K8sGPT analysiert Cluster-Probleme. Das ist nützlich. Aber eine Multi-Region-Failover-Strategie entwerfen, die Compliance-Anforderungen der BaFin erfüllt und gleichzeitig die Cloud-Kosten im Rahmen hält? Dafür braucht man Kontext, Erfahrung und ein Verständnis des Geschäftsmodells, das kein Sprachmodell liefern kann. KI beschleunigt die Routine. Die eigentliche Infrastrukturarbeit ist keine Routine.
Die Zahlen stützen das. Eine Umfrage von Humanitec unter 281 Platform-Engineering-Teams zeigte 2024, dass weniger als ein Sechstel der Befragten KI-Tools intensiv nutzen, obwohl das Thema in der Community allgegenwärtig ist [8]. Zwischen Hype und Praxis klafft eine Lücke. Terraform-Snippets generieren lassen spart zehn Minuten. Aber ob man EKS, GKE oder eine selbst gehostete Lösung wählt, hängt von Compliance, Budget, Teamgröße und einem Dutzend weiterer Faktoren ab, die kein Sprachmodell kennt.
Mythos 3: DevOps bedeutet permanenten Stress und 24/7-Verfügbarkeit
On-Call gehört dazu. Aber gut organisierte Teams rotieren die Bereitschaft, investieren in Automatisierung und reduzieren Alerts systematisch. Der DORA-Report zeigt, dass Elite-Performing-Teams weniger ungeplante Arbeit haben, nicht mehr [3]. Bessere Tooling und Prozesse führen zu weniger nächtlichen Störungen, nicht zu mehr. Der Stresspegel hängt weniger vom Beruf als von der Organisation ab. Unternehmen, die On-Call als Bestrafung behandeln statt als gemeinsame Verantwortung, haben ein Kulturproblem, kein Organisationsproblem.
Konkret: Firmen wie Grafana Labs oder GitLab dokumentieren ihre On-Call-Prozesse öffentlich. Bei GitLab rotiert die Bereitschaft wöchentlich, jeder Incident erzeugt automatisch ein Postmortem-Issue, und wiederholte Nachtalarme für dasselbe Problem werden als Bugs priorisiert, nicht als unvermeidliches Schicksal. Das Ergebnis: weniger Alerts pro Quartal, nicht mehr. Stress entsteht dort, wo niemand Zeit in die Verbesserung des Alerting investiert.
Wie misst man den Erfolg von DevOps?
DORA (DevOps Research and Assessment) hat vier Metriken etabliert, die als Industriestandard gelten: Deployment Frequency, Lead Time for Changes, Change Failure Rate und Time to Restore Service [3]. Elite-Performer deployen mehrmals täglich, bringen Änderungen innerhalb eines Tages in Produktion, haben eine Change Failure Rate unter fünf Prozent und stellen Services innerhalb einer Stunde wieder her.
Diese Metriken sind keine akademische Übung. Unternehmen wie Spotify, ING und die Otto Group nutzen sie als KPIs für ihre Engineering-Teams. Für Ops-Spezialisten bedeutet das: Der eigene Erfolg lässt sich messen. Wer eine Pipeline optimiert, die die Lead Time von zwei Wochen auf vier Stunden senkt, kann das beziffern. Das ist ein Vorteil gegenüber vielen anderen IT-Berufen, wo der Beitrag schwerer quantifizierbar ist.
Gleichzeitig warnt der DORA-Report davor, die Metriken als alleinige Erfolgsmaßstäbe zu verwenden. Teams, die ihre Deployment Frequency künstlich erhöhen, ohne die Codequalität zu berücksichtigen, verschlechtern ihre Change Failure Rate. Die vier Metriken gehören zusammen. Eine einzelne zu optimieren, während die anderen sinken, ist Kosmetik.
In der Praxis sieht das so aus: Die ING Bank in den Niederlanden strukturierte ihre IT ab 2015 in 350 autonome Squads um, organisiert in 13 Tribes nach dem Spotify-Modell. Die Releases stiegen von fünf bis sechs pro Jahr auf Zyklen von wenigen Wochen, die Zahl der Incidents pro Release sank deutlich [3]. McKinsey dokumentierte diese Transformation als Referenzbeispiel. Was dabei auffiel: Der größte Hebel war nicht die Technologie, sondern die organisatorische Veränderung. Metriken allein ändern nichts. Aber sie machen sichtbar, wo es hakt, und das ist der erste Schritt zur Verbesserung.
Remote, hybrid oder Büro: Wie arbeiten DevOps Engineers?
Der Beruf ist einer der am besten für Remote-Arbeit geeigneten IT-Berufe. Die gesamte Infrastruktur lebt in der Cloud, Terminals funktionieren von überall, Incident Response läuft über Slack und PagerDuty. Laut Stack Overflow Developer Survey 2024 arbeiten mehr als ein Drittel aller Entwickler vollständig remote, knapp die Hälfte hybrid [5]. Bei Infrastrukturrollen dürfte der Remote-Anteil noch höher liegen, weil die Arbeit weniger Präsenz erfordert als etwa UX-Design oder Pair Programming.
In der DACH-Region hat sich hybrides Arbeiten mit wenigen Präsenztagen pro Woche als Standard durchgesetzt. SAP verlangt nach einer Einigung mit dem Betriebsrat Präsenztage, Siemens setzt auf flexible Tage, Zalando erlaubt bis zu zwei Drittel Remote-Arbeit [6]. Startups bieten häufiger vollständige Remote-Optionen, zahlen dafür aber oft moderatere Gehälter. Die Entscheidung zwischen Remote und höherem Gehalt vor Ort ist individuell. Mein Eindruck: Wer On-Call-Bereitschaft leistet, profitiert von der Flexibilität, die Remote-Arbeit bietet, weil nächtliche Einsätze von zu Hause aus einfacher zu handhaben sind als mit einer Stunde Pendelweg.
Auf die Teamdynamik wirkt sich das Arbeitsmodell stärker aus, als viele Führungskräfte zugeben. Pair-Debugging funktioniert remote über Screen-Sharing oft erstaunlich gut. Spontane Gespräche am Whiteboard dagegen fehlen. Einige Teams lösen das mit festen „Collaboration Days“, an denen alle im Büro sind und gemeinsam an komplexen Problemen arbeiten. Die Otto Group in Hamburg setzt auf „Activity Based Working“: Jedes Team entscheidet selbst, wann und wo es arbeitet. In sogenannten Collaboration Sprints definieren die Organisationseinheiten ihre eigenen Richtlinien. Feste Präsenztage gibt es bewusst nicht.
Für verteilte Infrastrukturteams ist gute Dokumentation kein Nice-to-have, sondern Voraussetzung. Runbooks, Architekturdiagramme und Entscheidungsprotokolle müssen aktuell sein, weil mitten in der Nacht niemand einen Kollegen anrufen will, um zu fragen, wie der Failover-Prozess funktioniert. GitLab selbst praktiziert „Docs as Code“ konsequent und dokumentiert den Ansatz öffentlich im eigenen Handbook: Die technische Dokumentation liegt im selben Repository wie der Code und wird im selben Merge-Request-Prozess geprüft. Das kostet anfangs mehr Zeit. Langfristig spart es Stunden pro Woche, die sonst für Rückfragen verloren gehen.
Fazit
Der Beruf liegt an der Schnittstelle von Entwicklung, Betrieb und Kommunikation. Wer nur die Tool-Liste sieht, versteht den Beruf zur Hälfte. Die andere Hälfte besteht aus Abstimmung, Priorisierung und der Fähigkeit, unter Druck klare Entscheidungen zu treffen.
Die Abgrenzung zu SRE und Platform Engineering ist fließend und hängt stark vom Unternehmen ab. Wer sich für den Beruf entscheidet, sollte weniger auf den Titel achten und mehr auf die konkreten Aufgaben in der Stellenanzeige. On-Call, Infrastrukturautomatisierung, CI/CD-Pipelines, Monitoring: Das ist der Kern, unabhängig vom Label.
Teil 2 dieser Serie sortiert die Technologielandschaft: Welche Tools und Plattformen sind 2026 tatsächlich gefragt, welche kann man getrost ignorieren und in welcher Reihenfolge lohnt sich das Lernen?
Quellen
[1] Betsy Beyer et al.: Site Reliability Engineering, O'Reilly Media 2016 (https://sre.google/sre-book/table-of-contents/)
[2] Gartner: Top Strategic Technology Trends 2026, Platform Engineering (https://www.gartner.com/)
[3] DORA: State of DevOps Report 2024 (https://dora.dev/research/2024/)
[4] IDC: How Do Software Developers Really Spend Their Time?, Februar 2025 (https://www.idc.com/)
[5] Stack Overflow Developer Survey 2024 (https://survey.stackoverflow.co/2024/)
[6] Handelsblatt: Homeoffice-Regelungen DAX-Konzerne, September 2025 (https://www.handelsblatt.com/)
[7] Bosch Engineering Blog: Scaling DevOps in Automotive Software Development, Oktober 2023 (https://www.bosch.com/stories/software-defined-vehicle/)
[8] Humanitec: State of Platform Engineering Report 2024, 281 Teams befragt (https://humanitec.com/whitepapers/state-of-platform-engineering-vol-3)
[9] The Incredible True Story of How DevOps Got Its Name, New Relic Blog (https://newrelic.com/blog/nerd-life/devops-name)
[10] Puppet: State of DevOps Report 2016 (https://www.puppet.com/resources/state-of-devops-report)