Day in the Life of a DevOps Engineer

Du sitzt vor dem Laptop, überlegst, ob DevOps wirklich zu dir passt, und findest online nur Hochglanztexte über Automatisierung und Kultur. Was du wissen willst, ist ein ehrlicher Arbeitstag mit allem, was dazugehört: Termine, stille Konzentration, Frust und die Momente, in denen es einfach läuft.

Ich beschreibe hier den typischen Tag eines DevOps Engineers auf mittlerer Ebene, mit zwei bis vier Jahren Erfahrung, in einem Team von fünf bis zehn Leuten. Keine Startup-Euphorie, kein Rekrutierungsgesang. So sieht es in vielen Unternehmen tatsächlich aus.

Der Morgen beginnt selten mit Code#

Wecker, Kaffee, Rechner. Die erste halbe Stunde verbringst du fast immer mit dem, was seit gestern Abend passiert ist. Alerts, Pipeline-Fehler, offene Pull Requests, vielleicht eine Nachricht aus einem anderen Zeitraum.

Viele Teams machen um 9:15 ein kurzes Stand-up. Fünfzehn Minuten, drei Sätze pro Person. Danach hast du oft direkt noch ein Sync mit einem Entwickler-Team, das eine neue Deployment-Strategie besprechen will. Bis 10:30 ist der Vormittag damit schon halb weg.

Der Klassiker: Du wolltest eigentlich eine Terraform-Modul-Refactorierung fertig machen und stattdessen löst du ein Zertifikatsproblem, das sonst niemand anfassen will.

Meetings gegen Deep Work: die ehrliche Aufteilung#

In vielen Firmen ist die Aufteilung ungefähr so: 25 bis 40 Prozent Meetings und Abstimmung, der Rest ist konzentrierte Arbeit. Das ist kein Naturgesetz. Teams mit viel On-Call und vielen Stakeholdern kommen auf über 50 Prozent Meetings. Gute Organisation hält es bei 20 Prozent.

Was wirklich hilft: Ein Block am Vormittag oder Nachmittag, der als "Focus Time" im Kalender steht und den niemand ohne Rücksprache bucht. Ohne diesen Block arbeitest du den ganzen Tag in Fragmenten und kommst abends nicht dazu, etwas fertig zu machen.

Ein konkretes Beispiel aus meinem Umfeld: Ein Kollege blockierte dienstags und donnerstags von 13:00 bis 16:00. In diesen drei Stunden baute er die Observability-Pipeline, die vorher monatelang liegen geblieben war. Der Unterschied war nicht Talent, sondern dass niemand ihn störte.

Die Tools, die tatsächlich täglich laufen#

Die Liste aus Stellenanzeigen ist lang. Im Alltag benutzt du davon einen Kern relativ intensiv und den Rest gelegentlich.

Meist täglich: Git, eine CI/CD-Lösung wie GitLab CI oder GitHub Actions, Terraform oder ein vergleichbares Infrastructure-as-Code-Tool, Kubernetes, Docker, ein Cloud-Provider (AWS, Azure oder GCP), Prometheus und Grafana für Metriken, ein Logging-Stack wie Loki oder ELK, dazu Slack und das Ticketsystem.

Was Neueinsteiger überrascht: Der Löwenanteil der Zeit geht in Text. YAML-Dateien, Bash-Skripte, Python, Dokumentation, Kommentare in Pull Requests. Du schreibst weniger glamouröse Software und mehr Dinge, die dafür sorgen, dass andere Leute ihre Software überhaupt ausliefern können.

Wenn du wissen willst, welche Tools in echten Stellenanzeigen vorkommen, hilft ein Blick in aktuelle DevOps-Stellenangebote. Dort siehst du, was Firmen wirklich suchen, nicht was ein Blog-Artikel für modern hält.

Ein typischer Arbeitstag im Detail#

08:45 Ankommen, Alerts checken, Slack sichten. Ein Nightly-Build ist fehlgeschlagen, Ursache: Ein abgelaufenes Secret in der Staging-Umgebung.

