Ранее я рассказал о том, что такое методология DevOps и кому она нужна. Сегодня — фокус на DevOps-специалистах: их задачах, зарплатах и навыках.
Методология DevOps — это набор практик, задача которых сократить время разработки программного обеспечения и ускорить выпуск обновлений и патчей к нему. Для этого подхода недостаточно привлечь классических админов и разработчиков. Здесь нужны отдельные специалисты, которые могут и настраивать железо, и адаптировать под него приложения.
Разбираемся, кому подходит профессия, что должен уметь специалист и как им стать.
Пишет о бизнесе и IT для Билайна, Mail.Ru Cloud Solutions и технологических стартапов.
DevOps-инженер — не просто универсал, который умеет всё понемногу, а в итоге не умеет ничего. Тут скорее симбиоз программиста и системного администратора — одновременно эволюция каждой из профессий и шаг в сторону от них.
Специалист по DevOps не решает отдельные задачи разработки и администрирования, а ускоряет весь процесс разработки программ, мобильных приложений и сайтов в IT-компаниях отделах. Он разбирается в специфике задач программистов, тестировщиков и системных администраторов и помогает им работать вместе и автоматизировать процессы — чтобы быстрее выпускать новые продукты и обновлять уже готовые.
Разберём, что конкретно делает DevOps-инженер, каким компаниям он нужен, сколько ему готовы платить и каковы перспективы роста.
Разработка ПО и сайтов никогда не была быстрым процессом. Одна из причин в том, что между разработчиками, тестировщиками и сисадминами всегда стояла стена, через которую время от времени перекидывались куски кода.
Никто не понимал, что происходит по другую сторону стены: разработчики не знали, с какими проблемами сталкиваются тестировщики и сисадмины; тестировщики ругали разработчиков за то, что их код неудобно тестировать; сисадмины ругали всех — потому что исправление ошибок требовало времени, а выпустить обновление надо было ещё вчера.
Всё это происходило из-за того, что создание ПО делилось на три отдельных процесса:
- Разработчики писали код и периодически передавали готовые большие куски тестировщикам.
- Тестировщики тестировали то, что им передали разработчики. Если что-то работало не так, они накапливали отчёты об ошибках и пачкой отправляли их назад разработчикам.
- Системные администраторы брали протестированный рабочий код и делали его доступным для пользователей — заливали на сервера компаний и выпускали новое приложение или обновление.
Чтобы как-то исправить ситуацию, светлые умы IT-индустрии решили превратить разработку в единый цикл. Они продумали процессы, создали новые стандарты разработки, и в итоге это выросло сначала в методологию, а потом и в целую культуру — DevOps.
Термин собран из двух английских слов: и . Смысл в том, что DevOps превращает разработку в непрерывный конвейер. Даже небольшие куски программ тестируются автоматически, разработчики сразу делают их удобными для ручного тестирования и запуска у пользователей, а сисадмины могут прийти с ошибками и хотелками пользователей прямо к программистам — чтобы те быстро написали новый код.
Но чтобы внедрить красоту и мощь DevOps у себя в компании, нужно:
- обучить ей программистов, тестировщиков и сисадминов;
- сделать, чтобы все понимали друг друга и хоть немного прониклись проблемами, с которыми сталкиваются коллеги;
- настроить автоматизацию, чтобы повторяющиеся процессы занимали меньше времени. Например, чтобы часть готового кода сразу тестировалась с помощью специальных инструментов.
Для решения всех этих вопросов и появилась профессия DevOps-инженера. Его главная задача — сделать так, чтобы разработка в компании шла по методологии DevOps. Для этого он должен:
- наладить общение между разработчиками, тестировщиками и сисадминами. Говорить с ними на одном языке, понимать их проблемы, хотя бы немного уметь работать с их инструментами;
- настроить инструменты процесса: репозитории кода, -системы, автоматические инструменты тестирования, средства для контейнеризации приложений;
- постоянно следить за процессом разработки: помогать всем осваиваться с новыми инструментами, обновлять автоматические системы и придумывать, что ещё можно упростить и автоматизировать.
Сейчас DevOps — стандарт разработки. Без него не получится быстро выпускать IT-продукты — есть риск, что конкуренты уйдут далеко вперёд, а компания останется без прибыли. Поэтому DevOps-инженеров стараются нанимать все, кто так или иначе связан с разработкой и осознал ценность методологии DevOps.
Такие компании делятся на три группы:
IT-компании. Зарабатывают именно благодаря программам, приложениям и сайтам, то есть разработка — основное направление их деятельности. Google, Mail.ru, Uber, Booking, 1С, разработчики игр — всё это IT-компании. Им жизненно необходим DevOps, так как без него не получится эффективно выпускать главный продукт.
Обычные компании с IT-отделом. Эти компании в основном занимаются чем-то другим: продают одежду, выдают кредиты, строят дома. Но у них есть IT-отдел, который разрабатывает сайты или мобильные приложения. Ozon, Сбербанк, «Лента» — всё это обычные компании с IT-отделом, который занимается их сайтами и приложениями. Теоретически они могут существовать и без DevOps, но тогда конкуренты их обгонят, поскольку будут выпускать приложения быстрее и завоюют больше клиентской любви.
IT-агентства. Это компании, которые занимаются разработкой под заказ — для других компаний. Например, небольшой магазин хочет сайт или приложение, но не может позволить себе целый IT-отдел — и нанимает IT-агентство, которое всё разработает. Таким компаниям DevOps нужен, чтобы быстрее и качественнее делать свою работу для клиентов.
В крупных компаниях обычно есть штат разработчиков, тестировщиков и сисадминов. Поэтому девопса приглашают именно для внедрения методологии, настройки всех процессов и автоматизации. В небольших компаниях денег на такой большой штат нет.
Поэтому часто от сисадмина ждут, что он будет выполнять ещё и работу DevOps-инженера — поддерживать разработчиков и помогать тестировщикам. Это нормальная практика в небольших компаниях — здесь не найти столько задач, чтобы понадобились и девопс, и сисадмин.
DevOps-инженеры нужны во всём мире. Например, согласно исследованию Linux Foundation и edX, в 2020 году 65% IT-компаний искали DevOps-инженеров, но только 59% искали разработчиков. Разница в процентах кажется небольшой, но на практике это сотни и тысячи открытых вакансий. Рынок DevOps растёт даже несмотря на пандемию — это значит, что спрос на девопс-инженеров будет только увеличиваться. В рейтинге лучших должностей Америки должность DevOps-инженера занимает пятое место.
По России такой статистики, к сожалению, нет. Но можно оценить общий спрос, просмотрев вакансии. На «Яндекс.Работе», которая агрегирует данные разных работных ресурсов, сейчас есть больше 8 тысяч предложений для DevOps-инженеров:
Для сравнения, вакансий по запросу «Web-разработчик» — около 7 тысяч, «JavaScript-разработчик» — 8,5 тысяч, а это самый популярный язык веб-программирования в мире. Это совсем не значит, что DevOps требуется больше — на 10–20 разработчиков нужен всего один. Но сами цифры показывают, что потребность в таких специалистах очень высока.
К слову, вакансий сисадмина гораздо больше — 23 тысячи. Но большая часть из них никак не связана с разработкой — это поиск системного администратора в небольшую компанию, который будет настраивать сеть и следить, чтобы бухгалтеры и менеджеры ничего не сломали.
Всё это значит, что DevOps-инженер легко может найти работу в России, а при желании — уехать за рубеж. И спрос на таких специалистов будет только расти.
В США DevOps зарабатывает в среднем 7–10 тысяч долларов. В России даже начинающим специалистам готовы платить от 90 тысяч рублей в месяц уже после вычета налогов, а зарплаты опытных доходят до 250 тысяч рублей и больше.
Часто в вакансиях DevOps-инженерам предлагают переезд и зарплату в долларах или евро
Сложность профессии в том, что она включает в себя два набора компетенций: знания в разработке и в администрировании. Изучать сразу оба непросто, поэтому проще стать DevOps-инженером, если вы уже сисадмин или программист. Тогда понадобится освоить специфику другого направления — и можно будет приступать к работе.
Если хочется получить профессию с нуля, лучше сначала изучить системное администрирование или программирование, немного набраться опыта — и потом осваивать специфические инструменты, необходимые именно для DevOps.
Каждый DevOps должен уметь:
- работать с GitLab, создавать пространство для коллективной работы, разрешать внутренние конфликты версий, настраивать CI/CD — конвейер, который позволяет непрерывно вносить в код небольшие изменения и быстро запускать приложения на боевых серверах;
- программировать на Python. Это понадобится, чтобы писать программы для автоматизации и в целом понимать специфику работы программистов;
- работать с контейнерами Docker — ПО для автоматического развёртывания и управления приложениями в средах с поддержкой контейнеризации;
- настраивать всю инфраструктуру разработки;
- мониторить статусы сервисов, серверов и сетевого оборудования с помощью инструментов вроде Zabbix;
- настраивать инструменты для автоматизации тестирования.
Другие компетенции зависят от компании, в которой будет работать DevOps. Например, может потребоваться умение администрировать Linux, работать с облачными технологиями, настраивать виртуализацию. Но для старта хватит базовых навыков.
Например, вот требования к DevOps в одной из вакансий. Обещают зарплату 200–250 тысяч рублей
Кроме того, понадобятся прокачанные софт-скиллы: аналитический склад ума, желание организовывать и автоматизировать, умение логически мыслить и видеть всё системно. Без них даже освоить профессию DevOps будет непросто. Также полезно уметь общаться — придётся много разговаривать с разработчиками, тестировщиками и сисадминами, обучать их методологии DevOps, презентовать свои решения руководству.
Знание английского тоже пригодится: документация ко многим программам написана на английском, а решения для каких-то проблем часто проще найти на зарубежных сайтах и форумах, так как там культура DevOps развита сильнее.
Даже на старте DevOps-инженеры зарабатывают неплохо. В основном потому, что DevOps считается следующим шагом в карьере программиста и сисадмина — пусть и шагом слегка в сторону.
Перспективы дальнейшего развития тоже есть. В первую очередь рост идёт за счёт опыта — когда DevOps отработает три-пять лет, ему будут предлагать более высокооплачиваемую работу. Опыт в этой профессии особенно важен, так как опытный DevOps сталкивался с большим количеством проблем и знает, что делать в нестандартных ситуациях, в которых даже очень умный новичок растеряется.
Чтобы получать больше, можно наращивать дополнительные компетенции: учиться строить инфраструктуру в облаке, работать с базами данных, осваивать системы оркестрации контейнеров и новые инструменты автоматизации. А вот дальше для роста понадобится прокачивать уже не конкретные навыки или знания, а опыт и умение решать нестандартные проблемы. Тогда девопса охотнее наймут в большую компанию, где всё это пригодится.
В особенно крупных обычно есть целые отделы DevOps. Здесь можно в итоге вырасти до руководителя такого отдела — то есть задавать направление развития разработки во всей компании. Конечно для этого понадобятся управленческие навыки — умение руководить, делегировать, планировать работы и презентовать решения высшему руководству.
Если вы уже разработчик или системный администратор, можно попытаться освоить профессию самостоятельно. Для этого понадобится проникнуть в специфику смежной области, освоить нужные для DevOps инструменты и разобраться в автоматизации и контейнеризации. Сисадминам обычно проще — знаний в языках программирования от DevOps ждут совсем немного, а вот в IT-инфраструктуре нужно разбираться глубже.
Если боитесь зайти не туда или не хотите тратить много времени на самостоятельное освоение, можно получить более основательное образование. Например, окончить курс «Профессия DevOps-инженер» в Skillbox — здесь сразу дают системные знания из всех областей и не грузят тем, что девопсу знать не обязательно.
Учись бесплатно: вебинары по программированию, маркетингу и дизайну.
Школа дронов для всехУчим программировать беспилотники и управлять ими.
Краткая экскурсия по миру DevOps, в которой мы расскажем о топологиях, практиках, культуре и взаимодействии команд.
Фулстек-разработчик. Любимый стек: Java + Angular, но в хорошей компании готова писать хоть на языке Ада.
Программист, специализируется на веб- и мобильной разработке. Пишет статьи, чтобы учиться самой и делиться знаниями с другими.
DevOps (Development Operations) — это популярная методология, которую применяют, чтобы повысить производительность компании — независимо от того, в какой отрасли она работает. С каждым днём всё больше компаний внедряют у себя эту модель.
Главная цель DevOps — обеспечить бесперебойную поставку ПО с помощью непрерывной интеграции рабочих процессов. При этом процессы разработки и развёртывания ускоряются и требуют меньше ресурсов, а компании экономят деньги, производя более качественные программные продукты.
В этой вводной статье мы объясним основы методологии DevOps, расскажем, как она возникла, опишем лучшие практики, ключевые топологии и главные преимущества DevOps.
Раньше в IT были отдельные команды разработки (developers, Dev-команда) и сопровождения, или поддержки (operations, Ops-команда). У этих команд были разные руководители, обязанности и цели. Во многих компаниях они даже работали на разных этажах и почти не пересекались.
Такая культура разрозненности мешала сотрудничать, а зону отчуждённости они преодолевали только в случае крайней необходимости. В общем, в то время работал принцип «отправь софт через сетку на другую сторону поля».
Успехи DevOps помогли сломать эту стену. Теперь эти команды:
- работают сообща;
- разделяют обязанности;
- вместе отвечают за каждую часть ПО на протяжении его жизненного цикла.
Сегодня DevOps широко используется в IT-индустрии. Этой методологии доверяют даже техногиганты вроде Amazon, Google, Netflix и BMC Software. И всё чаще компании задумываются, как распространить принципы DevOps на всю организацию, то есть применять их не только в IT.
До 2000 года большинство IT-компаний применяли линейный подход к разработке ПО — каскадную модель, или «водопад» (waterfall).
При таком подходе:
- уйма времени разработчиков уходила на то, чтобы написать и связать между собой большие фрагменты кода;
- тестировщики и команда сопровождения работали разобщённо и тратили больше времени на проверку этого кода.
В итоге в выпуске ПО образовывались большие перерывы (порой в несколько лет). А само оно часто выходило забагованным, и эти баги затыкали многочисленными патчами между выпусками.
С появлением методологии Agile отрасль перешла к итеративной разработке ПО с более частыми релизами. Заработавшие в этой модели непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) позволили быстрее и чаще выпускать ПО для пользователей.
DevOps-практики последовательно улучшали взаимодействие между командами разработки и сопровождения на каждом шаге жизненного цикла ПО. Так что можно с уверенностью сказать, что корни DevOps — в Agile-методологии.
- отказаться от традиционных методов работы и управления;
- пересмотреть привычный образ мышления.
По этой методологии Dev- и Ops-команды должны работать сообща и часто общаться друг с другом.
В некоторых организациях DevOps-инженеры занимаются как разработкой, так и сопровождением. Их роль охватывает много всего: они разделяют обязанности с другими командами и считают себя ответственными за весь цикл разработки.
Эти инженеры стремятся повысить производительность и качество обслуживания, чтобы принести как можно больше пользы клиентам.
Конечно же, в основе DevOps лежит не только общение и сотрудничество. Выпускать как можно более качественное ПО и как можно чаще помогает множество практик DevOps. DevOps нацелена на высокую эффективность, поэтому призывает применять средства автоматизации рутинных задач.
А теперь подробнее об этих практиках и инструментах.
Обычно разработчики вручную обновляли свой код, а затем вручную же его тестировали.
При непрерывной интеграции разработчики часто заливают изменения кода в центральный репозиторий. После внесения изменений происходит автоматическая сборка и для неё запускаются автоматизированные тесты.
Эта практика помогает быстрее выявлять ошибки и повышает качество ПО.
Это продолжение непрерывной интеграции. После сборки все изменения кода автоматически развёртываются в тестовой среде. После этого развёрнутый код прогоняют через автоматические тесты, и запускается развёртывание в производственной среде. И только неудачный тест может предотвратить запуск обновления сборки. Так разработчики могут быстрее обнаруживать и исправлять ошибки.
Все эти задачи помогают выполнять Jenkins, Bamboo, Travis, TeamCity и другие CI- и CD-утилиты.
(Подробнее о разнице между CI и CD читайте тут.)
Практика непрерывного тестирования помогает как можно раньше выявлять возможные риски на всех стадиях разработки ПО — чтобы ошибки не повлияли на конечных пользователей.
Например, когда код развёртывается на серверах сборки, запускаются автоматические модульные тесты для выявления любых ошибок. Если какие-то тесты не проходят, сборка отклоняется, а разработчик получает уведомление о том, что код нужно перепроверить.
Таким образом, код будет развёрнут в среде контроля качества (QA environment) для функционального тестирования, только если успешно пройдёт все модульные тесты.
Функциональные тесты (ФТ) проверяют работу приложения снаружи, как если бы это делал пользователь, а модульные тесты (МТ, юнит-тесты) — изнутри, с точки зрения разработчика.
ФТ помогают создать приложение, которое делает ровно то, чего хочет клиент. Они гарантируют, что вы никогда не сломаете логику работы. МТ помогают писать чистый код без ошибок — надёжный, производительный, не вызывающий утечек памяти, расширяемый и так далее.
Согласно ISTQB, модульное тестирование может проверять и функциональность — в том случае, если компонент (модуль, программу, функцию, объект, класс и так далее) можно тестировать отдельно от других.
В числе популярных инструментов для непрерывного тестирования — Selenium, Travis и Appium.
Предполагается, что приложение, инфраструктура, промежуточное ПО и сети постоянно мониторятся на предмет производительности, ошибок, безопасности и соответствия требованиям.
Большинство компаний следят за такими показателями:
- использование CPU и памяти;
- использование дискового пространства;
- действия клиентов;
- политики безопасности.
Применяя непрерывный мониторинг, вы всегда будете в курсе любых проблем на контурах: от тестирования до продакшена. Это поможет вам обеспечить высокую доступность продукта.
Популярные инструменты непрерывного мониторинга: Nagios, Sensu, Prometheus.
Инфраструктура как код (Infrastructure as Code, IaC) — это модель, при которой инфраструктура — виртуальные машины, балансировщики нагрузки, сети и так далее — настраивается и управляется программно, а не вручную. Такая инфраструктура стала необходимым компонентом DevOps в организациях, которые специально перешли на облачные платформы.
Например, Amazon Web Services (AWS) предоставляет API для программного взаимодействия со своей облачной инфраструктурой. Использование программного кода для определения конфигурации помогает сделать процесс стандартным и быстро развёртывать ресурсы в облаке.
В отличие от традиционного монолита, приложение в микросервисной архитектуре состоит из множества маленьких сервисов или компонентов. Каждый сервис отвечает за свою функциональность, а взаимодействуют они через легковесный интерфейс или API.
Микросервисная архитектура — распространённое решение в DevOps-культуре. И это не случайно. Она:
- Помогает независимо управлять ресурсами в рамках различных компонентов.
- Повышает доступность системы, так как в ней нет единой точки отказа: отказ одного из компонентов не влияет на работу остальных.
- Помогает DevOps-командам добавлять дополнительные компоненты с новыми функциями, не влияя на другие компоненты.
Способы применения DevOps сильно зависят от конкретной организации. По словам Мэттью Скелтона (Matthew Skelton) и Мануэля Пайса (Manuel Pais), чтобы внедрение DevOps проходило успешно, компании применяют разные типы топологий или командных структур. Скелтон и Пайс выделяют девять типов топологий.
Это идеальная командная структура для DevOps. В ней Dev- и Ops-группы тесно взаимодействуют друг с другом:
- Разработчики серьёзно относятся к задачам команд поддержки и прислушиваются к Ops-коллегам, если это необходимо.
- Члены команд поддержки отлично понимают, чем занимаются разработчики.
Лучше всего подходит для компаний с отдельными веб-приложениями.
Эта топология подходит для организаций с различными/несколькими службами, расположенными на облачных платформах, но с традиционным IT-отделом, реструктурировать который не планируется. При таком подходе Ops-группа — это, по сути, «инфраструктура как услуга» (, IaaS).
Некоторые организации не обладают достаточным опытом или не могут себе позволить организацию отдельной Ops-команды. В таком случае они могут поручить управление операционными аспектами ПО внешнему провайдеру.
Dev- и Ops-команды временно объединяются, чтобы достичь какой-то конкретной цели. Как только задача выполнена, команду распускают.
Такая топология подходит для слабо сплочённых команд. DevOps-адвокаты помогают и разработчикам, и группе поддержки, рассказывают им о DevOps-практиках и вовлекают в работу.
Эту топологию придумали в Google. В такой структуре есть группа, которая занимается «проектированием надёжности сайта» (Site Reliability Engineering, SRE). Разработчики доказывают сотрудникам этой команды, что их ПО соответствует стандартам. SRE могут откатить изменения, если не согласны с ними.
При контейнеризации требования к развёртыванию и времени выполнения переносятся на слой контейнеров. Это убирает часть взаимозависимостей между Dev- и Ops-командами.
Такая структура подходит для организаций с хорошо развитой инженерной культурой.
Организации, которые внедрили у себя DevOps-культуру, замечают улучшения во многих аспектах разработки ПО:
- налаживание связей между командами;
- повышение эффективности и продуктивности организации;
- увеличение скорости выпуска ПО;
- повышение лояльности клиентов (они же теперь получают ПО высокого качества);
- уверенность в том, что система доступна и надёжна, — благодаря тому, что угрозы и ошибки быстро находят и исправляют;
- содействие инновациям благодаря обмену идеями между различными командами
На этом видео Дэвид Риццо (David Rizzo), вице-президент по разработке ПО в BMC Software, и Дэвид Кеннеди, архитектор решений, рассказывают о том, как внедрили DevOps в Compuware, чтобы подстегнуть инновации, уменьшить число ошибок и уменьшить показатель .
DevOps — довольно абстрактное понятие, поэтому его сложно объяснить в паре предложений. Как я уже говорила, DevOps — это не только бизнес-модель. Это целый культурный сдвиг, который должен связать и автоматизировать разработку ПО и процессы развития и поддержки продукта в один унифицированный рабочий процесс. При этом нужно фокусироваться на скорости выпуска и высоком качестве ПО, которое соответствует всем требованиям клиентов.
DevOps-подход успешен за счёт того, что внедряет лучшие практики на каждом этапе производства софта. Организациям нужно выбрать наиболее подходящую для них топологию DevOps и стремиться к ней в долгосрочной перспективе.
При правильном применении культура DevOps может дать компаниям огромные возможности для успешного выпуска ПО.
Кто такой DevOps-инженер, почему его не существует и чем настоящий DevOps отличается от ненастоящего.
Иллюстрация: Mike lean / FreePik / Colowgee для Skillbox Media
Писал на Java до того, как в нём появились дженерики, рассказывал про DevOps до того, как появился Docker, и занимался DevRel до того, как это стали так называть. Барух основал DevRel в JFrog, когда там было 10 человек, и помог компании дойти до IPO с оценкой в 6 млрд долларов, помогая инженерам лучше делать их работу.
Теперь Барух продолжает помогать инженерам, а также помогает компаниям помогать инженерам. Он соавтор книг Liquid Software и DevOps Tools for Java Developers, является членом программных комитетов нескольких престижных конференций и выступает регулярно на таких конференциях, как KubeCon, JavaOne (мир праху его), Devoxx, QCon, DevRelCon, DevOpsDays (по всему миру), DevOops (не опечатка) и так далее. Часть его докладов есть в открытом доступе: jfrog.com/shownotes.
Есть мнение, что DevOps — это профессия. Но это не так: такой должности не существует. Это может показаться мелкой придиркой, но на самом деле разница принципиальная. Ведь, называя DevOps профессией, мы обесцениваем его. Расскажу почему.
DevOps — набор практик, методологий и культурных изменений, которые должны произойти в организации. Речь о системных преобразованиях в работе программистов, системных администраторов, инженеров, QA-специалистов в парадигме DevOps. В результате внедрения практик DevOps у них меняются к лучшему рабочие процессы — благодаря использованию новых инструментов и методологий.
Но как только мы называем человека DevOps и делаем из этого профессию, немедленно теряется весь смысл — мы сразу буквально уничтожаем все позитивные изменения, которые происходят благодаря внедрению DevOps. Ведь если мы назвали словом DevOps одного человека, то получается, что команде уже не нужно работать сообща, не нужно ничего менять, перестраивать процессы — сейчас придёт какой-то мифический DevOps и сам всё наладит.
А проблемы, для решения которых создавали DevOps, так не устранить — в итоге мы снова придём к тому, что нужно изобретать якобы новую методологию поверх старой. Можно будет придумать DevDevOps! И суть этой методологии будет примерно такой: добиться, чтобы разработчики всё-таки работали вместе с DevOps. В каждой шутке доля шутки, знаете ли.
Именно поэтому меня так бомбит от должности DevOps. Ведь гораздо легче назвать кого-то в компании этим словом, чем на самом деле внедрять глубокие поведенческие изменения, которые меняют процессы и методы взаимодействия.
Методология DevOps предполагает, что мы пытаемся организовать взаимодействие между разными людьми в разных отделах. Но при этом в DevOps привычное нам деление по отделам перестаёт существовать. Вместо этого появляются так называемые empowered teams — объединённые команды, состоящие из представителей разных профессий, которые совместно решают проблемы.
Например, это может быть команда из разработчиков, тестировщиков и инженеров, которая отвечает за инфраструктуру, облачные сервисы, продакшен, и постепенно убирает все bottleneck на пути к продакшену.
Задача такой команды — настроить процессы, чтобы появились автоматизированные . Было ручное тестирование — а теперь тестировщики работают вместе с разработчиками и выстраивают систему автотестов. Build-release-инженеры, которые занимались запуском билдов, теперь следят, чтобы система тестов работала. Безопасники, которые раньше перед релизом проверяли всё вручную, теперь взаимодействуют с разработчиками и другими членами команды — и тоже автоматизируют свои тесты на безопасность внутри пайплайна.
В результате релизы выходят чаще, становятся более надёжными и предсказуемыми, а значит, появляется больше времени на создание и выкатку новых фич — вместо того, чтобы тратить время на обслуживание текущих процессов. В этом суть DevOps.
Вместо того чтобы перестраивать работу в соответствии с методологиями DevOps, многие компании ищут мифического DevOps-инженера, который придёт и всё сделает. То есть автоматизирует процессы для всей команды.
Поэтому, когда вы видите вакансию DevOps-инженера, знайте: компания ищет человека, который будет настраивать пайплайны, к которому постоянно будут ходить разработчики и тестировщики с просьбами помочь им автоматизировать тестирование.
Пример вакансии из Telegram-канала «Удалёнщики»Скриншот: Барух Садогурский для Skillbox Media
На самом деле это имеет отношение непосредственно к DevOps. Без такого человека действительно автоматизировать процессы невозможно, но название «DevOps-инженер», конечно, неправильное. Что можно использовать вместо него? Есть несколько вариантов.
SRE (Service Reliability Engineer). Но у многих есть проблемы с этим термином, потому что они считают задачей SRE смотреть, чтобы в проде ничего не упало. Хотя на самом деле, когда этот термин появился, он подразумевал гораздо более широкий список функций и обязанностей.
Infrastructure Engineer. Это гораздо более широкий термин, и он на самом деле подходит ко всему, о чём мы говорили в контексте DevOps-задач. Это человек, который придумывает, создаёт, поддерживает пайплайны, а затем следит, чтоб они работали и правильно отражали DevOps-процессы в организации.
Production Engineer. Такой человек заботится о том, чтобы всё, что должно попасть в продакшен, оказалось там — причём именно в том виде, в котором и должно было.
Но никто из этих специалистов не может в полной мере считаться «DevOps‑инженером», потому что DevOps — это процесс совместной работы разных людей и команд.
Инструментарий мифического DevOps-инженера — это всё, что требуется для трёх главных аспектов автоматизации: построения пайплайнов, мониторинга (observability) и incident management. Эти три аспекта позволяют автоматизировать доставку кода, следить за качеством его исполнения в любой среде и реагировать на любые инциденты. Для этого нужен весь набор инструментов Infrastructure Engineer, Production Engineer и SRE.
Отвечать за все три аспекта могут как разные люди, так и один специалист — тот самый «DevOps-инженер», который на самом деле вовсе и не DevOps-инженер, а Infrastructure Engineer, Production Engineer или SRE.
Изображение: Барух Садогурский, из доклада про внедрение DevOps / Habr
Но это не значит, что один человек способен или должен отвечать за все эти процессы: он лишь позволяет этому случиться, используя правильный инструментарий. Но, опять же, чтобы DevOps работал как надо, нужна слаженная работа всех специалистов. Потому что все IT-специалисты в конечном итоге пользуются observability, пайплайнами и участвуют в incident management.
Не должно быть так, что человека назначают главным DevOps-инженером и заставляют полностью отвечать за observability, а у других специалистов к этим системам нет доступа. Нет, тот, кто отвечает за направление DevOps, должен помочь всей команде — и разработчикам, и тестировщикам, и безопасникам, и всем на свете — пользоваться инструментами для автоматизации. Да, он их выбрал, настроил и подключил, но потом, если DevOps настоящий, все в команде ими пользуются.
DevOps — это в первую очередь культурная трансформация. Речь идёт не о «нанял нового человека с названием „DevOps-инженер“ и закрыл вопрос», а о регулярной и планомерной работе с людьми — в итоге они должны понять, что мы меняем и зачем, к какой цели идём. А дальше очень осторожно и постепенно можно трансформировать организацию в парадигме DevOps.
Сначала мы внедряем DevOps на отдельных проектах, с отдельными командами, с людьми, которые уже понимают смысл таких перемен. Их успехом мы заряжаем остальных — и они тоже начинают ждать этих изменений. Самое главное — всё время проверять, что мы не сбились с курса, что у нас действительно идёт организационная трансформация, а не назначение кого-то на роль DevOps-инженера. Потому что зачастую проще делать то, что легко, а не то, что правильно.
У меня есть любимый ресурс, который называется State of DevOps Report от организации DORA (DevOps Research & Assessment). Там расписано, каких результатов можно ожидать, если трансформация произошла правильно — с ним можно сверяться, чтобы понять, действительно ли мы идём в правильную сторону.
Каких результатов можно ожидать, если трансформация произошла правильноСкриншот: Барух Садогурский для Skillbox Media
Например, если у нас исчезают bottlenecks, начинают более быстро и качественно происходить релизы, уменьшилась регрессия, исчезли интеграционные затыки, значит, мы всё делаем правильно.
А если, несмотря на то что мы назначили кого-то DevOps-инженером, никаких улучшений нет или улучшения произошли чисто технически и на короткий срок за счёт использования более хороших инструментов, значит, мы что-то делаем не так.
В DevOps-комьюнити десятки тысяч человек — в одном только русскоязычном Telegram-чате «DevOps — русскоговорящее сообщество» около 12 тысяч участников.
К сообществу относятся люди, которые занимаются внедрением DevOps в организациях или в командах. Это те самые Infrastructure Engineers, Production Engineers и SRE. Именно они сегодня драйвят всё сообщество. Но DevOps-комьюнити состоит не только из них, в него входят все, кто заинтересован в DevOps-трансформации, участвует в ней или вовлекает других.
Например, я делал доклад о важности DevOps для QA и разработчиков. И теперь разработчиков и тестировщиков, которые слушали эти доклады, я считаю полноправной частью DevOps-комьюнити. Потому что они тоже вовлечены в процесс.
Если вы хотите заявить о себе в сообществе, лучший путь — выступать на конференциях. Я, как человек, который помогает организовывать DevOops, очень рекомендую заявиться туда в качестве спикера. Мы будем рады новым лицам, новым мыслям, поможем с темой доклада и презентацией.
Конечно, мы отбираем спикеров из очень большого числа претендентов. Но это не означает, что мы берём только известных, проверенных людей. В конечном счёте всё сводится к тому, насколько интересная у вас тема, насколько хорош доклад и насколько хороши вы сами как докладчик.
Одно из направлений работы программного комитета — находить новые лица, новые голоса, новые темы и работать с ними, пока они не вырастут до того уровня, который даст им право выступать на конференции.
Да, не все преодолевают этот путь с первого раза. Есть спикеры, которых мы не взяли, потому что они были на тот момент не готовы, — однако мы продолжали им помогать, а потом включили в программу следующих конференций. Потому что к тому времени они сумели доработать свой доклад. Это всё реально, хотя и потребует усилий с вашей стороны.
Я надеюсь, что относительно скоро вернутся и митапы — с них очень легко начать свои выступления новичку, потому что аудитория небольшая и более лояльная, а попасть на них достаточно просто. Нужны только тема и идеи — а дальше вы просто пишете в программный комитет и говорите, что пока не знаете, как правильно её сформулировать и как лучше оформить доклад. Программные комитеты с удовольствием вам помогут.
Кстати, на ивентах всегда нарасхват волонтёры. Если хотите им стать, можно предложить себя в разных комьюнити во «ВКонтакте» и Telegram, написать, что готовы помогать в организации.
Как и в любом популярном сообществе, споров в DevOps-комьюнити очень много. Спорят обо всём: об инструментах, методологии, о том, кто такой DevOps‑инженер — человек или не человек. На мой взгляд, наиболее важные из этих холиваров — про роль разных людей, разных специалистов в DevOps. Например, должны ли разработчики быть вовлечены в DevOps, и если да, то насколько и в каком качестве.
Или можно ли разработчикам давать доступ к продакшену? Одни говорят, что да, конечно, согласно принципам DevOps все должны в этом участвовать, а разработчики должны сами деплоить свой код. Другие же высказывают противоположное мнение: «Ой, мы сейчас дадим им доступ в продакшен, а они его поломают и придётся всё чинить».
Есть очень много непонимания процессов, много legacy, которое растёт из устаревших принципов работы и чёткого разделения обязанностей — мол, если у нас есть сисадмины, то это их обязанность, и не надо туда лезть.
Всё это генерирует холивары, хотя методология понятна, ясна, ей уже 11 лет и на все вопросы ответили — причём не единожды. Я бы сказал, что большая часть споров возникает из-за проблем именно с организационной структурой компаний. Люди хотят, чтобы всё было так, как описано в теории. Но на практике внутри компаний всё строится совершенно иначе — и они не понимают, что с этим делать.
Такие проблемы — проблемы реального мира — меняют розовую и сказочную картинку DevOps. Особенно когда это всё накладывается на практические ограничения внутри конкретной организации.
Однако изменить сложившуюся ситуацию даже в неблагоприятных условиях вполне реально. Я рассказывал, как это сделать, в своём докладе на конференции DevOops «Устраиваем DevOps без полномочий».
Он о том, как даже мифический DevOps-инженер может задрайвить внедрение настоящего DevOps у себя в компании. Я готовил его для тех, кто действительно понимает, что такое настоящий DevOps, и хочет его имплементировать, но пока не знает, с чего начать, поскольку менять надо всю организацию. Я дал несколько советов, как повлиять на начальство и даже топ-менеджмент, чтобы они помогли сделать всё правильно.
Сколько платят
DevOps-инженеры зарабатывают больше всех в отрасли. Средний заработок таких специалистов по миру составляет от 100 до 125 тыс. долларов в год.
В США они получают 90 тыс. долларов в год (500 тыс. рублей в месяц). В Канаде им платят 122 тыс. долларов в год (670 тыс. рублей в месяц), а в UK — 67,5 тыс. фунтов стерлингов в год (490 тыс. рублей в месяц).
Что касается России, то московские компании готовы платить DevOps-специалистам от 100 до 200 тыс. рублей в месяц. В Санкт-Петербурге работодатели чуть щедрее — предлагают 160–360 тыс. рублей в месяц. В регионах указывают зарплату 100–120 тыс. рублей в месяц.
Как стать специалистом по DevOps
DevOps — это относительно новое направление в IT, поэтому устоявшегося перечня требований к DevOps-инженерам нет. В вакансиях среди требований на эту должность можно встретить как навыки администрирования Debian и CentOS, так и умение работать с дисковыми RAID-массивами.
На основании этого можно сделать вывод, что прежде всего DevOps-инженер должен иметь хороший технический кругозор. Такому человеку важно постоянно изучать новые инструменты и технологии.
Проще всего стать DevOps-инженером будет сисадмину или разработчику. У них уже есть ряд навыков, которые нужно просто развить. Главная задача — подтянуть минимальный набор знаний по DevOps, понять, как работать с инструментами автоматизации и заполнить пробелы в навыках администрирования, программирования и виртуализации.
Что еще почитать в выходные:
Кто такой DevOps-инженер
DevOps-инженер занимается внедрением методологии DevOps. Он синхронизирует все этапы создания программного продукта: от написания кода до тестирования и выпуска приложения. Такой специалист контролирует отделы разработки и администрирования плюс автоматизирует выполнение их задач, внедряя различные программные инструменты.
Фишка DevOps-инженера в том, что он совмещает множество профессий: админа, разработчика, тестировщика и менеджера.
Джо Санчес, DevOps-евангелист из VMware, компании-разработчика программного обеспечения для виртуализации, выделил ряд навыков, которыми обязан обладать DevOps-инженер. Помимо очевидного знания методологии DevOps, этот человек должен иметь опыт администрирования ОС Windows и Linux и опыт работы с инструментами автоматизации вроде Chef, Puppet, Ansible. Еще он должен уметь писать скрипты и код на паре-тройке языков и разбираться в сетевых технологиях.
DevOps-инженер отвечает за любую автоматизацию задач, связанных с настройкой и развертыванием приложений. На его плечи ложится и мониторинг программного обеспечения. Для решения этих задач он применяет различные системы управления конфигурациями, решения виртуализации и облачные инструменты для балансировки ресурсов.
Кто нанимает
Не нанимают DevOps-инженеров только стартапы. Их задача — выпустить минимально жизнеспособный продукт, чтобы проверить новую идею. В большинстве случаев стартапы могут обойтись без DevOps.