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