09:15 Stand-up. Du berichtest, dass das Secret-Problem an dir hängt, und dass du heute das Deployment für Service X vorbereiten willst.

09:30 Secret rotiert, Pipeline neu angestoßen, läuft. Kurzer Kommentar im zugehörigen Ticket, damit der Kontext nicht verloren geht.

10:00 Review von zwei Pull Requests. Einer ist sauber, einer ändert heimlich das Memory-Limit im Deployment. Du blockierst ihn mit einer konkreten Frage.

11:00 Sync mit dem Backend-Team. Sie wollen Canary-Deployments. Du erklärst, was dafür nötig ist, und notierst drei offene Punkte.

12:00 Mittagessen. Ehrlich gesagt oft am Schreibtisch, wenn ein Rollout läuft.

13:00 Focus Time. Du baust das Terraform-Modul für die neue Datenbank-Instanz weiter, testest es in einer Sandbox, committest.

15:30 Ein Entwickler meldet sich: Sein Pod startet nicht. Du schaust dir die Events an, findest einen falsch gesetzten Taint, löst es in zehn Minuten. Davor liegen aber dreißig Minuten, in denen du zwischen zwei Sachen herumgerissen wurdest.

16:30 Dokumentation für das Deployment ergänzen. Klingt langweilig, rettet dir später den Rücken.

17:00 On-Call-Übergabe an einen Kollegen, falls du im Rotation-Plan bist. Dann Feierabend, oder eine kurze Überstunde, wenn etwas klemmt.

Die Druckpunkte, über die niemand spricht#

On-Call-Bereitschaft ist der größte. Je nach Firma hast du eine Woche im Monat, in der du abends und nachts erreichbar sein musst. Manche zahlen dafür ein zusätzliches Gehalt, andere nicht. Frag das im Gespräch konkret, bevor du unterschreibst.

Incidents sind der zweite Punkt. Wenn die Produktion brennt, arbeitest du unter Zeitdruck mit halben Informationen. Das ist für manche Leute der beste Teil des Jobs. Für andere ist es der Grund, nach zwei Jahren zu wechseln.

Der dritte Punkt: Verantwortung ohne direkte Entscheidungsgewalt. Du bist für die Stabilität der Plattform zuständig, kannst aber selten allein entscheiden, wie schnell Features ausgeliefert werden. Das erzeugt eine Spannung, an der viele Teams scheitern.

Was Neueinsteiger wirklich überrascht#

Der erste Schock ist, wie viel im Job indirekt passiert. Du löst ein Problem für jemand anderen und bekommst selten direkte Anerkennung. Wenn alles läuft, bemerkt es niemand.

Der zweite Schock ist die Tiefe der Systeme. Ein Kubernetes-Cluster ist keine Blackbox, die man nach drei Monaten durchdrungen hat. Viele erfahrene Leute suchen wöchentlich in der offiziellen Dokumentation, weil die Details so spezifisch sind.

Der dritte Schock ist, wie stark Soft Skills zählen. Du musst erklären können, warum ein Deployment jetzt nicht stattfindet, ohne als Bremser dazustehen. Diese Fähigkeit entwickelt sich über Jahre.

Wenn du vor dem Einstieg stehst, hilft es, den aktuellen Markt anzuschauen. Unsere Jobbörse zeigt dir reale DevOps-Positionen mit den dazugehörigen Anforderungen.

Wie sich die Rolle von Junior zu Senior verändert#

Als Junior löst du Tickets, die dir zugewiesen werden. Du schreibst Skripte, pflegst bestehende Pipelines, lernst die Umgebung kennen. Entscheidungen triffst du selten allein.

Auf mittlerer Ebene besitzt du Themen. Du baust ein Deployment-System, pflegst einen Teil der Infrastruktur, beantwortest die Fragen der Entwickler. Du wirst seltener gefragt und entscheidest öfter selbst.

Als Senior gestaltest du Richtungen. Du setzt Standards, führst Architekturgespräche, verhandelst mit Produktverantwortlichen über Prioritäten. Der Anteil an Meetings und an ungelösten, unklaren Problemen wächst. Der Anteil an reinem Coding sinkt paradoxerweise oft.

