Head of DevOps kündigt 2026: Bus-Faktor 1 sichern

Robin Werner, Head of Azure & Kubernetes bei Pexon Consulting | 10 Min. Lesezeit | 10.09.2026

TL;DR: Head of DevOps kündigt, Bus-Faktor 1

Wenn der Head of DevOps kündigt und das Cluster-Wissen in einer Person steckt, steht die Plattform. Bus-Faktor 1 ist in Kubernetes der Normalfall, nicht die Ausnahme. Pexon Consulting geht in Bestandsumgebungen hinein, klärt die Lage und beginnt mit Cluster-Review plus Grunddokumentation – oft schon am nächsten Morgen.

Das Problem: eine Kündigung legt die ganze Plattform offen

Der Anruf klingt jedes Mal ähnlich: Der Head of DevOps hat gekündigt. Oder der leitende Kubernetes-Architekt verlässt das Unternehmen. Und dann stellt sich heraus, dass das gesamte Infrastrukturwissen in dieser einen Person steckte.

Das ist Bus-Faktor 1 – die Zahl der Personen, die ausfallen müssten, damit ein Projekt zum Stillstand kommt. Bei Infrastruktur liegt sie in erschreckend vielen Unternehmen bei genau eins.

Wir hatten das nicht einmal, sondern mehrfach: Kunden, die anrufen, weil „der Guy weg ist“ und dringend Hilfe brauchen. Insbesondere bei Kubernetes-Themen, aber längst nicht nur dort.

Und der Auslöser muss nicht einmal eine Kündigung sein. Er kann Krankheit heißen, Elternzeit, ein interner Wechsel oder einfach ein längerer Urlaub zum falschen Zeitpunkt.

Genau dieser falsche Zeitpunkt ist im August 2026 greifbar geworden. Kubernetes 1.37 (Garhwal) ist am 26.08.2026 erschienen, mit 16 Stabilisierungen und einem Satz Breaking Changes: Feature-Gates fallen weg, kubeadm v1beta3 ist Geschichte, eine Reihe kubelet-Flags verschwindet. Wer den Upgrade-Pfad nur im Kopf einer Person hat, merkt den Bus-Faktor nicht am Kündigungsschreiben, sondern am ersten Patch-Zyklus, den niemand mehr erklären kann.

Vorsorge: das unsexy wichtigste Thema

Der beste Tipp ist zugleich der langweiligste: Dokumentation. Dokumentation. Dokumentation.

Es ist ein unsexy Thema, und genau deshalb wird es liegengelassen. Aber es ist der einzige Mechanismus, der Wissen aus einem Kopf herausholt und in die Organisation bringt – besonders dann, wenn der Head of DevOps noch da ist und erklären kann, warum etwas so gebaut wurde. Konkret heißt das:

• Architekturentscheidungen festhalten – nicht nur was gebaut wurde, sondern warum. Das „Warum“ ist der Teil, der bei einem Abgang tatsächlich verlorengeht.
• Betriebswissen dokumentieren – Wartungsfenster, Update-Pfade, bekannte Eigenheiten, die Stellen, an denen die Umgebung anders ist als die Standardlösung.
• Zugänge und Abhängigkeiten – welche Systeme hängen an welchen Credentials, wo liegen Zertifikate, was passiert bei Ablauf.
• Wiederherstellungspfade – wie kommt jemand, der die Umgebung nicht kennt, in einen funktionsfähigen Zustand zurück.

Nichts davon ist anspruchsvoll. Alles davon ist Arbeit, die niemand freiwillig priorisiert, solange die Person noch da ist.

Was nach einem Abgang sofort vorliegen muss, ist überschaubar. Wer das vorher aufschreibt, kauft sich Wochen:

# Inventar nach einem Personalabgang - Stand muss bei Ihnen liegen
cluster:
  name: production
  kubernetes_version: "1.37.0"   # Release 26.08.2026
  umgebung: aks                    # oder eks / gke / on-prem
zugang:
  kubeconfig: vault/k8s/prod
  break_glass: dokumentiert
dokumentation:
  architekturentcheidungen: vorhanden
  runbooks: vorhanden
  zertifikate_ablauf: kalender
wiederherstellung:
  letzter_restore_test: "2026-08-15"
  rto_ziel: "4h"

Wenn diese Liste leer ist, haben Sie kein Betriebsproblem, sondern eine Wissenslücke. Der Cluster-Review füllt genau diese Liste.

Machen Sie sich auch von Ihrem Dienstleister unabhängig

Diese Empfehlung gilt genauso für die Zusammenarbeit mit Partnern wie uns: Verlassen Sie sich niemals darauf, dass ein Dienstleister für immer an Ihrer Seite ist.

Der Mechanismus ist derselbe wie beim internen Bus-Faktor, nur mit anderer Dynamik. Ein Dienstleister, der sein Wissen unter Verschluss hält, sagt jahrelang „läuft ja schon“ – und das stimmt sogar. Aber wenn er dann geht, der Vertrag teurer wird oder Sie wechseln möchten, stehen Sie vor einem Scherbenhaufen.

