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 die Vordenkerrolle des Unternehmens näherzubringen.

Während Sie die Lernbesprechung moderieren, kommen ganz natürlich Ideen für Änderungen oder Pläne auf. Bei Vorfallbesprechungen wollen die Teilnehmer Lösungen finden, oft bevor das Problem vollständig verstanden ist. Widerstehen Sie diesem Drang! Anstatt sich im Lernbericht die Zeit zu nehmen, diese Pläne auszuarbeiten, sollten Aktionspunkte idealerweise getrennt vom eigentlichen Lernbesprechungsmeeting behandelt werden. Wir empfehlen, wenn möglich, ein separates Meeting abzuhalten. So bleibt der Fokus des Lernberichts auf dem Lernen. Ist dies nicht möglich, identifizieren Sie die Punkte, die am Ende des Meetings bearbeitet werden müssen, und weisen Sie die Teilnehmer an, diese zu einem späteren Zeitpunkt und an einem bestimmten Ort mit den erforderlichen Stakeholdern weiter zu besprechen. Doch zunächst einmal sollten wir uns mit den richtigen Aktionspunkten befassen.

Was sind die richtigen Maßnahmen?

Nehmen wir folgendes 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 und brachte einen seit Jahren im Code vorhandenen Fehler ans Licht. Die Reaktion zog sich hin, da alle Anzeichen auf eine Beeinträchtigung von Atlas hindeuteten. Das Team hatte zwar Kapazitäten hinzugefügt, verfügte aber nicht über den vollständigen Kontext der an Gandalf vorgenommenen Änderungen. Es dauerte eine Weile, die richtigen Leute ins Boot zu holen, und nun gibt es einige Streitigkeiten zwischen den Teams.

Wo liegen die „richtigen“ Aktionspunkte? Sicherstellen, dass das Gandalf-Team das Atlas-Team immer informiert, bevor es eine Änderung vornimmt? Diesen Fehler im Code beheben? Etwas hinzufügen, um diesen Fehler in einer Testsuite abzufangen? Warnmeldungen hinzufügen, die anzeigen, wann Kunden diese bestimmte Aktion ausführen? Die 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 keines davon sein. Die einzig „richtige“ Antwort hier ist: Es kommt darauf an.

Beim Erstellen von Aktionspunkten ist es besonders wichtig, das gewünschte Ergebnis zu verstehen. Soll verhindert werden, dass bestimmte Aspekte dieses spezifischen Fehlerszenarios erneut auftreten? Dies könnte beispielsweise der Fall sein, wenn bestimmte Risiken gemindert werden müssen. Soll ein Einblick in die Zusammenarbeit von Menschen und Systemen gewonnen werden, wenn etwas schiefgeht?

Bei Änderungsvorschlägen ist es am besten, sich auf das System als Ganzes zu konzentrieren und nicht nur auf einen Teil (z. B. eine einzelne Person). Wenn Sie feststellen, dass Sie zu Befehls- und Kontrolllösungen greifen, kann dies ein Zeichen dafür sein, dass Sie bei der Suche nach systemischen Veränderungen vom Weg abgekommen sind. Dies gilt insbesondere, wenn es sich um eine Richtlinienänderung nach einem Fehler handelt, um „Fehler X nicht noch einmal zu machen“. Ein solcher Aktionspunkt zeigt, dass noch mehr über die Umstände dieses Fehlers und die Optionen, die Einzelpersonen in dieser Situation zur Verfügung stehen, zu lernen ist.

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

Aktionspunkte sollten von den Verantwortlichen erstellt und verwaltet werden, die für die Umsetzung der Pläne und die Ausführung der Arbeiten verantwortlich sind. Oft sind diese Punkte komplexer als ein einzelnes Ticket, und die Planung von Projekten oder das Verfassen von Änderungsvorschlägen/-plänen erfordert eine sorgfältige Planung. Das Erstellen von Aktionspunkten für andere kann zu Verwirrung, Debatten und Widerstand führen. Wenn etwas umgesetzt werden muss, sind die Mitarbeiter, die täglich in diesen Bereichen arbeiten, am besten in der Lage, herauszufinden, was getan werden muss, ob es getan werden sollte und wie es umgesetzt werden kann.

