Oddziel kontrole stanu VPN od kontroli stanu aplikacji

Twój proces tunelu może działać, gdy chronione połączenie jest bezużyteczne, a niedziałająca strona internetowa nie jest dowodem, że tunel się zepsuł. Gdy jedna sonda zastępuje wszystkie pozostałe, polityka ponownego uruchamiania restartuje niewłaściwy komponent i nazywa to automatyzacją. Każda kontrola poniżej nazywa warstwę, którą obserwuje, akcję wyzwalaną przez jej błąd i dowód, że akcja zadziałała. Ostatni krok zamienia cały zestaw w stronę, którą ktoś może śledzić o trzeciej nad ranem.

Krok 1: nazwij warstwę, którą obserwuje każda kontrola

Zapytaj, co każda sonda naprawdę widzi, zanim napiszesz którąkolwiek z nich. Żywotność dowodzi, że demon działa, uścisk dłoni lub lista peerów dowodzi, że relacja istnieje, kierowane żądanie dowodzi dostarczenia, a wyszukanie dowodzi rozwiązania. Zawodzą dokładnie w tej kolejności i żadna nie implikuje następnej. Zielona kontrola procesu obok martwego tunelu to normalny przypadek, nie sprzeczność.

Zapisz cztery kontrole w tej kolejności, z dokładnym poleceniem i oczekiwanym wyjściem dla każdej. Sondę, której oczekiwanego wyjścia nie potrafisz podać, każdy operator, który zobaczy alert, odczyta inaczej. Umieść tę samą listę w tekście alertu, nie tylko w runbooku, aby osoba obudzona w nocy spotkała warstwę przed objawem. Trzymaj każde polecenie gotowe do skopiowania na hoście, który je wykonuje.

Następnie dodaj kontrolę aplikacji jako piąty, osobny punkt. Strona, której usługa kont jest wyłączona, nie uzasadnia restartu tunelu.

Krok 2: powiąż każdy błąd z jedną akcją

Dla każdej kontroli zdecyduj, co się restartuje, co pozostaje zablokowane i co wzywa człowieka. Błąd warstwy tunelu może uzasadniać restart tunelu; błąd resolvera wskazuje na integrację DNS na kliencie; błąd warstwy aplikacji prawie nigdy nie powinien dotykać tunelu.

Powiedz, czego błąd nie może zrobić, bo niebezpieczne wartości domyślne to te przyzwalające. Niezdrowy stan nigdy nie może stać się pozwoleniem na bezpośredni ruch aplikacji, ponieważ ścieżka awaryjna, która po cichu omija tunel, usuwa powód istnienia tunelu. Zawęź także akcje: restart współdzielonego komponentu dlatego, że jeden cel jest wolny, zamienia problem lokalny w problem całej floty. Niszczy to również dowód potrzebny do znalezienia przyczyny.

Krok 3: utrzymuj sondy nieszkodliwe i tanie

Używaj małych żądań tylko do odczytu: zasobu statycznego, punktu końcowego stanu, który raportuje własną zależność, albo połączenia TCP z portem, który kontrolujesz. Unikaj danych uwierzytelniających, przeglądania prywatnego i wszystkiego, co zmienia stan w każdym interwale, ponieważ sonda, która zapisuje, jest testem obciążenia według harmonogramu.

Zapisz cel, oczekiwanie trasy i limit czasu dla każdej sondy. Oczekiwanie trasy to pole, które ludzie pomijają, i to ono oddziela awarię tunelu od błędu routingu, gdy później czytasz alert. Wyprowadź interwał i próg błędu z obiecanego czasu odzyskiwania i trzymaj limit czasu krótszy niż interwał. Sonda, która wciąż działa, gdy zaczyna się następna, zgłasza jeden błąd dwa razy i wygląda jak migotanie.

Krok 4: zepsuj każdą warstwę i sprawdź, czy właściwa sonda zmienia się na czerwono

Zatrzymaj proces tunelu i potwierdź, że kontrola procesu zawodzi, podczas gdy DNS może jeszcze odpowiadać z pamięci podręcznej. Zmień trasę i potwierdź, że kierowane żądanie zawodzi, podczas gdy proces i uścisk dłoni pozostają zdrowe. Zepsuj tylko DNS i potwierdź, że kontrola aplikacji zgłasza rozwiązanie, a nie błąd tunelu. Jeśli dwie sondy zawsze poruszają się razem, masz mniej kontroli, niż myślisz.

Przetestuj kierunek odzyskiwania z tą samą dyscypliną. Po przywróceniu warstwy sonda powinna się wyczyścić bez ręcznego restartu, a wyzwolona akcja nie powinna pozostawić żadnego obejścia. Obserwuj jeden pełny cykl, zanim zaufasz zielonemu stanowi, ponieważ sonda, która czyści się tylko ręcznie, ukrywa zepsutą ścieżkę odzyskiwania.

Krok 5: umieść runbook tam, gdzie wskazuje alert

Jedna strona z pięcioma wierszami niesie cały projekt: warstwa, polecenie, oczekiwany wynik, akcja przy błędzie, właściciel. Dodaj wiersz dla każdej sondy o tym, czego świadomie nie testuje. To ten wiersz powstrzymuje następną osobę przed dodaniem szóstej kontroli, która mierzy wszystko i nie rozróżnia niczego. Podlinkuj stronę z tekstu alertu, inaczej nikt jej nie otworzy, gdy incydent trwa.

W wdrożeniach kontenerowych warunek zależności kształtuje start i nic więcej. Kolejność startu i warunek stanu w Compose dokumentacja opisuje, jak gotowość wyznacza kolejność uruchamiania usług; nic z tego nie egzekwuje potem polityki wyjścia i nic z tego nie zawodzi zamknięcie, gdy tunel pada. Ciągłe egzekwowanie wymaga własnej polityki i własnej sondy, zapisanych na tej samej stronie.

Runbook jest gotowy, gdy właściwa warstwa się odtwarza, a nikt nie czyta niedostępnej strony jako zepsutego tunelu. To testuje dokument, nie tunel.