Um 2:10 Uhr wird eine Warnmeldung ausgelöst. Ein Entwickler spielt eine Konfigurationsänderung ein, der Checkout-Service meldet Fehler, und der diensthabende Teamleiter macht die Änderung 40 Minuten später rückgängig. In der Besprechung lautet die erste Frage: „Wer hat die Änderung eingeleitet?“ Innerhalb weniger Minuten dreht sich die Diskussion nur noch um die Fehlentscheidung einer einzelnen Person um 02 Uhr nachts, und niemand fragt, warum die Änderung ohne Canary-Test in die Produktion gelangen konnte, warum die Warnmeldung so lange auf sich warten ließ oder warum das Runbook veraltet war.
Dies ist ein beispielhaftes Szenario, kein realer Kundenfall. Es ist wiedererkennbar, weil es vorkommt: Eine Vorfallanalyse, die sich auf die zuletzt handelnde Person konzentriert, liefert zwar eine saubere Darstellung, aber kaum neue Erkenntnisse.
Dieser Leitfaden richtet sich an Führungskräfte im Engineering und an Verantwortliche für die Mitarbeiterentwicklung, die ihre Kompetenzen in der Analyse von Vorfallsinformationen und der Vereinbarung testbarer Verbesserungen verbessern möchten. Er behandelt die Unterscheidung von Kompetenzlücken und den zugrunde liegenden Bedingungen, die Gestaltung von Schulungsmethoden, die Durchführung von Nachbesprechungen und die Messung des Erfolgs der Analysen.
Was „unschuldig“ bedeutet und was nicht
Googles Buch „Site Reliability Engineering“ bringt es auf den Punkt: Damit eine Fehleranalyse wirklich unvoreingenommen ist, muss sie sich darauf konzentrieren, die beitragenden Ursachen des Vorfalls zu identifizieren, ohne Einzelpersonen oder Teams für schlechtes oder unangemessenes Verhalten zu beschuldigen. Es beschreibt auch die zugrunde liegende Annahme: Alle Beteiligten handelten in guter Absicht und taten mit den ihnen zur Verfügung stehenden Informationen das Richtige.Google SRE-Buch „Postmortem Culture: Learning from Failure“.)
Schuldfrei bedeutet nicht folgenlos. Dasselbe Kapitel erwartet, dass Nachbesprechungen mit priorisierten Maßnahmen und einem Verantwortlichen enden. Auch eine schuldfreie Untersuchung erfordert Verantwortlichkeit, diese verlagert sich jedoch von der Frage „Wer hat das verursacht?“ hin zu „Wer wird das System sicherer machen und bis wann?“. Wenn Ihre Überprüfungen den zweiten Teil auslassen, führen Sie ein angenehmes Gespräch, aber keinen Lernprozess.
1. Identifizieren Sie das Verhalten und seinen Kontext.
Beginnen Sie mit dem konkreten Verhalten, das Sie ändern möchten. „Unsere Vorfallsanalysen konzentrieren sich auf die letzte Person, die gehandelt hat“ ist beobachtbar. „Unsere Kultur ist stark auf Schuldzuweisungen ausgerichtet“ ist es nicht.
Fragen Sie sich dann, ob es sich überhaupt um ein Kompetenzproblem handelt. Schulungen können nur einige Ursachen für schlechte Leistungen beheben. Bevor Sie etwas bauen, unterscheiden Sie drei Möglichkeiten:
- Eine fehlende Fähigkeit. Die Gutachter wissen nicht, wie man eine Zeitleiste erstellt, einen Auslöser von einem mitwirkenden Faktor unterscheidet oder fragt: „Warum erschien diese Handlung zum damaligen Zeitpunkt angemessen?“
- Anreize. Bewertungen fließen in Leistungsgespräche ein, daher gestalten die Leute ihre Accounts so, dass sie sich selbst schützen.
- Autoritätsgradienten und vergangene Reaktionen. Ein junger Ingenieur, der im letzten Quartal Bedenken geäußert hat und dem gesagt wurde, er solle aufhören, negativ zu sein, wird in diesem Meeting keine Bedenken äußern, egal wie gut er ausgebildet ist.
Nur das erste Problem ist ein Schulungsproblem. Die anderen beiden sind Rahmenbedingungen. Wenn man die Fertigkeit trainiert, die Rahmenbedingungen aber außer Acht lässt, üben die Teilnehmenden etwas ein, das im Arbeitsalltag bestraft wird. Betrachten Sie Ihre aktuelle Sicht der Ursache als Hypothese und überprüfen Sie diese in Gesprächen mit Ingenieuren und anhand aktueller Prüfberichte, bevor Sie sich für ein Programm entscheiden.
2. Legen Sie die betrieblichen Bedingungen für die Praxis fest.
Üben Sie Transfers nur, wenn der Arbeitsplatz diese beantwortet. Bevor jemand probt, stimmen Sie diese mit denjenigen ab, die die Überprüfungen durchführen:
- Genehmigte Verantwortlichkeiten. Wer übernimmt die Moderation, wer erstellt den Zeitplan, wer ist für die Folgemaßnahmen verantwortlich? Die Rollen sollten klar definiert sein, damit der Moderator seine Befugnisse nicht improvisiert.
- Wie Führungskräfte Anliegen entgegennehmen. Wenn ein Entwickler sagt: „Das Bereitstellungstool hat es mir ermöglicht, die Canary-Version zu überspringen“, was unternimmt der Leiter als Nächstes? Legen Sie die Antwort im Voraus fest, zum Beispiel: Bedanken Sie sich, protokollieren Sie es als mitwirkenden Faktor und weisen Sie eine Maßnahme zu.
- Die Antwort des Vorgesetzten. Eine Mitarbeiterschulung erfordert eine entsprechende Reaktion der Vorgesetzten. Wenn man Ingenieure darin schult, sich in Mitarbeitergesprächen zu Wort zu melden, ihre Vorgesetzten aber trotzdem fragen: „Wessen Fehler war es?“, dann ist die Schulung wirkungslos.
Eine kurze Einweisung der Führungskräfte in den Beurteilungsprozess ist genauso wichtig wie die Schulung der Teilnehmenden. Fügen Sie eine klare und verständliche Erklärung hinzu, wie Beurteilungsdokumente im Leistungsmanagement verwendet werden und wie nicht.
3. Einen verhaltensbasierten Lernprozess entwerfen
Die Leitlinien des Carnegie Mellon Eberly Center zu Lernzielen betonen den wichtigen Punkt, dass Ziele, Beurteilungen und Unterrichtsstrategien aufeinander abgestimmt sein sollten.Eberly Center, LernzieleDas sind Gestaltungshinweise, keine Belege für ein bestimmtes Werkzeug oder Ergebnis, aber es ist ein guter Test für dieses Programm: Wenn das Ziel darin besteht, Belege zu analysieren und überprüfbare Verbesserungen zu vereinbaren, dann können Erinnerungsfragen allein nicht die Bewertung sein.
Blooms Taxonomie kann hier hilfreich sein, um die kognitiven Anforderungen der Aufgabe zu beschreiben: Analysieren, Bewerten, Erstellen. Sie beschreibt, was die Aufgabe von einer Person verlangt. Sie erklärt jedoch nicht, warum jemand die Aufgabe erledigt oder nicht erledigt; daher sollte sie nicht zur Diagnose von Motivation herangezogen werden.
Eine praktikable Reise besteht aus drei Phasen.
| Praktikum | Lernaktivität | Lieferung |
|---|---|---|
| Vorbereitung | Lesen Sie Ihre Richtlinie zur Vorfallsanalyse und ein kurzes Glossar (Auslöser, beitragender Faktor, Abhilfemaßnahme, Aktionspunkt). Eine kurze Diagnose prüft die Voraussetzungen. | Selbstgesteuertes Lernen. Eine Wissensüberprüfung bestätigt lediglich die Voraussetzungen, nicht die Fertigkeiten. |
| Praxis | Analysieren Sie einen vorbereiteten Vorfallsfall und vereinbaren Sie überprüfbare Verbesserungen. Eine begründete Antwort ist erforderlich, keine Auswahl aus einer Multiple-Choice-Liste. | Interaktive oder moderierte Fallstudien mit Feedback zur Qualität der Einflussfaktorenanalyse und der Nachbereitung. |
| Überprüfung und Weiterleitung | Besprechen Sie eine mehrdeutige Entscheidung und bearbeiten Sie anschließend einen neuen Fall oder eine betreute Fallstudie. | Live-Coaching oder asynchrone Überprüfung. Überprüfen Sie den Transfer, nachdem die Teilnehmer Zeit hatten, die erlernten Fähigkeiten im Arbeitsalltag anzuwenden. |
Gestalten Sie den Fall realistisch und lassen Sie ihn von einem erfahrenen Ingenieur prüfen. Ein technisch fehlerhafter Fall führt dazu, dass die Prüfer dem gesamten Projekt misstrauen.
4. Das Szenario durcharbeiten und anschließend besprechen.
So könnte eine Übungssitzung mit dem Szenario 02:10 ablaufen. Das Beweismaterial enthält das Bereitstellungsprotokoll, die Alarm-Timeline, die Paging-Richtlinie, den Pull Request und das Runbook – alles fiktiv.
Aufforderung an den Teilnehmer. „Erklären Sie, warum der Ingenieur die Änderung zu diesem Zeitpunkt durchgesetzt hat. Führen Sie die von Ihnen verwendeten Belege an. Teilen Sie uns mit, welche weiteren Informationen oder Unterstützung Sie benötigen, um sich sicher zu sein.“
Eine schwache Antwort klingt etwa so: „Der Ingenieur hätte die Testumgebung überprüfen sollen.“ Sie nennt eine Person, führt aber nichts an und schlägt keine Änderung vor.
Eine aussagekräftigere Antwort könnte so lauten: „Das Deployment-Protokoll zeigt, dass die Änderung direkt veröffentlicht wurde, da der Canary-Schritt im Tool optional ist. Der Pull Request hatte einen Reviewer, der ihn nach 20 Minuten freigegeben hat. Die Seite wurde 18 Minuten nach Auftreten der Fehler geladen, da der Alarmschwellenwert auf einen Fünf-Minuten-Durchschnitt eingestellt war. Ich möchte wissen, wie viele andere Änderungen in diesem Monat den Canary-Schritt übersprungen haben und ob den Bereitschaftsingenieuren jemals mitgeteilt wurde, dass dieser Schritt übersprungen werden kann. Vorgeschlagene Maßnahmen: Den Canary-Schritt für diese Serviceebene verpflichtend machen (zuständig: Plattformteam; Überprüfung: Einen Deployment-Versuch ohne Canary-Schritt in der Staging-Umgebung durchführen und bestätigen, dass er blockiert wird); das Alarmfenster verkürzen (zuständig: Bereitschaftsdienstleitung; Überprüfung: Die Fehler der letzten Woche mit dem neuen Schwellenwert vergleichen).“
Beachten Sie, was es besser macht. Es nutzt Beweise, benennt Einschränkungen und Unsicherheiten und mündet in überprüfbare Maßnahmen.
Nun zur Nachbesprechung. Nicht nur bewerten. Fragen Sie:
- Was stützten die Beweise, und was nahmen Sie an?
- Welche Ihrer Maßnahmen hätte das Team tatsächlich die Befugnis, durchzuführen?
- Was würde es Ihnen erleichtern, dieses Verhalten in Ihrer nächsten echten Leistungsbeurteilung zu wiederholen? Was würde es Ihnen erschweren?
Die dritte Frage ist die wichtigste. Sie bringt die Bedingungen aus Abschnitt 2 ans Licht. Wenn drei Teilnehmer sagen: „Mein Vorgesetzter wird fragen, wer es getan hat“, haben Sie eine Einschränkung gefunden, die durch ein Training nicht beseitigt werden kann.
5. Verhalten und Konsequenz messen
Die zentrale Frage ist, welche Nachweise belegen, dass Lernende Vorfallsberichte analysieren und überprüfbare Verbesserungen vereinbaren können. Hier finden Sie eine erste Orientierungshilfe. Es handelt sich um einen Vorschlag zur Anpassung an einen erfahrenen Ingenieur, nicht um einen validierten Bereitschaftsstandard.
| Kriterium | Sichtbare Beweise | 0 | 1 | 2 |
|---|---|---|---|---|
| Aufgabenausführung | Analysiert die Beweise und vereinbart Verbesserungen; dokumentiert die Maßnahmen und die zugrunde liegenden Beweise. | Fehlend oder nicht unterstützt | Teilweise, mit relevanten Auslassungen | Vollständig und anhand vereinbarter Kriterien begründet |
| Argumentation | Erläutert Einschränkungen, Alternativen und Unsicherheiten; die Einflussfaktoren reichen über die letzte Aktion hinaus. | Fehlend oder nicht unterstützt | Teilweise, mit relevanten Auslassungen | Vollständig und gerechtfertigt |
| Boundaries | Wendet genehmigte Verfahren an; bittet um Hilfe, wenn Informationen oder Befugnisse fehlen. | Fehlend oder nicht unterstützt | Teilweise, mit relevanten Auslassungen | Vollständig und gerechtfertigt |
Kritische Fehler müssen separat definiert werden, beispielsweise durch die Benennung einer Person als Ursache oder den Vorschlag einer Maßnahme ohne Verantwortlichen. Eine hohe Gesamtpunktzahl darf niemals einen kritischen Fehler verschleiern.
Zur Messung selbst:
- Qualität der Einflussfaktorenanalyse. Vergleichen Sie Rezensionen, die vor dem Programm verfasst wurden, mit Rezensionen, die danach verfasst wurden. Die Bewertung erfolgte anhand derselben Kriterien durch eine Person, die nicht weiß, welche Rezensionen welche sind. Verwenden Sie sowohl fiktive als auch reale Folgefälle.
- Durchziehen. Ermitteln Sie den Anteil der Maßnahmen, die einen Verantwortlichen haben, getestet wurden und abgeschlossen sind, bezogen auf alle erstellten Maßnahmen. Geben Sie den Nenner und den Zeitraum an.
- Beobachtungen mit Prozessänderungen verknüpfen. Nehmen Sie an einer echten Besprechung teil. Überprüfen Sie anschließend, was mit den Maßnahmenpunkten geschehen ist.
Seien Sie vorsichtig mit der Anzahl der gemeldeten Vorfälle. Werden nach dem Programm mehr Bedenken und Beinaheunfälle protokolliert, kann dies bedeuten, dass sich die Sicherheit oder das Vertrauen verbessert hat oder dass ein neues Tool die Protokollierung vereinfacht hat. Ein Rückgang könnte hingegen auf weniger Probleme oder eine geringere Bereitschaft zum Sprechen hindeuten. Prüfen Sie, was sich im gleichen Zeitraum verändert hat, bevor Sie eine Veränderung dem Training zuschreiben, und vermeiden Sie es, eine Effektstärke anzugeben, die Sie nicht gemessen haben.
Die oben genannten Eberly-Richtlinien beschreiben die Ausrichtung; sie beweisen jedoch nicht, dass dieser Ansatz die Anzahl der Vorfälle reduziert. Erfassen Sie Ihre eigenen Ausgangs- und Folgedaten und behandeln Sie diese als lokale Belege.
Welche Einschränkungen könnten auch nach einer Verbesserung der Fähigkeiten bestehen bleiben?
Seien Sie gegenüber Sponsoren in diesen Punkten ehrlich:
- Prüfdokumente können weiterhin in Leistungsentscheidungen einfließen.
- Teams, die unter Lieferdruck stehen, verzichten möglicherweise auf Maßnahmen, die zwar kostspielig, aber sinnvoll sind.
- Teamübergreifende Aktionen können ins Stocken geraten, weil niemand die Spielfeldbegrenzung sicher hat.
- Die leitenden Ingenieure könnten die Diskussion weiterhin dominieren.
Eine bessere Analyse beseitigt diese Probleme nicht. Planen Sie separate Prozessänderungen dafür.
Die Umsetzung in die Praxis mit AhaSlides
AhaSlides Unterstützt adaptives und interaktives Lernen sowie den Wechsel zwischen Live- und Selbstlernphasen. Dies kann beispielsweise eine selbstgesteuerte Vorbereitungsphase, eine Live- oder moderierte Fallstudie mit offenen Fragerunden zur Analyse aller Teilnehmenden vor der Gruppendiskussion und eine Nachbereitungsaufgabe umfassen. Spezifische Funktionen zum Erstellen, Bewerten und Berichten von Fallstudien sollten anhand eines eigenen Falls demonstriert werden, bevor Sie sich darauf verlassen. KI, Simulatoren oder Integrationen mit Ihren Incident-Management-Tools sollten bis zur Demonstration als extern betrachtet werden.
Nächster Schritt: Nehmen Sie die oben genannte Rubrik und passen Sie sie gemeinsam mit einem Ihrer erfahrenen Ingenieure an, um anschließend den Anwendungsfall zu erstellen.
Sobald Sie den Fall und die Bewertungskriterien ausgearbeitet haben, erkunden Sie, wie eine Live- und selbstgesteuerte Version dieser Lernreise funktionieren könnte. AhaSlides.
