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.

Es gibt ein altes Sprichwort, das besagt, dass das beste Werkzeug für die Arbeit dasjenige ist, das man hat. Ebenso ist die beste Vorfallanalyse für Ihr Unternehmen diejenige, die die Leute tatsächlich durchführen. Es gibt keine Universallösung. Natürlich wäre es toll, wenn wir zwei Wochen damit verbringen könnten, jeden Vorfall zu untersuchen, aber das ist wahrscheinlich nicht realistisch.

Jeder Vorfall ist einzigartig. Auch wenn ein Vorfall ähnlich oder wie die Wiederholung eines früheren Problems erscheint, ist er verschiedenen Personen zu unterschiedlichen Zeiten passiert. Es gibt fast immer etwas Neues zu lernen. Die Zeit, Aufmerksamkeit und Mühe, die Sie in die Analyse eines Vorfalls investieren, sollten auf seinem Potenzial basieren, Erkenntnisse über die Praktiken, Systeme, Geschichte oder Fachkompetenz Ihres Unternehmens zu liefern. Wir wollen und müssen nicht für jeden Vorfall das gleiche Maß an Analyse durchführen.

Daher ist es sinnvoll, die Fähigkeiten zu entwickeln, um zu erkennen, welche Vorfälle ein größeres Potenzial haben, wertvolle Erkenntnisse zu liefern, und bei welchen es sich möglicherweise nicht lohnt, so viel Zeit darauf zu verwenden. Aus denjenigen, die eine tiefere Analyse wert sind, möchten wir so viel wie möglich herausholen und die Zeit, Aufmerksamkeit und Mühe investieren, die wir zuvor erwähnt haben, damit unsere Organisation so viel wie möglich daraus lernen kann. Aber wie entwickeln wir diese Fähigkeiten zum Erkennen von Erkenntnissen?

Es waren mehrere (>2) Teams beteiligt

Die Koordination zwischen Teams kann die Bearbeitung von Vorfällen erschweren, wenn Teams, die noch nie zusammengearbeitet haben, dies unter Stress, Unsicherheit und Zeitdruck tun müssen. Die Schwierigkeiten können noch verstärkt werden, wenn den Helfern ein gemeinsames Verständnis für eine effektive Zusammenarbeit fehlt. Dies kann bedeuten, dass man sich nicht sicher ist, wer was über die verschiedenen Teile des Problems weiß, wer Zugriff auf die benötigten Informationen hat (oder nicht hat) und sogar bei einfachen Dingen wie der Frage, wie man alle zusammenbringt, um gemeinsam an dem Problem zu arbeiten (z. B. indem man sich in verschiedenen Slack-Arbeitsbereichen oder bei separaten Zoom-Anrufen befindet). Die Bearbeitungsschwierigkeiten nehmen oft zu, wenn die Anzahl der beteiligten Teams, Personen und Software zunimmt.

Die Untersuchung solcher Vorfälle kann dabei helfen, herauszufinden, wo im Unternehmen Quellen mit tiefgreifender Expertise vorhanden sind – etwas, das möglicherweise nicht durch Organigramme oder Teamzusammensetzungen abgebildet wird. Ein Fokus auf die Koordination zwischen Teams ist eine lohnende Investition, da Nachforschungen haben ergeben dass implizites Organisationswissen für eine reibungslose Reaktion auf Vorfälle von entscheidender Bedeutung ist.

Ein neuer Dienst oder eine Interaktion zwischen Diensten war erforderlich.

Unvorhergesehene Interaktionen zwischen Softwarekomponenten können Verwirrung stiften, wenn nicht das passiert, was der Benutzer erwartet. Mit anderen Worten: Die internen mentalen Modelle des Systems unterscheiden sich von dem, was es tatsächlich ist. In diesen Fällen sind die mentalen Modelle unvollständig oder fehlerhaft – ein sehr häufiges Merkmal bei der Arbeit mit komplexen und sich verändernden Systemen.

Die Untersuchung derartiger Vorfälle kann allen Beteiligten (den Helfern selbst, den Lesern der Vorfallberichte oder den Teilnehmern an Obduktionen) dabei helfen, ihre eigenen, ähnlichen mentalen Modelle zu aktualisieren oder Erkenntnisse auszutauschen, die für andere hilfreich sein könnten.

Es ging um den Gebrauch oder Missbrauch von etwas, das einfach oder uninteressant erschien

