Кто такой 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

Рассматривая DevOps как масштабирование Agile-подхода на весь процесс разработки, внедрения и сопровождение ПО, можно выделить 5 основных принципов (CALMS) его реализации с целью увеличения частоты релизов и повышения ответственности команды за продукт :

  • Культура (Culture) – кросс-функциональное сотрудничество разнопрофильных специалистов и команд за счет единого информационного пространства проектного контента, открытых каналов коммуникаций и постоянного общения всех участников;
  • Автоматизация (Automatization) – использование инструментов непрерывной поставки с прогоном каждой правки кода через серию автоматизированных тестов, часто использующих облачную инфраструктуру, и последующую упаковку успешных сборок с дальнейшим перемещением на рабочий сервер с помощью автоматизированных развертываний и управления инфраструктурой как кодом через конфигурации саморазвертываемых сред;
  • Бережливость (Lean) – устранение действий с низкой полезностью и ускорение процессов, непрерывное совершенствование через регулярный ретроспективный анализ, раздельное тестирование различных инструментов, принятие поражений, возможности быстрого обнаружения проблем и их незамедлительного решения;
  • Измерения (Measurement) производительности, например, продолжительность работы пользователей с продуктом, частота появления в логах сообщений о критических ошибках – необходимы ясные и четкие критерии оценки работы, показатели эффективности процессов;
  • Обмен (Sharing) – совместная ответственность и разделение успехов, выпуск и обеспечение работы приложения осуществляются теми же людьми, что выполняли его сборку, т.е. разработчики (Developers) и операторы (Operators) взаимодействуют на каждом этапе жизненного цикла приложения.

Кто такой devops-инженер, что он делает, сколько зарабатывает и как им статьCALMS: главные принципы DevOps 

С чего начать, чтобы стать DevOps engineer?

Начните с полезных статей:

  • Эффективный DevOps: 6 способов прокачать команду и себя
  • Как IT-специалисту ввести культуру DevOps в своей компании
  • Кто такой DevOps и как им стать: план обучения

Посмотрите видео на канале ADV-IT, где подробно расписано, что учить и в каком порядке:

Получите более уверенные знания из нескольких книг:

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

DevOps — это не просто набор техник, это философия

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

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

Книга «Философия DevOps» познакомит вас с техническими, культурными и управленческими аспектами devops-культуры и позволит организовать работу так, чтобы вы получали удовольствие от разработки, поддержки и использования программного обеспечения.

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

Эберхард Вольф познакомит вас с популярными передовыми технологиями, облегчающими труд разработчиков: Docker, Chef, Vagrant, Jenkins, Graphite, ELK stack, JBehave и Gatling. Вы пройдёте через все этапы сборки, непрерывной интеграции, нагрузочного тестирования, развёртывания и контроля.

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

И помните, что от этого специалиста требуется тщательная проработка целого ряда вопросов.

Типичный рабочий день DevOps-инженера

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

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

Многие задачи занимают много времени. Иногда можно провести целый рабочий день оптимизируя что-либо или пробуя те или иные подходы. Как выглядит одна из типичных рабочих задач? Например, сейчас очень актуально создание CI/CD pipeline в Kubernetes для того, чтобы разработчик мог убедиться, что продукт в системе собирается, работает, интегрируется и готов к продвижению по тестовым средам.

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

Валидация Kubernetes YAML на соответствие лучшим практикам и политикам

Перевод

Прим. перев.: С ростом числа YAML-конфигураций для K8s-окружений всё более актуальной становится потребность в их автоматизированной проверке. Автор этого обзора не просто отобрал существующие решения для этой задачи, но и на примере Deployment’а посмотрел, как они работают. Получилось весьма информативно для тех, кому эта тема интересна.

TL;DR: В статье сравниваются шесть статических инструментов проверки и оценки YAML-файлов Kubernetes на соответствие лучшим практикам и требованиям.

Рабочие нагрузки Kubernetes, как правило, определяются в форме YAML-документов. Одна из проблем с YAML’ом — сложность задания ограничений или взаимоотношений между файлами манифестов.

О технологиях

Цифровая трансформация — насколько по твоему мнению она необходима?

