Dieser Beitrag wurde ursprünglich im Jeli-Blog veröffentlicht. Jeli wurde 2023 von PagerDuty übernommen und wir veröffentlichen ihn hier erneut, um unserer Community ihre Vordenkerrolle nahezubringen.

Während Sie die Lernbesprechung moderieren, kommen ganz natürlich Ideen für Änderungen oder Pläne auf. Bei Vorfallbesprechungen wollen die Leute Lösungen finden, oft bevor das Problem vollständig verstanden ist. Widerstehen Sie diesem Drang! Anstatt sich in der Lernbesprechung die Zeit zu nehmen, um auszuarbeiten, wie diese Pläne aussehen sollen, sollten Aktionspunkte idealerweise getrennt von der Hauptbesprechung der Lernbesprechung behandelt werden. Wir empfehlen, wenn möglich, eine komplett separate Besprechung abzuhalten. Dies hilft dabei, den Fokus der Lernbesprechung auf das Lernen zu richten. Wenn dies nicht möglich ist, identifizieren Sie die Punkte, die am Ende der Besprechung bearbeitet werden müssen, und weisen Sie die Leute an, zu einem späteren Zeitpunkt und an einem bestimmten Ort weitere Diskussionen mit den erforderlichen Interessenvertretern zu führen. Aber beginnen wir zunächst damit, welche Arten von Aktionspunkten die richtigen sind.

Was sind die richtigen Maßnahmen?

Nehmen wir dieses Vorfallszenario: Am Gandalf-Dienst wurde eine Änderung vorgenommen, die es Kunden ermöglicht, eine neue Aktion auszuführen. Dies erhöhte den Datenverkehr zum Atlas-Dienst, wodurch ein Fehler aufgedeckt wurde, der seit Jahren im Code vorhanden war. Die Reaktion war langwierig, da alle Anzeichen darauf hindeuteten, dass Atlas betroffen war. Das Team fügte Kapazitäten hinzu, hatte aber keinen vollständigen Kontext zu den an Gandalf vorgenommenen Änderungen. Es dauerte eine Weile, die richtigen Leute in den Raum zu bringen, und jetzt gibt es einige Streitigkeiten zwischen den Teams.

Wo liegen die „richtigen“ Aktionspunkte? Sicherstellen, dass das Gandalf-Team dem Atlas-Team immer Bescheid sagt, bevor es eine Änderung vornimmt? Diesen Fehler im Code beheben? Etwas hinzufügen, um diesen Fehler in einer Testsuite abzufangen? Warnmeldungen hinzufügen, um anzuzeigen, wann Kunden diese bestimmte Aktion ausführen? Kapazität für diesen Dienst automatisch skalieren? Kunden daran hindern, diese Aktion auszuführen? Es könnte alles davon sein, es könnte aber auch nichts davon sein. Die einzige „richtige“ Antwort hier ist: es kommt darauf an.

Beim Erstellen von Aktionselementen ist es am wichtigsten, das beabsichtigte Ergebnis zu verstehen. Soll verhindert werden, dass sich Aspekte dieses sehr spezifischen Fehlerszenarios erneut wiederholen? Dies könnte zum Beispiel der Fall sein, wenn es bestimmte Risiken gibt, die gemindert werden müssen. Soll ein Einblick gewonnen werden, wie Menschen und Systeme zusammenarbeiten, wenn etwas schief geht?

Wenn Sie Änderungsvorschläge machen, sollten Sie sich am besten auf das System als Ganzes konzentrieren und nicht nur auf einen Teil (wie eine Einzelperson). Wenn Sie feststellen, dass Sie nach Befehls- und Kontrolllösungen greifen, kann dies ein Zeichen dafür sein, dass Sie bei der Suche nach systemischen Änderungen vom richtigen Weg abgekommen sind. Dies gilt insbesondere, wenn es sich bei dem Punkt um eine Richtlinienänderung nach einem Fehler handelt, um „Fehler X nicht noch einmal zu machen“. Ein Aktionspunkt wie dieser weist darauf hin, dass noch mehr über die Umstände dieses Fehlers und die Optionen, die Einzelpersonen in dieser Situation zur Verfügung stehen, gelernt werden muss.

Wer sollte Aktionspunkte erstellen? Wer sollte sie „besitzen“?

Aktionspunkte sollten von denjenigen erstellt und verwaltet werden, die für die Umsetzung der Pläne und die Ausführung der Arbeit verantwortlich sind. Oft sind diese Punkte komplexer als ein einzelnes Ticket und es muss überlegt werden, welche Projekte geplant oder welche Vorschläge/Entwürfe für Änderungen verfasst werden sollen. Das Erstellen von Aktionspunkten, die andere ausführen sollen, ist ein Weg, um Verwirrung, Debatten und Widerstand zu erzeugen. Wenn etwas getan werden muss, sind die Leute, die täglich in diesen Bereichen arbeiten, die besten Leute, um herauszufinden, was getan werden muss, ob es getan werden sollte und wie es umgesetzt werden kann.

Aktionspunkte müssen nicht unbedingt etwas sein, das in Ihr Ticketsystem oder Ihre Engineering-Arbeit einfließt. Aktionspunkte können das Ändern, Aktualisieren, Abschaffen oder Erstellen neuer Prozesse auf der Grundlage von Feedback aus der Überprüfung umfassen. Sie können beispielsweise darin bestehen, mehr über eine bestimmte Technologie zu lernen, einen Teil des Systems zu untersuchen oder sogar andere zu unterrichten – beispielsweise einen Überblick über die Architektur zu geben, um das Verständnis dafür, wie die Dinge zusammenarbeiten, neu auszurichten.

