Как понять, что ваше приложение действительно работает корректно

Вы только что развернули новую версию. Пайплайн зелёный. Артефакт попал в продакшен. И что дальше?

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

Суть вопроса проста: как узнать, что новая версия действительно работает так, как ожидалось, после развёртывания?

Что говорят сигналы здоровья

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

Эти сигналы называются сигналами здоровья (health signals). Это точки данных, которые позволяют определить, работает ли приложение нормально после развёртывания и в процессе непрерывной эксплуатации.

Вот быстрый способ вручную проверить два самых распространённых сигнала здоровья сразу после деплоя:

# Проверка эндпоинта здоровья приложения
curl http://localhost:8080/health

# Ожидаемый вывод (пример):
# {"status":"ok","uptime":"2m34s"}

# Поиск недавних ошибок в логе приложения
grep 'ERROR' /var/log/app.log | tail -20

Сигналы здоровья поступают из нескольких источников, и у каждого своё назначение.

Логи: сырая история произошедшего

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

Когда пользователи начинают сообщать об ошибках, логи — это первое место, куда вы смотрите. Вы открываете файл лога или инструмент поиска, фильтруете по временному окну, когда началась проблема, и идёте назад, чтобы найти, что пошло не так. Логи отвечают на вопрос: «Что произошло прямо перед этой ошибкой?»

Но у логов есть ограничение. Представьте, что вы читаете тысячи строк лога в минуту только для того, чтобы убедиться, что всё нормально. Это непрактично. Логи отлично подходят для отладки, но неэффективны для постоянной оценки состояния.

Метрики: числа, показывающие тренды

Метрики решают проблему объёма, которую создают логи. Вместо чтения отдельных событий вы собираете числовые измерения через равные промежутки времени. Распространённые метрики:

  • Сколько запросов приходит в секунду
  • Среднее время ответа
  • Процент запросов, возвращающих ошибки
  • Использование памяти
  • Загрузка CPU

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

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

Мониторинг: сбор, отображение и оповещение

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

Хорошо настроенный мониторинг делает три вещи:

  1. Собирает логи и метрики из вашего приложения и инфраструктуры
  2. Отображает их на дашбордах, чтобы вы могли видеть текущее состояние с одного взгляда
  3. Оповещает вас, когда что-то выходит за нормальные границы

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

Почему сигналы здоровья важны на раннем этапе

Чем раньше вы обнаружите проблему, тем быстрее сможете отреагировать. Если вы понимаете, что приложение сломалось, только после того, как пользователи заполонили соцсети жалобами, проблема уже существует какое-то время. В контексте CI/CD сигналы здоровья служат этапом верификации после развёртывания. Они отвечают на вопрос: «Действительно ли этот релиз работает в продакшене?»

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

Сигналы здоровья также ловят проблемы, которые проявляются постепенно. Утечка памяти может потребовать часов или дней, чтобы вызвать видимые проблемы. Медленная деградация времени ответа может остаться незамеченной пользователями, пока не превысит порог. Непрерывный мониторинг сигналов здоровья ловит такие медленные проблемы до того, как они повлияют на пользователей.

Практический чек-лист сигналов здоровья

Если вы настраиваете сигналы здоровья впервые, вот минимальный чек-лист для начала:

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

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

Вывод

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