Was fällt aus, wenn dies ausfällt? Auswirkungen vor dem Ausfall

Das wöchentliche Betriebssitzungsmeeting diskutiert einen geplanten Speicherarray-Austausch. Jemand fragt: "Welche Dienste werden davon eigentlich betroffen sein?" Stille. Der Speicheradministrator weiß, welche Server angeschlossen sind. Das Virtualisierungsteam hat eine gute Vorstellung davon, welche virtuellen Maschinen darauf laufen. Aber wer weiß genau, welche Anwendungen und Business-Services darauf sitzen und wer informiert werden muss? Die Antwort wird aus mehreren Personen und mehreren Tabellen zusammengesetzt und ist oft unvollständig.

Die gleiche Frage taucht in einem schlechteren Moment auf. Das Monitoring meldet einen fehlgeschlagenen Hypervisor und der Service Desk kann nicht sagen, ob es sich um ein vergessenes Testsystem oder einen Dienst handelt, auf den Tausende von Menschen jeden Morgen angewiesen sind. Die Priorisierung stockt und die Personen, die das Problem beheben könnten, verbringen ihre Zeit damit, herauszufinden, was eigentlich kaputt ist.

Warum die Auswirkungen selten rechtzeitig bekannt sind

Organisationen verfügen über Abhängigkeitswissen. Es ist nur verstreut. Jedes Team sieht seine eigene Schicht und versteht sie gut. Was fehlt, ist eine Ansicht, die die Schichten verbindet.

• Architekturdokumentation veraltet mit jeder Änderung und nur wenige Personen halten sie aktuell.
• Eine CMDB ohne Beziehungen ist nur eine Liste von Elementen. Ohne Verbindungen kann sie nicht sagen, was von was abhängt.
• Monitoring sieht technische Komponenten, aber nicht die Business-Services, die darauf angewiesen sind.
• Change-Impact-Analyse wird manuell durchgeführt und hängt von der Erfahrung desjenigen ab, der sie schreibt.

Das Ergebnis ist, dass die Auswirkungen zum Zeitpunkt des Ausfalls entdeckt werden, wenn es zu spät ist, um zu planen oder zu kommunizieren.

Eine bessere Art, über Auswirkungen nachzudenken

Der Schlüssel besteht darin, Abhängigkeiten einmal zu modellieren und sie überall zu verwenden. Wenn die CMDB weiß, wie die Schichten miteinander in Beziehung stehen, vom Business-Service über die Anwendung, die Datenbank und den Server bis hin zum Hypervisor, Speicher und Netzwerk, kann die gleiche Frage in verschiedenen Situationen gestellt werden:

• Vor einer Änderung: Was wird während der Arbeit down oder beeinträchtigt sein?
• Während eines Incidents: Welcher Dienst ist betroffen und wer ist dafür verantwortlich?
• Bei der Verarbeitung von Monitoring-Ereignissen: Welche Alerts gehören zusammen und was ist die wahrscheinliche Ursache?
• Bei der Planung: Was passiert, wenn eine bestimmte Komponente ausfällt und wird der Dienst überleben?

Eine Abhängigkeitskarte dient dann sowohl dem Change-Management, den Incident-Responder als auch dem Monitoring-Team.

Wie Eywo Stratum es handhabt

Eywo Stratum zeigt eine mehrschichtige Abhängigkeitskarte: Business-Services, Anwendungen, Datenbanken, Server, Hypervisor, Speicher und Netzwerk. Für jedes Element können Sie sehen, was darauf läuft und was es laufen lässt.

Auf der Karte können Sie eine Ausfall-Simulation durchführen. Wählen Sie eine Komponente und Stratum zeigt, welche Dienste und Anwendungen betroffen wären und ob einige von ihnen durch Redundanz geschützt sind. Andere Teile des Produkts bauen auf dem gleichen Fundament auf:

• Incidents: Wenn ein Incident von einem CMDB-Element erhoben wird, schlägt Stratum den betroffenen Dienst, die Auswirkungen und das Resolver-Team vor. Die Priorität wird dann aus Auswirkungen und Dringlichkeit abgeleitet.
• Änderungen: Bevor eine Änderung eingereicht wird, werden ihre Auswirkungen berechnet, um zu zeigen, welche Dienste und Anwendungen nicht verfügbar oder beeinträchtigt sein werden. Der Eigentümer des betroffenen Dienstes genehmigt dann eine Ausfallzeit, die er tatsächlich versteht.
• Monitoring: Bei der Ereignisverwaltung werden Alerts basierend auf der CMDB-Topologie in Situationen gruppiert, sodass Sie eine wahrscheinliche Ursache sehen, anstatt Dutzender separater Benachrichtigungen.

Die Frage "Was bricht, wenn dies ausfällt?" wird dann aus Daten beantwortet, die das Team versteht, nicht durch Raten in einem Meeting.

Fazit

Sie können die Auswirkungen eines Ausfalls kennen, bevor er eintritt. Dazu benötigen Sie eine CMDB, die Beziehungen kennt, nicht nur Elemente, und ein Tool, das dieses Wissen bei Änderungen, Incidents und Ereignisverarbeitung einsetzt. Für Betriebsteams bedeutet dies weniger Raten in kritischen Momenten und mehr Zuversicht bei der Planung.

Die Abhängigkeitskarte, die Ausfall-Simulation und die Auswirkungen-Berechnung für Incidents und Änderungen sind Teil der Standard-Edition; die topology-basierte Alert-Gruppierung kommt mit der Business-Edition.