company_banner

DevOps-инженеров не существует. Кто тогда существует, и что с этим делать?


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


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


    Такие вакансии можно всячески порицать, но факт остается фактом: их много, и так устроен рынок на данный момент. Мы сделали девопс-конференцию и открыто заявляем: «DevOops — не для DevOps-инженеров». Тут многим покажется странным и диким: почему люди, делающие совершенно коммерческое мероприятие, идут против рынка. Сейчас всё объясним.


    Про культуру и процессы


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


    Например, описанием разницы между сисадминским и SRE-шным подходом к service management начинается знаменитая Google SRE Book. Интересные исследования проведены в рамках опроса DORA — видно, что самые лучшие разработчики каким-то образом умудряются деплоить новые изменения на продакшн быстрее, чем раз в час. Они же тестируют руками не больше 10% (это видно по прошлогоднему DORA). Каким образом у них это получается? «Excel or die» – говорит один из заголовков отчета. За подробным обсуждением этой статистики в разрезе тестирования можно обратиться к кейноуту Баруха Садогурского «У нас DevOps. Давайте уволим всех тестировщиков» на другой нашей конференции, Heisenbug.


    «Когда в товарищах согласья нет,
    На лад их дело не пойдет,
    И выйдет из него не дело, только мука.
    Однажды Лебедь, Рак да Щука…»

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


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


    Замкнутый круг


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


    Представьте: вчера вы в Химках лудили шаурму, а сегодня — вы уже большой человек, сениор рекрутер. Тут целый процесс поиска и отбора кандидатов, всё непросто, понимать надо. Допустим, начальник отдела говорит: найди специалиста по X. Приписываем к X слово «инженер», и дело в шляпе. Нужен Linux? Ну это точно Linux-инженер, хочешь DevOps — DevOps-инженер. Вакансия состоит не только из заголовка, но внутри нужно вписать какой-то текст. Проще всего — вписать набор кейвордов из Гугла, кому сколько хватит фантазии. DevOps состоит из двух слов — «Dev» и «Ops», значит, надо склеивать кейворды, относящиеся к разработчикам и администраторам, все в одну кучу. Так появляются вакансии про владение 42 языками программирования и 20 лет использования Kubernetes и Swarm одновременно. Рабочая схема.


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


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


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


    Безусловно, кроме сисадминов, переименовавшихся в «девопсы», есть и другие участники — например, профессиональные SRE или разработчики Infrastructure-as-Code.


    Чем люди занимаются в DevOps (на самом деле)


    Итак, вы хотите продвинуться в изучении и применении практик DevOps. Но как это сделать, в какую сторону смотреть? Очевидно, слепо руководствоваться популярными ключевыми словами не стоит.


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


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


    «Культура задаётся основными ценностями организации. Обычно люди этого не замечают, но мы, работая в консалтинге на протяжении многих лет, привыкли это подмечать. Ты заходишь в компанию и буквально через несколько минут начинаешь чувствовать, что происходит. Мы называем это «ароматом». Иногда этот аромат действительно хорош. Иногда он вызывает тошноту. (…) Ты не можешь изменить культуру до того, как были осознаны ценности и убеждения, которые стоят за конкретными действиями. Поведение наблюдать легко, а искать убеждения — сложно. DevOps — это как раз отличный пример того, как всё становится сложнее и сложнее».

    Есть и техническая часть вопроса, конечно. Если у тебя новый код на тестирование попадает через месяц, а в релизе оказывается только через год, и ускорить всё это физически невозможно — до хороших практик можно не дожить. Хорошие практики поддерживаются хорошими инструментами. Например, держа в голове идею Infrastructure-as-Code, можно использовать что угодно, от AWS CloudFormation и Terraform до Chef-Ansible-Puppet. Всё это надо знать и уметь, и вот это уже вполне инженерная дисциплина. Важно не путать причину со следствиями: вначале вы работаете по принципам SRE и только потом уже воплощаете эти принципы в виде каких-то конкретных технических решений. При этом SRE — это очень комплексная методология, которая рассказывает не про то, как настроить Jenkins, а про пять основных принципов:


    • Улучшение взаимодействия между ролями и отделами
    • Принятие ошибок как неотъемлемой части работы
    • Постепенное осуществление изменений
    • Использование тулинга и прочей автоматики
    • Измерение всего, что можно измерить

    Это не просто какой-то набор утверждений, а конкретное руководство к действию. Например, на пути принятия ошибок нужно будет разобраться с рисками, измерить доступность и недоступность сервисов с помощью чего-то вроде SLI (service level indicators) и SLO (service level objectives), научиться писать постмортемы и сделать так, чтобы писать их было не страшно.


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


    В свою очередь, сейчас стали очень популярными решения Cloud Native. Согласно современному пониманию Cloud Native Computing Foundation, технологии Cloud Native позволяют организациям разрабатывать и запускать масштабируемые приложения в современных динамичных средах, таких как публичные, приватные и гибридные облака. В качестве примера можно привести контейнеры, сервис-меши, микросервисы, неизменяемую инфраструктуру и декларативные API. Все эти техники позволяют слабосвязанным системам оставаться эластичными, управляемыми и хорошо наблюдаемыми. Хорошая автоматика позволяет инженерам делать большие изменения часто и с предсказуемыми результатами, не превращая это в адский труд. Все это поддерживается стеком из всем известных инструментов, таких как Docker и Kubernetes.


    Это довольно непростое и развесистое определение связано с тем, что и область довольно непростая. С одной стороны утверждается, что новые изменения в эту систему должны добавляться достаточно просто. С другой стороны, чтобы разобраться в том, как сделать некую контейнеризованную среду, в которой слабосвязанные сервисы живут на software-defined инфраструктуре и поставляются туда с помощью непрерывного CI/CD, и выстроить вокруг всего этого DevOps-практики — на всем этом надо не одну собаку съесть.


    Что со всем этим делать


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


    Мы же делаем конференцию DevOops 2020 Moscow, которая предоставляет возможность глубже разобраться в вещах, о которых мы только что поговорили. Для этого есть несколько групп докладов:


    • Процессы и культура;
    • Site Reliability Engineering;
    • Cloud Native;

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


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


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


    • Разработчиков, которые занимаются инфраструктурой. Для вас больше всего подойдут группы докладов про SRE и Cloud Native.
    • Системных администраторов. Тут сложнее. DevOops — не про системное администрирование. К счастью, на тему системного администрирования есть масса прекрасных конференций, книг, статей, видео в интернете и т.п. С другой стороны, если вам интересно развиваться в плане понимания культуры и процессов, изучения облачных технологий и подробностей жизни с Cloud Native, то мы будем рады вас видеть! Подумайте вот о чем: вот вы занимаетесь админством, а дальше что вы будете делать? Чтобы внезапно не оказаться в неприятной ситуации, стоит учиться уже сейчас.

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



    Слайд из доклада Konstantin Diener в Мюнхене


    DevOops 2020 Moscow пройдет 29-30 апреля в Москве, билеты уже можно приобрести на официальном сайте.


    Кроме того, вы можете подать свой доклад до 8 февраля. Обратите внимание, что при заполнении формы вы должны выбрать целевую аудиторию, которой ваш доклад принесет больше пользы (внутри списка зарыт сюрприз).

    JUG Ru Group
    228,12
    Конференции для программистов и сочувствующих. 18+
    Поделиться публикацией

    Комментарии 34

      +9

      напомнило


      Заголовок спойлера


        +10
        К сожалению, конференции помогают против псевдо-девопса примерно как агитационные листовки против употребления запрещённых веществ, то есть почти никак. А едет это всё потому что даже к пятидесяти годам у менеджмента массово сохраняется святая вера в Деда Мороза, который сейчас придёт и всё починит вместо них. Раньше основной корпус сказочных решал составляли аутсорсеры, ещё раньше — консультанты, теперь девопсы вот. И на этой вот вере торговцу лицом можно ехать очень долго, ведь если бы менеджер сам был в состоянии хотя бы запросить/посчитать нужные метрики и сделать выводы, девопс-инженер был бы не нужен — менеджер бы имеющимся людям задач поставил и по этим метрикам контролировал эффективность выполения.

          +1

          Конференции вообще не панацея, конечно. Потому что это капля в море информационного потока. Но мы стараемся, стараемся.

            +3

            Конференции это способ заработать бабла разными способами на модных темах. По факту они все скатились в саморекламу и перетирание одних и тех же тем.


            У меня даже желание есть доклад на тему "Все лгут. Почему все доклады п… вранье" сделать. =). Но это будет не очень корректно по отношению к бывшим работодателям.

            +3
            Многорукие шивы, связывающие код с инфраструктурой в DevOps методологии таки есть и нужны. И термин «Девопс-инженер» как «инженер в процессе DevOps» вполне себе адекватный.
              +2
              Так, похоже, DevOps — истерия пока все еще продолжается.
                +3

                Скорее уж DevOops истерия. Это когда нанимаешь DevOps'ов, сжигаешь десятилетний бюджет какой-нибудь небогатой африканской страны, а на выходе имеешь продакшн в огне )

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

                  Если отмести всю шелуху типа облаков, автоматизации администрирования и прочих пуговиц, которые обычно пришивают к DevOps — в сухом остатке будет красивое и ёмкое Release Engineer.


                  что с этим делать

                  Работодателю — продолжать публиковать вакансии для DevOps, аккуратно опуская планку (сарказм некоторый, мда-с...). Соискателю — определяться, на каком он берегу )))

                    +1
                    в сухом остатке будет красивое и ёмкое Release Engineer.
                    это не так.

                    Еще Monitoring Engineer, Infrastructure Engineer, Cloud Engineer etc.

                      +1
                      Я бы сказал Build/Release Engineer, чтобы полностью описать чем заниматься. Тк билдить можно что угодно — начиная от артефакта Мавеном, до инфраструктуры в облаках Терраформом.
                      +8
                      На самом деле жуткая ситуация, когда приходится называть себя devops-инженером, зная что это некорректно, только для того, чтобы неграмотный hr на тебя хотя бы обратил внимание
                        +3

                        Обнял.

                          +1

                          В точку.

                            0

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

                            +1
                            Так появляются вакансии про владение 42 языками программирования и 20 лет использования Kubernetes и Swarm одновременно

                            «5+ лет опыта администрирования Windows Server 2016» (условно говоря — ещё с версии «Technical Preview» имел сервер на нем) — вполне могут в вакансии сисадмина написать?
                              +3
                              Всё очень просто. В чьих-то светлых головах devops == «уволим нафиг сисадминов, заживём». Но, во-первых, потом оказывается, что совсем уж без админов жить не выходит, а во-вторых админы мигрируют массово «в devops» — ведь именно им этим и занимались ещё до того, как слово было придумано.
                                +9
                                Все знакомые админы просто переименовали себя в DevOps и подняли оплату труда в 2-3 раза. Я вообще никогда не мог понять почему админы часто получали меньше разработчиков, но теперь они решили эту проблемы простым ренеймингом на глобальном уровне, что супер круто. Хотя, «админ» звучит как-то теплее =)
                                  +2

                                  Так и есть да. Написал в резюме devops. Занимаюсь тем же чем занимался. ЗП выросла.

                                    +1
                                    sed -i s/ренеймингом/ребрендингом/g

                                    Так делают не все, и чаще под внешним давлением работодателя или списка вакансий, составленного HR Generalist из статьи.


                                    Надеюсь, что останусь востребован во время этой истории, называя себя не devops-инженером или SRE-инженером, а всего лишь инженером автоматизации систем, он же systems automation engineer

                                    +5
                                    Ну ок. Как тогда называется человек, который умеет в Docker, Ansible, мониторинг, настройку CI и вот это всё? Сисадмин для облаков? SRE? Давайте просто придумаем другое название и попросим эйчаров писать его вместо DevOps-инженера.

                                    Если в вакансии перечислен рандомный набор кейвордов, то это конечно дно. А если эти технологии действительно используются в компании и нужен человек, который имеет опыт в этих технологиях и будет с ними работать, то что плохого? Вкансии разработчиков на конкретных языках (Python, Go, PHP) вас ведь не смущают.

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

                                    Сам работаю devops-инженером, если что.
                                      +3

                                      В терминологии DevOps такой человек называется "op" (во множественном числе — "ops").

                                        +1

                                        Вопрос не в том, что он умеет, а какие задачи делает. Если задача — заниматься site reliability, то это SRE. Если задача — программировать программы на Python — это программист. В первом приближении, можно дальше уточнять. Например, если ты занимаешься безопасностью, то вполне возможно ты Security and Privacy Engineer, а если разрабатываешь управление датацентром — то Data Center Controls Engineer.


                                        На всякий случай позову jbaruch


                                        Вкансии разработчиков на конкретных языках (Python, Go, PHP) вас ведь не смущают.

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


                                        За свою специальность скажу: если Java-разработчик не знает, что такое Docker и Ansible (если Docker и Ansible используются в его компании), и не может в случае чего завести джобу на Jenkins или хотя бы объяснить админам, что ему нужна джоба на Jenkins, у него большие проблемы. Тоже самое и с админом, который не представляет, как накидать скрипт на Python.

                                          +2

                                          А если PHP-разработчик занимается параллельно с разработкой разворачиванием к8с кластеров для разных окрежений, включая политики безопасности и ресурсные, написанием CI/CD конфигов и скриптов, то разработчик ли он ещё?

                                            +2
                                            Можно сколько угодно говорить, что Девопс это неграмотно, но история уже свершилась — и девопсы существуют.
                                              +3

                                              SRE это такая же модная хрень для обозначения админа работающего с отказоустойчивым хайлоадом, появившаяся после книжки гугла, в которой налито 2 ведра воды. Из разряда "делай хорошо, хорошо будет". Спасибо КО, без вас то не знали.

                                                –2

                                                А по-моему, это тренд: придумать скандальную формулировку и запустить с ней конференцию. Например:


                                                • почему не существует DevOps инженеров.
                                                • почему team lead должен получать не более 15 тысяч в месяц.
                                                • почему senior developer — это миф.

                                                Настройка деплоймента и поставка продукта на различные конфигурации — не тривиальная задача. Я могу прийти в команду, потратить время на развёртывание проекта локально. Могу столкнуться с тем, что подключение нового сервиса к инфраструктуре проекта невозможно. Кто будет решать эти проблемы? Я точно не буду: мне ещё тесты писать. Вот тоже бред пишете: путаете unit testing с тестированием UI. Вторым занимается тестировщик. Первым — программист. А DevOps отвечает за работу их инструментов: линтера, дебагера, тестов на сборке, автоматизированной системы тестирования.


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

                                              +5
                                              Вот так заходишь с утра почитать хабр, а тебя не существует.
                                                +3

                                                That's the idea

                                                +2

                                                Если за это платят компании х2-3-4 денег от уровня сисадмина, то почему бы нет? Все же довольны.

                                                  +1

                                                  "В молодую развивающуюся компанию требуется DevOps-инженер DevOps-манагер"
                                                  Так лучше?

                                                    +1
                                                    Если ДевОпс — это человек, налаживающий междисциплинарное взаимоотношение, то кто-же тогда аналитик?
                                                      +1
                                                      Расскажите им, что devops-инженеров не существует :) aws.amazon.com/ru/certification/certified-devops-engineer-professional
                                                        +1
                                                        «Я мыслю, следовательно, я есмь»

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое