ITIL Baselines - Der Weg zur verlässlichen IT-Dokumentation

Das Konzept der “Baseline” ist fest in der IT Infrastructure Library (ITIL) verankert. Selbsterklärend ist es nicht. Und wenn wir versuchen, den Begriff mit “Basislinie” oder “Messbasis” einzudeutschen, wird es nicht klarer. Darum schauen wir uns das Konzept der ITIL Baselines an. Wir zeigen Ihnen, was es damit aufsich hat und wie Sie es mit i-doit und der Netzwerk-Discovery umsetzen können.

Woher kommt das Konzept der Baseline?

Zuerst wurde der Begriff des Baselining in Großbritannien Ende der 1980er Jahre benutzt. Damals wurde er in der Version 1 der IT Infrastructure Library (ITIL) niedergeschrieben. Und auch heute noch taucht der Begriff an mehreren Stellen der ITIL-Literatur auf.

Welche Arten von Baselines gibt es?

Die ITIL-Dokumente beschreiben nicht nur eine Art der Baseline, sondern gleich drei.

• Die ITSM-Baseline bildet den Ausgangspunkt von Maßnahmen zur Verbesserung von Services, ab dem die Wirksamkeit dieser Maßnahmen gemessen wird.
• Die Performance-Baseline wird als Startpunkt für die Messung und spätere Bewertung der Performance von Services definiert.
• Die Configuration-Baseline wird als bekannter und definierter Zustand einer Konfiguration beschrieben. Zu diesem kann z. B. zurückgekehrt werden, wenn Changes oder Releases fehlschlagen. Hier werden Snapshots erwähnt. Es wird darauf hingewiesen, dass Baselines einem manuellen oder digital erhobenem Snapshot entsprechen. Nicht jeder Snapshot ist jedoch auch eine Baseline.

Bis zu diesem Punkt klingt alles noch einfach. Im Folgenden beschäftigen wir uns hauptsächlich mit der Configuration Baseline und ihrer praktischen Anwendung im IT-Betrieb.

Bevor wir dies tun, werfen wir noch einen Blick auf den Begriff “Configuration”. Wenn Sie verstanden haben, worum es sich dabei handelt, werden die weiteren Beispiele noch anschaulicher.

Der Begriff “Configuration”

Was im ersten Augenblick nach einer Übersetzung des deutschen Wortes “Konfiguration” aussieht, beinhaltet viel mehr. Denn es handelt sich nicht einfach um eine definierte Zusammenstellung von Hard- und Softwarekomponenten.

Das ITIL-Glossar sagt an dieser Stelle:

“Eine allgemeine Bezeichnung für eine Gruppe von Configuration Items, die zusammen für die Erbringung eines IT-Service oder eines umfangreicheren Teils eines IT-Service eingesetzt werden. Als „Konfiguration“ werden darüber hinaus die Parametereinstellungen für ein oder mehrere CIs bezeichnet.“

Diese Definition wirkt auf den ersten Blick mehr verwirrend als aufklärend. Doch liest sie sich komplizierter als sie ist. Denn sie besagt, dass 

• sowohl die Eigenschaften eines einzelnen Configuration Items oder auch 
• die Kombination mehrerer Configuration Items, die man für einen Service benötigt

eine Konfiguration darstellen. Ein Configuration Item (CI) ist schließlich die kleinste mögliche Dokumentationseinheit, sozusagen das Atom im Universum der IT-Dokumentation. i-doit bezeichnet diese CIs als “Objekte”.

Die wichtige Frage: Ist der aktuelle Zustand auch der Soll-Zustand?

Möchten Sie eine CMDB im Unternehmen einführen und erstmalig mit Daten beladen, sollten Sie zunächst einige Dinge klären. Allen voran ist die Frage zu beantworten, ob der aktuelle Zustand der IT-Infrastruktur auch tatsächlich “stimmt”. Diese Frage sollte leicht zu beantworten sein. Fragen Sie an verschiedenen Stellen im Unternehmen nach, ist die Antwort jedoch nicht mehr so eindeutig, wie Sie vielleicht denken.

Dazu ein Beispiel:

