Ein Titel ohne Berufsbild

Was hinter dem Titel DevOps tatsächlich steckt

Zwei Anzeigen mit demselben Titel können völlig verschiedene Arbeit meinen, deshalb lohnt der Blick auf die Werkzeuge und auf die Frage, wer nachts erreichbar sein muss.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Kleine Gruppen Präsenz und Live-Online Zertifizierte Trainer
Worum es geht

Derselbe Titel bezeichnet zwei sehr verschiedene Stellen

Die eine Variante ist Betrieb mit Automatisierung: Du baust Pipelines, beschreibst Infrastruktur als Code, betreibst Cluster und sorgst dafür, dass eine Auslieferung ohne Handarbeit funktioniert. Die andere ist Entwicklung mit Betriebsverantwortung: Du schreibst die Anwendung und stehst dafür gerade, dass sie läuft. Beide werden mit demselben Wort ausgeschrieben, und wer im Gespräch nicht nachfragt, unterschreibt bei der falschen.

Für den Einstieg hat das Folgen. Wer sich auf die Werkzeuge stürzt, die in den Anzeigen stehen, lernt Kubernetes, bevor er weiß, wie ein Dienst auf einem Linux-System startet, und steht beim ersten Zertifikats- oder Namensauflösungsproblem still. Die Fehler, die in verteilten Umgebungen tatsächlich auftreten, sind selten Fehler der Orchestrierung.

Der zweite teure Punkt ist die Erreichbarkeit. In vielen dieser Stellen gehört Rufbereitschaft dazu, und sie steht selten in der Anzeige. Wer erst nach der Unterschrift danach fragt, verhandelt aus der schwächeren Position, und zwar über etwas, das den Alltag stärker prägt als jedes Werkzeug.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet was

Wer entscheidet was, wenn Entwicklung und Betrieb zusammenrücken

Der Reiz dieser Arbeitsweise liegt darin, dass Zuständigkeiten näher zusammenliegen. Genau deshalb müssen sie ausgesprochen sein, sonst landen sie stillschweigend bei der Person, die am schnellsten helfen kann.

Was in Produktion geht

Wer entscheidet
Die Stelle mit der Ergebnisverantwortung für den Dienst, auf Basis der Prüfergebnisse aus der Pipeline
Wer setzt um
Die Pipeline selbst, nicht eine Person mit persönlichem Zugriff
Stolperfalle
Es gibt einen Weg an der Pipeline vorbei, und im Notfall wird er benutzt, danach unterscheidet sich der Stand vom beschriebenen.

Rufbereitschaft und Störungen außerhalb der Arbeitszeit

Wer entscheidet
Betrieb und Leitung, verbindlich geregelt und vergütet
Wer setzt um
Ein Bereitschaftsplan mit benannten Vertretungen und Eskalationsstufen
Stolperfalle
Die Zuständigkeit wandert still zu der Person, die es am schnellsten beheben kann, und steht in keinem Plan.

Zugangsdaten und Berechtigungen

Wer entscheidet
Die Informationssicherheit, die den Rahmen und die Ablage vorgibt
Wer setzt um
Das Team über einen Geheimnisspeicher und kurzlebige Zugänge
Stolperfalle
Die Zugangsdaten stehen als Variable in der Pipeline-Konfiguration im Repository, weil es beim ersten Mal schneller ging.

Auswahl der Werkzeuge

Wer entscheidet
Das Team gemeinsam, mit Blick auf Betreibbarkeit und Vertretung
Wer setzt um
Die Leute, die den Betrieb danach übernehmen, nicht die, die es eingeführt haben
Stolperfalle
Jedes Team wählt anders, und im Urlaubsfall kann niemand einspringen, weil nichts davon vergleichbar aufgebaut ist.

Kosten der Umgebungen

Wer entscheidet
Wer das Budget trägt, auf Basis einer nachvollziehbaren Zuordnung
Wer setzt um
Die Automatisierung, die Testumgebungen nach Ablauf wieder abräumt
Stolperfalle
Die Umgebung für einen einmaligen Lasttest läuft seit vier Monaten weiter, und niemand traut sich, sie abzuschalten.

Sechs Stufen, in denen der Werkzeugkasten wächst

  1. 01 Linux und Shell tragen alles, was darüber gebaut wird.
  2. 02 Versionsverwaltung mit Git ordnet die Zusammenarbeit.
  3. 03 Eine Pipeline baut und testet ohne Handarbeit.
  4. 04 Container packen die Anwendung mit ihren Abhängigkeiten.
  5. 05 Automatisierung beschreibt Server und Infrastruktur als Code.
  6. 06 Überwachung zeigt, ob eine Änderung etwas verbessert hat.
