Профессия: инженер devops

Сколько зарабатывает DevOps Engineer?

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

• Юниор — до 1 года опыта;
• Средний — от 1 до 3 лет опыта;
• Старший — опыт работы более 3-х лет.

Не менее важна позиция работодателя: традиционно инженеры DevOps в Москве зарабатывают больше.

Средняя зарплата DevOps-инженера в Москве за 2019 / начало 2020 года по данным портала занятостиotrud.com

Градация наблюдается и в регионах страны.

Средняя зарплата DevOps-инженера в регионах России на 2019 / начало 2020 года по данным портала занятостиotrud.com

Кроме того, размер выплаты напрямую зависит от объема выполняемых работ и уровня компании. В целом, по статистике сервиса Habr Career, средняя зарплата DevOps во второй половине 2020 года составила 155000 рублей.

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

Узнайте больше о системах *nix

Мы живем в эпоху, когда не можем жить без систем Linux/Unix. Вы должны лучше понять и получить практические знания о различных дистрибутивах Linux, широко используемых организациями (RHEL, Centos, Ubuntu, CoreOS и т.д.).

Согласно тематическому исследованию Linux Foundation, 90 % рабочей нагрузки в публичных облаках обрабатывается на Linux.

Вот еще одно интересное исследование Redhat, в котором показаны различные дистрибутивы Linux, используемые в публичных облаках:

Теперь у вас есть достаточно причин, по которым вам стоит сосредоточиться на Linux.

Когда дело доходит до Linux, это всё про терминал, графический интерфейс менее предпочтителен в мире *nix.

Для запуска Linux-серверов вы можете использовать VirtualBox или AWS/GCP/Azure и множество других облачных платформ.

Начать изучение можно со следующего:

• Разберитесь в процессе загрузки Linux.

• Установите и настройте веб-серверы (Apache, Nginx, Tomcat и т.д.). И узнайте, как работают веб-серверы.

• Узнайте, как работают процессы Linux.

• Узнайте, как работает SSH.

• Почитайте о различных файловых системах.

• Изучите ведение системного журналирования, мониторинга и устранения неполадок.

• Узнайте о важных протоколах (SSL, TLS, TCP, UDP, FTP, SFTP, SCP, SSH).

• Научитесь управлять сервисами и попробуйте создать сервис самостоятельно (Initd, Systemd).

• Попробуйте разместить статические и динамические сайты на веб-серверах.

• Настройте балансировщики нагрузки и реверс-прокси (Nginx, HAproxy и т.д.).

• Сломайте что-нибудь и научитесь устранять неполадки.

Цели и задачи DevOps-инженера

Перечисленные выше навыки и знания необходимы для достижения следующих целей:

• повысить безопасность разработки;
• сократить время, затрачиваемое на разработку программного обеспечения;
• минимизировать риск появления ошибок в новых версиях;
• поиск ошибок и их своевременное исправление;
• координация работы и автоматизация процессов разработки и выпуска ПО.

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

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

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

В чём состоит работа DevOps-инженера

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

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

Всё это происходило из-за того, что создание ПО делилось на три отдельных процесса:

• Разработчики писали код и периодически передавали готовые большие куски тестировщикам.
• Тестировщики тестировали то, что им передали разработчики. Если что-то работало не так, они накапливали отчёты об ошибках и пачкой отправляли их назад разработчикам.
• Системные администраторы брали протестированный рабочий код и делали его доступным для пользователей — заливали на сервера компаний и выпускали новое приложение или обновление.

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

Термин собран из двух английских слов: development и operations. Смысл в том, что DevOps превращает разработку в непрерывный конвейер. Даже небольшие куски программ тестируются автоматически, разработчики сразу делают их удобными для ручного тестирования и запуска у пользователей, а сисадмины могут прийти с ошибками и хотелками пользователей прямо к программистам — чтобы те быстро написали новый код.

Но чтобы внедрить красоту и мощь DevOps у себя в компании, нужно:

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

Для решения всех этих вопросов и появилась профессия DevOps-инженера. Его главная задача — сделать так, чтобы разработка в компании шла по методологии DevOps. Для этого он должен:

• наладить общение между разработчиками, тестировщиками и сисадминами. Говорить с ними на одном языке, понимать их проблемы, хотя бы немного уметь работать с их инструментами;
• настроить инструменты процесса: репозитории кода, CI/CD-системы, автоматические инструменты тестирования, средства для контейнеризации приложений;
• постоянно следить за процессом разработки: помогать всем осваиваться с новыми инструментами, обновлять автоматические системы и придумывать, что ещё можно упростить и автоматизировать.

