Когда развертывание можно считать завершенным?

Вы только что выполнили команду деплоя. Терминал показывает чистый зеленый вывод. Никаких ошибок. Никаких предупреждений. Новый контейнер запущен. Файлы на месте. Ваша команда начинает собираться домой.

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

Большинство команд считают финишной чертой момент завершения команды деплоя. Это опасное предположение. В этот момент вы знаете только то, что процесс перемещения файлов или перезапуска сервисов завершился успешно. Вы еще не знаете, работает ли приложение на самом деле.

Разница между деплоем и работоспособностью

Развертывание состоит из двух четких фаз. Первая — техническое действие по размещению новой версии. Вторая — проверка того, что новая версия ведет себя корректно. Многие команды останавливаются после первой фазы и считают день завершенным.

Следующая диаграмма иллюстрирует описанный выше двухфазный процесс:

flowchart TD A[Фаза деплоя] --> B[Перемещение файлов / перезапуск сервисов] B --> C[Деплой успешен] C --> D[Фаза верификации] D --> E[Дымовые тесты] E --> F[Синтетические транзакции] F --> G[Сигналы мониторинга] G --> H[Частота ошибок, задержка, ресурсы] H --> I[Собраны доказательства] I --> J[Развертывание завершено] C -.->|Не завершено| K[Развертывание НЕ завершено] style J fill:#a3d9a5 style K fill:#f4a3a3

Подумайте, что может пойти не так после успешного деплоя:

  • В новом коде есть ошибка конфигурации, которая проявляется только под реальной нагрузкой
  • Миграция базы данных прошла успешно, но код приложения ожидает другое имя столбца
  • Обновилась зависимость, которая сломала интеграцию, не покрытую модульными тестами
  • Новая версия потребляет больше памяти и через несколько минут запускает OOM-killer

Ни одна из этих проблем не отобразится в логах деплоя. Терминал по-прежнему покажет "deploy successful". Но приложение будет сломано.

Что считать доказательством

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

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

Вот минимальный скрипт, который автоматизирует первый уровень сбора доказательств после деплоя:

#!/bin/bash
# post-deploy-verify.sh - Запускать после команды деплоя

set -euo pipefail

URL="https://your-app.example.com"
DB_CONN_STRING="postgresql://user:pass@db-host:5432/app"

# 1. Проверка здоровья
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$URL/health")
if [ "$HTTP_CODE" -ne 200 ]; then
  echo "FAIL: Health check returned $HTTP_CODE"
  exit 1
fi
echo "PASS: Health check returned 200"

# 2. Дымовой тест - главная страница загружается
if ! curl -s "$URL" | grep -q "<title>App</title>"; then
  echo "FAIL: Main page missing expected title"
  exit 1
fi
echo "PASS: Main page loads correctly"

# 3. Проверка подключения к БД
if ! psql "$DB_CONN_STRING" -c "SELECT 1" > /dev/null 2>&1; then
  echo "FAIL: Database connection failed"
  exit 1
fi
echo "PASS: Database connection successful"

echo "All checks passed - deployment evidence collected"

Синтетические транзакции идут глубже. Они симулируют реальные пользовательские сценарии: вход в систему, поиск данных, отправку формы, оформление заказа. Если синтетическая транзакция проходит, вы знаете, что полный пользовательский путь работает end-to-end.

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

Ловушка поверхностной проверки

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

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

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

Разумный набор критериев может выглядеть так:

  • Дымовой тест главной страницы и входа в систему проходит
  • Синтетические транзакции для трех наиболее критичных пользовательских сценариев проходят
  • Частота ошибок остается ниже 0,1%
  • P95 задержка не увеличивается более чем на 5% от базового уровня до деплоя
  • Утилизация пула соединений с БД остается ниже 70%

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

Кто решает, что развертывание завершено

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

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

Для изменений с высоким риском вы все еще можете оставить человека в цикле. Старший инженер или дежурный может просмотреть доказательства и принять окончательное решение. Но даже в этом случае критерии должны быть четкими. Человек не гадает, все ли в порядке. Он проверяет предопределенный список условий.

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

Практический чек-лист завершения развертывания

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

  • Команда деплоя завершилась без ошибок
  • Дымовые тесты пройдены (главная страница, вход, основные функции)
  • Синтетические транзакции пройдены (критические пользовательские сценарии)
  • Частота ошибок в допустимом диапазоне
  • Задержка в допустимом диапазоне
  • Использование ресурсов (CPU, память, соединения) стабильно
  • Нет сработавших оповещений от систем мониторинга
  • Миграции БД применены и проверены

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

Что меняется, когда вы делаете это правильно

Когда ваша команда соглашается, что развертывание не завершено, пока нет доказательств работоспособности, весь процесс деплоя меняется. Деплой перестает быть технической задачей, которая заканчивается в терминале. Он становится переходом, который заканчивается, когда пользователи могут безопасно использовать новую версию.

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

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