Ist die Ursachenanalyse tot oder stehen wir erst am Anfang?

Kürzlich schickte mir ein Freund einen Link zu einem Blogbeitrag mit dem Titel "The myth of the Root Cause". Dieser Beitrag enthält einige gute Argumente. Vor allem der Punkt, dass mit der zunehmenden Komplexität unserer Systeme auch unsere Probleme zunehmen. Oft ist es schwer, eine einzige Ursache zu finden. Vielleicht gibt es sogar gar keine!

In dem Blogbeitrag: "Focus on Analysis: the end of root cause" behauptet der Autor (Matthew Boeckman), dass die Konzentration auf die Suche nach einer Grundursache sogar die falsche Einstellung bei der Analyse eines Vorfalls sein könnte. Wenn es so etwas wie eine Grundursache nicht gibt, kann die Suche danach als schädlich angesehen werden. Und noch einmal: Wenn unsere Systeme immer ausgefeilter werden, werden auch unsere Probleme immer größer.

Ist die Ursachenforschung in der IT tot? Das bringt mich zu meiner nächsten Frage.

Was meinen wir eigentlich mit "Grundursache"? 

Ich glaube, ein Teil der Missverständnisse rührt daher, was wir eigentlich mit "Ursache" meinen. Wörterbücher sind in dieser Hinsicht sicherlich nicht hilfreich (schauen Sie einfach selbst nach), aber die wenigen Definitionen, die es gibt, haben einige gemeinsame Vorstellungen.

Im Folgenden finden Sie die drei Schlüsselpunkte , die eine Grundursache definieren: 

1. Eine Grundursache ist die tiefste, grundlegendste, früheste Ursache, die zu einem Problem geführt hat.
2. Eine Grundursache sollte für den (RCA-)Prozess von Bedeutung sein. Einige Definitionen legen nahe, dass eine Grundursache etwas sein sollte, das auch behebbar ist und dass die Beseitigung der Grundursache zur Beseitigung des Problems führen sollte.
3. Es kann mehrere Ursachen für ein einziges Problem geben.

Obwohl die meisten Definitionen darin übereinstimmen, dass wir mehrere Ursachen in Betracht ziehen sollten, sind die meisten Menschen überrascht, wenn ich ihnen das sage. Und warum? Wenn wir voraussetzen, dass es eine einzige Ursache für alle Probleme gibt, dann ist es nicht unmöglich, in jedem Fall eine zu finden: Der Urknall ist die Ursache für alle Probleme. Aber wie soll das sinnvoll sein? Deshalb beinhalten die meisten Definitionen von "Grundursache" auch den zweiten Punkt, der dann zwangsläufig zum dritten Punkt führt.  

Warum suchen wir überhaupt nach den Ursachen? 

Wir möchten, dass die Lösungen, die wir auf den Tisch legen, einen maximalen ROI haben. Eine oberflächliche Lösung mag zwar das Problem lösen, kann aber nicht verhindern, dass eine leichte Variation desselben Problems auftritt. Solide Geschäftslogik.

Auch wenn es scheint, dass die IT-Branche insgesamt mit dem Konzept der RCA zu kämpfen hat, wird der Bedarf immer größer. Durch die Agile- und DevOps-Transformationen des letzten Jahrzehnts haben wir eine enorme Zunahme der Dynamik von IT-Landschaften erlebt. Die meisten Vorfälle bleiben heutzutage unter Kontrolle, aber wenn sie es nicht tun, kann es extrem schwierig sein, sie zu ihrem Ursprung zurückzuverfolgen.

Können wir die Ursachenanalyse automatisieren?

Das hängt davon ab, wie Sie "Ursache" definieren. Einige Definitionen machen es ziemlich schwer. Wenn wir zum Beispiel verlangen, dass eine Grundursache behebbar sein muss, dann müssen wir einem System beibringen, was behebbar ist und was nicht. Bei StackState verwenden wir jedoch eine Definition, die den drei Kernpunkten einer Ursache treu bleibt und gleichzeitig eine Automatisierung ermöglicht.

Hier ist unsere Definition für die Ursache:

"Eine Ursache, deren direkte oder indirekte Wirkung signifikant/bedeutsam mit dem Problem korreliert ist und deren direkte Ursachen nicht signifikant/bedeutsam mit dem Problem korrelieren. Ein Problem kann mehrere Ursachen haben, deren kombinierte Wirkung zu dem Problem geführt hat. Ursache und Problem (Wirkung) können weiter verfeinert werden, um entweder ein Ereignis oder einen Zustand zu bezeichnen."

StackState baut ein Modell Ihrer IT-Umgebung auf. Das bedeutet, dass StackState weiß, dass Ihre Microservices nicht miteinander kommunizieren können, wenn Ihr interner HTTP-Proxy nicht funktioniert, und dass dies zum Ausfall mehrerer kritischer Geschäftsfunktionen führen wird.   Dies ist ein Beispiel für das, was wir ein Kausalmodell nennen.

