Selbst während einer Katastrophe bleibt immer Zeit für eine Tasse
DRP- Tee (Disaster Recovery Plan) - eine Sache, die im Idealfall nie benötigt wird. Aber wenn plötzlich die Biber, die während der Paarungszeit wandern, durch die Rückgratfaser nagen oder der Junior-Administrator die produktive Basis fallen lässt, möchten Sie auf jeden Fall sicher sein, dass Sie einen vorgefertigten Plan haben, was Sie mit all diesem Durcheinander anfangen sollen.
Während Kunden in Panik anfangen, ihre Telefone für den technischen Support abzuschalten, sucht der Junior nach Cyanid. Öffnen Sie mit Bedacht den roten Umschlag und ordnen Sie alles.
In diesem Beitrag möchte ich Empfehlungen dazu geben, wie ein DRP geschrieben wird und was es enthalten sollte. Wir werden uns auch die folgenden Dinge ansehen:
- Lass uns lernen, wie ein Bösewicht zu denken.
- Schauen wir uns die Vorteile einer Tasse Tee während der Apokalypse an.
- Wir werden über eine bequeme DRP-Struktur nachdenken
- Mal sehen, wie man es testet.
Für welche Unternehmen kann es nützlich sein
Es ist sehr schwierig, die Grenze zu ziehen, wenn die IT-Abteilung diese Dinge benötigt. Ich würde sagen, dass Sie garantiert DRP benötigen, wenn:
- Das Stoppen eines Servers, einer Anwendung oder der Verlust einer Basis führt zu einem erheblichen Geschäftsverlust insgesamt.
- Sie haben eine vollwertige IT-Abteilung. Im Sinne einer Abteilung in Form einer vollwertigen Einheit des Unternehmens mit eigenem Budget und nicht nur wenigen müden Mitarbeitern, die ein Netzwerk aufbauen, Viren reinigen und Drucker tanken.
- Sie haben ein realistisches Budget für zumindest teilweise Redundanz im Notfall.
Wenn die IT-Abteilung monatelang um mindestens ein paar Festplatten für einen alten Server für Backups bittet, ist es unwahrscheinlich, dass Sie eine vollständige Übertragung eines ausgefallenen Dienstes zur Kapazitätsreserve organisieren können. Obwohl die Dokumentation hier nicht überflüssig sein wird.
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 Verschuldung und der Mangel an Dokumentation werden Sie unweigerlich nicht nur ins Knie, sondern auch in andere Gliedmaßen schießen, es ist eher eine Frage der Zeit.
Wenn Sie eine gute Beschreibung der Servicekomponenten haben, öffnen Sie die Absturzstatistik. Sie werden mit ziemlicher Sicherheit ganz typisch sein. Beispielsweise ist die Festplatte von Zeit zu Zeit voll, was zu einem Knotenausfall führt, bevor sie manuell bereinigt wird. Oder der Client-Service ist nicht mehr verfügbar, da jemand erneut vergessen hat, das Zertifikat zu erneuern, und Let's Encrypt es nicht konfigurieren konnte oder wollte.
Gedanken wie ein Saboteur
Am schwierigsten ist es, Unfälle vorherzusagen, die noch nie zuvor passiert sind, die Ihren Dienst jedoch möglicherweise vollständig beeinträchtigen könnten. Hier spielen wir normalerweise Bösewichte mit unseren Kollegen. Nehmen Sie viel Kaffee und etwas Leckeres und schließen Sie sich in einem Besprechungsraum ein. Stellen Sie einfach sicher, dass Sie im selben Besprechungsraum die Ingenieure gesperrt haben, die selbst den Zieldienst erhöht haben oder regelmäßig damit arbeiten. Dann beginnen Sie entweder an der Tafel oder auf Papier, alle möglichen Schrecken zu zeichnen, die Ihrem Dienst widerfahren können. Es ist nicht erforderlich, auf einen bestimmten Reiniger einzugehen und Kabel herauszuziehen. Es reicht aus, das Szenario "Verletzung der Integrität des lokalen Netzwerks" zu betrachten.
Normalerweise passen die meisten typischen Notfallsituationen in die folgenden Typen:
- Netzwerkfehler
- Ausfall der Betriebssystemdienste
- Anwendungsfehler
- Eisenversagen
- Virtualisierungsfehler
Gehen Sie einfach jede Ansicht durch und sehen Sie, was für Ihren Service gilt. Beispielsweise kann der Nginx-Dämon abstürzen und nicht ansteigen - dies ist ein Fehler des Betriebssystems. Eine seltene Situation, die Ihre Webanwendung in einen nicht funktionierenden Zustand versetzt, ist ein Softwarefehler. Während dieser Phase ist es wichtig, die Diagnose des Problems zu erarbeiten. So unterscheiden Sie beispielsweise eine blockierte Schnittstelle bei der Virtualisierung von einem heruntergefallenen Tsiska und einem Netzwerkabsturz. Es ist wichtig, die Verantwortlichen schnell zu finden und an ihrem Schwanz zu ziehen, bis der Unfall behoben ist.
Nachdem die typischen Probleme aufgeschrieben wurden, gießen wir mehr Kaffee ein und betrachten die seltsamsten Szenarien, wenn einige Parameter über die Norm hinausgehen. Zum Beispiel:
- Was passiert, wenn sich die Zeit auf dem aktiven Knoten im Vergleich zu den anderen im Cluster um eine Minute zurückzieht?
- Und wenn die Zeit voranschreitet und wenn um 10 Jahre?
- Was passiert, wenn ein Clusterknoten während der Synchronisation plötzlich sein Netzwerk verliert?
- Was passiert, wenn sich zwei Knoten aufgrund der vorübergehenden Isolation über das Netzwerk nicht die Führung teilen?
Der umgekehrte Ansatz hilft in dieser Phase sehr. Sie nehmen das hartnäckigste Teammitglied mit einer kranken Fantasie und geben ihm die Aufgabe, so schnell wie möglich eine Sabotage zu arrangieren, die den Dienst beeinträchtigt. Wenn es schwierig ist, es zu diagnostizieren, noch besser. Sie werden nicht glauben, welche seltsamen und coolen Ideen Ingenieure haben, wenn Sie ihnen eine Idee geben, etwas zu brechen. Und schon, wenn Sie ihnen einen Prüfstand dafür versprechen, ist es sehr gut.
Was ist dein DRP ?!
Sie haben also das Bedrohungsmodell definiert. Berücksichtigt wurden auch die Einheimischen, die auf der Suche nach Kupfer Glasfaserkabel durchtrennten, und das Militärradar, das freitags um 16:46 Uhr die Funkleitung strikt absetzt. Jetzt müssen wir verstehen, was wir mit all dem anfangen sollen.
Ihre Aufgabe ist es, die sehr roten Umschläge zu schreiben, die im Notfall geöffnet werden. Erwarten Sie sofort, dass, wenn (nicht wenn!) Alles in Ordnung ist, nur der unerfahrenste Auszubildende in der Nähe sein wird, dessen Hände vor dem Schrecken des Geschehens heftig zittern werden. Sehen Sie, wie Notfalletiketten in Arztpraxen implementiert werden. Zum Beispiel, was bei einem anaphylaktischen Schock zu tun ist. Das medizinische Personal kennt alle Protokolle auswendig, aber wenn eine Person neben ihnen zu sterben beginnt, greift sehr oft jeder hilflos nach allem. Zu diesem Zweck befindet sich an der Wand eine klare Anweisung mit Elementen wie „Öffnen Sie die Verpackung“ und „Injizieren Sie so viele Einheiten des Arzneimittels intravenös“.
Im Notfall ist es schwer zu denken! Es sollte einfache Anweisungen zum Parsen durch das Rückenmark geben.
Ein gutes DRP besteht aus ein paar einfachen Blöcken:
- . , .
- — , systemctl status servicename .
- . SLA — .
- , .
Denken Sie daran, dass DRP gestartet wird, wenn der Dienst vollständig ausgefallen ist und auch bei reduzierter Effizienz neu erstellt wird. Das einfache Verlieren einer Reservierung sollte DRP nicht aktivieren. Sie können DRP auch eine Tasse Tee hinzufügen. Ernsthaft. Laut Statistik werden viele Unfälle aufgrund von Unannehmlichkeiten katastrophal, da die Mitarbeiter in Panik eilen, um etwas zu reparieren, gleichzeitig den einzigen lebenden Knoten mit Daten töten oder den Cluster endgültig beenden. In der Regel haben Sie nach 5 Minuten für eine Tasse Tee etwas Zeit, um sich zu beruhigen und zu analysieren, was gerade passiert.
Verwechseln Sie DRP und Systempass nicht! Überladen Sie es nicht mit unnötigen Daten. Machen Sie es einfach möglich, schnell und bequem Hyperlinks zu verwenden, um zum erforderlichen Abschnitt der Dokumentation zu gelangen und in einem erweiterten Format die erforderlichen Abschnitte der Servicearchitektur zu lesen. Und in DRP selbst gibt es nur direkte Anweisungen, wo und wie Sie sich mit bestimmten Befehlen zum Kopieren und Einfügen verbinden.
So testen Sie richtig
Stellen Sie sicher, dass jede verantwortliche Person alle Punkte ausfüllen kann. Im entscheidenden Moment kann sich herausstellen, dass der Techniker keine Zugriffsrechte auf das erforderliche System hat, keine Kennwörter für das erforderliche Konto vorhanden sind oder keine Ahnung hat, was dies bedeutet: "Über einen Proxy in der Zentrale eine Verbindung zur Service-Management-Konsole herstellen". Jeder Punkt sollte extrem einfach sein.
Falsch - "Gehen Sie zur Virtualisierung und starten Sie den toten Knoten neu."
Richtig - "Stellen Sie über die Weboberfläche eine Verbindung zu virt.example.com her. Starten Sie im Abschnitt " Knoten " den Knoten neu, der den Fehler verursacht."
Vermeiden Sie Mehrdeutigkeiten. Erinnern Sie sich an den verängstigten Auszubildenden.
Stellen Sie sicher, dass Sie DRP testen. Dies ist nicht nur ein Plan zum Abhaken, sondern ermöglicht es Ihnen und Ihren Kunden, schnell aus einer kritischen Situation herauszukommen. Es ist optimal, dies mehrmals zu tun:
- Ein Experte und mehrere Auszubildende arbeiten an einem Prüfstand, der einen echten Service so gut wie möglich simuliert. Der Experte unterbricht den Dienst auf verschiedene Weise und gibt den Auszubildenden die Möglichkeit, ihn gemäß DRP wiederherzustellen. Alle Probleme, Unklarheiten in der Dokumentation und Fehler werden aufgezeichnet. Nach der Ausbildung der Auszubildenden wird die DRP an dunklen Stellen ergänzt und vereinfacht.
- . . , , , . 10 , .
- . , . , , DRP .
- , , .
- , .
- , , .
- .
- .
- DRP . , . .
- DRP.
- DRP.
- . .
