Die unbekannten Single Points of Failure

Der Service verfügt über zwei Anwendungserver und eine Cluster-Datenbank, und im Architekturdiagramm sieht es sicher aus. Eines Tages fällt ein einzelnes Netzwerkgerät aus und der gesamte Service ist dunkel. Die Post-Incident-Überprüfung zeigt, dass beide Anwendungserver auf demselben Hypervisor liefen oder dass beide Datenbankinstanzen an demselben Speicherarray angeschlossen waren. Die Redundanz existierte nur in einer Schicht.

Solche Entdeckungen sind für alle unangenehm. Der Service Owner glaubte, geschützt zu sein. Das Betriebsteam könnte die Schwachstelle vermutet haben, aber es hatte keine Möglichkeit, sie zu beweisen. Und die Menschen, die den Incident in der Nacht bekämpften, fragen sich, warum niemand es kommen sah.

Warum einzelne Fehlerpunkte verborgen bleiben

Ein einzelner Fehlerpunkt (SPOF) ist selten ein Designfehler. Er ist normalerweise das Ergebnis einer allmählichen Abweichung. Die Infrastruktur ändert sich, virtuelle Maschinen bewegen sich, Kapazitäten werden neu zugewiesen. Was bei der Inbetriebnahme getrennt war, kann Monate später auf demselben Hardware enden.

• Redundanz wird Schicht für Schicht bewertet. Das Anwendungsteam sieht zwei Server, das Virtualisierungsteam sieht freie Kapazität, und niemand sieht die gesamte Kette.
• Diagramme erfassen die Absicht, nicht die Realität. Sie zeigen, wie die Dinge gemeint waren, nicht wo Systeme seitdem bewegt wurden.
• Resilienzprüfungen sind einmalige Übungen. Sie finden zum Zeitpunkt des Designs oder während eines Audits statt, nicht kontinuierlich.
• Wartung setzt Schwachstellen zu spät frei. Wenn beide Knoten eines redundanten Paares gleichzeitig gepatcht werden, geht der Service down, obwohl er formal redundant ist.

Eine bessere Art, über Resilienz nachzudenken

Die Service-Resilienz ist eine Eigenschaft der gesamten Abhängigkeitskette, nicht einzelner Komponenten. Sie muss daher auf Service-Ebene bewertet werden, über alle Schichten hinweg auf einmal. Wir empfehlen:

1. Redundanz explizit aufzeichnen. Welche Elemente stehen füreinander ein und bilden eine redundante Gruppe.
2. SPOFs kontinuierlich suchen, nicht einmal im Jahr. Jede Infrastrukturänderung kann die Antwort ändern.
3. Resilienz mit Simulation testen. Fragen Sie, was passiert, wenn eine bestimmte Komponente ausfällt.
4. Redundanz in die Wartung einbeziehen. Patchen Sie redundante Knoten nacheinander, damit der Service oben bleibt.

Wie Eywo Stratum damit umgeht

Eywo Stratum arbeitet mit einer mehrschichtigen Abhängigkeitskarte, von Business Services über Anwendungen, Datenbanken und Server bis hin zu Hypervisoren, Speicher und Netzwerk. Auf dieser Grundlage kann es:

• redundante Gruppen aufzeichnen, d.h. Elemente, die füreinander einstehen,
• einzelne Fehlerpunkte identifizieren, die Komponenten, deren Ausfall einen Service unabhängig von der Redundanz an anderer Stelle in der Kette trifft,
• Service-Resilienz bewerten und zeigen, wo ein Service geschützt ist und wo nicht,
• den Ausfall einer ausgewählten Komponente simulieren und die betroffenen Services und Anwendungen anzeigen.

Die Kenntnis von Redundanz prägt auch die Wartung. Änderungen können gegenstandsweise in einer rollenden Weise durchgeführt werden, sodass die Knoten einer redundanten Gruppe niemals zusammen heruntergefahren werden. In der Business-Edition unterstützt die Patch-Vereinbarung mit dem Service Owner rollendes Patchen von redundanten Knoten: Ein Knoten wird aktualisiert und überprüft, bevor der nächste folgt. Der Service bleibt auch während der routinemäßigen Wartung verfügbar.

Der Service Owner muss sich nicht mehr auf ein Diagramm verlassen. Er sieht den aktuellen Zustand, abgeleitet aus der CMDB, und weiß, worauf sein Service tatsächlich angewiesen ist.

Fazit

Einzelne Fehlerpunkte erscheinen nicht über Nacht, und eine einmalige Überprüfung wird sie nicht verschwinden lassen. Sie können nur gefunden werden, indem man einen Service als Ganzes betrachtet, über jede Schicht hinweg, mit einer aktuellen Ansicht. Unangenehme nächtliche Entdeckungen werden dann zu gewöhnlichen Posten auf dem Arbeitsplan, die ruhig und während der Geschäftszeiten behoben werden.

Redundante Gruppen, Single-Point-of-Failure-Analyse und Ausfallsimulation sind Teil der Standard-Edition; rollendes Patchen von redundanten Knoten als Teil des Patch-Managements ist in der Business-Edition enthalten.