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

На что я обращаю особое внимание в DevOps-контексте:

1. Безопасность (Security):

   • Проверка на наличие hardcoded секретов (паролей, токенов) в коде или конфигах.
   • Анализ прав доступа в IAM-политиках (AWS, GCP, Azure) на предмет избыточных привилегий.
   • Оценка Dockerfile на использование последних базовых образов и отсутствие запуска процессов от root.

     
     # Плохо
     FROM alpine:3.7
     USER root
     CMD ["nginx", "-g", "daemon off;"]

   Лучше

   FROM alpine:3.19 RUN addgroup -S app && adduser -S app -G app USER app CMD ["nginx", "-g", "daemon off;"]

2. Надёжность и отказоустойчивость (Reliability):

   • Проверка конфигураций оркестраторов (Kubernetes manifests, Terraform) на наличие лимитов ресурсов (resources.limits/requests), readiness/liveness проб.
   • Анализ скриптов развёртывания на отсутствие точек отказа (например, необработанных ошибок).

3. Повторяемость и идемпотентность (Idempotency):

   • Код инфраструктуры (Terraform, Ansible) должен быть идемпотентным — его многократный запуск даёт один и тот же результат.

4. Соответствие стандартам и best practices:

   • Соблюдение принятых в команде шаблонов для Terraform модулей, CI/CD пайплайнов (GitLab CI, GitHub Actions).
   • Проверка логгирования и мониторинга: логируются ли ключевые события, настроены ли алерты на метрики.

Баланс: Жёсткое ревью оправдано для критичных компонентов: security-related кода, модулей ядра инфраструктуры, конфигураций production-окружения. Для менее критичных изменений или hotfix-ов допустим более лояльный подход, чтобы не блокировать разработку.