Oddeľte kontroly stavu VPN od kontrol stavu aplikácie

Váš proces tunela môže bežať, zatiaľ čo chránené pripojenie je nepoužiteľné, a zlyhávajúca webová stránka nie je dôkazom, že sa tunel rozbil. Keď jedna sonda zastupuje všetky ostatné, politika reštartu reštartuje nesprávny komponent a nazýva to automatizáciou. Každá kontrola nižšie pomenuje vrstvu, ktorú sleduje, akciu, ktorú spúšťa jej zlyhanie, a dôkaz, že akcia fungovala. Posledný krok premení celú sadu na stránku, po ktorej sa niekto môže riadiť o tretej ráno.

Krok 1: pomenujte vrstvu, ktorú každá kontrola sleduje

Predtým, než niektorú z nich napíšete, opýtajte sa, čo každá sonda skutočne vidí. Živosť dokazuje, že démon beží, handshake alebo zoznam peerov dokazuje, že vzťah existuje, smerovaná požiadavka dokazuje doručenie a vyhľadanie dokazuje preklad. Zlyhávajú presne v tomto poradí a žiadna neimplikuje nasledujúcu. Zelená kontrola procesu vedľa mŕtveho tunela je normálny prípad, nie rozpor.

Zapíšte štyri kontroly v tomto poradí, s presným príkazom a očakávaným výstupom pre každú z nich. Sondu, ktorej očakávaný výstup nedokážete vysloviť, bude každý operátor, ktorý uvidí alarm, čítať inak. Dajte rovnaký zoznam do textu alarmu, nielen do runbooku, aby človek zobudený v noci stretol vrstvu skôr ako symptóm. Udržujte každý príkaz pripravený na skopírovanie na hostiteľovi, ktorý ho spúšťa.

Potom pridajte kontrolu aplikácie ako piatu, samostatnú položku. Stránka, ktorej služba účtov nefunguje, neospravedlňuje reštart tunela.

Krok 2: spojte každé zlyhanie s jednou akciou

Pri každej kontrole rozhodnite, čo sa reštartuje, čo zostane zablokované a čo zavolá človeka. Zlyhanie vrstvy tunela môže ospravedlniť reštart tunela; zlyhanie resolvera ukazuje na integráciu DNS na klientovi; zlyhanie vrstvy aplikácie by sa takmer nikdy nemalo dotknúť tunela.

Povedzte, čo zlyhanie nesmie urobiť, pretože nebezpečné predvolené hodnoty sú tie povoľujúce. Nezdravý stav sa nikdy nesmie stať povolením pre priamu prevádzku aplikácie, pretože záložná cesta, ktorá potichu obchádza tunel, odstraňuje dôvod, prečo tunel existuje. Zúžte aj akcie: reštart zdieľaného komponentu preto, že jeden cieľ je pomalý, mení lokálny problém na problém celej flotily. Ničí to aj dôkaz, ktorý ste potrebovali na nájdenie príčiny.

Krok 3: udržujte sondy neškodné a lacné

Používajte malé požiadavky iba na čítanie: statický prostriedok, health endpoint, ktorý hlási svoju vlastnú závislosť, alebo TCP pripojenie k portu, ktorý ovládate. Vyhnite sa prihlasovacím údajom, súkromnému prehliadaniu a čomukoľvek, čo v každom intervale mení stav, pretože sonda, ktorá zapisuje, je záťažový test podľa plánu.

Zaznamenajte cieľ, očakávanie trasy a časový limit pre každú sondu. Očakávanie trasy je pole, ktoré ľudia vynechávajú, a práve ono oddeľuje zlyhanie tunela od chyby smerovania, keď alarm neskôr čítate. Odvoďte interval a prah zlyhania z doby obnovy, ktorú sľubujete, a držte časový limit kratší ako interval. Sonda, ktorá stále beží, keď začína ďalšia, hlási jedno zlyhanie dvakrát a vyzerá ako blikanie.

Krok 4: rozbite každú vrstvu a sledujte, či sčervenie správna sonda

Zastavte proces tunela a potvrďte, že kontrola procesu zlyhá, zatiaľ čo DNS môže ešte odpovedať z vyrovnávacej pamäte. Zmeňte trasu a potvrďte, že smerovaná požiadavka zlyhá, zatiaľ čo proces a handshake zostávajú zdravé. Rozbite iba DNS a potvrďte, že kontrola aplikácie hlási preklad, a nie chybu tunela. Ak sa dve sondy vždy pohybujú spolu, máte menej kontrol, než si myslíte.

Otestujte smer obnovy s rovnakou disciplínou. Po obnovení vrstvy by sa sonda mala vyčistiť bez ručného reštartu a akcia, ktorá sa spustila, by nemala zanechať žiadne obchádzanie. Sledujte jeden celý cyklus, kým uveríte zelenému stavu, pretože sonda, ktorá sa čistí iba ručne, skrýva rozbitú cestu obnovy.

Krok 5: umiestnite runbook tam, kam ukazuje alarm

Jedna stránka s piatimi riadkami nesie celý návrh: vrstva, príkaz, očakávaný výsledok, akcia pri zlyhaní, vlastník. Pridajte riadok pre každú sondu o tom, čo zámerne netestuje. Práve tento riadok bráni ďalšiemu človeku pridať šiestu kontrolu, ktorá meria všetko a nerozlišuje nič. Prepojte stránku z textu alarmu, inak ju nikto počas incidentu neotvorí.

V kontajnerových nasadeniach podmienka závislosti formuje štart a nič iné. Poradie štartu a podmienka stavu v Compose dokumentácia opisuje, ako pripravenosť určuje poradie, v ktorom služby štartujú; nič z toho potom nevynucuje výstupnú politiku a nič z toho nezlyháva zatvorene, keď tunel padne. Nepretržité vynucovanie potrebuje vlastnú politiku a vlastnú sondu, napísané na tej istej stránke.

Runbook je hotový, keď sa správna vrstva obnoví bez toho, aby niekto čítal nedostupnú stránku ako rozbitý tunel. To testuje dokument, nie tunel.