Что отслеживать после каждого развертывания: пять сигналов, которые покажут, что новая версия работает стабильно
Вы только что выкатили новую версию. Пайплайн зелёный. Команда смотрит на дашборд. Но действительно ли приложение работает хорошо для пользователей?
Без конкретных сигналов вы гадаете. Гадание может сработать, если приложением пользуетесь только вы. Но когда от него зависят другие люди, нужны данные. Нужно в течение нескольких минут понять, стабильна новая версия или сломана.
Вот пять базовых сигналов, которые каждой команде стоит отслеживать после развертывания. Начните с одного-двух, затем добавляйте остальные со временем.
Доступность: могут ли пользователи достучаться до приложения?
Самый простой вопрос после деплоя: доступно ли приложение? Если сервер упал, приложение упало при старте или порт не открыт, доступность падает до нуля.
Обычно команды отслеживают это через эндпоинт health check. Это специальный URL, который приложение предоставляет только для ответа «я жив?». Инструменты мониторинга регулярно стучатся на этот эндпоинт. Если он перестаёт отвечать — что-то не так.
Доступность обычно измеряется в процентах: 99%, 99,9% или 99,99% ожидаемого аптайма. Чем выше цель, тем меньше у вас допуска на перерывы. Цель 99% означает примерно 7 часов простоя в месяц. Цель 99,99% — около 4 минут в месяц.
Чтобы проверить доступность сразу после деплоя, выполните простую команду curl к вашему health-эндпоинту:
curl -f http://localhost:8080/health && echo "OK" || echo "FAIL"
Флаг -f заставляет curl вернуть ненулевой код возврата, если HTTP-ответ содержит ошибку (4xx или 5xx). Нулевой код означает, что эндпоинт доступен и здоров. Это можно использовать в скрипте деплоя, чтобы автоматически решить: продолжать или откатывать.
После деплоя сначала проверяйте доступность. Если приложение недоступно, всё остальное не имеет значения.
Частота ошибок: сколько запросов завершаются сбоем?
Приложение может быть живо, но сломано. Каждый входящий запрос может завершаться ошибкой. Частота ошибок показывает, сколько запросов заканчиваются кодом ошибки, например HTTP 500 или таймаутом.
До деплоя вы должны знать базовую частоту ошибок. Допустим, это 0,5% всех запросов. После деплоя, если это число подскочило до 5%, значит, в новой версии что-то вызывает сбои.
Всплески частоты ошибок часто становятся первой тревогой, что что-то пошло не так. Их легко заметить, и они обычно указывают на реальную проблему. Резкий рост ошибок должен вызывать немедленное расследование, а не «давайте подождём и посмотрим».
Задержка: как быстро приложение отвечает?
Пользователи не любят ждать. Если страница, которая раньше загружалась за секунду, теперь грузится пять секунд, пользователи уйдут. Задержка (latency) измеряет, как быстро приложение отвечает на запросы.
Задержка может расти по разным причинам. Новый код может быть медленнее. Пул соединений с базой данных может быть заполнен. Сервер может быть перегружен трафиком. Какова бы ни была причина, высокая задержка напрямую ухудшает пользовательский опыт.
Нужно знать нормальный диапазон задержки до деплоя. После деплоя сравните цифры. Если среднее время ответа удвоилось, что-то изменилось. Даже небольшое увеличение задержки может указывать на проблемы, которые усугубятся при большей нагрузке.
Насыщенность: насколько заполнены ваши ресурсы?
У любой системы есть пределы. CPU, память, дисковое пространство, соединения с БД, пулы потоков, пропускная способность сети — у всего есть потолок. Насыщенность (saturation) показывает, насколько вы близки к этим пределам.
После деплоя следите за использованием ресурсов. Если загрузка CPU выросла с 40% до 90%, новая версия потребляет больше ресурсов. Это может быть нормально, если у вас есть запас. Но если трафик позже вырастет, эти 90% превратятся в 100%, и приложение замедлится или упадёт.
Насыщенность также помогает с планированием мощностей. Если сервер постоянно загружен на 80%, вероятно, нужно добавить ещё один сервер до следующего пика трафика. Мониторинг насыщенности после деплоя показывает, изменил ли новый релиз ресурсный профиль вашего приложения.
Логи: что на самом деле произошло внутри?
Не всё можно выразить числом. Когда частота ошибок взлетает, нужно понять почему. Тут приходят на помощь логи. Логи — это записи событий, которые приложение пишет во время работы.
Хорошие логи имеют уровни: info для нормальной работы, warning для необычных, но не критичных событий, error для сбоев. У них также есть контекст: временная метка, ID запроса, имя функции и релевантные данные. Без контекста логи — просто шум.
Когда после деплоя что-то идёт не так, логи — первое место, куда стоит заглянуть. Появилось ли конкретное исключение? Привел ли определённый ввод к падению? Не отвечает ли база данных? Логи рассказывают историю, которую цифры сами по себе рассказать не могут.
Начинайте с малого, будьте последовательны
Вам не нужно мониторить все пять сигналов с первого дня. Начните с доступности и частоты ошибок. Эти два поймают большинство проблем. Добавьте задержку, когда понадобится понимать производительность. Добавьте насыщенность, когда начнёте планировать мощности. Добавьте логи, когда нужно будет отлаживать более глубокие проблемы.
Важна последовательность. Каждый деплой должен измеряться одинаково. Используйте тот же health check эндпоинт. Собирайте частоту ошибок из того же источника. Измеряйте задержку теми же инструментами. Только тогда вы сможете честно сравнивать версии: новая версия лучше старой или хуже?
Эти пять сигналов дают вам данные вместо ощущений. Данные подсказывают: продолжать, откатывать или расследовать дальше.
Краткий чек-лист для мониторинга после деплоя
- Health check эндпоинт отвечает
- Частота ошибок не значительно выше базовой
- Средняя задержка в пределах нормы
- Загрузка CPU, памяти и диска не接近 к пределу
- В логах нет неожиданных ошибок или исключений
Что дальше
Эти сигналы говорят, стабильно ли приложение, но не говорят, работает ли новая функция так, как ожидалось. Версия может иметь идеальную доступность, низкую частоту ошибок, быструю задержку — и всё равно выдавать неверный результат. Для этого нужна верификация.
Но прежде чем перейти к ней, убедитесь, что эти пять сигналов настроены. Без них вы летите вслепую. С ними у вас есть фундамент, чтобы знать, что происходит после каждого деплоя.