Bei einem gerichteten Graphen, der das Kausalmodell darstellt, können wir dann in die entgegengesetzte Richtung des Problems traversieren, bis wir auf einige Eckpunkte (Ereignisse oder Zustände) stoßen, die keine signifikante Korrelation mehr mit dem Problem aufweisen. Dieser Traversal kann in eine Suche nach mehreren Ursachen übergehen. Wir sollten bei diesem Traversal Teleports zulassen, damit wir Korrelationen finden können, die nicht strikt durch die Kanten des Graphen verlaufen.

Bei dieser Definition bleibt es dem Benutzer überlassen, was im Modell enthalten ist und was signifikant/bedeutsam ist, aber die Ursachen können automatisch zugeordnet werden.

Was ist eine Ursache?

Bei StackState haben wir Ursachen entweder als Zustände oder als Ereignisse definiert. Diese Neuerung erweist sich als eine unglaublich nützliche Art, eine Ursache zu definieren. Ein Ereignis bezieht sich auf einen Punkt oder ein Zeitintervall, das mit der realen Welt interagiert. Zum Beispiel eine Spitze im Netzwerkverkehr oder eine fehlerhafte Transaktion. Ein Zustand bezieht sich auf eine Eigenschaft eines Objekts, z.B. ein ausgefallener Server oder ein fast voller Verbindungspool.

Sowohl Ereignisse als auch Zustände können Teil einer Kette von Ursache und Wirkung sein. Sie sind auch austauschbar:  

• Ein Ereignis kann ein anderes Ereignis auslösen: Ein Werbespot während eines beliebten Sportereignisses kann eine Spitze des Netzwerkverkehrs verursachen.
• Ein Ereignis kann auch einen Zustand hervorrufen: eine Spitze im Netzwerkverkehr kann dazu führen, dass ein Server ausfällt.
• Ein Zustand kann einen anderen Zustand verursachen: Wenn der Server ausfällt, kann dies auch den Zahlungsserver in Mitleidenschaft ziehen.
• Und schließlich kann ein Zustand auch ein Ereignis auslösen: Wenn ein Server ausfällt, kann dies zu einer Zeitüberschreitung der Verbindung führen.

Jeder Zustand und jeder mögliche Zustandsübergang ist im Voraus bekannt. Wir nennen das einen Zustandsautomaten. Ein einfaches Beispiel wäre, dass ein Server entweder hoch- oder heruntergefahren sein kann. Es lassen sich aber auch komplizierte Zustandsautomaten konstruieren, die nicht nur mehrere Zustände, sondern auch die Bedingungen für die Zustandsübergänge vordefinieren.

Das Tolle an Zustandsautomaten ist, dass sie uns die Möglichkeit geben, über die Welt in Form von Möglichkeiten zu denken. Zum Beispiel kann eine Abwesenheit in der tatsächlichen Welt nicht existieren. Das wäre ein Paradoxon. Aber es könnte genau das sein, was wir als Grundursache bezeichnen würden. Wie können wir also auf etwas schließen, das nicht vorhanden ist? Mit Zustandsautomaten! Denken Sie darüber nach: Wie können Sie wissen, dass ein Glas leer ist, wenn Sie dies nicht als Zustand in einem Zustandsautomaten definiert haben?

Es gibt mehr Wechselwirkungen zwischen Zuständen und Ereignissen. Jeder Übergang zwischen Zuständen kann als Ereignis festgehalten werden. Das bedeutet, dass Ereignisse verwendet werden können, um Zustandsautomaten zu verifizieren oder sie zurückzuentwickeln.

Jetzt verstehen Sie, warum wir es für wichtig halten, beides zu haben. Während Ereignisse erklären, was passiert, beschreiben Zustände (und ihre Zustandsautomaten), was passieren kann. Beide sind vom Standpunkt der RCA aus gesehen unglaublich interessant.

Kontextbedingte Grundursachen

Was für einen Stakeholder in einem bestimmten Kontext von Bedeutung ist, kann für einen anderen Stakeholder in einem anderen Kontext nicht von Bedeutung sein. Wenn z.B. ein Fehler Ausfallzeiten verursacht hat, könnte der Entwickler, der den Fehler kodiert hat, die Komplexität der Codebasis als Ursache ansehen, während für den QA-Ingenieur die Tatsache, dass die Versionshinweise nicht vollständig waren, die Ursache ist.

Mehrere Ursachen aus verschiedenen Blickwinkeln können zu mehreren Lösungen führen, die alle einen großen ROI haben. Hätten wir auf einer einzigen Ursache bestanden, hätten wir vielleicht endlose frustrierende Debatten darüber geführt, was die wahre Ursache ist, und hätten möglicherweise die Tatsache übersehen, dass mehrere kleine Lösungen einen besseren ROI als eine einzige große Lösung bringen würden. Vielleicht müssen wir anfangen, über kontextbezogene Ursachen nachzudenken.

