# Процесс: изменение инфраструктуры через 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 недель пилота и после первого проверенного отката.

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

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