In diesem Zusammenhang können mentale Modelle aufgrund übermäßiger Vereinfachungen fehlerhaft oder mangelhaft sein. Die Verwendung von Heuristiken – oder mentalen Abkürzungen – ist selbst bei Experten üblich. Bei der Softwareentwicklung geht es häufig darum, im Laufe der Zeit durch das Sammeln von Erfahrungen mit dem System unter unterschiedlichen Betriebsbedingungen ein Verständnis dafür aufzubauen, wie das System funktioniert.

Vereinfachungen werden im Nachhinein, nach dem Vorfall, schnell als solche erkannt. Eine Untersuchung sollte dazu dienen, herauszufinden, welche Sichtweise der Antwortenden sinnvoll war. Oft werden dabei mehrere andere Personen entdeckt, die dasselbe dachten! Diese Vorfälle sind also eine Gelegenheit, zu erfahren, wann und wie Ihre Ingenieure Vereinfachungen verwenden, und das beabsichtigte und erwartete Verhalten zu besprechen, um den Wissensaustausch zu verbessern.

Das Ereignis betraf einen Anwendungsfall, an den nie gedacht wurde (Hinweis auf eine Überraschung)

Jede Software enthält ein Modell ihrer Benutzer. Dabei handelt es sich um Annahmen der Entwickler über die Fähigkeiten und Möglichkeiten der Benutzer und ihre mögliche Verwendung der Software. Gut konzipierte Software versucht, unbeabsichtigte Anwendungsfälle durch ordnungsgemäße Fehler zu berücksichtigen. Schlechtes Design führt zu Leistungseinbrüchen, wenn die Software außerhalb der vorgesehenen Betriebsbedingungen verwendet wird.

Die Untersuchung dieser Art von Vorfällen kann wichtige Erkenntnisse darüber liefern, wie Kunden die Software verwenden, wie Mitarbeiter bei der Vorfallbewältigung mit unerwarteter Verwendung umgehen und wie die Reaktion auf Vorfälle mit einem hohen Maß an Unsicherheit am besten unterstützt werden kann.

Das Ereignis wäre beinahe wirklich schlimm gewesen, ein „Beinaheunfall“

Ein „Beinahe-Vorfall“ ist ein Vorfall, der ganz anders hätte ausgehen können, wenn nicht jemand „zufällig“ ein fehlerhaftes Dashboard bemerkt hätte oder ein Techniker „zufällig“ die Protokolle angeschaut hätte. Diese scheinbar „glücklichen“ Fehlschläge geben oft wichtige Einblicke in die normale Alltagsleistung des Systems. Dies können Schlüsselpersonen sein, die unaufgefordert routinemäßig nach Problemen suchen, oder jemand, der Kundensupportgespräche mithört, um frühe Anzeichen von Problemen zu erkennen.

Die Untersuchung dieser „Beinahe“-Ereignisse kann hilfreiche Verhaltensweisen aufdecken und kodifizieren, um die Widerstandsfähigkeit zu verbessern. Solche Vorfälle werden oft in lockeren Gesprächen angesprochen – entweder weil sie Angst auslösen („das hätte so schlimm ausgehen können!“) oder weil sie Neugier wecken („ich frage mich, warum es nicht schlimmer gekommen ist?“).

Es sieht aus wie ein „Wiederholungsvorfall“

Niemand möchte zweimal den gleichen Vorfall haben – er kann Ingenieure demoralisieren, Manager frustrieren, Kunden verärgern oder die Aufmerksamkeit der Aufsichtsbehörden auf sich ziehen.

Eine eingehendere Untersuchung scheinbar wiederholter Vorfälle kann hilfreich sein, um subtile, aber nicht unerhebliche Unterschiede aufzudecken, die die Bewältigung des Vorfalls für die Einsatzkräfte besonders schwierig machten. Oder sie kann dabei helfen zu verstehen, welche Arten von organisatorischem Druck (wie überlastete Teams) und Einschränkungen (wie Einschränkungen im Code) die Anwendung einer früheren Korrekturmaßnahme verhindert haben.

Beispiele hierfür, die wir in der gesamten Branche sehen, sind häufig „Zertifikatsablauf“ oder „Konfigurationsänderungen“. Beispiele wie diese können häufig auf ein tieferes systemisches Problem hinweisen, das dazu führt, dass diese Fehler wahrscheinlich häufig auftreten.

