Привет! Меня зовут Василий Куценко, я возглавляю департамент DevOps в Почтатехе и считаю, что девопсов не существует… 

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

Но как же быть с тем, что компании постоянно ищут DevOps-инженеров, на хантинговых сайтах полно подобных вакансий, а сама должность престижна и хорошо оплачивается? Кто же эти «фантастические девопсы» и что нужно, чтобы быть «труъ», разбираемся в статье.

P. S. Текст написан на основе доклада, с которым я выступал на DevOops-митапе в мае 2023.

Главный облом

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

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

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

Немного истории

Представим мир конца нулевых. У нас была водопадная методология разработки, мы поставляли обновления хорошо если раз в квартал, но реалистично — раз в полгода. И вот, в 2009 году Джон Оллспоу и Пол Хэммонд на инженерной конференции представляют свой революционный доклад под названием: «Более 10 деплоев в день, кооперация разработчиков и сопровождения в компании Flickr». Кстати, очень рекомендую к просмотру.

Технически ребята рассказали, как они договорились передавать код разработки в определенном формате, тогда как со стороны инфраструктуры была соответствующая дырка, из которой осуществлялась автоматизированная раскатка кода. Само собой, это вызвало революцию, которую и окрестили словом «DevOps».

На самом деле, за кадром остался бриллиант: эти два человека стандартизировали входные и выходные форматы, по сути построив жестко структурированный интерфейс между двумя подразделениями. И после того, как они договорились о техстеке, выработали правила именования, состав поставки и т. д., только после этого они автоматизировали выкат.

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

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

DevOps умер,
да здравствует DevOps!

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

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

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

Оказалось, что всякие метрики типа time-to-market или Lead Time уже не настолько зависят от простой автоматизации деплоя. Более того, конвейер стал длиннее, включая в себя проверки качества кода различными линтерами, анализаторами уязвимостей и интеграционными тестами.

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

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

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

В этом моменте мы и поломаем с вами копья. Потому что, в моем понимании, DevOps-инженер по своей сути и философии ближе к UX-дизайнеру или к Agile-коучу, чем, например, к сисадмину.

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

Профиль DevOps

Софты

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

Коммуникабельность

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

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

Есть замечательный тезис, который я почерпнул из книги «45 татуировок менеджера», — рекомендую всем прочитать — очень легкая и насыщенная книга. Тезис звучит так: «То, что очевидно тебе, не очевидно другим».

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

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

Эта задача намного глубже, чем кажется, и возникает не только в практике инженера. К примеру, Китай закупает у России самолеты и просит не переводить приборную панель на китайский. Потому что «тангаж», «высота» или «крен» — это не просто слова, а понятия, за которыми стоят разделы фундаментальной физики. Дословный перевод здесь не прокатывает.

Системное мышление

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

Говоря о системном мышлении, вспоминаю сказку про Кощея Бессмертного. Есть гигантская матрешка: утки, зайцы, хрустальные гробы и так далее. Но ключ к проблеме Кощея — игла. Именно с неё всё и началось. 

В нашем случае есть сложный ландшафт: физические серверы, на них гипервизоры, виртуалки, а следом кубернетисы со своими оверлейными сетями и кучами микросервисов. Тем не менее около 30% всех проблем в той самой «игле»: кто-то банально вовремя не докинул дисков на ноду.

Допустим, проблему мы определили, но остается огромное количество абстракций, которые рождаются каждый день. Я знал разработчика, который как-то раз на проекте читал с жесткого диска побитово. С блочного устройства — побитово! При этом разработчик и его менеджер жаловались вендору по виртуализации на медленные диски — конечно же, «проблема в инфраструктуре» =)

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

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

Кругозор

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

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

Все, о чем я рассказываю, так или иначе способствует улучшению коммуникации. И этот пункт не исключение. Сами посудите, если человек поработал, например, в разработке, аналитике, немного посисадминил или поархитекторил и таки пришел в DevOps, он с каждой из ролей «на короткой ноге». Он хорошо понимает специфику работы коллег, артефакты, необходимые им на входе и остающиеся на выходе. И переведет на доступный для всей команды язык то, о чем говорит, например, аналитик.

