Health-checks: три разные проверки, которые зовут одним словом

Что здесь на самом деле спрашивают

Лестница обычно такая:

1. «Зачем нужны проверки здоровья?» — разминка.
2. «Чем liveness отличается от readiness?» — начало содержания.
3. «Что проверять внутри пробы?» — главный вопрос темы.
4. «Почему liveness не должен ходить в базу?» — вопрос про каскад.
5. «Зачем нужна отдельная startup-проба?» — вопрос про медленный старт.
6. «Что будет, если readiness врёт?» — вопрос про обратную ошибку.

Этот урок стоит не на замере, а на модели: у поведения проб нет общего стандарта — есть документация отдельных продуктов. Модель отвечает не на вопрос «сколько именно», а на вопрос «что с чем связано», и допущения у неё названы.

База: три вопроса, а не одна проверка

У сервиса несколько одинаковых реплик, и снаружи не видно, что происходит внутри любой из них. Спросить можно ровно одним способом: постучаться и посмотреть на ответ. Отсюда и берётся проверка здоровья — короткий вопрос, который кто-то задаёт реплике регулярно, и заранее назначенное действие на случай отрицательного ответа.

Вся тема стоит на том, что «здоров ли ты» — это не один вопрос. Действий, на которые способен наблюдатель, несколько, и разные действия чинят разное. Поэтому проверок три, и у каждой свой вопрос:

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

Правая колонка отвечает и на главный вопрос урока: что положить внутрь каждой пробы? Ответ выводится из последствия — проверять надо то, что этим последствием чинится, и ничего больше.

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

Механизм 1: последствие и есть определение

Нормативного документа у этого разделения нет: ниже — различение по последствию, которым урок пользуется как определением. Путаница начинается там, где на все три вопроса отвечают одним обработчиком.

Liveness — «поможет ли перезапуск этого процесса». Отрицательный ответ означает: процесс испорчен настолько, что вернуть его в рабочее состояние может только перезапуск. Взаимоблокировка, исчерпание пула потоков, бесконечный цикл — поломки внутренние и накопительные, и все они лечатся возвратом процесса в известное состояние.

Readiness — «можно ли слать сюда трафик сейчас». Отрицательный ответ означает: не присылайте мне запросы, но перезапускать меня не надо. Прогрев кеша, потеря соединения с зависимостью, временная перегрузка — состояния, из которых реплика выходит сама, если её не нагружать.

Startup — «успел ли подняться». Отдельная проба нужна, чтобы медленный старт не выглядел как смерть. Урок считает, что до успеха startup-пробы liveness не применяется, — в этом и есть смысл отдельной пробы.

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

Механизм 2: что даёт каждая проба

Модель: три реплики, постоянный поток, одна реплика с десятой секунды начинает отвечать медленно — но отвечать.

REQUESTS SERVED SLOWLY OR NOT AT ALL
------------------------------------
                  mode       slow     failed      total
                  none       1600       1000       6000
              liveness        520       1000       6000
    liveness+readiness         80       1000       6000
        liveness-on-db        640       1200       6000

Без проб — 1600 медленных ответов. Балансировщик не знает, что реплике плохо, и продолжает слать ей треть трафика всё время.

Только liveness — 520. Проба замечает беду и перезапускает реплику; перезапуск на пять секунд убирает её из строя, потом она возвращается — и снова деградирует. Помогает, но криво: реплика курсирует между «плохо» и «перезапускается».

Liveness плюс readiness — 80. Реплику выводят из ротации без перезапуска, и нагрузка на неё прекращается. В 6,5 раза меньше медленных ответов, чем при одном liveness.

Отсюда ответ на второй вопрос лестницы: readiness — не «то же самое, но мягче». Это другое последствие, и в случае деградации именно оно уместно: реплика, которую не нагружают, может восстановиться сама, а перезапущенная начинает с холодного старта.

Механизм 3: почему liveness не ходит в базу

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

Её медленные ответы (640) близки к режиму с одним liveness — 520; вся разница ушла в колонку неуспешных, и ею занят этот раздел.

