Player Unknown’s Bug: Kann man wachsen, wenn man Probleme unbekannter Ursache dokumentiert?
(engineering.ab180.co)Ich möchte die Geschichte teilen, wie wir über eine zufällig entstandene Issue-Seite die psychologische Sicherheit im Team erhöht, den Informationsaustausch verbessert und so eine robustere Organisation und bessere Services aufgebaut haben.
Bei der Entwicklung stößt man immer wieder auf Probleme mit unbekannter Ursache.
Besonders im Web-Frontend wird man neben dem Zustand des Servers und Ähnlichem auch von zahlreichen externen Faktoren beeinflusst, etwa vom Browsertyp oder der Browserversion, von Chrome-Erweiterungen und mehr.
Wenn wir die Ursache eines Problems nicht kennen oder die Ursache gar nicht bei uns liegt, fragte ich mich plötzlich, ob sich allein mit einem Postmortem wirklich eine belastbare Struktur schaffen lässt (ob das nicht zu wenig ist?).
Auslöser
Einmal hat es 9 Stunden gedauert, vom Eingang eines Reports über ein Problem unbekannter Ursache bis zu dessen Abschluss.
Erst nachdem ich 4 Stunden in das Debugging des Issues investiert hatte, wurde klar, dass die Ursache nicht im internen Code oder in der Infrastruktur lag, sondern durch einen Bug in der Chrome-Erweiterung des Nutzers entstand.
Es war schon schwer genug, überhaupt zu verstehen, wo die Ursache des Problems lag, aber dass es ganze 4 bis 5 Stunden dauerte, bis klar war, dass die Ursache extern war, machte mich wütend auf mich selbst.
Ich erstellte in Notion eine Seite namens „Player Unknown’s Bug (PUB)“ und hielt dort zusammen mit meinem Frust fest, wie ich auf das Issue reagiert hatte, was ich ausprobiert hatte, was unbefriedigend war und was man verbessern könnte.
Etablierung als Kultur und Weiterentwicklung
In der Rückschau sprachen wir über die Ursache des Issues, über Dinge, die wir bei der Recherche zusätzlich gelernt hatten, und über Stellen, an denen wir falsche Einschätzungen getroffen hatten. Teammitglieder wiesen auf offene Fragen und mögliche Verbesserungen hin, und aus diesen Punkten entwickelten wir einen Prozess für den Incident-Response-Fall.
Das Gute an diesem Prozess war, dass die Teammitglieder die Schwierigkeiten nachvollziehen konnten, die ich während der Bearbeitung des Issues empfunden hatte, und dass es Spaß machte, neu Gelerntes zu teilen. Außerdem erstellten wir eine Checkliste, sodass wir in ähnlichen Situationen künftig schneller Probleme identifizieren können. Nach einem Gespräch im Team wurde dies als offizielle Kultur übernommen.
Die Entwicklungsorganisation von AB180 führt grundsätzlich Postmortems durch. Während interne Postmortems vor allem auf Resolution und Action Items fokussiert sind, verfolgt PUB das Ziel, Lessons Learned festzuhalten, psychologische Sicherheit im Umgang mit Issues zu schaffen und Faktoren zu ordnen, die man bei unbekannten Problemen zuerst prüfen sollte.
Eine Kultur des freiwilligen Informationsaustauschs
Mit der Verankerung im Team sammelten sich nach und nach auch Issues an, die von anderen Teammitgliedern bearbeitet worden waren.
Die Rückschauen, in denen wir über unbekannte Aspekte sprachen und tiefer nachbohrten, begannen wie kleine, aber freiwillige „Knowledge-Sharing-Sessions“ zu funktionieren.
Um diese Kultur noch etwas weiter auszubauen, betreiben wir einen Slack-Kanal, in dem wir fortlaufend teilen, was wir gelernt oder erkannt haben. Bis jetzt funktioniert das gut.
Lessons Learned
- Man muss die psychologische Sicherheit des gesamten Teams erhöhen, das auf Störungen reagiert, und dafür müssen wir mehr miteinander sprechen.
- Wenn das nicht geschieht, wiederholen sich Probleme, und in der Organisation setzt sich der Gedanke fest: „Probleme = Dinge, über die man nicht sprechen sollte“.
- Durch das Teilen von Informationen kann man psychologische Sicherheit in einer Organisation schaffen und sogar erhöhen.
- Und eine solche Kultur des Informationsaustauschs beginnt vielleicht mit etwas, das viel unscheinbarer ist, als man denkt.
5 Kommentare
Bei mir war es heute genau umgekehrt: Ich bin den ganzen Tag mit einem Ausfall beschäftigt gewesen, bei dem die Ursache zwar ganz eindeutig ein bestimmter externer Faktor zu sein schien, wir aber wegen interner Umstände dachten, dass sich nicht so leicht etwas dagegen unternehmen lässt und nur hilflos zusehen konnten. Am Ende stellte sich heraus, dass das Problem tatsächlich durch die Änderung nur einer einzigen Zeile in der Konfigurationsdatei zu beheben gewesen wäre. Wenn ich diesen Beitrag lese, hilft mir das wirklich sehr.
Sie haben heute wirklich gute Arbeit geleistet. Zum Glück konnten Sie das Problem trotzdem lösen. An die Probleme, die ich im obigen Beitrag erwähnt habe, denke ich auch manchmal noch. Damals war es schwer, aber heute kann ich sie, glaube ich, mit Freude annehmen.
Könnte es nicht sein, dass auch das, was für Sie heute so schwer war, mit der Zeit zu einer angenehmen Erinnerung wird? Haha.
Vielen Dank, dass Sie meinen bescheidenen Text gelesen haben.
Ehrlich gesagt habe ich weder früher noch heute je gedacht, dass es Spaß macht, sich mit Störungen herumzuschlagen.
Zum Beispiel trat die Störung, die ich heute bearbeitet habe, ausgerechnet bei einem Produkt auf, bei dem unserem Team der direkte Zugriff auf den Produktionsserver verwehrt war. Daher konnten wir, abgesehen von der Anfangsphase nach dem Entdecken der Störung und beim Erfassen des Problems sowie der späteren Phase, nachdem wir uns mühsam Zugriffsrechte auf den Server verschafft hatten, kaum etwas anderes tun, als uns relativ machtlos zu fühlen. Wenn unser Team darum bat, dass diese oder jene Maßnahmen ergriffen werden, lehnte das Server-Betriebsteam dies aus seinen eigenen Gründen ab. So ein Gefühl der Ohnmacht kann man unmöglich mit Freude annehmen.
Deshalb hatte ich beim Schreiben des Postmortem-Dokuments vor Feierabend eher das Gefühl: „Dann eben aus Trotz – so einen Fehler mache ich beim nächsten Mal nicht noch einmal!“
Wenn ich höre, was Sie erzählt haben, denke ich, dass es für Sie sehr belastend gewesen sein muss. Wie Sie gesagt haben, wird man wohl nur Schritt für Schritt besser, indem man dieselben Fehler nicht noch einmal macht... schluchz
Eigentlich ist dieses Produkt ein ziemlich altes Legacy-Produkt, ich habe die Verantwortung dafür erst vor nicht allzu langer Zeit übernommen, und direkt danach kam bereits ein Änderungsaufwand für eine Funktion herein. Deshalb habe ich zwar in letzter Zeit Code angepasst, aber das betraf einen Bereich, der mit dem heutigen Ausfall überhaupt nichts zu tun hatte. Der tatsächlich problematische Teil war also nicht etwas, das ich selbst geschrieben hatte. Hätte ich das Produkt jedoch noch genauer in- und auswendig gekannt, hätte ich das Problem wohl schneller lösen können. Das ist wirklich bedauerlich.
Und dann war meine Vermutung über die Ursache, von der ich nach der Feststellung des vollständigen Ausfalls anfangs überzeugt war, in Wahrheit auch nur zur Hälfte richtig. Ich denke, genau diese Gewissheit in Bezug auf die Vermutung war heute mein eigentlicher Fehler.