Die ersten 90 Tage: Schritt-für-Schritt-Playbook für DevOps-Ingenieur:innen

Man hat dir Zugriff auf das Cloud-Konsol, die Build-Pipeline und vielleicht sogar – erschreckenderweise – Root auf Prod gegeben (kein Druck).

Die meisten DevOps-Onboardings sind ein fragiles Gemisch aus „Lies dieses zufällige Dokument von 2021“, „Frag mal rum“ und „Fass das Skript lieber nicht an, wir glauben, das macht noch irgendwas.“ 

Die Rolle ist selten klar definiert, die Erwartungen sind absurd hoch, aber die Dokumentation niedrig. Und einige Deployments wirken, als könnten sie einen uralten Fluch wecken.

Auch wenn es im Vorstellungsgespräch um Tools ging, deine ersten 90 Tage drehen sich um Menschen, Prozesse und Prioritäten. Genau hier baust du dir Glaubwürdigkeit auf, entdeckst das Undokumentierte und legst das Fundament für eine Infrastruktur, auf die dein Team sich verlassen kann.

Dieses Playbook wird nicht über Nacht die Infrastruktur deines Teams reparieren. Aber es hilft dir, nicht wie der*diejenige zu wirken, der*die sie kaputt gemacht hat.

Stimmen aus der Praxis

„Die wichtigste Lektion, die ich gelernt habe, ist, wie schnell man seine Kunden verstehen muss – also die Entwickler – und ihre Vorlieben. Bei Pixar habe ich einmal ein CI-System aufgesetzt, das niemand nutzte, bis ich E-Mail-Benachrichtigungen einrichtete. Es stellte sich heraus, dass genau das die bevorzugte Art der Benachrichtigung war. In einem anderen Unternehmen haben wir die Einführung von Tests gefördert, indem wir sie mit Live-Leaderboards im Büro gamifizierten. Kultur ist nicht nur ein Hintergrunddetail – sie ist die eigentliche Delivery-Pipeline. -Tara Hernandez, VP of Developer Productivity bei MongoDB

Die Rolle: DevOps vs. Platform vs. SRE

Starten wir mit dem ewigen Hinweis: „DevOps ist eine Kultur, kein Jobtitel.“ Sicher, Jan – aber den Jobtitel gibt es trotzdem. Und in der Praxis bedeutet das oft eine Mischung aus Automatisierungsspezialist*in, Systemarchitekt*in, SRE und Expert*in für interne Tools.

Du sollst ein Ermöglicher*in sein, ein Multiplikator*in, ein*e Champion für Delivery-Geschwindigkeit. Aber in Wirklichkeit kommst du ins Spiel, wenn:

• Der Build fehlschlägt und niemand weiß warum.
• Jemand jetzt sofort eine neue Staging-Umgebung braucht.
• Ein Compliance-Audit ansteht und Geheimnisse im Klartext herumfliegen.
• Aus „Das sollten wir echt automatisieren“ wird „Kannst du das automatisieren?“

Platform Engineering ist DevOps mit besserem Branding.
SRE ist DevOps mit einem SLA.

Wie auch immer es genannt wird, dein Job ist es, dafür zu sorgen, dass alles skaliert, läuft und nicht nervt.

Die ersten 30 Tage: Noch nichts anfassen

Tipp #1: Mappe die Infrastruktur, nicht nur die Architektur 

Finde heraus, wofür du verantwortlich bist: Cloud-Provider, CI/CD-Pipelines, Container-Orchestrierung, Geheimnisverwaltung und Incident-Workflows. Erstelle deine eigene „Infra-Map“, um den Stack zu visualisieren. Extra Punkte, wenn du zu Live-Dashboards oder Skripten verlinkst.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with LinkedIn

Or sign up with email:

URL

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Tipp #2: Finde das Schadenspotenzial

Jede DevOps-Abteilung hat ein „Bitte fass das nicht an“-Setup. Erfasse alles, was explodieren könnte, wenn es falsch behandelt wird. Dazu gehören:

• Deploy-Skripte, die per SSH auf Prod gehen (warum… warumyy?)
• Jenkins-Jobs, zuletzt geändert 2019
• Manuelle Runbooks als PDF gespeichert
• Terraform-Dateien, die nie wirklich angewendet wurden

