Первая неделя у нового банковского клиента. Я задал вопрос, который считал разминочным: «А где health check?» В комнате на секунду повисла пауза. Оказалось, health check в Azure App Service не было настроено нигде — двадцать шесть App Service крутятся в проде, проводят реальные транзакции, обслуживают живых клиентов, и ни у одного нет настроенного health check endpoint. В банке. Платформа просто считала, что всё здорово.
Надежда — это не стратегия.
Разница между «работает» и «отвечает»
Вот что упускает большинство дашбордов. Между «сервер поднят» и «приложение реально работает» — пропасть. Инстанс App Service может быть запущен, процесс жив, график CPU идеально спокоен — а приложение внутри отдаёт 500 на каждый запрос. Без health probe этого никто не замечает. Балансировщик всё так же бодро шлёт трафик на мёртвый инстанс. Пользователи всё так же ловят ошибки. А в банке ошибка — это не пустая страница, это не прошедший платёж, зависшая транзакция, клиент, который смотрит в экран и не понимает, что вообще произошло.
Это зомби-инстансы: по всем грубым метрикам живые, по единственной важной — мёртвые. И самое паршивое — как ты об этом узнаёшь. Не из графика, не из алерта, а из звонка клиента. К моменту, когда живой человек руками лезет разбираться, ущерб уже считается в реальных деньгах и реальном доверии.
Почему я не стал просто щёлкнуть тумблером
Звучит-то просто: настроил health check endpoint — и готово. В банковской среде так не бывает, и правильно, что не бывает. Инфраструктуру платёжных систем не катят «на авось». Поэтому я раскатывал не одним махом, а в пять этапов.
- Этап 1 — сначала самые тихие, наименее критичные сервисы, чисто чтобы обкатать паттерн.
- Этап 2 — внутренние API, где ошибка остаётся внутри периметра.
- Этап 3 — сервисы среднего уровня.
- Этап 4 — то, что видит клиент.
- Этап 5 — и только теперь критичные банковские нагрузки.
Каждый этап проходил через Change Advisory Board с расписанным планом отката ещё до того, как я вообще что-то трогал. Это не бюрократия ради бюрократии — именно она позволяет двигаться уверенно там, где радиус поражения включает чужие деньги. К критичным нагрузкам я подошёл, когда паттерн уже четырежды доказал, что работает.
Policy, а не страничка в вики
Раскатка probes закрыла настоящее. Будущее — нет. Через полгода кто-то поднимет App Service номер двадцать семь, забудет про health check — и слепое пятно возвращается. Документация это не лечит. Страница «best practices» в вики — это кладбище хороших намерений.
Поэтому больше всего я горжусь не раскаткой, а тем, что было после. Я настроил Azure Policy, которая требует health check прямо на этапе деплоя. Не совет, а реальный барьер. Деплоишь новый App Service без health check — деплой автоматически помечается как нарушение. Плюс теперь автоматически подменяется нездоровый инстанс в тот самый момент, когда probe падает: платформа убирает битый инстанс и поднимает свежий. Команда узнаёт о проблеме от системы, а не из жалобы клиента.
Результат, который остаётся
Двадцать шесть сервисов. Пять этапов. Ноль даунтайма, ноль инцидентов. Но цифра, которая мне по-настоящему дорога, в слайд не помещается: с этого момента каждый новый App Service рождается здоровым. Не потому что инженер вспомнил про probe, а потому что система не даёт забыть. Знание перестало жить в одной голове и переехало в саму платформу.
Вот в этом и урок тех двадцати шести сервисов. Health check — это не «сделаю, когда дойдут руки». Это разница между «узнал из мониторинга» и «узнал от клиента». А единственный health check, который реально существует, — тот, без которого policy отказывается деплоить.
Поэтому оставлю вас с тем же вопросом, что задал в той комнате на первой неделе: сколько ваших продовых сервисов прямо сейчас имеют настоящий health check — и что вас страхует, когда следующий человек про него забудет?