Новый экземпляр приложения открыл сетевой порт, и платформа включила его в обслуживание. Только справочник ещё загружается, конфигурация не проверена, а первый пользователь получает ошибку. Через минуту приложение начнёт работать нормально. Но зачем было отправлять к нему людей раньше?
Health check — проверка состояния, на основании которой инфраструктура принимает решение. Сам по себе зелёный ответ ничего не гарантирует. Важно, какой вопрос задали приложению и что система сделает, если ответ окажется отрицательным.
Три проверки с разными последствиями
Liveness помогает обнаружить состояние, из которого процесс не восстанавливается сам: например, зависший обработчик. Неуспешная проверка после установленного порога может привести к перезапуску контейнера. Поэтому здесь нужен признак, при котором перезапуск имеет смысл, а не просто сообщение «сейчас есть ошибки».
Readiness показывает, можно ли направлять экземпляру новую пользовательскую работу. Процесс может быть исправен, но ещё не готов или временно не способен обслуживать нужный сценарий. Удаление из обычного потока запросов не равно перезапуску и не обязано прерывать уже установленные соединения.
Startup выделяет время на начальную подготовку. В Kubernetes при наличии startup probe проверки liveness и readiness ждут её успешного завершения. При этом запуск не должен продолжаться бесконечно: нужен предел, после которого явно не стартовавший контейнер будет обработан согласно политике перезапуска. Эти различия описаны в документации Kubernetes; у другой платформы названия и действия могут отличаться.
Что исправит перезапуск, если недоступен поставщик?
Представим, что liveness проверяет внешний сервис расчёта тарифов. Поставщик ненадолго перестал отвечать, все экземпляры приложения признаны неисправными и перезапущены. Тарифный сервис от этого не восстановился. Зато приложение потеряло прогретые данные и теперь повторно устанавливает подключения под той же нагрузкой.
Внешняя зависимость может входить в диагностику, но её отказ не должен автоматически означать неисправность самого процесса. Особенно опасно связать один и тот же глубокий тест и с выводом из трафика, и с перезапуском: две разные реакции начинают выполняться по одному сигналу.
С readiness решение тоньше. Если экземпляр потерял собственное подключение к обязательной базе, направлять клиентов на другие экземпляры разумно. Если база недоступна всем, исключение всех получателей не восстановит её. Нужно заранее определить поведение сервиса: контролируемый отказ критической операции, сохранение доступных функций или полное прекращение приёма запросов. Общего правила «никогда не проверять зависимости» здесь тоже нет.
Дешёвая проверка должна проверять нужное
Статическая страница с ответом «OK» может продолжать открываться, пока основной обработчик уже завис. Но и полный пользовательский сценарий при каждом обращении платформы — плохая замена: проверка начнёт занимать соединения и конкурировать с настоящими клиентами.
Полезно разделить локальную готовность и более глубокую диагностику. Частая проверка должна быть короткой, ограниченной по времени и осмысленно связанной с обслуживанием запросов. Подробное исследование зависимостей можно выполнять отдельно и с другой частотой. Нельзя случайно создавать реальные заказы или менять рабочие данные ради доказательства здоровья.
Частоту тоже нужно считать для всей группы экземпляров. Недорогой запрос, повторённый каждой проверяющей системой на каждой машине, способен стать заметной нагрузкой. При этом публичный ответ не обязан раскрывать адреса внутренних узлов, секреты и подробные ошибки подключения.
Во время обновления важна последовательность
Новый экземпляр сначала готовят, затем допускают к работе. Уходящий перестаёт принимать новые запросы и завершает уже принятые в отведённое время. Изменение readiness не распространяется мгновенно, поэтому само приложение должно корректно переживать переходный период.
Один неудачный ответ проверки ещё не обязательно означает устойчивый отказ. Порог неудач, период проверки и время ожидания должны учитывать обычные паузы процесса. Слишком агрессивные настройки способны убрать мощность именно тогда, когда оставшимся экземплярам и так тяжело. Слишком мягкие надолго оставят неисправный узел в потоке.
Подробности настройки приведены в руководстве по probes. Для руководителя важнее результат: обновление не должно создавать заметную очередь ошибок из-за преждевременного включения или выключения мощности.
Зелёная инфраструктура может обслуживать сломанный продукт
Корректная readiness не доказывает, что покупка, поиск или согласование проходят целиком. Для этого нужны наблюдение за клиентским результатом и отдельные сквозные проверки. Их не обязательно использовать как повод немедленно перезапускать каждое приложение: ошибка может находиться в общей конфигурации или данных.
На проверке полезно отдельно замедлить запуск, нарушить связь одного экземпляра с зависимостью, остановить общий внешний сервис и воспроизвести локальное зависание. Важно увидеть разные, ожидаемые реакции. Если все четыре ситуации заканчиваются одинаковым массовым перезапуском, система пока не различает причины отказа, а просто быстро повторяет одно действие.