Infrastruktur & Security · Methode
IT-Service-Management klingt nach Konzern: Prozesse, Gremien, Rollen, ein Regelwerk mit hunderten Seiten. Der Kern dahinter ist aber banal — und im Kleinen genauso gültig: Wer betreibt was, wie erfährt man von Problemen, und wie ändert man etwas, ohne den Rest umzuwerfen.
Die Frage ist nicht, ob man Betriebsdisziplin braucht, sondern wie viel davon sich lohnt, wenn die Organisation aus einer Person besteht. Vieles ist dann Ballast. Drei Dinge sind es nicht.
Was sich lohnt
Drei Bausteine, die auch allein tragen
Ein Verzeichnis dessen, was existiert
Welche Geräte, Dienste und Zugänge gibt es, wovon hängt was ab, wer ist zuständig. Klingt nach Karteikasten, beantwortet aber die erste Frage jeder Störung und jeder Sicherheitsprüfung: Was ist überhaupt betroffen?
Ein Ort für Störungen
Wo landet die Beobachtung „X ist komisch“, wenn gerade keine Zeit ist? Ohne festen Ort landet sie im Kopf und verfällt. Mit einem festen Ort entsteht nebenbei eine Historie — und die zeigt Muster, die einzeln nie auffallen.
Eine Spur der Änderungen
Was wurde wann warum geändert. Der wichtigste Datensatz bei jeder Fehlersuche, weil die meisten Störungen kurz nach einer Änderung beginnen — nur selten nach der, die man vermutet.
Diese drei greifen ineinander: Eine Störung verweist auf einen betroffenen Dienst im Verzeichnis, dessen letzte Änderung sich in der Spur findet. Erst zusammen ergeben sie mehr als drei Listen.
Was Ballast ist
Wo die Konzernfassung nicht passt
Ein großer Teil des klassischen Regelwerks löst Probleme, die aus Arbeitsteilung entstehen — Abstimmung zwischen Abteilungen, Nachweis von Zuständigkeit, Absicherung von Entscheidungen. Allein betrieben lösen sich diese Probleme von selbst und die Verfahren dagegen sind reine Kosten.
Getrost weglassen
- Gremien und mehrstufige Freigaben. Wer die Änderung durchführt, ist auch die genehmigende Instanz. Ein Freigabeschritt, der aus derselben Person besteht, ist Theater — außer er zwingt zu einer Denkpause vor riskanten Eingriffen. Dann heißt er besser Prüfliste.
- Dienstgütevereinbarungen mit Vertragscharakter. Sinnvoll ist die Zahl dahinter — wie lange darf was ausfallen. Der Vertrag mit sich selbst ist es nicht.
- Rollentrennung um ihrer selbst willen. Vier Rollen für eine Person erzeugen Verwaltungsaufwand ohne Kontrollgewinn.
- Vollständige Prozesslandschaften. Ein Prozess, den man einmal aufmalt und nie wieder anfasst, beschreibt nach einem halben Jahr eine Anlage, die es nicht mehr gibt.
Die nützliche Frage bei jedem Baustein lautet: Welches konkrete Problem löst er hier? Fällt die Antwort nur allgemein aus — „Ordnung“, „Professionalität“ —, ist es Ballast.
Werkzeuge
Womit man die drei Bausteine führt
| Werkzeug | Deckt ab | Wann es passt |
|---|---|---|
| Markdown-Dateien, Obsidian | Verzeichnis, Entscheidungen, lose Notizen | Am Anfang fast immer die richtige Wahl: kein Server, kein Schema, verlinkbar und durchsuchbar — und die Dateien bleiben lesbar, wenn das Programm einmal weg ist. |
| Git | Änderungsspur, Konfiguration, Begründungen | Wo die Konfiguration ohnehin versioniert ist. Die Commit-Historie ist die Änderungsspur, ohne Zusatzaufwand. |
| GLPI | alle drei in einem System | Sobald Verknüpfung zählt: Inventar, Störungen und Änderungen greifen ineinander, sodass sich „welche Änderungen betrafen diesen Dienst“ beantworten lässt. Quelloffen, dafür mit Pflegeaufwand. |
| Snipe-IT, NetBox | Inventar, spezialisiert | Wenn Geräte- beziehungsweise Netzdokumentation im Vordergrund steht und der Rest schon anderswo läuft. |
| Zammad, Redmine | Störungen und Aufgaben | Wenn Anfragen von anderen Menschen dazukommen — dann lohnt ein echtes Ticketsystem statt einer Liste. |
Der häufigste Fehler ist nicht die falsche Wahl, sondern die parallele: zwei Systeme für dieselbe Sache, weil das zweite anfangs bequemer war. Danach ist keines vollständig, und beide sind wertlos. Besser eines, das nur zu achtzig Prozent passt, aber ausschließlich benutzt wird.
Der Unterschied
Störung, Ursache, Änderung
Eine Unterscheidung aus dem großen Regelwerk lohnt sich allerdings auch im Kleinen, weil sie eine echte Falle vermeidet:
| Was | Ziel | Typischer Fehler |
|---|---|---|
| Störung | Dienst läuft wieder — schnell, notfalls provisorisch | Die Ursachensuche mit der Reparatur vermischen und beides schlecht machen |
| Ursache | Warum ist es passiert, und was verhindert die Wiederholung | Nach erfolgreicher Reparatur gar nicht mehr stellen — die Störung kommt wieder |
| Änderung | Etwas gezielt anders machen, mit Rückweg | Unter dem Deckmantel der Störungsbehebung nebenbei umbauen |
Der dritte Fehler ist der teuerste. Während einer Störung ist die Hemmschwelle niedrig und die Dokumentation lückenhaft — genau dann entstehen Zustände, die später niemand mehr erklären kann. Das Provisorium gehört deshalb ausdrücklich als solches notiert, mit dem Vorsatz, es zu ersetzen. Sonst wird es dauerhaft.
Maß halten
Nicht-Ziele aufschreiben
Der wirksamste Kniff gegen ausufernde Verfahren ist, die Grenzen ausdrücklich festzuhalten: Was wollen wir bewusst nicht? Ohne diese Liste wächst jedes Konzept, weil jede einzelne Ergänzung für sich sinnvoll klingt.
Konkret heißt das etwa: keine Hochverfügbarkeit, wo ein Ausfall von Stunden verkraftbar ist. Keine Überwachung, deren Meldungen niemand liest. Keine Automatisierung für Vorgänge, die zweimal im Jahr anfallen. Jedes dieser Nicht-Ziele spart dauerhaft Pflegeaufwand — und macht die Entscheidung nachvollziehbar, statt sie als Versäumnis erscheinen zu lassen.
Einstieg
Eine Woche, kein Projekt
-
Aufschreiben, was läuft
Eine Liste, eine Stunde, unvollständig. Sie wird nie fertig, und das ist in Ordnung — sie muss nur existieren und beim nächsten Anfassen ergänzt werden.
-
Einen Ort für Auffälligkeiten festlegen
Datei, Notizbuch, Ticketsystem — egal, solange es genau einer ist. Zwei Orte bedeuten null Orte.
-
Änderungen mitschreiben
Sechs Zeilen je Änderung, im selben Arbeitsgang. Nach drei Monaten hat man etwas, das man bei der ersten Störung tatsächlich benutzt.
-
Nach einem halben Jahr durchsehen
Was hat geholfen, was wurde nie gelesen? Das Ungelesene abschaffen. Diese Durchsicht ist der eigentliche Prozess — alles andere ist Fleißarbeit.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.