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?
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”
Das ITIL-Glossar sagt an dieser Stelle:
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
- der 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?
Dazu ein Beispiel:
Idealerweise erinnert er sich im Fehlerfall daran, dass er seinerzeit den Speicher des Application Server auf 16 GB erweitert hat.
Sie sehen: schon eine Kleinigkeit kann bedeutende Auswirkungen haben.
Nicht ausreichende Dokumentation des SOLL – Zustands
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
Fehlende Dokumentation und die Fachabteilungen
Die Baseline: Gleichstand von Technik und Organisation
Hier ist die Baseline.
Die Planung der Baselines
Start der Configuration Control
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.
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.
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
Netzwerk-Discovery mit JDisc
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
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.
Nacharbeiten und Verifizierung
Wichtig: SOLL und IST sollten verifiziert werden.
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
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
- Ankündigung einer Änderung. Hinweis, dass SOLL und IST voneinander abweichen können.
- Änderungen an den Geräten werden durchgeführt (Update, neue Hardware etc.)
- Scan mit JDisc und Übernahme des neuen IST
- Übernahme des neuen IST in die CMDB
- Verifizieren der Daten in der CMDB, SOLL und IST werden gleichgesetzt
- Eventuelle Anpassungen im IST durchführen. Punkt 3 wiederholen.
- 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.
Eine Konfiguration ist mehr als Discovery leisten kann
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.
Die Discovery kann erkennen, nicht interpretieren
Discovery der Netzwerk-Topologie
Die Dokumentation von SOLL und IST-Zuständen
Wir trennen die funktionale Beschreibung und SOLL-Dokumentation von der mit JDisc identifizierten IST-Konfiguration. Und wir definieren folgende Regeln:
- Die SOLL-Konfiguration (in der Grafik die vier oberen Configuration Items) darf nur im Zuge einer Baseline-Planung verändert werden.
- Die IST-Konfiguration (die realen Assets) werden ausschließlich durch Discovery identifiziert und überschrieben. Der oben dargestellte Workflow sorgt für Ordnung.
- Damit wir einen Bezug zwischen SOLL und IST herstellen, diesen analysieren und vergleichen können, verwenden wir die drei (rot dargestellten) manuell herzustellenden Verbindungen.
- Discovery-Läufe können beliebig oft durchgeführt werden. JDisc holt sich regelmäßig die IST-Daten aus dem Netzwerk.
- Es sind keine komplexen Regeln beim Überschreiben von Asset-Daten in der CMDB nötig.
- Die Dokumentation des SOLL-Zustands kann unabhängig vom IST zeitgleich in der CMDB stattfinden.
- Eine zeitliche Trennung von SOLL- und IST-Dokumentation ist möglich. Denkbar ist ein Start mit der Übernahme von Discovery (IST), danach Modellieren des SOLL-Zustands. Der umgekehrte Weg ist ebenfalls möglich.
- Kurzfristige Aktionen in der IST-Konfiguration können nachvollzogen werden, verändern jedoch nicht das SOLL.
Die Möglichkeit der Auswertung mit intelligenten Reports (“zeige mir Konfigurations-Abweichungen von Objekten und deren übergeordneten CIs”) ist herausfordernd, aber möglich.
- mehr dokumentierte Objekte in der CMDB
- IP-Adressen, die im SOLL dokumentiert sind, können nicht mehr frei vergeben werden
Arbeit mit Referenz-Configuration Items
Niemand dokumentiert zu jedem Client jeweils ein passendes SOLL-Objekt. Also gehen wir hier pragmatisch vor und arbeiten mit Referenzen. Wir definieren einzelne Configuration Items als Referenz der SOLL-Konfiguration. Auf diese Referenz Configuration Items kann z. B. mit Hilfe eines zusätzlichen Attributs “Link zum SOLL-CI” verwiesen werden.
Vorteile
- Nur ein Referenz-Objekt wird benötigt.
- Das neue Release eines Standardclients und seines Lifecycles kann damit ebenso dokumentiert werden.
Nachteile
- Die Verbindungen müssen ebenfalls von Hand gezogen werden.
- Zusätzliche Dokumentationsobjekte in der CMDB.
Zusammenfassung: Was macht Baselining?
- Eine Configuration Baseline kann aus verschiedenen Gründen erstellt werden. Dazu gehören Veränderungen der Hard- oder Software, ein Massen-Rollout oder auch eine Inventur. Es ist ein Sammelbegriff.
- Eine Baseline stellt eine qualitätsgesicherte, definierte Basis dar, auf die zu einem späteren Zeitpunkt geregelt zurückgekehrt werden kann.
- Die Baseline ist in jedem Falle dokumentationspflichtig. Spätere Prozesse beziehen sich darauf.
- In der Baseline laufen alle Zustände zusammen. Der in der Baseline beschriebene Zustand der Systeme, Applikationen und Konfigurationen ist so erwünscht (SOLL). Er ist in der Realität wie beschrieben (IST). Und er ist auch funktional.
- Die Baseline definiert einen neuen Punkt, ab dem die Configuration Control greift. Änderungen sind nur mit einem Change Request erlaubt.
Herausforderungen des Baselining
- Versuchen Sie nicht, alle Objekte aus JDisc zu übernehmen. Das ist unrealistisch. Die großen Datenmengen können Sie nicht zeitnah qualitätssichern. Sie sollten bereits in JDisc überschaubare Gruppen bilden.
- Rechnen sie damit, dass JDisc nicht alle Geräte zu einem definierten Zeitpunkt erreicht und aktualisieren kann. Arbeiten Sie iterativ und legen Sie – wenn möglich – überschaubare Einheiten fest.
- Das Erreichen einer Baseline muss im Datenbestand der CMDB – z.B. im Logbuch der betroffenen Objekte – ersichtlich sein.
- Eine geplante Baseline unterteilt sich unter Umständen in mehrere Änderungen (Changes, RfCs). Hier sind Verbindungen mit den entsprechenden Einträgen im Change Management System sinnvoll.
Was ist nach dem Erreichen einer Baseline zu tun?
- Dokumentieren Sie die neue Baseline. Bedenken Sie, dass jede Änderung ab sofort kritisch ist.
- Führen Sie Backups von Snapshots und ggf. ganzen Konfigurationen durch.
- Müssen Sie eine schriftliche Gesamtdokumentation überarbeiten? Dann denken Sie bitte daran, diese an die passenden Empfänger zu übermitteln (z. B. externe Beteiligte in Wiederanlaufplänen).
- Denken Sie daran, alle offiziellen Dokumentationen zu aktualisieren. Dies betrifft z.B. Wiederanlaufpläne, Desaster Recovery Pläne oder Systemscheine.
- Reports müssen eventuell erneuert und neu versendet werden.
- Denken Sie daran, notwendige Daten zu exportieren und in eventuell vorhandene Zielsysteme zu importieren, z.B. unternehmensweit eingesetzte Data Warehouses.
- Bestücken Sie externe Dokumentationsplattformen mit den neuen Daten (z.B. USB Sticks, Notfall-Notebooks, Cloud-Speicher)
- Ist der Bereich Informationssicherheit betroffen, wird sehr wahrscheinlich ein Audit fällig.
- Denken Sie an weitere Stakeholder. Auch diese müssen offizielle Informationen erhalten.
Starten Sie mit Ihrer ersten Baseline
i-doit 30 Tage Testversion
JDisc Free Edition
Der Autor
Klaus Wockenfoth ist Onlinemarketing-Manager bei synetics. Der gelernte Softwareentwickler ist - zusammen mit dem i-doit Marketingteam - für viele Online- und Social-Media-Auftritte von i-doit zuständig und verantwortet den Bereich Content-Entwicklung und SEO.
Seit seinem Einstieg bei i-doit im Jahre 2018 befasst er sich intensiv mit der Thematik "IT-Dokumentation" und "CMDB".