Паспорт процесса · P-03

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

Процесс: изменение инфраструктуры через IaC

Учебный пример для команды, где инфраструктура уже частично описана кодом. Инфраструктура как код (Infrastructure as Code, IaC) здесь является способом выполнить конкретное изменение, а не названием всего направления.

Зачем

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

Точка входа

  • Что запускает процесс: принятое целевое состояние и граница инфраструктурного изменения.
  • Кто может запустить: владелец платформы или Tech Lead.
  • Где это происходит: задача или ADR, Git-репозиторий IaC и CI/CD.
  • Как понять, что входные данные готовы: описаны целевое состояние, периметр, проверки и критерий отката.

Участники и ответственность

  • Владелец процесса: владелец платформы или Tech Lead.
  • Кто готовит входные данные: автор запроса на изменение.
  • Кто принимает результат: владелец процесса и второй инженер.
  • Кто обновляет шаблоны, промпты или скиллы: платформенный инженер или Tech Lead.

Входные данные

  • Задача или ADR с целевым состоянием и ограничениями.
  • Актуальный код IaC и инструкции репозитория.
  • Доступные данные тестовой среды и мониторинга.

Выходные артефакты

  • Ветка с изменением IaC.
  • Результаты статических проверок и план применения.
  • Инструкция отката и подтверждение состояния до и после теста.

Шаги процесса

ШагВходВыходКритерий качества
1. Подготовить изменениеЗадача или ADR и актуальный код IaCОтдельная ветка с изменениемИзменение остаётся в согласованном периметре и не содержит секретов
2. Построить план примененияВетка и конфигурация проверокРезультаты статических проверок и планПроверки проходят; план содержит только ожидаемые изменения
3. Провести второе ревьюПлан, изменение и инструкция откатаВердикт и замечания второго инженераГраница, зависимости и откат проверены; критических замечаний не осталось
4. Применить в тестовой средеОдобренное изменение и готовая тестовая средаФактическое состояние после примененияПрименение выполнил уполномоченный человек; рабочая среда не затронута
5. Проверить результат и восстановлениеСостояние до и после тестаДоказательство ожидаемого результата и проверенный откатНаблюдаемое состояние совпадает с планом, возврат воспроизводим
6. Принять решение и записать запускРезультаты теста, ревью и откатаРешение владельца и строка журналаУказаны источники метрик, проверяющие и условие дальнейшего применения

Промпты, скиллы и инструменты

  • Git, используемый инструмент IaC, CI/CD и мониторинг.
  • Версионируемые инструкции репозитория и скилл инфраструктурного изменения.
  • Чек-лист проверки плана и отката.

Контрольные точки с человеком

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

Данные и доступы

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

Метрики

  • Основная метрика результата: доля изменений, воспроизводимо прошедших проверку и тестовую среду; источник — CI/CD и журнал запусков.
  • Метрика качества или внедрённости: медианное время от принятого целевого состояния до проверенного плана.
  • Негативный сигнал: неуспешное применение, расхождение фактического состояния с кодом или невозможность отката.
  • Исходный уровень: измерить на сопоставимых изменениях за неделю до пилота.

Ресурсы и срок

  • Срок первого этапа: 4 недели.
  • Время команды: до 28 часов на настройку, ревью и проверку тестовой среды.
  • Лимит на инструменты и инфраструктуру: определить до запуска; рабочая среда и её секреты в лимит доступа агента не входят.
  • Стоимость одного запуска: время подготовки, человеческого ревью и тестовой инфраструктуры.
  • Полная стоимость этапа: 28 часов по внутренним ставкам плюс фактическая стоимость тестовой инфраструктуры и инструментов.

Критерий внедрённости

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

Журнал запусков

ДатаВходРезультатПроверка человекомМетрикиЧто изменить