Dies ist der zweite Teil einer Geschichte über Fehler in fragilen Systemen, über Entscheidungen und deren Auswirkungen. Aber auch eine Geschichte über Teamwork in einer Lernkultur.
Noch immer starrte der Techniker auf den Bildschirm.
Der Eingabeprompt blinkte vor sich hin als wäre nichts passiert, und der Techniker hätte sich nur zu gerne dieser Illusion hingegeben. Doch der Techniker wusste es besser.
Nur einen kurzen Moment hatte es gedauert, bis ihm bewusst geworden war, dass er Mist gebaut hatte. Nur ein kurzer Moment, bis ihm bewusst geworden war, dass er den Befehl auf dem falschen System ausgeführt hatte. Er hatte in bester Absicht gehandelt und ärgerte sich sehr über seinen Fehler.
Für einen Moment lähmten ihn der Schock und der Ärger über sich selbst, aber dann setzte das Verantwortungsbewusstsein ein. Er kannte die Geschichten von Mitarbeitern, die in einer solchen Situation versucht hätten, alles unter den Teppich zu kehren, aber so einer wollte er nicht sein. Er wusste, dass er die Ereignisse am besten kannte, die zu dieser verhängnisvollen Situation geführt hatten. Sein Wissen und sein Mitwirken würden gebraucht werden, wenn man eine Situation wie diese in Zukunft vermeiden wollte. Statt über Flucht nachzudenken oder was ihm seitens seines Teams blühen konnte, dachte er also über die nächsten Schritte nach. Dabei wurde ihm schnell klar, dass er das Pferd allein nicht geschaukelt bekommen würde. Er verstand eine Menge von seinem Job, aber die einzig vernünftige Entscheidung war es, nach Hilfe zu fragen – und so tat er genau das.
„Oh shit“, war die erste Reaktion als der Techniker, im Slack-Channel seines Teams erzählte, was ihm passiert war. Ein Anderer sendete ein geschockt wirkendes Emoticon.
Die erste Reaktion war spontan und man konnte sie den Kollegen nicht verdenken. Später würder man den Techniker in allen Publikationen zu dem Thema als Teammitglied #1 bezeichnen und auch jetzt verzichteten sie darauf auf ihm rum zu hacken. Stattdessen gingen die Kollegen schnell in den Problemlösungsmodus über. Ihnen war klar, dass ihr Teamkollege sich selbst wahrscheinlich am meisten über seinen Fehler ärgerte und es ihm im Augenblick nicht besonders gut gehen durfte. Also versicherten sie ihm, dass sie die Situation schon schaukeln würden, und überlegten dann gemeinsam, welche Möglichkeiten ihnen jetzt zur Verfügung standen.
Der allgemeine Tenor war: „Backups – genau für solche Fälle haben wir Backups.“
Relativ schnell war dem Team klar, dass die Frage nicht war, ob sie Daten verlieren würden sondern eher wie viel. Die gute Nachricht war: sie hatten tatsächlich Backups. Leider musste das Team an diesem Tag auf die harte Tour lernen, dass Backups allein nicht reichen, wenn man nicht auch hin und wieder testet, ob sich Backups im Fall der Fälle auch wieder herstellen lassen. Die Backups waren seit längerem kaputt und keinem war es aufgefallen. Ein frustrierender Tiefschlag für das ganze Team, aber natürlich war aufgeben keine Option und zudem stellte sich ohnehin die Frage, ob man den Datenverlust geringer halten könnte als es mit den kaputten Backups möglich gewesen wäre.
Schließlich griffen sie auf eine Datensicherung zurück, die gar nicht für solche Situationen gedacht war.
Die Datensicherung war zuvor im Rahmen anderer Arbeiten routinemäßig erzeugt worden und diente Testzwecken. Diese Sicherung war nicht ideal, weil sie nicht identisch zu den Produktivdaten war, sondern zur Vermeidung von ungewollten Seiteneffekten bei den Tests geringfügigen Modifikationen unterzogen wurde. Das Team musste folglich tief in die Trickkiste greifen, konnte aber nach fast 24 Stunden einen Erfolg vermelden:
Der Dienst konnte wiederhergestellt und der Verlust an Daten vergleichsweise gering gehalten werden.
Wie ging es weiter?
In vielen Unternehmen wäre die Geschichte an dieser Stelle vielleicht mehr oder weniger zuende erzählt.
In einem Bericht an den jeweiligen Vorgesetzten und in der späteren Pressemitteilung hätte gestanden, dass das Problem auf menschliches Versagen zurückzuführen sei und vielleicht hätte der Vorfall auch personelle Konsequenzen nach sich gezogen. Das war das Problem mit der durchaus gängigen Unternehmenskultur: wenn ein Schuldiger gefunden und gehängt wurde, war das oftmals schon genug. Der Techniker kannte ein paar Leute, die wegen so etwas ihren Job verloren hatten, aber wirklich etwas verändert hatte sich dadurch nicht.
Doch er und das Unternehmen, für das er arbeitete, tickten da etwas anders.
Statt das „Teammitglied #1“ zu kündigen wurde ein umfangreicher Bericht über den zeitlichen Ablauf, die Ereignisse und Probleme verfasst. Der Techniker und die anderen beteiligten Personen schrieben akribisch auf, was sie wann getan, welche Annahmen sie getroffen und welche Beobachtungen sie gemacht hatten – mit schonungsloser Ehrlichkeit und später für für jedermann öffentlich einsehbar. Auch führten sie eine sogenannte Root Cause Analysis durch und entdeckten so ein paar viel tieferliegende Probleme als es sonst möglich gewesen wäre. Letztlich fanden sie eine Reihe von Maßnahmen, die sie pro-aktiv ergreifen konnten, um solche Probleme in der Zukunft zu verhindern oder zumindest unwahrscheinlicher zu machen.
Manche Leser werden es an dieser Stelle wohl schon vermuten: Meine fiktive Geschichte ist lose an realen Gegebenheiten angelehnt. Ein ähnlicher Vorfall ereignete sich nämlich Anfang letzten Jahres bei Gitlab Inc. und wurde dort von Anfang mit maximaler Transparenz behandelt:
Sicherlich war der Datenverlust nichts, was das Unternehmen auf die leichte Schulter nahm und vermutlich wird es auch Nutzer gegeben haben, die deswegen zur Konkurrenz gegangen sind. Doch sicherlich wird der Umgang mit dem Vorfall und dem betroffenen Mitarbeiter sich auch positiv auf die öffentliche Wahrnehmung und ganz sicher auch auf das Produkt ausgewirkt haben.
Mich hat es auf jeden Fall beeindruckt.
Und was geschah mit dem Techniker?
Der Techniker beteiligte sich aktiv an diesem Prozess und arbeitet auch nach dem Vorfall noch für das Unternehmen.
Kurze Zeit vorher war er für eine Beförderung vorgeschlagen worden und das Unternehmen sah keinen Grund daran etwas zu ändern. Letztlich fanden sie wohl, dass er ein wertvoller Mitarbeiter sei und ein einzelner Fehler daran auch nichts änderte. Leider nicht unbedingt die Art des Hinter-den-Mitarbeiter-Stehens, die für unsere Geschäftswelt üblich ist, aber wahrscheinlich auch aus geschäftlicher Sicht eine kluge Entscheidung. Denn machen wir uns nichts vor: viele Fehler in Unternehmen sind nicht allein auf ein einzelnes menschliches Versagen zurückzuführen, sondern letztlich nur das Ergebnis vieler kleiner, für sich nicht schwerwiegend erscheinender und in Summe halt doch gravierender Probleme zurückzuführen.
Im oben genannten Fall wurde beispielsweise ein Dokumentationsproblem festgestellt und dass eines der beteiligten Tools leider ein wenig an hilfreichen Meldungen vermissen ließ.
Wer würde schon annehmen, dass sowas den Unterschied machen könnte, wenn man unter Druck (weil gewissermaßen Operation am offenen Herzen) an etwas arbeitet? Im Nachhinein mit entsprechender Analyse fällt das leicht – im Vorfeld eher nicht. Gut also, wenn so ein Vorfall wenigstens Verbesserungen an diesen Werkzeugen mit sich bringt. Wenn Übermüdung die Ursache gewesen wäre, fiele es wohl leicht, den Zusammenhang herzustellen – aber ob es soweit überhaupt kommt, wenn man sich nicht eingehender mit den Ursachen auseinander setzt, bleibt fraglich. In der IT ist es jedenfalls nach wie vor eine recht geläufige Praktik, dass Wartungsarbeiten an „business-kritischen“ Systemen gerne außerhalb der regulären Arbeitszeiten und zu späten Uhrzeiten stattfinden.
Eine Lernkultur etablieren ist gar nicht so einfach.
Der „Post Mortem“-Bericht, wie er von Gitlab verfasst wurde, kann helfen systemische Probleme zu erkennen, aber das funktioniert nur, wenn im Unternehmen Zusammenarbeit und Wissen teilen großgeschrieben wird.
Eine Lernkultur aufzubauen ist aber gar nicht so einfach, denn natürlich sind wir in einer Welt begrenzter Ressourcen bemüht, unsere Ressourcen sparsam zu verwenden. Wenn wir beispielsweise erleben, dass mit dem Finger auf jemanden gezeigt oder sich lustig gemacht wird, sobald man ein Fehler entdeckt oder auf ein Problem aufmerksam gemacht wird, dann werden die Menschen im Unternehmen wohl früher oder später erkannte Probleme lieber für sich behalten. Dass auf diese Weise Fehler vermieden werden, kann man aber getrost vergessen. Auch ist das Finger Pointing nur die offensichtlichste der kontraproduktiven Verhaltensweisen.
Die Frage ist letztlich: Kommt man im Unternehmen eher mit kooperativem oder mit einzelgängerischen Verhalten weiter? Und welche der beiden Seiten möchte man fördern?
Was ist denn eigentlich ein Post Mortem?