WHAT THE THREE MODES ACTUALLY CHANGE
------------------------------------
  no probes: slow answers                      1600
  liveness only: slow answers                  520
  liveness + readiness: slow answers           80
  liveness tied to the database: failures      1200
  the same failures without that tie           1000

  failures added by tying liveness to the database 200

База лежит десять секунд в обоих прогонах, и эти десять секунд стоят 1000 неуспешных запросов независимо от проб — починить чужую аварию проба не может.

А вот лишние 200 — целиком заслуга пробы. Механизм такой: база недоступна → liveness не проходит у всех реплик одновременно → все реплики перезапускаются → пока они поднимаются, сервис не отвечает вообще, и это продолжается после того, как база уже вернулась.

Отсюда правило, которым стоит отвечать: liveness проверяет только то, что чинится перезапуском этого процесса. База, сеть и соседний сервис перезапуском не чинятся; их место — в readiness, где последствие мягче: реплику перестают нагружать, но она остаётся живой и вернётся сама.

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

Глубже: границы правила и обе ошибки readiness

Обратная ошибка устроена наоборот и стоит в модели больше всего медленных ответов. Readiness, который отвечает «готов» всегда — например, потому что это статический обработчик, возвращающий 200, — превращает балансировщик в слепого: он продолжает слать запросы туда, где их некому обслужить.

Отдельного режима для такого readiness в модели нет; ближайший к нему — режим вообще без проб: 1600 медленных ответов. Балансировщик в обоих случаях одинаково слеп, поэтому число то же. Реплика жива и формально готова, а запросы на неё продолжают идти.

Отсюда практическая проверка, которую стоит называть на собеседовании: readiness обязан отражать способность обслужить запрос, а не факт запуска процесса. Минимальная честная реализация проверяет то, без чего запрос не выполнится: соединение с базой, наличие места в пуле, состояние очереди задач.

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

Здесь и стоит назвать границу правила, симметричную границе для liveness. Из фразы «зависимости живут в readiness» напрашивается вывод «значит, надо перечислить в ней все зависимости» — и это тоже ошибка, просто другая. Readiness отвечает не на вопрос «всё ли вокруг меня в порядке», а на вопрос способна ли эта реплика обслужить хоть какой-то трафик. Сервис, который без второй базы всё ещё отвечает на часть своих запросов, обязан остаться в ротации, когда вторая база недоступна: выведя его, вы превратите частичную деградацию в полный отказ — и сделаете это своими руками, а не аварией.

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

Как отвечать на собеседовании

Короткий ответ: проб три, и различаются они последствием — liveness перезапускает, readiness выводит из ротации, startup откладывает liveness на время запуска. Поэтому вопрос liveness звучит не «жив ли процесс», а «поможет ли перезапуск этого процесса»: внутрь неё попадает только то, что чинится перезапуском, а зависимости — в readiness.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Хороший ответ отличают три вещи. Первая — вы называете цену ошибки числом: в модели liveness, завязанный на базу, добавил 200 неуспешных запросов к тем 1000, что стоила сама авария, потому что перезапустились все реплики сразу. Вторая — вы объясняете, зачем readiness при наличии liveness: перезапуск возвращает реплику в строй снова и снова, а вывод из ротации прекращает нагрузку; в модели 80 медленных ответов против 520. Третья — вы упоминаете обратную ошибку: readiness, который всегда отвечает «готов», делает балансировщик слепым, и это худший случай в модели — 1600.

И одна вещь, на которой легко переусердствовать. Из правила «зависимости — в readiness» не следует, что readiness должен быть суммой всех зависимостей. Точная формулировка звучит так: readiness отвечает на вопрос, способна ли реплика обслужить хоть какой-то трафик — и реплика, которая без одной из зависимостей обслуживает часть запросов, из ротации выходить не должна. Иначе проба сама превращает частичную деградацию в полный отказ, а общая зависимость снова делает все реплики синхронными.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона модели, а не назначен.

none = simulate("none")
liveness = simulate("liveness")
both = simulate("liveness+readiness")
on_db = simulate("liveness-on-db")
print(none["slow"])
print(both["slow"])
print(on_db["failed"] - liveness["failed"])

1600
80
200

1600
80
0

80
1600
200

1600
520
200

Проверка знаний