Bus-Faktor minimieren: Sieben praktische Schritte ohne größeres Team

Bus-Faktor-Mitigation klingt, als bräuchte man dafür ein größeres Engineering-Team, und genau das ist meist der erste Grund, warum kleine Unternehmen das Thema aufschieben. Das stimmt nicht. Der Großteil des Risikos, das entsteht, wenn ein einziger Entwickler das gesamte Wissen trägt, lässt sich mit einer Handvoll konkreter Schritte senken, für die ein Nachmittag, verteilt über ein paar Wochen, ausreicht. Keiner dieser Schritte erfordert eine Neueinstellung. Was es erfordert, ist, ein paar Gewohnheiten als Arbeit zu behandeln, die eingeplant wird, statt als etwas, das nur passiert, wenn gerade Zeit übrig ist.

Falls Sie noch nicht geklärt haben, ob das auf Sie zutrifft, geht unser früherer Beitrag zum Bus-Faktor-Risiko die Zehn-Fragen-Prüfung durch. Dieser Beitrag setzt voraus, dass Sie die Antwort schon kennen und etwas dagegen tun wollen.

Warum das keine weitere Einstellung erfordert

Der Instinkt, das Bus-Faktor-Risiko durch mehr Köpfe zu lösen, ist verständlich, aber meist falsch, zumindest als erster Schritt. Ein zweiter Entwickler kostet ein Gehalt, braucht Monate, um produktiv zu werden, und löst nichts automatisch, wenn das benötigte Wissen weiterhin nur im Kopf einer Person steckt. Die eigentliche Lösung liegt näher an Buchhaltung als an Engineering: Dinge aufschreiben, Zugänge teilen und bestätigen, dass eine zweite Person das Aufgeschriebene auch nutzen kann.

Deshalb kann jeden der folgenden Schritte das bestehende Team erledigen, selbst ein Team aus einer Person plus einer nicht-technischen Inhaberin oder einem Inhaber, ganz ohne Neueinstellung. Manches davon geht wirklich schnell. Manches dauert länger, als man denkt, meist weil es immer wieder gegen das Feature verliert, das in dieser Woche fällig ist.

Sieben Schritte zur Bus-Faktor-Mitigation

1. Einen gemeinsamen Passwort-Tresor einrichten

Aufwand: ein halber Tag.

Wenn Ihre Hosting-Zugangsdaten, das Passwort des Domain-Registrars, die Datenbank-Admin-Zugänge und die Keys des Zahlungsabwicklers im Kopf einer Person, in einer Notizen-App oder verteilt über alte E-Mails liegen, verschieben Sie sie in einen gemeinsamen Passwort-Manager mit mindestens zwei Zugangsberechtigten. Das ist der wirkungsvollste Schritt auf dieser Liste, weil sich fast jeder andere Ausfall darauf zurückführen lässt, dass jemand aus einem Konto ausgesperrt ist, auf das sonst niemand zugreifen kann. Die Einrichtung dauert einen Nachmittag. Dass alle den Tresor tatsächlich nutzen, statt in alte Gewohnheiten zurückzufallen, dauert länger, prüfen Sie das also nach einem Monat noch einmal.

2. Einen zweiten Admin für jedes wichtige Konto anlegen

Aufwand: ein Nachmittag.

Gehen Sie Hosting, Domain-Registrar, den Host des Code-Repositorys, den Zahlungsabwickler und jeden E-Mail- oder DNS-Anbieter durch und legen Sie bei jedem einen zweiten Admin-Zugang an. Kein geteiltes Login, sondern ein echter zweiter Zugang mit eigenen Zugangsdaten, damit sich der Zugriff einer Person entziehen lässt, ohne alle anderen auszuschließen. Die meisten Unternehmen stellen bei diesem Schritt fest, dass sie gar nicht genau wissen, von wie vielen Diensten ihr Produkt abhängt, was für sich genommen schon eine nützliche Erkenntnis ist.

3. Ein Deployment-Runbook schreiben

Aufwand: ein bis zwei Tage, inklusive des Gesprächs mit der Person, die aktuell deployt.

Setzen Sie sich mit der Person zusammen, die heute Code ausliefert, und schreiben Sie genau auf, was passiert: welcher Befehl läuft, welcher Branch das auslöst, wie ein erfolgreiches Deployment aussieht und was zu prüfen ist, wenn es fehlschlägt. Das muss keine polierte Dokumentation sein. Eine einfache Textdatei, der eine zweite Person unter Druck folgen kann, ist mehr wert als eine schön formatierte Wiki-Seite, die niemand liest, bis sie drei Jahre veraltet ist.

4. Eine Architektur-Walkthrough aufnehmen

Aufwand: zwei bis drei Stunden, größtenteils Aufnahme und leichtes Schneiden.

Bitten Sie die Person, die das System am besten versteht, sich beim Bildschirmteilen aufzunehmen, während sie durchgeht, wie die Teile zusammenspielen: welcher Service mit welchem spricht, wo die größten Schwachstellen liegen, wovor sie eine ersetzende Person am ersten Tag warnen würde. Ein aufgenommenes Gespräch fängt genau die Art von Kontext ein, die nie in schriftlicher Dokumentation landet, weil niemand daran denkt aufzuschreiben, was für ihn selbst offensichtlich wirkt.

