Wiederherstellungspläne für risikoreiche Infrastrukturänderungen

Sie haben eine Änderung vor sich, die die Produktion lahmlegen könnte. Vielleicht ist es eine Überholung der Netzwerkarchitektur, eine Datenbankmigration oder eine Neukonfiguration von Sicherheitsgruppen, die kritische Dienste betrifft. Das Team hat den Plan geprüft, den Schadensradius abgeschätzt, und alle sind sich einig, dass die Änderung ein echtes Risiko birgt.

Was nun?

Bevor jemand terraform apply ausführt oder auf den Deploy-Button klickt, brauchen Sie einen Wiederherstellungsplan. Kein dickes Dokument, das im Regal verstaubt. Sondern einen praktischen, spezifischen, ausführbaren Plan für den Fall, dass etwas schiefgeht.

Beginnen Sie mit einer Frage

Der gesamte Wiederherstellungsplan beginnt mit einer einzigen Frage: Wenn diese Änderung fehlschlägt, was müssen wir tun, um alles wieder in einen sicheren Zustand zu versetzen?

Die Antwort hängt davon ab, was Sie ändern und wie weit der Schadensradius reicht. Eine einfache Konfigurationsänderung an einer Sicherheitsgruppe hat vielleicht eine kurze Antwort: die alte Konfiguration erneut anwenden. Eine Änderung der Netzwerkarchitektur oder eine Datenbankmigration erfordert eine viel detailliertere Antwort.

Machen Sie es nicht zu kompliziert. Der Wiederherstellungsplan sollte dem Risiko angemessen sein. Ein Fünfzeilen-Plan ist für eine Änderung mit geringem Risiko in Ordnung. Ein mehrstufiges Runbook ist für etwas angemessen, das einen Kerndienst lahmlegen könnte.

Drei Dinge, die jeder Wiederherstellungsplan braucht

Ein nützlicher Wiederherstellungsplan hat drei Komponenten, und alle müssen explizit sein.

Konkrete Wiederherstellungsschritte. „Auf die vorherige Version zurücksetzen“ ist kein Schritt. Schreiben Sie die genauen Befehle auf, die Server, auf denen sie ausgeführt werden, die zu verwendenden Parameter und wie Sie überprüfen, ob die Wiederherstellung tatsächlich funktioniert hat. Wenn jemand per SSH auf einen Bastion-Host zugreifen und einen bestimmten Terraform-Befehl mit einer bestimmten Statusdatei ausführen muss, sagen Sie das. Wenn jemand eine Datenbank aus einem Snapshot wiederherstellen muss, geben Sie den Snapshot-Namen und die Wiederherstellungsprozedur an.

Hier ist ein konkretes Beispiel dafür, wie diese Wiederherstellungsschritte für eine Sicherheitsgruppenänderung auf AWS aussehen:

# Wiederherstellungsplan: Sicherheitsgruppenänderung rückgängig machen
# Ziel: sg-12345678 (Produktions-Web-Tier)

# Schritt 1: Sicherheitsgruppenregeln rückgängig machen
aws ec2 revoke-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 10.0.0.0/16

# Schritt 2: Überprüfen, ob die Regeln korrekt sind
aws ec2 describe-security-groups \
  --group-ids sg-12345678 \
  --query 'SecurityGroups[0].IpPermissions'

# Schritt 3: Bestätigen, dass der Dienst erreichbar ist
curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health

Wer entscheidet, die Wiederherstellung zu aktivieren. Wenn etwas schiefgeht, geraten Leute in Panik. Sie beginnen, eigene Entscheidungen zu treffen. Einige werden sofort zurücksetzen wollen. Andere werden zuerst in das Problem eintauchen wollen. Sie brauchen eine einzelne Person oder Rolle mit der Befugnis zu sagen: „Stopp, wir stellen jetzt wieder her.“ Dies ist während eines Vorfalls kein demokratischer Prozess. Nennen Sie die Person oder Rolle explizit im Plan.

Wann der Plan aktiviert wird. Nicht jeder Fehler löst eine sofortige Wiederherstellung aus. Manchmal ist es besser, die Änderung laufen zu lassen, während das Team untersucht. Aber Sie brauchen klare Grenzen. Zwei gängige Ansätze funktionieren gut:

  • Zeitbasiert: Wenn das System innerhalb von 15 Minuten nach dem Anwenden der Änderung nicht stabil ist, starten Sie die Wiederherstellung.
  • Auswirkungsbasiert: Wenn die Fehlerrate über 5 Prozent steigt oder wenn Benutzer melden, dass sie nicht auf den Dienst zugreifen können, starten Sie die Wiederherstellung.

Schreiben Sie diese Schwellenwerte auf. Verlassen Sie sich nicht darauf, dass sich die Leute während eines Vorfalls daran erinnern.

Die Checkliste vor dem Anwenden

Bevor Sie eine risikoreiche Änderung anwenden, müssen bestimmte Dinge bereits erledigt sein. Dies ist Ihre Checkliste vor dem Anwenden, und sie gehört in den Wiederherstellungsplan.

Häufige Punkte sind:

  • Letzter Snapshot erstellt
  • Infrastruktur-Statusdatei gesichert
  • Zugriff auf Wiederherstellungssysteme bestätigt
  • Teammitglieder kennen ihre Rollen während der Wiederherstellung
  • Kommunikationskanal für die Koordination bei Vorfällen eingerichtet

