Кто такой devops-инженер? 12 ответов на часто задаваемые вопросы

DevOps сейчас

Итак, что же такое DevOps в 2021 году? Инструменты, люди, процессы? Умение писать на Bash скрипты для кофемашины?

Как  и многие фреймворки гибких методологий, DevOps не имеет четкого определения, и каждая компания будет объяснять его по-своему. Но его главная идея DevOps — это культура сотрудничества, и эта идея оставалась неизменной всегда. Об этом говорили Патрик Дебуа и Эндрю Клэй Шафер, Пол Хэммонд и Джон Оллспоу, а теперь об этом говорят люди вроде Баруха Садогурского.

А что тогда изменилось за 12 лет существования понятия? Во-первых, практики DevOps постепенно меняли общий подход к поставке ПО. Из новомодного слова все превращалось в общепринятую норму. Как в свое время Agile стал стандартом в разработке, так и DevOps становится стандартом в поставке.

А во-вторых, как и Agile в свое время, идея получает дальнейшее развитие

Например, в 2020 году Патрик Дебуа выступал на нашей конференции DevOops c докладом DevSecOps: More of the same — back to the roots, и в частности рассказывал про то, как важно вернуться к основам и посмотреть, что стоит за модным словом «Devops».  А сейчас, уже практически из зрелой методологии вырастает новая —  DevSecOps. Ее жизнеспособность покажет время и практика, а пока еще раз напомним, что самое важное в DevOps — это люди и культура

Почему никто не стремится к 100% доступности

SRE исходит из предположения, что ошибки и сбои неизбежны. Более того, на них рассчитывают.

Оценивая доступность, говорят о «девятках»:

• две девятки — 99%,
• три девятки — 99,9%,
• четыре девятки — 99,99%,
• пять девяток — 99,999%.

Пять девяток — это чуть больше 5 минут даунтайма в год, две девятки — это 3,5 дня даунтайма.

Стремиться к повышению доступности нормально, однако чем ближе она к 100%, тем выше стоимость и техническая сложность сервиса. В какой-то момент происходит уменьшение ROI — отдача инвестиций снижается.

Например, переход от двух девяток к трём уменьшает даунтайм на три с лишним дня в год. Заметный прогресс! А вот переход с четырёх девяток до пяти уменьшает даунтайм всего на 47 минут. Для бизнеса это может быть не критично. При этом затраты на повышение доступности могут превышать рост выручки.

При постановке целей учитывают также надёжность окружающих компонентов. Пользователь не заметит переход стабильности приложения от 99,99% к 99,999%, если стабильность его смартфона 99%. Грубо говоря, из 10 сбоев приложения 8 приходится на ОС. Пользователь к этому привык, поэтому на один лишний раз в год не обратит внимания.

Как стать DevOps-инженером

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

Но на первом плане — качественное базовое образование в IT.

Имея классическое университетское образование, молодые специалисты сами выбирают путь, который приведет их в профессию мечты:

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

В любом случае, без университетского образования в сфере IT не обойтись.

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

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

Для тех, кто нацелен много работать над своим образованием и над реальными результатами, лучшим выбором будут вузы Германии.

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

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

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

По окончании учебы выпускники немецких вузов имеют право устроиться на работу в Германии.

Советуем изучить: Подбор программ обучения в вузах Германии

DevOps-инженер — это новая, но уже очень востребованная и важная профессия в сфере IT. Спрос на рынке труда на этих специалистов высок, а их зарплаты очень привлекательны. Эта профессия требует глубоких знаний и постоянного самообучения, но прежде всего — крепкого качественного образования. Вузы Германии могут похвалиться не только традиционно высоким качеством обучения и новаторскими методами преподавания, но и всесторонней поддержкой своих студентов: хорошей учебной базой, практикой, стажировками, которые помогают сформировать настоящего конкурентоспособного специалиста. И все это бесплатно. Для поступления в немецкий вуз вам не нужно иметь высокие баллы ЕГЭ; потребуются высокие академические успехи, хороший немецкий язык и правильно оформленный пакет документов. По всем организационным вопросам вы можете проконсультироваться со специалистом.

История появления

Термин «DevOps» был популяризован серией встреч «DevOps Days», прошедших в 2009 году в Бельгии . Одной из наиболее важных теоретических работ по DevOps считается книга Патрика Дюбуа, Джина Ким, Джеза Хамбл и Джона Уиллис «Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях», впервые опубликованная на английском языке в 2016 году. К этому основателей нескольких софтверных компаний и независимых ИТ-консультантов подтолкнул накопленный опыт работы в крупных проектах . 

Однако само понятие DevOps зародилось в начале 2000-х годов, когда в ИТ-мире больших корпораций возникла проблема рассогласования рабочих процессов, при которой нормальная работа программного продукта нарушена из-за функционального и организационного разделения тех, кто пишет код, и тех, кто выполняет его развертывание и поддержку. У разработчиков и специалистов по эксплуатации продукта часто бывают разные и даже противоречащие друг другу цели, руководители подразделений и ключевые показатели эффективности. Рабочие места разнопрофильных участников жизненного цикла ПО зачастую располагаются в разных локациях. Такая разрозненность и нарушение коммуникации внутри компании приводит к удлинению сроков решения задач, сверхурочной работе, сорванным релизам и недовольству клиентов 1.

