🥇Bereiten Sie den DRP vor – vergessen Sie nicht, den Meteoriten zu berücksichtigen

Selbst während einer Katastrophe gibt es immer Zeit für eine Tasse Tee.

DRP (disaster recovery plan) ist etwas, das idealerweise nie benötigt wird. Aber wenn plötzlich wandernde Biber während der Paarungszeit das Haupt-Glasfaserkabel annagen oder ein Junior-Administrator die produktive Datenbank löscht, möchten Sie sich sicher sein, dass Sie einen im Voraus erstellten Plan haben, was mit all dem Chaos zu tun ist.

Während die Kunden in Panik anfangen, die Support-Hotline zu überlasten, sucht der Junior nach Cyaniden, während Sie weise den roten Umschlag öffnen und alles in Ordnung bringen.

In diesem Beitrag möchte ich Empfehlungen teilen, wie man ein DRP schreibt und was es enthalten sollte. Außerdem betrachten wir die folgenden Punkte:

Lernen wir, wie ein Bösewicht zu denken.
Wir analysieren den Nutzen einer Tasse Tee während der Apokalypse.
Wir arbeiten an einer praktischen Struktur für das DRP.
Wir schauen uns an, wie man es testen sollte.

Für welche Unternehmen es nützlich sein könnte.

Es ist sehr schwierig, eine Grenze zu ziehen, wenn die IT-Abteilung anfängt, solche Dinge zu benötigen. Ich würde sagen, dass Sie ein DRP auf jeden Fall brauchen, wenn:

Ein Ausfall eines Servers, einer Anwendung oder der Verlust einer Datenbank zu erheblichen Geschäftseinbußen insgesamt führt.
Sie haben eine vollwertige IT-Abteilung. Ich meine eine Abteilung in Form einer vollständigen Einheit innerhalb des Unternehmens, mit einem eigenen Budget und nicht nur ein paar müden Mitarbeitern, die Netzwerke aufbauen, Viren entfernen und Drucker auffüllen.
Sie haben ein realistisches Budget, das zumindest eine teilweise Sicherung im Notfall ermöglicht.

Wenn die IT-Abteilung monatelang um zumindest ein paar HDDs für einen alten Server für Backups bittet, wird es unwahrscheinlich sein, dass Sie einen vollständigen Umzug eines ausgefallenen Dienstes auf Backup-Ressourcen organisieren können. Auch hier ist die Dokumentation nicht überflüssig.

Dokumentation ist wichtig.

Beginnen Sie mit der Dokumentation. Angenommen, Ihr Dienst basiert auf einem Perl-Skript, das vor drei Generationen von Administratoren geschrieben wurde, und niemand weiß, wie es funktioniert. Die angesammelte technische Schuld und das Fehlen von Dokumentation werden Ihnen unweigerlich nicht nur das Knie, sondern auch andere Gliedmaßen brechen, es ist eher eine Frage der Zeit.

Nachdem Sie eine gute Beschreibung der Komponenten des Dienstes haben, sollten Sie die Statistiken zu Ausfällen überprüfen. Fast sicher werden sie stereotyp sein. Zum Beispiel kann die Festplatte von Zeit zu Zeit überlaufen, was zu einem Ausfall des Knotens führt, bis dieser manuell gereinigt wird. Oder der Client-Service ist nicht verfügbar, weil jemand wieder vergessen hat, das Zertifikat zu verlängern und Let’s Encrypt nicht eingerichtet hat oder nicht einrichten wollte.

Denken Sie wie ein Saboteur

Der schwierigste Teil besteht darin, die Ausfälle vorherzusagen, die bisher noch nie aufgetreten sind, aber das Potenzial haben, Ihren Dienst vollständig lahmzulegen. Hier spielen wir normalerweise mit Kollegen die Bösewichte. Sie nehmen viel Kaffee und etwas Leckeres mit und schließen sich in einem Besprechungsraum ein. Stellen Sie nur sicher, dass Sie auch die Ingenieure im selben Besprechungsraum eingeschlossen haben, die den Ziel-Service selbst in Betrieb genommen haben oder regelmäßig damit arbeiten. Dann beginnen Sie, entweder auf einem Whiteboard oder auf Papier alle möglichen Horrorszenarien zu skizzieren, die mit Ihrem Dienst passieren könnten. Es ist nicht notwendig, bis ins Detail zu gehen – zum Beispiel bis zur konkreten Putzfrau und dem Herausziehen von Kabeln – es reicht aus, das Szenario „Verstoß gegen die Integrität des lokalen Netzwerks“ zu betrachten.

In der Regel fallen die meisten typischen Notfallsituationen in folgende Kategorien:

