Der Bestand: was Sie eigentlich betreiben
Die Liste, die es fast nie gibt — und ohne die jede weitere Frage unbeantwortbar ist.
Vor jeder Sicherung, jedem Alarm und jedem Notfallplan steht eine Frage, die überraschend oft nicht beantwortet werden kann: Was betreiben wir eigentlich? Nicht „welche Software haben wir gekauft“, sondern: Welche Dinge laufen, für die jemand zuständig ist, wenn sie stehen?
Das durchgehende Beispiel
Kurs 1 hat die Anwendung „Ausleihe“, Kurs 2 den Agenten „Beleg“. Dieser Kurs hat kein Beispielprogramm — sein Gegenstand ist ja keines. Sein Beispiel ist ein Bestand: drei Anwendungen auf einem Server, eine Kollegin als Vertretung, und ein Urlaub vom 14. bis 28. Juli.
Die drei Anwendungen sind mit Absicht so gewählt, dass sie unterschiedlich ausfallen: Die Website merkt jeder sofort, aber es kostet fast nichts. Die Ausleihe legt den Betrieb lahm. Der Belegagent fällt tagelang niemandem auf — und das ist der teuerste der drei Fälle.
Ihre eigene Liste
Legen Sie jetzt eine Datei an — sie wird später das Betriebsbuch (Station 09). Eine Zeile je Ding, das läuft:
# Was wir betreiben | Anwendung | Adresse | Zweck | Wer braucht sie | Ausfall merkt man | |-----------|--------------------|------------------------|-------------------|-------------------| | website | example.de | Außendarstellung | alle | sofort | | ausleihe | ausleihe.apps… | Geräteausleihe intern | Werkstatt, 6 Pers.| innerhalb 1 Std. | | beleg | kein Webzugang | Belegeingang nachts | Buchhaltung | nach Tagen |
- Die Liste ist vollständig, wenn Sie zu jeder Zeile sagen können
- Prüfliste Station 00
WarumWarum die Liste öfter fehlt, als man denkt
Ein Bestandsverzeichnis entsteht nicht von selbst, weil jede einzelne Anwendung zu einem Zeitpunkt entstanden ist, an dem sie die einzige war. Beim ersten Ding schreibt niemand eine Liste mit einer Zeile. Beim zweiten erinnert man sich an beide. Beim vierten fehlt eines — und zwar zuverlässig das, das gut funktioniert und deshalb nie Aufmerksamkeit bekommt.
Der zweite Grund ist die Frage, was überhaupt dazugehört. Eine Web-Anwendung ist offensichtlich. Ein nächtliches Skript, ein Cron-Eintrag, ein Datenbankdienst, den nur eine andere Anwendung benutzt, ein Uptime-Kuma, das die anderen überwacht — all das läuft, all das kann ausfallen, und nichts davon hat eine Adresse, die jemand im Browser aufruft.
Die brauchbare Abgrenzung ist deshalb nicht „was hat eine Oberfläche?“, sondern: Wofür wäre jemand zuständig, wenn es stillstünde?
TiefeDie Liste als Datei statt als Tabelle — und warum das eine Rolle spielt
Die naheliegende Form ist eine Tabellenkalkulation. Sie hat drei Nachteile, die im Ernstfall zählen: Sie liegt meist in einem Cloudordner mit eigenem Zugang, sie hat keine Historie, und sie wird von niemandem angefasst, der gerade an der Anwendung arbeitet.
Eine Markdown-Datei im Repository hat die umgekehrten Eigenschaften: Sie ist für jeden erreichbar, der ohnehin am Code arbeitet, sie wird beim Ändern mit versioniert (git log betriebsbuch.md zeigt, wann zuletzt jemand etwas nachgetragen hat), und sie ist Teil der Sicherung, weil das Repository ohnehin an zwei Orten liegt.
Der Preis ist, dass sie hässlicher aussieht. Für ein Dokument, das im Ernstfall gelesen wird und sonst nie, ist das der richtige Tausch.