Es mag verlockend sein, Fälligkeitsdaten für die Fertigstellung von Aktionselementen festzulegen. Dies ist sinnvoll, wenn der Zeitpunkt pro Element basierend auf der aktuellen Arbeitsbelastung und der Zeit, die zur Entwicklung der Lösung benötigt wird, bestimmt wird. Pauschale SLAs für die Fertigstellung von Aktionselementen bewirken nur eines: Aktionselemente werden speziell so dimensioniert, dass sie innerhalb dieses Zeitrahmens fertiggestellt werden. Sofern Ihre Projekt- und Produktmanager nicht planen, dass die aus einem Vorfall resultierende Arbeit sofort Vorrang vor allen bestehenden Fristen hat, zwingt die Anforderung, dass Aktionselemente für Vorfälle innerhalb eines bestimmten Zeitrahmens fertiggestellt werden müssen, die Ingenieure dazu, Kompromisse mit anderen wichtigen Prioritäten einzugehen.

Die Art und Weise ändern, wie wir über Aktionspunkte denken

Im Bereich technischer Vorfälle liegt der Fokus tendenziell viel stärker auf der Fehlerreduzierung als auf der Gewinnung von Erkenntnissen. Das ist verständlich, da Fehler bereits sichtbar und daher leichter zu beheben sind, aber das nützt uns nicht so viel, wie wir denken.

Nach einem Vorfall herrscht oft das Gefühl, das Ziel bestehe darin, zu verhindern, dass sich dieser Vorfall jemals wieder ereignet. Die Wahrheit ist jedoch, dass wir, egal was wir tun, diesen genauen Vorfall wahrscheinlich nie wieder erleben werden. Wir können durch eine Reihe technischer Abhilfemaßnahmen verhindern, dass sich sehr spezifische Vorfallszenarien wiederholen. Aber wir können neue Vorfälle nicht verhindern, die möglicherweise andere Faktoren mit derselben oder einer ähnlichen Auswirkung haben. Dies ist die Realität von Vorfällen in zunehmend komplexen Systemen: Verschiedene Auslöser, beitragende Faktoren und Risiken verschmelzen zu einem neuen und anderen Problem, das sich auf die Funktionsweise dieses Dienstes, Systems oder Features auswirkt. Sogar die technischen Abhilfemaßnahmen für die Vorfälle von heute können ein Faktor für den Vorfall von morgen sein.

Das soll nicht heißen, dass technische Abhilfemaßnahmen schlecht oder nicht hilfreich sind. Sie sind oft sofortige Lösungen, die erforderlich sind, um die Auswirkungen auf den erwarteten Betrieb wiederherzustellen, oder offensichtliche Probleme wie „Tool bestätigt vor dem Löschen nicht“, die behoben werden können. Wenn das Ziel jedoch darin besteht, ein widerstandsfähigeres System aufzubauen, reichen technische Abhilfemaßnahmen nicht aus.

Soziotechnische Systemeinblicke = echte Resilienz

Wenn ein Vorfall ähnliche Auswirkungen wie ein vorheriger hat, sind es wahrscheinlich nicht die vorherigen technischen Abhilfemaßnahmen, die zur Lösung des neuen Problems beitragen. Es sind die Erkenntnisse über die soziotechnischen Systeme, die wir bei jenem Vorfall gewonnen haben, die uns helfen, auf den neuen Vorfall besser zu reagieren.

Wir haben erlebt, dass Learning Reviews durch Diskussionen zu folgenden Themen tiefe Einblicke in soziotechnische Systeme ermöglichen:

• Wie wir auf die verfügbaren Systemdaten zugreifen, diese überwachen und Warnmeldungen dazu abgeben
• Wie wir diese Daten entschlüsseln und wie wir wissen, was sie anzeigen
• Wie wir wissen, welche Leute wir zusammentrommeln müssen, um bei dem, was wir sehen, zu helfen
• Wie wir miteinander und mit unseren Kunden über aktuelle Entwicklungen sprechen
• So bestimmen wir, welche Wege zur Sanierung eingeschlagen werden müssen
• So erkennen wir, ob die Sanierung wirksam war
• Durch die Gewinnung von Einblicken in diese (und andere) Aspekte der Leistungserbringung können wir die Quellen der Widerstandsfähigkeit des Systems entdecken.

Unsere Systeme und Menschen wachsen, entwickeln sich und verändern sich ständig. Die Erkenntnisse, die wir aus jedem Vorfall gewinnen, sind die Grundlage dafür, dass wir unsere Systeme und einander immer besser verstehen lernen. Wenn wir dem Lernen als unserer Reaktion Priorität einräumen, wenn etwas schief geht, konzentrieren wir uns darauf, zu verstehen, was wir vorher oder während des Vorfalls nicht wussten, anstatt sofort nach Dingen zu suchen, die behoben werden müssen. Aus unserer neuen, fundierteren Perspektive können wir dann feststellen, ob Maßnahmen erforderlich sind, und von denjenigen, die dem Problem am nächsten sind, erfahren, wie Lösungen aussehen könnten.

Ausführlichere Informationen zu diesen und anderen Themen finden Sie jederzeit unter Howie: Der Leitfaden nach dem Vorfall für weitere Informationen zur Vorfallanalyse.