(Artikel 9 von 9)

Arbeit mit Referenz – Configuration Items

 

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 Configuration Items als SOLL-Konfiguration vor. Auf diese Referenz Configuration Items kann beispielsweise mit Hilfe eines zusätzlichen Attributs “link zum SOLL-CI” verwiesen werden.

Vorteile

 

  • Nur ein Referenz-Objekt wird benötigt
  • Die 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 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.

 

Herausforderungen des Baselining

 

  • 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 Logbuch 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.

 

Erreichen einer Baseline und Aktivitäten danach

 

  • 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 Dokumentationsplattformen 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

 

Starten Sie mit Ihrer ersten Baseline

 

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.