Как любая хайповая тема, она и модна, и необходима. У нас очень большое количество заказов сделать загрузку «эксельки». Невероятное количество компаний ведут работы в Excel. И им надо сделать так, чтобы эта «экселька» загружалась, парсилась, превращалась в базу данных и дальше можно было работать с ней, а потом выгрузить. Цифровая трансформация должна привести к переходу на нормальные системы работы — CRM, системы контента, СМS. И отказаться от эксельки и жить в нормальном web-мире. Есть такой хороший пример. В предыдущей компании, где я работал до Бюро-Бюро, у нас были две компании-клиента. А мы смогли детально отследить, как всё происходит. В одной компании работа с клиентами шла через Excel. Там была большая база данных. Это был 2012-2013 год. Обычная CRM там не подходила — большое workflow и на обычной CRM настраивать всё это очень долго. И одна компания ушла работать в «эксельку». А вторая потратила полгода — и написала свою CRM. В итоге, первая компания через полгода после того, как они дошли до пика продаж, и у них началась работа с клиентами — они схлопнулись. Просто их служба обращений не смогла обеспечить хороший и быстрый сервис. А вторая компания со своей CRM наоборот быстро по одной кнопке отслеживали, что за клиент, как он попал к ним, что ему ответили менеджеры. Они выжили в этот пик роста — и работают до сих пор. Электронный документооборот — тоже тренд. Экономия времени. Кто оперирует быстрее информацией, тот быстрее зарабатывает. Так во всём. Если нет хорошего мониторинга и нет хорошего логирования на проекте, то инженеры не смогут понять быстро, в чём проблема. А от этого сейчас по-настоящему зависит выживаемость и успешность бизнеса. А значит надо не просто забацать красивый сайтец, а необходимо построить правильный сайт и правильную систему логирования. Цифровая трансформация нужна. Необходимо идти в ногу со временем. Если есть такие технологии, надо стараться их внедрить.

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

Будущее за machine learning и AI. Лет через пять это станет актуально. Год назад была крипта и был machine learning на хайпе. Сейчас всё поутихло. Но всё равно в ближайшие пять лет machine learning выстрелит, как я думаю. Работы ведутся — опыт и решения накапливаются.

Есть мнение, что с машинным обучением и искусственным интеллектом много профессий просто пропадёт. Это касается и учителей, и экономистов. И юристы поговаривают, что технология блокчейн подвинет определённые сферы в юриспруденции. Какие профессии в IT, как ты видишь, пропадут?

Исчезнет точно, как я думаю, верстальщики. Как мне кажется в ближайшие года три. Как говорится, запомните этот твит. (смеётся) Скорее всего, скоро напишут machine learning, который будет хорошо верстать. Что-нибудь придумают. А дальше, наверное, пропадут программисты несложных систем. Но всё равно всегда останутся программисты, которые будут проектировать и программировать ядро микрочипа. Всегда программисты будут.

Squzy — бесплатная open-source self-host система мониторинга с инцидентами и уведомлениями

Однажды знойным зимним вечером к нам пришла идея написать приложение для проверки Sitemap фирмы, в которой мы работаем, с возможностью нотификации при возникновении ошибки.
Постепенно эта идея перешла к реализации, там появились мысли по улучшению, возник мониторинг хостов, затем — мониторинг приложений, и как вишенка на торте — инциденты с нотификацией.
В итоге мы получили полноценную систему мониторинга, являющуюся полностью open-source self-host решением, не имеющим внешних коммуникаций, с полностью определяемыми пользователем инцидентами.
И в этом посте мы хотим познакомить Вас с получившимся продуктом.

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

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

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

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

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

Критика и недостатки DevOps

При всех достоинствах этого подхода, можно выделить следующие недостатки:

  • Неполнота цикла – за бортом процессов девопс остаются важные этапы жизни ПО, как разработка и анализ требований, а также проектирование архитектуры. Также возможно упущение ручного тестирование, что может быть критично в некоторых случаях . Например, если разработчики недостаточно качественно проанализировали требования и протестировали продукт, рассматривая его с точки зрения «идеального» кода, а не с позиции пользователей, результат может быть неудобным в эксплуатации .
  • Недостаточный профессионализм участников, которые разбираются во всем (разработка, тестирование, развертывание, поддержка), но поверхностно.
  • Высокая нагрузка на менеджмент – если у разработчиков и операторов нет общих целей, в этом виноваты менеджеры, не организовавшие эффективное взаимодействие между командами разнопрофильных специалистов. Для решения этой проблемы нужна новая система оценки менеджеров на основе отзывов от подчиненных .

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

Кто такой devops-инженер, что он делает, сколько зарабатывает и как им статьУспех Devops зависит от людей, процессов и технологий

Ссылки

  1. Debois, Patrick . DevopsDays. Дата обращения 19 августа 2019.
  2. Gartner Market Trends: DevOps – Not a Market, but Tool-Centric Philosophy That supports a Continuous Delivery Value Chain (англ.) : journal. — Gartner, 2015. — 18 February.
  3. Theakanath, Thomas  (недоступная ссылка). devops.com. Дата обращения 5 июня 2017.
  4.  (недоступная ссылка). Puppet Labs. Дата обращения 22 октября 2015.
  5. Humble, Jez; Farley, David. Continuous Delivery: reliable software releases through build, test, and deployment automation (англ.). — Pearson Education Inc. (англ.)русск., 2011. — ISBN 978-0-321-60191-9.

Рынок DevOps ресурсов

Давайте рассмотрим несколько вакансий на позицию DevOps от разных компаний.

Итак:

  • с 1 по 6 — системный администратор
  • 7 — немного сетевого администрирования, что тоже укладывается в сисадмина, уровня Middle
  • 8 — немного безопасности, что обязательно для сисадмина уровня Middle
  • 9-11 — Middle System Administrator
  • 12 — В зависимости от поставленных задач либо Middle System Administrator, либо Build Engineer
  • 13 — Виртуализация — Middle System Administrator, либо так называемый CloudOps, расширенные знания именно сервисов конкретной хостинг площадки, для эффективного использования денежных средств и снижения нагрузки на обслуживание

