Tunnelprosessen din kan køyra medan den verna sambindinga er ubrukeleg, og ei nettside som feilar er ikkje prov på at tunnelen er broten. Når ein probe står for alle dei andre, startar ein omstartspolicy feil komponent på nytt og kallar det automatisering. Kvar sjekk nedanfor nemner laget han observerer, handlinga feilen utløyser, og provet på at handlinga verka. Det siste trinnet gjer heile settet om til ei side nokon kan følgja klokka tre om natta.

Trinn 1: nemn laget kvar sjekk observerer

Spør kva kvar probe faktisk kan sjå før du skriv nokon av dei. Livlegheit provar at daemonen køyrer, eit handtrykk eller ei peer-liste provar at forholdet finst, ein ruta førespurnad provar levering, og eit oppslag provar oppslag. Dei feilar i nettopp den rekkjefølgja, og ingen av dei føreset den neste. Ein grøn prosesssjekk ved sida av ein død tunnel er det normale tilfellet, ikkje ein sjølvmotseiing.

Skriv ned dei fire sjekkane i den rekkjefølgja, med den nøyaktige kommandoen og forventa utdata for kvar. Ein probe der du ikkje kan oppgje forventa utdata, vil bli lesen ulikt av kvar operatør som ser varselet. Set den same lista i varselteksten, ikkje berre i runbooken, slik at personen som blir vekt om natta møter laget før symptomet. Hald kvar kommando klar til å kopierast på verten som køyrer han.

Legg deretter til applikasjonssjekken som eit femte, eige punkt. Ei side der kontotenesta er nede rettferdiggjer ikkje omstart av tunnelen.

Trinn 2: bind kvar feil til éi handling

For kvar sjekk, avgjer kva som startar på nytt, kva som blir verande blokkert, og kva som kallar på eit menneske. Ein feil i tunnellaget kan rettferdiggjere omstart av tunnelen; ein resolverfeil peikar på DNS-integrasjonen på klienten; ein feil i applikasjonslaget bør nesten aldri røra tunnelen.

Sei kva ein feil ikkje må gjera, fordi dei farlege standardverdiane er dei som tillèt. Ein usunn status må aldri bli løyve for direkte applikasjonstrafikk, sidan ein reserveveg som stille går utanom tunnelen fjernar grunnen til at tunnelen finst. Snekk inn handlingane òg: å starta ein delt komponent på nytt fordi éin destinasjon er treg gjer eit lokalt problem til eit problem for heile flåten. Det øydelegg òg provet du trong for å finna årsaka.

Trinn 3: hald probane ufarlege og billege

Bruk små, skriveverna førespurnader: ein statisk ressurs, eit helseendepunkt som rapporterer si eiga avhengnad, eller ei TCP-tilkopling til ein port du kontrollerer. Unngå påloggingsdetaljar, privat nettlesing og alt som endrar tilstand ved kvart intervall, fordi ein probe som skriv er ein lasttest etter plan.

Registrer destinasjonen, ruteforventinga og tidsavbrotet for kvar probe. Ruteforventinga er feltet folk utelèt, og det er det som skil ein tunnelfeil frå ein rutefeil når du les varselet seinare. Utleid intervallet og feilterskelen frå gjenopprettingstida du lovar, og hald tidsavbrotet kortare enn intervallet. Ein probe som framleis køyrer når den neste startar, rapporterer éin feil to gonger og ser ut som flakking.

Trinn 4: bryt kvart lag og sjå om rett probe blir raud

Stopp tunnelprosessen og stadfest at prosesssjekken feilar medan DNS kanskje framleis svarar frå mellombufferet. Endra ei rute og stadfest at den ruta førespurnaden feilar medan prosessen og handtrykket blir verande sunne. Bryt berre DNS og stadfest at applikasjonssjekken rapporterer oppslag i staden for ein tunnelfeil. Viss to prober alltid rører seg saman, har du færre sjekkar enn du trur.

Test gjenopprettingsretninga med same disiplin. Når du har gjenoppretta laget, bør proben klara seg utan ein manuell omstart, og handlinga som vart utløyst bør ikkje etterlata nokon omveg. Sjå ein heil syklus før du stolar på den grøne tilstanden, fordi ein probe som berre klarer seg manuelt løyner ein broten gjenopprettingsveg.

Trinn 5: set runbooken der varselet peikar

Éi side med fem radar ber heile designet: lag, kommando, forventa resultat, handling ved feil, eigar. Legg til ei linje per probe om kva han med vilje ikkje testar. Den linja er det som hindrar den neste personen i å leggja til ein sjette sjekk som måler alt og skil ingenting. Lenk sida frå varselteksten, elles opnar ingen ho medan hendinga pågår.

I containerutplasseringar formar eit avhengnadskrav oppstarten og ingenting anna. Compose-oppstartsrekkjefølgje og helsekrav dokumentasjonen skildrar korleis beredskap styrer rekkjefølgja tenestene startar i; ingenting av det handhevar egress-policy etterpå, og ingenting av det feilar lukka når tunnelen fell. Kontinuerleg handheving treng si eiga policy og sin eigen probe, skrivne på same sida.

Runbooken er ferdig når rett lag blir gjenoppretta utan at nokon les ein utilgjengeleg nettstad som ein broten tunnel. Det testar dokumentet, ikkje tunnelen.

Relaterte artiklar