По опыту работы в командах хранилищ данных могу сказать, что большая часть запросов по улучшению жизни — в минимизации дублирования информации. Предположим, есть логическая модель, в которой описаны атрибуты сущностей в БД и их взаимосвязь. А есть артефакты вокруг модели: SRS, BRD со стороны аналитики, код, ETL со стороны разработки и оценки влияния со стороны сопровождения. И всем должно быть удобно работать с этой моделью, причем желательно без неожиданностей вроде добавления кучи новых инструментов. Тут и выходим мы — проектировщики интерфейсов, и ищем возможность интеграции их артефактов в эту модель.

С точки зрения разработки эти задачи могут быть неинтересными. В самом деле, что сложного распарсить какой-нибудь Excel, положить его в БД или выложить на Confluence. Но вот эффект от таких мелочей бывает гигантским.

Важно не пренебрегать мелочами. Ведь наступит такой момент, когда пайплайн настолько выверен и оптимизирован, что его изменение практически не улучшает наш любимый TTM или Lead Time. Тогда-то эти мелочи и начинают выстреливать. Меньше глупого копипаста — быстрее подкатила аналитика по задаче. Разработчик меньше времени тратит на описание релиза — быстрее TTM или больше задач параллелится.

Велосипедостроение

Идем дальше, теперь про велосипеды. Велосипедостроение — основа нашей отрасли! Без него нет конкурентных продуктов, новых технологий и подходов. Так что бояться этого не стоит, но нужен баланс. Я не зря говорил про кругозор: для успешного велосипеда он важен, чтобы не размениваться по мелочам, упуская главное. Тут важно еще сказать про комьюнити — глупо отрицать и не использовать чужой опыт. Но если вы считаете, что ваше решение правильное, а сообщество думает иначе, то бояться осуждения также не стоит. Вы можете оказаться правы.

Как я уже сказал, мы проектируем интерфейсы между людьми. А еще в их глазах мы — волшебники. Специальные ребята, которые в любой ситуации найдут способ сделать магическую кнопку, и все проблемы будут решены. Но вот как среди множества проблем найти самую-самую?

Эмпатия

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

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

Приведу пример. Есть большой юнит, у которого одним из необходимых артефактов является Release Info. По сути это страничка в Confluence, в которой собрана вся необходимая информация для Release-инженера. Там указаны всякие шаги, неважно, автоматические они или ручные. Помимо этого там хранится мета-информация о релизе: номер версии, всякие хэш-суммы и прочее. А также там указаны пререквизиты. Например, для того, чтобы выкатить эту доработку, вы должны сначала выкатить что-то предыдущее, иначе все взорвется.

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

DevOps-инженер эту задачу решил так: теперь последовательность доработок ведется в Jira через специальный вид связи, который однозначно интерпретируется. Все в выигрыше: нет нового инструмента, а используется существующий, знакомый всем участникам процесса. Эту информацию легко распарсить и положить в Release Info.

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

Стремление к порядку

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

Сам порядок выражается в стандартах: это могут быть стандарты именования, какие-то структуры хранения, модели ветвления, списки артефактов — да все что угодно, на основании чего можно лепить космолеты.

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

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

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

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

Обучаемость

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

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

Обучаемость хорошо держится в тонусе через синергию с упорядочиванием. Например, ведение собственной базы знаний, в каком-нибудь Obsidian.md позволяет держать свои знания актуальными и всегда иметь возможность найти похожий кейс по ключевым словам.

Самостоятельность

Последний, но не по важности, софт-скилл — самостоятельность. По сути это умение полагаться на себя и брать ответственность.

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

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

Харды

Хорошо, когда вы уже что-то умеете. Но если нет — это нестрашно. Как я уже говорил, всегда можно научиться чему-то, был бы системный подход. В компаниях, а зачастую и на проектах в одной компании, все сделано по-разному. Стек свой, реализация своя. Ведь какие-то универсальные пайплайны, например, обычно плохо работают: вытягивают ТТМ или сложно адаптируются к изменениям. Поэтому если вы ожидаете универсальный список технологий, с которым вы везде найдете себя, то вот он:

Шутка! Ну, конечно, универсального списка нет, и никто его не даст. Хотя бы потому, что стандартный список технологий уже загнал нас в дыру между разработчиками и девопсами. Но вот более общий список составить мы все-таки можем.

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

Из языков программирования лучше что-нибудь общего назначения и с кучей библиотек. Я выбрал Python, потому что он интерпретируемый — очень просто писать прототипы, скрипты и мелкие софтины.

Вы, так или иначе, будете сталкиваться со сложными информационными системами. Чтобы понимать, как они работают, и уметь в их траблшутинг, изучаем, как говорят старики, ЭВМ.

Мы должны уметь в линукс — ну какой инженер нынче без никсов? Здесь я скажу так: вы должны быть уверенным пользователем командной строки, чтобы лог нужный найти, LVM/диски расширить, сетевые адаптеры с маршрутами настроить. Это минимум.

Кронтабы, эирфлоу и кубернетисы — шедулеров много, а я один. Поэтому расписания — важная штука.

Из очередей кафки и кролики — такой уж нынче асинхронный ИТ-ландшафт. Любой инженер должен понимать, что такое offset и как им управлять.

Пипелиностроение — это база! Конвейер — наша главная технология построения бесшовного процесса. Так что тут хорошо бы знать как минимум один движок на экспертном уровне. Желательно, чтобы он был популярным типа Jenkins или GitLab CI.

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

Для удобства вот вам агрегированный список софтов и хардов:

Не все могут быть востребованы, но вот знания по GitLab CI или Jenkins лишними точно не будут.

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

Знание СУБД обязательно. Чем больше, тем лучше. Я сторонился этого как мог, пока работал в консалтинге. В результате карьера повернулась так, что я около пяти лет девопсил в Data Warehouse — карма, такая карма…

Логирование и мониторинг — last but not least. Само собой вы должны понимать, что у вас где работает, куда что пишет и как алертит. Должно быть понимание по сбору метрик с приложений и прочее.

BPM-язык понадобиться для понимания архитекторов и аналитиков. Знание основ DevSecOps — безопасность нынче в фаворе и, разумеется, нужно про это понимать хотя бы на уровне терминологии. Например, знать, что стоит за всякими OWASP и подобными.

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

А если не DevOps?

На прогоне этого доклада мне задали вопрос: «А что будет если поменять слово “DevOps” в докладе и заменить список хардов?» Давайте пофантазируем.

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

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

А что если не хотим инженера? Держим в голове кругозор и опыт, добавляем лидерских хардов — получаем линейного или функционального руководителя, ну или техлида команды разработки. Все зависит от «базовой» специальности.

Или, например, специалист хорошо рисует графические штуки. Если нет хардов по разработке, но есть в руках какая-нибудь Figma, получится толковый UX/UI-дизайнер.

Крутить можно и дальше, но, я думаю, суть вы поняли. Почему так получается? Не потому, что девопсы — лучшие в мире ребята, хотя нам с вами этого может и хотелось бы. Скорее причина в другом: входить в DevOps с нуля как будто бы не имеет смысла.

Эта работа не должна стать первой главой в профессиональной карьере инженера. Для нее кругозор — определяющий аспект, который, к сожалению, приобретается только через практический опыт.

С другой стороны, в текущих реалиях, как будто хороший девопс — своеобразная «вышка» среди инженеров: и жрец, и жнец, и на дуде игрец. Сродни роли СТО или, например, Solution-архитектора.

Ну и, так как вы дочитали эту статью до конца, получается, все дороги ведут в DevOps! Если хотите задать вопрос или поспорить — жду вас в комментариях.