Skill VPN-helsesjekker fra applikasjonens helsesjekker

Tunnelprosessen din kan kjøre mens den beskyttede forbindelsen er ubrukelig, og en nettside som feiler er ikke bevis på at tunnelen er brutt. Når én probe står for alle de andre, starter en omstartspolicy feil komponent på nytt og kaller det automatisering. Hver sjekk nedenfor navngir laget den observerer, handlingen feilen utløser, og beviset på at handlingen virket. Det siste trinnet gjør hele settet om til en side noen kan følge klokken tre om natten.

Trinn 1: navngi laget hver sjekk observerer

Spør hva hver probe faktisk kan se før du skriver noen av dem. Livlighet beviser at daemonen kjører, et håndtrykk eller en peer-liste beviser at forholdet finnes, en rutet forespørsel beviser levering, og et oppslag beviser oppslag. De feiler i nettopp den rekkefølgen, og ingen av dem forutsetter den neste. En grønn prosesssjekk ved siden av en død tunnel er det normale tilfellet, ikke en selvmotsigelse.

Skriv ned de fire sjekkene i den rekkefølgen, med den nøyaktige kommandoen og forventet utdata for hver. En probe der du ikke kan angi forventet utdata, vil bli lest forskjellig av hver operatør som ser varselet. Sett den samme listen i varselteksten, ikke bare i runbooken, slik at personen som vekkes om natten møter laget før symptomet. Hold hver kommando klar til å kopieres på verten som kjører den.

Legg deretter til applikasjonssjekken som et femte, eget punkt. En side der kontotjenesten er nede rettferdiggjør ikke omstart av tunnelen.

Trinn 2: bind hver feil til én handling

For hver sjekk, avgjør hva som starter på nytt, hva som forblir blokkert, og hva som tilkaller et menneske. En feil i tunnellaget kan rettferdiggjøre omstart av tunnelen; en resolverfeil peker på DNS-integrasjonen på klienten; en feil i applikasjonslaget bør nesten aldri berøre tunnelen.

Si hva en feil ikke må gjøre, fordi de farlige standardverdiene er de som tillater. En usunn status må aldri bli tillatelse for direkte applikasjonstrafikk, siden en reservevei som stille omgår tunnelen fjerner grunnen til at tunnelen finnes. Snevre inn handlingene også: å starte en delt komponent på nytt fordi én destinasjon er treg gjør et lokalt problem til et problem for hele flåten. Det ødelegger også beviset du trengte for å finne årsaken.

Trinn 3: hold probene ufarlige og billige

Bruk små, skrivebeskyttede forespørsler: en statisk ressurs, et helseendepunkt som rapporterer sin egen avhengighet, eller en TCP-tilkobling til en port du kontrollerer. Unngå påloggingsdetaljer, privat nettlesing og alt som endrer tilstand ved hvert intervall, fordi en probe som skriver er en lasttest etter plan.

Registrer destinasjonen, ruteforventningen og tidsavbruddet for hver probe. Ruteforventningen er feltet folk utelater, og det er det som skiller en tunnelfeil fra en rutefeil når du leser varselet senere. Utled intervallet og feilterskelen fra gjenopprettingstiden du lover, og hold tidsavbruddet kortere enn intervallet. En probe som fortsatt kjører når den neste starter, rapporterer én feil to ganger og ser ut som flakking.

Trinn 4: bryt hvert lag og se om riktig probe blir rød

Stopp tunnelprosessen og bekreft at prosesssjekken feiler mens DNS kanskje fortsatt svarer fra hurtigbufferen. Endre en rute og bekreft at den rutete forespørselen feiler mens prosessen og håndtrykket forblir sunne. Bryt bare DNS og bekreft at applikasjonssjekken rapporterer oppslag i stedet for en tunnelfeil. Hvis to prober alltid beveger seg sammen, har du færre sjekker enn du tror.

Test gjenopprettingsretningen med samme disiplin. Når du har gjenopprettet laget, bør proben klare seg uten en manuell omstart, og handlingen som ble utløst bør ikke etterlate noen omvei. Se en hel syklus før du stoler på den grønne tilstanden, fordi en probe som bare klarer seg manuelt skjuler en brutt gjenopprettingsvei.

Trinn 5: sett runbooken der varselet peker

Én side med fem rader bærer hele designet: lag, kommando, forventet resultat, handling ved feil, eier. Legg til en linje per probe om hva den bevisst ikke tester. Den linjen er det som hindrer den neste personen i å legge til en sjette sjekk som måler alt og skiller ingenting. Lenk siden fra varselteksten, ellers åpner ingen den mens hendelsen pågår.

I containerutplasseringer former en avhengighetsbetingelse oppstarten og ingenting annet. Compose-oppstartsrekkefølge og helsebetingelse dokumentasjonen beskriver hvordan beredskap styrer rekkefølgen tjenestene starter i; ingenting av det håndhever egress-policy etterpå, og ingenting av det feiler lukket når tunnelen faller. Kontinuerlig håndheving trenger sin egen policy og sin egen probe, skrevet på samme side.

Runbooken er ferdig når riktig lag gjenopprettes uten at noen leser et utilgjengelig nettsted som en brutt tunnel. Det tester dokumentet, ikke tunnelen.