Claudia Isenberg
|
| 12 Minuten Lesedauer
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.
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.
Die ITIL-Dokumente beschreiben nicht nur eine Art der Baseline, sondern gleich drei.
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.
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
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”.
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.
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.
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.”
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.
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!
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.
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.
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.
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.
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.
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”.
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.
Wenn Daten in die CMDB übernommen werden sollen, folgen wir einem festgelegten Prozess. Dieser kann wie folgt aussehen:
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.
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?
In den Daten, die uns das Discovery-System liefert, befinden sich auch die drei Server, die wir näher betrachten. Wir Menschen wissen (oder können ableiten), dass diese für unseren CRM-Service die Rolle Datenbankserver, Application-Server und Webserver ausfüllen.
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.
Wir müssen den Systemen mitteilen, dass der übergeordnete Service der CRM-Service ist. Maschinen können das nicht erkennen. Der Discovery-Lösung geht es nicht anders. Denn sie kann sich zwar die Verbindungen zwischen den Geräten ansehen und diese analysieren. Die Netzwerktopologie kann analysiert und aufgezeichnet werden. Aber die Interpretation bleibt uns Menschen vorbehalten.
Es bietet sich nun eine verlockende Möglichkeit. Wir könnten mit der Hilfe einer automatisch ausgeführten Analyse der Netzwerktopologie den CRM-Service dokumentieren. Aber es gibt eine Unschärfe, die wir beachten müssen. Wenn zum Zeitpunkt des Discovery-Laufs zwei Maschinen keine Verbindung haben, heißt das nicht automatisch, dass sie nie verbunden sind. Kommunizieren zwei Server über den Port 1433, können wir annehmen, dass hier ein MS-SQL-Server seine Arbeit verrichtet. Wir wissen es aber nicht. Und auch ein geöffneter Port bedeutet noch lange nicht, dass er auch geöffnet sein soll oder benötigt wird.
Im Ergebnis erspart uns die Discovery enorm viel Analyse-Zeit. Die gewonnenen Informationen geben uns solide Anhaltspunkte und ermöglichen weitere Untersuchungen. Aber als Wahrheit können wir die Daten nicht behandeln. Sollen wir diese Daten nun als IST-Zustand übernehmen oder als SOLL-Zustand? Vorsicht ist angebracht. Wir befinden uns mitten im Mustervergleich. Vom Wissen sind wir noch weit entfernt.
Um nun diese vielen Informationen in eine gemeinsame Datenbasis wie die CMDB zu überführen, brauchen wir ein Dokumentationsmodell. Diesem müssen alle Beteiligten folgen können. Es sollte im Idealfall selbsterklärend sein. Einige unterschiedliche Modelle sind in der 7. ITIL Baseline beschrieben.
Wir trennen die funktionale Beschreibung und SOLL-Dokumentation von der mit JDisc identifizierten IST-Konfiguration. Und wir definieren folgende Regeln:
Folgendes Modell könnten Sie somit problemlos in einer CMDB abbilden:
Auch Konfigurationsänderungen wie die folgende sind möglich und selbsterklärend:
Die Möglichkeit der Auswertung mit intelligenten Reports (“zeige mir Konfigurations-Abweichungen von Objekten und deren übergeordneten CIs”) ist herausfordernd, aber möglich.
Für Server, Applikationen oder Services ist das eben vorgestellte Modell hervorragend anwendbar. SOLL und IST werden in voneinander getrennten Objekten dokumentiert. Werfen wir jedoch einen Blick auf die Clients, können wir das Modell so nicht mehr anwenden.
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.
Fühlen Sie sich bereit für Ihre erste Baseline? Wir sind sicher, dass Sie mit der optimalen Kombination von JDisc und i-doit einen leichten Einstieg in die Welt des Baselining bekommen. Sie können beide Systeme kostenfrei testen.
Pattrick Bluhm: 22. Dezember 2023
Die Server-Dokumentation umfasst die Erfassung und Speicherung wichtiger Informationen über die Server-Infrastruktur eines Unternehmens. Dazu gehören...
i-doit Team: 20. Dezember 2023
Mit i-doit pro verfügen Unternehmen über ein mächtiges Tool, mit dem Sie Ihre gesamte IT-Infrastruktur zentral dokumentieren können. Eine umfassende...
i-doit Team: 06. Dezember 2023
Paris/Düsseldorf, Dezember 2023 - Humans4help, ein führender französischer Gründerkonzern für digitale Transformation mit Fokus auf...
