SRE - Postmortems

 

Was ist ein ein Postmortem?

Ein Postmortem ist die Durchführung einer Retrospektive nach einem Servicevorfall.

Je nach Organisation hat eine Postmortem-Analyse viele Bezheichnungen:

Retrospektive , Ursachenanalyse (RCA), Vorfallbesprechung und andere. Es geht darum , ein Dokument zu erstellen, in dem festgehalten wird, warum ein Vorfall passiert ist, und mit den Beteiligten zu besprechen, was passiert ist.

Der Begriff „Postmortem“ wird in der Regel mit medizinischen oder juristischen Berufen in Verbindung gebracht. Das Oxford English Dictionary definiert ihn als „Untersuchung eines toten Leichnahms zur Feststellung der Todesursache“. Diese Definition ist der Grund dafür, dass viele Menschen in der Softwarebranche den Begriff „postmortem“ verwenden. Manche betrachten Softwareprozesse als Lebewesen, und wenn ein Prozess anhält, wird er als tot bezeichnet. Diejenigen, die die Idee, einer Maschine Leben zuzuschreiben, problematisch finden,  verwenden oft die Begriffe Incident Review oder RCA. Unabhängig von der verwendeten Bezeichnung besteht das Ziel darin, ein historisches Artefakt zu erstellen und den Vorfall, der sich ereignet hat, zu diskutieren.

Warum ein Postmortem schreiben ?

Die Erstellung eines Postmortem-Dokuments ist der richtige Zeitpunkt , um herauszufinden, was passiert ist. Wie ist der Prozess abgestürzt? Welcher Teil des Systems verursachte die Instabilität? Wie lange nach Beginn des Vorfalls haben wir dies bemerkt?

Warum sind andere Systeme ausgefallen?

Wir führen eine Postmortem-Untersuchung getrennt vom ursprünglichen Vorfall durch, um gründlich und sorgfältig vorgehen zu können. Wir müssen sicherstellen , dass uns alle Daten vorliegen und wir das Problem vollständig beheben können. Bei einem Zwischenfall fließt of das Adrenalin und es werden schnelle Bauchentscheidungen getroffen. Das liegt daran, dass nur sehr wenig Zeit zum Nachdenken und Abwägen von Entscheidungen bleibt. Wenn wir die Analyse und die Nachforschungen erst im Nachhinein durchführen, können wir mit mehr Leuten sprechen, stehen nicht unter dem Stress des Ausfalls und haben mehr Zeit, eine kalkulierte Entscheidung zu treffen. Auf der Grundlage dieser Analyse können wir beschließen, ein Dokument zu erstellen, in dem wir unsere Erkenntnisse zusmmenfassen und den Vorfall mit unseren Teamkollegen teilen. Um einen Postmortem zu verfassen ist auf jeden Fall eine Analyse erforderlich . Sie müssen wissen , warum etwas fehlgeschlagen ist. 

Die Entscheidung ein Dokument zu erstellen, ist optional , aber ein Bericht ist nutzlos , wenn Sie den Vorfall nicht analysieren und herausfinden , was passiert ist.

Ein Postmortem ist auch ein historisches Dokument. Es ist sehr wahrscheinlich , dass Sie nicht ewig für eine Organisation arbeiten werden und dass es in Ihrer Organisation Mitarbeiter geben wird, die nicht an dem Vorfall oder dem ausgefallenen Dienst beteiligt waren. In einem Postmortem-Dokument können Sie festhalten, was passiert ist, wie Sie das Problem gelöst haben und was Ihr Team daraus gelernt hat.

Wann ist ein Postmortem-Dokument zu erstellen?

Eine Frage, die oft gestellt wird, wenn mit Dokumentationen von Postmortem in einer Organisation begonnen wird, lautet: „Soll ich einen Postmortem schreiben?“ Es gibt viele verschiedene Möglichkeiten, wie Organisationen entscheiden, wann ein Postmortem geschrieben werden soll, aber ich habe eine einfache Regel, die ich gerne befolge: Wenn jemand nach einem Postmortem fragt, sollte man eines schreiben. In einer großen Organisation funktioniert das hervorragend , denn oft wird jemand fragen:“Was hatte es mit dem Vorfall von gestern Abend auf sich?“ oder „Wird es einen Postmortem für den Ausfall von gestern Abend auf sich?“ oder „Wird es einen Postmortem für den Ausfall von letzter Woche geben?“ Dies sind Anzeichen dafür , dass ein Dokument erstellt werden sollte.