Концепция DevOps предлагает решать эту проблему с помощью приложения принципов Agile не только к разработке и тестированию, но и к процессам эксплуатации ПО, т.е. к развертыванию и поддержке. Таким образом, популярность DevOps возникла, в том числе благодаря распространению Agile-практик, ориентированных на ускорение процессов поставки готового продукта и увеличение количества выпускаемых версий. Кроме того, дополнительным драйвером развития девопс стала микросервисная архитектура, когда система состоит из набора отдельных слабосвязанных модулей, реализация каждого из которых находится в зоне ответственности одного человека, который разрабатывает, тестирует и развертывает ПО. Благодаря небольшому размеру каждого модуля (сервиса), его архитектура может создаваться путем непрерывного рефакторинга, что уменьшает трудоемкость предварительного проектирования и позволяет постоянно выпускать новые релизы программного продукта 2.

Концепция DevOps как пересечение разработки, эксплуатации и тестирования

От DevOps к SRE

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

Цели команд противоречат друг другу. Чтобы разрешить эти противоречия, была создана методология DevOps. Она предполагает уменьшение разрозненности, принятие ошибок, опору на автоматизацию и другие принципы.

Проблема в том, что долгое время не было чёткого понимания, как воплощать принципы DevOps на практике. Редкая конференция по этой методологии обходилась без доклада «Что такое DevOps?». Все соглашались с заложенными идеями, но мало кто понимал, как их реализовать.

Ситуация изменилась в 2016 году, когда Google выпустила книгу «Site Reliability Engineering». В этой книге описывалась конкретная реализация DevOps. С неё и началось распространение SRE-подхода, который сейчас применяется во многих международных IT-компаниях.

DevOps — это философия. SRE — реализация этой философии. Если DevOps — это интерфейс в языке программирования, то SRE — конкретный класс, который реализует DevOps.

Карьера DevOps Engineer и перспективы профессии в будущем

Строить карьеру в DevOps можно двумя способами.

• Вертикально: повышая уровень компетенций и нарабатывая опыт — от Junior до Senior.
• Горизонтально: прокачивая hard skills в одном из направлений, на которые сегодня разделяется DevOps, и сконцентрировавшись на одном сегменте задач.

Спрос на специалистов в сфере DevOps по данным отчета DevOps Institute Upskilling: Enterprise DevOps Skills Report за 2019 год

Финансовая сторона профессии выглядит привлекательно, карьерная стратегия ясна, но где гарантии, что DevOps — не один из тех модных трендов, о которых все забудут пару лет спустя?

Cultural norms

Job satisfaction

Ранние исследования, проведенные DevOps Research and Assessment (DORA), показали, что удовлетворенность работой является важным фактором, предопределяющим эффективность работы организации. Вовлеченность сотрудников, выполняющих осмысленную работу, повышает ценность бизнеса.

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

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

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

Learning culture

Исследование от команды DORA показывает, что любая организационная культура, которая ценит обучение, влияет на эффективность доставки софта следующими вещами:
повышением частоты деплоев сокращением времени для изменений, для восстановления сервиса и сокращением количества падений после изменений сильной командной культурой. Атмосфера обучения в вашей организации напрямую зависит от степени, с которой ваша организация относится к обучению, как к стратегии:

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

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

What is DevSecOps?

DevSecOps is DevOps that continuously integrates and automates security throughout the DevOps lifecycle — from start to finish, from planning through feedback and back to planning again.

Another way to put this is that DevSecOps is what DevOps was supposed to be from the start. But two of the early significant (and for a time insurmountable) challenges of DevOps adoption were integrating security expertise into cross-functional teams (a cultural problem), and implementing security automation into the DevOps lifecycle (a technical issue). Security came to be perceived as the «Team of ‘No,'» and as an expensive bottleneck in many DevOps practices.

DevSecOps emerged as a specific effort to integrate and automate security as originally intended. In DevSecOps, security is a “first class” citizen and stakeholder along with development and Operations, and brings security into the development process with a product focus.

Watch ‘What is DevSecOps?’ to learn more about DevSecOps principles, benefits and use cases:

Так кто же такие DevOps инженеры?

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

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

Появилась «замечательная» вещь — docker. Почему замечательная? Да только лишь потому, что создание изоляции в chroot или jail, равно как OpenVZ, требовало нетривиальных знаний ОС, в контру утилите позволяющей элементарно создать изолированную среду приложения на неком хосте со всем необходимым внутри и передать бразды правления разработке вновь, а системному администратору управлять только лишь одним хостом, обеспечивая его безопасность и высокую доступность — логичное упрощение. Но прогресс не стоит на месте и системы вновь становятся все сложнее и сложнее, компонентов все больше и больше, один хост уже не удовлетворяет потребностям системы и необходимо строить кластеры, мы вновь возвращаемся к системным администраторам, которые способны построить данные системы.

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

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

