Что считать здоровым развертыванием для приложений, баз данных и инфраструктуры

Когда развертывание завершено, как вы узнаете, что оно действительно сработало? Не статус пайплайна. Не зеленая галочка. Не сообщение "deploy successful" в Slack. Настоящий вопрос в другом: делает ли то, что вы развернули, то, что должно?

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

Проверка развертывания приложения

Начните с самого простого вопроса: запущен ли процесс приложения и принимает ли он соединения? Это аналог проверки, включен ли сервер. Вы можете обратиться к простому health endpoint и ожидать ответ 200. Если вы его получили, приложение живо.

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

flowchart TD subgraph App[Приложение] A1[Health check] --> A2[Smoke-тесты] A2 --> A3[Синтетические транзакции] A3 --> A4{Все прошло?} A4 -->|Да| A5[Здорово] A4 -->|Нет| A6[Откат] end subgraph DB[База данных] D1[Проверка миграции] --> D2[Проверка целостности данных] D2 --> D3[Проверка производительности запросов] D3 --> D4{Все прошло?} D4 -->|Да| D5[Здорово] D4 -->|Нет| D6[Откат] end subgraph Infra[Инфраструктура] I1[Валидация конфигурации] --> I2[Тест связности] I2 --> I3[Проверка лимитов ресурсов] I3 --> I4{Все прошло?} I4 -->|Да| I5[Здорово] I4 -->|Нет| I6[Откат] end

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

Вот почему проверка приложения должна быть глубже. Запустите smoke-тесты, которые вызывают несколько endpoint'ов последовательно. Сымитируйте синтетическую транзакцию, повторяющую действия реального пользователя: войти, найти что-то, отправить форму, выйти. Если этот синтетический сценарий успешен, у вас есть более веские доказательства того, что приложение действительно функционально, а не просто запущено.

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

Вот практический пример health check и скрипта синтетической транзакции, которые можно запустить после развертывания:

# Health check: проверяем, живо ли приложение
if curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health | grep -q "200"; then
  echo "Health check passed"
else
  echo "Health check failed"
  exit 1
fi

# Smoke test: имитируем основной пользовательский сценарий (логин, поиск, отправка)
#!/bin/bash
set -euo pipefail

BASE_URL="http://localhost:8080"

# Шаг 1: Логин
LOGIN_RESPONSE=$(curl -s -X POST "$BASE_URL/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"testuser","password":"testpass"}')
TOKEN=$(echo "$LOGIN_RESPONSE" | jq -r '.token')

# Шаг 2: Поиск
SEARCH_RESPONSE=$(curl -s "$BASE_URL/search?q=test&date_from=2024-01-01" \
  -H "Authorization: Bearer $TOKEN")
if ! echo "$SEARCH_RESPONSE" | jq -e '.results | length > 0' > /dev/null; then
  echo "Search returned no results"
  exit 1
fi

# Шаг 3: Отправка формы
SUBMIT_RESPONSE=$(curl -s -X POST "$BASE_URL/submit" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"test","content":"test content"}')
if ! echo "$SUBMIT_RESPONSE" | jq -e '.id' > /dev/null; then
  echo "Form submission failed"
  exit 1
fi

echo "Smoke test passed"

Проверка изменений в базе данных

Базы данных не говорят на HTTP. Вы не можете просто пинговать endpoint БД и получать ответ 200. Проверка базы данных касается изменений схемы, модификации индексов, хранимых процедур и обновлений справочных данных. Вопрос в том: выполнилась ли миграция без ошибок и сломала ли она что-то, что работало раньше?

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

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

Распространенная ошибка — относиться к проверке базы данных как к одноразовой процедуре. Изменения в БД могут иметь тонкие эффекты, которые проявляются только под нагрузкой продакшена. Новый индекс может ускорить один запрос, но замедлить другой. Изменение схемы может отлично работать с тестовыми данными, но вызывать проблемы с блокировками при реальных объемах данных. Вот почему проверка базы данных должна включать как функциональные проверки, так и проверки производительности, даже если последние — это просто сравнение с базовыми показателями.

Проверка изменений инфраструктуры

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

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

Эти проверки часто нужно запускать извне самой инфраструктуры. Вы не можете проверить внешнюю связность изнутри сети. Используйте скрипты или инструменты, которые имитируют соединения извне. Пингуйте endpoint'ы. Проверяйте дату истечения сертификата. Убедитесь, что DNS-резолвинг возвращает правильные IP-адреса.

Изменения инфраструктуры также имеют каскадные эффекты. Изменение одной DNS-записи может повлиять на несколько сервисов. Обновление одного правила файрвола может заблокировать трафик, который ранее был разрешен. Вот почему проверка инфраструктуры должна включать карту связности: список всех соединений, которые должны работать, и тест для каждого из них.

Общий принцип

Хотя методы проверки различаются, принцип един: каждое развертывание должно оставлять доказательства того, что развернутый объект функционирует корректно. Доказательством может быть запись в логе об успешной миграции, HTTP-ответ, показывающий, что приложение может обслуживать запросы, или результат пинга, показывающий, что сервер доступен. Без доказательств вы не знаете, удалось ли развертывание. Вы знаете только, что пайплайн завершился.

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

Используйте это как отправную точку, а не окончательный список. Адаптируйте под свои конкретные системы.

  • Приложение: health endpoint возвращает 200, синтетическая транзакция для основного пользовательского сценария успешна, критические внешние зависимости (БД, кеш, API) доступны.
  • База данных: скрипт миграции выполняется без ошибок, тестовые запросы возвращают корректные результаты, производительность запросов в пределах допустимого, скрипт отката работает в staging.
  • Инфраструктура: проверена связность между всеми зависимыми компонентами, TLS-сертификаты валидны и не истекают в ближайшее время, DNS-резолвинг возвращает корректные записи, правила файрвола разрешают необходимый трафик.

Когда развертывание действительно завершено?

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

Именно эти доказательства отличают развертывание, которое произошло, от развертывания, которое удалось.