🥇DRP vorbereiten – denken Sie daran, den Meteoriten zu berücksichtigen

Selbst in Krisenzeiten 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 während der Fortpflanzungszeit die Biber das Haupt-Glasfaserkabel durchknabbern oder der Junior-Admin die produktive Datenbank löscht, möchten Sie sicherstellen, dass Sie einen vorher ausgearbeiteten Plan haben, um mit diesem Chaos umzugehen.

Während die Kunden panisch die Support-Hotline überfluten und der Junior nach Zyaniden sucht, öffnen Sie weise den roten Umschlag und beginnen, alles in Ordnung zu bringen.

In diesem Beitrag möchte ich Empfehlungen teilen, wie man einen DRP schreibt und was er beinhalten sollte. Außerdem werden wir die folgenden Punkte beleuchten:

Lernen wir, wie ein Bösewicht zu denken.
Untersuchen wir den Nutzen einer Tasse Tee während der Apokalypse.
Entwickeln wir eine praktische Struktur für den DRP.
Schauen wir uns an, wie man ihn testen sollte.

Für welche Unternehmen dies nützlich sein kann.

Es ist sehr schwierig, eine Grenze zu ziehen, wenn die IT-Abteilung solche Dinge benötigt. Ich würde sagen, dass Sie unbedingt einen DRP benötigen, wenn:

Die Abschaltung eines Servers, einer Anwendung oder der Verlust einer Datenbank kann zu erheblichen Geschäftseinbußen führen.
Sie verfügen über eine vollwertige IT-Abteilung. Damit ist eine Abteilung gemeint, die als eigenständige Einheit im Unternehmen fungiert, mit eigenem Budget, und nicht einfach nur ein paar müde Angestellte, die Netzwerke verwalten, Viren entfernen und Drucker nachfüllen.
Sie haben ein realistisches Budget, zumindest für eine teilweise Sicherung im Falle einer Notlage.

Wenn die IT-Abteilung monatelang um ein paar HDDs für einen alten Server für Backups bittet, wird es kaum möglich sein, einen vollständigen Umzug der ausgefallenen Dienste auf die Backup-Kapazitäten zu organisieren. Auch hier kann Dokumentation nicht schaden.

Dokumentation ist wichtig

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

Nachdem Sie eine gute Beschreibung der Servicekomponenten erstellt haben, holen Sie sich die Statistiken zu den Ausfällen. Diese werden mit hoher Wahrscheinlichkeit ganz typisch sein. Zum Beispiel kann es vorkommen, dass die Festplatte gelegentlich überläuft, was zu einem Ausfall des Nodes führt, bis er manuell bereinigt wird. Oder der Kundenservice ist nicht erreichbar, weil jemand erneut vergessen hat, das Zertifikat zu verlängern, und sich nicht in der Lage sah, Let's Encrypt zu konfigurieren.

Denke wie ein Diversant

Der schwierigste Teil besteht darin, die technischen Störungen vorherzusagen, die bisher noch nicht aufgetreten sind, aber potenziell Ihren Service vollständig lahmlegen könnten. Hier spielen wir normalerweise mit meinen Kollegen die Bösewichte. Man nimmt viel Kaffee und etwas Leckeres mit und schließt sich in einem Besprechungsraum ein. Stellen Sie nur sicher, dass Sie in diesem Raum auch die Ingenieure eingeschlossen haben, die den Zielservice selbst eingerichtet 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 Service passieren können. Es ist nicht notwendig, bis ins kleinste Detail zu gehen, wie etwa mit einer bestimmten Reinigungskraft und dem Herausziehen von Kabeln; es reicht aus, das Szenario „Integritätsverletzung des lokalen Netzwerks“ zu betrachten.

In der Regel fallen die meisten typischen Notfall-Situationen in folgende Kategorien:

Netzwerkausfall
Betriebssystemdienstausfall
Anwendungsfehler
Hardware-Ausfall
Virtualisierungsfehler

