Der Begriff DevOps ist noch keine zwanzig Jahre alt. Patrick Debois, ein belgischer IT-Berater, prägte ihn 2009, als er die erste DevOpsDays-Konferenz in Gent organisierte. Ausgelöst hatte das ein Vortrag von John Allspaw und Paul Hammond auf der Velocity-Konferenz im selben Jahr mit dem Titel "10+ Deploys a Day: Dev and Ops Cooperation at Flickr". Debois hatte den Vortrag per Video verfolgt und lud daraufhin Systemadministratoren und Entwickler zu einem gemeinsamen Treffen ein, um genau die Zusammenarbeit zu diskutieren, die bei Flickr schon funktionierte.
Vor diesem Zusammenschluss arbeiteten Entwicklungsteams und Betriebsteams in vielen Unternehmen getrennt voneinander und mit gegensätzlichen Zielen. Die Entwicklung sollte neue Funktionen so schnell wie möglich veröffentlichen, der Betrieb sollte die Systeme stabil halten und scheute deshalb jede Veränderung. Die Folge: verzögerte Veröffentlichungen, und bei einem Ausfall schob jede Seite der anderen die Schuld zu.
Was DevOps als Arbeitsweise bedeutet
DevOps bezeichnet keine einzelne Software, sondern eine Arbeitsweise, die Entwicklung (englisch Development) und Betrieb (englisch Operations) zusammenbringt, daher der Name. Statt getrennter Abteilungen mit getrennter Verantwortung übernimmt ein Team beides: Es schreibt den Code, testet ihn, bringt ihn auf die Produktivsysteme und kümmert sich danach auch um dessen Betrieb. Automatisierung ersetzt dabei viele manuelle Übergaben zwischen Abteilungen, etwa das Ausfüllen eines Tickets, mit dem eine Entwicklerin früher den Betrieb um eine neue Serverkonfiguration bat.
Kontinuierliche Integration und Bereitstellung als Kernpraktiken
Zwei Praktiken tragen DevOps im Arbeitsalltag. Continuous Integration, kurz CI, bedeutet, dass Entwicklerinnen und Entwickler ihren Code mehrmals täglich in ein gemeinsames Repository einspielen, wo automatisierte Tests ihn sofort prüfen. Continuous Delivery beziehungsweise Continuous Deployment, kurz CD, führt diesen Gedanken weiter: Eine Änderung, die die Tests besteht, steht automatisch bereit für die Veröffentlichung oder geht bei Continuous Deployment sogar ohne weiteren manuellen Schritt live. Infrastructure as Code ergänzt beides: Serverkonfigurationen liegen dabei als Textdateien im selben Versionskontrollsystem wie der Anwendungscode, meist mit Werkzeugen wie Ansible, Chef, Puppet oder Terraform, sodass sich eine komplette Serverumgebung reproduzierbar aus einer Datei aufbauen lässt statt von Hand.
Container und Überwachung im laufenden Betrieb
Docker verpackt eine Anwendung seit 2013 zusammen mit allen Abhängigkeiten in einen Container, der auf jedem System gleich läuft, ob auf dem Laptop einer Entwicklerin oder auf einem Server in einem Rechenzentrum. Kubernetes, ursprünglich bei Google entwickelt und seit 2014 quelloffen, verteilt und überwacht solche Container über mehrere Maschinen hinweg und startet einen abgestürzten Container automatisch neu. Für die laufende Überwachung protokollieren Werkzeuge wie Prometheus und Grafana Kennzahlen wie Antwortzeiten und Fehlerraten, während der ELK-Stack, benannt nach seinen drei Bestandteilen Elasticsearch, Logstash und Kibana, Logdateien durchsuchbar macht. Ohne diese Überwachung bemerkt ein Team einen Fehler oft erst, wenn sich Kundinnen und Kunden beschweren.
Was der jährliche DevOps-Report über die Praxis zeigt
Die Forschungsgruppe DORA, kurz für DevOps Research and Assessment und inzwischen Teil von Google Cloud, veröffentlicht seit 2014 einen jährlichen Bericht zum Stand von DevOps in der Praxis, gestützt auf Befragungen tausender IT-Fachleute. Über mehrere Jahre zeigte sich ein stabiles Muster: Teams mit der höchsten Leistungsfähigkeit veröffentlichen mehrmals täglich, brauchen von einer Codeänderung bis zur Veröffentlichung weniger als eine Stunde und beheben einen Ausfall im Schnitt ebenfalls innerhalb einer Stunde. Der Bericht von 2025 ersetzte diese vier Leistungsstufen durch sieben feinere Profile, das Grundmuster blieb aber bestehen. Eine Erkenntnis aus demselben Bericht überrascht: Teams, die verstärkt KI-Werkzeuge in der Entwicklung einsetzen, verbessern zwar die Effektivität einzelner Personen, gleichzeitig steigt bei ihnen aber die Instabilität der Softwarebereitstellung. Der Bericht wertet das als Hinweis darauf, dass KI-Werkzeuge bestehende Stärken und Schwächen eines Teams verstärken, statt sie automatisch zu beheben.
Wer die Umstellung auf DevOps bezahlt und wer davon profitiert
Die Umstellung auf DevOps kostet zunächst Zeit: Teams müssen Pipelines aufbauen, Testautomatisierung nachrüsten und oft auch ihre Organisationsstruktur verändern, weil Verantwortung neu verteilt wird. Bezahlt wird das aus dem Budget, das sonst in manuelle Freigabeprozesse und in die Behebung von Ausfällen nach der Veröffentlichung geflossen wäre. Profitieren tun in erster Linie die Kundinnen und Kunden, die neue Funktionen schneller erhalten und weniger Ausfälle bemerken, und die Entwicklerinnen und Entwickler selbst, weil weniger nächtliche Noteinsätze wegen fehlgeschlagener Großveröffentlichungen anfallen. Unternehmen, die stattdessen an seltenen, großen Releases festhalten, tragen das umgekehrte Risiko: Je mehr Änderungen in einer einzigen Veröffentlichung stecken, desto schwerer lässt sich im Fehlerfall die eine Ursache darin finden.
Wer mit DevOps beginnt, muss nicht sofort Kubernetes und eine vollständige CI/CD-Pipeline aufbauen. Ein guter erster Schritt ist meist, überhaupt automatisierte Tests einzuführen und den Code mehrmals pro Woche statt einmal im Quartal zu veröffentlichen. Der Rest der Praktiken lässt sich darauf aufbauen.
Häufig gestellte Fragen
Was unterscheidet DevOps von einer klassischen IT-Abteilung mit getrennten Teams?
In einer klassischen Struktur arbeiten Entwicklung und Betrieb in getrennten Abteilungen mit gegensätzlichen Zielen. Die Entwicklung will neue Funktionen schnell veröffentlichen, der Betrieb will die Systeme stabil halten und scheut deshalb Veränderungen. Bei DevOps übernimmt ein gemeinsames Team beide Aufgaben, schreibt den Code, bringt ihn auf die Produktivsysteme und betreibt ihn danach selbst. Automatisierung ersetzt dabei viele der früheren manuellen Übergaben zwischen den Abteilungen.
Wie viel kostet die Umstellung auf DevOps ein Unternehmen?
Die Umstellung kostet zunächst Zeit, weil Teams Pipelines aufbauen, Testautomatisierung nachrüsten und oft die Organisationsstruktur verändern müssen, da Verantwortung neu verteilt wird. Bezahlt wird das aus dem Budget, das sonst in manuelle Freigabeprozesse und in die Behebung von Ausfällen nach der Veröffentlichung geflossen wäre. Profitieren tun vor allem Kunden, die neue Funktionen schneller erhalten, und Entwicklerinnen und Entwickler, weil weniger nächtliche Noteinsätze wegen fehlgeschlagener Großveröffentlichungen anfallen.
Muss ein Unternehmen sofort Kubernetes und eine vollständige CI/CD-Pipeline einführen?
Nein, ein guter erster Schritt ist meist, überhaupt automatisierte Tests einzuführen und den Code mehrmals pro Woche statt einmal im Quartal zu veröffentlichen. Container-Werkzeuge wie Docker und Kubernetes sowie eine vollständige Infrastructure-as-Code-Pipeline lassen sich darauf aufbauen, sobald diese Grundlage steht.
Was zeigt der DORA-Bericht zum Einsatz von KI-Werkzeugen in der Softwareentwicklung?
Der Bericht der Forschungsgruppe DORA zeigt, dass Teams, die verstärkt KI-Werkzeuge einsetzen, zwar die Effektivität einzelner Personen verbessern, gleichzeitig aber die Instabilität ihrer Softwarebereitstellung steigt. DORA wertet das als Hinweis darauf, dass KI-Werkzeuge bestehende Stärken und Schwächen eines Teams verstärken, statt sie automatisch zu beheben.