Zusammenfassung - 197 - Konfigurationsmanagement

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


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


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


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


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


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


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).


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


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.


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


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


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


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

Documents

Zusammenfassung - 197 - Konfigurationsmanagement