Bus-Faktor 1: Wenn der Cluster nur einem Kollegen gehört
In vielen kleinen Teams gehört der Cluster einem Kollegen. Das geht gut, bis er Urlaub hat. Sechs Schritte, mit denen der Betrieb nicht mehr an einer Person hängt.
Der Bus-Faktor ist die Zahl der Kollegen, die ausfallen müssten, damit ein Projekt stillsteht. In vielen kleinen Teams ist er für den Kubernetes-Betrieb genau eins. Ein Kollege hat den Cluster aufgesetzt, kennt die Terraform-Dateien, hat das Admin-Token auf seinem Laptop und weiß, in welcher Reihenfolge das Onboarding-Skript für einen neuen Kunden läuft. Das funktioniert jahrelang. Bis er zwei Wochen Urlaub hat und ein Zertifikat abläuft.
Woran erkennen Sie Bus-Faktor 1?
- Deployments laufen nur, wenn eine bestimmte Person Zeit hat.
- Es gibt ein Skript für neue Kunden, aber nur einer weiß, welche Parameter es braucht.
- Die kubeconfig mit Admin-Rechten liegt auf genau einem Rechner, oder auf fünf, und niemand weiß mehr, auf welchen.
- Alarme gehen an eine persönliche E-Mail-Adresse.
- Die Doku im Wiki beschreibt den Zustand von vor zwei Upgrades.
- Auf die Frage, wie man eine Datenbank wiederherstellt, lautet die Antwort: Frag ihn.
Wer drei dieser Punkte wiedererkennt, hat Bus-Faktor 1. Das ist kein Vorwurf an den Kollegen. Es ist die natürliche Folge davon, dass einer die Arbeit gemacht hat, während alle anderen Features gebaut haben.
Was kostet Bus-Faktor 1?
Die offensichtlichen Kosten sind Ausfälle, die niemand beheben kann, und Releases, die warten. Die weniger offensichtlichen sind teurer:
Sicherheit. Ein persönliches Admin-Token, das nie rotiert wird, ist das wertvollste Ziel im ganzen Unternehmen. Verlässt der Kollege das Team, müsste es ausgetauscht werden, und oft weiß niemand, wo es überall hinterlegt ist.
Tempo. Jede Infrastrukturfrage landet bei einer Person. Sie wird zum Engpass, auch wenn sie schnell ist.
Abhängigkeit. Wer als einziger den Cluster versteht, hat eine Verhandlungsposition, die weder er noch das Unternehmen haben sollten. Und er bekommt nie richtig Urlaub.
Wie kommen Sie zu Bus-Faktor zwei und mehr?
1. Bestandsaufnahme
Aufschreiben, was es gibt: Cluster, Datenbanken, Buckets, Domains, Zertifikate, Zugänge. Nicht als Wiki-Seite, die veraltet, sondern als Liste, die aus dem System selbst kommt. Allein diese Übung zeigt meist zwei vergessene Zugänge und ein Zertifikat, das in drei Wochen abläuft.
2. Persönliche Zugänge statt geteiltem Token
Jeder, der am Betrieb beteiligt ist, bekommt einen eigenen Zugang mit einer Rolle. Entwickler dürfen deployen, aber keine Cluster löschen. Die CI-Pipeline bekommt ein eigenes Token mit Ablaufdatum. Das Admin-Token wird nicht mehr für den Alltag gebraucht und landet sicher verwahrt, nicht auf Laptops. Genau danach fragt übrigens auch jeder Prüfer, siehe NIS2 im Kubernetes-Betrieb.
3. Abläufe als Daten statt als Skripte
Ein Onboarding-Skript ist Wissen in Code, den einer versteht. Ein beschriebener Ablauf, den das System ausführt, ist Wissen, das jeder bedienen kann: Datenbank anlegen, Bucket anlegen, Domain einrichten, Anwendung ausrollen, in dieser Reihenfolge, mit den Werten des Kunden. Wer das einmal so beschrieben hat, braucht niemanden mehr, der sich an die Parameter erinnert. Wie das als Pipeline aussieht, zeigt Tenant-Pipelines.
4. Der Zweite macht, der Erste schaut zu
Das nächste Kubernetes-Upgrade, das nächste Add-on-Update, die nächste Wiederherstellung: Der Kollege, der es noch nie gemacht hat, führt aus, der Erfahrene sitzt daneben. Nach zwei Durchgängen gibt es zwei, die es können.
5. Alarme an einen Kanal, nicht an eine Person
Ein Alarm an eine persönliche Adresse verschwindet im Urlaub. Ein Alarm in einem Team-Kanal sieht jeder, und wer ihn übernimmt, schreibt es dazu.
6. Doku dort, wo die Arbeit passiert
Die beste Doku ist die, die man nicht suchen muss: der Hinweis neben dem Knopf, das Protokoll, das zeigt, wie es beim letzten Mal gemacht wurde, die Liste der Änderungen mit Namen. Ein Wiki ergänzt das, ersetzt es aber nicht.
Der Urlaubstest
Ein einfacher Test zeigt, ob es gewirkt hat: Der Kollege, der den Cluster aufgebaut hat, nimmt zwei Wochen Urlaub und ist nicht erreichbar. In dieser Zeit werden deployt, ein neuer Kunde angelegt und ein Alarm bearbeitet. Wenn das klappt, ist der Bus-Faktor größer als eins. Wenn nicht, wissen Sie genau, woran es hing.
Ein typischer Verlauf
Nehmen wir einen SaaS-Anbieter mit sechs Entwicklern, einem Cluster und rund vierzig Kunden, wie wir ihn oft sehen. Den Cluster hat vor drei Jahren ein Kollege aufgesetzt, der seitdem jedes Upgrade, jedes neue Kunden-Onboarding und jede nächtliche Störung übernimmt. Er kündigt eine längere Elternzeit an, es bleiben sechs Wochen.
Die ersten zwei Wochen gehen typischerweise für die Bestandsaufnahme drauf, und sie fördert Dinge zutage wie Zugänge ehemaliger Mitarbeitender, ein Wildcard-Zertifikat, das von Hand erneuert wird, oder ein Onboarding-Skript mit elf Parametern. Danach bekommt jeder Entwickler einen eigenen Zugang, die CI ein eigenes Token, das Admin-Token wandert in einen Tresor. Das Onboarding wird als Ablauf beschrieben, und zwei Kollegen legen unter Anleitung je einen Kunden an. Das nächste Kubernetes-Upgrade macht ein Kollege, der vorher nie im Cluster war.
Das Ziel ist erreicht, wenn Störungen in der Elternzeit bearbeitet werden, ohne dass jemand anruft.
Was Sie nicht tun sollten
Einen Doku-Sprint ansetzen. Zwei Wochen Wiki-Seiten schreiben erzeugt Seiten, die nach dem nächsten Upgrade veraltet sind. Besser: die Arbeit so umbauen, dass sie sich selbst dokumentiert.
Alle alles lernen lassen. Nicht jeder Entwickler muss Kubernetes-Upgrades können. Zwei bis drei Leute, die den Betrieb beherrschen, reichen für ein kleines Team, wenn die Abläufe für alle anderen bedienbar sind.
Ein zweites Admin-Token verteilen. Wer den Bus-Faktor erhöht, indem er das Admin-Token an einen zweiten Kollegen gibt, hat das Risiko verdoppelt statt verteilt. Mehr Leute brauchen mehr Zugänge mit weniger Rechten, nicht mehr Kopien des einen mit allen.
Wie Clusterward dabei hilft
Clusterward nimmt dem Team die Teile ab, die sonst in einem Kopf stecken: Cluster, Datenbanken, Buckets, Domains und Deployments entstehen nach denselben Regeln, egal wer sie anlegt. Jeder hat einen eigenen Zugang mit Pflicht-Mehr-Faktor und einer Rolle, die CI ein eigenes Token, und das Audit-Log zeigt, wer was wann gemacht hat. Onboarding-Abläufe sind Pipelines, Alarme gehen an Team-Kanäle. Was das für die technische Leitung bedeutet, steht unter Für CTOs; wie sich das gegen einen selbst gebauten Betrieb rechnet, unter Clusterward vs. Eigenbau.
Fazit
Bus-Faktor 1 ist kein Personalproblem, sondern ein Aufbauproblem. Verteilen Sie Zugänge statt Tokens, beschreiben Sie Abläufe statt Skripte und lassen Sie den Zweiten die nächste Wartung machen. Der beste Beweis ist ein Urlaub, in dem niemand anruft.
Wie hoch ist Ihr Bus-Faktor? In einer Demo zeigen wir, wie ein zweiter Kollege am ersten Tag deployt, ohne private Skripte und ohne geteiltes Admin-Token. Demo anfragen →
Quellen und weiterführende Links
Häufige Fragen
- Der Bus-Faktor ist die Zahl der Kollegen, die ausfallen müssten, damit ein Projekt stillsteht. Bei Bus-Faktor 1 hängt der Kubernetes-Betrieb an einer Person: Sie hat den Cluster aufgesetzt, kennt die Terraform-Dateien, hat das Admin-Token auf ihrem Laptop und weiß als Einzige, wie das Onboarding-Skript für neue Kunden läuft.