Was du mitnimmst

Was du mitnimmst

Du bekommst eine Reihenfolge für den Aufbau des Werkzeugkastens, die den Unterbau nicht überspringt, und die Fragen, mit denen du eine Stelle vor der Zusage einordnest.

Den Unterbau zuerst

Du beherrschst Prozesse, Rechte, Netz und Namensauflösung unter Linux, bevor du Cluster betreibst, weil dort die meisten Fehler entstehen.

Wiederholbar statt einmalig

Du schreibst Automatisierung so, dass sie mehrfach laufen kann, ohne beim zweiten Durchlauf etwas kaputtzumachen.

Zugangsdaten aus dem Repository halten

Du legst Geheimnisse in einen dafür vorgesehenen Speicher und reichst sie zur Laufzeit ein, statt sie in Konfigurationsdateien zu pflegen.

Zustand gemeinsam verwalten

Du legst den Zustand deiner Infrastrukturbeschreibung zentral ab und sperrst ihn, damit zwei gleichzeitige Läufe sich nicht überschreiben.

Wirkung messen

Du beurteilst Änderungen an der Auslieferung anhand weniger Kennzahlen statt am Gefühl, dass es schneller geworden ist.

Betreibbarkeit vor Werkzeugvielfalt

Du wählst Werkzeuge danach aus, ob eine andere Person sie im Notfall bedienen kann, und nicht danach, was neu ist.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Was Arbeitgeber unter dem Titel tatsächlich suchen

Der Alltag hat mit dem Bild aus der Fachliteratur wenig zu tun. Ein großer Teil der Zeit geht in die Pflege dessen, was schon läuft: Abhängigkeiten aktualisieren, Zertifikate erneuern, Cluster auf eine neue Version heben, Pipelines reparieren, die durch eine Änderung von außen gebrochen sind. Dazwischen liegen die Anfragen der Entwicklungsteams, die eine Umgebung, einen Zugang oder eine Auswertung brauchen.

Die häufigste falsche Erwartung betrifft das Programmieren. Geschrieben wird viel, aber selten Anwendungslogik: Skripte, Konfiguration, Vorlagen, kleine Werkzeuge. Wer die Rolle wählt, weil er eigentlich Software entwickeln will, landet an der falschen Stelle, und umgekehrt gilt dasselbe für jemanden, der am liebsten Systeme betreut und plötzlich Programmierstandards einhalten soll.

Der Widerspruch im Begriff bleibt bestehen. DevOps war als Arbeitsweise gemeint, die Trennung zwischen Entwicklung und Betrieb aufzulösen. Eine eigene Abteilung mit diesem Namen führt die Trennung an anderer Stelle wieder ein. In der Praxis funktioniert es dort am besten, wo die Leute mit diesem Titel die Werkzeuge und Leitplanken bereitstellen, mit denen die Entwicklungsteams ihre Anwendungen selbst ausliefern.

Der Werkzeugkasten in der Reihenfolge, in der er sich aufbaut

Unten liegt Linux. Wer versteht, wie ein Dienst gestartet wird, wo Protokolle landen, wie Rechte greifen und wie Namensauflösung funktioniert, findet Fehler auch in Umgebungen, die er noch nie gesehen hat. Darauf folgt Git, und zwar mehr als die drei täglichen Befehle: Wer Verzweigungen, Zusammenführungen und das Zurücknehmen von Änderungen sicher beherrscht, ist im Team die Person, die man bei einem verkorksten Verlauf holt.

Danach kommt die Pipeline, also der automatisierte Weg von der Änderung bis zum lauffähigen Ergebnis, gefolgt von Containern, von Konfigurationsverwaltung wie Ansible und von Orchestrierung mit Kubernetes. Zuletzt die Beschreibung der Infrastruktur selbst, etwa mit Terraform oder OpenTofu, und die Überwachung mit Prometheus und Grafana. Diese Reihenfolge ist keine Geschmacksfrage: Jede Stufe erklärt die Fehler der darüberliegenden, und wer eine überspringt, sucht später an der falschen Stelle.

Zwei Fehler wiederholen sich in fast jeder Umgebung. Der erste sind Zugangsdaten, die in der Pipeline-Konfiguration im Repository stehen, weil es beim ersten Mal schneller ging und danach niemand mehr hingesehen hat. Der zweite ist der gemeinsame Zustand der Infrastrukturbeschreibung: Wenn zwei Leute gleichzeitig anwenden und dieser Zustand nicht zentral liegt und gesperrt wird, entsteht ein Schaden, der sich nur von Hand beheben lässt.

Warum es für diese Rolle keine eigene amtliche Zahl gibt

