(Artikel 9 von 9)

Arbeit mit Referenz-CIs

Ist das soeben vorgestellte Dokumentationsmodell mit getrennten SOLL und IST Objekten bei Servern, Applikationen bzw. Services ein gangbares, ist es bei Clients nicht denkbar.

Niemand dokumentiert zu einem Client jeweils ein passendes SOLL-Stück. Hier schlagen wir die Anwendung von einzelnen CIs als SOLL-Konfiguration vor. Auf diese Referenz-CIs kann beispielsweise mit Hilfe eines zusätzlichen Attributs “link zum SOLL-CI” verwiesen werden.

Vorteile dieser Lösung:

  • Nur ein Referenz-Objekt wird benötigt
  • Die neue Release eines Standardclients und seines Lifecycles kann damit ebenso dokumentiert werden.

Nachteil der Lösung:

  • Die Verbindungen müssen ebenfalls von Hand gezogen werden.
  • Zusätzliche Dokumentationsobjekte in der CMDB

Zusammenfassung: Was macht Baselining?

 

  • Eine Configuration Baseline kann zum Anlass eine neue Software- oder Hardware- Release haben, 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 jedenfalls dokumentationspflichtig, denn spätere Prozesse beziehen sich darauf.
  • Der Zustand der von einer Baseline betroffenen Systeme, Applikationen , Konfigurationen bzw. CIs war so erwünscht (SOLL), tatsächlich so (IST) und auch funktional.
  • Die Baseline definiert einen neuen Punkt, ab dem die Configuration Control greift – Änderungen nur mit Change Request.

 

Folgende Herausforderungen sind zu meistern:

  • Es ist unrealistisch ALLE Objekte aus JDisc zu übernehmen und zeitnah in der CMDB qualitätssichern zu können – man sollte bereits in JDisc überschaubare Gruppen bilden.
  • Ebenso unrealistisch ist es, dass mit JDisc alle Geräte zu einem Zeitpunkt erreicht und aktualisiert werden können. Hier muss iterativ und ebenfalls mit überschaubaren Einheiten gearbeitet werden.
  • Das Erreichen einer Baseline muss im Datenbestand der CMDB, z.B. im LOG der betroffenen Objekte, ersichtlich sein.
  • Eine geplante Baseline unterteilt sich unter Umständen in mehrere Änderungen (Changes, RfCs) aus. Hier sind Verbindungen mit den entsprechenden Einträgen im Change Management System sinnvoll.

 

Das Erreichen einer Baseline löst, je nach IT-Organisation viele weitere Aktivitäten aus:

  • Dokumentieren der neuen Baseline (ab nun sind Änderungen kritisch!)
  • Durchführen von Backups, Snapshots, ggf. ganzer Konfigurationen
  • EIne schriftliche Gesamt-Dokumentation muss ggf- überarbeitet und den Empfängern übermittelt werden (externe Beteiligte in Wiederanlaufplänen).
  • offizielle Dokumentationen, z.B. Wiederanlaufpläne, Desaster Recovery Pläne, Systemscheine, etc. müssen aktualisiert werden
  • Reports müssen ggf. erneuert und neu versandt werden
  • Export der Daten und Import in eventuell vorhandene Zielsysteme, z.B. unternehmensweit eingesetzte Data Warehouses
  • Beladen externer Dokuplattformen mit den neuen Daten (z.B. USB Sticks, Notfall-Notebooks, Cloud-Speicher)
  • ggf. Auditieren, Bewerten im Security- und Datenschutz-Kontext
  • ggf. offizielle Informationen an weitere Stakeholder herausgeben

 

Auf die Plätze …

Sie sind bereit für Ihre erste Baseline? Wir sind sicher, mit JDisc und i-doit haben Sie ein Software-Bündel, dass Ihnen den leichten Einstieg ermöglicht. Unsere Anwender-Community trifft sich einmal pro Quartal zu einem regionalen Anwendertreffen und jeden Herbst zur großen Anwenderkonferenz. Wir freuen uns Sie dort zu sehen und auf Ihren Erfahrungsbericht!

We do IT!

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.