Bus-Faktor eins: Wie Sie erkennen, ob Ihr Unternehmen von einem einzigen Entwickler abhängt

Bus-Faktor-Risiko ist die Wahrscheinlichkeit, dass Ihre Software in dem Moment aufhört zu funktionieren, in dem eine bestimmte Person nicht verfügbar ist. Der Begriff stammt aus einer schonungslosen Frage, die unter Software-Teams zuerst gestellt wurde: Wie viele Personen müsste ein Bus erfassen, bevor das Projekt stillsteht? Lautet die ehrliche Antwort „eine", haben Sie einen Bus-Faktor von eins, und für ein wachsendes Unternehmen sagt diese Zahl mehr über Ihr Risiko aus als fast jede andere technische Kennzahl, weil sie nichts mit der Qualität des Codes zu tun hat und alles damit, was passiert, wenn diese eine Person weg ist, ob sie kündigt, krank wird oder zwei Wochen ohne Mobilfunkempfang verreist.

Die meisten Inhaber, die darauf stoßen, haben es nicht kommen sehen. Ein Entwickler hat jahrelang alles gebaut und betrieben, das Produkt lief, und niemand hatte einen Grund zu fragen, wer sonst einspringen könnte. Dann ging dieser Entwickler, und das Unternehmen stellte fest, dass niemand sonst einen Fix deployen, ein Passwort zurücksetzen oder erklären konnte, warum die Checkout-Seite eine ganz bestimmte Umgebungsvariable brauchte, um überhaupt zu starten.

Wie sich Bus-Faktor-Risiko zeigt

Bus-Faktor hat nichts damit zu tun, wie viele Entwickler auf der Gehaltsliste stehen. Ein Team aus fünf Personen kann trotzdem einen Bus-Faktor von eins haben, wenn nur eine von ihnen den Deployment-Prozess versteht, die funktionierenden Zugangsdaten für das Hosting-Konto besitzt oder als einzige jemals die Zahlungsintegration angefasst hat. Die Zahl beschreibt, wie konzentriert das Wissen ist, nicht wie viele Personen vorhanden sind.

Für eine nicht-technische Inhaberin oder einen Inhaber ist das klarste Zeichen meist das einfachste: Wenn Ihr Entwickler morgen ohne Vorwarnung verschwände, könnte dann jemand anderes sich einloggen, sehen, was läuft, und die Website eine Woche am Laufen halten? Wenn Sie sich nicht sicher sind, oder wenn die ehrliche Antwort „nein" ist, haben Sie Ihre Zahl schon.

Wo sich das in einem scheinbar gesunden Unternehmen versteckt

Ein paar Muster tauchen immer wieder in Unternehmen auf, die ihren Bus-Faktor auf die harte Art entdecken.

Deployments laufen über ein einziges Laptop. Kein dokumentierter Prozess, kein Skript, das jemand anders ausführen könnte, nur die Maschine einer Person mit den richtigen Keys und dem richtigen Griff aus dem Gedächtnis. Ist dieses Laptop nicht verfügbar, ist es auch die Fähigkeit nicht, einen Fix auszuliefern.

Passwörter leben in einem Kopf oder in einer Notizen-App auf einem Telefon. Hosting, Domain-Registrar, Datenbank-Admin, Zahlungsabwickler: Jedes davon braucht ein Login, und in einer Bus-Faktor-eins-Situation hält dieselbe Person die meisten oder alle davon, oft ohne dass ein gemeinsamer Tresor irgendetwas davon sichert.

Nichts ist aufgeschrieben. Nicht, weil der Entwickler nachlässig war, sondern weil Dokumentation sich nie dringend anfühlte, solange er oder sie noch da war, um Fragen direkt zu beantworten. Das Wissen existiert, nur eben nirgendwo, wo eine zweite Person es finden könnte.

Es gibt keinen zweiten Admin. Die meisten kleinen Unternehmen haben es nie geschafft, einen Ersatz-Inhaber für das Hosting-Konto, die Domain oder das Code-Repository anzulegen, weil es jahrelang keinen offensichtlichen Grund dafür gab.

Niemand hat eine Wiederherstellung getestet. Selbst wenn Backups oder Dokumentation existieren, hat niemand bestätigt, dass eine zweite Person damit das System wieder hochbringen kann. Ein Backup, das nie wiederhergestellt wurde, ist eine Hoffnung, kein Plan.

Die Zehn-Fragen-Prüfung zum Bus-Faktor

Beantworten Sie diese Fragen ehrlich, ohne vorher Ihren Entwickler um Hilfe zu bitten. Müssen Sie ihn fragen, ist das selbst schon Teil der Antwort.

