Der nächste «Incident» kommt bestimmt.

Systemausfälle sind unvermeidlich. Inzwischen hat sich eine Best Practice herausgebildet, wie man sie danach aufbereitet und kommuniziert.

Wer vorbereitet ist, ist besser dran. Denn der nächste «Incident» kommt bestimmt (Bild: Austin Distel on Unsplash)

Manches haben sie in den USA einfach besser drauf als wir. Zum Beispiel den schönen Euphemismus für alle Lebenslagen. Was für uns Mitteleuropäer schon als peinliche Katastrophe gilt, nennen sie oft nur schlicht «Incident», also Vorfall oder Ereignis und erst in der übertragenen Bedeutung: Zwischenfall.

Heute vor zwei Wochen hatte ich über den eigentlich kleinen Zwischenfall beim Schweizer Discounter Otto's geschrieben, und dass Otto's PDF-Kommunikation nicht ganz optimal war. Nun hat Otto's eine starke Präsenz in der physischen Welt, und vermutlich werden nicht viel weniger Menschen in die Filialen gehen wegen eines kaputten Gewinnspiels.

Bockt die Software, bröckelt das Vertrauen

Anders sieht es aus, wenn eine Firma mit Software oder softwarebasierten Dienstleistungen ihr Geld verdient und womöglich insbesondere private, vertrauliche oder anderweitig wertvolle Daten ihrer Kundinnen und Kunden managt. Wenn es hier schief läuft, stellen diese schnell die Vertrauensfrage, ob sie nicht allenfalls bei einem anderen Anbieter besser aufgehoben wären.

In dieser Woche erlangte das Thema neue Aktualität – das trifft allerdings auf fast jede Woche zu – als der Tages-Anzeiger berichtete, dass im privatem System «MyCloud» von Swisscom Kundendaten verloren gegangen seien, und zwar schon Mitte 2018*. Da eine umfassende Kommunikation von Swisscom fehlte, rekonstruierte Watson den Fall mit der Timeline einer Support-Odyssee, die schon beim Lesen schmerzt. Swisscom schob rasch eine etwas halbherzige Kommunikation mit nebulösen Angaben («Rund 98% der Betroffenen haben weniger als einen Zwanzigstel ihrer Daten verloren.») nach, wofür sie in der proaktiven Variante ein Jahr Zeit gehabt hätte.

Verschlüsselt ist nicht gleich verschlüsselt

Ich bin zwar Swisscom-Kunde, aber nicht MyCloud-User, und das wird auch so bleiben, denn mir wird vor allem ein Fakt aus dem Tagi-Artikel im Gedächtnis bleiben: Die Daten werden zwar verschlüsselt übertragen, aber nicht verschlüsselt gespeichert, sind also – anders als etwa bei Dropbox – für Servicemitarbeiter der Swisscom frei einsehbar. Das zeigt einmal mehr, dass «selbstgestrickte» Angebote für den Schweizer Markt zwar mit heimischen Servern werben, aber bei den Features meist mit den Weltmarktführern aus dem Silicon Valley nicht mithalten können.

Apropos Silicon Valley: Bei den (guten) Tech-Firmen hat sich inzwischen eine Art Standard für die Krisenkommunikation herausgebildet, der im Jargon «Incident Postmortem» heisst, also metaphorisch das «Abliegen» eines IT-Systems mit dem Tod vergleicht, dessen Ursachen es danach zu analysieren gilt.

6 Ratschläge: Richtig reagieren

Den ultimativen Artikel zum Thema hat die Software-Firma Atlassian verfasst: The importance of an incident postmortem process.

Alle Postmortem-Ratgeber betonen diese wichtigen Aspekte:

• Es geht ums Lernen, um die Vermeidung zukünftiger Probleme, und vor allem darum, das Vertrauen von internen Usern und Kunden zurückzugewinnen.
• Keine Schuldzuweisungen.
• Details, Details, Details. Je mehr man offenlegt, desto besser können sich versierte User ein Bild darüber machen, ob es eher Unfähigkeit oder einfach ein dummer Zufall war. Die in der Timeline getroffenen Entscheidungen erlauben oft auch spannende Einblick in die Priorisierung, zum Beispiel «Datenintegrität versus schnelle Behebung» (etwa beim vorbildlichen Postmortem von Github im letzten Oktober – man hätte sich sehr viel Ärger sparen können, wenn man die Änderungen von etwa 30 Minuten verloren hätte, hat sich aber dagegen entschieden).
• Don't procrastinate. Einmal ausschlafen nach der Wiederherstellung des Systems, und dann dokumentieren, denn danach vergisst man schnell wichtige Details.
• Man sollte eine Vorlage verwenden. Auf Englisch gibt es zahlreiche Templates, die sich leicht adaptieren lassen.

Ich würde noch hinzufügen: Nicht delegieren. Insbesondere in einem Startup ist der CEO der richtige Absender für einen Postmortem-Beitrag, auch wenn er sich, wie es auch bei uns wäre, die Geschichte von seinem CTO erklären lassen muss. 

Nochmal zurück zur ernüchternden Aussage aus der obigen Grafik: Der «Incident» wird früher oder später passieren. Wer vorbereitet ist, ist besser dran.  

PS. Fast trivial ist die Aussage, dass man natürlich unbedingt vermeiden sollte, dass die Wahrheit scheibchenweise ans Licht kommt. Wer sich in den Ferien mit einem der grausamsten Beispiele der Technologie-Geschichte belasten will, dem empfehle ich die so brillante wie erschütternde Fernsehserie«Tschernobyl». In den letzten beiden Episoden geht es genau um unser Thema Postmortem: den Konflikt zwischen Politik und Wissenschaft bei der Aufarbeitung der Gründe. 

Unsere Leseempfehlungen zum Thema:

The importance of an incident postmortem process

Der bereits erwähnte beste Überblick zum Thema, von den australischen Kollegen von Atlassian (Confluence, Jira, Trello). Enthält auch einen Link zu ihrem Template.

Site Reliability Engineering

Bei Google gibt es ein Team, das sich nur um die Uptime ihrer Services kümmert: Site Reliability Engineering. Sie haben ein 52-minütiges Video mit interessanten Einblicken publiziert – und sogar ein Buch darüber geschrieben: Site Reliability Engineering – How Google Runs Production Systems.

Ein schwarzer Montag

Es gibt nicht viele gute Beispiele für Schweizer Postmortems. Vor zwei Jahren hatte der Basler Hosting-Anbieter Cyon mal einen sehr schlechten Tag, den Gründer David Burkardt ganz ordentlich aufgearbeitet hat.

A List of Post-mortems!

Auf der Entwicklerplattform GitHub hat jemand Links zu hunderten von Postmortems gesammelt. Die schiere Länge der Liste zeigt einmal mehr: Niemand ist gefeit. *Im Newsletter vom 20. Juli 2019 schrieben wir versehentlich, dass MyCloud-Daten Mitte 2008 statt 2018 verloren gegangen seien. Das tut uns leid.