Сообщить об ошибкеКороткий ответ
Разделяю изменения по риску: автоматические lint, plan и policy checks обязательны всегда, а число и состав reviewer'ов зависят от окружения и blast radius. Для аварий нужен break-glass с журналированием и обязательным post-review.
Как это работает подробнее
Автоматика быстро ловит синтаксис, небезопасные политики и неожиданный plan; люди оценивают архитектуру, зависимости и бизнес-контекст. Одинаково строгий процесс для sandbox и production создаёт очереди и стимулирует обход правил.
- Низкий риск. Dev или локальный модуль: один reviewer и зелёные автоматические проверки.
- Высокий риск. Production, IAM, сети, данные и shared-модули: владелец компонента, опытный reviewer и план отката.
- Инцидент. Ограниченный по времени доступ, аудит действий, последующий PR и review в заданный срок.
Что использовать на практике
- CODEOWNERS. Назначать обязательных владельцев только критичным путям, чтобы не превратить senior-инженеров в постоянное узкое место.
- Policy as code. Автоматизировать повторяемые ограничения на доступ, шифрование, теги и удаление ресурсов.
- Метрики. Следить за lead time review, долей bypass, замечаниями до merge и инцидентами после изменений.
Подводные камни
- Избыточный контроль. Два senior-reviewer для любого изменения замедляют поставку без пропорционального снижения риска.
- Формальное approve. Большой plan без удобного summary провоцирует поверхностную проверку; опасные операции нужно выделять автоматически.