1. Könnten Sie sich innerhalb einer Stunde in das Hosting-Konto einloggen, wenn Ihr Entwickler heute nicht erreichbar wäre?
2. Hat außer diesem einen Entwickler noch jemand Admin-Zugriff auf Ihren Domain-Registrar?
3. Könnte jemand anderes einen Code-Fix deployen, ohne ihn vorher anzurufen?
4. Gibt es einen Passwort-Manager oder Tresor, auf den eine zweite Person zugreifen kann, oder lebt der Zugang nur im Gedächtnis oder auf dem persönlichen Gerät einer einzigen Person?
5. Wissen Sie, was ein Deployment auslöst: ein manueller Befehl, ein Skript, ein Merge in einen bestimmten Branch?
6. Gibt es eine schriftliche Aufzeichnung darüber, was jeder geplante Job oder Cronjob tut, und was kaputtgeht, wenn er nicht mehr läuft?
7. Hat eine zweite Person schon einmal erfolgreich ein Backup wiederhergestellt, oder existiert das Backup ungetestet?
8. Wissen Sie, von welchen Drittanbieterdiensten (Zahlungsabwickler, E-Mail-Versand, externe APIs) das Produkt abhängt, und wer deren Zugangsdaten hält?
9. Würde jemand ein ablaufendes Zertifikat oder Abonnement in der Infrastruktur bemerken, bevor es die Kunden tun?
10. Könnten Sie alle diese Fragen beantworten, ohne dass Ihr Entwickler neben Ihnen sitzt?

Zwei oder weniger sichere Ja-Antworten bedeuten, dass Sie mit einem Bus-Faktor von eins fahren, ob Sie es bisher so genannt haben oder nicht.

Warum das passiert, auch wenn das Team auf dem Papier gut aussieht

Kleine und mittelgroße Unternehmen bauen dieses Risiko schrittweise auf, nicht absichtlich. Einen zweiten Entwickler einzustellen kostet Geld, das ein funktionierendes Produkt scheinbar noch nicht braucht. Dokumentation nimmt Zeit weg vom Ausliefern von Features, und es ist schwer zu begründen, aufzuschreiben, was eine Person bereits aus dem Kopf weiß. Zugriffskontrollen fühlen sich wie Overhead an, bis zu dem Tag, an dem sie das Einzige sind, das zwischen einem Unternehmen und einer ausgesperrten Produktionsumgebung steht.

Die Unternehmen, die am härtesten getroffen werden, wachsen meist am schnellsten, weil mehr Kunden und mehr Umsatz bedeuten, dass mehr davon abhängt, dass das System läuft, während das zugrunde liegende Setup mit diesem Wachstum nicht mitgehalten hat.

Was es kostet, wenn die eine Person weg ist

Die Kosten zeigen sich selten als einzelner dramatischer Ausfall. Häufiger ist es ein langsames Ausbluten: Ein Bug, der früher eine Stunde brauchte, braucht jetzt eine Woche, weil niemand weiß, wo er nachsehen soll, ein geplanter Job scheitert leise und niemand merkt es einen Monat lang, eine Kundenintegration bricht, und es gibt niemanden mehr, der sich erinnert, wie sie verdrahtet war. Wenn ein Unternehmen externe Hilfe holt, ist das akute Problem oft kleiner als das Chaos, das sich darum angesammelt hat: undokumentierte Entscheidungen, Zugangsdaten, die niemand findet, und eine Codebasis, die niemand, der aktuell daran arbeitet, versteht.

Die akute Version dieses Problems, die vierzehn Tage direkt nach der Kündigung eines alleinigen Entwicklers, haben wir in unserem Leitfaden dazu, was zu tun ist, wenn Ihr einziger Entwickler kündigt behandelt. Wenn Sie eine Codebasis übernehmen, die jemand anderes ohne nennenswerte Dokumentation gebaut hat, deckt unser 30-Tage-Plan für den sicheren Einstieg in eine undokumentierte Codebasis das von der anderen Seite der Übergabe ab.

Die Zahl senken, bevor sie zur Krise wird

Sie müssen Ihre Engineering-Mannschaft nicht verdoppeln, um einen Bus-Faktor von eins zu beheben. Ein gemeinsamer Passwort-Tresor, ein zweiter Admin für jedes wichtige Konto und eine schriftliche Aufzeichnung, wie Deployments tatsächlich ablaufen, decken den Großteil des Risikos bereits von allein ab. Ein Code-Qualitäts-Review kann außerdem aufdecken, was undokumentiert und fragil ist, bevor es dringend wird, und unsere Arbeit im Bereich Code-Qualitäts-Beratung ist genau darauf aufgebaut: herauszufinden, was derzeit nur eine Person versteht, und es aufzuschreiben und zu teilen, bevor Sie es brauchen.

Wenn Sie eine zweite Meinung dazu wollen, wie exponiert Ihr Unternehmen tatsächlich ist, schreiben Sie uns an hello@wolf-tech.io oder erfahren Sie mehr darüber, wie wir arbeiten, auf wolf-tech.io. Ein kurzes Gespräch reicht meist schon aus, um zu wissen, ob Ihr Bus-Faktor eins ist oder etwas Sichereres.