Weisheit 12: Zur Einführung einer CMDB

Weisheit 12: Zur Einführung einer CMDB
4.5 (90%) 2 votes

Vor mittlerweile mehr als 10 Jahren habe ich meine erste CMDB Einführung begonnen. Wir haben eine eigene CMDB nach unserer Vorstellung entwickelt und dann noch eine, ich hab mir viele Produkte angeschaut, viele Lieferanten angehört und oft verfolge ich, wie es andere angehen. Ich liebe das Configuration Management!

Mein Ego ist groß und natürlich bin ich davon überzeugt, dass ich es besser weiß. Aber entscheiden Sie selbst:

Wer eine CMDB einführen will, braucht erstens Services, zweitens SLAs und drittens einen funktionierenden Change Management Prozess. Achja und Management Attention wär auch noch gut, ein bissl Budget auch und natürlich kundiges und williges Personal in den Rollen Change Management, Configuration Management usw. Aber dann kanns los gehen.

Wie kommt man zu Services?

Ich erkläre es so: Die Applikation „kann“ und das Service „tut“. Also die Funktionalität und die Version/Release wird in der Applikation beschrieben. Sie wird weiterentwickelt und funktional verändert. Damit der User die Applikation nutzen kann, konsumiert er das Service. Das Service baut die qualitativen Parameter um die Applikation herum. Also den Servicedesk, die Bereitschaft, die versprochene Verfügbarkeit, die geplante Antwortzeit, die vereinbarte Servicezeit.

Natürlich kann man diese Parameter nun für jedes Service separat definieren. Das geht, aber es ist wenig lustig, langwierig und mühsam. Ich empfehle deshalb 4 Serviceklassen (4 deshalb, damit es keine „goldene“ Mitte gibt) und in diese Klassen wird jedes Service schubladisiert (Ja, Services darf man in Schubladen einteilen, die sind da nicht böse). Also zuerst wird vorsortiert, ob eher kritisch oder eher unkritisch und dann nochmals feinsortiert: Wenn kritisch, dann ob sehr kritisch oder nur kritisch und wenn weniger kritisch – ob nur unterstützend oder doch wichtig.

Was Sie sich dann anschauen müssen ist der Verfügbarkeitsbaum. Jedes Service muss für sich „berichtbar“ sein. Was bedeutet das? Jedes Service muss einer bestimmten Benutzergruppe zuweisbar sein. Wenn das Service nicht funktioniert, kann diese Usergruppe nicht arbeiten. Mit dieser Usergruppe wird der SLA über das Service abgeschlossen. Und genau dieser SLA muss ja reportbar sein.

Ein Beispiel: Die Benutzer Erich sitzen in Linz. Die Benutzer Lena sitzen in Graz. Beide verwenden den Service MIZE (Mitarbeiterzeiterfassung). Wenn Mize nicht geht, können sowohl die Erichs als auch die Lenas nicht arbeiten. Es handelt sich also um EIN Service, die Kennzahlen sind für beide Usergruppen gleich. Natürlich kann es sein, dass das Netzwerk nach Graz ausfällt und das Netzwerk nach Linz funktioniert. Dann können die Erichs arbeiten, aber die Lenas nicht und das Service ist unterschiedlich verfügbar und es muss im SLA (in dem einen gemeinsamen für Graz und Linz gültigen SLA) geregelt sein, wie das berichtet wird und wie bezüglich Penalties damit umzugehen ist, wenn aufgrund eines Netzwerkfehlers ein Standort ausfällt.

Oder aber Sie machen 2 SLAs. Ein Mize-Graz und ein Mize-Linz und berichten beide unabhängig voneinander.

Das müssen Sie entscheiden, bevor sie weitermachen.

Dann klassifizieren Sie Mize-Graz und Mize-Linz. Wenn Graz wichtiger ist als Linz, dann bekommt es die höhere Serviceklasse (also Prio 1) und Mize-Linz bekommt „nur“ Prio2. Beginnen sie mit Ihren Prio1 Services. Diese sollten maximal 5-10% Ihrer ganzen Services ausmachen. Diese kommen natürlich zuerst in die CMDB. Es reicht auch, wenn Sie mit Ihren Top-10 beginnen. Ich empfehle aber, mit mehreren zu beginnen, nicht mit einem. Wenn genau das eine Service, das Sie ausgewählt haben, sehr speziell ist, dann wird Ihre CMDB von Anfang an sehr speziell. Machen Sie eine Best-Of der ersten 10 Services. Was für die funktioniert, geht für den Rest auch.