Резюмируя по данной вакансии можно сказать, что ребятам достаточно Middle/Senior System Administrator.

Кстати, не стоит сильно разделять админов на Linux/Windows. Я конечно понимаю, что сервисы и системы этих двух миров различаются, но основа у всех одна и любой уважающий себя админ знаком как с одним, так и с другим, и даже если не знаком, то для грамотного админа не составит труда ознакомится с этим.

Рассмотрим иную вакансию:

Разбираем:

  • 1 — Senior System Administrator
  • 2 — В зависимости от смысла вкладываемого в этот стэк — Middle/Senior System Administrator
  • 3 — Опыт работы, в том числе, может означать — «Кластер не подымал, но создавал и управлял виртуалками, был один Docker хост, доступ к контейнерам натил» — Middle System Administrator
  • 4 — Junior System Administrator — да, админ не умеющий писать элементарные скрипты автоматизации, вне зависимости от языка, не админ — эникей.
  • 5 — Middle System Administrator
  • 6 — Senior System Administrator

Резюмируя — Middle/Senior System Administrator

Еще одна:

Посмотрим:

  • 1 — Хм… Что ребята имеют в виду? =) Скорее всего они сами не знают что за этим скрывается
  • 2 — Build Engineer
  • 3 — Middle System Administrator
  • 4 — Софт-скил, рассматривать пока не будем, хотя Agile еще одна вещь, которую интерпретируют так, как удобно.
  • 5 — Слишком пространно — это может быть скриптовый язык, либо компилируемый. Интересно, а писал в школе на Pascal и Basic их устроит? =)

Хотелось бы также оставить ремарку относительно 3 пункта, дабы укрепить понимание, почему этот пункт покрывается сисадмином. Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все. Для примера возьмем ‘build framework’ Make, коего фреймворком я, к слову, не считаю. Да, я знаю про моду пихать Make куда угодно, где нужно и не нужно — обернуть Maven в Make например, серьезно?
По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s.

Однажды, я собеседовал парня, который использовал k8s в своей работе поверх OpenStack, и он рассказывал как развертывал сервисы на нем, однако, когда я спросил именно про OpenStack, оказалось, что он администрируется, равно как и подымается системными администраторами. Вы правда думаете, что человек поднявший OpenStack вне зависимости от того какую платформу он использует позади него не способен использовать k8s?=)
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.

Резюмируем в очередной раз — Middle/Senior System Administrator им будет достаточно.

Swarming в качестве альтернативы

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

Ключевой компанией, которая первой начала внедрять эту систему, была Cisco. В 2008 году в документе под названием Digital Swarming она представила «Модель распределенного сотрудничества и принятия решений». Концепция была впоследствии принята организацией Consortium for Service Innovation, трансформировавшись в Intelligent Swarming. Некоторые из ее принципов гласят:

  • Не должно быть разделенных на уровни групп поддержки.

  • Не должно быть эскалации от одной группы к другой.

  • Задача должна передаваться напрямую тому сотруднику, который наверняка сможет ее решить.

  • Человек, принявший обращение, отвечает за него до конца.

DevOps или как мы теряем заработную плату и будущее IT-отрасли

Самое печальное в сегодняшней ситуации то, что IT постепенно становится отраслью, где вообще нет слова “стоп” в количестве обязанностей на 1 человека.
Читая вакансии иногда уже даже видишь не 2-3 человека, а целую компанию в 1 лице, все спешат, тех.долг растёт, старое legacy на фоне новых продуктов выглядит совершенством, потому что в нём хотя бы есть дока и комменты в коде, новые продукты пишутся со скоростью света, но в итоге пользоваться ими нельзя ещё год после их написания, и зачастую этот год прибыли не приносит, более того, расходы на “облако” выше, чем продажи сервиса. Деньги инвесторов уходят на содержание ещё не работающего сервиса, но который уже выпустили в сеть как рабочий.

Ceph: Первый практический курс на русском языке

Сообщества пользователей Сeph переполнены историями, как всё сломалось, не завелось, отвалилось. Значит ли это, что технология плохая? Совсем нет. Это означает, что идёт развитие. Пользователи натыкаются на узкие места технологии, находят рецепты и решения, отправляют в апстрим патчи. Чем больше опыта с технологией, чем больше пользователей делают на неё ставку, тем больше будет описанных проблем и решений. То же самое совсем недавно было с Kubernetes.

Сeph прошёл долгий путь от проекта Сейджа Уэйла в 2007 году в его докторской диссертации до поглощения фирмы Уэйла Inktank корпорацией Red Hat в 2014 году. И сейчас многие узкие места Сeph уже известны, многие кейсы от практиков можно изучить и взять на заметку.

1 сентября стартует бета-тест нашего практического видеокурса по Ceph. Научим работать с технологией стабильно и эффективно.