Netzausfall
Ausfall von Betriebssystemdiensten
Ausfall der Anwendung
Hardwareausfall
Virtualisierungsfehler

Gehen Sie einfach jeden Typ durch und prüfen Sie, was auf Ihren Dienst zutrifft. Zum Beispiel kann der Nginx-Dienst abstürzen und nicht wieder hochkommen, was ein Problem auf der Betriebssystemseite darstellt. Eine seltene Situation, die Ihre Webanwendung in einen nicht funktionsfähigen Zustand versetzt, ist ein Softwareausfall. Während des ablaufenden Prozesses ist es wichtig, das Problem zu diagnostizieren. Wie unterscheidet man ein festgefahrenes Interface in der Virtualisierung von einem ausgefallenen Router und einem Netzwerknotfall? Das ist wichtig, um schnell Verantwortliche zu finden und sie an die Kandare zu nehmen, während der Notfall noch nicht behoben ist.

Nachdem die typischen Probleme dokumentiert sind, gießen wir noch Kaffee ein und beginnen, die seltsamsten Szenarien zu betrachten, in denen einige Parameter stark von der Norm abweichen. Zum Beispiel:

Was passiert, wenn die Zeit auf dem aktiven Knoten um eine Minute im Vergleich zu den anderen im Cluster zurückgesetzt wird?
Und wenn die Zeit nach vorne verschoben wird, was ist, wenn sie um 10 Jahre vorgeht?
Was passiert, wenn der Clusterknoten während der Synchronisation plötzlich die Verbindung zum Netzwerk verliert?
Was passiert, wenn zwei Knoten aufgrund zeitweiser Netzwerkisolation um die Führungsstärke kämpfen?

In diesem Stadium hilft es sehr, von hinten heranzugehen. Nehmen Sie das verrückteste Mitglied Ihres Teams mit der kranken Fantasie und geben Sie ihm die Aufgabe, in kürzester Zeit einen Sabotageakt zu organisieren, der den Dienst lahmlegt. Wenn es schwer zu diagnostizieren ist, umso besser. Sie werden nicht glauben, welche seltsamen und coolen Ideen Ingenieure haben, wenn man ihnen den Auftrag gibt, etwas kaputt zu machen. Und wenn man ihnen verspricht, dafür eine Testumgebung zur Verfügung zu stellen, umso besser.

Was ist dieses DRP?!

Sie haben also das Bedrohungsmodell festgelegt. Sie haben auch die Einheimischen berücksichtigt, die Glasfaserkabel auf der Suche nach Kupfer durchtrennen, sowie den Militärradar, der die Richtfunkverbindung freitags um 16:46 Uhr kappt. Nun müssen Sie herausfinden, was mit all dem zu tun ist.

Ihre Aufgabe besteht darin, die roten Umschläge zu schreiben, die in einer Notfallsituation geöffnet werden sollen. Rechnen Sie gleich damit, dass, wenn (nicht ob!) alles schiefgeht, nur der unerfahrenste Praktikant in der Nähe sein wird, dessen Hände vor Angst zittern. Schauen Sie sich an, wie Notfallhinweisschilder in medizinischen Einrichtungen umgesetzt sind. Zum Beispiel, was in einem Fall von anaphylaktischem Schock zu tun ist. Das medizinische Personal kennt alle Protokolle auswendig, aber wenn ein Mensch in der Nähe zu sterben beginnt, greifen sie oft hilflos nach allem Möglichen. Dafür hängt an der Wand eine klare Anleitung mit Punkten wie "Die Verpackung von dem öffnen" und "soviel Einheiten des Medikaments intravenös verabreichen".

In einer Notfallsituation ist das Denken schwierig! Es müssen einfache Anweisungen zum Parsonieren durch das Rückenmark vorhanden sein.

Ein gutes DRP besteht aus mehreren einfachen Elementen:

Wen über den Beginn des Notfalls informieren. Das ist wichtig, um den Prozess der Behebung maximal parallel zu gestalten.
Wie man richtig diagnostiziert – wir führen eine Nachverfolgung durch, schauen uns den Status des Dienstes mit systemctl status servicename an und so weiter.
Wie viel Zeit für jeden Schritt aufgewendet werden kann. Wenn Sie es nicht innerhalb der SLA mit den Händen reparieren können, wird die virtuelle Maschine abgeschaltet und vom Backup von gestern neu gestartet.
Wie man sicherstellt, dass der Notfall beendet ist.