Frage: Was ist undokumentiert, aber kritisch? Wem gehört es? Und was ist der Rollback-Plan, wenn es fehlschlägt?

Tipp #3: Setz dich bei einem Deployment dazu – oder begleite besser ein Live-Deployment 

Von einem einzigen Deployment (und seinen Hiccups) lernst du mehr als von stundenlangem Lesen. Was läuft manuell? Was ist wackelig? Was ist Stammeswissen, was ist dokumentiert? Du bist nicht hier, um jetzt schon geniale Ideen zu droppen. Du bist hier, um Schmutz zu sammeln.

Du solltest in der Lage sein, einen Commit von Merge bis Produktion im Schlaf zu verfolgen. Verstehe:

• Die CI/CD-Pipeline (wo sie ausfällt, wo sie Engpässe hat)
• Geheimnisverwaltung (bitte nicht in Umgebungsvariablen)
• Genehmigungsprozesse (deployen wir YOLO direkt aus Slack?)

Versende keinen Code. Beobachte die Abläufe und notiere alles.

Stimmen aus der Praxis

“Gutes Onboarding geht nicht immer mit guter Dokumentation einher. Manchmal kommt man durch das Chaos nur mit Neugier und Beharrlichkeit. Als ich in ein Team kam und eine komplexe Einführung ohne Doku erhielt, habe ich den gesamten Ablauf rückverfolgt. Diese Erfahrung lehrte mich: Fehlt die Dokumentation, wirst du selbst zur Dokumentation.” –Anant Agarwal, CTO bei Aidora

Die ersten 60 Tage: Risiken erkennen, Reibungsverluste verringern

Tipp #4: Sorge für einen 5-Minuten-Erfolg

Suche nach Aufgaben mit hohem Reibungsverlust und geringem Risiko, die du skripten oder als Vorlage bereitstellen kannst. Diese „1%“-Verbesserungen machen dein Leben einfacher und schaffen Vertrauen im Team. Finde einfach eine Sache, die 5 Minuten zu lange dauert, und beschleunige sie:

• Shell-Wrapper für lokale Entwicklungsumgebung
• Ein CLI-Helfer 
• Ein wiederverwendbares Terraform-Modul
• Skript zum Entfernen festsitzender Testumgebungen
• Slack-Benachrichtigung bei fehlgeschlagenen Builds

Kleine Erfolge schaffen Vertrauen. Vertrauen gibt dir Spielraum für große Veränderungen.

Tipp #5: Überprüfe die CI/CD-Pipeline mit äußerster Sorgfalt

Schau dir die Buildzeiten an. Sieh dir die Testabdeckung an. Beobachte, was täglich ausfällt. Stell Fragen wie:

• Können wir Tests parallelisieren?
• Hätte das schon früher im CI verhindert werden können?
• Cachen wir Abhängigkeiten?
• Deployen wir beim Merge… oder mehr auf gut Glück?

Du bist nicht hier, um Schuldige zu finden. Du bist hier, um den Ablauf reibungslos zu gestalten.

Tipp #6: Erstelle Dashboards, die tatsächlich verwendet werden, und kläre Verantwortlichkeiten 

 Grafana, Prometheus, Datadog – das Tool ist egal. Was zählt:

• Kann dein Team die Erfolgsrate von Deployments sehen?
• Haben Alarme einen Wert, oder sind sie nur Lärm?

Überwacht jemand die Fehlerraten, bevor Nutzer sich beschweren? Wer ist für die Build-Pipeline verantwortlich? Für die Helm-Charts? Für die DNS-Konfigurationen? Die Zuständigkeiten sind selten klar. Erstelle eine Liste mit Grauzonen und stimme sie mit deinem Team ab. Das beugt spätem Fingerzeigen vor.

Ab jetzt bist du für die Transparenz verantwortlich. Mach was draus.

Die ersten 90 Tage: Vertrauen durch Zuverlässigkeit aufbauen

Tipp #7: Liefere etwas, das die Stabilität erhöht 

Das kann sein:

• Alarmierung für ein bisher wenig überwachtes System hinzufügen
• Testabdeckung in der Vorproduktion verbessern
• Instabilität in CI-Pipelines verringern
• Ein Bash-Skript überarbeiten, das nur einen rm -rf von der Katastrophe entfernt war

Es muss nicht groß sein. Aber es muss deinem Team das Leben leichter machen.

