Lassen Sie mich Sie zu einem meiner schmerzhaftesten Vorfälle in der Produktion zurückbringen: Einer unserer Hauptdatenspeicher fiel während eines Vorgangs aus, den wir für einen einfachen Wartungsvorgang hielten.

Der Datenspeicher war damals eine Hauptkomponente in unserem System und stellte sich als Single Point of Failure heraus. Während es ausgefallen ist, konnten wir keine Anfragen bearbeiten.

Es wurde geschätzt, dass die vollständige Genesung ein paar Stunden dauern würde, was zu diesem Zeitpunkt wie eine Ewigkeit erschien.

Ungefähr zehn Minuten nach Beginn des Wiederherstellungsprozesses hatten einige talentierte Ingenieure des Incident-Response-Teams eine Idee, die unser System wieder zum Laufen bringen könnte: die Trennung der Logik, die den Datenspeicher verwendet, vom Hauptprozess, indem ein „Dooms-Day“ umgeschaltet wird. Konfigurationseinstellung, die wir hatten.

Klingt erstaunlich! Buchstäblich die erste Regel im Incident Response Rulebook – „stoppt die Blutung! Holen Sie das System wieder hoch“ . Nun – es stellte sich heraus, dass es nicht so einfach war, Regel eins im Regelbuch hat einige vage Implikationen, die wir gerade aufdecken wollten.

In diesem Beitrag werde ich erklären, dass, obwohl „das System wieder hochfahren“ unsere erste Priorität sein sollte, wir dies sicher tun müssen – wir müssen zuerst sehr sorgfältig definieren, was „hochfahren“ bedeutet .

Der Vorfall und die Reaktion

Zurück zu meiner Geschichte – unser System verarbeitete Nachrichten von einem Nachrichtenbus mit einem Microservice, der vom fehlerhaften Datenspeicher abhängig war.

Das erste, was wir taten, als wir das Problem identifizierten, war, unsere Mitarbeiter zu verkleinern, die Anfragen von einem unserer Nachrichtenbusse abholten.

Dadurch haben wir das Rauschen im System begrenzt und den betroffenen Diensten eine optimale Wiederherstellungsleistung ermöglicht. Der aktuelle Stand ist also, dass Anfragen jetzt in unserem Nachrichtenbus eingereiht wurden und darauf warten, verarbeitet zu werden.

Zurück zur Konfigurationseinstellung – wir haben darüber diskutiert, ob wir sie umschalten sollen oder nicht.

Das Umschalten bedeutete, dass wir das System mithilfe des Datenspeichers ausschalten und so das System „entsperren“ konnten – es wieder hochskalieren und mit der Verarbeitung des (bereits riesigen) Rückstands an Anfragen beginnen konnten. Aber der Microservice, der den fehlerhaften Datenspeicher nutzte, war aus einem bestimmten Grund da! Es spielte eine wichtige Rolle in unserem System – können wir ohne es gültige Ergebnisse liefern?

Diese Debatte dauerte etwa eine Stunde und umfasste verschiedene Personen aus der Organisation:

• Das Engineering-Team wollte es unbedingt einschalten und das System wieder zum Laufen bringen
• Einer der Geschäftskontakte im Incident Response Team fand heraus, dass das Umschalten unsere Leistung in einer Weise beeinträchtigt, die bei einigen unserer Top-Kunden zu einem Strand-SLA führen wird
• Als nächstes erwähnte der Leiter der Technik, dass es nachgelagerte Probleme verursachen könnte, wenn andere „Offline-Prozesse“ versuchen, teilweise verarbeitete Anfragen zu verarbeiten (teilweise = ohne die Eingabe des fehlerhaften Microservice).

Wir saßen nur da und warteten darauf, dass der Wiederherstellungsprozess abgeschlossen war. Obwohl dies die richtige Entscheidung war, war es dennoch ein schreckliches Gefühl.

Das Fazit ist, dass es „einfach“ ist, einen Vorfall zu mindern, wenn der Minderungsprozess das zugrunde liegende Problem behebt und das System in seinen korrekten Zustand zurückversetzt. Aber wenn der Minderungsprozess Ihr System in einen anderen schlechten Zustand versetzt , ist es viel schwieriger zu entscheiden, ob Sie diesen Weg der Minderung einschlagen möchten.

Die SLI-Pyramide

