Scheid VPN-gezondheidscontroles van applicatiegezondheidscontroles

Uw tunnelproces kan draaien terwijl de beschermde verbinding onbruikbaar is, en een webpagina die faalt is geen bewijs dat de tunnel kapot is. Wanneer één probe alle andere vertegenwoordigt, herstart een herstartbeleid de verkeerde component en noemt dat automatisering. Elke controle hieronder benoemt de laag die hij observeert, de actie die zijn falen veroorzaakt en het bewijs dat de actie werkte. De laatste stap maakt van de hele set een pagina die iemand om drie uur ’s nachts kan volgen.

Stap 1: benoem de laag die elke controle observeert

Vraag wat elke probe werkelijk kan zien voordat u er een schrijft. Levensvatbaarheid bewijst dat de daemon draait, een handshake of een peerlijst bewijst dat de relatie bestaat, een gerouteerd verzoek bewijst aflevering, en een opzoeking bewijst resolutie. Ze falen precies in die volgorde, en geen enkele impliceert de volgende. Een groene procescontrole naast een dode tunnel is het normale geval, geen tegenspraak.

Schrijf de vier controles in die volgorde op, met het exacte commando en de verwachte uitvoer voor elk. Een probe waarvan u de verwachte uitvoer niet kunt benoemen, wordt door elke operator die de melding ziet anders gelezen. Zet dezelfde lijst in de meldingstekst, niet alleen in de runbook, zodat de persoon die ’s nachts gewekt wordt de laag voor het symptoom tegenkomt. Houd elk commando klaar om te kopiëren op de host die het uitvoert.

Voeg daarna de applicatiecontrole toe als vijfde, apart item. Een pagina waarvan de accountdienst platligt rechtvaardigt geen herstart van de tunnel.

Stap 2: koppel elk falen aan één actie

Bepaal voor elke controle wat er herstart, wat geblokkeerd blijft en wat een mens oproept. Een falen van de tunnellaag kan een herstart van de tunnel rechtvaardigen; een falen van de resolver wijst op de DNS-integratie op de client; een falen van de applicatielaag mag bijna nooit de tunnel raken.

Zeg wat een falen niet mag doen, want de gevaarlijke standaardwaarden zijn de toestemmende. Een ongezonde status mag nooit toestemming worden voor direct applicatieverkeer, omdat een terugvalroute die de tunnel stilzwijgend omzeilt de reden wegneemt waarom de tunnel bestaat. Vernauw ook de acties: een gedeelde component herstarten omdat één bestemming traag is, maakt van een lokaal probleem een probleem voor de hele vloot. Het vernietigt ook het bewijs dat u nodig had om de oorzaak te vinden.

Stap 3: houd de probes onschadelijk en goedkoop

Gebruik kleine, alleen-lezen verzoeken: een statische bron, een gezondheidseindpunt dat zijn eigen afhankelijkheid meldt, of een TCP-verbinding naar een poort die u beheert. Vermijd inloggegevens, privé browsen en alles wat bij elk interval de status wijzigt, want een probe die schrijft is een belastingstest volgens schema.

Leg de bestemming, de routeverwachting en de time-out voor elke probe vast. De routeverwachting is het veld dat mensen weglaten, en dat is wat een tunnelfout van een routeringsfout scheidt wanneer u de melding later leest. Leid het interval en de foutdrempel af van de hersteltijd die u belooft, en houd de time-out korter dan het interval. Een probe die nog draait wanneer de volgende begint, meldt één fout twee keer en ziet eruit als flapperen.

Stap 4: breek elke laag en kijk of de juiste probe rood wordt

Stop het tunnelproces en bevestig dat de procescontrole faalt terwijl DNS misschien nog uit de cache antwoordt. Wijzig een route en bevestig dat het gerouteerde verzoek faalt terwijl het proces en de handshake gezond blijven. Breek alleen DNS en bevestig dat de applicatiecontrole resolutie meldt in plaats van een tunnelfout. Als twee probes altijd samen bewegen, hebt u minder controles dan u denkt.

Test de herstelrichting met dezelfde discipline. Nadat u de laag hebt hersteld, zou de probe zonder handmatige herstart moeten herstellen, en de actie die afging zou geen omweg achter moeten laten. Bekijk één volledige cyclus voordat u de groene status vertrouwt, want een probe die alleen met de hand herstelt verbergt een kapot herstelpad.

Stap 5: zet de runbook waar de melding naar wijst

Eén pagina met vijf rijen draagt het hele ontwerp: laag, commando, verwacht resultaat, actie bij falen, eigenaar. Voeg per probe een regel toe over wat hij bewust niet test. Die regel is wat voorkomt dat de volgende persoon een zesde controle toevoegt die alles meet en niets onderscheidt. Link de pagina vanuit de meldingstekst, anders opent niemand hem terwijl het incident loopt.

In containerimplementaties vormt een afhankelijkheidsvoorwaarde de start en niets anders. Compose-startvolgorde en gezondheidsvoorwaarde documentatie beschrijft hoe gereedheid de volgorde bepaalt waarin diensten starten; niets daarvan handhaaft daarna een uitgaand beleid, en niets daarvan faalt gesloten wanneer de tunnel wegvalt. Doorlopende handhaving vereist een eigen beleid en een eigen probe, geschreven op dezelfde pagina.

De runbook is klaar wanneer de juiste laag herstelt zonder dat iemand een onbereikbare website als een kapotte tunnel leest. Dat test het document, niet de tunnel.