in devops ~ read.
Анти-паттерны DevOps #1. Человек-DevOps

Анти-паттерны DevOps #1. Человек-DevOps

Давно хотел написать, но руки всё никак не доходили. Понятие DevOps незаметно перешло в разряд баззвордов, и за ним скрываются просто тонны разнообразных практик и представлений о том, что это, как это надо готовить и даже критерии "есть девопс или нет" будут отличаться у разных людей. Серьёзно, если опросить с десяток случайных ИТ-специалистов разной направленности, то их мнения конечно будут пересекаться, но каждый из них расскажет о проблеме со своей точки зрения, и порой они просто не будут совпадать, часто по ключевым вопросам.

Основной проблемой является то, что не все понимают, что DevOps это в первую очередь мировоззрение людей, то как они делают свою работу и как они не делают казалось бы очевидных, но абсолютно неэффективных вещей. Этой заметкой хотелось бы открыть серию очерков о распространённых анти-паттернах (вы можете быть не согласны, и я с удовольствием с вами поспорю) при внедрении методологии. И первый из них "Человек-DevOps".

Когда я слышу, что нужны мифические DevOps-инженеры, которые придут и построят вам в компании DevOps, мне всегда хочется спросить - а как один или несколько человек, которых предполагается использовать фактически на сервисном уровне (настрой мне дженкинс, напиши скрипты), могут поменять сознание разработчиков, тестировщиков и сопровождения? Фактически вы вводите буфер между саппортом и разработкой (чёрт и каждый раз надо как минимум вставить тестирование, а кажется что в системе devops-координат вместить эту категорию просто некуда), что никак не приведёт к разрушению между этими группами "колодцев" (silos).

Следующий вопрос - это как в компании такого человека будут называть? Чаще всего позиция называется как DevOps Engineer. И вот вопрос - а кто это? Вариантов два (предлагайте свои в комментариях):

  • бывший системный администратор, постигнувший дзен автоматизации
  • разработчик, который смог освоить инструменты администрирования и деплоймента, которые упрощаются с каждым годом (спасибо тебе Docker!)

Самое важное тут, что мировоззрение у двух этих категорий часто не пересекается, потому что давит предыдущий бэкграунд, разработки или администрирования. От этого будут сильно зависеть подходы, стратегия и тактика автоматизации рутинных процессов и в целом его построения. В результате, если у нас есть два человека (один с одной стороны баррикад, и один с другой) мы получим два разных DevOps-а, каждый со своим смещённым центром тяжести, и почти наверняка у нас будут проблемы с масштабированием, особенно в большой компании, когда неизбежно будет соблазн перевести анти-паттерн "человек-devops" в другой анти-паттерн "команда/отдел/департамент-devops", что то же самое, только в несколько раз хуже.

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

comments powered by Disqus