Kolumne

DevOps Stories: Ein Sündenbock hilft nicht! Blameless Post Mortems

Konstantin Diener

Agilität, Management 3.0, New Work oder DevOps – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen berichtet die Kolumne DevOps Stories. Heute belauschen wir das MusicStore-Team beim morgendlichen Stand-up.

DevOps Story: Ein Sündenbock hilft nicht! Blameless Post Mortems

  • Lukas: „Heute Nacht gab es vermehrt Alerts im Produktivsystem.“
  • Julia: „Wann hat das angefangen?“
  • Lukas: „Gestern gegen 21:00 Uhr. Zumindest sieht es im Chatverlauf danach aus.“
  • Erik: „Was war da los?“
  • Lukas: „Es gab scheinbar Probleme mit den Kreditkartenzahlungen, die …“
  • Manuela: „Das passt, ich habe hier drei Beschwerden. Die Kunden wollten ein Abo mit der Kreditkarte bezahlen, es hat aber nicht geklappt.“
  • Ruben: „Heute Nacht war Jens mit der Rufbereitschaft dran, oder?“
  • Lukas: „Ja.“
  • Christian: „Wo ist der schon wieder?“
  • Ruben: „Er hat doch gestern gesagt, dass er heute Morgen zum Zahnarzt muss.“
  • Christian: „Super Timing!“
  • Lukas: „Durch den Verlauf in unserem ChatOps-Tool können wir doch eigentlich ganz gut nachvollziehen, was da passiert ist. Gegen 21:30 Uhr wurde Jens informiert, und er hat direkt mit der Fehlersuche begonnen. Um 23:40 Uhr hat er festgestellt, dass das Problem offenbar mit seiner Änderung am Bezahlprozess zu tun hat.“
  • Christian: „Dafür hat der ernsthaft über zwei Stunden gebraucht?“
  • Lukas: „Die neue API-Version verhält sich offenbar anders als die bisherige. Als das klar war, hat er die Änderung zurückgerollt.“
  • Julia: „Es sieht hier aber danach aus, dass die Kartenzahlungen dann immer noch nicht funktionierten, oder?“
  • Lukas: „Korrekt. Durch das Zurückrollen der API-Version ist irgendwie der API Key der Testumgebung auch auf Production gelandet. Und aus gutem Grund lassen sich damit keine echten Zahlungen durchführen.“
  • Manuela: „Jetzt funktioniert‘s aber wieder, oder?“
  • Lukas: „Genau. Jens hat um 01:05 Uhr den richtigen API Key auf dem Produktivsystem gesetzt, und seitdem funktioniert es wieder.“
  • Manuela: „Alles klar, dann setzte ich jetzt gleich eine Info an unsere Kunden auf. Sie sollen es einfach nochmal versuchen. Aber jetzt ist maximale Transparenz wichtig.“
  • Christian: „Das ist doch peinlich. Die Kunden sind sauer, weil ihr Abo nicht funktioniert hat! Und du teilst ihnen jetzt mit, dass es daran lag, dass bei uns Dilettanten arbeiten, die Bugs in Produktion pushen, niemanden um Hilfe fragen und dann auch noch so dämlich sind, den falschen API Key zu verwenden? Jens bekommt das einfach nicht auf die Reihe …“
  • Ruben: „Ich finde, Jens hat sehr professionell reagiert. Und du glaubst doch wohl nicht, dass er dich um Hilfe bittet, wenn du so über ihn redest!“

In komplexen Systemen passieren Fehler …

Im MusicStore-Team ist ein Fehler passiert, der Endkunden verärgert und vermutlich auch zu Umsatzeinbußen geführt hat. Es gibt nicht wenige Menschen in der IT-Branche, die in einer solchen Situation wie Christian denken: Der Fehler hätte vermieden werden können. Wenn wir uns nur ausreichend anstrengen, passieren keinerlei Fehler.

Nach Meinung von Werner Vogels, CTO bei Amazon, ist diese Ansicht nicht ganz richtig. Von ihm stammt das Zitat „Everything fails all the time“. Dahinter steckt die Überzeugung, dass IT-Systeme heute so komplex sind, dass sich Fehler nicht per se vermeiden lassen. Entscheidend ist der professionelle Umgang mit diesen Fehlern.

Einen Beweis für diese Ansicht liefert ein Fehler, der im Oktober 2018 bei GitHub aufgetreten ist. Durch den Austausch von Netzwerkhardware entstand zwischen verschiedenen Standorten ein Verbindungsausfall von 43 Sekunden, der in letzter Konsequenz zu über 24 Stunden mit (Teil-)Ausfällen der GitHub-Produkte führte. GitHub ist mit Sicherheit kein kleines Unternehmen, beschäftigt einige der besten Softwareingenieure der Welt und ist in der Entwicklung und im Betrieb großer Softwarelösungen definitiv kein Anfänger.

Den „Schuldigen“ zu bestrafen, erhöht nicht die Sicherheit, sondern verringert sie

Der Bericht über den Ausfall ist gut geschrieben. Neben einigen anderen Aspekten fällt einer besonders auf: An keiner Stelle steht „Es war die Schuld der Netzwerkingenieure (o. a.) und wir haben sie entlassen“.

