Hausaufgaben sind noch vor dem eigentlichen Start des CMDB Projekts zu erledigen. Das Pilotprojekt, das neulich beendet wurde, hat bewiesen, dass i-doit pro für die Anforderungen an die IT Dokumentation und als CMDB ein taugliches Werkzeug ist. Projektleiter Max Admin brennt jedoch die Anforderung der Geschäftsführung unter den Nägeln: Eine Notfallsdokumentation zu erstellen. Er muss den Weg dafür bereiten. Und da gibt es noch einiges zu überdenken. 

Bottom Up: Details

Bisher wurde “bottom up” gearbeitet um die CMDB mit Daten zu befüllen. Mit Unterstützung von Discovery wurden Daten der Netzwerkknoten aus dem Netzwerk strukturiert in die CMDB übernommen. Das hat einerseits bewiesen, dass die manuelle Pflege von Excel-Dateien für die IT-Dokumentation tatsächlich der Vergangenheit angehört. Der Prozess der Daten-Detailpflege kann und muss möglichst hoch automatisiert werden. Der Import manuell gepflegter Datensätze aus den üblichen Tabellen brachte nur fragliche Ergebnisse. Netzwerk-Discovery bringt eine hohe Detailtiefe, die manuell nicht annähernd zusammengetragen, geschweige denn: aktuell gehalten werden könnte. Aber: Was nutzt das Detail, wenn im Notfall nicht klar ist, wie die Dinge zusammenhängen? Welche Reihenfolge muss eingehalten werden, um wieder zum Normalbetrieb zu kommen? Wohin zuerst? Hier fehlt ein größeres Bild.

Die Gesamtzusammenhänge eines komplexen IT-Systems sind nur bedingt mit Discovery herauszufinden. Zwar ist es möglich technische Schnittstellen zu identifizieren. Doch: wenn zwei Maschinen miteinander hin und wieder auf einem IP-Port kommunizieren, kann das viel oder wenig für die Gesamtfunktion eines Systems bedeuten. Gerne wird in diesem Zusammenhang vom IT Verbund gesprochen. Eine Web-Recherche bringt Klarheit, was da alles dazu gehört:

IT Verbund

Gesamtheit der infrastrukturellen, organisatorischen, personellen und technischen Komponenten, die der Aufgabenerfüllung in einem bestimmten Anwendungsbereich der IT dienen. (Quelle: http://www.informationsmanagement-buch.org )

Eben diesen Verbund möchte Max nun strukturiert analysieren. Und als Techniker denkt er dabei zuerst mal an die technischen Komponenten.

Top Down Modellierung der CMDB – Gibt es Best Practices?

Max ist im Gespräch mit seinem Chef, IT Leiter Adam Kapon: “Sag Adam, du bist ja ITIL geschult. Gibt es da keine Methode, wie man den IT Verbund analysiert und dokumentiert? Wir müssen ja für den Notfall gerüstet sein.”

Adam, der im Rahmen seiner Ausbildungen viel mit Standards, Normen und Best Practices zu tun hatte, muss leider verneinen: “ITIL sagt dir was gemacht werden soll. Und zwar aus dem Best Practice Ansatz: Diese und jene Methoden haben sich tausendfach bewährt. ITIL ist aber kein Kochbuch. Wie wir die Prozesse bei uns umsetzen unterscheidet sich ganz maßgeblich von anderen Unternehmen. Daher gibt es kein Wie in ITIL.”

Max versteht, ist aber nicht glücklich. Auch seine Recherche im Internet zeigt so gut wie keine Treffer für sein Vorhaben. Am besten wird es wohl sein seinen Hausverstand zu befragen und mit einigen anderen “klugen Köpfen” die Sache anzugehen.

Und wieder die Frage aller Fragen: Wo beginnen?

Max nützt die seltene Gelegenheit mit seinem Chef ein ausführliches Gespräch führen zu können: “Wenn wir beide schon zusammen sitzen: Gehen wir doch einmal davon aus, dass wir reichlich IT im Haus haben. Aber: genau keine Dokumentation darüber, wie alles zusammenhängt. Wir ahnen den IT-Verbund, wir wissen, dass es ihn gibt. Einige wissen mehr als andere. Dokumentiert ist er nicht. Da sind wir natürlich für den Notfall schlecht aufgestellt. Ja, eine Menge Excel-Dateien haben wir. Die werfen wir auch nicht weg. Ich will jedoch mal so tun, als ob wir von Null beginnen. Denken wir in neuen Bahnen, investieren wir doch mal ein paar Stunden. Überlegen wir, wie ein Notfallmanagement bei uns, und zwar von Null weg, klappen könnte und wie wir dorthin kommen!

Kapon lässt sich auf das Planspiel ein. “Da müssten wir uns doch in erster Linie mal überlegen, bei welchen unserer IT-Services und Systemen es überhaupt wichtig ist, die Notfalldokumentation lückenlos und rasch fertig zu haben!”

Was interessiert uns “brennend”?

“Max, das hast du doch schon 1000 mal gehört. Das Business ist abhängig von der IT. Aber auch: “Business rules IT”. Unser Kerngeschäft gibt uns vor, was wir zu tun haben. Wir müssen uns also nur ansehen, womit wir unser Geld verdienen. Dort starten wir! Und dann habe ich noch ein anderes Denkmodell für die Dringlichkeit einer IT-Notfalldokumentation: Der Job von euch Admins ist zu 100% vom Funktionieren der IT abhängig. Klappt’s nicht, wird die Zufriedenheit mit euren Leistungen enden wollend sein. Wann stellt man denn fest, dass man von der IT abhängig ist? Wenn’s nicht klappt. Es ist also in eurem Interesse für den Notfall gerüstet zu sein. Wie könnt ihr beweisen, dass ihr euren Job im Griff habt? Genau: Wenn’s drauf ankommt schnell das Richtige zu tun. Feuerwehr und Rettung haben eine klar strukturierte Vorgehensweise, einen Notfalls- und sogar Katastrophenplan. Darauf können wir uns als Gesellschaft verlassen. Auf dieses Niveau sollten wir mit dem Notfallmanagement auch in unserer Firma hin! Letztlich verlassen sich alle Fachbereiche und die Geschäftsführung darauf, dass wir wissen, was wir tun! Dazu brauchen wir zuerst mal einen Bauplan des IT Hauses in das wir im Ernstfall hineingehen.”

Beginnen, wo es weh tut!

Max hakt ein. Seine Versuche “alles” zu dokumentieren sind mehrfach gescheitert. Er führt seine Erfahrungen so aus: “Wir Admins sind gelernte Perfektionisten. Insgeheim hegen wir den Wunsch “alles” dokumentiert zu haben. Am liebsten in einer Datei oder Datenbank. Ich merkte das auch im CMDB-Pilotprojekt. Jeder Stakeholder im Projekt geht davon aus, dass wir alle Informationen komplett korrekt und zentral in einer Datenbank auswertbar vorliegen haben! Nun versucht das natürlich jeder Admin irgendwie zu erreichen. Aber es ist so gut wie unmöglich! Mit “Alles” können wir das Projekt weder starten noch jemals sauber beenden.”

Ist laut auch wichtig?

Max ist in Fahrt: “Von wegen: “Nur ansehen, womit wir unser Geld verdienen”. Es gibt Systeme, Applikationen, Dienste, ja, von mir aus: “IT-Services”, die große Schmerzen und laute Geräusche in der Chefetage verursachen, wenn sie nicht funktionieren. Wehe, ein e-Mail kommt nicht sofort an, da laufen bei uns die Telefone heiß. Solche Services haben natürlich mehr Aufmerksamkeit, als jene, die nicht täglich wahrgenommen werden. Trotzdem müssen das nicht die wichtigsten Services für unser Geschäft sein. Und dann gibt es, in meinen Worten: “Geld-Druck-Services”. Jedes Unternehmen hat so was und wir haben auch mehrere Kandidaten.

Keine Details bitte! Wie ist die Gesamtkonfiguration?

“Es ist mir klar, dass es ratsam ist, diese, für’s Geschäft kritischen, Services zu dokumentieren. Mit allem, was dazu gehört und in einem definierten Status. Die Gesamtkonfiguration.Im Fall der Fälle stellen wir dann diese wieder her. Aber, wenn du meine Kollegen oder mich fragst: Das ist ja wieder ALLES, weil jedes System wiederum andere Systeme braucht um zu funktionieren!

Virtuelle Maschinen sind individuell konfiguriert und laufen auf physischen Maschinen, die ebenfalls eine gewisse Konfiguration haben. Die Verbindungen der Maschinen untereinander sind ebenfalls speziell. Datenbanken, Applikationen, Rechenzentrumsdienste wie DNS, DHCP, Directory, usw. braucht man auch dazu. Dann noch das gesamte Netzwerk, mit all seinen Diensten. Auch externe Leistungen, zum Beispiel Internet-Services, gehören dazu. Jedes Service braucht irgendwie auch alle anderen. Man kann also nicht ein einzelnes Service herausschneiden und die anderen ignorieren, oder?”

Kapon nickt. “Wir müssen irgendwo vereinfachen. Denn wir arbeiten “nach”. Wir machen sozusagen unser Haus sauber. Wir planen nicht am Reißbrett etwas Neues, wir beschäftigen uns mit dem, das schon da ist. Egal, wie es dazu kam. Es läuft.
Zusammenräumen, das geht nicht im ganzen Haus auf einmal, da muss man sich Raum für Raum her nehmen und anfangs über einige Räume hinwegsehen. Um im Wohnzimmer wohnen zu können, müssen wir nicht zwingend mit dem Saubermachen des Heizraumes und dem Dokumentieren der Heizung beginnen. Wir sagen einfach: Heizung ist da, wir können wohnen. Genauso ist es mit Licht, Strom und Wasser. Dort müssen wir vorerst grob bleiben und erst später ins Detail gehen. Ist ungefähr verständlich, was ich meine? Wir müssen uns bei der Dokumentation “Platzhalter” schaffen, die wir erst später dokumentieren! Da hilft uns der Begriff “IT-Service” schon gut weiter!”

Max greift sich einen Stift und ein Blatt Papier. “Ich glaube ich weiß was du meinst. Aber dazu machen wir einen eigenen Termin, ja? Sehen wir uns bitte jetzt an, wo wir unsere Dokumentationsenergie hinlenken: wo starten wir?”

Max hat im Kopf drei Faktoren festgemacht, woran er eine Priorisierung aufhängen will: Die tatsächliche Geschäftskritikalität, die Stabilität, die er subjektiv der jeweiligen Applikation zuschreibt und eben die Lautstärke bei Ausfall in der Chefetage. Nun will er herauszufinden, ob diese Kriterien für eine Priorisierung der Aufgaben im CMDB-Projekt anwendbar sind. Der Einfachheit geht er einmal von einer Störungsdauer von 1 Tag aus:

Nun addiert er die Werte und zeichnet eine kleine Grafik – schnell wird klar, wo sie rasch beginnen sollten zu dokumentieren…

“Eigentlich müsste ich diese Abfrage mit Geschäftsführer Sukero und jedem Abteilungsleiter machen”, wird Max klar. Sein Chef wirft ein: “Für den Start genügt das wahrscheinlich. Da sind wir auf dem richtigen Weg. Später wird es notwendig sein die maximal tolerierbare Ausfalldauer der Services zu erurieren. Und wenn erst mal unser neuer Online-Shop live geht, sollten wir die wichtigsten Systeme bereits fertig dokumentiert haben.”

 

Conclusio

Schmerz hilft! Dort beginnen, wo es weh tun könnte ist bei der Priorisierung für die Dokumentation und das IT-Notfallmanagement kein Fehler. So, wie unsere Helden ihre Business Impact Analyse durchführen, entspricht das sicher keinem Lehrbuch. So what! Warum nicht auf diese Weise an die komplexe Materie herangehen? Besser werden geht immer. Aber einfach nicht starten, weil die Methode nicht 100%ig ist, ist ja auch keine Lösung. Seien Sie hart und ehrlich zu sich. Es ist längst nötig sauber zu machen. Bitte nicht auf den nächsten Frühjahrsputz warten!

Feedback

Teilen Sie Ihre Erfahrungen zum Thema Priorisierung mit uns! Wir freuen uns auf Ihr Feedback unter info@i-doit.com oder via Twitter.

Wer hier schreibt:
Peter Resch-Edermayr arbeitet seit nahezu 20 Jahren als Berater an der 
Ausgestaltung von IT-Prozessen. Seit 2014 ist er als Evangelist für i-doit tätig. Situationen aus seinen Projekten verarbeitet er hier zu BLOG-EpisodenDie handelnden Personen sind daher auch nicht ganz frei erfunden, ihre Namen schon. Er begrüßt es, wenn Sie sich mit ihm über Xing oder Twitter vernetzen und austauschen.

Share This