11-4 · Глава 11 · 5 мин. чтения

Когда ручное утверждение всё ещё важно в вашем пайплайне развёртывания

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

Когда ручное утверждение всё ещё важно в вашем пайплайне развёртывания

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

Это момент, когда автоматизация достигает своего предела.

Что не могут увидеть автоматические шлюзы

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

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

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

Четыре ситуации, требующие ручного утверждения

Крупные изменения в коде приложения

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

Ручное утверждение важно, когда изменение затрагивает критический бизнес-процесс. Переписывание платёжного модуля, изменение того, как приложение обрабатывает пользовательские сессии, или замена основной библиотеки, от которой зависят многие части приложения — эти изменения несут риск, который автоматические тесты не могут полностью оценить. Тесты могут проверить, что новый код не падает, но они не могут подтвердить, что новая бизнес-логика соответствует тому, что команда согласовала с заинтересованными сторонами.

Кто-то, кто понимает бизнес-контекст, должен просмотреть изменение и сказать: «Это соответствует тому, что мы запланировали».

Изменения в базе данных

Изменения в базе данных — один из самых частых источников инцидентов в production. Изменения схемы, новые индексы и миграции данных имеют побочные эффекты, которые трудно обнаружить автоматически.

Следующий фрагмент workflow GitHub Actions показывает, как можно потребовать ручное утверждение для изменений миграции базы данных:

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    # Требовать ручное утверждение для изменений в migrations/
    if: contains(github.event.head_commit.modified, 'migrations/')
    steps:
      - uses: actions/checkout@v4
      - name: Run database migration
        run: |
          echo "Applying migration..."
          # Скрипт миграции здесь

В этом примере настройка environment: production запускает шаг ручного утверждения в GitHub Actions. Пайплайн приостанавливается, пока назначенный рецензент не утвердит развёртывание, гарантируя, что человек оценит миграцию перед тем, как она попадёт в production.

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

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

Инфраструктурные изменения

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

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

Инфраструктурным командам нужно просмотреть изменение, проверить зависимости и подтвердить, что его безопасно применять.

Любое изменение в production

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

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

Как решить, что требует утверждения

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

Распространённый подход — классифицировать изменения по уровню риска:

Следующая блок-схема обобщает процесс принятия решения:

flowchart TD A[Обнаружено изменение] --> B{Тип изменения?} B -->|Схема БД| C[Высокий риск] B -->|Инфраструктура| C B -->|Основная бизнес-логика| C B -->|Production конфиг| C B -->|Исправление ошибок / документация / мониторинг| D[Низкий риск] C --> E[Требовать ручное утверждение] D --> F[Только автоматические шлюзы] E --> G[Назначить утверждающего по экспертизе] G --> H[Утвердить или отклонить]

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

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

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

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

Настоящая цель ручного утверждения

Ручное утверждение — это не про замедление доставки. Это про то, чтобы высокорисковые изменения получали должное внимание, прежде чем они попадут к пользователям. Автоматизация обрабатывает рутинные проверки. Люди обрабатывают те суждения, которые машины не могут вынести.

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