Gehen Sie einfach jeden Typ durch und sehen Sie, was für Ihren Service zutrifft. Zum Beispiel kann der Nginx-Daemon abstürzen und nicht wieder hochfahren – das deutet auf ein Problem mit dem Betriebssystem hin. Eine seltene Situation, die Ihre Webanwendung in einen inaktiven Zustand versetzt, ist ein Softwarefehler. Während dieser Phase ist es wichtig, die Problemdiagnose sorgfältig durchzuführen. Wie erkennt man zum Beispiel eine eingefrorene Schnittstelle in der Virtualisierung im Vergleich zu einem abgestürzten Switch oder einem Netzwerkfehler? Das ist entscheidend, um schnell die Verantwortlichen zu finden und sie zur Rede zu stellen, bevor das Problem behoben ist.

Nachdem wir die typischen Probleme notiert haben, gießen wir uns noch eine Tasse Kaffee ein und beginnen, die seltsamsten Szenarien zu betrachten, in denen bestimmte Parameter stark außerhalb der Norm liegen. Zum Beispiel:

Was passiert, wenn die Zeit auf einem aktiven Knoten eine Minute hinter den anderen im Cluster zurückgeht?
Und wenn die Zeit nach vorne springt, was ist, wenn sie um 10 Jahre verschoben wird?
Was geschieht, wenn ein Knoten im Cluster während der Synchronisation plötzlich die Netzwerkverbindung verliert?
Und was passiert, wenn zwei Knoten aufgrund vorübergehender Netzwerkisolierung um die Führung konkurrieren?

In dieser Phase ist es oft hilfreich, von hinten zu denken. Nehmen Sie das kreativste Mitglied Ihres Teams mit einer kranken Fantasie und geben Sie ihm die Aufgabe, innerhalb kürzester Zeit einen Sabotageakt zu planen, der den Dienst lahmlegt. Wenn er dabei schwer zu diagnostizierende Probleme verursacht, umso besser. Sie werden nicht glauben, welche seltsamen und genialen Ideen Ingenieure äußern, wenn sie den Auftrag bekommen, etwas zu zerstören. Wenn man ihnen auch noch einen Teststand verspricht, umso besser.

Was ist dieses DRP?!

Also, Sie haben das Bedrohungsmodell definiert. Sie haben auch die lokalen Bewohner bedacht, die Glasfaserkabel auf der Suche nach Kupfer durchtrennen, und das militärische Radar, das die Funkverbindung jeden Freitag um 16:46 unterbricht. Jetzt müssen Sie herausfinden, was Sie mit all dem machen sollen.

Ihre Aufgabe ist es, die roten Umschläge zu erstellen, die in Notfällen geöffnet werden müssen. Seien Sie sich sofort bewusst, dass, wenn alles schiefgeht (nicht wenn!), nur der unerfahrenste Praktikant in der Nähe sein wird, dessen Hände vor Angst zittern. Schauen Sie sich an, wie Notfalltafeln in Arztpraxen umgesetzt sind. Zum Beispiel, was bei einem anaphylaktischen Schock zu tun ist. Das medizinische Personal kennt alle Protokolle auswendig, doch wenn jemand in der Nähe zu sterben beginnt, greifen sie oft hilflos nach allem Möglichen. Deshalb hängt an der Wand eine klare Anleitung mit Punkten wie "Öffnen Sie die Verpackung von ..." und "Verabreichen Sie intravenös so viele Einheiten des Medikaments."

In einer Notfallsituation ist es schwierig, zu denken! Es sollten einfache Anweisungen für das schnelle Handeln vorhanden sein.

Ein gutes DRP besteht aus mehreren einfachen Blöcken:

Wen alle über den Beginn der Notlage informieren. Dies ist wichtig, um den Prozess der Behebung so weit wie möglich zu parallelisieren.
Wie man richtig diagnostiziert – wir führen ein Tracing durch, schauen uns den systemctl-Status des Dienstnamens an und so weiter.
Wie viel Zeit kann für jeden Schritt aufgewendet werden? Wenn Sie es nicht schaffen, manuell innerhalb der SLA-Zeit zu reparieren, wird die virtuelle Maschine gelöscht und aus dem gestrigen Backup wiederhergestellt.
Wie stellen Sie sicher, dass die Panne beendet ist?

