Change Records für Faule — Dokumentation von Veränderungen
Vielleicht kennen Sie das, ein Kunde oder eine AnwenderIn meldet sich bei Ihnen, weil irgendein Dienst plötzlich nicht mehr so funktioniert wie gewohnt. IT-Services sind komplexe in sich verzahnte Systeme und eine kleine Änderung an einer Stelle hat oft unerwartete Auswirkungen. Daher stellt sich bei solch unerwarteten Auswirkungen oft die Frage "Wer hat diese Änderung vorgenommen und warum?".
Change Records sind die Dokumentation von Änderungen an der IT, beantworten die Frage nach dem Wer und Warum und entstehen bei einem etablierten Change Management Prozess ganz nebenher. Der Change Management Prozess beziehungsweise die Change Enablement Pratice, wie es in ITILv4 nun heißt, verfolgt das Ziel die Zahl erfolgreicher Veränderungen an IT-Services zu maximieren. Ein formeller Prozess zur Abarbeitung von Veränderungen reicht normalerweise von der Registrierung von Änderungsanforderungen (Request for Change), deren Evaluierung inkl. Risikoanalyse über die Genehmigung und schließlich der Umsetzung. Dadurch wird sichergestellt, dass Veränderungen angemessen geplant, die damit einhergehenden Risiken entsprechend bewertet und gemanagt und alle betroffenen Personen rechtzeitig einbezogen werden. Mit Hilfe unseres RfC Tools lässt sich solch ein Prozess effizient abbilden. Mit Hilfe der Change Records, die im Verlauf dieses Prozesses entstehen, lassen sich Änderungen an IT-Services später nachvollziehen und bewerten.
Was aber ist mit den vielen Änderungen die MitarbeiterInnen von IT-Abteilungen laufend an IT-Services vornehmen? Schließlich besteht die Arbeit von Administratoren zu einem Großteil darin, Änderungen an IT-Services durchzuführen. Auch mit einer Vielzahl vorab genehmigter Standard Changes erhöht sich der Arbeitsaufwand erheblich, wenn wirklich für jede noch so kleine Änderung ein formeller Change Prozess abgearbeitet werden muss. Wenn die Dokumentation einer Änderung mehr Zeit in Anspruch nimmt als die Änderung selbst, stellt sich rasch die Frage nach dem Sinn. Viele Änderungen werden daher am Change Management Prozess vorbei implementiert und für manche Organisationen ist der erhöhte Arbeitsaufwand auch der Grund zur Gänze auf einen formellen Change Management Prozess zu verzichten. Leider werden so auch keine Change Records erzeugt und die eingangs gestellte Frage "Wer hat diese Änderung vorgenommen und warum?" lässt sich oft nicht mehr beantworten.
Change Records leicht gemacht
Um auch Änderungen zu dokumentieren, die am Change Management Prozess vorbei durchgeführt werden ist ein schlanker, leichtgewichtiger Prozess gefragt. Für alle die Zammad und i-doit einsetzen oder das noch planen, haben wir folgenden Vorschlag.
Aktivieren Sie zunächst das Objekt Ticket Typ
, das ist in der Standard Installationen von Zammad zwar vorhanden, aber zunächst noch deaktiviert.
Wenn nun ein Ticket der Ausgangspunkt für eine Veränderung ist, kann diesem Ticket der Typ Request for Change
zugewiesen werden und die Change Records, die wir nachfolgend erzeugen, können als Kind-Tickets mit dem Request for Change
verknüpft werden. Aber keine Sorge, wir können auch Change Records erzeugen, ohne zuvor ein Request for Change Ticket zu lösen.
Wir haben i-doit eine Schnittstelle zu Zammad spendiert, die es erlaubt i-doit Objekte in Tickets zu referenzieren. In i-doit lassen sich dann alle Tickets anzeigen die ein bestimmtes Objekt referenzieren. Diese Schnittstelle ist in den Standard Code von i-doit eingeflossen, so dass sie allen i-doit PRO AnwenderInnen zur Verfügung steht.
Die Konfiguration der i-doit Schnittstelle auf Zammad Seite findet sich unter den Integrationen.
Um mit Zammad auf einfache Weise Änderungen zu dokumentieren, legen Sie eine neue Gruppe an, zum Beispiel die Gruppe Change Records
und konfigurieren ein E-Mail Konto dessen Mails Tickets in dieser Gruppe erzeugen. Erstellen Sie dann einen Trigger, der Tickets in dieser Gruppe automatisch schließt, wir erklären später warum.
Wenn nun jemand eine Änderung an einem IT-Service beziehungsweise einer Service-Komponente vornimmt, muss sie oder er nur eine E-Mail an die entsprechende Adresse senden. Zur besseren Nachvollziehbarkeit bietet es sich an, neben einer kurzen Beschreibung und dem Grund für die Änderung einen Screenshot, ausgeführte Kommandos oder ein paar Logzeilen in die Mail zu kopieren. Möglich ist aber auch ein Backup von Settings vor und nach der Änderung als Attachment mitzusenden.
Damit Tickets automatisch mit i-doit Objekten verknüpft werden, haben wir eine kleine Applikation programmiert, die periodisch zum Beispiel als Cron-Job aufgerufen werden kann. Diese Applikation parsed den Titel von neuen Tickets und sucht nach i-doit Objekten, die im Titel in Eckigen Klammern aufgeführt werden. Eine E-Mail mit dem Betreff Eine Änderung an Zammad [Zammad, c03]
veranlasst dieses Script zum Beispiel alle i-doit Objekte mit dem Objekt-Titel Zammad
und c03
zu verknüpfen.
Da die Tickets auch von i-doit aus zu sehen sind, finden Sie Änderungen an den jeweiligen Komponenten schnell in Ihrer IT-Dokumentation.
Kleine Änderungen sind in diesem Fall abgeschlossen und fertig dokumentiert. Weil wir einen Trigger konfiguriert haben, der das Ticket geschlossen hat, brauchen wir uns eigentlich nicht mehr darum kümmern, außer es es ruft jemand an und wirft die Frage auf "Wer hat diese Änderung vorgenommen und warum?".
Wenn Sie einen Überblick haben wollen, welche Änderungen zum Beispiel in der letzten Woche durchgeführt wurden, erstellen Sie sich eine neue Übersicht, die auf diese Gruppe und den gewünschte Zeitraum filtert.
Fazit
Organisationen die bereits Zammad und i-doit im Einsatz haben behalten mit der beschriebenen Methode den Überblick über die durchgeführten Änderungen und können im Bedarfsfall die Frage "Wer hat diese Änderung vorgenommen und warum?" schnell beantworten. Schon die dadurch eingesparte Zeit sollte den minimalen Mehraufwand überwiegen. Zudem ist die Anzahl erfolgreich durchgeführter Änderungen eine wichtige Messgröße, die zu kennen ein wichtiges Steuerinstrument beim Management von IT-Services ist.