Ein Unternehmen führt eine neue CRM-Software ein. Für dieses Projekt wurde ein Application Server mit 8 GB RAM angefordert. Eine virtuelle Maschine wurde von der IT-Abteilung wie vereinbart bereitgestellt und an die Fachabteilung verrechnet.

In der Projektdokumentation ist der Server in der ursprünglichen Konfiguration beschrieben. Niemand hat diese verändert. Das PDF-Dokument kam von einem externen Dienstleister. Hier handelt es sich um eine Soll-Dokumentation zum Zeitpunkt des Projektstarts. Alle Projektbeteiligten waren zufrieden. SOLL und IST waren gleich.

Nach Abschluss des Projektes wird ein Softwareupdate eingespielt. Es hat sich herausgestellt, dass dafür der Speicher des Application Servers aufgerüstet werden muss. Ihr freundlicher Administrator hat das mit wenigen Mausklicks rasch erledigt. Dem virtuellen Server sind nun 16GB RAM zugewiesen.

Das System läuft zur Zufriedenheit der Anwender. Doch die dokumentierten Informationen driften auseinander. Streng genommen ist das SOLL immer noch mit 8 GB definiert. Die Fachabteilung kennt unter Umständen nicht einmal die Schwierigkeiten, die beim Update aufgetreten sind. Worauf beziehen sich nun die weiteren Prozesse?

Der Administrator wird sagen: “Auf das IST!”.
Idealerweise erinnert er sich im Fehlerfall daran, dass er seinerzeit den Speicher des Application Server auf 16 GB erweitert hat.

Die Fachabteilung (und vielleicht der externe Dienstleister) wird sagen, dass die SOLL-Dokumentation maßgeblich ist. Schließlich war diese Konfiguration der Stand, den alle kannten.

Sie sehen: schon eine Kleinigkeit kann bedeutende Auswirkungen haben.

Nicht ausreichende Dokumentation des SOLL – Zustands

Was geschieht im Fall eines (Aus)Falles?
Bezieht sich der Fehlerbehebungsprozess auf das alte (und einzige) Dokument? Dann stellen Sie – formal vollkommen korrekt – nach einem Ausfall eine alte SOLL-Konfiguration wieder her. Die Applikation funktioniert jedoch nicht. Die Folge sind unnötige Recherche und Zeitverlust bis zur Wiederherstellung des CRM-Service.

Der Grund ist klar: eine nicht ausreichende Dokumentation des SOLL-Zustands.

Eine Diskrepanz im Arbeitsspeicher eines Servers kann bereits zu einem bedeutenden Problem führen. Weitaus kostenintensiver für das Unternehmen können jedoch kleine Änderungen von Konfigurationen sein, wenn sie das Lizenzmanagement berühren. Und wenn erst sicherheitsrelevante Aspekte ins Spiel kommen, können die Folgen einer falschen SOLL-Konfiguration katastrophal sein.

SOLL oder IST ist meist nicht definiert

Den Aufbau und die laufende Pflege einer CMDB übernimmt in der Regel ein Admin. Als Techniker muss man davon ausgehen, dass der aktuelle Status im Netzwerk auch der erwünschte Zustand ist. Schließlich läuft das System. Das bringt ein Problem mit sich. Denn weder IST noch SOLL sind definiert. Es geht einzig um den funktionalen Status. Dieser wird als Grundlage einer Wiederherstellung im Fehlerfall angenommen.

Am einfachsten wird ein solcher Status mit Snapshots von virtuellen Umgebungen oder mit Backups zu fixen Zeitpunkten erstellt. Diese Snapshots sind vermeintlich funktional. Wir haben uns daran gewöhnt, sie nicht weiter zu dokumentieren.
Das gilt gleichermaßen für die Konfiguration eines Netzwerkes. Auch die Software, die auf Clients installiert ist, wird meist vernachlässigt. Dabei spielt es auch keine Rolle, wie sie dorthin gekommen ist. Im besten Fall steht im Backup-Log ein Einzeiler: “Full Backup vom 29.02.2020.”

Fehlende Dokumentation und die Fachabteilungen

Aber wie sehen das die Verantwortlichen der verschiedenen Abteilungen? Wie gehen Budgetverantwortliche, die Buchhaltung, oder die Prozessverantwortlichen mit nicht vorhandener Dokumentation um?