Aus Regulatorik-Sicht sollte man das ohnehin adressieren. Exit-Fähigkeit ist in vielen Rahmenwerken ein expliziter Punkt – und wird trotzdem regelmäßig vergessen. Laut Richtlinie 2022/2555 (NIS2) muss Betriebssicherheit nachweisbar sein, nicht das Versprechen einer einzelnen Person, dass „es schon läuft“.

Unser Anspruch bei jeder Zusammenarbeit ist deshalb, dass der Kunde alleine weiterarbeiten kann, wenn wir aus dem Projekt oder aus dem Managed-Service-Vertrag herausgehen – aus welchen Gründen auch immer. Wir bauen von Anfang an eine saubere Dokumentation auf und beteiligen das Kundenteam, wenn es das möchte: Wie funktioniert was, was haben wir da gebaut. Nicht jeder will das – manche sagen ausdrücklich, hier ist die Applikation, die soll laufen, gut ist. Aber viele wollen zumindest grundlegend verstehen, wie ihre Plattform funktioniert. Und das ist die gesündere Variante.

Der Ernstfall: der Head of DevOps ist weg

Angenommen, es ist bereits passiert. Der DevOps-Kollege ist weg, dokumentiert ist nichts, und Sie leiten das Entwicklungsteam, ohne sich mit der Infrastruktur auszukennen. Was dann?

Erstens: melden. Wir haben in der Regel kurzfristig Kapazität frei, um zumindest zeitnah zu unterstützen. Es gab Fälle, in denen ein Kunde abends anrief und am nächsten Morgen ein Call stattfand.

Zweitens: Lage klären, nicht reparieren. Wenn nicht akut die Hütte brennt, nehmen wir uns zuerst Zeit, die Situation anzuschauen und uns einzuarbeiten. Je nachdem, wie schnell Ergebnisse gebraucht werden, gehen wir mit mehr Personal hinein. Diese Phase ist unbeliebt, weil sie nach Stillstand aussieht – sie ist aber der Unterschied zwischen einer Lösung und einem zweiten Problem.

Dass das schnell geht, liegt an der Erfahrung: Unsere Kollegen – darunter Golden Kubestronauts – haben so viele verschiedene Infrastrukturen und Umgebungen gesehen, dass die Einarbeitung in eine fremde Landschaft meist erstaunlich zügig gelingt. Nach Angaben der CNCF ist das der Nachweis für geprüfte Kubernetes-Praxis, nicht nur ein Kurszertifikat.

Drittens: Review und Grunddokumentation. Der erste konkrete Schritt ist praktisch immer ein Review des gesamten Clusters plus eine grundlegende Dokumentation. Einmal für uns – auch bei uns kann Personal wechseln – und einmal für Sie. Danach haben Sie schwarz auf weiß, wie die Dinge laufen und funktionieren. Das ist die Grundlage für jede weitere Entscheidung.

Ein Fall aus der Praxis

Ein Kunde meldete sich an einem Mittwochabend: dringend Hilfe nötig. Die komplette Website war down, sie lief auf AKS. Der leitende Infrastruktur-Ingenieur war gegangen.

Am nächsten Morgen war Zeit für einen Call und zwei, drei Stunden Analyse. Man muss sich in solchen Situationen zuerst sehr schnell einen Überblick verschaffen, worum es tatsächlich geht.

Die Vorgeschichte war der eigentlich interessante Teil und ein Klassiker: Nach dem Abgang hatte der Entwickler die Infrastrukturthemen mit übernommen – in der Annahme, das passe schon, man finde ja bald einen neuen Head of DevOps. Fand man nicht. Dann kamen die Probleme: In der Infrastruktur war etwas falsch konfiguriert, und der Entwickler konnte an dieser Stelle nicht weiter.

Die Lehre daraus ist nicht, dass der Entwickler zu wenig konnte. Sie ist, dass die Zwischenlösung „macht erstmal jemand mit“ der Punkt war, an dem die Situation kippte. Wer nach einem Abgang sofort Ersatz organisiert – intern oder über einen Partner -, überspringt genau diese Phase.

Die unbequeme Wahrheit über Nebenbei-Zuständigkeiten

Ein IT-Leiter erzählte uns einmal sehr offen: Das Kubernetes-Cluster hatte ein Entwickler aufgesetzt. Im Personalgespräch sagte dieser Entwickler, dass er eigentlich gar keine Lust auf die ganze Infrastruktursache habe und lieber wieder entwickeln würde.

Das ist häufiger, als man denkt. Infrastruktur wird von Leuten aufgesetzt, die lieber etwas anderes machen würden und irgendwann damit beauftragt wurden. Das Ergebnis ist doppelt ungünstig: Die Umgebung ist nicht optimal aufgesetzt, und die Person, die sie betreut, hat keine Motivation dafür.