Кому подойдет DevOps-трансформация

Внедрение методологии DevOps в процесс разработки может быть полезен практически каждой организации, деятельность которой связана с разработкой приложений и работой с большим количеством серверов. Крупнейшие мировые ИТ-гиганты (Facebook, Amazon, Adobe) и высокотехнологичные компании уже несколько лет активно ищут и нанимают в штат DevOps-инженеров. Девопс также активно используется в финтехе и телекоммуникациях.

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

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

В качестве альтернативы компания может воспользоваться услугой Managed DevOps.

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

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

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

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

Успех Devops зависит от людей, процессов и технологий

CI / CD

Краткое описание технологии

Далее я буду использовать эти термины на английском языкеcontinuous

• Continuous Integration – это начальный шаг эволюции. После отправки нового кода на сервер, мы ожидаем получить быструю обратную связь, что с нашими изменениями все в порядке. Обычно CI включает запуск инструментов статического анализа кода и модульные/внутренние API тесты Это позволяет получать информацию о нашем коде уже несколько секунд/минут спустя.
• Continuous Delivery является более продвинутым шагом, на котором мы запускаем интеграционные/UI-тесты. Однако на данном этапе мы не получаем результаты так же быстро, как в случае с CI. Во-первых, эти типы тестов требует больше времени для прохождения. Во-вторых, перед запуском мы должны развернуть наши изменения на test/staging — среде. Более того, если мы говорим о мобильной разработке, то появляется дополнительный этап для создания сборки нашего приложения.
• Continuous Deployment предполагает, что мы автоматически выпускаем (release) наши изменения на production, если все приемочные тесты были пройдены на предыдущих этапах. В дополнение к этому после этапа release можно настроить различные этапы, такие как запуск smoke — тестов на production и сбор интересующих метрик. Continuous Deployment возможно только при хорошем покрытии автоматизированными тестами. Если требуются какие-то ручные вмешательства, в том числе и тестирование, то это больше не Continuous (непрерывное). Тогда мы можем говорить, что наш конвейер соответствует только практике Continuous Delivery.

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

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

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

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

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

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

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

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

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

Опыт:

1. до 3-х лет — Junior
2. до 6-ти лет — Middle
3. более 6-ти — Senior

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

1. Junior — 2 года — 50к руб.
2. Middle — 5 лет — 70к руб.
3. Senior — 11 лет — 100к руб.

DevOps Engineers:

1. Junior — 2 года — 100к руб.
2. Middle — 3 года — 160к руб.
3. Senior — 6 лет — 220к руб.

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

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

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

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

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

DevOps-инженер

По запросу «DevOps инженер» HeadHunter тоже выдает около 3 тыс. вакансий. Подготовленный читатель скажет: «DevOps — это не специальность, DevOps — это философия, набор инструментов». Так и есть!

Что такое DevOps

DevOps — это набор практик для повышения эффективности процессов разработки (Development) и эксплуатации (Operation) софта.

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

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

• тесное взаимодействие разработчиков и отдела эксплуатации;
• настройку и автоматизацию процессов непрерывной интеграции и непрерывной поставки кода (CI/CD).

Второй пункт часто невозможен без перехода на микросервисную архитектуру. Как правило, она реализуется с помощью Docker и Kubernetes.

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

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

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

Требования, совпадающие с требованиям к системным администраторам:

• знание и опыт администрирования Linux, систем контейнеризации (Docker, Kubernetes), баз данных, LAMP;
• понимание принципов работы TCP/IP;
• опыт администрирования SQL и NoSQL баз данных;
• опыт настройки систем мониторинга и логирования (Zabbix, ELK, Grafana, Prometheus);
• опыт конфигурирования инфраструктуры через код (Ansible);
• умение писать скрипты на Bash, Python или Ruby (иногда упоминается Perl);
• опыт работы с облачными платформами.

Требования, которые не встречаются в вакансиях системных администраторов, но типичны для вакансий DevOps-инженеров:

• понимание философии DevOps;
• понимание и следование подходу «инфраструктура как код»;
• понимание жизненного цикла разработки ПО и принципов CI/CD;
• тесное взаимодействие с командой разработки.

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