In der Klassifikation der Berufe gibt es keine Gattung für DevOps, und das ist kein Versäumnis, sondern die Folge davon, dass die Tätigkeit quer zu zwei bestehenden Berufen liegt. Die beiden Zellen unten zeigen die Nachbarn: IT-Systemadministration und Softwareentwicklung, beide auf dem Anforderungsniveau Spezialist. Sie rahmen die Rolle ein, sie sind aber ausdrücklich kein DevOps-Gehalt.

Weil beide auf demselben Niveau stehen, ist der Abstand zwischen ihnen kein Stufeneffekt, sondern ein Unterschied zwischen zwei Berufsgruppen. In welcher Zelle eine konkrete Stelle landet, entscheidet sich bei der Meldung durch den Arbeitgeber, und genau darin spiegelt sich die Uneindeutigkeit des Titels: Dieselbe Arbeit kann in beiden Zeilen auftauchen.

Für die Einordnung gilt hier dasselbe wie überall in dieser Erhebung. Das Anforderungsniveau bezeichnet den Zuschnitt der Stelle und nicht die Erfahrung der Person. Es sind Bruttomonatsverdienste in Vollzeit ohne Sonderzahlungen, der Jahresverdienst liegt also über dem Zwölffachen, sobald es Weihnachts- oder Urlaubsgeld gibt. Und der Median trägt weiter als der Durchschnitt, weil einzelne Spitzenverdienste den Durchschnitt anheben, ohne für die Mehrheit etwas zu bedeuten.

Der Weg hinein und welche Nachweise etwas bringen

Der häufigste Weg führt aus der Administration, der zweithäufigste aus der Entwicklung. Aus der Administration fehlt meistens die Erfahrung mit Versionsverwaltung, Tests und der Frage, wie eine Anwendung überhaupt gebaut wird. Aus der Entwicklung fehlt das Betriebsdenken: Was passiert im Fehlerfall, wer bekommt die Meldung, wie sieht die Rücknahme aus, und was kostet der Betrieb dieser Lösung im Monat.

Zertifikate bringen an zwei Stellen etwas: in der Bewerbung, weil sie ein Feld belegen, in dem sich sonst schwer nachweisen lässt, was jemand kann, und beim Lernen, weil sie einen Aufbau vorgeben. Verbreitet sind die Linux-Zertifizierungen und die Prüfungen rund um Kubernetes. Was in Gesprächen mehr zählt, ist etwas anderes: eine Umgebung, die du selbst aufgebaut hast, samt der Erklärung, was du beim zweiten Mal anders machen würdest.

Ein eigenes kleines System, das automatisiert gebaut, ausgeliefert und überwacht wird, ersetzt kein Projekt im Unternehmen. Es ist aber der einzige Weg, die Zusammenhänge ohne Arbeitgeber zu üben, und es beantwortet im Gespräch mehr Fragen als jede Aufzählung von Werkzeugnamen.

Woran du wächst und wohin die Rolle führt

Zwei Leute mit gleicher Berufsdauer unterscheiden sich daran, ob sie etwas wieder abschalten können. Automatisierung wächst schnell und stirbt langsam. Wer Umgebungen, Skripte und Sonderfälle nur hinzufügt, baut ein System, das am Ende niemand mehr versteht, auch er selbst nicht. Der zweite Unterschied ist die Lesbarkeit für andere: Eine Automatisierung, die nur ihr Autor bedienen kann, ist um drei Uhr nachts wertlos.

Der dritte Unterschied ist die Bereitschaft, Wirkung zu messen statt sie zu behaupten. DORA veröffentlicht dafür eine kleine Kennzahlensammlung, aus den ursprünglich vier Kennzahlen sind inzwischen fünf geworden: die Vorlaufzeit einer Änderung, die Häufigkeit der Auslieferungen, die Zeit bis zur Erholung nach einer fehlgeschlagenen Auslieferung, der Anteil fehlerhafter Änderungen und der Anteil der Auslieferungen, die nachgearbeitet werden müssen. Wer diese Größen kennt, kann eine Verbesserung belegen, statt sie zu behaupten.

Weiter geht es Richtung Plattformentwicklung, wo du interne Werkzeuge für Entwicklungsteams baust, Richtung Verlässlichkeit und Messung im Betrieb, Richtung Cloud-Architektur oder Richtung Sicherheit, wo Lieferkette, Signaturen und Berechtigungen im Mittelpunkt stehen. Allen vier Wegen ist gemeinsam, dass sie den Werkzeugkasten voraussetzen und darauf etwas aufbauen, das länger hält als eine einzelne Technologie.

Dazu passende Kurse

Die Stufen von der Pipeline bis zur Orchestrierung decken Kurse zu Pipelines, Containern und Automatisierung ab.

