что такое девопс простыми словами
Зачем нужен DevOps и кто такие DevOps-специалисты
Когда приложение не работает, меньше всего хочется услышать от коллег фразу «проблема на вашей стороне». В итоге страдают пользователи – а им всё равно, какая часть команды несет ответственность за поломку. Культура DevOps появилась как раз затем, чтобы сплотить разработку и поддержку и объединить их вокруг общей ответственности за конечный продукт.
Какие практики входят в понятие DevOps и зачем они нужны? Чем занимаются DevOps-инженеры и что они должны уметь? На эти и другие вопросы отвечают эксперты из EPAM: Кирилл Сергеев, системный инженер и DevOps-евангелист, и Игорь Бойко, ведущий системный инженер и координатор одной из DevOps-команд компании.
Зачем нужен DevOps?
Раньше между разработчиками и поддержкой (т. н. operations) существовал барьер. Звучит парадоксально, но у них были разные цели и KPI, хотя они и делали общее дело. Целью разработки было как можно быстрее реализовать бизнес-требования и добавить их в работающий продукт. Поддержка отвечала за то, чтобы приложение стабильно работало – а любые изменения ставят стабильность под угрозу. Налицо конфликт интересов – DevOps появился, чтобы его решить.
Что такое DevOps?
Вопрос хороший – и спорный: окончательно в мире об этом пока не договорились. В ЕРАМ считают, что DevOps объединяет в себе технологии, процессы и культуру взаимодействия внутри команды. Это объединение нацелено на непрерывную доставку ценностей конечным пользователям.
Кирилл Сергеев: «Разработчики пишут код, тестировщики его проверяют, а администраторы устанавливают финальный продукт на производственное окружение. Долгое время эти части команды были несколько разрознены, а потом появилась идея объединить их общим процессом. Так появились DevOps-практики».
Настал тот день, когда разработчики и системные инженеры заинтересовались работой друг друга. Барьер между производством и поддержкой стал стираться. Так появился DevOps, в который входят практики, культура и порядок взаимодействия в команде.
В чем состоит суть DevOps-культуры?
В том, что ответственность за конечный результат лежит на каждом из участников команды. Самое интересное и сложное в философии DevOps – понять, что конкретный человек не просто отвечает за свой этап работы, а несет ответственность за то, как будет работать весь продукт. Проблема лежит не на чьей-то стороне – она общая, и каждый член команды помогает ее решить.
Важнейшее положение DevOps-культуры – именно решать проблему, а не просто применять DevOps-практики. Более того, эти практики внедряют не «на чьей-то стороне», а в весь продукт. Проекту нужен не сам по себе DevOps-инженер – ему нужно решение проблемы, а роль DevOps-инженера может быть распределена по нескольким членам команды с разной специализацией.
Какие бывают DevOps-практики?
DevOps-практики покрывают все этапы жизненного цикла ПО.
Игорь Бойко: «Идеальный случай – когда мы начинаем использовать DevOps-практики прямо при инициации проекта. Вместе с архитекторами мы планируем, какой у приложения будет архитектурный ландшафт, где оно будет располагаться и как масштабироваться, выбираем платформу. Сейчас в моде микросервисная архитектура – для нее мы выбираем систему оркестрации: нужно уметь управлять каждым элементом приложения по отдельности и обновлять его независимо от других. Еще одна практика – это “инфраструктура как код”. Так называют подход, при котором инфраструктура проекта создается и управляется при помощи кода, а не через прямое взаимодействие с серверами.
Дальше мы переходим на этап разработки. Здесь одна из крупнейших практик – построение CI/CD: нужно помочь разработчикам интегрировать изменения в продукт быстро, мелкими порциями, чаще и безболезненней. CI/CD покрывает и проверку кода, и заливку мастера в кодовую базу, и разворачивание приложения на тестовых и продуктивных средах.
На этапах CI/CD код проходит через quality gates. С их помощью проверяют, чтобы код, который вышел с рабочей станции разработчика, соответствовал заданным критериям качества. Здесь добавляется юнит- и UI-тестирование. Для быстрого, безболезненного и фокусированного разворачивания продукта можно выбрать подходящий тип деплоймента.
DevOps-практикам есть место и на стадии поддержки готового продукта. Их применяют для мониторинга, обратной связи, безопасности, внедрения изменений. На все эти задачи DevOps смотрит с точки зрения постоянных улучшений. Мы сводим к минимуму повторяющиеся операции, автоматизируем их. Сюда же относятся миграции, расширение приложения, поддержка работоспособности».
Чем полезны DevOps-практики?
Если бы мы писали учебник по современным практикам DevOps, на его первой странице значились бы три пункта: автоматизация, ускорение релиза и быстрая обратная связь от пользователей.
Кирилл Сергеев: «Первое – это автоматизация. Все взаимодействия в команде мы можем автоматизировать: написали код – выкатили – проверили – установили – собрали фидбэк – вернулись в начало. Всё это – автоматически.
Второе – ускорение выхода релиза и даже упрощение разработки. Заказчику всегда важно, чтобы продукт вышел на рынок как можно скорее и начал приносить пользу раньше, чем аналоги конкурентов. Процесс доставки продукта можно бесконечно улучшать: сокращать время, добавлять дополнительные контрольные метки, совершенствовать мониторинг.
Третье – это ускорение обратной связи от пользователя. Если у него есть замечания, мы можем сразу же вносить корректировки и тут же обновлять приложение».
Как соотносятся понятия «системный инженер», «билд-инженер» и «DevOps-инженер»?
Они пересекаются, но относятся к немного разным сферам.
Системный инженер в ЕРАМ – это должность. Они бывают разных уровней: от джуниора до chief-специалиста.
Билд-инженер – это скорее роль, которую можно выполнять на проекте. Сейчас так называют людей, ответственных за CI/CD.
DevOps-инженером называют специалиста, который внедряет на проекте DevOps-практики.
Если суммировать всё это, получается примерно следующее: человек в должности системного инженера исполняет на проекте роль билд-инженера и занимается там внедрением DevOps-практик.
Чем именно занимается DevOps-инженер?
DevOps-инженеры собирают воедино все части, из которых состоит проект. Они знают специфику работы программистов, тестировщиков, системных администраторов и помогают упростить их работу. Они понимают потребности и требования бизнеса, его роль в процессе разработки – и строят процесс с учетом интересов заказчика.
Мы много говорили про автоматизацию – ею DevOps-инженеры занимаются в первую очередь. Это очень большой пункт, в который, помимо прочего, входит подготовка окружения.
Кирилл Сергеев: «Прежде чем внедрять обновления в продукт, их нужно протестировать на стороннем окружении. Его готовят DevOps-инженеры. Они же насаждают на проекте DevOps-культуру в целом: внедряют DevOps-практики на всех слоях своих проектов. Эти три принципа: автоматизация, упрощение, ускорение – они привносят всюду, куда могут дотянуться».
Что должен знать DevOps-инженер?
По большому счету, у него должны быть знания из разных областей: программирование, работа с операционными системами, базами данных, системами сборки и конфигураций. К ним добавляется умение работать с облачной инфраструктурой, системами оркестрации, мониторинга.
1. Языки программирования
DevOps-инженеры знают несколько базовых языков для автоматизации и могут, например, сказать программисту: «Давай ты будешь делать установку кода не руками, а с помощью нашего скрипта, который всё автоматизирует? К нему мы подготовим config-файл, его будет удобно читать и тебе, и нам – и мы в любой момент сможем его изменить. А еще мы будем видеть, кто, когда и для чего вносит в него изменения».
DevOps-инженер может выучить один или несколько из этих языков: Python, Groovy, Bash, Powershell, Ruby, Go. Знать их на глубинном уровне не требуется – достаточно основ синтаксиса, принципов ООП, умения писать несложные скрипты для автоматизации.
2. Операционные системы
DevOps-инженер должен понимать, на каком сервере будет установлен продукт, в какой среде будет запускаться, с какими сервисами будет взаимодействовать. Можно выбрать специализацию на Windows или Linux-семействе.
3. Системы контроля версий
Без знаний системы контроля версий DevOps-инженеру никуда. Git – одна из самых популярных систем в настоящий момент.
4. Облачные провайдеры
AWS, Google, Azure – особенно если мы говорим про Windows-направление.
Кирилл Сергеев: «Облачные провайдеры предоставляют нам виртуальные сервера, которые прекрасно ложатся на рельсы CI/CD.
Установка десяти физических серверов требует порядка ста ручных операций. Каждый сервер нужно вручную запустить, установить и настроить нужную операционную систему, установить наше приложение на этих десяти серверах, а потом десять раз всё перепроверить. Облачные сервисы заменяют эту процедуру десятью строчками кода, и хороший DevOps-инженер должен уметь ими оперировать. Так он экономит время, силы и деньги – и для заказчика, и для компании».
5. Системы оркестрации: Docker и Kubernetes
Кирилл Сергеев: «Виртуальные сервера разделены на контейнеры, в каждый из которых мы можем установить наше приложение. Когда контейнеров много, надо ими управлять: один включить, другой выключить, где-то сделать бэкапы. Это становится довольно сложным делом, для которого нужна система оркестрации.
Раньше каждым приложением занимался отдельный сервер – любые изменения в его работе могли повлиять на исправность приложения. Благодаря контейнерам приложения становятся изолированными и запускаются по отдельности – каждое на своей виртуальной машине. Если происходит сбой, не нужно тратить время на поиск причины. Проще уничтожить старый контейнер и добавить новый».
6. Системы конфигураций: Chef, Ansible, Puppet
Когда необходимо обслуживать целый парк серверов, приходится делать много однотипных операций. Это долго и сложно, а еще ручная работа повышает шанс ошибки. Тут на помощь приходят системы конфигураций. С их помощью создают скрипт, который удобно читать и программистами, и DevOps-инженерами, и системными администраторами. Этот скрипт помогает проводить одинаковые операции на серверах автоматически. Так ручных операций (и, следовательно, ошибок) становится меньше.
Какую карьеру может построить DevOps-инженер?
Развиваться можно и горизонтально, и вертикально.
Игорь Бойко: «С точки зрения горизонтального развития, у DevOps-инженеров сейчас самые широкие перспективы. Всё постоянно меняется, и наращивать навыки можно по самым разным направлениям: от систем контроля версий до мониторинга, от управления конфигурациями до баз данных.
Можно стать системным архитектором, если сотруднику интересно разобраться, как работает приложение на всех этапах своего жизненного цикла – от разработки до поддержки».
Как стать DevOps-инженером?
А также можно посмотреть актуальные тренинги по DevOps на сайте Тренинг-центра EPAM.
Больше информации о DevOps-направлении на сайте.
Кто такой DevOps и когда он не нужен
Тема DevOps за последние несколько лет стала очень популярной. Многие мечтают в нее влиться, но, как показывает практика, часто только из-за уровня зарплат.
Некоторые указывают в своем резюме DevOps, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «девопсом». Это, конечно, не так.
Несколько последних лет я занимаюсь в основном внедрением DevOps в различных компаниях. До этого более 20 лет работал на позициях от системного администратора до IT-директора. Сейчас — DevOps Lead Engineer в Playgendary.
Кто такой DevOps
Идея написать статью возникла после очередного вопроса: «кто такой DevOps?». До сих пор нет устоявшегося термина, что или кто это. Часть ответов уже есть в этом видео. Сначала выделю главные тезисы из него, а затем поделюсь своими наблюдениями и мыслями.
DevOps — не специалист, которого можно нанять, не набор утилит, и не отдел разработчиков с инженерами.
DevOps — это философия и методология.
Другими словами, это набор практик, который помогает активно взаимодействовать разработчикам с системными администраторами. То есть связывать и интегрировать рабочие процессы друг в друга.
С появлением DevOps структура и роли специалистов остались такими же (есть девелоперы, есть инженеры), но изменились правила взаимодействия. Размылись границы между отделами.
Цели DevOps можно описать тремя пунктами:
И это только часть инструментов DevOps
Уже больше 2-х лет собеседую людей на позицию DevOps-инженера и ко мне пришло осознание, насколько важно четко понимать суть термина. Накопился специфический опыт, наблюдения и мысли, которыми хочу поделиться.
Из опыта собеседований я вижу такую картину: у специалистов, которые считают DevOps должностью, обычно есть недопонимания с коллегами.
Был яркий пример. На собеседование пришел молодой человек с кучей умных слов в резюме. На последних трех местах работы у него был стаж 5-6 месяцев. Из двух стартапов ушел, потому что «не взлетели». А вот насчет третьей компании сказал, что там его никто не понимает: разработчики пишут код по Windows, а директор заставляет этот код «заворачивать» в обычный Docker и встраивать в CI/CD-пайплайн. Парень много чего негативного рассказал по поводу его текущего места работы и его коллегах — так и хотелось ответить: «Так ты слона не продашь».
Потом я задал ему вопрос, который в моем списке один из первых для каждого кандидата.
— Что лично для тебя означает DevOps?
— Вообще или как я это воспринимаю?
Меня интересовало его личное мнение. Он знал теорию и происхождение термина, но был категорически с ними не согласен. Он считал, что DevOps — должность. Здесь и кроется корень его проблем. Как и других специалистов с таким же мнением.
Работодатели, наслушавшись о «магии DevOps», хотят найти человека, который придёт и эту «магию» создаст. А соискатели из разряда «DevOps — это должность» не понимают, что при таком подходе они не смогут оправдать ожидания. И, вообще, написали в своём резюме DevOps, потому что это тренд и за это много платят.
Методология и философия DevOps
Методология бывает теоретической и практической. В нашем случае — второе. Как я упоминал выше, DevOps — это набор практик и стратегий, применяемых для достижения заявленных целей. И в каждом случае, в зависимости от бизнес-процессов компании, он может существенно отличаться. Что не делает его лучше или хуже.
Методология DevOps — лишь средство достижения поставленных целей.
Теперь о том, что такое философия DevOps. И это, наверное, самый трудный вопрос.
Сформулировать краткий и емкий ответ достаточно сложно, потому что он еще не формализован. И так как адепты философии DevOps больше занимаются практикой — на философствования просто нет времени. Тем не менее, это очень важный процесс. Причём напрямую относящийся к инженерной деятельности. Есть даже специализированная область познания — философия техники.
В моём ВУЗе такого предмета не было, пришлось изучать все самостоятельно по тем материалам, которые смог найти в 90-е. Тема необязательная для инженерного образования, отсюда и отсутствие формализации ответа. Но те люди, которые серьёзно погрузились в DevOps, начинают ощущать некий «дух» или «неосознанную всеобъемлющность» всех процессов компании.
Я на своем опыте постарался формализовать некоторые «постулаты» этой философии. Получилось следующее:
Что делает DevOps
Ключевое слово здесь — коммуникации. Очень много коммуникаций, инициатором которых должен быть как раз тот самый DevOps-инженер. Почему так? Потому что это философия и методология, а уже потом инженерные знания.
Про западный рынок труда говорить со 100% уверенностью не могу. Но вот о рынке DevOps в России знаю довольно много. Кроме сотен собеседований, за последние полтора года я участвовал в сотне технических пресейлов по услуге «Внедрение DevOps» для крупных российский компаний и банков.
В России DevOps ещё очень молодая, но уже трендовая тема. Насколько я знаю, только по Москве дефицит таких специалистов за 2019 год составил более 1000 человек. А слово Kubernetes для работодателей почти как красная тряпка для быка. Адепты этого инструмента готовы использовать его даже там, где это не нужно и экономически не выгодно. Работодатель не всегда понимает в каких случаях, что уместнее использовать, а при должном развертывании содержание кластера Kubernetes стоит в 2-3 раза дороже, чем развертывание приложения по обычной кластерной схеме. Используйте его там, где он действительно нужен.
Внедрение DevOps с точки зрения денег — дорого. И оправдано только там, где приносит экономическую выгоду в других областях, а не само по себе.
DevOps-инженеры, фактически, первопроходцы — именно они первыми должны внедрять в компании эту методологию и выстраивать процессы. Чтобы это было успешно, специалист должен постоянно взаимодействовать с сотрудниками и коллегами на всех уровнях. Как я обычно говорю, в процесс внедрения DevOps должны быть вовлечены все сотрудники компании: от уборщицы до CEO. И это обязательное условие. Если самый младший член команды не будет знать и понимать, что такое DevOps и зачем выполняются те или иные организационные действия, то успешного внедрения не получится.
Также DevOps-инженеру нужно время от времени использовать административный ресурс. Например, для преодоления «сопротивления среды» — когда команда не готова принять инструменты и методологию DevOps.
Разработчик должен писать только код и тесты. Для этого ему не нужен супермощный ноутбук, на котором он будет разворачивать и поддерживать локально всю инфраструктуру проекта. Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.
Но есть команды, которые, наоборот, рады внедрению новых инструментов и методов, и живо участвуют в этом процессе. Хотя даже в таком случае коммуникации между DevOps-инженером и командой никто не отменял.
Когда DevOps не нужен
Бывают ситуации, когда DevOps не нужен. Это факт — его нужно понять и принять.
В первую очередь, это касается любых компаний (особенно малого бизнеса), когда их прибыль не зависит напрямую от наличия или отсутствия IT-продуктов, предоставляющих информационные сервисы клиентам. И здесь речь не о сайте компании, будь он статической «визиткой» или с динамическими новостными блоками и т.п.
DevOps требуется, когда от наличия этих информационных сервисов по взаимодействию с клиентом, их качества и таргетированности зависит удовлетворенность вашего клиента и его желание вновь возвращаться именно к вам.
Ярким примером является один известный банк. У компании нет привычных клиентских офисов, документооборот осуществляется через почту или курьеров, а множество сотрудников работает из дома. Компания перестала быть просто банком и, на мой взгляд, превратилась в IT-компанию с развитыми DevOps-технологиями.
Много других примеров и лекций можно найти в записях тематических митапов и конференций. Часть из них я посетил лично — это очень полезный опыт для тех, кто хочет развиваться в этом направлении. Вот ссылки на YouTube-каналы с хорошими лекциями и материалами по DevOps:
Если ваша компания торгует рыбой в небольшом магазинчике и единственным IT-продуктом являются две конфигурации 1С: Предприятие (Бухгалтерия и УНФ), то вряд ли есть смысл говорить о DevOps.
Если же вы работаете на крупном торговом и производственном предприятии (например, производите охотничьи ружья), то стоит задуматься. Вы можете проявить инициативу и донести своему руководству перспективы внедрения DevOps. Ну, и заодно, возглавить этот процесс. Проактивная позиция — один из важных постулатов философии DevOps.
Размер и объем годового финансового оборота не является основным критерием для определения, нужен ли вашей компании DevOps.
Представим себе крупное промышленное предприятие, которое не взаимодействует напрямую с клиентами. Например, некоторые автоконцерны и автомобилестроительные компании. Сейчас не уверен, но, из моего прошлого опыта, много лет всё взаимодействие с клиентами осуществлялось по электронной почте и телефону.
Их клиенты — это ограниченный список автомобильных дилеров. И к каждому прикреплен специалист от производителя. Весь внутренний документооборот происходит через ERP SAP. Внутренние сотрудники, по сути, являются клиентами информационной системы. Но управление этой ИС осуществляется классическими средствами управления кластерными системами. Что исключает возможность использования практик DevOps.
Отсюда вывод: для подобных предприятий внедрение DevOps не является чем-то критически важным, если вспомнить цели методологии из начала статьи. Но не исключаю, что какие-то инструменты DevOps используются ими сегодня.
С другой стороны, есть много небольших компаний, которые разрабатывают программное обеспечение с использованием методологии, философии, практик и инструментов DevOps. И считают, что затраты на внедрение DevOps являются расходами, позволяющими им эффективно конкурировать на рынке ПО. Примеры таких компаний можно увидеть здесь.
Основной критерий для понимания нужен ли DevOps: какое значение ваши IT-продукты имеют для компании и клиентов.
Если основной продукт компании, приносящий прибыль, это ПО — вам нужен DevOps. И не так важно, если зарабатываете реальные деньги вы с помощью других товаров. Сюда также можно отнести интернет-магазины или мобильные приложения с играми.
Любые игры существуют благодаря финансированию: прямому или косвенному со стороны игроков. В Playgendary мы разрабатываем бесплатные мобильные игры, в непосредственном создании которых участвуют более 200 человек. Как мы используем DevOps?
Да точно также, как описано выше. Я постоянно общаюсь с разработчиками и тестировщиками, провожу внутреннее обучение сотрудников методологии и инструментам DevOps.
Сейчас у нас активно используется Jenkins как инструмент CI/CD pipelines для выполнения всех сборочных конвейеров с Unity и последующего деплоя в App Store и Play Market. Еще из классического набора инструментов:
Вместо заключения
Хочу закончить следующей мыслью: чтобы стать DevOps-инженером высокой квалификации, жизненно необходимо научиться живому общению с людьми.
DevOps-инженер — командный игрок. И никак иначе. Инициатива в общении с коллегами должна исходить от него самого, а не под воздействием каких-то обстоятельств. DevOps-специалист должен увидеть и предложить наилучшее решение для команды.
И да, внедрение любого решения потребует множества обсуждений, а к концу может вообще измениться. Самостоятельно развиваясь, предлагая и осуществляя свои задумки — такой человек представляет все большую ценность как для команды, так и для работодателя. Что, в конечном счёте, отражается и на размере его ежемесячного вознаграждения или в виде дополнительных премий.
DevOps — что это, зачем, и насколько востребовано?
Несколько лет назад в IT появилась новая специальность DevOps-инженер. Она очень быстро стала одной из наиболее популярных и востребованных на рынке. Но вот парадокс — частично популярность DevOps объясняется тем, что компании, нанимающие таких специалистов, часто путают их с представителями других профессий.
Эта статья посвящена разбору нюансов профессии DevOps, текущем положении на рынке и перспективам. Мы разобрались в этом сложном вопросе при помощи декана факультета DevOps в GeekBrains в онлайн-университете GeekUniversity Дмитрия Бурковского.
Итак, что же такое DevOps?
Сам термин расшифровывается как Development Operations. Это не столько специальность, сколько подход к организации работы в средней или крупной компании при подготовке продукта или сервиса. Дело в том, что в процессе подготовки участвуют разные отделы одной компании, и действия их далеко не всегда хорошо скоординированы.
Так, разработчики, например, не всегда знают о том, какие проблемы возникают у пользователей, которые работают с выпущенной программой или сервисом. Техподдержка — знает все отлично, но она может быть не в курсе того, что «внутри» ПО. И тут приходит на помощь DevOps-инженер, который помогает координировать процесс разработки, способствует автоматизации процессов, улучшает их прозрачность.
Концепция DevOps объединяет людей, процессы и инструменты.
Что должен знать и уметь DevOps-инженер?
По мнению одного из наиболее известных адептов концепции DevOps Джо Санчеса, представитель профессии должен хорошо понимать нюансы самой концепции, иметь опыт администрирования как Windows, так и Linux-систем, понимать программный код, написанный на разных ЯП, работать Chef, Puppet, Ansible. Понятно, что для разбора кода нужно знать несколько языков программирования, и не просто знать, но и иметь опыт разработки. А еще очень желателен опыт тестирования готовых программных продуктов и сервисов.
Но это в идеале, такой уровень опыта и знаний найдется далеко не у каждого представителя IT-сферы. Вот набор минимально необходимых для хорошего DevOps знаний и опыта:
Кроме того, DevOps-cпециалист должен понимать потребности и требования бизнеса, видеть его роль в процессе разработки и уметь строить процесс с учетом интересом заказчика.
А что с порогом входа?
Список знаний и опыта не зря был подан выше. Теперь становится проще понять, кто же может стать DevOps-специалистом. Получается, что проще всего перейти в эту профессию для представителей других IT-специальностей, в особенности — системным администраторам и разработчикам. И тем, и другим можно быстро нарастить недостающий объем опыта и знаний. Половина необходимого набора у них уже есть, а нередко — и больше половины.
А еще отличные DevOps-инженеры получаются из тестировщиков. Они знают, что и как работает, в курсе недостатков и недоработок ПО и «железа». Можно сказать, что тестировщик, который знает языки программирования и умеет писать программы — без пяти минут DevOps.
А вот представителю нетехнической специальности, никогда не имевшему дело ни с разработкой, ни с системным администрированием, будет сложно. Конечно, ничего невозможного нет, но все же новичкам нужно адекватно оценивать свои силы. Времени на получение требуемого «багажа» потребуется немало.
Куда может устроиться DevOps?
В крупную компанию, работа которой напрямую либо косвенно связана с разработкой приложений и администрированием «железа». Максимальный дефицит в DevOps-инженерах — у компаний, предоставляющих большое количество сервисов конечным потребителям. Это банки, операторы связи, крупнейшие интернет-провайдеры и т.п. Среди компаний, которые активно нанимают на работу DevOps-инженеров — Google, Facebook, Amazon, Adobe.
Внедряют DevOps и стартапы с мелким бизнесом, но все же для многих из этих компаний приглашение DevOps-инженеров, скорее, дань моде, чем реальная необходимость. Конечно, бывают и исключения, но их не так много. Небольшим компаниям нужен, скорее «и швец, и жнец, и на дуде игрец», то есть человек, который в состоянии работать по ряду направлений. Хороший СТО способен справиться со всем этим. Дело в том, что малому бизнесу важна скорость работы, оптимизация рабочих процессов критична для среднего и крупного бизнеса.
Вот немного вакансий (следить за новыми можно на Хабр Карьере по этой ссылке):
Зарплата DevOps в России и мире
В России средняя зарплата DevOps-инженера составляет около 132 тысяч рублей в месяц. Это расчеты калькулятора зарплат сервиса Хабр Карьера, произведенные на основании 170 анкет на 2-е полугодие 2020 года. Да, выборка не такая уж и большая, но в качестве «средней температуры по больнице» вполне подходит.
Есть зарплаты в размере 250 тысяч рублей, есть — около 80 тысяч и чуть ниже. Все зависит от компании, квалификации и самого специалиста, конечно.
Что касается других стран, то статистика по зарплатам тоже известна. Хорошую работу провели специалисты Stack Overflow, проанализировав анкеты около 90 тысяч человек — не только DevOps, но и вообще представителей технических специальностей. Оказалось, что Engineering Manager и как раз DevOps получают больше всех.
В качестве заключения стоит сказать, что востребованность DevOps постепенно растет, спрос на специалистов любого уровня превышает предложение. Так что если есть желание — можно попробовать себя в этой сфере. Правда, нужно помнить, что одного желания — недостаточно. Нужно постоянно развиваться, учиться и работать.