Viele Senior-Leute sagen, der Job werde mit der Zeit weniger technisch und mehr kommunikativ. Wer das nicht will, bleibt lieber Individual Contributor auf einer tieferen technischen Ebene, was in vielen Firmen ein akzeptabler Weg ist.

Gehalt und realistische Erwartungen#

DevOps-Gehälter liegen in Deutschland je nach Erfahrung, Region und Unternehmensgröße in einem weiten Rahmen. Für Berufseinstieg werden oft Werte um die 45.000 bis 55.000 Euro genannt, auf mittlerer Ebene etwa 55.000 bis 75.000 Euro, bei Senior-Rollen und Verantwortung auch darüber. Diese Zahlen schwanken stark und sind keine Zusage.

Prüfe immer die aktuellen offiziellen Quellen und vergleiche konkrete Angebote, bevor du dich festlegst. Regionale Unterschiede zwischen München, Berlin und dem ländlichen Raum sind erheblich.

Checkliste für deinen Einstieg#

• Lies eine Stellenanzeige Zeile für Zeile und notiere, welche Tools dort wirklich vorkommen
• Prüfe deine Bewerbungsunterlagen auf ATS-Kompatibilität, viele Firmen filtern automatisch vor dem ersten Blick
• Frage im Gespräch konkret nach der On-Call-Regelung, wie oft und wie vergütet
• Frage nach dem typischen Split zwischen Meetings und konzentrierter Arbeit im Team
• Frage, wie Incidents dokumentiert werden und ob es eine blameless Post-Mortem-Kultur gibt
• Kläre, wer die technischen Entscheidungen trifft, wenn Produkt und Plattform kollidieren
• Recherchiere das aktuelle Gehaltsniveau für deine Region, nicht für ganz Deutschland

Wenn du dir unsicher bist, ob dein Lebenslauf überhaupt durch die Vorauswahl kommt, kannst du ihn mit dem kostenlosen ATS-Checker prüfen. Für Stellenanzeigen, die vor Buzzwords nur so strotzen, gibt es zusätzlich den kostenfreien Stellenanzeigen-Decoder, der dir zeigt, was die Firma wirklich sucht.

Kostenlose Tools#

• jobrise.io/de/free-ats-checker/
• jobrise.io/de/free-jd-decoder/
• jobrise.io/de/jobs/
• jobrise.io/de/blog/

Häufige Fragen#

Wie viel Zeit verbringt ein DevOps Engineer wirklich in Meetings?

In vielen Teams sind es 25 bis 40 Prozent der Arbeitszeit, in stakeholderlastigen Umgebungen auch mehr. Frag im Bewerbungsgespräch direkt nach, wie das konkrete Team seine Woche strukturiert.

Muss ich als DevOps Engineer programmieren können?

Ja, aber selten in dem Umfang wie ein Softwareentwickler. Du schreibst vor allem Skripte, Konfigurationen, Terraform-Code und kleine Automatisierungen. Python, Bash und YAML sind die häufigsten Sprachen im Alltag.

Wie oft hat man als DevOps Engineer Bereitschaftsdienst?

Das variiert stark. Manche Firmen haben eine Woche pro Monat im Rotation, andere nur ein paar Tage im Quartal. Kläre vor der Unterschrift, wie oft Bereitschaft anfällt und wie sie vergütet wird.

Was unterscheidet DevOps von Site Reliability Engineering?

Die Grenzen sind fließend und je nach Firma unterschiedlich. SRE hat oft einen stärkeren Fokus auf Kennzahlen wie Service Level Objectives, während DevOps breiter auf die Zusammenarbeit zwischen Entwicklung und Betrieb setzt. Lies die Stellenanzeige genau, statt dich auf den Titel zu verlassen.

Wie lange dauert es, bis man im Job produktiv ist?

In einer neuen Umgebung sind drei bis sechs Monate realistisch, bis du dich sicher bewegst. Die Systeme sind komplex, und viel Wissen steckt in Dokumentation und Gesprächen mit Kollegen. Erwarte nicht, nach vier Wochen alles zu verstehen.