Aktionspunkte müssen nicht unbedingt in Ihr Ticketsystem oder Ihre Engineering-Arbeit einfließen. Aktionspunkte können das Ändern, Aktualisieren, Abschaffen oder Erstellen neuer Prozesse basierend auf dem Feedback aus der Überprüfung umfassen. Sie können beispielsweise darin bestehen, mehr über eine bestimmte Technologie zu erfahren, einen Teil des Systems zu untersuchen oder andere zu unterrichten – zum Beispiel einen Architekturüberblick zu geben, um das Verständnis für das Zusammenspiel der Dinge zu verbessern.

Es mag verlockend sein, Fälligkeitstermine für die Fertigstellung von Aktionspunkten festzulegen. Dies ist sinnvoll, wenn der Zeitplan pro Punkt anhand der aktuellen Arbeitsbelastung und der für die Lösungsentwicklung benötigten Zeit festgelegt wird. Pauschale SLAs für die Fertigstellung von Aktionspunkten bewirken nur eines: die Dimensionierung der Aktionspunkte, sodass sie innerhalb dieses Zeitrahmens abgeschlossen werden können. Sofern Ihre Projekt- und Produktmanager nicht planen, dass die aus einem Vorfall resultierende Arbeit sofort Vorrang vor allen bestehenden Terminen hat, zwingt die Anforderung, dass Aktionspunkte innerhalb eines bestimmten Zeitrahmens abgeschlossen werden müssen, die Ingenieure zu Kompromissen mit anderen wichtigen Prioritäten.

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. Doch das nützt uns nicht so viel, wie wir denken.

Nach einem Vorfall herrscht oft das Gefühl, das Ziel bestehe darin, eine Wiederholung dieses Vorfalls zu verhindern. Die Wahrheit ist: Egal, was wir tun, genau diesen Vorfall wird es wahrscheinlich nie wieder geben. Wir können ganz bestimmte Vorfallszenarien durch eine Reihe technischer Abhilfemaßnahmen verhindern. Neue Vorfälle mit unterschiedlichen Faktoren und gleichen oder ähnlichen Auswirkungen können wir jedoch nicht verhindern. So sieht die Realität bei Vorfällen in zunehmend komplexeren Systemen aus: Verschiedene Auslöser, Faktoren und Risiken verschmelzen zu einem neuen und anderen Problem, das die Funktionsweise des jeweiligen Dienstes, Systems oder Features beeinträchtigt. Selbst die technischen Abhilfemaßnahmen für heutige Vorfälle können zu morgigen Vorfällen beitragen.

Das heißt nicht, dass technische Abhilfemaßnahmen schlecht oder nicht hilfreich sind. Oft handelt es sich um Sofortlösungen, die erforderlich sind, um den erwarteten Betrieb wiederherzustellen, oder um 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 Systemerkenntnisse = echte Resilienz

Wenn ein Vorfall ähnliche Auswirkungen hat wie ein vorheriger, 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 durch diesen Vorfall gewonnen haben, die uns helfen, auf diesen Vorfall besser zu reagieren.

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

• So greifen wir auf die verfügbaren Systemdaten zu, überwachen sie und geben Warnmeldungen dazu aus
• Wie wir diese Daten entschlüsseln und wie wir wissen, was sie anzeigen
• Wie wir wissen, welche Leute wir zusammenrufen müssen, um uns bei dem zu helfen, was wir sehen
• 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
• Indem wir Einblicke in diese (und andere) Aspekte der Leistungserbringung gewinnen, entdecken wir die Quellen der Widerstandsfähigkeit im System.

Unsere Systeme und Mitarbeiter entwickeln sich ständig weiter und verändern sich. Die Erkenntnisse, die wir aus jedem Vorfall gewinnen, ermöglichen es uns, unsere Systeme und einander besser zu verstehen. Wenn wir Lernen als unsere Reaktion auf Probleme priorisieren, konzentrieren wir uns darauf, das zu verstehen, was wir vorher oder während des Vorfalls nicht wussten, anstatt sofort nach Lösungen zu suchen. Aus unserer neuen, fundierteren Perspektive können wir dann feststellen, ob Maßnahmen erforderlich sind, und von den am nächsten am Problem Beteiligten Lösungsansätze einholen.

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