Stimmen aus der Praxis

“Einer der ersten Erfolge in einer neuen DevOps-Rolle war die Einführung einer zentralisierten CI/CD-Pipeline mit automatisiertem Rollback und GitOps-Workflows. Vorher verließ sich das Team auf fragmentierte Skripte und manuelle Bastellösungen. Das reduzierte die Bereitstellungszeiten um über 50 % und katapultierte uns von ständiger Brandbekämpfung zu proaktiver Zuverlässigkeit. Die Glaubwürdigkeit, die dieser Rollout gebracht hat, hat einen riesigen Unterschied gemacht.” –Divya Parashar, Senior Staff Engineer

Tipp #8: Schreibe ein „DevEx“-Feedback-Memo

Sammle anonymes oder informelles Feedback von Entwicklern darüber, wo die Infrastruktur sie ausbremst. Präsentiere deine Erkenntnisse und schlage Experimente vor (z. B. schnellere lokale Entwicklung, kurzlebige Umgebungen, besseres Logging).

Schreibe ein Dokument mit dem Titel „Das habe ich gelernt und das mache ich als Nächstes.“ Das ist ein Fahrplan (und vielleicht auch ein bisschen Eigenwerbung ;). Teile es mit deinem Manager und dem Team.

Erstelle eine „Das darf ich nicht vergessen“-Liste:

• Die seltsamen Eigenheiten, die du aufgedeckt hast
• Die Schatten-Infrastruktur, zu der sich niemand bekennt
• Das Stammeswissen, das anscheinend nur Carl von der IT kennt

Wandle diese Liste in Dokumente, Automatisierung oder Tickets um—oder behalte sie griffbereit. Das zeigt Führungskräften, dass du feuerfeste Systeme aufbaust.

Stimmen aus der Praxis

“Fokussiere dich auf die Ergebnisse, die du heute beeinflussen kannst. Mach dir klar, warum deine Arbeit für die Kunden wichtig ist—diese Perspektive macht gerade in den ersten 90 Tagen den Unterschied.” –Rukmini Reddy, SVP of Engineering bei PagerDuty

Tipp #9: Wähle ein einzelnes Projekt mit großem Hebel und beginne mit der Ausarbeitung 

Jetzt solltest du genug Hinweise haben, um einen wichtigen Verbesserungsbereich zu erkennen. Nutze die letzte Phase deiner ersten 90 Tage, um das Thema zu definieren, bekannt zu machen und Einigkeit zu schaffen.

• Instabile Jobs zu GitHub Actions migrieren
• Einen "Snowflake"-Server durch Infrastructure as Code ersetzen
• Einen Golden Path entwerfen, damit Entwickler einfach neue Services anlegen können

Starte klein und zeige deinen Wert. Dokumentiere alles.

Abschließende Worte

Mit etwas Glück schaffst du es innerhalb der ersten 90 Tage, die Lage zu stabilisieren, Deployments durchzuführen und vor allem die Entwickler davon abzuhalten, verzweifelt in den Abgrund zu schreien.

Gerade die ersten Tage sind entscheidend, um langfristig Schwung aufzubauen. Finde die Schwachstellen und dokumentiere wie ein Besessener! 

Stimmen aus der Praxis

“Du musst nicht alles an einem Tag beweisen. Atme durch. Stabilität geht vor Geschwindigkeit. Stelle am Anfang die vermeintlich dummen Fragen—später werden sie nur schwieriger. Und denk daran: Ein langweiliges, aber funktionierendes System ist besser als ein spektakuläres, das ständig ausfällt.” –Pablo Gerboles, CEO bei Alive DevOps

Nicht dein erster Tech-Ritt?

Dieses DevOps-Playbook ist Teil einer stetig wachsenden Serie für Neueinsteiger, die wirklich etwas bewegen wollen, bevor sie „Legacy Ownership“ zugeschoben bekommen.

👉 Du beginnst gerade in einer Rolle als Security Engineer? Wir haben genau das Richtige:
Die ersten 90 Tage: Cybersecurity Edition

👉 Coolere Commits als Root-Access? Dann schau mal hier:
Die ersten 90 Tage: Software Engineer Edition

Und ja—weitere Rollen folgen bald. Bleib dran oder noch besser, abonniere den Newsletter, damit du die nächste Ausgabe nicht verpasst.