Diese Checkliste existiert, weil Sie sich während eines Notfalls nicht auf die Wiederherstellung vorbereiten können. Wenn Sie vor der Änderung keinen Snapshot erstellt haben, können Sie danach nicht von diesem Snapshot wiederherstellen. Wenn Sie die Statusdatei nicht gesichert haben, können Sie nicht mit Zuversicht zurücksetzen.

Das folgende Flussdiagramm zeigt den gesamten Ablauf von der Änderungsprüfung über die Checks vor dem Anwenden, das Anwenden, das Überwachen bis hin zur Ausführung der Wiederherstellung, falls erforderlich.

flowchart TD A[Änderungsprüfung] --> B[Checks vor dem Anwenden] B --> C[Änderung anwenden] C --> D[System überwachen] D --> E{System stabil?} E -->|Ja| F[Änderung abgeschlossen] E -->|Nein| G[Auswirkung bewerten] G --> H{Wiederherstellung aktivieren?} H -->|Nein| I[Untersuchung fortsetzen] H -->|Ja| J[Wiederherstellungsbefehle ausführen] J --> K[Wiederherstellung überprüfen] K --> L[System wiederhergestellt]

Die Checkliste vor dem Anwenden dient auch als zwingende Maßnahme. Sie zwingt das Team, innezuhalten und zu bestätigen, dass eine Wiederherstellung tatsächlich möglich ist, bevor die Änderung vorgenommen wird. Wenn Sie nicht jeden Punkt abhaken können, wenden Sie die Änderung noch nicht an.

Wer genehmigt den Wiederherstellungsplan

Bei risikoreichen Infrastrukturänderungen muss der Wiederherstellungsplan von jemandem genehmigt werden, der die Auswirkungen versteht und die Befugnis hat, das Risiko zu akzeptieren. Dies könnte ein leitender Ingenieur, ein Engineering Manager oder ein Vertreter eines Teams sein, das von der Änderung betroffen sein wird.

Der Titel spielt keine Rolle. Worauf es ankommt, ist, dass der Genehmigende beurteilen kann, ob der Wiederherstellungsplan ausreichend ist oder ob es Lücken gibt. Er sollte in der Lage sein, Fragen zu stellen wie „Was passiert, wenn auch das Zurücksetzen fehlschlägt?“ oder „Wie überprüfen wir, ob das System nach der Wiederherstellung gesund ist?“

Dies ist kein reines Abnicken. Wenn der Genehmigende den Plan nicht gut genug versteht, um ihn zu beurteilen, sollte er ihn nicht genehmigen.

Speichern Sie den Plan, wo Leute ihn finden können

Ein Wiederherstellungsplan ist nutzlos, wenn ihn während eines Vorfalls niemand finden kann. Speichern Sie ihn nicht auf Ihrem Laptop. Legen Sie ihn nicht in einen Ordner, der speziellen Zugriff erfordert. Vergraben Sie ihn nicht in einem langen E-Mail-Thread.

Legen Sie den Plan an einem gemeinsamen Ort ab, auf den alle Beteiligten schnell zugreifen können. Team-Wiki, gemeinsames Laufwerk oder sogar als Datei, die dem Pull-Request beigefügt ist, der die Infrastrukturänderung enthält. Das Ziel ist es, jede Reibung zwischen „etwas ist schiefgelaufen“ und „wir haben den Plan vor uns“ zu beseitigen.

Eine kurze praktische Checkliste

Bevor Sie eine risikoreiche Infrastrukturänderung anwenden, gehen Sie diese Punkte durch:

  • Wiederherstellungsschritte sind mit genauen Befehlen und Parametern aufgeschrieben
  • Eine bestimmte Person ist benannt, die entscheidet, wann die Wiederherstellung aktiviert wird
  • Zeit- oder Auswirkungsschwellenwerte für die Aktivierung der Wiederherstellung sind definiert
  • Letzter Snapshot oder letztes Backup ist als verfügbar bestätigt
  • Infrastruktur-Statusdatei ist gesichert
  • Alle Teammitglieder kennen ihre Rollen während der Wiederherstellung
  • Der Plan ist an einem für alle Beteiligten zugänglichen Ort gespeichert
  • Jemand mit Autorität hat den Plan geprüft und genehmigt

Der wahre Test kommt während der Ausführung

Ein Wiederherstellungsplan, der vorbereitet und genehmigt wurde, ist nicht dasselbe wie ein Wiederherstellungsplan, der funktioniert. Der einzige Weg, um zu wissen, ob Ihr Plan solide ist, ist, ihn zu testen. Das bedeutet, die Wiederherstellungsschritte in einer sicheren Umgebung durchzuspielen, zu überprüfen, ob die Befehle die erwarteten Ergebnisse liefern, und zu bestätigen, dass das Team den Plan unter Druck ausführen kann.

Aber das ist ein Thema für eine andere Diskussion. Für den Moment ist es wichtig, den Plan bereit zu haben, bevor Sie die Änderung anwenden. Ein guter Wiederherstellungsplan garantiert nicht, dass alles reibungslos verläuft, aber er bedeutet, dass Sie keine Entscheidungen im Dunkeln treffen müssen, wenn etwas kaputtgeht.