Separera VPN-hälsokontroller från applikationens hälsokontroller

Din tunnelprocess kan köra medan den skyddade anslutningen är oanvändbar, och en webbsida som misslyckas är inte bevis för att tunneln är trasig. När en enda sond representerar alla andra startar en omstartspolicy fel komponent och kallar det automatisering. Varje kontroll nedan namnger lagret den observerar, åtgärden som dess misslyckande utlöser och beviset att åtgärden fungerade. Det sista steget gör hela uppsättningen till en sida som någon kan följa klockan tre på natten.

Steg 1: namnge lagret som varje kontroll observerar

Fråga vad varje sond faktiskt kan se innan du skriver någon av dem. Livlighet bevisar att daemonen kör, ett handskakning eller en peer-lista bevisar att relationen finns, en routad begäran bevisar leverans och en uppslagning bevisar upplösning. De misslyckas i precis den ordningen och ingen av dem förutsätter nästa. En grön processkontroll bredvid en död tunnel är det normala fallet, inte en motsägelse.

Skriv ned de fyra kontrollerna i den ordningen, med det exakta kommandot och förväntad utdata för varje. En sond vars förväntade utdata du inte kan ange kommer att läsas olika av varje operatör som ser larmet. Sätt samma lista i larmtexten, inte bara i runbooken, så att personen som väcks på natten möter lagret före symtomet. Håll varje kommando klart att kopiera på värden som kör det.

Lägg sedan till applikationskontrollen som ett femte, separat objekt. En sida vars kontotjänst är nere rättfärdigar inte en omstart av tunneln.

Steg 2: bind varje misslyckande till en enda åtgärd

För varje kontroll, avgör vad som startar om, vad som förblir blockerat och vad som larmar en människa. Ett misslyckande i tunnellagret kan rättfärdiga en omstart av tunneln; ett resolverfel pekar på DNS-integrationen på klienten; ett fel i applikationslagret bör nästan aldrig röra tunneln.

Säg vad ett misslyckande inte får göra, eftersom de farliga standardvärdena är de tillåtande. En ohälsosam status får aldrig bli tillstånd för direkt applikationstrafik, eftersom en reservväg som tyst kringgår tunneln tar bort anledningen till att tunneln finns. Begränsa också åtgärderna: att starta om en delad komponent för att ett mål är långsamt gör ett lokalt problem till ett problem för hela flottan. Det förstör också beviset du behövde för att hitta orsaken.

Steg 3: håll sonderna ofarliga och billiga

Använd små, skrivskyddade begäranden: en statisk resurs, en hälsoslutpunkt som rapporterar sitt eget beroende eller en TCP-anslutning till en port du kontrollerar. Undvik inloggningsuppgifter, privat surfning och allt som ändrar tillstånd vid varje intervall, eftersom en sond som skriver är ett lasttest enligt schema.

Registrera målet, ruttförväntningen och tidsgränsen för varje sond. Ruttförväntningen är fältet folk utelämnar, och det är den som skiljer ett tunnelfel från ett routingfel när du läser larmet senare. Härled intervallet och feltröskeln från återställningstiden du lovar, och håll tidsgränsen kortare än intervallet. En sond som fortfarande kör när nästa börjar rapporterar ett fel två gånger och ser ut som fladdring.

Steg 4: bryt varje lager och se om rätt sond blir röd

Stoppa tunnelprocessen och bekräfta att processkontrollen misslyckas medan DNS kanske fortfarande svarar från cachen. Ändra en rutt och bekräfta att den routade begäran misslyckas medan processen och handskakningen förblir friska. Bryt bara DNS och bekräfta att applikationskontrollen rapporterar upplösning i stället för ett tunnelfel. Om två sondar alltid rör sig tillsammans har du färre kontroller än du tror.

Testa återställningsriktningen med samma disciplin. När du har återställt lagret bör sonden klarna utan en manuell omstart, och åtgärden som utlöstes bör inte lämna någon omväg efter sig. Se en hel cykel innan du litar på det gröna tillståndet, eftersom en sond som bara klarnar för hand döljer en trasig återställningsväg.

Steg 5: placera runbooken där larmet pekar

En sida med fem rader bär hela designen: lager, kommando, förväntat resultat, åtgärd vid fel, ägare. Lägg till en rad per sond om vad den medvetet inte testar. Den raden är det som hindrar nästa person från att lägga till en sjätte kontroll som mäter allt och skiljer ingenting. Länka sidan från larmtexten, annars öppnar ingen den medan incidenten pågår.

I containerdistributioner formar ett beroendevillkor starten och ingenting annat. Compose-startordning och hälsovillkor dokumentation beskriver hur beredskap styr ordningen tjänsterna startar i; ingenting av det upprätthåller egress-policy efteråt, och ingenting av det misslyckas stängt när tunneln faller. Kontinuerlig upprätthållning behöver sin egen policy och sin egen sond, skrivna på samma sida.

Runbooken är klar när rätt lager återställs utan att någon läser en otillgänglig webbplats som en trasig tunnel. Det testar dokumentet, inte tunnelen.