Identifizieren Sie die Verantwortlichen, identifizieren Sie die dazugehörenden Komponenten und Schnittstellen und alle relevanten Service Level Requirements.

Und dann rein damit in die CMDB. Jede Komponente, jeder Verantwortliche, jedes Dokument ist ein CI. Eine Anzahl von 20-30 unterschiedlichen Cis ist durchaus OK. Halten Sie sich aber bei den Attributen zurück. Es mag sie ohnehin keiner befüllen und meistens ist die Hälfte leer und das schaut nicht gut aus, und dann schreibt jemand Alibi Inhalte hinein, die niemandem helfen (lesen Sie dazu meinen letzen Blog: ITSM und die Shopping Queen)

Die Qual der Attribut-Auswahl

Suchen Sie also nach den Attributen, die Sie wirklich brauchen, und lassen Sie alle „nice to haves“ weg. (Die könnten Sie, wenn es unbedingt sein muss in einem Freitextfeld unterbringen, aber bitte nicht als eigene Auswahl oder Pflichtfelder)

Attribute zur Applikation sind beispielsweise: Weiterentwicklungsverantwortlicher, Lizenzowner, Version, Lieferant, Authentifizierung, Anzahl total Users, Anzahl concurrent Users, Hauptfunktionen.

Attribute zum Service sind beispielsweise: Serviceverantwortlicher, Agreed Servicetime, zugesagte Verfügbarkeit, Inbetriebnahmedatum, geplantes Retire-Datum, Serviceklasse, zuständiger Servicedesk, …

CMDB Einführung

Setzen Sie die Prozesse zur Aktuellhaltung der Informationen auf (am wichtigsten dabei: der Change Management Prozess – und vergessen Sie nicht, auch für Änderungen an SLAs einen Change anzulegen!) und machen Sie das Umfeld von diesen Informationen abhängig. Sobald sich herumgesprochen hat, dass die Infos, die Sie in der CMDB haben, aktuell sind, wird sie jeder wollen. Dann machen alle mit und ruckzuck sind auch die Prio2 Services und später auch alle anderen in der CMDB erfasst). Versorgen Sie alle, die die Daten brauchen damit und achten Sie strengstens auf Konsistenz und Aktualität, prüfen Sie diese immer wieder per Stichproben und machen Sie auf Abweichungen aufmerksam. Nehmen Sie nichts in die CMDB auf, wo niemand für die Aktualisierung der Daten grade steht!

Warum ich mich so über die „manuelle“ Aktualisierung auslasse? Weil die Informationen aus dem SLA und die Verantwortlichen nicht von Tools identifiziert werden können und deshalb manuell gepflegt werden müssen. (Auch wenn mir schon mehr als ein Dutzend Lieferanten versprochen haben, dass alles total automatisch geht.) Dass Serverparameter und Konfigs per Reconciliation aus der Produktionsumgebung geholt werden und mit den Daten in der CMDB abgeglichen werden können, versteht sich von selbst, aber das ist ja auch schon ein alter Hut.

Das Resultat einer gelungenen CMDB Einführung

Was Sie dann davon haben? Sie wissen bei jeder Serverwartung – wann sie laut SLA des darüberliegenden Services sein darf, welche User zu verständigen sind und welche Applikationen nicht funktionieren werden und daher aus der Alarmierung im Monitoring genommen werden können. Umgekehrt wissen Sie im Fehlerfall eines Services, welche Schnittstellen sie prüfen und welche Komponenten Sie im Monitoring auf Alarme checken müssen. Und das Beste daran: Auf Knopfdruck finden Sie heraus, wer aller eingebunden werden muss, denn die Verantwortlichen der einzelnen Services und Komponenten sind ja auch in der CMDB dokumentiert.

Es ist ein Knochenjob! Aber er lohnt sich!

Stichworte:

Schreibe einen Kommentar

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

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close