Denken Sie daran, dass der DRP beginnt, wenn der Dienst vollständig ausgefallen ist, und endet mit der Wiederherstellung der Funktionalität, selbst wenn diese eingeschränkt ist. Der bloße Verlust von Redundanz sollte den DRP nicht aktivieren. Sie können sogar eine Tasse Tee im DRP vermerken. Im Ernst: Statistisch gesehen werden viele Pannen aus unangenehm katastrophal, weil das Personal in Panik versucht, irgendetwas zu reparieren und dabei den einzigen aktiven Knoten mit Daten oder das gesamte Cluster endgültig gefährdet. 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 nicht DRP und Systempass! Überladen Sie ihn nicht mit unnötigen Informationen. Geben Sie einfach den Zugang zu den wichtigen Abschnitten der Dokumentation über Hyperlinks, damit diese schnell und bequem gelesen werden können. Im DRP selbst sollten klare Anweisungen stehen, wo und wie man sich mit spezifischen Kommandos zum Kopieren und Einfügen verbindet.

Wie man richtig testet

Stellen Sie sicher, dass jeder verantwortliche Mitarbeiter alle Punkte ausführen kann. Im entscheidenden Moment kann es sich herausstellen, dass der Ingenieur keine Zugriffsrechte auf das benötigte System hat, Passwörter für die erforderlichen Konten fehlen oder er keine Ahnung hat, was bedeutet: „Verbinden Sie sich über einen Proxy im Hauptbüro mit der Verwaltungs-Konsole des Services.“ Jeder Punkt sollte so einfach wie möglich sein.

Falsch — „Gehen Sie zur Virtualisierung und starten Sie die tote Node neu.“
Richtig — „Verbinden Sie sich über die Web-Oberfläche mit virt.example.com, und starten Sie im Abschnitt Nodes die fehlerhafte Node neu.“

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

Testen Sie unbedingt Ihr DRP. Es handelt sich nicht nur um einen Plan, den man abhakt – es ist entscheidend für Sie und Ihre Kunden, um schnell aus kritischen Situationen herauszukommen. Es ist ratsam, dies mehrere Male durchzuführen:

Ein Experte und mehrere Praktikanten arbeiten an einer Testumgebung, die den echten Service so gut wie möglich imitiert. Der Experte bringt den Service auf verschiedene Weise zum Ausfall und gibt den Praktikanten die Möglichkeit, ihn gemäß DRP wiederherzustellen. Alle Probleme, Unklarheiten in der Dokumentation und Fehler werden dokumentiert. Nach der Schulung der Praktikanten wird das DRP ergänzt und an unklaren Stellen vereinfacht.
Tests im realen Service. Es ist in der Tat niemals möglich, eine perfekte Kopie eines echten Dienstes zu erstellen. Daher ist es notwendig, ein paar Mal im Jahr planmäßig einen Teil der Server abzuschalten, Verbindungen zu kappen und andere Notfälle aus der Gefahrenliste zu simulieren, um die Wiederherstellungsordnung zu bewerten. Eine geplante Störung von 10 Minuten mitten in der Nacht ist besser als ein plötzlicher Ausfall von mehreren Stunden während der Hauptlastzeit mit Datenverlust.
Reale Notfallbewältigung. Ja, das ist auch ein Teil der Tests. Wenn ein Notfall eintritt, der nicht in der Bedrohungsliste steht, muss der DRP basierend auf den Ergebnissen der Untersuchung ergänzt und überarbeitet werden.

Wesentliche Punkte

Wenn etwas schiefgehen kann, dann wird es nicht nur schiefgehen, sondern auf die katastrophalste Weise.
Stellen Sie sicher, dass Sie Ressourcen für die Notfalllastenauslagerung haben.
Vergewissern Sie sich, dass Sie Backups haben, die automatisch erstellt und regelmäßig auf Konsistenz geprüft werden.
Denken Sie über typische Bedrohungsszenarien nach.
Lassen Sie den Ingenieuren die Möglichkeit, untypische Wege zu finden, um den Dienst lahmzulegen.
Der DRP sollte eine einfache und klare Anleitung sein. Alle komplexe Diagnose erfolgt erst, nachdem der Dienst für die Kunden wiederhergestellt wurde. Selbst wenn es auf den Backup-Ressourcen ist.
Geben Sie wichtige Telefonnummern und Kontakte im DRP an.
Testen Sie regelmäßig das Verständnis der Mitarbeiter für den DRP.
Führen Sie geplante Notfälle im Produktivsystem durch. Stände können nicht alles ersetzen.