Dokumentieren wir den IST-Zustand nur mittels Snapshot, verpassen wir unter Umständen etwas Wesentliches. Jemand muss für die Differenz der im erwähnten Beispiel zugewiesenen 8GB auch bezahlen. In anderen Fällen muss eine Lizenz angepasst werden. Die SOLL-Dokumentation muss aktualisiert und an die richtigen Personen verteilt werden. Möglicherweise ist auch herauszufinden, warum unser Änderungsprozess es zulässt, dass vom SOLL zum IST plötzlich Unterschiede bestehen.

Das alles ist Grund genug, um im Rahmen eines Projektes über den Umgang mit Versäumnissen und Ungereimtheiten der Vergangenheit zu sprechen. Aber es ist auch Grund genug, eine für alle Beteiligten klar definierte Linie zu setzen. Eine klare Basis muss geschaffen werden, auf die hingearbeitet wird und von der fort gearbeitet wird.

Die Baseline: Gleichstand von Technik und Organisation

Eines dürfte schnell klar werden: Der technische Snapshot allein ist zu wenig. Wir müssen diesen auch Nachbearbeiten, anpassen und mit zusätzlichen Informationen anreichern können. Und in Zukunft wollen wir ihn planen. Und damit sind wir angekommen.

Hier ist die Baseline.

Wir ziehen einen Strich und sagen: Die Ebenen Buchhaltung, Technik, Lizenzen und Dokumentation haben sich auf diese eine Wahrheit geeinigt. Das ist das neue SOLL. Abweichungen, egal aus welchem Grund, darf es nicht geben. Wenn doch, wollen wir sie auch herausfinden und einer Betrachtung unterziehen!

Die Planung der Baselines

Eine Baseline kann durch vieles ausgelöst werden. In unserem Beispiel hat das neue Release der CRM-Software den Grund geliefert, den Speicher des Servers zu erweitern. Damit benötigen wir auch mehr Speicher beim Backup und mehr Zeit beim Rücksichern. Eventuell ist beim Update auch eine neue Version des Webservers installiert worden oder PHP hat eine Aktualisierung erfahren.

Wurde auch die Datenbank auf den neuesten Stand gebracht? Dann führt dies automatisch bei allen anderen Anwendungen, die am Datenbankcluster mitlaufen, zu Nacharbeiten. Alles zusammen genommen umfasst unsere Baseline “CRM Update Frühjahr 2020” also viele einzelne Punkte. Diese hängen direkt miteinander zusammen und machen eine betriebsinterne Baseline aus. Diese Baseline ist nun unser neues Plan-Soll. Für die Verrechnung, für Backup-Konzepte, das Lizenzmanagement, den Störungsfall und letztlich für unsere gesamte  IT-Dokumentation.

Start der Configuration Control

Die erste Baseline definieren Sie bereits mit der Erstaufnahme von Daten in die CMDB. Dabei ist es unerheblich, ob das nun ein offizieller Anlass ist oder nicht. Alle anderen Informationen und Dokumentationen sind von nun an überholt. Sie dürfen streng genommen nur noch als historisches Nachschlagewerk verwendet werden. Sie könnten sie z. B. zum entsprechenden Configuration Item als Hyperlink oder Dokument hinzufügen.

Ab jetzt ist Ihre CMDB das führende System für alle ITSM-Prozesse. Halten Sie sich vor Augen, dass das in die CMDB aufgenommene IST für die Folgeprozesse dem SOLL entspricht. Ausnahme: Sie verifizieren es sofort und passen es gegebenenfalls an.

Diese Ausnahme ist wichtig. Sie zwingt uns dazu, darüber nachzudenken, wie viele Informationen wir auf einmal in die CMDB übertragen. Übernehmen wir direkt alle Daten oder nur das, was wir auch zeitlich vertretbar verifizieren und korrigieren können?

Bei dieser Überlegung ist zu beachten, dass ab Aufnahme in die CMDB alle darin befindlichen CIs unter “Configuration Control” stehen.

Das bedeutet für unser erwähntes Beispiel:

Der Change Management Prozess muss dafür Sorge tragen, dass die gleiche Situation beim nächsten Aufrüsten des Speichers nicht nochmals auftritt. Das gilt für das Überarbeiten der SOLL-Dokumentation, das Auslösen der Verrechnung und auch für die IST-Dokumentation. Welche Daten “einfach so” überschrieben werden dürfen, muss vorher festgelegt sein. Doch dazu später mehr.

ITIL kennt im Übrigen für den Prozess der Erstaufnahme in die CMDB einen eigenen Begriff und definiert diesen wie folgt:

Configuration Identification
Die Aktivität, die für die Sammlung von Informationen zu Configuration Items und deren Beziehungen sowie für das Laden dieser Informationen in die CMDB verantwortlich ist. Bei der Configuration-Identifizierung werden darüber hinaus die CIs selbst mit Bezeichnungen versehen, um eine Suche nach den entsprechenden Configuration Records durchführen zu können.

Baseline mit Discovery-Tools

Die nächste Aufgabe wartet. Sie müssen kurzfristig einen Snapshot der jetzt vorgefundenen Konfiguration anfertigen. Das ist auch bei einem kleinen Netzwerk eine nicht zu unterschätzende Aufgabe. In einem relativ kurzen Zeitfenster sollen die Konfigurationen aus den beteiligten Netzwerkknoten ausgelesen und in eine Datenbank eingegeben werden. Während der Erstaufnahme sollten auch keinerlei Änderungen stattfinden.

Die Aufgabe klingt einfacher als sie ist. Die beteiligten Mitarbeiter müssen sich in die einzelnen Geräte einloggen. Anschließend müssen sie die Konfigurationsdaten identifizieren und auslesen und diese strukturiert (und standardisiert) in einer Datenbank ablegen. Das klingt nach einer Aufgabe, die manuell nur mit hohem Zeitaufwand und einem ausgefeilten Qualitätssicherungsprozess zu leisten ist. Die Korrekturen garantiert auftretender Tippfehler sollten Sie von vornherein mit einkalkulieren.

Diese Informationen auch nur einige Tage aktuell zu halten ist eine anspruchsvolle Herausforderung. Zum Glück kommt hier die Automatisierung in Form von Netzwerk-Discovery ins Spiel. Als Werkzeug der Wahl nutzen wir hier JDisc. Damit sind wir bestens aufgestellt, denn der Hersteller kümmert sich darum, die neuesten Geräte und Standards zeitnah zu unterstützen.

Netzwerk-Discovery mit JDisc

Lassen wir JDisc auf unser Netzwerk los, wird jeder aus DNS, Directory oder ARP-Caches gefundene Netzwerkknoten verifiziert. Mit unterschiedlichen Methoden werden die Konfigurationen der Geräte, die in der Firmware bzw. dem Betriebssystem gespeichert sind, ausgelesen. 

Wir gewinnen hierdurch in erster Linie Zeit. Unterschätzen Sie jedoch auch nicht den Qualitätsfaktor. So schnell und fehlerfrei tippt kein Mensch. In Tabellenform werden die Geräte anschließend aufgelistet, können analysiert, gruppiert und nach gewissen Eigenschaften und Konfigurationen sortiert werden.

Gruppen in JDisc bilden

Wir haben die Angewohnheit, in einer Menge von Dingen nach gleichartigen Merkmalen zu suchen, sie zu gruppieren. Diese Angewohnheit können wir bei den durch JDisc erhaltenen Daten nutzen. So können wir den gewaltigen Datenmengen im Netzwerk Herr werden.

Gleichartige Assets wie Notebooks, PCs oder IP-Telefone fassen wir zu Gruppen zusammen. Auch aus IP-Netzen, die geografisch strukturiert sind, werden eigene Scan-Gruppen gebildet. Mit der Kombination aus beidem erhalten wir dynamische Gruppen. So könnten wir Clients in Frankreich und Telefone in den USA gruppieren.

Wir strukturieren also verarbeitbare Datenblöcke bereits im Discovery-Tool. So ermöglichen wir eine Vorqualifizierung der Daten, noch bevor sie in die CMDB gespielt werden. In JDisc können sie vorab auf Vollständigkeit geprüft und dann auf einmal in die CMDB übernommen werden. Die in i-doit integrierte Schnittstelle zu JDisc kann mit dessen Gruppen umgehen.