Denken Sie daran, dass der DRP beginnt, wenn der Dienst vollständig ausgefallen ist, und endet mit der Wiederherstellung der Funktionsfähigkeit, auch wenn diese vermindert ist. Allein der Verlust der Reservierung sollte den DRP nicht aktivieren. Und Sie können auch eine Tasse Tee im DRP vermerken. Im Ernst. Statistisch gesehen werden viele Pannen aus unangenehm zu katastrophal, weil das Personal in Panik ist und versucht, etwas zu reparieren, während es gleichzeitig die einzige lebende Knoten mit Daten tötet oder den Cluster endgültig kaputt macht. In der Regel geben fünf Minuten für eine Tasse Tee Ihnen etwas Zeit, um sich zu beruhigen und die Situation zu analysieren.

Verwechseln Sie den DRP nicht mit dem Systempass! Überladen Sie ihn nicht mit unnötigen Daten. Geben Sie einfach die Möglichkeit, schnell und bequem über Hyperlinks zu den relevanten Abschnitten der Dokumentation zu gelangen und im erweiterten Format über die relevanten Teile der Architektur des Dienstes zu lesen. Im DRP sollten nur direkte Anweisungen enthalten sein, wo und wie man sich mit konkreten Befehlen zum Kopieren und Einfügen verbindet.

Wie man richtig testet

Stellen Sie sicher, dass jeder verantwortliche Mitarbeiter in der Lage ist, alle Punkte zu erfüllen. Im entscheidenden Moment kann es sein, dass der Ingenieur keine Zugriffsrechte auf das benötigte System hat, die Passwörter für das erforderliche Konto fehlen oder er überhaupt keinen blassen Schimmer hat, was 'Verbinden Sie sich über den Proxy mit der Verwaltungs-Konsole des Dienstes im Hauptbüro' bedeutet. Jeder Punkt sollte so einfach wie möglich sein.

Falsch — 'Gehen Sie zur Virtualisierung und starten Sie den toten Knoten neu'
Richtig — 'Verbinden Sie sich über die Web-Oberfläche mit virt.example.com, und führen Sie im Knotenabschnitt einen Neustart des Knotens durch, der den Fehler verursacht.'

Vermeiden Sie Mehrdeutigkeiten. Denken Sie an den verängstigten Praktikanten.

Testen Sie den DRP unbedingt. Es ist nicht nur ein Plan für die Ablage — es ist das, was Ihnen und Ihren Kunden hilft, schnell aus kritischen Situationen herauszukommen. Optimal ist es, dies mehrere Male zu tun:

Ein Experte und mehrere Praktikanten arbeiten an einem Teststand, der den realen Dienst so gut wie möglich nachahmt. Der Experte schädigt den Dienst auf verschiedene Weisen und gibt den Praktikanten die Möglichkeit, ihn gemäß dem DRP wiederherzustellen. Alle Probleme, Unklarheiten in der Dokumentation und Fehler werden dokumentiert. Nach der Schulung der Praktikanten wird der DRP an unklaren Stellen ergänzt und vereinfacht.
Testen auf einem echten Dienst. Tatsächlich kann niemals eine perfekte Kopie eines echten Dienstes erstellt werden. Daher ist es notwendig, ein paar Mal im Jahr planmäßig Teile der Server abzuschalten, Verbindungen zu trennen und andere Pannen aus der Liste der Bedrohungen zu verursachen, um die Wiederherstellungsordnung zu bewerten. Eine planmäßige Panne von 10 Minuten mitten in der Nacht ist besser als ein plötzlicher Ausfall über mehrere Stunden bei hoher Last mit Datenverlust.
Echtes Beheben von Pannen. Ja, das ist auch Teil des Testens. Wenn ein Ausfall auftritt, der nicht auf der Liste der Bedrohungen steht, muss der DRP im Anschluss an die Untersuchung ergänzt und überarbeitet werden.

Schlüsselthemen

Wenn etwas Schlimmes passieren kann, wird es nicht nur passieren, sondern nach dem schlimmstmöglichen Szenario.
Stellen Sie sicher, dass Sie Ressourcen für das Notfall-Load-Balancing haben.
Stellen Sie sicher, dass Sie Backups haben, die automatisch erstellt und regelmäßig auf Konsistenz überprüft werden.
Denken Sie an typische Bedrohungsszenarien.
Geben Sie den Ingenieuren die Möglichkeit, untypische Varianten zu entwickeln, die den Dienst ausfallen lassen.
Der DRP sollte ein einfaches, klares Dokument sein. Alle komplexen Diagnosen erfolgen erst, nachdem der Dienst für die Kunden wiederhergestellt wurde, selbst wenn es auf Backup-Kapazitäten geschieht.
Geben Sie Schlüsseltelefonnummern und Kontakte im DRP an.
Testen Sie regelmäßig die Mitarbeiter auf ihr Verständnis des DRP.
Führen Sie planmäßige Pannen im Produktivbetrieb durch. Stände können nicht alles ersetzen.