Учебный пример для команды, где инфраструктура уже частично описана кодом. Инфраструктура как код (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 недель пилота и после первого проверенного отката.