Kubernetes ist unglaublich komplex und teilweise schwer gut zu konfigurieren – vor allem schwer sicher zu konfigurieren. Es ist keine gute Idee, dafür einfach irgendjemanden abzustellen. Zumindest einmal mit einem Experten daraufzuschauen, hilft schon erheblich.

Drei Wege aus der Abhängigkeit

Wenn der Head of DevOps kündigt oder das Thema abgibt, stehen drei Wege offen. Welcher passt, hängt an Bereitschaft und Zeit, nicht am Cluster.

1. Wissen aufbauen. Der positive Fall, den wir ebenfalls oft sehen: IT-Leiter rufen an, weil sie es lernen wollen. Schulung, Beratung, wirklich fit werden. Wir haben eine Reihe von Projekten umgesetzt, in denen Entwickler und Infrastrukturkollegen Kubernetes von Grund auf gelernt haben. Das funktioniert gut, wenn die Bereitschaft da ist.
2. Betrieb abgeben. Managed Service, dauerhaft oder als Überbrückung. Über die Gesamtkosten gerechnet ist das oft günstiger, als eine eigene Person dafür zu beschäftigen – und es hat keinen Bus-Faktor. Was zwei interne Stellen plus Bereitschaft wirklich kosten, steht in der Kubernetes-Eigenbetrieb-Rechnung.
3. Der Mittelweg. Ein Modell, das wir aktuell in einem größeren Projekt fahren: Wir bauen das Cluster wirklich professionell auf, der Kunde betreibt es danach selbst. Learning on the Job auf einer Umgebung, die von Anfang an richtig gebaut und dadurch auch wartbar ist. Das ist häufig die nachhaltigste Variante.

Keiner der drei Wege startet mit einem großen Umbau. Der Einstieg ist derselbe: ein Blick auf das Cluster und eine Dokumentation, die Ihnen gehört. Welche Variante danach folgt, entscheiden Sie, nicht der Kalender des ersten Anrufs.

Häufig gestellte Fragen

Wie schnell können Sie im Notfall einsteigen?

Meistens sehr kurzfristig – wir haben in der Regel Kapazität, um zeitnah einen ersten Call zu machen und die Lage anzuschauen. Für die geordnete Übernahme planen Sie danach realistisch mit ein bis zwei Wochen für Review und Grunddokumentation.

Was kostet ein Cluster-Review nach einem Personalabgang?

Das hängt an Größe und Zustand der Umgebung und klären wir im Vorgespräch. Der Einstieg über ein kleines Security- oder Cluster-Review ist bewusst niedrigschwellig gehalten, weil es beiden Seiten dient: Wir lernen die Umgebung kennen, Sie bekommen eine erste belastbare Einschätzung. Danach lässt sich der weitere Bedarf deutlich besser beziffern.

Ist Managed Service eine dauerhafte Entscheidung?

Nein, und das ist uns wichtig. Wenn Sie später wieder jemanden einstellen wollen, ist das völlig in Ordnung – wir arbeiten so, dass Sie sich jederzeit wieder von uns lösen können. Manche Kunden stellen dabei fest, dass der Managed Service hervorragend läuft und günstiger ist als eine eigene Stelle. Das ist dann Ihre Entscheidung, nicht unsere.

Wir haben noch niemanden verloren. Lohnt sich das Thema trotzdem?

Das ist der mit Abstand beste Zeitpunkt. Ein Cluster-Review, während die Person noch da ist, kostet einen Bruchteil dessen, was dieselbe Analyse nach ihrem Abgang kostet – und die Dokumentation entsteht mit der Person zusammen statt gegen die Lücke, die sie hinterlässt.

Wie erkenne ich, ob wir Bus-Faktor 1 haben?

Eine einfache Probe: Bitten Sie jemanden aus dem Team, der die Umgebung nicht gebaut hat, anhand der vorhandenen Dokumentation zu beschreiben, wie das Cluster im Notfall wiederhergestellt wird. Wenn dabei eine Rückfrage an genau eine Person entsteht – oft der Head of DevOps – haben Sie Ihre Antwort.

Nächster Schritt

Mitbringen sollten Sie drei Dinge: eine ehrliche Einschätzung, wie viel Ihrer Infrastruktur an einer einzelnen Person hängt, den Zugang zu Ihrer Umgebung, und die Information, ob Sie mittelfristig selbst betreiben oder abgeben wollen.

Ob es akut brennt oder ob Sie vorsorgen – der Einstieg ist derselbe: ein Blick auf das Cluster und eine Dokumentation, die Ihnen gehört.

Philipp Pham und Robin Werner sprechen über Bus-Faktor 1 in der Infrastruktur, einen konkreten Notfall bei einem Kunden und die Frage, wie man vorsorgt, wenn der Head of DevOps kündigt. Video auf YouTube ansehen.

Verwandte Themen