Selbst im Katastrophenfall bleibt immer Zeit für eine Tasse Tee
DRP (Disaster-Recovery-Plan) ist eine Sache, die im Idealfall nie benötigt wird. Aber wenn plötzlich während der Paarungszeit wandernde Biber das Rückgrat der Glasfaser durchnagen oder ein Nachwuchsadministrator die produktive Basis verlässt, möchten Sie auf jeden Fall sicher sein, dass Sie einen vorgefertigten Plan haben, was mit all dieser Schande geschehen soll.
Während Kunden in Panik beginnen, die Telefone des technischen Supports abzuschneiden, der Junior nach Zyanid sucht, öffnen Sie klugerweise den roten Umschlag und beginnen, alles in Ordnung zu bringen.
In diesem Beitrag möchte ich Empfehlungen dazu geben, wie man ein DRP schreibt und was es enthalten sollte. Wir werden uns auch die folgenden Dinge ansehen:
- Lernen wir, wie ein Bösewicht zu denken.
- Schauen wir uns die Vorteile einer Tasse Tee während der Apokalypse an.
- Lassen Sie uns über eine praktische DRP-Struktur nachdenken
- Mal sehen, wie man es testet
Für welche Unternehmen könnte dies nützlich sein?
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 DRP auf jeden Fall benötigen, wenn:
- Das Anhalten eines Servers oder einer Anwendung oder der Verlust einer Datenbank führt zu erheblichen Verlusten für das gesamte Unternehmen.
- Sie verfügen über eine vollwertige IT-Abteilung. Im Sinne einer Abteilung in Form einer vollwertigen Unternehmenseinheit mit eigenem Budget und nicht nur ein paar müden Mitarbeitern, die ein Netzwerk aufbauen, Viren bereinigen und Drucker auffüllen.
- Sie verfügen über ein realistisches Budget für eine zumindest teilweise Entlassung im Notfall.
Wenn die IT-Abteilung seit Monaten um mindestens ein paar Festplatten auf einem alten Server für Backups bittet, ist es unwahrscheinlich, dass Sie einen vollständigen Umzug eines ausgefallenen Dienstes zur Reservekapazität organisieren können. Obwohl hier die Dokumentation nicht überflüssig sein wird.
Dokumentation ist wichtig
Beginnen Sie mit der Dokumentation. Nehmen wir an, Ihr Dienst läuft auf einem Perl-Skript, das vor drei Generationen von Administratoren geschrieben wurde, aber niemand weiß, wie es funktioniert. Die angehäuften technischen Schulden und die fehlende Dokumentation werden Ihnen unweigerlich nicht nur ins Knie, sondern auch in andere Gliedmaßen schießen, es ist eher eine Frage der Zeit.
Sobald Sie eine gute Beschreibung der Servicekomponenten haben, schauen Sie sich die Unfallstatistiken an. Sie werden mit ziemlicher Sicherheit völlig typisch sein. Beispielsweise ist Ihre Festplatte von Zeit zu Zeit voll, was dazu führt, dass der Knoten ausfällt, bis er manuell bereinigt wird. Oder der Client-Dienst ist nicht verfügbar, weil jemand erneut vergessen hat, das Zertifikat zu erneuern, und Let's Encrypt nicht konfigurieren konnte oder wollte.
Gedanken wie ein Saboteur
Der schwierigste Teil besteht darin, Unfälle vorherzusagen, die noch nie zuvor passiert sind, aber möglicherweise Ihren Dienst völlig zum Erliegen bringen könnten. Hier spielen meine Kollegen und ich normalerweise Bösewichte. Nehmen Sie sich viel Kaffee und etwas Leckeres und schließen Sie sich in einem Besprechungsraum ein. Achten Sie nur darauf, dass Sie in die gleichen Verhandlungen auch diejenigen Ingenieure einbeziehen, die den Zieldienst selbst entwickelt haben oder regelmäßig damit arbeiten. Dann zeichnen Sie entweder an der Tafel oder auf Papier alle möglichen Schrecken auf, die Ihrem Dienst widerfahren könnten. Es ist nicht notwendig, im Detail auf eine bestimmte Putzfrau und das Herausziehen von Kabeln einzugehen; es reicht aus, das Szenario „Verletzung der Integrität des lokalen Netzwerks“ zu betrachten.
Typischerweise fallen die meisten typischen Notfallsituationen in die folgenden Typen:
- Netzwerkfehler
- Ausfall der Betriebssystemdienste
- Anwendungsfehler
- Eisenversagen
- Virtualisierungsfehler
Gehen Sie einfach jeden Typ durch und sehen Sie, was auf Ihren Service zutrifft. Beispielsweise kann es vorkommen, dass der Nginx-Daemon ausfällt und nicht hochfährt – das bedeutet Ausfälle seitens des Betriebssystems. Eine seltene Situation, die zum Scheitern Ihrer Webanwendung führt, ist ein Softwarefehler. Während dieser Phase ist es wichtig, die Diagnose des Problems zu ermitteln. So kann man zum Beispiel eine eingefrorene Schnittstelle bei der Virtualisierung von einem ausgefallenen cis-Laufwerk und einem Netzwerkunfall unterscheiden. Dies ist wichtig, um die Verantwortlichen schnell zu finden und ihnen auf den Fersen zu sein, bis der Unfall aufgeklärt ist.
Nachdem typische Probleme aufgeschrieben sind, gießen wir mehr Kaffee ein und beginnen, über die seltsamsten Szenarien nachzudenken, in denen einige Parameter beginnen, weit über die Norm hinauszugehen. Zum Beispiel:
- Was passiert, wenn die Zeit auf dem aktiven Knoten im Vergleich zu anderen im Cluster um eine Minute zurückgeht?
- Was wäre, wenn sich die Zeit vorwärts bewegte, was wäre, wenn um 10 Jahre?
- Was passiert, wenn ein Clusterknoten während der Synchronisierung plötzlich sein Netzwerk verliert?
- Was passiert, wenn zwei Knoten aufgrund einer vorübergehenden Isolation voneinander im Netzwerk nicht die Führung teilen?
In dieser Phase ist der umgekehrte Ansatz sehr hilfreich. Sie nehmen das sturste Mitglied des Teams mit einer kranken Vorstellungskraft und geben ihm die Aufgabe, in kürzester Zeit eine Sabotage zu organisieren, die den Dienst zum Scheitern bringt. Wenn die Diagnose schwierig ist, umso besser. Sie werden nicht glauben, auf welche seltsamen und coolen Ideen Ingenieure kommen, wenn Sie ihnen eine Idee geben, etwas kaputt zu machen. Und wenn man ihnen dafür einen Prüfstand verspricht, ist das völlig in Ordnung.
Was ist das für ein DRP von dir?!
Sie haben also Ihr Bedrohungsmodell definiert. Sie berücksichtigten auch Anwohner, die auf der Suche nach Kupfer Glasfaserkabel durchtrennten, und ein Militärradar, das ausschließlich freitags um 16:46 Uhr eine Richtfunklinie ablegt. Jetzt müssen wir verstehen, was wir mit all dem anfangen sollen.
Ihre Aufgabe ist es, die sehr roten Umschläge zu beschriften, die im Notfall geöffnet werden. Erwarten Sie sofort, dass, wenn (nicht wenn!) alles zu Ende geht, nur noch der unerfahrenste Praktikant in der Nähe sein wird, dessen Hände vor Schrecken über das, was passiert, heftig zittern werden. Sehen Sie, wie Notfallschilder in Arztpraxen umgesetzt werden. Zum Beispiel, was im Falle eines anaphylaktischen Schocks zu tun ist. Das medizinische Personal kennt alle Protokolle auswendig, aber wenn eine Person in der Nähe zu sterben beginnt, klammern sich sehr oft alle hilflos an alles, was in Sichtweite ist. Dazu gibt es klare Anweisungen an der Wand mit Aufsätzen wie „Öffne die Packung von diesem und jenem“ und „Verabreiche so viele Einheiten des Arzneimittels intravenös“.
Im Notfall ist es schwer zu denken! Es sollten einfache Anweisungen für die Analyse des Rückenmarks vorhanden sein.
Ein gutes DRP besteht aus mehreren einfachen Blöcken:
- Wen ist über den Beginn eines Unfalls zu informieren? Dies ist wichtig, um den Eliminierungsprozess möglichst parallel zu gestalten.
- So führen Sie eine korrekte Diagnose durch: Führen Sie eine Ablaufverfolgung durch, schauen Sie in systemctl status servicename nach und so weiter.
- Wie viel Zeit können Sie für jede Etappe aufwenden? Wenn Sie innerhalb der SLA-Zeit keine Zeit haben, das Problem manuell zu beheben, wird die virtuelle Maschine beendet und von der gestrigen Sicherung zurückgesetzt.
- So stellen Sie sicher, dass der Unfall vorbei ist.
Denken Sie daran, dass DRP beginnt, wenn der Dienst vollständig ausgefallen ist, und endet, wenn der Dienst wiederhergestellt ist, auch wenn die Effizienz verringert ist. Der bloße Verlust einer Reservierung sollte keinen DRP auslösen. Sie können auch eine Tasse Tee in das DRP schreiben. Ernsthaft. Laut Statistik werden viele Unfälle von unangenehmen zu katastrophalen Unfällen, weil das Personal in Panik eilt, um etwas zu reparieren, und dabei gleichzeitig den einzigen lebenden Knoten mit Daten zerstört oder schließlich den Cluster zerstört. In der Regel geben Ihnen 5 Minuten mit einer Tasse Tee etwas Zeit, sich zu beruhigen und zu analysieren, was passiert.
Verwechseln Sie DRP und Systempass nicht! Überladen Sie es nicht mit unnötigen Daten. Machen Sie es einfach möglich, über Hyperlinks schnell und bequem zum gewünschten Abschnitt der Dokumentation zu gelangen und in einem erweiterten Format über die notwendigen Abschnitte der Service-Architektur zu lesen. Und im DRP selbst gibt es nur direkte Anweisungen, wo und wie eine Verbindung mit bestimmten Befehlen zum Kopieren und Einfügen hergestellt werden soll.
So testen Sie richtig
Stellen Sie sicher, dass jeder verantwortliche Mitarbeiter in der Lage ist, alle Aufgaben zu erledigen. Im entscheidenden Moment kann sich herausstellen, dass der Techniker keine Zugriffsrechte auf das erforderliche System hat, keine Passwörter für das erforderliche Konto vorhanden sind oder keine Ahnung hat, was „Stellen Sie über einen Proxy eine Verbindung zur Service-Management-Konsole her.“ Hauptsitz“ bedeutet. Jeder Punkt sollte äußerst einfach sein.
Falsch - „Gehen Sie zur Virtualisierung und starten Sie den toten Knoten neu“
Richtig - „Stellen Sie über die Webschnittstelle eine Verbindung zu virt.example.com her. Starten Sie im Abschnitt „Knoten“ den Knoten neu, der den Fehler verursacht.“
Vermeiden Sie Unklarheiten. Erinnern Sie sich an den verängstigten Praktikanten.
Testen Sie unbedingt DRP. Dabei handelt es sich nicht nur um einen Plan zur Schau, sondern um etwas, das es Ihnen und Ihren Kunden ermöglicht, schnell aus einer kritischen Situation herauszukommen. Am besten machst du das mehrmals:
- Ein Experte und mehrere Auszubildende arbeiten an einem Prüfstand, der eine reale Dienstleistung möglichst genau simuliert. Der Experte unterbricht den Dienst auf verschiedene Weise und ermöglicht den Auszubildenden, ihn gemäß DRP wiederherzustellen. Alle Probleme, Unklarheiten in der Dokumentation und Fehler werden protokolliert. Nach der Schulung der Auszubildenden wird das DRP in unklaren Bereichen erweitert und vereinfacht.
- Testen an einem echten Dienst. Tatsächlich kann man nie eine perfekte Kopie eines echten Dienstes erstellen. Daher ist es zur Beurteilung des Wiederherstellungsverfahrens erforderlich, regelmäßig einige Server abzuschalten, Verbindungen zu trennen und andere Katastrophen aus der Liste der Bedrohungen zu verursachen. Ein geplanter Ausfall von 10 Minuten mitten in der Nacht ist besser als ein plötzlicher Ausfall von mehreren Stunden bei Spitzenlast mit Datenverlust.
- Echte Fehlerbehebung. Ja, das ist auch Teil des Testens. Kommt es zu einem Unfall, der nicht auf der Gefahrenliste stand, ist es notwendig, das DRP auf der Grundlage der Untersuchungsergebnisse zu ergänzen und zu finalisieren.
Wichtige Punkte
- Wenn Scheiße passieren kann, wird sie nicht nur passieren, sondern im größtmöglichen Katastrophenszenario.
- Stellen Sie sicher, dass Sie über Ressourcen für den Notlasttransfer verfügen.
- Stellen Sie sicher, dass Sie über Backups verfügen. Diese werden automatisch erstellt und regelmäßig auf Konsistenz überprüft.
- Denken Sie über typische Bedrohungsszenarien nach.
- Geben Sie Ingenieuren die Möglichkeit, nicht standardmäßige Optionen für die Bereitstellung des Dienstes zu entwickeln.
- DRP sollte eine einfache und klare Anweisung sein. Alle komplexen Diagnosen werden erst durchgeführt, nachdem der Dienst des Kunden wiederhergestellt wurde. Auch wenn die Reservekapazität vorhanden ist.
- Geben Sie im DRP wichtige Telefonnummern und Kontakte an.
- Testen Sie regelmäßig das Verständnis der Mitarbeiter für die DRP.
- Planen Sie geplante Unfälle an Produktionsstandorten. Stände können nicht alles ersetzen.
Source: habr.com