Räumliche und zeitliche Ursachen

Da wir mehrere Ursachen für verschiedene Aspekte eines Problems zulassen, können wir auch verschiedene Arten von Ursachen vordefinieren. Zum Beispiel räumliche und zeitliche Grundursachen. Eine räumliche Ursache sagt Ihnen, was derzeit (oder zu einem bestimmten Zeitpunkt) defekt ist und das Problem verursacht. Eine zeitliche Ursache sagt Ihnen, was passiert ist, um das Problem zu verursachen.

Ich möchte Ihnen zwei Beispiele nennen:

Problem: Benutzer kann keine Zahlung vornehmen.

Räumliche Ursache: Konten-Datenbank nicht ansprechbar.

Zeitliche Ursache: Select-Abfrage auf Konto mit 10 Mio. Transaktionen.

Die räumliche Ursache sagt uns, wo das Problem aufgetreten ist (die Datenbank), während die zeitliche Ursache uns sagt, warum das Problem aufgetreten ist (langsame Abfrage). Denken Sie daran, dass dieselbe zeitliche Ursache auch ein Problem in einem ganz anderen Teil des Stacks verursacht haben könnte, z.B. könnte dem http-Server der Speicher ausgegangen sein. Wenn Sie nur die zeitliche Ursache kennen, ist das möglicherweise uninteressant. Wenn Sie hingegen die räumliche Ursache hinzufügen, erfahren Sie genau das, was Sie wissen müssen.

Problem: Challenger-Raumfähre explodiert.

Räumliche Ursache: Gebrochene Dichtung um den O-Ring.

Zeitliche Ursache: Entscheidung, den Start nach einer Diskussion über ein mögliches O-Ring-Versagen fortzusetzen.

Natürlich kann kein Beitrag über die Ursachenanalyse vollständig sein, ohne die berüchtigte Challenger-Katastrophe zu erwähnen. Wie Sie sich vielleicht erinnern, wurde die eigentliche Explosion durch einen defekten O-Ring verursacht, der eine Kettenreaktion auslöste, die zur Explosion führte. Bei der weiteren Untersuchung stellte sich jedoch heraus, dass das tiefere Problem darin bestand, dass die NASA damals die Entscheidung traf, den Start trotzdem durchzuführen, nachdem Bedenken wegen des O-Rings geäußert worden waren.  

Die Grenzen von automatisiert RCA

Es wurde eine noch tiefere Ursache für die Explosion der Challenger festgestellt. Die Kultur der NASA war damals so, dass das Risiko der Mission als wichtiger angesehen wurde als die PR-Katastrophe, die aus einer (erneuten) Verschiebung der Mission in einem so späten Stadium resultiert hätte. Obwohl dies theoretisch als Zustand der NASA-Organisation modelliert werden könnte, werden Maschinen in den nächsten zehn Jahren nicht über solche metaphysischen Konzepte wie Organisationskultur nachdenken.

Unsere Definition erlaubt es zwar, diese Ursache zuzuordnen, aber solange sie nicht direkt oder indirekt beobachtbar ist (und somit weder zeitlich noch räumlich), wird sie leider nicht so bald automatisiert werden. Es wäre daher vielleicht genauer, die automatisierte RCA als assistierte RCA zu bezeichnen.

Fazit

Das Geschäft diktiert, dass es immer notwendig sein wird, Probleme an der Wurzel zu packen. Wenn Sie nach einem Vorfall keine RCA durchführen, bedeutet dies lediglich, dass Sie nicht überprüft haben, ob es eine Lösung mit einem besseren ROI gibt. Anstatt RCA abzuschaffen, müssen wir uns von der Idee einer 1:1-Zuordnung zwischen Problem und Ursache verabschieden und anfangen, über kontextbezogene Ursachen nachzudenken.  

Es ist schockierend, wie wenig Einblick die Unternehmen heutzutage noch in ihre Produktionsumgebungen haben, ganz zu schweigen von anderen Umgebungen. Wir müssen in den Aufbau besserer Modelle unserer IT-Umgebungen investieren. Auf diese Weise lässt sich die Geschwindigkeit, mit der RCA durchgeführt werden kann, erheblich steigern. Allein durch den Aufbau besserer Modelle lässt sich auf dem Gebiet der RCA noch so viel erreichen. Anstatt sie also für tot zu erklären, sollten wir uns eingestehen, wie unreif RCA in der IT wirklich ist. Wir fangen ja gerade erst an!

Wenn Sie StackState in Aktion sehen möchten, können Sie hier einen Termin für eine geführte Tour vereinbaren!