Blog

Mentale Modelle: eine Überlegung zum AWS-Ausfall

João Rosa

João Rosa

Aktualisiert Oktober 21, 2025
8 Minuten

Im November 2020 kam es bei AWS zu einem größeren Ausfall, der mit dem Kinesis-Service begann und zu einem kaskadenartigen Ausfall bei einigen Diensten führte. Es gibt mehrere Artikel und Analysen zu diesem Ausfall, darunter auch die offizielle Mitteilung von AWS. Dieser Blog-Beitrag befasst sich mit dem Ausfall, aber anstatt sich auf die technischen Aspekte zu konzentrieren, werde ich tiefer in die sozialen Aspekte eintauchen, nämlich die mentalen Modelle.

Vorüberlegung: Was ist ein mentales Modell?

Ich werde mir zwei Definitionen für die mentalen Modelle ausleihen; die erste stammt von Kenneth Craik:

Wenn der Organismus ein "kleines Modell" der äußeren Realität und seiner eigenen Handlungsmöglichkeiten im Kopf hat, ist er in der Lage, verschiedene Alternativen auszuprobieren, die beste von ihnen zu wählen, auf zukünftige Situationen zu reagieren, bevor sie entstehen, das Wissen über vergangene Ereignisse im Umgang mit der Gegenwart und der Zukunft zu nutzen und in jeder Hinsicht viel umfassender, sicherer und kompetenter auf die Notfälle zu reagieren, mit denen er konfrontiert ist.

Und das zweite von Jay Wright Forrester, wo er allgemeine mentale Modelle definiert:

Das Bild der Welt um uns herum, das wir in unserem Kopf tragen, ist nur ein Modell. Niemand stellt sich in seinem Kopf die ganze Welt, die Regierung oder das Land vor. Er hat nur ausgewählte Konzepte und die Beziehungen zwischen ihnen und verwendet diese, um das reale System darzustellen.

Ich kann sagen, dass ein mentales Modell eine Darstellung von Konzepten und ihren Beziehungen ist, die uns hilft, über ein Problem/eine Herausforderung/was auch immer unsere geistigen Fähigkeiten erfordert, nachzudenken. Es wird von unseren Vorurteilen, vergangenen Erfahrungen, Wissen und Informationen beeinflusst. Mit Hilfe dieser Modelle versuchen wir, zukünftige Ereignisse vorherzusehen, und sie prägen unser Verhalten. Unsere mentalen Modelle sind nicht statisch, sie entwickeln sich weiter, auch wenn wir uns dessen meistens nicht bewusst sind. Beachten Sie, dass ich kein Spezialist für Verhaltens- oder Kognitionswissenschaften bin und dass noch mehr dahinter steckt, aber wir können uns vorerst mit diesen Definitionen und meiner eigenen Sichtweise begnügen.

Meine Überlegung

In der offiziellen Mitteilung von AWS heißt es gegen Ende der Nachricht:

Abgesehen von den Serviceproblemen kam es zu Beginn des Ereignisses zu einigen Verzögerungen bei der Kommunikation des Servicestatus an unsere Kunden. Wir haben zwei Möglichkeiten der Kommunikation während betrieblicher Ereignisse - das Service Health Dashboard, unser öffentliches Dashboard, um alle Kunden über allgemeine betriebliche Probleme zu informieren, und das Personal Health Dashboard, das wir zur direkten Kommunikation mit den betroffenen Kunden nutzen. Bei einem Ereignis wie diesem posten wir normalerweise auf dem Service Health Dashboard. Zu Beginn dieses Ereignisses konnten wir das Service Health Dashboard nicht aktualisieren, da das Tool, mit dem wir diese Aktualisierungen vornehmen, Cognito verwendet, das durch dieses Ereignis beeinträchtigt wurde. Wir haben eine Backup-Methode zur Aktualisierung des Service Health Dashboard, die nur minimale Serviceabhängigkeiten aufweist. Obwohl dies wie erwartet funktionierte, kam es zu Beginn des Ereignisses zu einigen Verzögerungen bei der Veröffentlichung von Updates im Service Health Dashboard mit diesem Tool, da es sich um ein manuelleres und weniger vertrautes Tool für unsere Supportmitarbeiter handelt. Um sicherzustellen, dass die Kunden rechtzeitig auf dem Laufenden gehalten wurden, benutzte das Support-Team das Personal Health Dashboard, um die betroffenen Kunden zu benachrichtigen, wenn sie von den Serviceproblemen betroffen waren. Wir haben außerdem eine globale Banner-Zusammenfassung auf dem Service Health Dashboard veröffentlicht, um sicherzustellen, dass die Kunden einen umfassenden Überblick über das Ereignis hatten. Während des restlichen Verlaufs des Ereignisses haben wir weiterhin eine Kombination aus dem Service Health Dashboard verwendet, sowohl mit globalen Bannerzusammenfassungen als auch mit dienstespezifischen Details, während wir gleichzeitig die betroffenen Kunden über das Personal Health Dashboard auf dem Laufenden hielten. Wir haben unsere Support-Schulungen dahingehend geändert, dass unsere Support-Techniker regelmäßig im Umgang mit dem Backup-Tool für die Einträge im Service Health Dashboard geschult werden.

