Итак сразу кем не является DevOps-инженер:

• Не программист. Он не пишет сайты и чаще всего не пишет программы.

• Не тестировщик. Не проверяет есть ли ошибки в коде продукта.

• Не совсем сисадмин. Часто не рулит железом в серверной.

• Не аналитик. Не отвечает за добавление фич в продукт.

Но при этом DevOps-инженер должен уметь:

• Писать (и читать) код минимум на одном из скриптовых языков (bash/python/go).

• Уметь в автотесты, или хотя бы понимать как их запускать, править, получать результат.

• Рассчитывать нагрузку на сервера, знать на каких ОС работают разработчики, знать сетевой стек хотя бы на слабом уровне. Знать как операционная система работает "под капотом".

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

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

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

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

Примеры того что автоматизируют DevOps инженеры:

• Анализ кода на плохие штуки - уязвимости, баги, плохой код (Sonarqube, owasp и любые другие сканеры) и сигнализация об этом разработчику.

• Сборка кода (в один или несколько пакетов для установки/docker образ и тд).

• Запуск автотестов, выдача понятных результатов по итогу.

• Поднятие и уничтожение тестовых сред для тестов.

• Загрузка пакета/образа в хранилище.

• Доставка пакета/образа клиенту.

• Развёртывание приложения.

• И иные мелкие и крупные операции.

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

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

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

Ну и наконец, а почему они собственно так ценятся в IT?

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

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

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

Автоматика допускает ошибки, но делает это намного реже людей.

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

Ну и конечно денег много за счёт автоматизации и соответственно снижения трудозатрат могут сэкономить копаниям, но это уж совсем очевидно :) .