Что проверять после деплоя — зависит от того, что именно вы развернули

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

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

Приложения: смотрите, как обрабатываются запросы

Когда вы деплоите новую версию приложения, важнее всего понять, корректно ли оно обрабатывает пользовательские запросы. Две метрики дадут ответ быстрее всего: уровень ошибок и задержка.

Уровень ошибок показывает, сколько запросов завершаются сбоем. Если после деплоя он резко вырос — что-то пошло не так. Причина может быть в баге в новом коде, несоответствии конфигурации или несовместимости с продакшен-окружением. В любом случае пользователи сталкиваются с ошибками, и вы должны узнать об этом немедленно.

Задержка (latency) показывает, сколько времени приложение отвечает на запросы. Внезапное увеличение задержки означает, что новая версия работает медленнее. Возможно, она потребляет больше ресурсов, упирается в узкое место или делает неэффективные вызовы к нижестоящим сервисам. Пользователи могут не видеть ошибок, но они почувствуют тормоза — а это не менее опасно.

Пропускная способность (throughput) — ещё один полезный сигнал, особенно для приложений с большим количеством пользователей. Она измеряет, сколько запросов приложение обрабатывает в единицу времени. Если пропускная способность падает, а число пользователей остаётся прежним — новая версия менее эффективна. Что-то в коде замедляет работу, даже если уровень ошибок и задержка выглядят нормально.

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

Следующая блок-схема показывает, какие метрики проверять в первую очередь в зависимости от типа деплоя:

flowchart TD Start([Деплой выполнен]) --> Type{Тип деплоя?} Type -->|Приложение| App[Проверить метрики приложения] Type -->|База данных| DB[Проверить метрики БД] Type -->|Инфраструктура| Infra[Проверить метрики инфраструктуры] App --> App1[Уровень ошибок] App --> App2[Задержка] App --> App3[Пропускная способность] DB --> DB1[Задержка репликации] DB --> DB2[Производительность запросов] DB --> DB3[Количество соединений] DB --> DB4[Размер журнала транзакций] Infra --> Infra1[Состояние узлов] Infra --> Infra2[CPU и память] Infra --> Infra3[Дисковое пространство] Infra --> Infra4[Сетевая задержка]

Базы данных: проверяйте репликацию, запросы и соединения

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

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

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

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

Размер журнала транзакций — менее очевидный, но важный сигнал. Базы данных пишут логи для каждого изменения. Если деплой меняет способ записи данных приложением, журнал может расти быстрее обычного. Без своевременной очистки он может заполнить диск и остановить базу данных. У команд DBA обычно есть безопасный порог размера журнала. Если он превышен — нужно действовать.

Инфраструктура: начинайте с состояния узлов

Инфраструктурные деплои включают изменения серверов, контейнеров, сетей или облачных ресурсов. Первый сигнал для проверки — состояние узла. Жив ли сервер или контейнер? Использование CPU и памяти в норме? Не заполняется ли диск?

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

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

Сигналы взаимосвязаны, но начинайте с одного

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

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

Практический чек-лист для проверки после деплоя

  • Для деплоев приложений: проверьте уровень ошибок, задержку и пропускную способность в первые пять минут.
  • Для деплоев баз данных: проверьте отставание репликации, медленные запросы, количество соединений и размер журнала транзакций.
  • Для деплоев инфраструктуры: проверьте состояние узлов, использование CPU и памяти, дисковое пространство и сетевую задержку.
  • Если один сигнал выглядит аномально, проверьте связанные сигналы на других уровнях, чтобы найти реальную причину.

Вывод

Не используйте один и тот же дашборд для каждого деплоя. Значимые сигналы зависят от того, что именно вы изменили. Приложениям нужны метрики уровня запросов. Базам данных — метрики уровня данных. Инфраструктуре — метрики ресурсов и сети. Знайте, за какими сигналами следить для каждого типа деплоя, и вы поймаете проблемы до того, как их заметят пользователи.