Разделите проверки работоспособности VPN и приложения

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

Шаг 1: назовите уровень, который наблюдает каждая проверка

Спросите, что каждая проверка действительно видит, прежде чем писать хотя бы одну из них. Живость доказывает, что демон работает, рукопожатие или список пиров доказывает, что связь существует, маршрутизированный запрос доказывает доставку, а запрос имён доказывает разрешение. Они отказывают именно в этом порядке, и ни одна не подразумевает следующую. Зелёная проверка процесса рядом с мёртвым туннелем — это обычный случай, а не противоречие.

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

Затем добавьте проверку приложения пятым, отдельным пунктом. Страница, у которой служба учётных записей не работает, не оправдывает перезапуск туннеля.

Шаг 2: свяжите каждый сбой с одним действием

Для каждой проверки решите, что перезапускается, что остаётся заблокированным и что вызывает человека. Сбой уровня туннеля может оправдать перезапуск туннеля; сбой резолвера указывает на интеграцию DNS на клиенте; сбой уровня приложения почти никогда не должен касаться туннеля.

Скажите, чего сбой делать не должен, потому что опасные значения по умолчанию — это разрешающие. Нездоровое состояние никогда не должно становиться разрешением на прямой трафик приложения, поскольку резервный путь, тихо обходящий туннель, убирает причину существования туннеля. Сузьте и действия: перезапуск общего компонента из-за того, что одно назначение медленное, превращает местную проблему в проблему всего парка. Это также уничтожает доказательства, нужные вам для поиска причины.

Шаг 3: держите проверки безвредными и дешёвыми

Используйте небольшие запросы только для чтения: статический ресурс, эндпоинт состояния, сообщающий о своей зависимости, или TCP-подключение к порту, которым вы управляете. Избегайте учётных данных, приватного просмотра и всего, что меняет состояние на каждом интервале, потому что пишущая проверка — это нагрузочный тест по расписанию.

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

Шаг 4: сломайте каждый уровень и посмотрите, покраснеет ли нужная проверка

Остановите процесс туннеля и убедитесь, что проверка процесса отказывает, пока DNS ещё может отвечать из кэша. Измените маршрут и убедитесь, что маршрутизированный запрос отказывает, пока процесс и рукопожатие остаются здоровыми. Сломайте только DNS и убедитесь, что проверка приложения сообщает о разрешении, а не об ошибке туннеля. Если две проверки всегда двигаются вместе, у вас меньше проверок, чем вы думаете.

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

Шаг 5: положите инструкцию туда, куда указывает оповещение

Одна страница с пятью строками несёт весь замысел: уровень, команда, ожидаемый результат, действие при сбое, владелец. Добавьте для каждой проверки строку о том, что она намеренно не проверяет. Именно эта строка мешает следующему человеку добавить шестую проверку, которая измеряет всё и не различает ничего. Свяжите страницу из текста оповещения, иначе никто не откроет её, пока инцидент идёт.

В контейнерных развёртываниях условие зависимости формирует запуск и ничего больше. Порядок запуска и условие здоровья в Compose документация описывает, как готовность определяет порядок запуска служб; ничто из этого потом не навязывает исходящую политику, и ничто не отказывает закрыто, когда туннель падает. Непрерывное принуждение требует собственной политики и собственной проверки, написанных на той же странице.

Инструкция готова, когда нужный уровень восстанавливается без того, чтобы кто-то читал недоступный сайт как сломанный туннель. Это проверяет документ, а не туннель.