Weil der Unterbau alles trägt, was darüber liegt, beginnt der Weg bei die Linux-Kurse mit Zertifizierungsweg .

Was verdient man

Die amtlichen Zahlen zu dieser Rolle

Für DevOps gibt es keine eigene amtliche Berufsgattung, weil die Tätigkeit quer zu zwei bestehenden Berufen liegt. Die beiden Zellen zeigen die Nachbarn IT-Systemadministration und Softwareentwicklung und rahmen die Rolle ein, sie sind aber ausdrücklich kein DevOps-Gehalt. Beide stehen auf demselben Anforderungsniveau, der Abstand zwischen ihnen ist also kein Stufeneffekt, sondern ein Unterschied zwischen zwei Berufsgruppen, und in welcher Zelle eine Stelle landet, hängt davon ab, wie der Arbeitgeber sie meldet. Anforderungsniveau meint dabei den Zuschnitt der Stelle und nicht die Berufserfahrung der Person.

Amtliche Medianverdienste, April 2025

Brutto im Monat

Statistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.

IT-Systemadministration Spezialist 5.179 €

KldB 43343, Durchschnitt 5.495 €, gerundet rund 62.000 € im Jahr ohne Sonderzahlungen

Softwareentwicklung Spezialist 5.986 €

KldB 43413, Durchschnitt 6.238 €, gerundet rund 72.000 € im Jahr ohne Sonderzahlungen

02k4k6k
  • Vollzeitbeschäftigte, Bruttomonatsverdienst ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld, Prämien und Boni sind nicht enthalten, der Jahresverdienst liegt also über dem Zwölffachen.
  • Das Anforderungsniveau beschreibt den Zuschnitt der Stelle, nicht die Berufserfahrung. Fachkraft, Spezialist und Experte sagen etwas über die Komplexität der Tätigkeit aus, nicht über Dienstjahre.
  • Die Erhebung geht regional nur bis auf die Bundeslandebene. Für einzelne Städte gibt es keine amtlichen Zahlen, weil der Zufallsfehler zu groß wäre.

Quelle: Statistischer Bericht Verdienste , Statistisches Bundesamt (Destatis). Den eigenen Fall prüfst du im Entgeltatlas der Bundesagentur für Arbeit . Beachte dort: Entgelte oberhalb der Beitragsbemessungsgrenze sind der Statistik nicht bekannt, bei gut bezahlten IT-Rollen steht deshalb nur eine Untergrenze.

Wissen prüfen

Wie sicher bist du beim Thema wirklich?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
LimeSurvey - Anwendertraining Teil 1 (Grundlagen)
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
BricsCAD 2D Schulung Grundkurs
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
BricsCAD 3D Schulung - Grundlagen

Häufige Fragen

Ist DevOps ein Ausbildungsberuf?
Nein, und eine eigene amtliche Berufsgattung gibt es ebenfalls nicht. Der übliche Weg führt über eine Ausbildung oder ein Studium in Systemintegration oder Anwendungsentwicklung und danach über Erfahrung im Betrieb oder in der Entwicklung. Der Titel beschreibt eine Arbeitsweise, die sich mehrere Berufe teilen.
Muss ich programmieren können?
Ja, aber anders als in der Anwendungsentwicklung. Gebraucht werden Skripte, Konfiguration und kleine Werkzeuge, dazu die Fähigkeit, fremden Code zu lesen. Wer eine Sprache sicher beherrscht und Versionsverwaltung, Tests und Fehlersuche kennt, kommt weit, ohne Anwendungslogik zu schreiben.
Womit fange ich an, Kubernetes oder Linux?
Mit Linux, und das ist keine Geschmacksfrage. In einem Cluster laufen Dienste, Rechte, Netz und Namensauflösung genauso wie darunter, nur schwerer sichtbar. Wer die Grundlagen überspringt, kann eine Anwendung ausrollen, aber keinen Fehler eingrenzen, sobald etwas nicht wie erwartet startet.
Gehört Rufbereitschaft dazu?
Häufig ja, und die Ausgestaltung unterscheidet sich stark: Wie oft, mit welcher Reaktionszeit, mit welcher Vergütung und mit welcher Vertretung. Das gehört ins Gespräch vor der Zusage, weil es den Alltag stärker prägt als die eingesetzten Werkzeuge.

Passt thematisch dazu

In Häusern mit geregeltem Änderungsverfahren stellt sich schnell die Frage, wie sich Servicebetrieb und DevOps vertragen .

Welches der beiden Werkzeuge Infrastruktur erzeugt und welches sie anschließend konfiguriert, klärt der Vergleich von Terraform und Ansible entlang der Aufgaben .

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.