1 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
197 Konfigurations-management-
System konzipieren und implementieren
Zusammenfassung
Was ist Konfigurationsmgmt.
Stellt sicher, dass die Informationen über die Konfiguration von Hard & Software aktuell und korrekt sind!
Direkte Kontrolle der eingesetzten Ver-mögenswerte
Grundlage für Informatikdienstleistungen
Speicherung der Daten in der Konfigurati-onsmgmt. Datenbank (Configuration Ma-nagement Database – CMDB)
Ziel & Nutzen
Sicherstellen der Verfügbarkeit von IT Systemen
Änderungen werden geziehlt und nach-vollziebar durchgeführt
Alter Zustand kann wieder hergestellt werden
Nutzen
Verhinderung von Ausfällen und Störun-gen
Änderungen sind nachvollziehbar
Änderungen können rückgängig gemacht werden
Versionen und Varianten
Version unterschiedliche Funktio-nalität
Variante identische Funktionalität unterschiedliches Umfeld
Wissen
welche Datei von welcher SW verwendet wird
ob die Datei gelöscht werden kann
ob die Datei von anderer SW benutzt wird
Alle Informationen für Support eines Gerät via Inventarnummer
Change Management
Vor Änderungen müssen Auswirkungen be-kannt sein
An Hand fundierter Informationen beurteilen
wie hoch der Aufwand
wie hoch das Risiko
wer ist zu informieren
wer muss hinzugezogen werden
Konfigurationsmgmt. im Rahmen des IT Service-Mamagements
Ziel
Einsatz und Wirkung der eingesetzten IT-Infrastruktur zu optimie-ren
Grundgedanke
Kundenorientierung
Prozessorientierung
Qualitätsverbesserung
2 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Konfigurationsmanagement
Operationelle Ebenen des IT-Service-Mgmt. nach ITIL
Change Mgmt.
Änderungen werden durch einen sg. Än-derungsantrag (RfC) beantragt
Changes sind oft ein Resultat eines Prob-lems
Request for Change (RfC od. Changere-quest)
Verwaltet Änderungsanträge
Incident Mgmt.
Das Helpdesk muss feststellen, welche Komponenten betroffen sind.
Das Konfigurationsmgmt. o Liefert Diagramme der HW-
Komponenten o Liefert Diagramme über die Ver-
netzung o Liefert Diagramme über die instal-
lierte SW
Problem Mgmt.
Viele Störungen können zu einem Problem zu-sammengefasst werden. Kann eine Störung nicht behoben werden, wird sie zum Problemfall. Inte-ressant sind dabei vor allem die Schnittstellen zu anderen Systemen (Runder Tisch).
Probleme werden priorisiert und klassifi-ziert
Verbesserungsvorschläge werden ins Change Mgmt. eingebracht
SW-Kontrolle & -verteilung
Lizenzverwaltung zur Kontrolle der instal-lierten SW
SW-Installationtools zur Verteilung und Installierung der SW (SW-Library)
Sicherstellen, das nur aktuell freigegebe-ne Versionen verwendet werden.
ITIL (IT Infrastructure Library)
Ist der De-facto-Standard für das IT-Service-Management
Kernprozesse
Prozessart Prozessinhalt
Strategisch Beziehungsmgmt. zu Liefe-ranten
Qualitätsmgmt. (QM)
IT-Service-Organisation
IT-Infrastruktur-Architektur
Support für SW-Lifecycle
Planung & Kontrolle für IT-Services
Kundenbeziehungen
3 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Prozessart Prozessinhalt Taktisch Service Level Mgmt.
SLA
OLA
Cost-Mgmt.
Capacity-Mgmt.
Availability-Mgmt.
Katastrophenmgmt.
Security-Mgmt.
Unterhaltsverträge
Prozessart Prozessinhalt
Operationell Konfigurationsmgmt.
Change-Mgmt.
Incident-Mgmt.
Problem-Mgmt.
Softwarekontrolle & -verteilung
Testen eines IT-Services für die optimale Nutzung
Computer-Installation & Ak-zeptanz
Umgebungsmgmt.
Konfigurationseinheiten
Sind die einzelnen Teile der Konfiguration
Eine Einheit, welche selbständig installiert, ersetzt und modifiziert werden kann, wird als Konfigurationseinheit de-finiert.
Typen von Konfigurationseinheiten
Typen
Hardware
Software
Dokumentation Je nach Typ werden unterschiedliche Informati-onen gesammelt.
Relationen
Abhängigkeiten der Konfigurationseinheiten zu-einander müssen bekannt sein.
Abhängigkeiten
sind miteinder verbunden
wird von einer anderen benutzt
ist Teil einer anderen
ist eine Kopie einer anderen
ist eine Variante einer anderen
Detaillierungsgrad
Hardware
Software
Dokumentationen
4 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Versionen
Versionen unterscheiden sich in der Funktio-nalität, während Varianten eine identische Funktionalität für unterschiedliche Schnitt-stellen aufweisen.
Nur wenn eine Änderung bzw. ein Problem auch eine Variante betrifft, ist im Config-Mgmt. mit Varianten zu arbeiten.
Varianten können unterschiedliche Fehlerge-schichten haben, die Funktionalität wird aber immer von ein und derselben Version abgeleitet.
Attribute einer Konfigurationseinheit
Einheitsart Mögliche Attribute
Hardware Eindeutige Inventar-nummer
Bezeichnung
Kategorie
Drucker
PC
Bildschirm
etc.
Gerätespezifische In-formationen
Software Name
Typ
Beschreibung
Speicherort
Dateiversion
etc.
Dokumente Name
Datei-Typ
Beschreibung
Dateiname
Status
Dateiversion
etc.
Verwaltung
Papierform bei kleinen, überschaubaren Sys-temen
Tool bei grösseren, komplexen Systemen
Ablage Art Nachteile
Filesystem als Ablage zeit- & arbeitsauf-wendig
fehleranfällig
geringer Zugriffs-schutz
Versionisierung er-folgt manuell
Auswertungen von Hand
Dokumenten-Mgmt.-System als Ablage
Schwer zur erstellen-de Verknüpfungen
Für HW & SW unter-schiedliche Werkzeu-ge
für wichtige Aufgaben (SW-Verteilung etc.) nur beschränkt oder nicht brauchbar
Auswertung der Da-ten aufwendig
Konfigurationsmgmt.-Datenbank
Es werden alle Attribute sämtlicher Konfigurati-onseinheiten sowie deren Verknüpfungen unter-einander verwaltet.
Vorteile
Redundanzen von Daten sind selten
kann schnell & flexibel ausgewertet werden
kann durchgängig in die ITIL-Prozesse integ-riert werden
skalierbar (kann wachsenden Datenmengen und steigenden Anforderungen ohne grossen Aufwand angepasst werden.)
Oft werden SW-Dateien in einer separaten DB gehalten (Definitive Software Library)
Beispiel
5 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Aufgaben des Config Mgmt.
Aufgabe Funktionen
Kontrollieren Registrieren neuer Konfigura-tionseinheiten
Dokumentation von Änderun-gen
Schutz der Integrität der Da-ten
Unterstützung der Lizenzkon-trolle (keine Kernaufgabe)
Status über-wachen
Automatischer und periodi-scher Statusnachweis
Reports
Eindeutig identifizierbare Konfigurationseinheiten mit aktuellem Status
Baseline der Konfigurati-on, aktueller Releases und deren Status
Änderungshistorie
Offene Probleme und Changerequests (Request for Changes – Änderungs-antrag)
SW-Entwickler Unterstützen
Check-in des Programmcodes
Checkout des Programmcodes
Einstellung einer Delta-Sicherung (Veränderung ge-genüber der Vorversion)
Anlage einer neuen Version
Change-Mgmt. unter-stützen
Verantwortlichkeit für Ände-rungen festlegen
Relationen zwischen einzel-nen Konfigurationseinheiten aufzeigen
Rollen
Rolle Funktion
Konfigurations-manager
Aufsicht über Config-Mgmt.
Überwachung der Einhal-tung relevanter Prozesse
stellt sicher, dass Änderun-gen korrekt abgebildet werden
macht Auswertungen für
Projektleiter
Changemanager
diverse
Rapportiert regelmässig an das Management
Change-manager
Untersucht die Auswirkun-gen geplanter Änderungen.
Prüft formale Korrektheit
Verfolgt Ausführung der akzeptierten Änderungsan-träge
Weist Änderungsanträge bei Bedarf zurück
Konfigurationsmgmt.-Prozesse
Kernaktivitäten
6 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Prozesse
Prozess Funktionen
Identifikation Alle Einheiten identifizie-ren und bezeichnen.
Verknüpfungen der Konfi-gurationseinheiten ermit-teln.
Kontrolle Es wird ein Verantwortli-cher für die Integrität festgelegt.
Daten werden ausschliess-lich von autorisierten Per-sonal erfasst.
Statusüber-wachung
Lebenszyklus einer Kom-ponente muss genau ver-folgt werden.
Plausibilisierung Die CMDB muss jederzeit über aktuelle und integre (fehlerfreie und vollständi-ge) Daten verfügen.
Beispiele der Statusüberwachung
Statusüberwachung Hardware
Statusüberwachung Software
Konfigurationsmgmt. im SW-Bereich
Es soll verhindern, dass… a) …mehrere Entwickler an derselben Datei
arbeiten und Inkonsistenzen herbeifüh-ren.
b) …die Entwickler mit anderen Dateiversio-nen als die Benutzer arbeiten.
Entwicklungsprozesse
Es werden folgende Entwicklungsprozesse dabei unterstützt:
a) Entwicklungsumgebung b) Testumgebung c) Integrationstestumgebung d) Produktivumgebung
7 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Zusammenspiel der Entwicklungsprozesse
Baseline
Nach der Abnahme wird eine Mayor-Version ein-gefroren. Die erste "eingefrorene" Version wird als Baseline bezeichnet.
Unterstützung des Release Management
Es muss ein effizientes Versions- und Release Management aufgebaut werden.
Release-Nummern
Release-Nummern haben oft folgende Abstufung
Abstufung Bezeich-nung
Funktion
10 Major Re-lease
Bezeichnet eine komplett neue, überarbeitete Versi-on.
10.2627 Architectu-ral Release
Bezeichnen kleinere Funktionserweite-rungen bzw. –änderungen.
10.2626.2625
Internal Release
Bezeichnen Fehler-behebungen
Konfigurationsmgmt. im HW-Bereich
Das HW-Konfigurations-Management soll verhin-dern, dass nach einem Austausch der Hardware Störungen auftreten. Eine neue Hardware bringt meist auch eine Änderung der Treiber und somit eine Änderung der Software mit sich.
Solange die alte, ausgetauschte Hardware noch aufbewahrt wird, darf der Eintrag zur Hardware nicht aus der Konfigurationsmanagement-Datenbank gelöscht werden. Es darf lediglich der Status verändert werden (ausser Betrieb).
8 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Tools
Verschiedene Tools unterstützen das Konfigura-tions-Management. Bei der Auswahl der Tools sollten folgende Fragen beantwortet werden:
Lässt sich die Lösung in die bestehende Um-gebung integrieren?
Ist sie an neue Anforderungen anpassbar?
Werden Standards (ITIL) unterstützt?
Kann das Change Management integriert werden?
Lässt sich eine SW-Verteilung integrieren?
Kann die Lösung für das Störungs- und Prob-lemmanagement eingesetzt werden?
Gibt es ergänzende, komplementäre Lösun-gen?
Was kostet die Lösung (Anschaffung & Be-trieb)?
Wie können bestehende Konfigurationen übernommen bzw. Erfasst werden (automa-tisch)?
Change Management
Vorgenommen Änderungen ziehen immer wieder Folgeprobleme nach sich, deren Behebung den ursprünglichen Änderungsaufwand bei weitem übersteigen.
Ziel: Veränderungen möglichst wirtschaftlich und termingerecht mit möglichst geringem Risi-ko durchführen.
Nutzen
Kontrollierte Änderungen = weniger Fehler bzw. Qualitätseinbussen.
Frühzeitige Risikoerkennung
Systematische Information
Stabilere Dienstleistungen = höhere Produkti-vität
Bessere Produktivität der Informatiker
Bei Problemen durch Changes kann der ur-sprüngliche Zustand wieder hergestellt wer-den.
Change Management Prozess
Registrierung
Jeder Änderung muss mit einer eindeutigen Nummer registriert werden
Verbindung zum Problemmanagement muss ohne grossen Aufwand möglich sein.
Nach der Registrierung muss ein Änderungs-antrag autorisiert werden (Änderungsaus-schuss, Change Advisory Board)
Plan
DoCheck
Act
9 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Klassifizierung
Änderungen müssen kategorisiert und priorisiert werden.
Prioritätsstufen
Prioritätsstufe Kriterien Massnahmen
Service- leistung
Benutzer betroffen
Kann Warten bis Release
Ausf
all
Gro
sser
Ein
fluss
Geri
nger
Ein
fluss
vie
le
wenig
e
Nein
Ja
0 (dringend) X X
Entscheid des Änderungsausschusses dringend erforderlich. Sofortige Feststellung der notwen-digen Ressourcen.
X X X
1 (hoch) X X X Die Änderung durchläuft den ge-
wöhnlichen Änderungsprozess. X X X
2 (mittel) X X X Die Änderung durchläuft den ge-wöhnlichen Änderungsprozess.
3 (niedrig) X X X Diese Änderung wird nicht separat, sondern erst beim nächsten Release durchgeführt.
Kategorien
Alle nicht dringenden Änderungen (Prioritätsstu-fe 1-3) müssen vom Change Manager geprüft werden. Sie können dann in folgende Kategorien eingeteilt werden:
Kategorie Erläuterung
1 (wenig Aus-wirkungen)
Change Manager autorisiert
Änderungsausschuss zur Kenntnisnahme
2 (mittlere Auswirkungen)
Änderungsausschuss auto-risiert
Benötigt dazu die komplette Dokumentation des Ände-rungsantrags
3 (grosse Aus-wirkungen)
IT Management autorisiert
Planung
Folgende Fragen sollten für die Planung eines Changes beantwortet werden können:
Welche Komponenten der IT Infrastruktur sind von den Änderungen betroffen?
Sind währende des Changes Teile der IT Inf-rastruktur für Benutzer und bestimmte Be-nutzergruppen nicht verfügbar?
Sind andere Servicebereiche wie das Stö-rungs- oder das Problemmanagement davon betroffen?
Was würde geschehen, wenn die Änderung nicht durchgeführt würde? Sind nebst Folge-problemen auch Einschränkungen der Benut-zer zu erwarten?
Sind die Notwendigen Ressourcen vorhanden? Wie wird der Change finanziert?
Koordination
Mit allen Beteiligten koordinieren
Alle Betroffenen frühzeitig informieren
SW-Änderungen in einem Release zusammen-fassen
Realisierung
Einheit Was
Hardware Beschaffung von Hardware bzw. von Hardware-Komponenten.
Vorbereiten der Hardware für den produktiven Einsatz.
Software Beschaffung von Software bzw. von Software-Komponenten. Neue Version in Konfigurationsda-tenbank zur Verfügungsstellen. Dokumentation der kompletten Än-derung.
10 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Test
Der Change Manager überprüft, ob alle Richtlinien eingehalten wurden.
Für die Testdauer müssen die Konfigurationseinheiten vor weiteren Veränderun-gen geschützt werden.
Einheit Was Resultat
Hardware Hardware installieren und testen
Testresultat protokollieren
Test OK; Hardware wird implementiert.
Test NOK; Hardware wird nicht in PAV installiert.
Software SW aus Konfigurationsdatenbank in Testumgebung laden.
Roll-back-Verfahren testen
Test OK; Einheit wird in die Phase "Implementa-tion" freigegeben.
Test NOK; Einheit wird in Phase "Realisation" zurückgestellt.
Implementation
Regeln
Das Change Management ist Auslöser des Prozesses!
Ausführen, wenn der geringste Einfluss auf die Benutzer ausgeübt wird (Zeitfenster de-finieren).
Bei Problemen muss der ursprüngliche Zu-stand mit dem Roll-back-Verfahren herge-stellt werden.
Evaluierung & Abschluss
Änderungen müssen nach der Implementation geprüft werden. Das Resultat wird in einem Prüfbericht zusammengefasst, welcher dem Än-derungsausschuss übergeben wird:
Haben die Änderungen den gewünschten Ef-fekt?
Sind die Benutzer zufrieden?
Haben sich unerwünschte Folgeprobleme ergeben?
Wurde korrekt geplant (Ressourcen)? Nach zufrieden stellender Beurteilung kann der Change formell abgeschlossen werden.
Vorgehensweise
Hauptstudie und Evaluation im Phasenmo-del
11 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Grobkonzept
Um ein Grobkonzept zu erstellen, können wir uns am typischen Planungszyklus (Problemzyklus) orientieren.
Auftrag
Es wird ein Konfigurationsmanager bestimmt, welcher für die Managementfunktion verant-wortlich ist. Das ist idealerweise der Projektlei-ter.
Anzahl Projektmitarbeitende
Umfang der Verantwortlichkeiten.
Integration von anderen Disziplinen (Change Management, Softwareverteilung).
Grösse der Installation (Anzahl Komponen-ten, Detailierungsgrad).
Umfang der zur Verfügung stehenden Werk-zeuge.
Häufigkeit und Komplexität von Softwareän-derungen und Releases.
Trainingsarbeit bei fehlendem Know-how.
Projektziele
Zielsetzung muss vom Auftraggeber und dem Projektteam gemeinsam definiert werden, wie z.B.:
Es werden alle notwendigen Attribute sämtli-cher Konfigurationseinheiten festgehalten werden.
Es werden alle Relationen zwischen den ein-zelnen Konfigrationseinheiten aufgedeckt.
Es wird sichergestellt, dass alle Änderungen der IT Infrastruktur zeitgerecht erfasst wer-den.
Erhebung
Welche Auswertungen werden vom Manage-ment erwartet?
Soll das Help Desk eingebunden werden?
Wie sieht das Change management aus?
Wie sieht der Prozess der SW-Entwicklung aus?
Wie soll die SW verteilt werden?
Welche Weisungen, Standards und Prozesse bestehen?
Welche Funktionen sollen abgedeckt weden?
In welche Systeme muss die Lösung integriert werden?
Würdigung (Gewichtung)
Alle erhaltenen Informationen gewichten!
Lösungsentwurf & Bewertung
Nach dem eine Lösung entworfen wurde, kann diese an Hand der Gewichtung, bewertet wer-den.
Auswahl (Entscheid)
Am Schluss des Planungszyklus muss man sich für eine Lösung entscheiden. Als Resultat wird ein Grobkonzept erwartet.
Schritt Inhalt Pflichtenheft Ausgangslage
Ist-Situation
Ziele
Anforderungen
Mengengerüst
Vorgaben für Offerte
Administratives
Fragenkatalog
Bewertungsdo-kumentation
Kriterienkatalog
Bewertungsliste
Bewertungsmassstab
KO-Kriterienliste
Offerte Auswahlliste der Anbieter
Vergleichbare Offerte
Profile der Offertsteller
Grob- & Detail-Evaluation
Rangfolge der Offerten
Kosten pro Offerte
Kosten-Nutzen-Verhältnis pro Offerte
Evaluationsbericht Entscheidungsgrundlagen mit:
Nutzwertanalyse
SWOT-Analyse (Stärken, Schwä-chen, Chanchen, Risiken)
Risikobewertung
Kosten-Nutzen-Übersicht
Entscheid Lösungsvariante auswählen
Vertrag Vertragsdokument unterzeichnen und verteilen
12 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Arbeitsschritte im Rahmen der Projektphasen "3. Hauptstudie" und "4. Evaluation"
Evaluation durchführen
Pflichtenheft erstellen
Bietet das System die Möglichkeit der auto-matisierten Integration bestehender Compu-ter?
Bietet das System eine integrierte Datenhal-tung?
Wie findet die Überwachung, das Controlling und Reporting statt?
Kann das System mobile Nutzer (z.B. Lap-tops) effizient nutzen?
Mindmap «Pflichtenheft erstellen»
Bewertungskriterien
Einzelne Anforderungen müssen vor der Durch-sicht der Offerten gewichtet werden.
Implementation vorbereiten
Folgende Vorarbeiten müssen geleistet werden:
Jede Konfigurationseinheit muss eindeutig gekennzeichnet sein!
Es muss eine Namenskonvention für die Ein-heiten und die CMDB definiert werden.
Alle Status, welche durchlaufen werden kön-nen, sind zu definieren.
Mögliche Statusänderungen sind zu definie-ren
Richtlinie für Namenskonventionen
Kurze Namen bevorzugen
Aussagekräftige Namen und Nummern wählen
Bestehende Konventionen weiter verwenden
13 197 Konfigurationsmanagement-System konzipieren und implementieren
31. Oktober 2009
Konfigurationseinheiten und
Attribute erfassen
Zu einem bestimmten Zeitpunkt müssen sämtliche Konfigurationseinheiten der IT Inf-rastruktur aufgenommen werden. Diese In-ventur kann auch in Phasen ablaufen.
Alle Konfigurationseinheiten werden mit ei-nem Namen und entsprechenden Attributen versehen.
Alle Konfigurationseinheiten müssen diese Identifikation ab sofort tragen (Hardwarekle-ber, Kommentarzeile in Programmkopf usw.)
Eine Konfigurationseinheit wird in ihrem Le-benszyklus mehrfach geändert. Aktualisie-rungen müssen deshalb sehr sorgfältig durch-geführt werden.
Konfigurationseinheiten, ihre Verknüpfungen und ihr Status werden laufend überwacht und in der CMDB genau registriert.
Änderungen der IT Infrastruktur können auch währende der Einführung vorgenommen wer-den.
Implementierungsplan
Das operationelle Config Management umfasst folgende Tätigkeiten:
Neue Konfigurationseinheiten registrieren.
Alte Konfigurationseinheiten archivieren.
Konfigurationseinheiten pflegen.
CMDB für die Beurteilung der Auswirkung von Änderungsanträgen verwenden.
Standards bezüglich Konfigurations- und Change Management überwachen.
Helpdesk bei der Behandlung von Störungen und Problemen unterstützen.
CMDB mit dem wirklichen System vergleichen.
Nutzwertanalyse
Quellennachweis:
Konfigurationsmanagement-System konzipieren und implementieren (197) (Alain Mori und Johannes Scheuring) 1. Auflage 2003, Compendio Bildungsmedian AG, Zürich