VPN-Health-Checks von Anwendungs-Health-Checks trennen

Ihr Tunnelprozess kann laufen, während die geschützte Verbindung unbrauchbar ist, und eine fehlschlagende Webseite ist kein Beweis dafür, dass der Tunnel kaputt ist. Wenn eine einzige Prüfung für alle anderen einsteht, startet eine Neustartrichtlinie die falsche Komponente neu und nennt das Automatisierung. Jede Prüfung unten benennt die Ebene, die sie beobachtet, die Aktion, die ihr Fehlschlag auslöst, und den Nachweis, dass die Aktion gewirkt hat. Der letzte Schritt macht aus dem ganzen Satz eine Seite, der jemand um drei Uhr morgens folgen kann.

Schritt 1: Benennen Sie die Ebene, die jede Prüfung beobachtet

Fragen Sie, was jede Prüfung tatsächlich sehen kann, bevor Sie eine davon schreiben. Liveness beweist, dass der Daemon läuft, ein Handshake oder eine Peer-Liste beweist, dass die Beziehung besteht, eine geroutete Anfrage beweist die Zustellung und eine Namensauflösung beweist die Auflösung. Sie scheitern in genau dieser Reihenfolge, und keine von ihnen setzt die nächste voraus. Eine grüne Prozessprüfung neben einem toten Tunnel ist der Normalfall, kein Widerspruch.

Schreiben Sie die vier Prüfungen in dieser Reihenfolge auf, mit dem genauen Befehl und der erwarteten Ausgabe für jede. Eine Prüfung, deren erwartete Ausgabe Sie nicht angeben können, wird von jedem Operator, der den Alarm sieht, anders gelesen. Setzen Sie dieselbe Liste in den Alarmtext, nicht nur ins Runbook, damit die nachts geweckte Person die Ebene vor dem Symptom trifft. Halten Sie jeden Befehl auf dem Host, der ihn ausführt, kopierfertig.

Fügen Sie dann die Anwendungsprüfung als fünften, getrennten Punkt hinzu. Eine Seite, deren Kontodienst ausgefallen ist, rechtfertigt keinen Neustart des Tunnels.

Schritt 2: Binden Sie jeden Fehlschlag an genau eine Aktion

Entscheiden Sie für jede Prüfung, was neu startet, was blockiert bleibt und was einen Menschen ruft. Ein Fehlschlag auf Tunnel-Ebene kann einen Neustart des Tunnels rechtfertigen; ein Resolver-Fehlschlag weist auf die DNS-Integration auf dem Client hin; ein Fehlschlag auf Anwendungsebene sollte den Tunnel fast nie berühren.

Sagen Sie, was ein Fehlschlag nicht tun darf, denn die gefährlichen Voreinstellungen sind die nachgiebigen. Ein ungesunder Status darf niemals zur Erlaubnis für direkten Anwendungsverkehr werden, denn ein Fallback, der den Tunnel still umgeht, nimmt dem Tunnel seinen Daseinsgrund. Verengen Sie auch die Aktionen: eine gemeinsame Komponente neu zu starten, weil ein Ziel langsam ist, macht aus einem lokalen Problem eines für die gesamte Flotte. Es zerstört auch den Nachweis, den Sie brauchten, um die Ursache zu finden.

Schritt 3: Halten Sie die Prüfungen harmlos und billig

Verwenden Sie kleine, schreibgeschützte Anfragen: eine statische Ressource, einen Health-Endpunkt, der seine eigene Abhängigkeit meldet, oder eine TCP-Verbindung zu einem Port, den Sie kontrollieren. Vermeiden Sie Anmeldedaten, privates Surfen und alles, was bei jedem Intervall den Zustand ändert, denn eine Prüfung, die schreibt, ist ein Lasttest nach Zeitplan.

Erfassen Sie Ziel, Routenerwartung und Timeout für jede Prüfung. Die Routenerwartung ist das Feld, das Leute weglassen, und genau sie trennt einen Tunnelausfall von einem Routingfehler, wenn Sie den Alarm später lesen. Leiten Sie das Intervall und die Fehlerschwelle aus der Wiederherstellungszeit ab, die Sie zusagen, und halten Sie das Timeout kürzer als das Intervall. Eine Prüfung, die noch läuft, wenn die nächste startet, meldet einen Fehlschlag doppelt und sieht wie ein Flappen aus.

Schritt 4: Brechen Sie jede Ebene und beobachten Sie, ob die richtige Prüfung rot wird

Stoppen Sie den Tunnelprozess und bestätigen Sie, dass die Prozessprüfung fehlschlägt, während DNS vielleicht noch aus dem Cache antwortet. Ändern Sie eine Route und bestätigen Sie, dass die geroutete Anfrage fehlschlägt, während Prozess und Handshake gesund bleiben. Brechen Sie nur DNS und bestätigen Sie, dass die Anwendungsprüfung Auflösung statt eines Tunnel-Fehlers meldet. Wenn sich zwei Prüfungen immer gemeinsam bewegen, haben Sie weniger Prüfungen, als Sie denken.

Testen Sie die Wiederherstellungsrichtung mit derselben Disziplin. Nachdem Sie die Ebene wiederhergestellt haben, sollte sich die Prüfung ohne manuellen Neustart klären, und die ausgelöste Aktion sollte keinen Umweg hinterlassen. Beobachten Sie einen vollen Zyklus, bevor Sie dem grünen Zustand trauen, denn eine Prüfung, die sich nur von Hand klärt, verbirgt einen kaputten Wiederherstellungspfad.

Schritt 5: Legen Sie das Runbook dorthin, wohin der Alarm zeigt

Eine Seite mit fünf Zeilen trägt das ganze Design: Ebene, Befehl, erwartetes Ergebnis, Aktion bei Fehlschlag, Verantwortlicher. Fügen Sie pro Prüfung eine Zeile hinzu, was sie bewusst nicht testet. Diese Zeile ist es, die die nächste Person davon abhält, eine sechste Prüfung hinzuzufügen, die alles misst und nichts unterscheidet. Verlinken Sie die Seite aus dem Alarmtext, sonst öffnet sie niemand, solange der Vorfall läuft.

In Container-Bereitstellungen prägt eine Abhängigkeitsbedingung den Start und nichts anderes. Compose-Startreihenfolge und Health-Bedingung Dokumentation beschreibt, wie Bereitschaft die Reihenfolge bestimmt, in der Dienste starten; nichts davon erzwingt danach eine Egress-Richtlinie, und nichts davon schlägt geschlossen fehl, wenn der Tunnel wegfällt. Fortlaufende Durchsetzung braucht ihre eigene Richtlinie und ihre eigene Prüfung, geschrieben auf derselben Seite.

Das Runbook ist fertig, wenn sich die richtige Ebene erholt, ohne dass jemand eine nicht erreichbare Website als kaputten Tunnel liest. Das prüft das Dokument, nicht den Tunnel.