При этом некоторые вакансии DevOps-инженера действительно похожи на вакансии системного администратора. Иногда в объявлении совсем не упоминается настройка CI/CD, а есть только требование построить и поддерживать кластер на Kubernetes. Но четкой градации между вакансиями нет, разделить их на группы нельзя.

Сергей, СТO в Southbridge:

Ключевой момент, который отличает DevOps-инженера от системного администратора, — это навыки автоматизации и сокращение ручного труда (особенно касается построения CI/CD), понимание процессов со стороны разработки. DevOps должен знать  Linux, Git + CI/CD, Ansible, Docker + Kubernetes, Automation and Scripting (обязательно).

Валентина, инженер в МТС:

Топ-5 обязанностей: настраивать CI/CD, автоматизировать и поддерживать инфраструктуру тестовых сред и прода, общаться с разработкой и понимать их код. Топ-5 технологий: Gitlab CI, Docker, K8s, Ansible, Python.

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

Зарплата DevOps-инженеров значительно больше, чем системных администраторов: от 1000 до 3500 USD и выше. 

Чем полезен DevOps

• Автоматизация — первое и главное преимущество DevOps. Каждый этап работы команды может быть автоматизирован: написание кода, проверка, сборка, развертывание, обновления.
• Ускорение релиза — то есть упрощение разработки. Заказчик всегда заинтересован в том, чтобы продукт максимально быстро вышел на рынок. Поэтому процесс доставки конечного продукта можно постоянно улучшать: сокращать время сборки и тестирования, настраивать мониторинг и пр.
• Обратная связь — если у заказчика есть комментарии, правки или дополнения, их можно вносить в процессе разработки и сразу обновлять приложение.

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

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

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

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

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

Кто такие девопсы и что они делают

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

Вот что может сделать инженер DevOps:

• создавать и настраивать виртуальные контейнеры для быстрого запуска необходимого программного обеспечения. Чаще всего для этого используется Docker;
• настраивать серверы и автоматически управлять их конфигурациями;
• управлять этими контейнерами из одного места и автоматизировать всю их работу;
• настроить автоматический тест кода;
• убедиться, что код после тестирования автоматически попадает в готовую сборку;
• собирать данные для контроля работы всей системы. Если служба или процесс не работают, DevOps должен немедленно это увидеть и отреагировать.

Что такое Docker и зачем он нужен

Основная задача DevOps — обеспечить максимальную автоматизацию и действительно ускорить разработку.

Что должен уметь DevOps

Основным навыком, на мой взгляд, является умение быстро разбираться во множестве разных систем. Каждая система состоит из компонентов — и нужно быстро понять каждый компонент, и как они взаимодействуют между собой. Сюда же как навык относится «траблшутинг» (устранение неполадок), который приходит со временем. 

Фундаментальные скиллы, которые нужны каждому девопсу:

Знание операционных систем и принципов их работы. Без этого не обойтись, ведь любой продукт пишется и потом работает в определенной среде. Зная среду, мы понимаем, что нужно, чтобы продукт нормально функционировал. Сложно поставить какую-то одну операционную систему на первое место. Как минимум, нужно разбираться в Linux и Windows. 
Основы программирования. Это точно также, как и знать буквы и грамматику чтобы учить иностранный язык. Что такое биты и циклы, как работать с кодом и его синтаксисом и др. — важные базовые понятия, необходимые в принципе любому, кто хочет что-то делать в ИТ. 
Понимание компьютерных сетей

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

Из-за такой базовой ошибки нам пришлось перестраивать всю сеть, чтобы приложение заработало. 
Владение скриптовым языком, желательно несколькими. Bash, Python, PowerShell и др. — все зависит от платформы, с которой работаем. Да, DevOps-инженер не разрабатывает продукт непосредственно, но при этом занимается автоматизацией процессов, которая описывается как раз кодом. 
Понимание виртуализации и контейнеризации. 
Знание облачных систем. Все просто: бизнес сейчас уходит в облачные ресурсы, провайдеры, хостинги, а значит, DevOps-инженер должен в них разбираться. И более того, он готовит инфраструктуру для разработки из разного количества и наборов облачных сервисов. Кто-то может возразить, что это не обязательно. Я не буду спорить, какие-то приложения работают внутри дата-центров, то есть на своих «железках». Но все же чаще DevOps работает с «облаками». 

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

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

Периодическая таблица DevOps.

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