В гробу я видел весь ваш DevOps…01.11.2021 16:01

Эта статья о вреде выделенных команд DevOps инженеров в организации. Начну издалека. В книге Джорджа Массера «Нелокальность» приводится такой интересный момент оценки расстояния с точки зрения влияния. «Лев близко, значит он может напасть» — это о влиянии через определение пространство. Однако концепция «Лев может напасть, значит он близко» — нивелирует саму концепцию пространства. В сфере DevOps все скатывается в набор ритуалов и надутые щеки DevOps методологов-футурологов-идеологов и много чего. Речь разумеется не идет про лидеров индустрии, речь идет скорее про среднестатистические компании на рынке. Давайте перевернем все с головы на ноги!

Темна вода в облацех…

Пойдем по пути аналогий — если мы правильные инженеры, то нам нет особой разницы какое производство организовывать. Допустим у нас есть производство обычных водопроводных кранов, и есть конечный потребитель, желающий понежиться в ванной по утрам. Где у нас здесь DevOps-инженер? А вот он — тот самый прибухивающий дядя Вася из ЖЭС. Почему он прибухивает? А потому что весь производственный цикл направлен на то, чтобы дядя Вася пришел, взял стандартизированный инструмент, и прикрутил этот кран к стандартным трубам по стандартной процедуре. Улавливаете мысль? DevOps это пусконаладка. Мы не можем преуменьшать важность любой составляющей жизненного цикла продукта — потому что нам важны все они, но в первую очередь для нас важен конечный потребитель, тот самый хозяин квартиры. С этой точки зрения важен не дядя Вася, а непрерывная связь между производителем и потребителем, звеном которого он является. Никакой особенной DevOps трансформации или культуры нет — кроме важности понимания непрерывности цикла производства. Вроде бы очевидная вещь. Но нет лучше способа прослыть мудрецом, чем говорить очевидные вещи — «вода мокрая», «снег холодный», «программы пишутся для конечного потребителя».

DevOps инженеры занимаются самым сложным

Правда состоит в том, что эта сложность в большинстве своем шаблонная (пресловутые best practices). Она не имеет отношения к сложности продукта, она относится к сложности инфраструктурной и технологической зрелости. Если взять набор компаний примерно одинакового размера из одного домена, то окажется, что с некоторыми вариациями технологии и подходы в них совпадают. DevOps инженеры подобны муравьям — без всякой осознанности они выстраивают одни и те же термитники согласно заложенной в их ДНК программе независимо от продукта. Поэтому DevOps часто не культура, а целая религия — со своими шаманами и ритуалами. Возьмите среднестатистического DevOps инженера и потыкайте палочкой — из него посыпятся Docker, Terraform и Kubernetes. Даже если это приложение, состоящее из одного HTTP эндпойнта. Правда в том, что в большинстве случаев сложность вообще не нужна — можно сделать просто и быстро, либо сильно преувеличена — и такой подход пропагандируется самими разработчиками по принципу «у меня лапки».

DevOps инженеры занимаются самым важным

Важность эта опять же возникает из того, что DevOps инженеры в любой компании являются блокером, причем практически в любой активности. Вместо того чтобы обеспечить гибкость в доставке и внедрении новых технологий, они эту самую доставку присваивают, а поскольку их как обычно не хватает — то стремятся в целях сохранения status quo свести опять же все к шаблонам. Иначе все к чертям развалится. Вот и получается, что вместо того чтобы способствовать гибкости конфигурации продукта, выделенная DevOps команда замыкает этот продукт в рамках своего технологического стека. Важность DevOps инженера по сути сводится к важности вахтера — без него вы внутрь здания не попадете. Но кто сказал, что он вообще нужен?

Если все так плохо — почему все продолжают есть кактус?

Прочитайте определение DevOps из вики

Методология активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимная интеграция их рабочих процессов друг в друга для обеспечения качества продукта.

Вашу ж мать! Где здесь DevOps- инженеры? Ирония заключается в том, что попытка автоматизировать и упростить рабочие процессы нас приводит к тому, что мы помещаем людей прямо на пути изменения конфигурации продукта. Нам нужно проверить миллионы продуктовых гипотез -, а у нас тут люди. Сколько DevOps инженеров нужно на одного разработчика? А вот нет такого соотношения. Мы формируем бэклог, считаем эстимейты, делаем архитектуру -, а в середине упираемся в ограничения, причем в ограничения с головой загруженной группы специалистов, которых слишком много, чтобы ничего не делать, но слишком мало, чтобы удовлетворить все запросы. А ответ простой — на каждого разработчика нужен ровно один DevOps инженер. Как? А так, каждый разработчик является ответственным за доставку тех изменений в продукте, которые он вносит. Продолжая аналогию с дядей Васей — сделал кран — сходи сам его поставь. А дальше напиши «повторить так еще 10000 раз». Но на практике оказывается, что позволить сейчас себе подобный подход могут лишь несколько лидеров индустрии. В чем дело? В людях или в технологиях?

Если говорить о технологиях, то тот же Kubernetes, облачные провайдеры и тп не представляют никакой особой технологической сложности. Держу пари, что досконально изучить все особенности работы какой-нибудь postgresql куда сложнее, чем концепт работы с k8s. Ситуация сильно колеблется — в условиях дефицита специалистов с разработчика спрос минимален — код хотя бы писать мог, а на остальное наймем DevOps инженера, ведь все DevOps инженеры делают одно и то же.

Выход где?

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