RTO und RPO festlegen und testen

Definieren Sie zwei getrennte Ziele

Das Recovery Time Objective (RTO) legt die maximal akzeptable Unterbrechung fest, bis der Dienst wieder nutzbar sein muss. Das Recovery Point Objective (RPO) legt den maximal akzeptablen Datenverlust als Zeitspanne fest. Vereinbaren Sie diese Ziele mit dem fachlich Verantwortlichen für einen definierten Dienst und ein Ausfallszenario.

Ein Verfügbarkeitsziel beschreibt die Verfügbarkeit eines Dienstes über einen Zeitraum. RTO und RPO beschreiben Erwartungen an die Wiederherstellung. Sie beantworten unterschiedliche Fragen.

Für einen fiktiven Bestelldienst setzt der Verantwortliche das RTO auf 60 Minuten und das RPO auf 15 Minuten. Dies sind Beispielwerte, keine allgemeinen Empfehlungen. Ein anderer Dienst kann andere Grenzen brauchen, weil fehlende Bestellungen und verspätete Berichte unterschiedliche Folgen haben.

Messen Sie die gesamte Wiederherstellung

Der Dienst stoppt um 10:00. Das Team erfasst diese Übung:

Die gesamte Wiederherstellungszeit beträgt 55 Minuten. Die Übung erfüllt das RTO von 60 Minuten. Nur die 25 Minuten des Wiederherstellungsvorgangs zu zählen, würde den Großteil der Unterbrechung verbergen.

Der neueste nutzbare Wiederherstellungspunkt ist 09:40. Bis zur Unterbrechung um 10:00 liegen 20 Minuten. Das verfehlt das RPO von 15 Minuten um 5 Minuten. Dieselben Daten schneller wiederherzustellen, würde diese Lücke nicht schließen.

Untersuchen Sie tatsächlich fehlende oder inkonsistente Datensätze. Eine Zeitlücke beschreibt das Risiko, zählt aber nicht die betroffenen Bestellungen. Gleichen Sie externe Zahlungs- und Auftragsabwicklungsdaten ab, bevor Sie die normale Verarbeitung fortsetzen. Testen Sie andere Annahmen in der Wiederherstellungsübung.

Wählen Sie eine Wiederherstellungsstrategie

Eine Strategie muss den erforderlichen Dienst, seine Daten und Abhängigkeiten abdecken. Vergleichen Sie diese Muster anhand gemessener Ziele:

Für diese Muster gibt es keine universellen Wiederherstellungszeiten. Implementierung, Datenmenge, Abhängigkeiten und Testbedingungen bestimmen das Ergebnis. Beziehen Sie Betriebskosten und Teamfähigkeiten in die Entscheidung ein.

Schützen Sie vor mehr als einem Ausfall

Ein Replikat kann eine unerwünschte Löschung oder einen beschädigten Datensatz kopieren. Bewahren Sie bei Bedarf wiederherstellbare Versionen auf oder nutzen Sie Point-in-Time Recovery. Prüfen Sie Aufbewahrung, Wiederherstellungsberechtigungen und Zugriff auf Verschlüsselungsschlüssel. Passen Sie die Backup-Isolation an das Szenario an, einschließlich eines Zugriffsverlusts auf das primäre Konto.

Prüfen Sie für die Wiederherstellung nach einem Regionsausfall den erlaubten Datenstandort und die vollständige Abhängigkeitskette. Beziehen Sie Identität, DNS, Zertifikate, Secrets, Deployment-Artefakte, Quoten und Netzwerkzugriff ein. Eine Wiederherstellungsumgebung ohne einen erforderlichen Schlüssel kann unbrauchbar sein.

Definieren Sie, wer das Ereignis ausrufen darf, wer die Wiederherstellung ausführt und wer den wiederhergestellten Dienst abnimmt. Planen Sie die Rückkehr oder den Weiterbetrieb in der Wiederherstellungsumgebung. Verhindern Sie widersprüchliche Schreibvorgänge und gleichen Sie Daten vor einem erneuten Wechsel ab.

Machen Sie aus dem Plan Nachweise

Schreiben Sie ein Runbook und testen Sie es unter kontrollierten Bedingungen. Erfassen Sie Szenario, Datensatzgröße, Start- und Endzeiten, wiederhergestellten Datenstand, fehlgeschlagene Schritte und Verantwortliche. Prüfen Sie einen echten Geschäftsvorgang mit sicheren Testdatensätzen.

Wiederholen Sie die Übung nach relevanten Änderungen und gemäß vereinbartem Zeitplan. Eine Schemaänderung, eine neue externe Abhängigkeit oder eine andere Datenmenge kann frühere Ergebnisse ungültig machen. Verknüpfen Sie die Übungsnachweise mit der Veröffentlichung und den Betriebsverantwortlichkeiten.