Разрабы должны чувствовать последствия своих решений Кент Бек, в своем подкасте сказал очень хорошую мысль: "Задача Ops-команды дать разработчиком прочувствовать боль своих ошибок". Немного злобная, но очень честная мысль. Девопс, как функция, должны помогать "владеть" и эксплуатировать свой код командам разработки. А никак не тащить на дев, стейдж и прод и отвечать там за поломки

В традиционной модели разработчики пишут код, а операционные команды его поддерживают. Классическое разделение ответственности: "я написал — вы разбирайтесь". Результат предсказуем — код работает на машине разработчика, но превращается в кошмар на всех других средах и особенно — на продакшене.

"Практика you build it - you run it" предлагает радикально другой подход: пусть тот, кто создает проблему, сам с ней и разбирается. Не из садизма, а из понимания простой истины — только почувствовав боль, разработчик начинает писать код по-другому. Когда разработчик знает, что в 3 утра его разбудит алерт от его собственного кода, магическим образом меняется отношение к качеству:

• Логирование становится осмысленным, а не формальным
• Обработка ошибок из "авось пронесет" превращается в продуманную стратегию
• Мониторинг закладывается на этапе проектирования, а не добавляется постфактум, чтобы номинально удовлетворить требования
• Архитектурные решения перестают приниматься по модели "и так сойдет"

В конечной картине мира, когда команда разработки отвечает за весь жизненный цикл продукта — от идеи до поддержки в продакшене — качество кода растет экспоненциально. Потому что каждый костыль, каждый "а потом разберемся", каждое "и так сойдет" возвращается бумерангом и очень быстро обучает в затылок своего автора.

А вообще, в идеале: Синьор, который никогда не дежурил по своему коду — это не синьор. Это теоретик. Настоящая экспертиза приходит только через понимание операционных последствий архитектурных решений.

Хороший разработчик думает не только "как это реализовать", но и:

• Как это будет деплоиться?
• Как это будет мониториться?
• Что будет, если это упадет? И как сделать, чтобы не падало?
• Как быстро можно будет найти и исправить проблему?

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

• Исчезает менталитет "не моя проблема"
• Появляется проактивное мышление о надежности
• Растет эмпатия к операционным командам и пользователям
• Формируется внутренний стандарт качества, который не зависит от внешнего контроля

П.С. Знали бы вы, сколько я контр-аргументов против выслушал по этому поводу

П.С. На КДПВ девелоперы заботливо развивают свои микросервисы ^__^

В этом посте были ссылки, но мы их удалили по правилам Сетки