Изучайте программирование

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

Например, для написания конвейера Jenkins в декларативном виде (как код) требуется знания Groovy; кастомный модуль Ansible требует знания Python; для написания оператора Kubernetes требуется опыт работы с Go.

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

• Bash/Shell

• Python

• Go

Go действительно становится популярным в сфере DevOps. Его используют многие инструменты. Например, Kubernetes и Terraform написаны на Go. JFrog исследовал внедрение Go во время GopherCon, и 18 % респондентов заявили, что используют этот язык для работы, связанной с DevOps.

Кто такой DevOPS-инженер и что он делает?

Разобравшись, как работает методика DevOps уже гораздо проще понять объем и специфику работы инженера. Фактически, в своей работе он совмещает функции разработчика, тестировщика и специалиста по эксплуатации.

Перед специалистом стоит несколько основных задач:

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

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

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

Результат адекватной работы программиста DevOps – эффективные, предсказуемые и безопасные операционные процессы, стабильная и регулярная поставка продукта и его обновлений без сбоев в работе.

Чтобы выполнять свои задачи специалист должен владеть целым набором инструментов:

• Git, Mercurial, Subversion, CVS – для распределенного контроля версий.
• Применять Docker, Rocket, Kubernetes – для контейнеризации.
• Jenkins, TeamCity, Bamboo, GitLab, Github Actions, AWS CodePipeline – для непрерывной интеграции.
• Puppet, Chef, Ansible, Terraform – для управления инфраструктурой.
• VMware DRS, AWS, Google Cloud Platform, Microsoft Azure, Huawei Cloud, Яндекс Облако, Mail.ru Cloud Solutions – для работы с облачной архитектурой.
• Vagrant, lxc – для виртуализации.
• Prometheus, Grafana, Zabbix – для мониторинга.

Также, специалист должен владеть языками программирования. Практика показывает, что нет одного или нескольких «правильных» языков, главное то, что человек умеет использовать свои знания для автоматизации. Но чаще всего инженеры знают Python, Ruby, Node.js, Go, Rust, C или C++. Не лишним будет умение работать с оболочкой Bash, дистрибутивом Ubuntu, знание баз данных MySQL.

Базовый набор инструментов можно вместить в достаточно простую схему:

DevOPS Tools

Но в процессе развития, работы над разными проектами и в разных компаниях, список инструментов хорошего инженера может существенно расшириться… Примерно так:

В рамках этой профессии можно выделить несколько основных ролей со своей узкой специализацией:

Карьера и заработная плата DevOps‑инженера

На рынке наблюдается огромная нехватка DevOps‑специалистов. Это касается как России, так и зарубежных стран.

Вакансий достаточно много, особенно на специализированных IT-сайтах и сервисах по поиску работы. Больше предложений для сотрудников на полный день в офисе. Если же говорить о фрилансе, то тут меньше проектов.

Специалисты могут найти работу в банке, IT-компаниях и в любых других организациях, которые разрабатывают приложения или управляют большим количеством серверов. К примеру, DevOps‑инженеры есть в таких известных гигантах, как Amazon, Facebook, Netflix.

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

Часто на эту должность идут бывшие сисадмины, с которыми DevOps-инженеров иногда путают. Эти две должности может и похожи чем-то в определенном плане, но все же подход к работе у них разный. Системный администратор всегда знает, что ему надо выполнить завтра. Он имеет список задач, которому следует.

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

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

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

Новички на старте получают 40–80 тыс. руб., а средняя зарплата по России находится на уровне 100–200 тыс. руб.

В регионах DevOps-инженерам платят от 100 000 до 140 000 руб. В Москве и Санкт-Петербурге зарплаты выше: от 120 000 до 400 000 руб.

Для сравнения: американские специалисты в среднем получают 85–95 тыс. $ в год. Если переводить в рубли, то это около 500–550 тыс. руб. в месяц.

DevOps engineer может дорасти до системного архитектора или IT-директора и, соответственно, получать еще чуть больше.

Методы и средства реализации: как работает DevOps

Методологически девопс поддерживает принципы Agile и Continuous delivery – непрерывной поставки ПО. Для организации процессов могут быть использованы такие методы Agile, как Scrum, Kanban и их варианты.

В плане инструментов для автоматизации процессов разработки, тестирования и развертывания используются следующие технологии и популярные средства их реализации:

• Распределенный контроль версий (Git, Mercurial, Subversion, CVS);
• Контейнеризация (Docker, Rocket, Kubernetes);
• Непрерывная интеграция – сборка и тестирование конечного продукта (Jenkins, TeamCity, Bamboo);
• Управление инфраструктурой как кодом (Puppet, Chef, Ansible);
• Виртуализация (Vagrant);
• Балансировка облачных ресурсов (VMware DRS).

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

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

Инструменты Devops