Девопс инженер чем занимается

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

DevOps-инженеры — это многопрофильные специалисты, которые умеют автоматизировать процессы и знают, как работают разработчики, QA и менеджеры. Они умеют программировать, быстро осваивают сложные инструменты и не теряются перед незнакомой задачей. DevOps-инженеров мало — им готовы платить по 200–300 тысяч рублей, но вакансий всё равно много.

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

Чем занимается DevOps-инженер

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

Соответственно, DevOps-инженер — это специалист, который внедряет эту методологию в процесс работы:

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

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

Что нужно для старта в профессии

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

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

Источник

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

Авторизуйтесь

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

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

Что такое DevOps?

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

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

Зачем это нужно?

Участники команды работают сообща и приобретают целостное видение работы всей системы. Это способствует эффективному взаимодействию и, как следствие, улучшению качества продукта.

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

Это перспективная отрасль?

Ещё бы. Дополнительные навыки и понимание всего процесса сделают вас востребованным сотрудником. Эта специальность появилась на рынке IT относительно недавно и почти сразу же стала одной из самых популярных и востребованных. Но стоит отметить, что многие работодатели, выставляя подобную вакансию, путают DevOps-специалиста с представителями других профессий или просто ищут 2 в 1. Как итог, спрос сейчас превышает предложение.

Хорошо, а кто такой DevOps-инженер?

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

Какие проблемы он решает?

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

В чём разница между DevOps-инженером и системным администратором?

Главное отличие сисадмина от DevOps-инженера, конечно же, не в инструментарии и не в знаниях. Я считаю, что это отличие в подходе к работе. У сисадмина есть определённый, неизменный список задач, которые он выполняет ежедневно. Возможно, ещё план по развитию или автоматизации инфраструктуры. У DevOps-инженера, как части команды, таких ограничений нет. Список задач может быть крайне диверсифицированным: вчера я писал код, сегодня тестирую приложение, завтра буду делать то, что будет актуально на тот момент для команды, например, разрабатывать новую фичу, траблшутить проблему с сетью в тестовой среде или настраивать CI/CD процесс.

Какова его роль в команде?

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

С какими инструментами работает этот специалист?

Из основных инструментов DevOps-инженера я бы отметил:

Учитывая широкую зону интересов, DevOps’у приходиться пользоваться множеством инструментов и постоянно пробовать для себя что-то новое:

Что входит в обязанности DevOps-инженера?

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

Куда можно устроиться, будучи таким специалистом?

В любую крупную компанию, которая занимается разработкой, внедрением и администрированием. Дефицит DevOps-инженеров наблюдается там, где разрабатывается большое количество сервисов в рамках B2C: это мобильные операторы, банки, интернет-провайдеры, etc. К потенциальным работодателям также относятся Google, Facebook, Amazon и прочие гиганты.

Что с порогом вхождения?

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

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

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

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

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

Философия DevOps. Искусство управления IT

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

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

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

Continuous delivery. Практика непрерывных апдейтов

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

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

Руководство по DevOps. Как добиться гибкости, надёжности и безопасности мирового уровня в технологических компаниях

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

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

Дополнительные ответы экспертов

DevOps-инженер компании-разработчика российского офисного ПО МойОфис

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

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

Каждый день DevOps-инженер оперирует большим количеством инструментов. Их можно условно разделить на разные группы — к примеру, те, что связаны со средой непрерывного развёртывания (CI/CD-tools), с автоматической конфигурацией, мониторингом, облачной инфраструктурой и др. При выборе каждой технологии специалист обязан чётко осознавать, как внедрение того или иного решения повлияет на процессы в команде. Такие сотрудники должны обладать широким кругозором: это очень востребованная в наше время профессия, и настоящие профи ценятся на вес золота.

директор по развитию DBI

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

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

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

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

DevOps Engineer, TL, DataArt

Начнём с того, что DevOps — подход, а не инженер. Роль DevOps в проекте основополагающая. Проект и всё, что с ним связано, базируется на DevOps-процессах. DevOps — это связать вместе разные части всей экосистемы (Dev, QA, Ops, Sec) и автоматизировано обеспечить SDLC.

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

Чем DevOps отличается от сисадмина? Практически всем. Сисадмин отвечает за конкретные задачи: управление доступом пользователей, настройка сетевой составляющей инфраструктуры, почтовые/DNS-серверы, VMS, обновления ОС и т. д. В сложной экосистеме и процессах, связанных с проектом и SDLC, это малая часть задач, относящихся к Ops.

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

Каждый пункт можно разложить на десятки подзадач. Счёт технологий идёт на сотни. База выглядит вот так:

Источник

Кто такие DevOps?

На данный момент это чуть ли не самая дорогая позиция на рынке. Суета вокруг «DevOps» инженеров превосходит все мыслимые пределы, а тем хуже с Senior DevOps инженерами.
Я работаю руководителем отдела интеграции и автоматизации, угадайте английскую расшифровку — DevOps Manager. Отражает ли именно английская расшифровка нашу повседневную деятельность — вряд ли, а вот русский вариант в данном случае более точен. По роду моей деятельности, естественно, что мне, необходимо собеседовать будущих членов моей команды и, за прошедший год, через меня прошло человек 50, а еще столько же срезалось на прескрине с моими сотрудниками.

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

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

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

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

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

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

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

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

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

Build Engineer/Release Engineer

Весьма узкоспециализированные инженеры, появившиеся как средство стандартизации процессов сборки ПО и его релизов. В процессе введения повального Agile казалось бы они перестали быть востребованы, однако это далеко не так. Эта специализация появилась как средство стандартизации именно сборки и поставки ПО в промышленных масштабах, т.е. используя стандартные техники для всех продуктов компании. С появлением DevOps разработчиков частично утратили функции, поскольку именно разработчики стали подготавливать продукт к поставке, а учитывая изменяющуюся инфраструктуру и подход в максимально быстрой поставке без оглядки на качество со временем превратились именно в стопор изменений, поскольку следование стандартам качества неизбежно замедляет поставки. Так, постепенно, часть функционала Build/Release инженеров перекочевала на плечи системных администраторов.

Ops’ы такие разные

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

Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.

Так ли это в вашей компании? — Сомневаюсь. В большинстве случаев это или IT, или R&D.

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

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

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

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

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

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

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

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

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

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

Сколько вешать в граммах

Разброс предлагаемых зарплат для указанных вакансий — 90к-200к
Теперь хотелось бы провести параллель между денежными вознаграждениями Системных Администраторов и DevOps Engineers.

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

Сайт поиска сотрудников предлагает:
System Adminsitrators:

По стажу «DevOps»’ов использовался стаж, хоть как то затрагивающий SDLC.

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

Процесс обучения DevOps инженеров также ограничен лишь набором специфичных работ, утилит, не дает общего понимания процессов и их зависимостей. Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.

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

Так кто же они? DevOps’ы или жадные системные администраторы? =)

Как дальше жить?

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

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

Источник