Deployment-Wissen und Vertretbarkeit
Busfaktor 1 im Deployment
Wie Pairing, beobachtete Durchläufe, knappe Runbooks und gezielte Automatisierung aus persönlichem Wissen einen vertretbaren Prozess machen.
Die kurze Antwort
Busfaktor 1 im Deployment liegt vor, wenn nur eine Person den Release zuverlässig ausführen oder Störungen dabei einordnen kann. Typische Zeichen sind implizite manuelle Schritte, persönliche Zugänge, lokale Werkzeuge, fehlende Runbooks und keine erprobte Vertretung.
Das ist eine Systemeigenschaft, kein persönliches Versagen. Ziel ist, Wissen, Berechtigungen und Automatisierung getrennt sichtbar zu machen und den Prozess schrittweise vertretbar zu gestalten.
Entscheidungsrahmen
Wissen beantwortet, ob eine zweite Person Ablauf, Risiken und Abbruchkriterien versteht. Berechtigungen beantworten, ob sie den Ablauf tatsächlich ausführen darf.
Automatisierung beantwortet, welche wiederholbaren Schritte das System zuverlässig übernehmen kann. Sie ersetzt weder Kontextwissen noch angemessene Freigaben.
Hinweise aus dem Systemalltag
- Entscheidende Schritte stehen nur in Notizen, Shell-Historien oder im Gedächtnis einer Person.
- Der Ablauf benötigt persönliche Konten, lokale Dateien oder Werkzeuge auf einem einzelnen Rechner.
- Eine Vertretung kann den Normalfall ausführen, kennt aber keine Abbruch- und Wiederherstellungskriterien.
- Konfiguration wird während des Deployments manuell verändert und ist danach nicht vollständig rekonstruierbar.
- Releases werden um die Verfügbarkeit einer bestimmten Person geplant.
Daten und Voraussetzungen
- Ein beobachteter Durchlauf mit Zeitstempeln, Eingaben, Entscheidungen und Abweichungen.
- Eine getrennte Inventur von Wissen, Rollen und Berechtigungen sowie automatisierten Schritten.
- Ein geeigneter Release, den eine zweite Person unter realistischen Bedingungen übernehmen kann.
Vorgehen in Schritten
- Die verantwortliche und die vertretende Person führen den Ablauf zunächst gemeinsam aus und erklären Entscheidungen während des Deployments.
- Ein knappes Runbook hält Voraussetzungen, Schritte, Prüfungen, Abbruchkriterien und Rückfallweg fest.
- Persönliche Zugänge werden durch geeignete Rollen und nachvollziehbare Freigaben ersetzt, ohne Zugangsdaten zu dokumentieren.
- Zuerst werden häufige, risikoarme und eindeutig prüfbare Schritte automatisiert.
- Eine zweite Person führt ein Deployment aus. Beobachtete Lücken fließen in Runbook, Berechtigungen und Automatisierung zurück.
Ergebnis der Analyse
- Mindestens zwei Personen können den Standardablauf mit denselben freigegebenen Artefakten und Prüfschritten ausführen.
- Offene Risiken sind nach Wissen, Berechtigungen und Automatisierung getrennt priorisiert.
Grenzen und Abgrenzung
- Ein Runbook allein beweist keine Vertretbarkeit. Entscheidend ist ein ausgeführter Durchlauf durch eine zweite Person.
- Vollständige Automatisierung ist nicht die einzige Lösung. Seltene Entscheidungen können dokumentiert und kontrolliert manuell bleiben.
- Personenbezogene Zugangsdaten, Geheimnisse und produktive Kundendaten gehören nicht in Runbooks oder Quellcode.
Prüffragen
- Eine zweite Person versteht Ablauf und Abbruchkriterien.
- Sie besitzt passende, nachvollziehbare Berechtigungen.
- Lokale Werkzeuge und Dateien sind ersetzt oder reproduzierbar beschrieben.
- Das Runbook enthält Prüfungen und Rückfallweg, aber keine Geheimnisse.
- Ein Deployment durch die Vertretung wurde beobachtet und ausgewertet.
Quellen und Einordnung
Die Quellen stützen die technische Einordnung oder beschreiben den Umfang einer verknüpften Leistung. Projektergebnisse und Modellannahmen sind keine allgemeine Wirkungszusage.