Auch dieser Teil von Christians Reaktion auf die nächtlichen Probleme ist in vielen Organisationen immer noch weit verbreitet: Wir suchen den Schuldigen und bestrafen ihn. Seiner Meinung nach hätten andere Kollegen es gar nicht zu diesem Fehler kommen lassen. Dass es ein Problem gab, lag einzig und allein an Jens‘ Inkompetenz. Dabei ist es nicht unwahrscheinlich, dass ein ähnlicher Fehler auch anderen im Team hätte passieren können. Wir Menschen lassen uns in solchen Situationen allzu oft vom fundamentalen Attributionsfehler („Meine Fehler entstehen durch den Kontext, die der anderen durch Inkompetenz oder schlechte Absichten“) oder vom Rückschaufehler („Rückblickend war dieses Ereignis vorhersehbar“) leiten.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Aus der Überzeugung, dass die Ursache für den Fehler in einer bestimmten Person liegt, wird in der Regel die Schlussfolgerung gezogen, dass man diese Person nur feuern oder von kritischen Systemen fernhalten muss, um Fehler in Zukunft zu vermeiden. Damit geht auch die Überzeugung einher, dass Sicherheit sich durch Abschreckung steigern lässt. Wenn man den Verursacher schon nicht entlässt oder abschottet, muss man ihn auf jeden Fall gut sichtbar bestrafen, damit er und andere sich nicht noch einmal eine solche Dummheit erlauben.

Dieser komplette Denkansatz geht davon aus, dass der Verursacher vorsätzlich oder grob fahrlässig einen Fehler begangen hat. Tatsächlich ist es aber oft so, dass derjenige der Meinung war, dass …

  • … das, was als Folge seiner Handlung eingetreten ist, nicht möglich sei.
  • … das, was passiert ist, nichts mit seinen Aktionen zu tun hat.
  • … die Erreichung des gemeinsamen Ziels jede Art von Risiko wert ist.

Kurz gesagt: Wenn die Person nicht von der Richtigkeit der Entscheidung überzeugt gewesen wäre, hätte sie anders entschieden. Eine Bestrafung der Person stellt also keine sinnvolle Reaktion auf einen Fehler dar. Tatsächlich verringert man in der Regel mit einem solchen Schritt die Sicherheit, statt sie zu erhöhen.

Obwohl Jens beim Zahnarzt ist, kann das MusicStore-Team relativ gut nachvollziehen, was sich in der vergangenen Nacht zugetragen hat. Möglich wird das, weil Jens jeden seiner Schritte im Group-Chat-Tool des Teams dokumentiert hat. Wenn er Angst vor einer Bestrafung haben müsste, würde er vermutlich nicht selbst noch die Beweise in Form eines akribischen Protokolls liefern. Allgemein lässt sich feststellen, dass die Mitarbeiter in Organisationen mit einer ausgeprägten Bestrafungskultur nicht ehrlich sind, sondern versuchen, ihre Fehler zu vertuschen. Ohne detaillierte Informationen über die Entstehung werden der Mitarbeiter und seine Kollegen ähnliche Fehler in Zukunft kaum vermeiden können.

Blameless Postmortems helfen, Fehler bestmöglich zu verstehen und sie damit zukünftig zu verhindern

Systeme werden nur sicherer, wenn alle Beteiligten offen über Fehler und deren Entstehung sprechen können und keine Strafe fürchten müssen. Dieses Prinzip einer Blameless Culture ist in der Luftfahrt, und der Medizin schon länger bekannt. Hier wird ein Fehler als Möglichkeit gesehen, das System zu stärken.

IT-Unternehmen wie Google, Etsy, GitHub oder AWS haben deshalb für die systematische Analyse von Fehlern sogenannte Blameless Postmortems etabliert. Diese Postmortems werden bei Google in den folgenden Fällen durchgeführt:

  • User-visible downtime or degradation beyond a certain threshold
  • Data loss of any kind
  • On-call engineer intervention (release rollback, rerouting of traffic, etc.)
  • A resolution time above some threshold
  • A monitoring failure (which usually implies manual incident discovery)

Im Rahmen des Postmortems analysieren die beteiligten Personen den Fehler und seine Entstehung. Sie schreiben den zeitlichen Verlauf, den Kontext und die abgeleiteten Maßnahmen dann in einem Dokument auf, das von anderen Ingenieuren in der Firma gegengelesen und allen Teams zugänglich gemacht wird. Ein Beispiel findet sich hier. Am Ende handelt es sich bei einem solchen Postmortem um eine spezielle, technisch orientierte Retrospektive. Unter anderem wird hier auch festgehalten, was im Kontext des Fehlers gut gelaufen ist.

Jens‘ Protokoll im Chat-Tool stellt eine gute Ausgangsbasis für ein Postmortem dar, weil der zeitliche Verlauf sich offenbar klar erkennen lässt. Und es gibt offensichtlich Dinge, die gut funktioniert haben: Jens als Diensthabender ist sehr zügig über den Fehler informiert worden, er konnte seine Aktionen vom Group -Chat-Tool aus durchführen und der Deployment-Prozess ließ ihn zügig eine neue Version ausrollen, als er die Ursache identifiziert hatte. Das MusicStore-Team muss sich allerdings die Frage stellen, warum ihr Softwareentwicklungsprozess solche Fehler zulässt, wie sie Jens unterlaufen sind. Warum kann er das veränderte Laufzeitverhalten des APIs erst in Produktion sehen? Wie ist es möglich, dass durch ein Softwareupdate ein falscher API Key im Produktivsystem landet? Das Team sollte sich mit diesen Fragen beschäftigen, statt Jens die Schuld zuzuschieben.

Dieser Prozess fand statt, als Jens von seinem Arzttermin zurückkam. Als Ergebnis hat das Team in zusätzliche Tests und ein besseres Management der API Keys investiert.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: