Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

Уменьшите зависимость от разделения обязанностей

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

Есть много других менее спорных примеров разделения обязанностей в работе эксплуатации, например, администраторы серверов могут смотреть логи, но не могут удалять их или редактировать, чтобы никто с правами специального доступа не мог удалить свидетельства мошенничества или других проблем.

Когда мы проводили развертывания относительно редко (например, ежегодно) и когда наша работа была менее сложной, разделение работы и передачи управления проектами были приемлемыми способами ведения бизнеса. Однако с ростом сложности систем и увеличением частоты развертываний появляется необходимость того, чтобы все сотрудники в потоке создания ценности могли быстро увидеть результаты своей работы.

Разделение обязанностей часто мешает этому, замедляя и сокращая обратную связь, полученную инженерами. Из-за этого они не могут брать на себя полную ответственность за качество работы, а способность компании получать и накапливать знания значительно сокращается.

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