Abhängigkeiten in Notfallhandbuch darstellen

StephanBuerger

Hallo,

ich benutze das "Dokumenten Add-on" und möchte jetzt ein Handbuch erstellen, in dem unter anderem aufgeführt wird, welche Geräte in welcher Reihenfolge heruntergefahren und eingeschaltet werden müssen.

Zum Beispiel dürfen die Server A, B und C erst gestartet werden, wenn der Server S gestartet wurde. Umgekehrt darf Server S erst heruntergefahren werden, nachdem Server A, B und C beendet sind.

Natürlich kann ich das alles schreiben; aber es wäre schön, wenn es automatisch möglich wäre.

Zum Beispiel in einer "Baum-Ansicht".

Wenn dort steht

Switch 1 (alle Server unterhalb sind abhängig)

Server S
** Server A (ist abhängig von S)
--- Server D (ist abhängig von A)
** Server B (ist abhängig von S)
** Server C (ist abhängig von S)

Switch 2 (alle Server unterhalb sind abhängig)

Server H
** Server j

Hat jemand eine Idee, wie ich das am besten machen könnte?
Bei ca. 200 Servern und 20 Switchen wäre es extrem viel aufwand das von Hand zu machen.

Gruß
Stephan

vitamin-S

Hallo @StephanBuerger,
in der Regel servicieren Server etwas, sagen wir mal Service dazu. Meistens benötigt man zusätzlich zum Server auch noch andere Komponenten, damit ein Service voll funktionstüchtig ist. Zum Beispiel die wissenden Personen, Support- und Wartungsverträge, externe Partner oder andere Technologie, zum Beispiel auch externe Services aus der Cloud.

Du kannst natürlich auch nur bei den Servern bleiben, fix ist: Services werden tendenziell "größer", wenn du sie mal genau analysierst, als nur Server. Du kannst Services als Container oder Gruppen betrachten und ich empfehle dir von Anfang an Services zu verwenden. Server kommen und gehen, das Service bleibt.

Services sind natürlich auch von anderen Services abhängig.
Auf diese Weise modellierst du Service-Bausteine, ähnlich Lego, mit denen du jedes andere, neue, Service zusammenbaust.

Diese "Service-Chain", also eine Kette von Abhängigkeiten, kannst du sehr einfach in i-doit abbilden und mit dem CMDB Explorer darstellen. Natürlich sind Services auch Objekte, die du im Dokumenten Add-On verwenden kannst und natürlich sind diese Relationen Standard.

Die Reihenfolge beim Wiederanlaufplan (für ein Desaster Recovery) ergibt sich dann nur mehr aus den Services.

Beispiel:
Power(Service) -> Datacenter-Network(Service) -> DB-Service for CMDB(oder shared) -> CMDB Service (der Application Server) -> CMDB OK

Power -> Datacenter-Network -> Active Directory(Service) -> DB-Service for CRM -> CRM Application/Backend (Service)-> User Network (Service) -> CRM OK

Wundere dich nicht: Üblicher Weise hat man als IT Service Provider über hundert technische Services zu betreuen.
Und dann kommen noch die Business Services dazu, also jene, die ausschließlich das Business unterstützen. CRM ist so etwas.

IT Service Management ist genau das: Verwalten, Dokumentieren, Managen und im Notfall: Wiederherstellen von Services.

Wenn du erstmal deine Services kennst, kannst du auch so Planspiele mit den Ansprechpartnern aus dem Business machen wie: Welche Services brauchen wir denn UNBEDINGT, damit unsere Firma überlebt? Und die gruppierst du dann zu einer Gruppe oder wiederum zu einem "Notfall-Service".

Gutes Gelingen und beste Grüße!
Peter

P.S.: Das mit "unterhalb" und "oberhalb" musst du dir nochmals genau ansehen, am besten mit dem CMDB Explorer. In der ITSM Branche ist es üblich zu sagen: wenn das "untere" Objekt einen Fehler hat, kann das "obere" nicht, oder nur eingeschränkt funktionieren. Bäume oder Maps oder Graphen in der CMDB, oder wie auch immer du es nennen willst, sind also "Abhängigkeiten" im Sinne der Verfügbarkeit. Dein Beispiel vom Switch wäre also umgekehrt zu modellieren: Der Switch "ermöglicht" das Core-Network-Service und dieses Service ist ziemlich weit "unten".

StephanBuerger

Hallo Peter,

danke für die ausführliche Antwort. Das alles ist mir bekannt.
Mir ging es darum, wie ich das in einem Notfallhandbuch (PDF) visualisiere.
Im Notfall ist ja i-doit Unterumständen nicht verfügbar

Gruß
Stephan

leobaer

Hi
Ich glaube das Dokumenten Add-On hat hier einen anderen Fokus.

Ich würde in die Richtung gehen, die Daten per REST API auszulesen und dann geeignet darzustellen.
Das kann ein sauberes CSV pro Service sein. (Da kann man die erledigten Komponenten schön abhaken)
Oder auch eine MindMap.

Wenn Du das Zielformat bzw. die Zieldarstellung hast, kannst Du eine geeignete Datenstruktur in i-doit definieren und befüllen (falls die Abbildung als Service nicht geeignet ist)

Grüße
Leo