Барух Садогурский: «Называя DevOps профессией, мы нивелируем смысл термина»

Почему DevOps — это не должность

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

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

А проблемы, для решения которых создавали DevOps, так не устранить — в итоге мы снова придём к тому, что нужно изобретать якобы новую методологию поверх старой. Можно будет придумать DevDevOps! И суть этой методологии будет примерно такой: добиться, чтобы разработчики всё-таки работали вместе с DevOps. В каждой шутке доля шутки, знаете ли.

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

В чём смысл DevOps

Методология DevOps предполагает, что мы пытаемся организовать взаимодействие между разными людьми в разных отделах. Но при этом в DevOps привычное нам деление по отделам перестаёт существовать. Вместо этого появляются так называемые empowered teams — объединённые команды, состоящие из представителей разных профессий, которые совместно решают проблемы.

Например, это может быть команда из разработчиков, тестировщиков и инженеров, которая отвечает за инфраструктуру, облачные сервисы, продакшен, и постепенно убирает все bottleneck на пути к продакшену.

Задача такой команды — настроить процессы, чтобы появились автоматизированные пайплайны. Было ручное тестирование — а теперь тестировщики работают вместе с разработчиками и выстраивают систему автотестов. Build-release-инженеры, которые занимались запуском билдов, теперь следят, чтобы система тестов работала. Безопасники, которые раньше перед релизом проверяли всё вручную, теперь взаимодействуют с разработчиками и другими членами команды — и тоже автоматизируют свои тесты на безопасность внутри пайплайна.

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

Кто такой DevOps-инженер, которого все так хотят

Вместо того чтобы перестраивать работу в соответствии с методологиями DevOps, многие компании ищут мифического DevOps-инженера, который придёт и всё сделает. То есть автоматизирует процессы для всей команды.

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

На самом деле это имеет отношение непосредственно к DevOps. Без такого человека действительно автоматизировать процессы невозможно, но название «DevOps-инженер», конечно, неправильное. Что можно использовать вместо него? Есть несколько вариантов.

SRE (Service Reliability Engineer). Но у многих есть проблемы с этим термином, потому что они считают задачей SRE смотреть, чтобы в проде ничего не упало. Хотя на самом деле, когда этот термин появился, он подразумевал гораздо более широкий список функций и обязанностей.

Infrastructure Engineer. Это гораздо более широкий термин, и он на самом деле подходит ко всему, о чём мы говорили в контексте DevOps-задач. Это человек, который придумывает, создаёт, поддерживает пайплайны, а затем следит, чтоб они работали и правильно отражали DevOps-процессы в организации.

Production Engineer. Такой человек заботится о том, чтобы всё, что должно попасть в продакшен, оказалось там — причём именно в том виде, в котором и должно было.

Но никто из этих специалистов не может в полной мере считаться «DevOps‑инженером», потому что DevOps — это процесс совместной работы разных людей и команд.

Какой он — настоящий DevOps

Инструментарий мифического DevOps-инженера — это всё, что требуется для трёх главных аспектов автоматизации: построения пайплайнов, мониторинга (observability) и incident management. Эти три аспекта позволяют автоматизировать доставку кода, следить за качеством его исполнения в любой среде и реагировать на любые инциденты. Для этого нужен весь набор инструментов Infrastructure Engineer, Production Engineer и SRE.

Отвечать за все три аспекта могут как разные люди, так и один специалист — тот самый «DevOps-инженер», который на самом деле вовсе и не DevOps-инженер, а Infrastructure Engineer, Production Engineer или SRE.

Но это не значит, что один человек способен или должен отвечать за все эти процессы: он лишь позволяет этому случиться, используя правильный инструментарий. Но, опять же, чтобы DevOps работал как надо, нужна слаженная работа всех специалистов. Потому что все IT-специалисты в конечном итоге пользуются observability, пайплайнами и участвуют в incident management.

Не должно быть так, что человека назначают главным DevOps-инженером и заставляют полностью отвечать за observability, а у других специалистов к этим системам нет доступа. Нет, тот, кто отвечает за направление DevOps, должен помочь всей команде — и разработчикам, и тестировщикам, и безопасникам, и всем на свете — пользоваться инструментами для автоматизации. Да, он их выбрал, настроил и подключил, но потом, если DevOps настоящий, все в команде ими пользуются.

Как определить, состоялась ли DevOps-трансформация

DevOps — это в первую очередь культурная трансформация. Речь идёт не о «нанял нового человека с названием „DevOps-инженер“ и закрыл вопрос», а о регулярной и планомерной работе с людьми — в итоге они должны понять, что мы меняем и зачем, к какой цели идём. А дальше очень осторожно и постепенно можно трансформировать организацию в парадигме DevOps.

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

У меня есть любимый ресурс, который называется State of DevOps Report от организации DORA (DevOps Research & Assessment). Там расписано, каких результатов можно ожидать, если трансформация произошла правильно — с ним можно сверяться, чтобы понять, действительно ли мы идём в правильную сторону.

Например, если у нас исчезают bottlenecks, начинают более быстро и качественно происходить релизы, уменьшилась регрессия, исчезли интеграционные затыки, значит, мы всё делаем правильно.

А если, несмотря на то что мы назначили кого-то DevOps-инженером, никаких улучшений нет или улучшения произошли чисто технически и на короткий срок за счёт использования более хороших инструментов, значит, мы что-то делаем не так.

Кто входит в DevOps-комьюнити и как в него влиться

В DevOps-комьюнити десятки тысяч человек — в одном только русскоязычном Telegram-чате «DevOps — русскоговорящее сообщество» около 12 тысяч участников.

К сообществу относятся люди, которые занимаются внедрением DevOps в организациях или в командах. Это те самые Infrastructure Engineers, Production Engineers и SRE. Именно они сегодня драйвят всё сообщество. Но DevOps-комьюнити состоит не только из них, в него входят все, кто заинтересован в DevOps-трансформации, участвует в ней или вовлекает других.

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

Сейчас проходят десятки мероприятий, конференций, митапов, посвящённых DevOps: например, DevOops, DevOpsConf, DevOpsCon, DevOps Pro, DevOpsDays и так далее. И это только крупные конференции. Также есть сообщества в Telegram, Facebook*, «ВКонтакте». Можно участвовать в жизни комьюнити и помогать другим — советами, ответами на вопросы, рассказами о личном опыте.

Если вы хотите заявить о себе в сообществе, лучший путь — выступать на конференциях. Я, как человек, который помогает организовывать DevOops, очень рекомендую заявиться туда в качестве спикера. Мы будем рады новым лицам, новым мыслям, поможем с темой доклада и презентацией.

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

Одно из направлений работы программного комитета — находить новые лица, новые голоса, новые темы и работать с ними, пока они не вырастут до того уровня, который даст им право выступать на конференции.

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

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

Кстати, на ивентах всегда нарасхват волонтёры. Если хотите им стать, можно предложить себя в разных комьюнити во «ВКонтакте» и Telegram, написать, что готовы помогать в организации.

О чём спорят в DevOps-комьюнити

Как и в любом популярном сообществе, споров в DevOps-комьюнити очень много. Спорят обо всём: об инструментах, методологии, о том, кто такой DevOps‑инженер — человек или не человек. На мой взгляд, наиболее важные из этих холиваров — про роль разных людей, разных специалистов в DevOps. Например, должны ли разработчики быть вовлечены в DevOps, и если да, то насколько и в каком качестве.

Или можно ли разработчикам давать доступ к продакшену? Одни говорят, что да, конечно, согласно принципам DevOps все должны в этом участвовать, а разработчики должны сами деплоить свой код. Другие же высказывают противоположное мнение: «Ой, мы сейчас дадим им доступ в продакшен, а они его поломают и придётся всё чинить».

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

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

Такие проблемы — проблемы реального мира — меняют розовую и сказочную картинку DevOps. Особенно когда это всё накладывается на практические ограничения внутри конкретной организации.

Однако изменить сложившуюся ситуацию даже в неблагоприятных условиях вполне реально. Я рассказывал, как это сделать, в своём докладе на конференции DevOops «Устраиваем DevOps без полномочий».

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