DevOps культура: мифы и реальность

Первый набор мифов отвечает на вопрос «кто»: DevOps представляют либо универсальным человеком, который умеет и успевает всё, либо отдельным подразделением. В одном случае так переименовывают системного администратора, в другом — разработчика, которому приходится настраивать конвейеры. Эти названия сами по себе ничего не говорят о том, как команда создаёт продукт и отвечает за его работу.

Второй набор мифов подменяет подход инструментами: Ansible, Docker, Kubernetes, Jenkins или GitLab объявляются достаточным признаком DevOps. Встречаются и другие крайности — переименование прежнего управления ИТ или отношение к культуре как к пустому модному слову. Автор предлагает смотреть на реальное устройство работы: наличие технологии ещё не объясняет, какие проблемы она решает и кто несёт ответственность за результат.

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

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

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

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