Отделете проверките на VPN от проверките на приложението

Процесът на тунела ви може да работи, докато защитената връзка е неизползваема, а неработеща уеб страница не е доказателство, че тунелът се е счупил. Когато една проверка замества всички останали, политика за рестартиране рестартира грешния компонент и нарича това автоматизация. Всяка проверка по-долу назовава слоя, който наблюдава, действието, което задейства нейният провал, и доказателството, че действието е проработило. Последната стъпка превръща целия набор в страница, по която човек може да върви в три часа през нощта.

Стъпка 1: назовете слоя, който наблюдава всяка проверка

Попитайте какво всъщност вижда всяка проверка, преди да напишете която и да е от тях. Живостта доказва, че демонът работи, ръкостискането или списъкът с партньори доказва, че връзката съществува, маршрутизираната заявка доказва доставка, а резолюцията доказва преобразуването на името. Те се провалят точно в този ред и нито една не предполага следващата. Зелена проверка на процеса до мъртъв тунел е нормалният случай, а не противоречие.

Запишете четирите проверки в този ред, с точната команда и очаквания изход за всяка. Проверка, чийто очакван изход не можете да формулирате, ще бъде прочетена различно от всеки оператор, който види сигнала. Сложете същия списък в текста на сигнала, не само в указанието, за да срещне човекът, събуден през нощта, слоя преди симптома. Пазете всяка команда готова за копиране на хоста, който я изпълнява.

След това добавете проверката на приложението като пети, отделен елемент. Страница, чиято услуга за акаунти не работи, не оправдава рестартиране на тунела.

Стъпка 2: свържете всеки провал с едно действие

За всяка проверка решете какво се рестартира, какво остава блокирано и какво вика човек. Провал на слоя на тунела може да оправдае рестартиране на тунела; провал на резолвера сочи към DNS интеграцията на клиента; провал на слоя на приложението почти никога не трябва да докосва тунела.

Кажете какво не бива да прави провалът, защото опасните настройки по подразбиране са разрешаващите. Несъстоянието не бива никога да става разрешение за директен трафик на приложението, тъй като резервен път, който тихо заобикаля тунела, премахва причината тунелът да съществува. Стеснете и действията: рестартиране на споделен компонент, защото една дестинация е бавна, превръща местен проблем в проблем за целия парк. То също унищожава доказателството, което ви е нужно, за да намерите причината.

Стъпка 3: пазете проверките безвредни и евтини

Използвайте малки заявки само за четене: статичен ресурс, крайна точка за състояние, която отчита собствената си зависимост, или TCP връзка към порт, който контролирате. Избягвайте идентификационни данни, поверително сърфиране и всичко, което променя състояние на всеки интервал, защото проверка, която пише, е тест за натоварване по график.

Записвайте дестинацията, очакването за маршрута и таймаута за всяка проверка. Очакването за маршрута е полето, което хората пропускат, и точно то разделя провал на тунела от грешка в маршрутизацията, когато по-късно прочетете сигнала. Изведете интервала и прага на провал от времето за възстановяване, което обещавате, и дръжте таймаута по-кратък от интервала. Проверка, която още работи, когато започне следващата, отчита един провал два пъти и изглежда като трептене.

Стъпка 4: счупете всеки слой и гледайте дали правилната проверка почервенява

Спрете процеса на тунела и потвърдете, че проверката на процеса се проваля, докато DNS може още да отговаря от кеша. Променете маршрут и потвърдете, че маршрутизираната заявка се проваля, докато процесът и ръкостискането остават здрави. Счупете само DNS и потвърдете, че проверката на приложението отчита резолюция, а не грешка в тунела. Ако две проверки винаги се движат заедно, имате по-малко проверки, отколкото мислите.

Тествайте посоката на възстановяване със същата дисциплина. След като възстановите слоя, проверката трябва да се изчисти без ръчен рестарт, а действието, което е задействано, не трябва да оставя заобикалящ път. Наблюдавайте един пълен цикъл, преди да се доверите на зеленото състояние, защото проверка, която се изчиства само на ръка, крие счупен път за възстановяване.

Стъпка 5: поставете указанието там, където сочи сигналът

Една страница с пет реда носи целия дизайн: слой, команда, очакван резултат, действие при провал, собственик. Добавете ред за всяка проверка какво умишлено не тества. Точно този ред спира следващия човек да добави шеста проверка, която измерва всичко и не различава нищо. Сложете връзка към страницата в текста на сигнала, иначе никой няма да я отвори, докато инцидентът е активен.

При контейнерни внедрявания условието за зависимост оформя стартирането и нищо друго. Редът на стартиране и условието за състояние в Compose документацията описва как готовността определя реда, в който услугите стартират; никое от това не налага изходяща политика след това и никое не се проваля затворено, когато тунелът падне. Непрекъснатото прилагане изисква собствена политика и собствена проверка, написани на същата страница.

Указанието е готово, когато правилният слой се възстанови, без някой да чете недостъпен сайт като счупен тунел. Това тества документа, не тунела.