(Artikel 3 von 9)

Die dritte Baseline: Wer entscheidet?

In der Praxis wird oft nicht lange gefackelt. Den CMDB Aufbau und die laufende Datenpflege macht üblicherweise ein Admin. Als Techniker muss man davon ausgehen, dass der aktuelle Status im Netzwerk auch jener ist, der erwünscht ist, schließlich “läuft” das System. Soll heißen: Weder IST noch SOLL wird als solches definiert, es geht nur um den “funktionalen” Status. Auf diesen wird im oft zitierten Desasterfall oder nach misslungenen Änderungen, Updates und Releases wiederhergestellt.


Am einfachsten wird ein solcher Status mit Snapshots von virtuellen Umgebungen oder mit Snapshots in Form von Backups zu fixen Zeitpunkten hergestellt. Diese Snapshots sind vermeintlich eines: Funktional. Wir haben uns daran gewöhnt, mit Snapshots alle Fliegen auf einmal zu erschlagen und diese auch gar nicht weiter zu dokumentieren. Das gilt gleichermaßen für die Konfiguration eines Netzwerkes, von Applikationen, Servern als auch für Software, die auf Clients installiert ist, egal wie sie dorthin gekommen ist. Im besten Fall steht im Backup-Log ein Einzeiler: Full Backup vom 29.02.2017.

 

Aber wie sieht das der Budgetverantwortliche, die Buchhaltung, die Fachabteilung, die Prozessverantwortlichen? Gehen wir ausschließlich den Weg das aktuelle IST mittels Snapshot zu dokumentieren, verpassen wir unter Umständen etwas Wesentliches: Jemand muss im eingangs erwähnten Beispiel für die Differenz der schnell zugewiesenen 8GB auch bezahlen. Oder in anderen Fällen: Eine Lizenz anpassen. Oder auch die SOLL-Dokumentation aktualisieren und an die richtigen Personen mitteilen, diese verteilen. Eventuell ist es auch interessant, herauszufinden, warum unser Änderungsprozess es zulässt, dass vom SOLL zum IST plötzlich Unterschiede bestehen.

 

Grund genug im Rahmen eines Projektes intern zu besprechen, wie denn mit den Versäumnissen und Ungereimtheiten der Vergangenheit umgegangen werden soll. Aber, und hier kommen wir zum Kern der Betrachtung: Auch Grund genug sich einen “Marker” zu setzen und eine, für alle Beteiligte klar definierte Kante zu setzen: Eine Basis, auf die hingearbeitet wird und von der auch weggearbeitet wird.

 

Die Baseline: Gleichstand von Technik und Organisation

Schnell wird klar: Alleine der technische Snapshot einer Konfiguration zu einem Zeitpunkt 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. Hier ist sie nun, die Baseline. Wir ziehen einen Strich und sagen: Die buchhalterische, die technische, die lizenztechnische, die Dokumentationsebene: alle Prozesse haben sich nun auf diese eine Wahrheit geeinigt. Das ist das neue SOLL. Abweichungen, egal aus welchem Grund, darf es eigentlich nicht geben. Wenn doch, wollen wir sie auch herausfinden und einer Betrachtung unterziehen!

 

Planung von Baselines

Eine Baseline kann durch vieles ausgelöst werden. In unserem Beispiel hat die neue Release der CRM Software ausgelöst, dass wir den Speicher des Servers aufrüsteten, damit benötigen wir auch mehr Speicher beim Sichern, mehr Zeit beim Rücksichern. Eventuell ist beim Update auch eine neue Version des Apache Webservers einhergegangen, PHP wurde ebenfalls updated. Auch die Datenbank wurde auf neuesten Stand gebracht – was auch bei allen anderen Anwendungen, die am Datenbankcluster mitlaufen, zu Nacharbeiten sorgte. Alles zusammen genommen umfasst unsere Baseline “CRM Update Frühjahr 2017” also viele einzelne Punkte, die miteinander zusammenhängen und eine betriebsinterne Baseline ausmachen. Diese Baseline ist nun unser neues Plan-Soll. Für die Verrechnung, für Backup-Konzepte, das Lizenzmanagement, den Desasterfall und letztlich für unsere gesamte Dokumentation.