Zunächst ist es wichtig zu erwähnen, dass die Methode, die ich gleich vorschlagen werde, nicht immer möglich ist und stark von dem System abhängt, das Sie zur Hand haben, und von Ihrem Geschäfts- und Technologieverständnis sowie von der Geschäftshaltung Ihres Unternehmens.

Der Punkt, der unsere Entscheidung so schwierig machte, war, dass „ das System wieder zum Laufen zu bringen “ zu diesem Zeitpunkt nicht machbar war, wir konnten nur zwischen zwei unterschiedlich schlechten Zuständen wählen .

Ich schlage vor, dies anzugehen, indem ich etwas neu definiere, was „up“ bedeutet – statt eines einzelnen Zustands – betrachten Sie es als eine „SLI-Pyramide“, die eine visuelle Darstellung der SLI- Priorisierung ist . Das bedeutet, dass wir während des Systemdesigns, der Überprüfung des Systemessens oder zu jedem anderen Zeitpunkt entscheiden, welche unsere wichtigsten SLIs sind, und sie nach Wichtigkeit ordnen. Eine Beispielpyramide könnte so aussehen:

Diese Pyramide bedeutet, dass SLIs an der Spitze der Pyramide geopfert werden können, wenn wir die SLIs am unteren Ende der Pyramide sichern können – wenn wir gezwungen sind, zwischen schlechten Zuständen zu wählen, haben wir jetzt eine Möglichkeit, zu definieren, welche bevorzugt werden.

Betrachten Sie es als die Maslow-Pyramide Ihres Systems.

Im obigen Pyramidenbeispiel ist ein Vorfall in einen Zustand eskaliert, in dem sich sowohl die mobile Plattform in einem herabgesetzten Zustand befindet als auch wir ein Datenqualitätsproblem haben – wenn wir durch Ausschalten der mobilen Plattform das Datenqualifizierungsproblem beheben können – sind wir autorisiert ( und erwartet) es zu tun!

Die Pyramide sollte mit dem Product Owner, dem Unternehmen und allen Personen, die eine so wichtige Entscheidung absegnen können, definiert werden.

Es ist wichtig zu erwähnen, dass es nicht immer funktioniert und nicht immer möglich ist, diese diskrete Priorisierung vorzunehmen – aber in den meisten Fällen, denen ich begegnet bin, ist es durchaus machbar (auch wenn es etwas komplexere SLIs bedeutet), zum Beispiel, es kann sein etwas wie das:

Die Pyramide muss nicht 100 % der Anwendungsfälle, Vorfälle und SLIs abdecken, aber ich bin mir sicher, dass einige Ihrer SLIs so klar sind, dass sie leicht priorisiert werden können.

Ein Wort zur Analyseparalyse

In meiner Geschichte litt das Incident-Response-Team unter einem Zustand, der als Analyselähmung bezeichnet wird – es war nicht in der Lage, eine Entscheidung zu treffen, weil das Problem überanalysiert wurde .

Wir mussten stundenlang diskutieren und Alternativen und Ergebnisse abwägen, und selbst dann konnten wir nur durch Eskalation an eine Führungskraft des Unternehmens eine Entscheidung treffen.

Dies ist ein ziemlich frustrierendes Szenario – es ist frustrierend für das Reaktionsteam, das hilflos auf den Abschluss des Wiederherstellungsprozesses wartet, und frustrierend für den kreativen Ingenieur, der einen alternativen Minderungspfad gefunden hat, da wir damit nicht vorankommen.

Die SLI-Pyramide versucht, die wichtigsten SLIs des Systems vorab zu analysieren und die Entscheidungsfindung bei Ausfällen etwas zu erleichtern

Abschließende Gedanken

Ich glaube, dass die Anwendung dieser Methode wirklich dazu beitragen kann, Reibungsverluste bei Vorfällen zu reduzieren und die psychologische Sicherheit Ihrer Einsatzkräfte aufrechtzuerhalten. Dies ist auch eine großartige Möglichkeit, an Produktionsübungen oder „Spieltage“ zu denken, an denen wir die Wahl zwischen suboptimalen Minderungsschritten simulieren und verfolgen können, wie unser Reaktionsteam unter diesen schwierigen Bedingungen arbeitet.

Dieser Beitrag basiert auf meinem Vortrag „The (ir)rational Incident Response: How Psychological Biases Affect Incident Response“ und ist auf Englisch und Hebräisch verfügbar .

Wie immer sind Gedanken und Kommentare auf Twitter unter @cherkaskyb willkommen