Ich wurde von diesem Absatz angezogen und er ist der Grund für diesen Blogbeitrag: mentale Modelle und die Auswirkungen auf ein soziotechnisches System. Wie in dem Absatz erwähnt, haben die Betreiber von AWS-Services ein Backup-Verfahren zur Aktualisierung des Service Health Dashboard. Ich habe die Verzögerungen bemerkt, bei denen die öffentlich zugänglichen Informationen meldeten, dass alles in Ordnung war, aber die Dienste, die auf der AWS-Cloud liefen, waren ausgefallen. Und der bekannte DownDetector meldete den Ausfall.

Ich gehe davon aus, dass die AWS-Services stabil sind (das ist eine Tatsache) und die Menschen sich an die Zuverlässigkeit der Services gewöhnt haben. Die Menschen berücksichtigen nicht ihre mentalen Modelle, in diesem Fall die sekundären Prozesse während eines Ausfalls (das ist meine Annahme). Nach meiner Erfahrung in der Branche testen wir die Verfahren für Zwischenfälle (unabhängig von der Art des Zwischenfalls) nicht. Wir müssen noch von anderen Branchen lernen, in denen die Verfahren zur Verringerung der Risiken während eines Ausfalls ausgereift sind. Ich bin in diese Falle getappt und habe gesehen, wie meine Kollegen dasselbe taten (dies ist der Beginn meiner Überlegungen). Ich nenne sie die Zuverlässigkeitsfalle.

Wie entkommt man der Zuverlässigkeitsfalle?

Die Zuverlässigkeitsfalle ist in unserer Branche weit verbreitet. Ich beschreibe die Zuverlässigkeitsfalle, wenn Menschen, Teams und Organisationen IT-Systeme und -Prozesse als selbstverständlich ansehen, was zu vereinfachten Versionen ihrer mentalen Modelle führt. Sie tritt häufig auf, wenn Organisationen über hervorragende technische Verfahren verfügen und die IT-Systeme sehr zuverlässig sind (Beispiel Amazon) oder wenn die IT-Systeme und -Prozesse nicht unter einer Vielzahl von Anwendungsfällen leiden (Erhöhung der Last oder Verwendung für andere Zwecke, die nicht der ursprünglichen Absicht entsprechen).

In meinen Jahren als Ingenieur, Architekt, Berater und CTO habe ich Leitern "entwickelt", um der Falle zu entkommen, und mein Bewusstsein dafür geschärft. Mein Ziel ist es, nicht wieder in die Zuverlässigkeitsfalle zu tappen. Ich fasse zusammen, was ich gelernt habe und warum ich es verwende.

In erster Linie verwende ich Wardley Maps, um die Komponenten zu modellieren, die dem Umfang des Unternehmens zugrunde liegen, mit dem ich arbeite. Das hilft mir, ein Bewusstsein für die Landschaft zu entwickeln, und ich kann verschiedene Optionen für die verschiedenen Komponenten entwickeln (denken Sie an Was-wäre-wenn-Szenarien). Daneben und weil wir in soziotechnischen Systemen arbeiten, praktiziere und verwende ich die Sinnfindung, die ich von Cynefin übernommen habe. Anstatt meine eigenen Schlussfolgerungen auf der Grundlage meiner mentalen Modelle zu ziehen (die in hohem Maße von meinen Vorurteilen und Annahmen beeinflusst sind), verwende ich die Praktiken und Werkzeuge der Sinnfindung, um Erkenntnisse zu gewinnen. Diese beiden Praktiken und Schritte zusammen haben mir geholfen zu verstehen, wie Menschen ihre Rollen und Prozesse wahrnehmen.