In einer kleineren Organisation ist das schwieriger , weil Sie oft selbst entscheiden, ob Sie den Vorfall dokumentieren sollten. Um festzustellen, ob dies der Fall ist, könnten Sie eine interne Kennzahl entwickeln. Zum Beispiel: „Wenn wir mehr als 10 Minuten für die Wiederherstellung gebraucht haben, sollten wir einen Postmortem schreiben. 

Man sollte sich eine genaue Metrik ausdenken, um eine Postmortem zu schreiben. Die Metrik hat zwei Aspekte:

1, Wenn der Vorfall zweimal innerhalb weniger Tage auftritt, solle ich einen Postmortem schreiben.

2. Wenn es einen Ausfall länger als 30 Minuten gibt , sollte ein Postmortem geschrieben werden.

Ich verwende diese Metrtiken , weil sie dem Schweregrad entsprechen.

Es gibt kleinere Vorfälle aufgrund von Fehlern , Nachlässigkeit oder anderen Dingen. Bei der Geschwindigkeit , mit der wir arbeiten, können wir nicht alles aufhalten und dokumentieren, aber die Vorfälle, die diese Messwerte erreichen, scheinen die gleiche Art von Vorfällen zu sein, die eine größere Anzahl von Personen betreffen. 

Durchführung von Ereignisanalysen

Die Analyse von Vorfällen ist kompliziert. Sie sollten das System wie ein paranoider Sherlock Holmes angehen. Beginnen Sie am Tatort und gehen Sie dann jedem Aspekt auf den Grund. Seien Sie vorsichtig mit Ihren vorgefassten Meinungen, achten Sie auf  Ablenkungsmanöver und überprüfen Sie stets Ihre Hypothesen.

Der Tatort eines Ausfalls ist oft das , was Sie zurückgesetzt haben. Das kann eine fehlerhafte Konfiguration oder ein fehlerhafter Code sein. Wurde der Ausfall durch die Änderung verursacht, die ihr Team zu implementieren versuchte, oder durch ein System, das mit diesem Code interagiert? Dann können Sie damit beginnen , den geänderten Code oder den Code, der mit dem von Ihnen bereitgestellten Code interagiert, durchzulesen. Wenn es keinen Rollback gab, haben Sie das Problem wahrscheinlich schon herausgefunden, da Sie es während des Vorfalls herausfinden mussten, um das Problem zu lösen, sofern es sich nicht von selbst gelöst hat. Wir haben noch nicht über das Reverse Engineering von Systemen gesprochen, das oft ein wichtiges Werkzeug ist, also lassen Sie uns das genauer betrachten.

Beim Reverse Engineering geht man von einem System aus und findet heraus , wie es funktioniert, indem man mit ihm interagiert und sieht, wie es auf Eingaben reagiert. Wenn ich ein System habe, über das ich nichts weiß und niemanden dazu befragen kann (weil er schläft, nicht mehr arbeitet oder aus einem anderen Grund), beginne ich damit, mir anzusehen , wie die Dinge mit ihm interagieren. 

Versuchen sie ein Flow-Diagramm zu erstellen. Denken Sie daran , dass das Ziel nicht darin besteht, die Software vollständig zu verstehen, sondern herauszufinden, wie sie das tut, womit Sie Probleme haben. Ruft sie andere externe oder interne unterstützende Dienste auf? Speichert sie Daten? Kann sie diese beiden Dinge tun? Gibt es Kommentare, und stimmen Sie mit dem überein , was der Code tatsächlich tut? Wenn Sie dies herausgefunden haben, können Sie ein Systemdiagramm erstellen, in dem entweder die Funktionen doer die Dienste zusammenwirken.

Wie man ein Postmortem-Dokument verfasst

Der Vorfall ist passiert, und Sie haben beschlossen, ein Postmortem-Dokument zu verfassen. Sie haben Ihre Analyse gemacht. Was schreiben Sie hinein? Meine grobe Vorlage sieht in der Regel wie folgt aus: Zusammenfassung, Auswirkungen, Zeitleiste, Grundursache,Aktionspunkte und Anhang. 

Fügen Sie am Anfang des Dokuments die Namen der beteiligten Personen, das Datum des Vorfalls und das Datum der letzten Änderung des Dokuments ein. Wenn Sie ihre Postmortems in einem Online-System speichern, können Sie Schlüsselwörter oder Tags hinzufügen, um das Dokument zu Organisierung.

=> Zusammenfassung