Es gibt viele Diskussionen über den Vorfall in Slack-Kanälen oder im Büro

Anhaltendes Interesse oder Aufmerksamkeit für einen Vorfall kann auf Neugier, Überraschung oder Unbehagen in Bezug auf einen Aspekt des Ereignisses hinweisen. Die technischen Details können für andere technische Arbeiten interessant oder wichtig sein. Es könnte sich um ein seit langem latentes Problem handeln, das weiterhin Störungen verursacht und aufgrund organisatorischer Faktoren wie Silobildung, Verweigerung der Zusammenarbeit, überlasteten Teams oder unterschiedlichen Meinungen über die Priorität der zur Lösung des Problems erforderlichen Arbeiten nicht behandelt wird.

Die Untersuchung solcher Vorfälle kann für das Entwicklungsteam eine hervorragende Möglichkeit zur beruflichen Weiterentwicklung darstellen, um sein Verständnis für unterschiedliche Arten von Software zu vertiefen oder eine Chance zur Wiederherstellung oder Entwicklung funktionsübergreifender Beziehungen zu bieten.

Es kam zu Verwirrung während oder rund um die Veranstaltung

Ein gewisses Maß an Verwirrung darüber, was während eines Ereignisses passiert, ist bei komplexen Systemausfällen normal. Längere Phasen der Ungewissheit oder Schwierigkeiten bei der Bildung von Hypothesen über die Ursache von Problemen oder mögliche Maßnahmen zur Beschaffung weiterer Informationen können ein Zeichen für Wissensdefizite sein. Wenn jedoch eine Wissenslücke als Ursache eines Vorfalls identifiziert wird, bleiben wichtige Details zu Onboarding und Schulung, Übergaben, Codeüberprüfungen, fortlaufender Wissensaktualisierung und -weitergabe unberücksichtigt.

Wir untersuchen solche Vorfälle besonders gerne, um Mikro-Lernmöglichkeiten3 zu bieten, bei denen die Teilnehmer ihr Fachwissen teilen und klärende Fragen stellen, um das Verständnis zu verbessern.

Der Vorfall ereignete sich während einer wichtigen Veranstaltung (z. B. einer Telefonkonferenz zu den Quartalsergebnissen).

Vorfälle, die trotz Tests und proaktiver Schadensbegrenzung während Ereignissen mit hoher Sichtbarkeit auftreten, können aufgrund ihrer größeren Auswirkungen auf das Geschäft äußerst schmerzhaft sein.

Die Untersuchung dieser Vorfälle kann dazu beitragen, das Vertrauen der Kunden oder der Unternehmensleitung wiederherzustellen und Entwicklungsteams durch transparente und sorgfältige Betrachtung der beitragenden Faktoren bei der Bewältigung potenziell traumatischer Vorfälle zu unterstützen.

Es besteht Interesse an einer weiteren Untersuchung (z. B. Großkunde, Führungsanliegen usw.)

Auch Personen außerhalb der Technik (Kundensupport, Marketing oder leitende Angestellte) können Interesse daran haben, mehr über ein Ereignis zu erfahren. Die Einbindung der Organisation in die Praxis der Vorfallanalyse ist eine hervorragende Möglichkeit, Unterstützung für Lernaktivitäten nach einem Vorfall zu generieren und verschiedene Teile der Organisation zu ermutigen, ihre Perspektiven einzubringen – was die Wirkung der für die Untersuchung aufgewendeten Zeit und Mühe noch weiter steigert.

Lernen ist das Ziel

Während die oben genannten Punkte einige vielversprechende Richtungen für die zu untersuchenden Dinge darstellen, haben viele Unternehmen ihre eigenen internen Kriterien und wir sehen im Laufe der Zeit, dass Ingenieure ein feines Gespür dafür entwickeln, was für ihr Team oder Unternehmen von Wert ist. Mit der Zeit wird es einfacher und effizienter, zu bestimmen, was untersucht werden soll. Dasselbe gilt für die Softwareentwicklung: Ein erfahrenerer Ingenieur kann in kürzerer Zeit wertvolleren Code schreiben als ein Ingenieur, der das System gerade erst lernt. Während Sie Ihre Vorfälle und Beinaheunfälle weiter untersuchen, wird Ihr Unternehmen lernen, die Arten von Vorfällen, die untersucht werden, weiter zu verfeinern und zu einer proaktiveren und widerstandsfähigeren Entwicklungskultur beizutragen.

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