Adskil VPN-sundhedstjek fra applikationens sundhedstjek

Din tunnelproces kan køre, mens den beskyttede forbindelse er ubrugelig, og en webside, der fejler, er ikke bevis for, at tunnelen er brudt. Når én probe står i stedet for dem alle, genstarter en genstartspolitik den forkerte komponent og kalder det automatisering. Hvert tjek nedenfor navngiver det lag, det observerer, den handling, dets fejl udløser, og det bevis, at handlingen virkede. Det sidste trin gør hele sættet til en side, som nogen kan følge klokken tre om natten.

Trin 1: navngiv det lag, hvert tjek observerer

Spørg, hvad hver probe faktisk kan se, før du skriver nogen af dem. Livlighed beviser, at daemonen kører, et håndtryk eller en peer-liste beviser, at forholdet findes, en rutet anmodning beviser levering, og et opslag beviser opløsning. De fejler i netop den rækkefølge, og ingen af dem forudsætter den næste. Et grønt proces-tjek ved siden af en død tunnel er det normale tilfælde, ikke en selvmodsigelse.

Skriv de fire tjek ned i den rækkefølge, med den præcise kommando og det forventede output for hvert. En probe, hvis forventede output du ikke kan angive, vil blive læst forskelligt af hver operatør, der ser alarmen. Sæt den samme liste i alarmteksten, ikke kun i runbooken, så den person, der vækkes om natten, møder laget før symptomet. Hold hver kommando klar til at kopiere på den vært, der kører den.

Tilføj derefter applikationstjekket som et femte, separat punkt. En side, hvis kontotjeneste er nede, retfærdiggør ikke en genstart af tunnelen.

Trin 2: bind hver fejl til én handling

For hvert tjek skal du beslutte, hvad der genstarter, hvad der forbliver blokeret, og hvad der tilkalder et menneske. En fejl i tunnellaget kan retfærdiggøre en genstart af tunnelen; en resolverfejl peger på DNS-integrationen på klienten; en fejl i applikationslaget bør næsten aldrig røre tunnelen.

Sig, hvad en fejl ikke må gøre, for de farlige standarder er de eftergivende. En usund status må aldrig blive tilladelse til direkte applikationstrafik, da en fallback, der stille omgår tunnelen, fjerner grunden til, at tunnelen findes. Indsnævr også handlingerne: at genstarte en delt komponent, fordi én destination er langsom, gør et lokalt problem til et problem for hele flåden. Det ødelægger også det bevis, du havde brug for til at finde årsagen.

Trin 3: hold proberne harmløse og billige

Brug små skrivebeskyttede anmodninger: en statisk ressource, et sundhedsendepunkt, der rapporterer sin egen afhængighed, eller en TCP-forbindelse til en port, du kontrollerer. Undgå legitimationsoplysninger, privat browsing og alt, der ændrer tilstand ved hvert interval, fordi en probe, der skriver, er en belastningstest efter skema.

Registrér destinationen, ruteforventningen og timeoutet for hver probe. Ruteforventningen er det felt, folk udelader, og det er det, der adskiller en tunnelfejl fra en routingfejl, når du læser alarmen senere. Udled intervallet og fejltærsklen fra den genopretningstid, du lover, og hold timeoutet kortere end intervallet. En probe, der stadig kører, når den næste starter, rapporterer én fejl to gange og ligner en flapper.

Trin 4: bræk hvert lag og se, om den rigtige probe bliver rød

Stop tunnelprocessen, og bekræft, at procestjekket fejler, mens DNS måske stadig svarer fra cachen. Ændr en rute, og bekræft, at den rutede anmodning fejler, mens processen og håndtrykket forbliver sunde. Bræk kun DNS, og bekræft, at applikationstjekket rapporterer opløsning i stedet for en tunnelfejl. Hvis to prober altid bevæger sig sammen, har du færre tjek, end du tror.

Test genopretningsretningen med samme disciplin. Når du har gendannet laget, bør proben klare sig uden en manuel genstart, og den handling, der blev udløst, bør ikke efterlade en omvej. Se en hel cyklus, før du stoler på den grønne tilstand, fordi en probe, der kun klarer sig manuelt, skjuler en brudt genopretningsvej.

Trin 5: placér runbooken, hvor alarmen peger

Én side med fem rækker bærer hele designet: lag, kommando, forventet resultat, handling ved fejl, ejer. Tilføj en linje for hver probe om, hvad den bevidst ikke tester. Den linje er det, der forhindrer den næste person i at tilføje et sjette tjek, der måler alt og skelner intet. Link siden fra alarmteksten, ellers åbner ingen den, mens hændelsen er aktiv.

I containerudrulninger former en afhængighedsbetingelse opstart og intet andet. Compose startrækkefølge og sundhedsbetingelse dokumentationen beskriver, hvordan parathed styrer den rækkefølge, tjenester starter i; intet af det håndhæver egress-politik bagefter, og intet af det fejler lukket, når tunnelen falder. Kontinuerlig håndhævelse kræver sin egen politik og sin egen probe, skrevet på samme side.

Runbooken er færdig, når det rigtige lag genoprettes, uden at nogen læser et utilgængeligt websted som en brudt tunnel. Det tester dokumentet, ikke tunnelen.