Der erste Abschnitt sollte eine Zusammenfassung sein. Das bedeutet, dass jeder der dieses Dokument öffnet, eine ungefähre Vorstellung davon. Haben sollte, was passiert ist, wann es passiert ist und wer betroffen war. In der Regel handelt es sich um eine kurze Erklärung,

=>Auswirkungen

Ich nehme diesen Abschnitt nicht immer auf, aber er ist hilfreich, wenn es darum geht, wie der Kundendienst reagieren soll oder ob es irgendwelche externen Auswirkungen des Ausfalls geben wird. Der Abschnitt über die Auswirkungen ist ein guter Platz, im die Kunden zu beschreiben, die von dem Ausfall betroffen waren, alle öffentlichen Nachrichten über den Ausfall, eine Diskussion darüber, wie sich der Ausfall auf die SLA Ihres Dienstes ausgewirkt hat, und vielleicht ein oder zwei Grafiken. Sie können auch Statistiken über die Zeit bis zur Wiederherstellung oder die Reaktionsgeschwindigkeit des  Bereitschaftsdienstes einfügen, wenn Ihr Unternehmen daran interessiert ist, diese Daten zu messen.

Es ist wichtig, dass die Leser des Postmortem die Auswirkungen des Vorfalls verstehen, die nicht nur aus fehlgeschlagenen Anfragen, fehlgeschlagenen Aufträgen oder anderen technischen Fehlern resultieren. 

=> Zeitleiste

Dieser Abschnitt gefällt mir sehr gut, da er eine minutengenaue Erklärung des Geschehens liefert. Jede Zeile besteht aus einem Zeitstempel und einer Beschreibung. In der Beschreibung bieten Links zu Codeänderungen, Zeitleisten für Ereignisse und die Bereitstellung von Diensten zusätzliche Einblicke und Details zu dem Dokument. 

=> Grundlegende Ursache

Die Ursachenforschung ist wahrscheinlich der wichtigste Abschnitt eines Postmortem. Er beschreibt , was den Ausfall verursacht hat. Die vorherigen Abschnitte beschreiben, was passiert ist oder wie es passiert ist, aber nicht warum. Wenn wir zukünftige Ausfälle verhindern wollen, müssen wir wissen , warum sie passiert sind. 

=> Aktionspunkte 

Aktionspunkte sind eine liste von Maßnahmen, die nach dem Vorfall zu ergreifen sind, in der Regel mit angehängten Tickets oder einem Tracking. Tickets sind gut , weil sie die Verantwortlichkeit und die Prioritäten für die Behebung des Problems festlegen. Aktionspunkte stellen sicher, dass eine Gruppe von Personen daran arbeitet, einen erneuten Ausfall zu verhindern, und es ist wichtig, dass die Verantwortlichkeit gegeben ist. Unabhängig davon, wie das Problem aufgetreten ist, sollte das Team zusammenarbeiten, um sicherzustellen, dass es nicht noch einmal auftritt.

=> Anhang

Der Anhang ist der Abschnitt, in dem Sie alle mit diesem Vorfall zusammenhängenden Dinge hinzufügen. Das Hinzufügen von Chatprotokollen, relevanten Dienstprotokollen, Screenshots, Grafik, externen URLs ist.

Der Anhang ist genauso nützlich wie die Zeitleiste - er gibt Aufschluss darüber , wie Sie zu den Ursachen gelangt sind, und bietet visuelle Darstellungen, die den Text ergänzen. Der Anhang ist auch deshalb wichtig , weil die heute verwendeten Instrumente in Zukunft  vielleicht nicht mehr zur Verfügung stehen werden und die Daten selten für immer in der gleichen Qualität überwacht werden können. 

Durchführung einer Postmortem-Sitzung

Eine Postmortem-Sitzung ist die Folgemaßnahme zum Dokument. Dabei werden häufig die Maßnahmen abgeschlossen, die Ergebnisse der Ursachenforschung erörtert und ein sicherer Rahmen für die Diskussion geschaffen. Zu einer Postmortem-Besprechung werden in der Regel am besten diejenigen eingeladen, die an dem Vorfall beteiligt waren - der technische Leiter der betroffenen Dienste, der Produktmanager für die betroffenen Dienste und alle interessierten Techniker. Es ist schwierig, das richtige Gleichgewicht zu finden, denn wenn die Besprechung zu groß ist, wird nicht viel erreicht, aber wenn die Besprechung zu klein ist, wird das Wissen nicht gut weitergegeben.

