Процесс запущен, но еще прогревает справочники. Балансировщик уже отправляет запросы, которые завершаются ошибкой. Другая крайность — перезапускать здоровый процесс при кратком сбое зависимости. Проверки должны отвечать на разные вопросы о состоянии приложения.
Что подготовить
- Этапы запуска и зависимости, необходимые для обслуживания запросов.
- Возможные зависания процесса и ожидаемое время инициализации.
- Поведение инфраструктуры при отрицательном результате каждой проверки.
Порядок работы
- Разделите сигнал завершения запуска, готовности принимать трафик и способности процесса продолжать работу.
- Для готовности проверяйте только условия, без которых запрос действительно нельзя обслужить.
- Сделайте проверки легкими и ограниченными по времени, чтобы они сами не создавали нагрузку.
- Определите поведение при остановке: сначала прекратить новый трафик, затем завершить активные запросы в пределах срока.
- Смоделируйте медленный запуск, недоступность зависимости и зависание обработчика; проверьте фактические действия инфраструктуры.
Разобранный пример
Сервис может читать каталог из локального снимка даже при недоступном источнике обновлений. Поэтому временный сбой обновления не обязательно означает неготовность обслуживать чтение. Проверка отражает реальную способность маршрутов работать, а отдельная метрика сообщает об устаревании снимка.
Как проверить результат
- Трафик не поступает до завершения обязательной инициализации.
- Краткий внешний сбой не вызывает бесконечный цикл бесполезных перезапусков.
- При остановке активные запросы завершаются или получают предусмотренную ошибку.
Если что-то пошло не так
Если проверки нестабильны, изучите их стоимость и зависимость от общего пула ресурсов. Не увеличивайте пороги без понимания длительности нормальных состояний. Слишком широкая проверка может одновременно исключить все экземпляры при общей проблеме.
Матрица состояний экземпляра
Составьте строки для четырех состояний: инициализация, обычная работа, временная потеря зависимости и завершение. В колонках укажите ответы проверок и ожидаемое действие системы управления. Такая матрица обнаруживает противоречие, когда одна проверка просит исключить экземпляр из трафика, а другая одновременно вызывает его перезапуск без возможности закончить инициализацию.
Проверьте стоимость сигналов при большом числе экземпляров. Даже короткий запрос, запускаемый часто со всех узлов, может создавать заметный поток к общей зависимости. Сигнал должен отражать полезное состояние без выполнения тяжелой бизнес-операции. Если результат кешируется, укажите допустимую свежесть и поведение после ее истечения.
Для завершения запишите порядок: объявить неготовность, дождаться прекращения новых запросов, завершить активные операции и освободить ресурсы. Проверьте запрос, начатый непосредственно перед сменой готовности. Если срок завершения истек, определите ожидаемый результат клиента и возможность безопасного повтора. Отдельно проверьте, что служебный маршрут доступен в нужной сети и не раскрывает внутренние подробности публичному пользователю. Успешный ответ проверки должен быть связан с конкретным смыслом; фраза «все хорошо» без определения проверяемого свойства не позволяет интерпретировать отказ.
Промпт для разбора ваших материалов
По жизненному циклу сервиса предложи отдельные сигналы запуска, готовности и работоспособности. Для каждого укажи проверяемое условие, стоимость, срок и действие при отказе. Добавь сценарии остановки и общей недоступности зависимости.Частые вопросы
Нужен ли запрос к базе в каждой проверке?
Только если это необходимо для смысла конкретного сигнала. Частые тяжелые проверки могут ухудшить состояние базы.
Можно ли возвращать успешный ответ всегда?
Такой сигнал подтверждает лишь работу маршрута и не защищает от подачи трафика неготовому экземпляру.
Материал библиотеки решений Ильи Тарасова / TarasovWeb.
О проекте
Практическая библиотека Ильи Тарасова и TarasovWeb. Telegram-канал · Личная страница · ВКонтакте.
#tarasovweb #ИльяТарасов