Eine Pflegestelle, und die Tickets kommen von selbst
Kundenserver müssen regelmäßig gewartet, neu gestartet und geprüft werden. Bei uns hing das lange an dem, woran es überall hängt: am Gedächtnis, an Kalendereinträgen, an Zuruf, an einem halbfertigen Ablauf in Power Automate. Die Folge war die übliche. Wartungen wurden vergessen, Healthchecks liefen unregelmäßig, und wer gerade im Urlaub war, hatte die Liste im Kopf mitgenommen.
Die Lösung war keine neue Liste. Es gab schon zu viele.
Eine Pflegestelle
Wir dokumentieren unsere Kunden in Hudu . Dort steht jeder Server als Asset, mit Rolle, Standort, Zugängen, Notizen. Der Grundgedanke war: Wenn das ohnehin die Stelle ist, an der ein Server beschrieben wird, dann gehört auch dorthin, wie oft er gewartet wird.
Also stehen die Wartungsdaten jetzt als Felder am Asset:
- wie oft gewartet und neu gestartet wird,
- ob und wie oft ein Healthcheck nötig ist,
- ob vorher etwas vorbereitet werden muss, und was,
- dazu die fertigen Befehle für Update und Wartung, die der Techniker sonst zusammensuchen würde.
Es gibt keine zweite Liste, kein Excel, keinen Kalender daneben.
Das Werkzeug dazu
Aus diesen Feldern macht ein kleines eigenes Werkzeug, HuduOps, die Tickets. Es holt die Assets regelmäßig aus Hudu, prüft jeden Werktag am Morgen, welche Systeme fällig sind, und legt für jedes ein Ticket in unserem Ticketsystem an. Ein Asset, ein Ticket. Im Ticket steht, was am Asset steht, und ein Link direkt in die Fernwartung des Geräts.
Was HuduOps bewusst nicht tut: Es führt nie selbst etwas auf einem Server aus. Es schreibt nur Tickets. Die Arbeit macht ein Mensch. Und es erinnert nicht, wenn ein Ticket liegen bleibt. Das macht das Ticketsystem.
Was wir dabei gelernt haben
Was im Asset steht, landet im Ticket. Das ist der eigentliche Hebel. Wer den Ablauf einer Wartung ins Asset schreibt, schreibt ihn in jedes künftige Ticket. Eine Anleitung irgendwo anders würde niemand öffnen, weil im Ticket kein Anlass dazu steht. Deshalb schreiben wir die Felder so, als würde sie ein Mensch lesen, denn genau das passiert.
Checklisten gehören in einen Artikel, nicht in dreißig Felder. Die Healthcheck-Checkliste ist ein zentraler Wissensartikel in Hudu, verknüpft mit den betroffenen Servern. HuduOps hängt verknüpfte Artikel automatisch ans Ticket. Einen Artikel pflegen statt dreißig Freitextfelder.
Neue Aufgaben fangen als Konfiguration an, nicht als Programmierung. HuduOps erkennt seine Felder am Namen, nicht am Typ des Assets. Legt man ein bekanntes Feld auf eine weitere Art von Asset, greift die Logik dort auch. So kamen die Docker-Stacks in die Wartung, ohne eine Zeile Code.
Wo es gehakt hat
Eine Automatik, die aus Stammdaten Tickets macht, hat eine eigene Art Fehler: Sie sind still.
- Ein Wert, den das Werkzeug nicht kannte, erzeugte kein Ticket. Bei einer Gruppe von Servern stand als Wartungsrhythmus „Mittwochs“, ein Wert, den die Planung nicht verstand. Keine Fehlermeldung, kein Ticket. Monatelang.
- Felder veralten, ohne dass es jemand merkt. In einem Hinweisfeld stand eine Version, die auf dem Server seit einem Update nicht mehr lief. Die Automatik prüft, ob ein Feld gefüllt ist, nicht ob es stimmt.
- Ein neues Feld wirkt erst, wenn es jemand anfasst. Ein frisch angelegtes Feld lieferte die Schnittstelle erst aus, nachdem es an einem Asset einmal gespeichert worden war. Ein neues Feature erzeugte deshalb zunächst gar nichts.
Die Lehre daraus ist dieselbe wie bei jeder Dokumentation: Eine Pflegestelle ist besser als fünf. Aber sie ist nur so gut wie das, was drinsteht, und das muss jemand ab und zu gegen die Wirklichkeit halten.
Wie das zu den anderen Beiträgen passt
Warum Dokumentation überhaupt die Grundlage ist, steht in Das Betriebswissen stand nur in den Köpfen . Welches Werkzeug wofür, in Drei Werkzeuge, drei Aufgaben . Und wie die Dokumentation im Projekt nebenbei entsteht, in Die Dokumentation, die nie fertig wird . Dieser Beitrag ist der Teil, wie wir es bei uns selbst machen.