Es ist ein gute Idee, dass die am Vorfall Beteiligten anwesend sind, da sie wissen, was passiert ist, falls Daten in dem Dokument fehlen. Die technischen Leiter der betroffenen Dienste sollten anwesend sein, falls Annahmen über ihre Dienste gemacht werden, die nicht der Wahrheit entsprechen, und die Verantwortung übernehmen, um sicherzustellen, dass die Maßnahmen umgesetzt werden. Die Produktmanager der betroffenen Dienste sind wichtig, da sie helfen können, die geschäftlichen Anforderungen in Bezug auf den Dienst zu beschreiben und mit den technischen Leitern zusammenzuarbeiten, um sicherzustellen, dass die Korrekturen nach Priorität geordnet werden. Um den Wissentransfer zu fördern,ist es wichtig , interessierten Personen die Teilnahem zu ermöglichen.

Der Incident Commander des Vorfalls sollte die Besprechung leiten. Er schreibt zwar nicht immer den gesamten Postmortem, kennt sich aber oft am besten mit dem Ereignis und den Beteiligten aus und kann die Konversation leiten. Eröffnen Sie die Sitzung mit einer Erklärung, in der Sie diejenigen, die das Dokument nicht gelesen haben, auffordern, sich von der Sitzung zu entschuldigen oder sich bereit erklären, nicht teilzunehmen. Der Gedanke dahinter ist, dass diejenigen , die das Dokument nicht gelesen haben, Fragen stellen oder Erklärungen abgeben werden, die möglicherweise bereits in dem Dokument beantwortet werden. Die Sitzung sollte sich nicht an diejenigen richten, die sich nicht die Zeit nehmen konnten, sich über den Vorfall zu informieren, um einen größeren Lerneffekt zu erzielen. Versuchen Sie anschließend, sich an die folgende Tagesordnung zu halten:

=> Ein kurzer Zeitplan und eine Zusammenfassung des Vorfalls:

Dies sollte nicht länger als fünf Minuten dauern. Denken Sie daran, dass jeder das Dokument bereits gelesen hat und dies eher dazu dient, die Informationen aufzufrischen udn auf besonders bemerkenswerte Fakten hinzuweisen. Sie müssen nicht jede Minuten aufzählen, sondern nur grobe Züge nennen.

=>Erörterung der Grundursache: 

Dies ist in der Regel der variabelste Abschnitt, da die Menschen manchmal nicht verstehen, wie die Ursache überhaupt möglich gewesen sein könnte. Dies ist auch ein Bereich, in dem Menschen defensiv werden können, wenn sie sich angegriffen oder beschuldigt fühlen. 

Versuchen Sie, die Diskussionen zivilisiert zu führen und alle Schuldzuweisungen auf die Zsammenarbeit zu lenken, da wir alle für den Erfolg des anderen verantwortlich sind. Achten Sie auch darauf, dass Sie sich nicht zu sehr in Diskussionen darüber verlieren , wie eine Lösung für die Grundursache gefunden werden kann. Wenn es keine offensichtliche Lösung gibt, sollte eine Folgesitzung für die Entwicklung einer Lösung anberaumt werden, die ein Aktionspunkte sein sollte.

=> Fragen: 

Dieser Abschnitt wird oft in den vorherigen Abschnitt übergehen, aber Sie können die Teilnehmer dazu auffordern, Fragen vorab einzureichen, wenn es sich um eine große Gruppe handelt, oder alle Bedenken, die die Teilnehmer haben könnten, durchgehen.

Diskussion der Aktionspunkte: 

Die vorangegangenen Diskussionen haben möglicherweise zusätzliche Aktionspunkte hervorgebracht; stellen Sie also sicher, dass alle Aufgaben ordnungsgemäß dokumentiert sind. Wenn Sie einen Fehlerverfolgungsdienst haben, stellen Sie sicher, dass die Fehler protokolliert und mit dem Dokument verknüpft werden. Stellen Sie außerdem sicher, dass jemand für die Fehelr verantwortlich ist. Wir wollen niemanden beschuldigen, aber wir wollen sicherstellen, dass Fehelrbehebungen auch umgesetzt werden. Eines der ärgerlichsten Gefühle ist die Teilnahme an mehreren Postmortems, die alle die gleichen Aktionspunkte haben, aber niemand sorgt dafür, dass die Korrekturen durchgeführt werden.

Dieser Zeitplan eignet sich hervorragend für größere Organisationen. 

In kleineren Organisationen ist es oft sinnvoll, weniger formell zu sein und schneller vorzugehen. In diesen Fällen gefällt mir eine schnelle Diskussion über einen Postmortem oder einen Vorfall:

