Separați verificările de sănătate ale VPN de cele ale aplicației

Procesul tunelului poate rula în timp ce conexiunea protejată este inutilizabilă, iar o pagină web care eșuează nu este dovada că tunelul s-a stricat. Când o singură sondă reprezintă toate celelalte, o politică de repornire repornește componenta greșită și numește asta automatizare. Fiecare verificare de mai jos numește stratul pe care îl observă, acțiunea pe care o declanșează eșecul ei și dovada că acțiunea a funcționat. Ultimul pas transformă întregul set într-o pagină pe care cineva o poate urmări la trei dimineața.

Pasul 1: numiți stratul pe care îl observă fiecare verificare

Întrebați ce poate vedea cu adevărat fiecare sondă înainte de a scrie vreuna dintre ele. Viabilitatea dovedește că daemonul rulează, un handshake sau o listă de parteneri dovedește că relația există, o cerere rutată dovedește livrarea, iar o căutare dovedește rezolvarea. Ele eșuează exact în această ordine și niciuna nu o implică pe următoarea. O verificare de proces verde lângă un tunel mort este cazul normal, nu o contradicție.

Scrieți cele patru verificări în această ordine, cu comanda exactă și ieșirea așteptată pentru fiecare. O sondă a cărei ieșire așteptată nu o puteți enunța va fi citită diferit de fiecare operator care vede alerta. Puneți aceeași listă în textul alertei, nu doar în manual, ca persoana trezită noaptea să întâlnească stratul înaintea simptomului. Țineți fiecare comandă gata de copiat pe gazda care o execută.

Apoi adăugați verificarea aplicației ca al cincilea element, separat. O pagină al cărei serviciu de conturi este picat nu justifică repornirea tunelului.

Pasul 2: legați fiecare eșec de o singură acțiune

Pentru fiecare verificare, decideți ce repornește, ce rămâne blocat și ce cheamă o persoană. Un eșec al stratului de tunel poate justifica repornirea tunelului; un eșec al resolverului indică integrarea DNS pe client; un eșec al stratului de aplicație aproape niciodată nu ar trebui să atingă tunelul.

Spuneți ce nu trebuie să facă un eșec, pentru că valorile implicite periculoase sunt cele permisive. O stare nesănătoasă nu trebuie să devină niciodată permisiune pentru trafic direct al aplicației, fiindcă o cale de rezervă care ocolește tunelul în tăcere elimină motivul pentru care tunelul există. Îngustați și acțiunile: repornirea unei componente partajate pentru că o destinație este lentă transformă o problemă locală într-o problemă pentru toată flota. De asemenea, distruge dovada de care aveați nevoie pentru a găsi cauza.

Pasul 3: țineți sondele inofensive și ieftine

Folosiți cereri mici, doar de citire: o resursă statică, un punct final de sănătate care raportează propria dependență sau o conexiune TCP la un port pe care îl controlați. Evitați acreditările, navigarea privată și orice modifică starea la fiecare interval, pentru că o sondă care scrie este un test de încărcare programat.

Înregistrați destinația, așteptarea rutei și timpul limită pentru fiecare sondă. Așteptarea rutei este câmpul pe care oamenii îl omit, și ea este cea care separă un eșec de tunel de o eroare de rutare când citiți alerta mai târziu. Derivați intervalul și pragul de eșec din timpul de recuperare pe care îl promiteți și țineți timpul limită mai scurt decât intervalul. O sondă care încă rulează când începe următoarea raportează un eșec de două ori și arată ca o pâlpâire.

Pasul 4: rupeți fiecare strat și urmăriți dacă sonda corectă devine roșie

Opriți procesul tunelului și confirmați că verificarea procesului eșuează în timp ce DNS poate încă răspunde din cache. Schimbați o rută și confirmați că cererea rutată eșuează în timp ce procesul și handshake-ul rămân sănătoase. Rupeți doar DNS și confirmați că verificarea aplicației raportează rezolvare, nu o eroare de tunel. Dacă două sonde se mișcă mereu împreună, aveți mai puține verificări decât credeți.

Testați direcția de recuperare cu aceeași disciplină. După ce restabiliți stratul, sonda ar trebui să se curățe fără o repornire manuală, iar acțiunea declanșată nu ar trebui să lase nicio ocolire în urmă. Urmăriți un ciclu complet înainte să vă încredeți în starea verde, pentru că o sondă care se curăță doar manual ascunde o cale de recuperare ruptă.

Pasul 5: puneți manualul acolo unde indică alerta

O pagină cu cinci rânduri duce întregul design: strat, comandă, rezultat așteptat, acțiune la eșec, proprietar. Adăugați un rând pentru fiecare sondă despre ce nu testează deliberat. Acel rând este cel care împiedică următoarea persoană să adauge o a șasea verificare care măsoară tot și nu distinge nimic. Legați pagina din textul alertei, altfel nimeni nu o va deschide cât timp incidentul este activ.

În implementările cu containere, o condiție de dependență modelează pornirea și nimic altceva. Ordinea de pornire și condiția de sănătate din Compose documentația descrie cum disponibilitatea determină ordinea în care pornesc serviciile; nimic din toate acestea nu aplică apoi o politică de ieșire și nimic nu eșuează închis când tunelul cade. Aplicarea continuă are nevoie de propria politică și de propria sondă, scrise pe aceeași pagină.

Manualul este gata când stratul corect se recuperează fără ca cineva să citească un site indisponibil ca pe un tunel rupt. Asta testează documentul, nu tunelul.