Odvojite VPN provjere zdravlja od provjera zdravlja aplikacije

Vaš proces tunela može raditi dok je zaštićena veza neupotrebljiva, a stranica koja ne radi nije dokaz da se tunel pokvario. Kada jedna sonda zamjenjuje sve ostale, politika ponovnog pokretanja ponovo pokreće pogrešnu komponentu i to naziva automatizacijom. Svaka provjera u nastavku navodi sloj koji promatra, radnju koju pokreće njezin neuspjeh i dokaz da je radnja uspjela. Posljednji korak cijeli skup pretvara u stranicu koju netko može slijediti u tri sata ujutro.

Korak 1: navedite sloj koji svaka provjera promatra

Pitajte što svaka sonda doista može vidjeti prije nego što napišete bilo koju od njih. Živost dokazuje da je daemon pokrenut, rukovanje ili popis partnera dokazuje da veza postoji, usmjereni zahtjev dokazuje dostavu, a pretraga dokazuje razrješavanje. One otkazuju točno tim redom i nijedna ne podrazumijeva sljedeću. Zelena provjera procesa pored mrtvog tunela normalan je slučaj, a ne proturječje.

Zapišite četiri provjere tim redom, s točnom naredbom i očekivanim izlazom za svaku. Sondu čiji očekivani izlaz ne možete navesti svaki će operater koji vidi upozorenje pročitati drugačije. Stavite isti popis u tekst upozorenja, ne samo u priručnik, kako bi osoba probuđena noću susrela sloj prije simptoma. Držite svaku naredbu spremnom za kopiranje na hostu koji je izvršava.

Zatim dodajte provjeru aplikacije kao petu, zasebnu stavku. Stranica kojoj je servis računa pao ne opravdava ponovno pokretanje tunela.

Korak 2: povežite svaki neuspjeh s jednom radnjom

Za svaku provjeru odlučite što se ponovno pokreće, što ostaje blokirano i što poziva čovjeka. Neuspjeh sloja tunela može opravdati ponovno pokretanje tunela; neuspjeh razrješivača upućuje na DNS integraciju na klijentu; neuspjeh sloja aplikacije gotovo nikada ne smije dirati tunel.

Navedite što neuspjeh ne smije učiniti, jer opasne su zadane vrijednosti one popustljive. Nezdrav status nikada ne smije postati dopuštenje za izravni promet aplikacije, jer pričuvni put koji tiho zaobilazi tunel uklanja razlog postojanja tunela. Suzite i radnje: ponovno pokretanje zajedničke komponente zato što je jedno odredište sporo pretvara lokalni problem u problem cijele flote. To uništava i dokaz koji vam je potreban da nađete uzrok.

Korak 3: držite sonde bezopasnima i jeftinima

Koristite male zahtjeve samo za čitanje: statički resurs, health endpoint koji izvještava o vlastitoj ovisnosti ili TCP vezu na port koji kontrolirate. Izbjegavajte vjerodajnice, privatno pregledavanje i sve što mijenja stanje u svakom intervalu, jer sonda koja piše jest test opterećenja po rasporedu.

Zabilježite odredište, očekivanje rute i vremensko ograničenje za svaku sondu. Očekivanje rute je polje koje ljudi izostavljaju i upravo ono odvaja neuspjeh tunela od pogreške usmjeravanja kada kasnije čitate upozorenje. Izvedite interval i prag neuspjeha iz vremena oporavka koje obećavate i držite ograničenje kraćim od intervala. Sonda koja još radi kada sljedeća počne prijavljuje jedan neuspjeh dvaput i izgleda kao treperenje.

Korak 4: pokvarite svaki sloj i gledajte kako prava sonda postaje crvena

Zaustavite proces tunela i potvrdite da provjera procesa otkazuje dok DNS još može odgovarati iz predmemorije. Promijenite rutu i potvrdite da usmjereni zahtjev otkazuje dok proces i rukovanje ostaju zdravi. Pokvarite samo DNS i potvrdite da provjera aplikacije prijavljuje razrješavanje, a ne pogrešku tunela. Ako se dvije sonde uvijek kreću zajedno, imate manje provjera nego što mislite.

Testirajte smjer oporavka istom disciplinom. Nakon što vratite sloj, sonda bi se trebala očistiti bez ručnog ponovnog pokretanja, a radnja koja se aktivirala ne bi trebala ostaviti zaobilazni put. Promatrajte jedan puni ciklus prije nego povjerujete zelenom stanju, jer sonda koja se čisti samo ručno skriva pokvaren put oporavka.

Korak 5: stavite priručnik tamo gdje upozorenje pokazuje

Jedna stranica s pet redaka nosi cijeli dizajn: sloj, naredba, očekivani rezultat, radnja pri neuspjehu, vlasnik. Dodajte za svaku sondu redak o tome što namjerno ne testira. Upravo taj redak sprječava sljedeću osobu da doda šestu provjeru koja mjeri sve i ne razlikuje ništa. Povežite stranicu iz teksta upozorenja, inače je nitko neće otvoriti dok incident traje.

U kontejnerskim implementacijama uvjet ovisnosti oblikuje pokretanje i ništa više. Redoslijed pokretanja i uvjet zdravlja u Composeu dokumentacija opisuje kako spremnost određuje redoslijed pokretanja servisa; ništa od toga ne nameće izlaznu politiku poslije i ništa ne otkazuje zatvoreno kada tunel padne. Trajna provedba treba vlastitu politiku i vlastitu sondu, napisane na istoj stranici.

Priručnik je gotov kada se pravi sloj oporavi, a da nitko nedostupno web-mjesto ne pročita kao pokvaren tunel. To testira dokument, a ne tunel.