Oddělte kontroly stavu VPN od kontrol stavu aplikace

Váš proces tunelu může běžet, zatímco chráněné spojení je nepoužitelné, a selhávající webová stránka není důkazem, že se tunel rozbil. Když jedna sonda zastupuje všechny ostatní, politika restartu restartuje špatnou komponentu a říká tomu automatizace. Každá kontrola níže pojmenuje vrstvu, kterou sleduje, akci, kterou spouští její selhání, a důkaz, že akce fungovala. Poslední krok promění celou sadu ve stránku, po které se někdo může řídit ve tři ráno.

Krok 1: pojmenujte vrstvu, kterou každá kontrola sleduje

Než některou z nich napíšete, zeptejte se, co každá sonda skutečně vidí. Živost dokazuje, že démon běží, handshake nebo seznam peerů dokazuje, že vztah existuje, směrovaný požadavek dokazuje doručení a dotaz dokazuje překlad. Selhávají přesně v tomto pořadí a žádná z nich neimplikuje následující. Zelená kontrola procesu vedle mrtvého tunelu je normální případ, ne rozpor.

Zapište čtyři kontroly v tomto pořadí, s přesným příkazem a očekávaným výstupem pro každou z nich. Sondu, jejíž očekávaný výstup nedokážete vyslovit, bude každý operátor, který uvidí alarm, číst jinak. Dejte stejný seznam do textu alarmu, nejen do runbooku, aby člověk probuzený v noci potkal vrstvu dřív než symptom. Udržujte každý příkaz připravený ke zkopírování na hostiteli, který ho spouští.

Potom přidejte kontrolu aplikace jako pátou, samostatnou položku. Stránka, jejíž služba účtů nefunguje, neospravedlňuje restart tunelu.

Krok 2: spojte každé selhání s jednou akcí

U každé kontroly rozhodněte, co se restartuje, co zůstane zablokované a co zavolá člověka. Selhání vrstvy tunelu může ospravedlnit restart tunelu; selhání resolveru ukazuje na integraci DNS na klientu; selhání vrstvy aplikace by se téměř nikdy nemělo dotknout tunelu.

Řekněte, co selhání nesmí udělat, protože nebezpečné výchozí hodnoty jsou ty povolující. Nezdravý stav se nikdy nesmí stát povolením pro přímý provoz aplikace, protože záložní cesta, která tiše obchází tunel, odstraňuje důvod, proč tunel existuje. Zužte i akce: restart sdílené komponenty proto, že jeden cíl je pomalý, mění místní problém v problém celé flotily. Ničí to také důkaz, který jste potřebovali k nalezení příčiny.

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

Používejte malé požadavky jen pro čtení: statický prostředek, health endpoint, který hlásí svou vlastní závislost, nebo TCP připojení k portu, který ovládáte. Vyhněte se přihlašovacím údajům, soukromému prohlížení a čemukoli, co v každém intervalu mění stav, protože sonda, která zapisuje, je zátěžový test podle plánu.

Zaznamenejte cíl, očekávání trasy a časový limit pro každou sondu. Očekávání trasy je pole, které lidé vynechávají, a právě ono odděluje selhání tunelu od chyby směrování, když alarm později čtete. Odvoďte interval a práh selhání z doby obnovy, kterou slibujete, a držte časový limit kratší než interval. Sonda, která stále běží, když začne další, hlásí jedno selhání dvakrát a vypadá jako blikání.

Krok 4: rozbijte každou vrstvu a sledujte, zda zčervená správná sonda

Zastavte proces tunelu a potvrďte, že kontrola procesu selže, zatímco DNS může ještě odpovídat z cache. Změňte trasu a potvrďte, že směrovaný požadavek selže, zatímco proces a handshake zůstávají zdravé. Rozbijte jen DNS a potvrďte, že kontrola aplikace hlásí překlad, a ne chybu tunelu. Pokud se dvě sondy vždy pohybují společně, máte méně kontrol, než si myslíte.

Otestujte směr obnovy se stejnou disciplínou. Po obnovení vrstvy by se sonda měla vyčistit bez ručního restartu a akce, která se spustila, by neměla zanechat žádné obcházení. Sledujte jeden celý cyklus, než uvěříte zelenému stavu, protože sonda, která se čistí jen ručně, skrývá rozbitou cestu obnovy.

Krok 5: umístěte runbook tam, kam alarm ukazuje

Jedna stránka s pěti řádky nese celý návrh: vrstva, příkaz, očekávaný výsledek, akce při selhání, vlastník. Přidejte ke každé sondě řádek o tom, co záměrně netestuje. Právě tento řádek brání dalšímu člověku přidat šestou kontrolu, která měří všechno a nerozlišuje nic. Propojte stránku z textu alarmu, jinak ji nikdo během incidentu neotevře.

V kontejnerových nasazeních podmínka závislosti formuje start a nic jiného. Pořadí startu a podmínka stavu v Compose dokumentace popisuje, jak připravenost určuje pořadí, v němž služby startují; nic z toho potom nevynucuje výstupní politiku a nic z toho neselhává zavřeně, když tunel spadne. Nepřetržité vynucování potřebuje vlastní politiku a vlastní sondu, napsané na stejné stránce.

Runbook je hotový, když se správná vrstva obnoví, aniž by někdo četl nedostupný web jako rozbitý tunel. To testuje dokument, ne tunel.