Um die möglichen Konsequenzen der generierten Optionen zu überprüfen, wende ich Chaos Engineering an. Obwohl Chaos Engineering auf der technischen Ebene entstanden ist, verwende ich es auch auf der Ebene der Prozesse und der Organisation. Die Prinzipien sind die gleichen, aber wir haben nicht die gleichen Werkzeuge zur Verfügung. Wir sind Menschen, und wir können unsere Kreativität nutzen, um Experimente zu entwerfen, mit denen wir unsere Annahmen in einem größeren Rahmen überprüfen können. Ziel ist es, zu überprüfen, wie sich das soziotechnische System verhält, wie sich Menschen und Teams engagieren und ob die Prozesse eingehalten werden oder überholt sind. Weitere Einzelheiten finden Sie in einem früheren Beitrag. Es ist hilfreich, weil es einen sicheren Raum bietet, um die Annahmen und mentalen Modelle zu überprüfen. Wenn es zuverlässige Systeme gibt und die Menschen sich daran gewöhnt haben, wird es in einem realen Szenario (einem echten Ausfall) potenzielle Risiken aufdecken. Mit diesen Erkenntnissen und Erfahrungen aus erster Hand können die Mitarbeiter ihre mentalen Modelle in Frage stellen, und das Unternehmen kann sie dabei unterstützen, die Risiken zu mindern (denken Sie an Schulungsprogramme und passen Sie Prozesse an, die nicht sinnvoll sind und nur Hindernisse schaffen).

Im Anschluss an die Chaos-Experimente und als Teil der Retrospektiven verwende ich in der Regel das Maturity Mapping, eine Variante der Wardley Maps, die Bedeutung, Material und Kompetenz miteinander verbindet (mehr zu den Konzepten und dem Warum hier). Indem man die ursprünglichen Wardley Maps mit den Ergebnissen der Chaosexperimente anreichert, kann man das Delta diskutieren. Mit Delta meine ich die mentalen Modelle der Landschaft und das Ergebnis der Chaosexperimente. Die Darstellung des Deltas in einer Karte, nämlich einer Maturity Map, fängt die verschiedenen Perspektiven in einem soziotechnischen System ein und hat den Vorteil, dass zusätzlich zu den verschiedenen mentalen Modellen auch die Handlungsfähigkeit von Teams und der Zweck von Teams diskutiert werden kann. Als CTO kann ich die Organisation mit der richtigen Schulung, Moderation, Coaching und Mentoring unterstützen, da wir eine gemeinsame Basis haben. Die Menschen können mich auch herausfordern, mich zu verbessern, da mein eigenes Verhalten und meine mentalen Modelle das soziotechnische System beeinflussen; ich kann nach Schulungen, Coaching und Mentoring suchen, um die Lücke zu schließen.

Zusammengefasst

Heute, in einer Welt, die sich schneller bewegt, als wir es je erlebt haben, und in der wir uns nicht aller Zusammenhänge bewusst sind (es ist eine komplexe Herausforderung, die unsere Fähigkeit, genaue mentale Modelle zu haben, übersteigt), ist es von entscheidender Bedeutung, dass Organisationen in der Lage sind, sich ihre Optionen offen zu halten. Außerdem verfügen wir vor der Umsetzung einer Strategie über einen Wissensfundus, der es uns ermöglicht, die Richtung der Strategie zu testen und zu überprüfen, die Auswirkungen zu minimieren und den Irrtum der versunkenen Kosten zu vermeiden, der katastrophale Folgen haben kann (im Extremfall kann ein Unternehmen untergehen).

Ich habe diese Praktiken angewendet und lerne immer noch dazu :) Bei den Herausforderungen, denen ich mich gegenübersah, haben diese Praktiken die erwarteten Ergebnisse gebracht. Aber die Welt da draußen ist groß, und ich bin an Ihren Erfahrungen auf diesem Gebiet interessiert. Wie schaffen Sie es, sich zu erholen und die Zuverlässigkeitsfalle zu vermeiden?

 

Dieser Blogbeitrag wurde ursprünglich auf Joãos persönlichem Blog veröffentlicht: https://www.joaorosa.io/2021/01/11/mental-models-a-reflection-on-aws-outage/

Verfasst von

João Rosa

Contact

Let’s discuss how we can support your journey.