Відокремте перевірки стану VPN від перевірок стану застосунку

Процес тунелю може працювати, поки захищене з’єднання непридатне, а сторінка, що не завантажується, не є доказом того, що тунель зламався. Коли одна перевірка замінює всі інші, політика перезапуску перезапускає не той компонент і називає це автоматизацією. Кожна перевірка нижче називає рівень, який вона спостерігає, дію, яку запускає її збій, і доказ того, що дія спрацювала. Останній крок перетворює весь набір на сторінку, за якою хтось може йти о третій ночі.

Крок 1: назвіть рівень, який спостерігає кожна перевірка

Запитайте, що кожна перевірка справді бачить, перш ніж писати хоч одну з них. Живучість доводить, що демон працює, рукостискання або список пірів доводить, що зв’язок існує, маршрутизований запит доводить доставку, а запит імен доводить розв’язання. Вони відмовляють саме в цьому порядку, і жодна не передбачає наступну. Зелена перевірка процесу поруч із мертвим тунелем — це звичайний випадок, а не суперечність.

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

Потім додайте перевірку застосунку п’ятим, окремим пунктом. Сторінка, у якої служба облікових записів не працює, не виправдовує перезапуск тунелю.

Крок 2: прив’яжіть кожен збій до однієї дії

Для кожної перевірки вирішіть, що перезапускається, що залишається заблокованим і що викликає людину. Збій рівня тунелю може виправдати перезапуск тунелю; збій резолвера вказує на інтеграцію DNS на клієнті; збій рівня застосунку майже ніколи не повинен торкатися тунелю.

Скажіть, чого збій робити не повинен, бо небезпечні значення за замовчуванням — це ті, що дозволяють. Не здоровий стан ніколи не повинен ставати дозволом на прямий трафік застосунку, оскільки резервний шлях, який тихо обходить тунель, прибирає причину існування тунелю. Звужте й дії: перезапуск спільного компонента через те, що одне призначення повільне, перетворює місцеву проблему на проблему всього парку. Це також знищує докази, потрібні вам для пошуку причини.

Крок 3: тримайте перевірки нешкідливими та дешевими

Використовуйте невеликі запити лише для читання: статичний ресурс, кінцеву точку стану, що повідомляє про власну залежність, або TCP-з’єднання до порту, яким ви керуєте. Уникайте облікових даних, приватного перегляду та всього, що змінює стан на кожному інтервалі, бо перевірка, що пише, — це навантажувальний тест за розкладом.

Записуйте призначення, очікування маршруту та тайм-аут для кожної перевірки. Очікування маршруту — те поле, яке люди пропускають, і саме воно відокремлює збій тунелю від помилки маршрутизації, коли ви пізніше читаєте оповіщення. Виводьте інтервал і поріг збою з обіцяного часу відновлення і тримайте тайм-аут коротшим за інтервал. Перевірка, що ще виконується, коли починається наступна, повідомляє про один збій двічі і виглядає як мерехтіння.

Крок 4: зламайте кожен рівень і подивіться, чи червоніє потрібна перевірка

Зупиніть процес тунелю і підтвердіть, що перевірка процесу відмовляє, поки DNS ще може відповідати з кешу. Змініть маршрут і підтвердіть, що маршрутизований запит відмовляє, поки процес і рукостискання залишаються здоровими. Зламайте лише DNS і підтвердіть, що перевірка застосунку повідомляє про розв’язання, а не про помилку тунелю. Якщо дві перевірки завжди рухаються разом, у вас менше перевірок, ніж ви думаєте.

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

Крок 5: покладіть інструкцію туди, куди вказує оповіщення

Одна сторінка з п’ятьма рядками несе весь задум: рівень, команда, очікуваний результат, дія при збої, власник. Додайте для кожної перевірки рядок про те, чого вона навмисно не перевіряє. Саме цей рядок заважає наступній людині додати шосту перевірку, яка вимірює все і не розрізняє нічого. Зв’яжіть сторінку з тексту оповіщення, інакше ніхто не відкриє її, поки триває інцидент.

У контейнерних розгортаннях умова залежності формує запуск і нічого більше. Порядок запуску та умова здоров’я в Compose документація описує, як готовність визначає порядок запуску служб; ніщо з цього потім не нав’язує вихідну політику, і ніщо не відмовляє закрито, коли тунель падає. Безперервне примушування потребує власної політики та власної перевірки, написаних на тій самій сторінці.

Інструкція готова, коли потрібний рівень відновлюється без того, щоб хтось читав недоступний сайт як зламаний тунель. Це перевіряє документ, а не тунель.