Nacharbeiten und Verifizierung

Nun beginnen die Nacharbeiten in der CMDB. Die betreffen vor allem das Anreichern mit Daten, die nicht über die Discovery identifiziert werden konnten. Hierzu zählen Verträge, buchhalterische Werte und eindeutige Labels. Diese Arbeit kann im Team verteilt und von entsprechenden regionalen Betreuern abgewickelt werden.

Wichtig: SOLL und IST sollten verifiziert werden.
Sind SOLL und IST nun verifiziert, vollständig und für alle Folgeprozesse freigegeben, sollten Sie das auch bekanntgeben. Wie sollen Ihre Kolleginnen und Kollegen erfahren, dass es sich um verifizierte Daten handelt?

Auch diese Information wird im Datenbestand kenntlich gemacht. Wir benötigen eine Notiz im Verlauf des Lebenszyklus. Das Stichwort lautet hier “Logbuch”.

Erstellen einer Baseline in i-doit

Als “Notiz” bieten sich die Workflows an, die i-doit mitbringt. Ein eigener Workflow-Typ Baseline ist schnell erstellt. Die Daten, die aus JDisc in die CMDB importiert wurden, werden zu einer Baseline hinzugefügt. Ergänzt werden Sie durch einen aussagekräftigen Text. 

Ist der vereinbarte Vorgang durchgeführt, wird die Aufgabe auf “erledigt” gesetzt. Jede Aktion führt zu einem Eintrag bei den betroffenen Objekten. Der Screenshot zeigt uns die LOG-Einträge eines einzelnen Objekts, die für alle späteren Leser nachvollziehbar sind.

Der Prozess zur Datenübernahme von Assets

Wenn Daten in die CMDB übernommen werden sollen, folgen wir einem festgelegten Prozess. Dieser kann wie folgt aussehen:

1. Ankündigung einer Änderung. Hinweis, dass SOLL und IST voneinander abweichen können.
2. Änderungen an den Geräten werden durchgeführt (Update, neue Hardware etc.)
3. Scan mit JDisc und Übernahme des neuen IST
4. Übernahme des neuen IST in die CMDB
5. Verifizieren der Daten in der CMDB, SOLL und IST werden gleichgesetzt
6. Eventuelle Anpassungen im IST durchführen. Punkt 3 wiederholen.
7. Abschließen der Änderungen. Die neue Configuration Baseline ist nun gültig und steht ab sofort unter Configuration Control. Änderungen dürfen nun nicht mehr stattfinden.

Das alles klingt bisher sehr einfach. Es könnte der Eindruck entstehen, dass das Zusammenspiel von CMDB und Discovery alle Probleme löst. Doch dies ist nicht so, wie sich noch zeigen wird.

Eine Konfiguration ist mehr als Discovery leisten kann

Ziehen wir noch einmal das Beispiel unseres CRM-Systems heran. Auf den ersten Blick haben wir nun alle zugehörigen Daten in die CMDB übertragen. Das System funktioniert und die Anwender sind zufrieden.

Die CMDB kann Ihnen jedoch das Denken nicht abnehmen. Wenn wir wissen wollen, was zum IT-Verbund des CRM-Services gehört, kann uns die CMDB nur bedingt Antwort geben. Hier ist noch mehr der Mensch als die Maschine gefragt.

Bereits die Definition der Configuration weist darauf hin, dass es nicht nur um die Eigenschaften einzelner CIs geht. Auch die Abhängigkeiten zwischen ihnen sind von Bedeutung. Es geht um den Verbund mehrerer technischer und von Menschen erbrachter Dienste. Dieser Verbund ermöglicht erst den durch die Anwender genutzten Service. Wie kann nun die Discovery dabei helfen, eine Service-Konfiguration festzustellen? Und wo liegen die Grenzen dieser Technologie?

Die Discovery kann erkennen, nicht interpretieren

Auch die Discovery kennt entsprechende Hinweise. Das System kann laufende Dienste, Services und Daemons erkennen. Das bedeutet jedoch nicht, dass ein Dienst, der auf einem Server läuft, auch erwünscht oder notwendig ist. Auch wissen die Dienste in der Regel nicht, für wen sie angeboten werden.

Discovery der Netzwerk-Topologie