Ein Switch fällt aus – der Service steht noch nicht

Um zwei Uhr nachts fällt einer der beiden Switches in einem Rack aus. Die Server sind an beide angeschlossen, die Services laufen weiter. Das Monitoring meldet trotzdem Dutzende Alerts, die Abhängigkeitskarte färbt sich rot, und in der Morgenbesprechung lesen die Service-Verantwortlichen, ihr Service sei „beeinträchtigt“ gewesen. Das war er nicht. Er lief nur ein paar Stunden ohne Absicherung.

Der umgekehrte Fall ist schlimmer. Fünf virtuelle Server melden Alerts, der Host, auf dem sie laufen, bleibt still, weil das Monitoring ihn nicht sieht. Es entstehen fünf getrennte Meldungen, fünf Personen untersuchen ihren Server, und die eigentliche Ursache bleibt unbemerkt.

Beides hat dieselbe Wurzel: Das Werkzeug weiß, was womit verbunden ist, aber nicht, was der Ausfall eines Teils tatsächlich bewirken würde.

Reichweite ist nicht Auswirkung

Die meisten CMDBs beantworten die Frage, was von einem Element abhängt. Eine ehrliche Antwort braucht aber mehr als eine Liste von Beziehungen:

• Redundanz. Ein Server an zwei Switches übersteht den Ausfall eines davon. Eine Firewall ersetzt jedoch keinen Switch, und eine Management-Netzwerkschnittstelle ersetzt keine Datenschnittstelle.
• Den Zustand der Elemente. Ein geplanter zweiter Switch, der noch nicht in Betrieb ist, sichert nichts ab. Eine Komponente in Wartung ist während des Changes faktisch außer Betrieb.
• Die Art der Beziehung. Verwaltung (die Konsole, die einen Server steuert), Replikation und Backup geben keinen Ausfall weiter. Ein Server hört nicht auf zu arbeiten, weil seine Replik ausgefallen ist.

Wenn ein Werkzeug das nicht unterscheidet, ist jede Auswirkungsanalyse übertrieben. Die Menschen hören auf, ihr zu vertrauen, und kehren zu Schätzungen in Besprechungen zurück.

Drei Zustände statt zwei

Stilla unterscheidet jetzt drei Situationen:

• Ausfall – das Element funktioniert nicht, weil alle seine Stützen ausgefallen sind.
• Beeinträchtigt – das Element funktioniert ohne einen Teil seiner Funktionen oder mit geringerer Leistung.
• Gefährdet – nur eine der redundanten Komponenten ist ausgefallen. Das Element läuft weiter, aber ohne Absicherung.

„Gefährdet“ wird beim nächsten abhängigen Element und bei den Services darüber angezeigt, die den Hinweis „ohne Redundanz“ erhalten. Weiter wird es nicht weitergegeben. Der Ausfall eines Switches aus einem Paar markiert also nicht mehr Hunderte Elemente, sondern nur das, was tatsächlich seine Absicherung verloren hat. Der Ausfall beider Switches ist dann korrekt ein Ausfall.

Auf derselben Berechnung beruhen weitere Teile des Produkts. Wird ein Change an einer redundanten Komponente geplant, erfährt der Service-Verantwortliche, dass der Service ohne Absicherung laufen wird, muss aber nichts freigeben, und der Change ist auch außerhalb des Wartungsfensters möglich. Die Prüfung auf Single Points of Failure behandelt geplante Elemente als fehlend, sodass verborgene Schwachstellen auffallen, bevor sie sich bemerkbar machen.

Eine Karte, die zeigt, was passieren würde

Die Abhängigkeitskarte hat drei Änderungen erhalten:

• Verwaltungsbeziehungen sind eine eigene Ebene, standardmäßig ausgeblendet. Die Ansicht, wovon ein Service abhängt, zeigt so nur echte Abhängigkeiten und nicht alles, was ihn verwaltet.
• Die Ansicht, was von einem Element abhängt, simuliert sofort seinen Ausfall. Farbige Elemente wären betroffen, graue hängen nur redundant oder über die Verwaltung davon ab.
• Der Auswirkungspfad hebt die Kette von der Ursache zu jedem betroffenen Service hervor, einschließlich der Ports, Schnittstellen und Zonen auf dem Weg. Man sieht, wie ein Ausfall einen Service erreicht, und kann es der Leitung oder einem Kunden erklären.

Ereigniskorrelation nach derselben Logik

Das Event-Management fasst zusammengehörige Alerts zu einer Situation zusammen und markiert die wahrscheinliche Ursache. Neu geschieht das per Ausfallsimulation:

• Ursache kann nur ein Element sein, dessen Ausfall die Alerts tatsächlich erklärt. Ein Alert an einem Switch aus einem Paar ist daher nicht die Ursache für den Ausfall des Servers darunter, und der Operator kümmert sich nicht um das falsche Element.
• Unter mehreren Kandidaten gewinnt derjenige, der die meisten Alerts erklärt. Melden ein virtueller Server, sein Host und sein Datastore Alerts, erhält die Situation die tiefere Ursache, nicht die zeitlich erste.
• Von der Ursache erklärte Alerts sind Folgealarme. Sie sind in der Situation sichtbar, lösen aber keine Benachrichtigungen aus, zählen nicht zu den Rauschkennzahlen und werden zusammen mit der Ursache aufgelöst.
• Abgeleitete Ursache. Melden mehrere Elemente Alerts und schweigt ihre gemeinsame Stütze, leitet Stilla sie aus der CMDB ab und legt eine Situation mit dem Vermerk „aus der Topologie abgeleitet“ an. Der Operator weiß, wo er anfangen soll, auch wenn das Monitoring dieses Element nicht sieht.

Die Priorität eines Alerts und eines vorausgefüllten Incidents richtet sich nach der tatsächlichen Auswirkung auf den Service. Ein Alert an einer redundanten Komponente erhält daher nicht mehr die Priorität eines kritischen Services, den er nicht gefährdet, und die Warteschlange des Operators bleibt übersichtlicher.

Prozesse, die ineinandergreifen

Die Behebung erfolgt meist durch einen Change. Ein Change kann mehrere Incidents und ein Problem lösen, und sein Ergebnis wird in alle verknüpften Datensätze übernommen. Ein Problem mit dokumentierter Ursache geht nach einem erfolgreichen Change in den Status Gelöst, ein gescheiterter Change führt es zurück in die Analyse, und die Melder der Incidents werden benachrichtigt. Treten nach Abschluss des Changes Alerts an seinen Elementen auf, ist das Review nach dem Change Pflicht, und ein Incident lässt sich mit einem Klick anlegen.

Fazit

Eine Auswirkungsanalyse ist nur etwas wert, wenn man ihr vertraut. Deshalb muss sie einen Ausfall vom Verlust der Absicherung unterscheiden, und dieselben Zahlen müssen bei der Planung eines Changes, bei einem Incident und in dem Moment gelten, in dem das Monitoring Dutzende Alerts meldet. Für den Betrieb heißt das weniger nächtliche Anrufe wegen Folgealarmen, ein schnellerer Weg zur eigentlichen Ursache und Besprechungen, in denen niemand über die Auswirkung streitet.

Die Abhängigkeitskarte, die drei Auswirkungszustände, der Auswirkungspfad und die Verknüpfung von Changes mit Incidents und Problemen gehören zur Edition Standard. Ereigniskorrelation per Ausfallsimulation, Folgealarme und abgeleitete Ursachen gehören zur Edition Business.