Сталкивались ли вы с конфликтом между разработкой и инфраструктурой?

Стабилизируя прод, мы теряем в изменяемости, а давая разработчикам в руки IaaS и IaC — теряем в стабильности. Что же делать?

Любой разбор конфликта начинается с понимания интересов сторон. У команды Ops метрика успеха — uptime. У команды разработки — time to market. Конфликт исчезает когда обе стороны имеют общий интерес и отвечают за общий результат.

Разумеется, решение не в выборе между свободой и контролем, а в зафиксированных и автоматизированных договоренностях и правилах.

Инфраструктурная команда из Ops становится DevOps, когда описаны и автоматизированы все политики и выстроен стандартизированный процесс деплоя.

Политики блокируют PR автоматически если нарушен стандарт и превышены лимиты ресурсов. Ревью становится необходимым только для нестандартных случаев.

Процесс деплоя (canary, blue-green, feature-flags) сокращает последствия ошибки, а если настроен автоматический откат - изменения становятся менее стрессовыми.

Это решает техническую часть конфликта, организационную решает error budget. Пока бюджет не исчерпан - разработка может катить изменения так часто, как хочет, любым способом. Как только бюджет исчерпан - приоритет смещается на стабилизацию.

Ещё один важный момент - хорошее описание архитектуры и политики не содержат конкретных технологий. Если golden path описан на уровне "как задеплоить сервис", а не "как задеплоить Java-приложение", смена технологий превращается из борьбы с Ops в задачу "создание ещё одного шаблона".

В начале любых больших изменений, при создании рабочей группы, я всегда спрашиваю "как именно мы будем договариваться?" Чаще всего ответы сводятся к привычным встречам и обсуждениям. Этот ответ меня не удовлетворяет, я переспрашиваю "как именно". В итоге все соглашаются с подходом RFC.

А как в вашей компании договариваются Dev и Ops?