5. Einer zweiten Person jetzt schon Lesezugriff geben

Aufwand: eine Stunde Einrichtung, danach eine laufende Gewohnheit.

Das ist der Schritt, den die meisten Unternehmen auslassen, weil er sich unnötig anfühlt, solange alles läuft. Geben Sie einer zweiten Person, auch jemandem ohne technischen Hintergrund, der niemals Code schreiben wird, Lesezugriff auf das Repository, das Hosting-Dashboard und die Fehlerprotokolle. Das Ziel ist nicht, dass diese Person etwas repariert. Es geht darum, dass außer dem einen Entwickler noch jemand hinschauen und sehen kann, was läuft, damit ein Problem nicht damit beginnt, dass alle aus jedem Bildschirm ausgesperrt sind, der es erklären könnte.

6. Dokumentieren, was jeder geplante Job tut

Aufwand: ein Tag, meist verteilt über eine Woche, in der man die Jobs beim Laufen abfängt.

Cronjobs und geplante Aufgaben sind die Stelle, an der undokumentierte Systeme leise versagen. Ein Job, der Rechnungen versendet, alte Dateien aufräumt oder Daten mit einem Drittanbieter synchronisiert, kann wochenlang nicht mehr laufen, bevor es jemand merkt, weil ein stiller Ausfall keine Aufmerksamkeit einfordert. Listen Sie jede geplante Aufgabe auf, was sie tut und was kaputtgeht, wenn sie stoppt. Das ist mühsam statt schwierig, und genau deshalb fällt es so oft hinten runter.

7. Eine Backup-Wiederherstellung mit einer zweiten Person testen

Aufwand: ein halber Tag, plus die Zeit, die die Wiederherstellung selbst braucht.

Ein Backup, das nie wiederhergestellt wurde, ist eine Hoffnung, kein Plan. Suchen Sie sich einen ruhigen Nachmittag und lassen Sie jemand anderen als Ihren üblichen Entwickler ein Backup wiederherstellen, der vorhandenen Dokumentation folgend, und schauen Sie, was dabei kaputtgeht. Fast jedes Unternehmen, das das zum ersten Mal macht, findet mindestens eine Lücke: einen fehlenden Schritt, abgelaufene Zugangsdaten, eine Datei, die niemals im Backup enthalten war. Besser, diese Lücke an einem ruhigen Dienstag zu finden als während eines Ausfalls.

Was Ihnen das bringt

Keiner dieser sieben Schritte macht den Wert eines guten Entwicklers überflüssig, und keiner ersetzt die richtige Person im Team. Was sie tun, ist, den einen Single Point of Failure zu entfernen, der aus einem gewöhnlichen Übergang, einer Kündigung, einer Krankheit, einem Urlaub, eine Krise macht. Ein Unternehmen, das auch nur vier oder fünf dieser Schritte umgesetzt hat, überlebt die plötzliche Abwesenheit eines Entwicklers wochenlang, ohne die Fähigkeit zu verlieren, einen Fix auszuliefern oder ein Support-Ticket zu beantworten. Ein Unternehmen, das keinen davon umgesetzt hat, kann diese Fähigkeit an einem einzigen Nachmittag verlieren.

Die Reihenfolge oben entspricht ungefähr dem Verhältnis von Aufwand zu Nutzen. Wenn Sie diesen Monat nur eine Sache schaffen, beginnen Sie mit dem Passwort-Tresor. Wenn Sie drei schaffen, fügen Sie die zweiten Admin-Zugänge und das Deployment-Runbook hinzu. Der Rest kann über das folgende Quartal folgen, ohne irgendetwas zu stören, das Sie gerade ausliefern.

Hilfe bei den schwierigeren Teilen

Manche dieser Schritte lassen sich wirklich ohne externe Hilfe erledigen. Andere, besonders das Dokumentieren einer Architektur, die nie jemand aufgeschrieben hat, oder das Prüfen, welche geplanten Jobs tatsächlich wichtig sind, gehen schneller mit jemandem, der das schon gemacht hat und weiß, welche Fragen zu stellen sind. Unsere Arbeit im Bereich Code-Qualitäts-Beratung beginnt oft genau hier: herauszufinden, was derzeit nur im Kopf einer Person existiert, und es aufzuschreiben, bevor es dringend wird.

Wenn Ihr Unternehmen die ersten vierzehn Tage nach dem Verlust eines alleinigen Entwicklers schon durchlaufen hat, deckt unser Leitfaden zu den ersten zwei Wochen, nachdem Ihr einziger Entwickler gekündigt hat die Seite der Erholung ab.

Wenn Sie eine zweite Meinung wollen, welcher dieser sieben Schritte für Ihr Setup am wichtigsten ist, schreiben Sie uns an hello@wolf-tech.io oder schauen Sie sich an, wie wir arbeiten, auf wolf-tech.io. Die meisten Unternehmen brauchen nur ein oder zwei Gespräche, um zu wissen, wo sie anfangen sollen.