Pre-Mortems zur Vorbeugung von Obduktionen: Proaktives Engineering

Systeme versagen. Unsere Systeme hier bei FloQast sind ausfallanfällig, ebenso wie die in Ihrem Unternehmen, und sogar die da drüben. Angesichts der Tatsache, dass Systeme ständig und scheinbar zu den schlimmsten Zeiten ausfallen, ist es ein Wunder, dass in unserer modernen Welt überhaupt etwas funktioniert! Davon abgesehen, der Grund dafür in unserer modernen Welt funktioniert überhaupt alles ist weil Menschen haben sich auf diese Misserfolge vorbereitet.Diese Vorbereitungen bleiben manchmal ungenutzt und oft unbemerkt, aber sie sind präsent und von entscheidender Bedeutung. Verteilte Systeme, Notfallpläne, Backups, Redundanz — das sind alles Vorbereitungen, auf die wir uns verlassen, um uns nach einem Systemausfall zu erholen.

Ein weiterer Artikel in dieser Toolbox ist der vor dem Tod, das ist eine Planungsmethode, die uns zwingt, darüber nachzudenken, wie unsere Projekte scheitern können. Ein Pre-Mortem über den Projektumfang kann uns helfen, Eventualitäten in unsere Entwicklungssprints einzubeziehen, wohingegen ein Pre-Mortem für eine Codebereitstellung uns helfen kann, Risiken im Zusammenhang mit besonders kniffligem Code zu identifizieren. Auf diese Weise reduzieren wir das Chaos und die Verwirrung, die so leicht mit einem Produktionsausfall einhergehen können — eine ohnehin schon stressige Situation. Mit anderen Worten, ein Pre-Mortem hilft uns, eine Obduktion.Bei FloQast hatten wir vor Kurzem ein Pre-Mortem für ein Projekt, in dem wir einen kritischen, zeitkritischen Prozess geändert haben, der regelmäßig abläuft. Wir haben diese Details in einem Dokument festgehalten, damit wir sie problemlos mit anderen Teammitgliedern teilen können. (Und es war praktisch, als sich die Dinge ungewöhnlich verhielten. Aber das ist ein Blogbeitrag für einen anderen Tag...) Hier sind die Überlegungen, die wir in unser Pre-Mortem aufgenommen haben:(und ein Beispiel unten auf dieser Seite)

Überblick über das Projekt

Eine kurze Beschreibung des was und warum ist immer ein zuverlässiger Weg, um die Bühne zu bereiten. Wie würden wir vorgehen, um jemanden über dieses Thema auf den neuesten Stand zu bringen, wenn er zum ersten Mal davon hört?

• Was genau ändert sich durch das Projekt?
• Warum ist die Änderung notwendig?
• Gibt es einen historischen Kontext, den wir mit Ihnen teilen könnten?
• Wie würden wir das Risikoniveau für die Änderungen beschreiben?

Erwarteter Zeitplan und Personen

Auf diese Weise können wir auf einen Blick den Fortschritt ermitteln und die Ansprechpartner bei jedem einzelnen Schritt identifizieren, falls Fragen auftauchen. Wenn verschiedene Aktionen gleichzeitig ablaufen, können wir das auch hier nennen.

• Wann erwarten wir, dass die Feierlichkeiten beginnen werden? (d. h. Startzeit)
• Wer ist an dem Projekt beteiligt und welche Rollen/Verantwortlichkeiten haben sie? Wer wird die Systeme überwachen und welche Systeme sollten überwacht werden?
• Wie lange wird es dauern, bis die Änderungen aus dem Projekt wirksam werden? Arbeiten wir innerhalb eines strengen Zeitfensters?

Es ist in Ordnung, hier ungefähre oder relative Zeiten zu verwenden, auch wenn es sich um grobe Schätzungen handelt. Wir suchen nur nach einer schnellen Möglichkeit, ein Gefühl dafür zu bekommen, wie sich die Dinge entwickeln.

Was ist der Happy Path?

Bereite dich auf das Schlimmste vor... aber erwarte das Beste!

Wenn alles genau nach Plan verlaufen würde, wie würde es aussehen?

Wir können die Übersicht als Ausgangspunkt dafür verwenden, um einen Überblick über die erforderlichen Schritte zu erhalten. Als Nächstes fügen wir Details zu jedem der Schritte hinzu, einschließlich technischer Aufschlüsselungen des Codes und der Systeme, die dabei involviert sind.

Es ist hilfreich, diese Informationen wie ein Skript darzustellen, da wir uns so auf das konzentrieren können, was wir sind. erwartend passieren. Abweichungen vom Drehbuch könnten Anzeichen dafür sein, dass wir uns in die Gefahrenzone wagen.

Was kann schief gehen?

Jetzt kommt der lustige Teil: Zeit zum Brainstormen, welche Probleme auftreten können!

In typischer Brainstorming-Manier gibt es keine falschen Antworten — wir sollten alles herausgreifen, was die Dinge durcheinander bringen kann.

Es ist wichtig, dass wir mit diesen Problemen konkret umgehen und allzu allgemeine Formulierungen vermeiden (z. B. „das Warteschlangensystem reagiert nicht mehr“ oder „es funktioniert nicht“), da wir diese Gelegenheit auch nutzen wollen, um darüber nachzudenken, wie wir diese Probleme mildern oder sogar verhindern können.

• Was ist eine kurze Beschreibung des Problems?
• Was sind die Symptome? Woher wissen wir, ob wir in diesem Staat sind?
• Was sind die Auswirkungen auf den Endverbraucher?
• Sind Daten überhaupt betroffen?
• Welche Maßnahmen können wir ergreifen, um dies zu vermeiden? Können wir das Problem ohne Codebereitstellung beheben?
• Wenn wir das Problem beheben, gibt es danach zusätzliche Aufräumarbeiten?

Oft tauchen Muster auf, wenn wir diese Probleme aufzählen. Wir könnten sogar in der Lage sein, einige von ihnen zu gruppieren, wenn sie ähnliche Symptome oder Lösungen haben.

Das wird wirklich nützlich, wenn wir auf einen Misserfolg stoßen, den wir in der Voruntersuchung nicht erwartet hatten; er könnte in eine der Gruppen passen, die wir bereits identifiziert haben, was uns bei der Suche nach einer Lösung einen Vorsprung verschafft!

Überlegungen zum Rollback

Leider können wir das Problem nicht einfach beheben oder umgehen alles Probleme. In diesen Situationen müssen wir uns überlegen, wie wir unsere Arbeit rückgängig machen oder rückgängig machen können. Dies könnte beispielsweise das Zusammenführen einer Revert-PR für eine Codebereitstellung, das Stoppen eines Dienstes oder sogar das Löschen von Daten beinhalten, die während des Ereignisses erstellt wurden.

Wir wollen uns im Voraus auf diese Situation vorbereiten, da die Wahrscheinlichkeit hoch ist, dass wir uns zu einer Zeit darauf berufen, in der sich alle bereits zu sehr auf andere Details konzentriert haben. Daher ist es eine Zeit, in der einfache Fehler gemacht werden können. Im Rahmen unserer letzten Voruntersuchung hatten wir eine Revert-PR vorbereitet und überprüft, sodass wir loslegen konnten, bevor wir loslegten. (Am Ende haben wir uns für entschieden nicht Ich habe es damals eingesetzt, aber es war trotzdem eine gute Beruhigung.)

• Unter welchen Bedingungen sollten wir erwägen, Änderungen rückgängig zu machen?
• Wie führen wir ein Rollback durch?
• Wer muss den Rollback durchführen? (z. B. jemand mit verschmelzen Berechtigungen?)

Achte auf die Lücke

Die Hauptteilnehmer einer Vorsorgeuntersuchung sind die Personen, die die Veranstaltung koordinieren. Dazu gehören Produktvertreter und andere Teammitglieder, die in Bezug auf das Nutzererlebnis am Puls der Zeit sind. Es ist weniger wahrscheinlich, dass wir versehentlich etwas übersehen, wenn wir eine Vielzahl von Ideen und Sichtweisen aus verschiedenen Ebenen des Tech-Stacks haben.

Aber Dokumentation hilft nur, wenn sie jemand liest.

Daher sollten wir die Präferenzen unserer Teammitglieder berücksichtigen und das Dokument an ihre Bedürfnisse und Stile anpassen.

Wir genießen eine ziemlich ungezwungene Atmosphäre bei FloQast, was sich in einem Großteil unserer Dokumentation widerspiegelt - einfache Sprache und ein entspannter Ton, mit einer starken Chance auf GIFs.

Einige Teams fühlen sich jedoch möglicherweise mit einem strukturierten Format wohler: mit einem formellen Ton oder einer technisch präziseren Sprache. In ähnlicher Weise möchten wir vielleicht den allgemeinen Tenor bestimmter Themen kontrollieren, um die Dinge auf Kurs zu halten.

Das richtige Gleichgewicht zu finden, kann eine Herausforderung sein, aber das Wichtigste ist, es allen leicht zu machen, die Obduktion zu lesen und zu ihr beizutragen. Auf diese Weise können wir sicherstellen, dass alle auf derselben Wellenlänge sind, wenn es hart auf hart kommt.

Beispiel

(Hinweis: Dies ist kein echtes FloQAst-Pre-Mortem; wir laufen bereits auf Atlas.)

Überblick

Angesichts unseres beispiellosen Unternehmenswachstums verzeichnen wir einen enormen Zustrom neuer Kunden. Das bedeutet, dass viele neue Daten und Traffic auf unseren Servern ankommen. In letzter Zeit hatten wir Probleme, mit dieser erhöhten Belastung unseres DB-Clusters Schritt zu halten, insbesondere bei Wartung und Skalierung (siehe verwandter Vorfall). Wir haben uns für den MongoDB Atlas-Service entschieden, um diesen Druck etwas zu verringern und uns besser auf das Hinzufügen neuer Funktionen konzentrieren zu können. Wir verwenden den Atlas Live Migration Service, der dazu beitragen soll, das Risiko bei dieser Umstellung zu minimieren.

Erwarteter Zeitplan und Personen

Uhrzeit PDT (ca.) Beteiligte Aktionen Montag, 18 Uhr

(nach Geschäftsschluss)

Jess (DevOps)

• Überprüfen Sie den Zustand der Atlas-Instanz
• Stellen Sie sicher, dass die Daten in Atlas mit der Legacy-DB synchronisiert sind
• Go-/No-Go-Signal geben

(während des gesamten Prozesses) Jess (DevOps)

• Überwachen Sie den Zustand neuer und älterer Datenbanken

18:30 Uhr Liz und An (Eng)

• Verbindungs-PR für Rube Goldberg Service (RGS) zusammenführen
• Revert-PR erstellen

18:45 Uhr Kris und Luis (QE)

• Stellen Sie sicher, dass RGS funktioniert

19:00 Liz und An (Eng)

• Verbindungs-PR für App-Backend zusammenführen
• Revert-PR erstellen

19:15 Uhr Kris und Luis (QE)

• Überprüfen Sie, ob die App funktioniert

19:15 Uhr Jess (DevOps)

• Stellen Sie sicher, dass keine Verbindungen zur Legacy-Datenbank bestehen
• Zugriff auf Legacy-DB einschränken

20:00 Uhr (Team)

• Übergang abgeschlossen

Was ist der Happy Path?

Unsere neue Datenbank, die auf Atlas gehostet wird, wurde über den Atlas Live Migration Service mit unserer aktuellen (alten) Datenbank synchronisiert. Am Montag um 18 Uhr wird Engineering zwei PRs zusammenführen, um die Anwendung auf die neue Datenbank zu verweisen:

1. Rube Goldberg Service (RGS), der sicherstellt, dass die Planer nicht erstarren
2. Backend, das die von der App benötigten Daten bereitstellt

Nach der Zusammenführung jeder PR wird QE feststellen, dass sich die Anwendung wie erwartet verhält, ohne dass der Betrieb unterbrochen wird. Benutzer werden keine Ahnung haben, dass sie tatsächlich mit der neuen Datenbank verbunden sind.

DevOps wird erkennen, dass die Anwendung nicht mehr mit der Legacy-DB verbunden ist, und sie isolieren, sodass wir sie nächste Woche sicher außer Betrieb nehmen können.

Der Vorgang wird voraussichtlich einige Stunden dauern, könnte aber früher abgeschlossen werden, je nachdem, wie lange die Bereitstellungen und Tests dauern.

Was könnte schief gehen?

Probleme/SymptomeMögliche AktionenDer Atlas Live Migration Service synchronisiert nicht mit der Legacy-Datenbank

• Wir sehen Datenunterschiede zwischen den neuen und älteren DB-Instances

• Überprüfen Sie die Firewall und stellen Sie sicher, dass der Datenverkehr durchkommt
• Überprüfen Sie die Verzögerungszeit, um festzustellen, ob dies die Unterschiede erklärt
• Erwägen Sie, den Übergang abzubrechen wenn wir das nicht lösen können (und mehr untersuchen müssen)

Die Anmeldeseite reagiert nicht

• Die Planer sind verwirrt

• Starten Sie den Rube Goldberg Service Container neu

Das Laden von Benutzerprofilen dauert eine Weile

• Die Planer sind verwirrt

• Starten Sie den Rube Goldberg Service Container neu

Rube Goldberg Service gruselt weiter

• Container-Neustarts helfen nicht

• Führen Sie Rollback PR für RGS aus

Die gesamte Website reagiert nicht

• Andere Seiten als Registrierung und Benutzerprofil hängen
• Fehler beim Verbindungs-Timeout

• Überprüfen Sie die Berechtigungen für die neue Datenbank
• Überprüfen Sie die Firewall und die Konnektivität
• Erwägen Sie ein Rollback

Überlegungen zum Rollback

Das Engineering erstellt beim Zusammenführen Revert-PRs für die Verbindungs-PRs. Wenn wir während der Umstellung auf größere Probleme stoßen, können wir wieder auf die alte Datenbank zurückgreifen; besser, wir machen das richtig als schnell!

Wenn nach Abschluss der Umstellung Probleme auftreten und die Legacy-DB isoliert wurde, muss sich das Engineering mit DevOps abstimmen, um die DB wieder verfügbar zu machen, bevor die Revert-PRs angewendet werden.