=> Was hat funktioniert? 

Gehen sie durch den Raum und bitten Sie jede Person, bis zu drei Dinge aufzulisten, die während des Vorfalls funktioniert haben.

=> Was hat nicht funktioniert?

Lassen Sie jede Person sagen, was ihrer Meinung nach nicht gut funktioniert hat.

=> Was sollten wir anfangen zu tun? 

Bitten Sie diesmal die Teilnehmer , eine Sache aufzulisten, mit der das Team ihrer Meinung nach beginnen sollte. Dies ist oft ein guter Weg , um die Prioritäten von Maßnahmen festzulegen oder neue Maßnahmen zu entwickeln.

=> Was sollten wir nicht mehr tun?

Konzentrieren Sie sich stattdessen darauf , was das Team nicht mehr tun sollte.

=> Was sollten wir verbessern?

Gehen Sie schließlich herum und konzentrieren Sie sich auf die Dinge , die Sie verbessern wollen.

Analyse frühere Postmortems

Wenn alles gesagt und getan ist , ist es gut , zurück zu gehen und die vergangenen Postmortems zu überprüfen. Sammeln Sie einmal im Quartal oder einmal im Jahr alle Postmortems und versuchen Sie , einige Metriken zusammenzustellen. Diese Metriken können Ihnen Aufschluss darüber geben, wie Ihr Team auf Vorfälle reagiert:

=> Zeit bis zur Wiederherstellung

=> Zeit zwischen Ausfällen

=> Anzahl der ausgelösten Warnmeldungen im Vergleich zu den erstellten Postmortems

=> Anzahl der Ausschreibungen pro Bereitschaftsdienst-Rotation

MTTR und MTBF

Außerhalb von Zwischenfällen sind zwei Kennzahlen, über die oft gesprochen wird, die mittlere Zeit bis zur Wiederherstellung (MTTR) und die mittlere Zeit zwischen Ausfällen (MTBF). Ein Blick auf diese Zahlen über ein Jahr hinweg kann zeigen, wie sich Ihre Fähigkeit, auf Zwischenfälle zu reagieren, verbessert oder verändert.

Beachten Sie, dass das Ziel darin besteht, die Zeit bis zur Widerherstellung zu minimieren, nicht unbedingt die Zeit, bis die Ursache des Ausfalls behoben ist. Wenn die MTBF niedrig ist, kann das bedeuten, dass Ihr Team nicht genug in Tests investiert, und das belastet wahrscheinlich, dass Ihr Team nicht weiß, wie es auf  Vorfälle reagieren soll, oder dass die Werkzeuge für Rollbacks und andere Wiederherstellungsmaßnahmen schlecht oder langsam sind.

Meldungsmüdigkeit

Es ist wichtig für die Gesundheit der Mitarbeiter, herauszufinden, wie viel Prozent der Warnmeldungen umsetzbar waren. Anhand einer historischen Aufzeichnung von Alarmen, die zu Postmortems wurden, von Alarmen pro Rotation und von umsetzbaren Alarmen können Sie feststellen, ob die Responder überfordert sind und ob sie von wichtigen Dingen unterbrochen werden. Wenn Sie Techniker haben, die wissen, dass sie jedes Mal um drei Uhr morgens geweckt werden, wenn sie auf Abruf bereitstehen, bleiben sie vielleicht nicht lange dabei oder hören einfach auf zu reagieren.

Vergangene Ausfälle besprechen

Sobald Sie Daten über Ihre vergangenen Postmortems und Ausfälle gesammelt haben, sollten Sie sie mit dem Team teilen. Nach der Weitergabe der Daten kann es sinnvoll sein, Einzelgespräche zu führen oder eine Teamsitzung abzuhalten, in der die Mitarbeiter ihre Bedenken über den aktuellen Zustand der Störungsreaktion mitteilen. Manchmal hat das Team ein gutes Gefühl , während es in anderen Fällen das Gefühl hat, dass etwas fehlt - vielleicht zu viele Warnungen, schlechte Überwachung oder das Gefühl, dass die Behebung von Ausfällen nicht mir der nötigen Priorität behandelt wird.

Voriges Thema:

https://einsiedlerkreps.blogspot.com/2023/05/sre-monitoring.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-reaktion-auf-vorfalle-incident.html

Auskopplung vom Post:

https://einsiedlerkreps.blogspot.com/2023/05/sre-die-nachste-stufe-von-devops-teil.html