Как войти в DevOps: какие навыки нужны DevOps-инженеру | Блог slurm.io
2026-02-19 17:19 Diff
https://slurm.io/blog/tpost/p36prfibh1-kak-voiti-v-devops

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


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

Преподаватель курсов «Слёрма» и девелопер адвокат Southbridge Марсель Ибраев рассказывает в статье, что такое DevOps, как он появился, и какие навыки нужны DevOps-инженеру, чтобы получить оффер.

А куда мы, собственно, собираемся входить


Давайте сначала разберёмся, куда мы вообще собираемся входить. Можно предположить три варианта:
  • DevOps — это профессия. Как учитель, музыкант или программист. И этой профессии можно обучиться.
  • DevOps — это технология, типа Wi-Fi или 4G. Ей можно обучиться и применять, чтобы стать айтишником.
  • DevOps — это закрытое сообщество, секта (например, «Монолит» — привет фанатам S.T.A.L.K.E.R.). Нужно пройти определённые ритуалы, чтобы попасть в это сообщество.

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

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

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

История IT и DevOps


Начнём разбор с того времени, когда компьютеры были большими, а объемы памяти — маленькими. Тогда за компьютерами работали скорее ученые, часто — военные. Эти люди сами разрабатывали компьютеры, сами их обслуживали: чтобы с ними работать, нужно было знать, как они устроены. Таким образом каждый специалист, работающий на компьютере, был максимально широкопрофильным — мог и детали поменять, и связь наладить, и код написать. А писали тогда, кстати, на низкоуровневых языках, команды в которых отдавали приказ напрямую компьютерному железу и очень тесно взаимодействовали с процессором. То есть без технических знаний о работе систем компьютера программировать бы просто не получилось.
Первый в Европе программируемый компьютер МЭСМ

Отрасль развивалась дальше. Появились простые операционные системы типа Windows 95 и высокоуровневые языки программирования — те, которые работали с железом через другие программы-посредники. Теперь, чтобы работать на компьютере, не нужно было знать все тонкости его внутреннего устройства.

В начале 21 века началось активное развитие железа, операционных систем, языков программирования. Внешне, для пользователя, IT-сфера становится проще, но внутри всё сильно усложняется:один человек уже не в силах разбираться и в железе, и в ПО. В итоге в начале 2000-х отрасль разделилась на два лагеря: разработчики и системные администраторы (по-английски это development и operations). Первые стали заниматься кодом, вторые — настраивать железо.


В теории всё стало проще. Но появилась серая зона ответственности — когда проект падал после запуска, то есть после выпуска в продакшен. Разработчики говорили, что у них на компьютере приложение работало, и это админы неправильно настроили сервер. Админы говорили — всё работало, это код у них какой-то плохой, виноваты разработчики. Атмосфера между двумя лагерями накалялась, спецы ругались, а стабильность проектов уменьшалась.
Чтобы как-то решить эту проблему, в 2009 году на конференции DevOpsDays в Бельгии собрались IТ-специалисты, закрыли двери и сказали «Пока не разберёмся, что делать, дверь не откроется». В итоге они проработали концепцию Developers and Operations — «Разработка и эксплуатация», или сокращенно DevOps. Основная её идея такова: разработчики и администраторы наконец начали работать дружно, а процесс работы превратился в непрерывную  автоматическую доставку кода на сервер и в продакшн, при этом по пути ничего не ломалось и все шло как по маслу.
На словах звучит прекрасно — за всё хорошее, против всего плохого. На деле это выросло в ряд инструкций, а впоследствии  — в ряд инструментов. И всё ради того, чтобы оптимизировать процессы, увеличить стабильность ПО и сократить time-to-market, то есть время до продажи готового продукта клиенту.

Основные концепции DevOps


Автоматизация. Автоматизируем все процессы, какие только можно. Да, сначала на это уйдет масса времени, но всё потом вернется с лихвой. Кстати, концепция, когда код автоматически собирается, тестируется и доставляется на продакшн, называется CI/CD  (Continuous Integration, Continuous Delivery — непрерывная интеграция и доставка) — это одновременно и методология, и технология.

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

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

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

Что должен знать DevOps-инженер


Если зайти на hh и посмотреть вакансии DevOps-инженера, вы увидите широкий разброс требований. Некоторые описания очень размытые: «опыт построения архитектуры инфраструктуры», «анализ текущих решений», «разработка скриптов для Greenplum». Иногда вышеупомянутый CI/CD не требуется, а нужно только собирать готовые решения на базе данных. Иногда вместо операционной системы Linux, который обычно ассоциируется с разработкой, нужно администрировать Windows.

Но есть и общие навыки, которые позволят откликаться на 99% вакансий с названием «DevOps-инженер».

Linux. Это более популярное требование, чем знание Windows. Вариации Linux вроде Debian, Ubuntu, Centos не имеют большого значения — разберётесь с одним и легко перейдёте на другой.
Работа сети. Модель OSI, TCP/IP, сетевые протоколы. В общем, знать, как работает интернет, что происходит на стороне серверов, какие сетевые пакеты куда идут.

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

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

Виртуализация, контейнеризация и оркестрация. Уметь настраивать виртуальные машины на своих серверах. Например, разобраться с virtualbox и KVM. А ещё разобраться с контейнеризацией: здесь сейчас самый популярный инструмент — это Docker. Для оркестрации, то есть управлении контейнерами, чаще всего пользуются Kubernetes. Правда, это система с высоким порогом входа — требуется разобраться во множестве сложных функций. Так что начать можно и без неё.

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

Если вы выбираете веб, нужно будет разобраться с Nginx и PHP-FPM, хотя бы в базовых вопросах.

Работа с Git. Нужно уметь работать с репозиториями, знать, что такое мерж-реквест и GITLab.

CI/CD. На базовом уровне нужно строить самые простые пайплайны, то есть конвейеры, по которым код автоматически доставляется на сервер.

Инструменты IaC. IaC (Infrastructure as Code, инфраструктура как код) — это особый подход к построению IT-инфраструктуры. Суть в том, что мы не заходим на серверы и пишем конфигурации, а делаем всё через специальные текстовые файлы: меняем конфигурации, задаём параметры, отслеживаем версии. Это критично, когда серверов много, их нужно постоянно обновлять и мониторить состояние. В DevOps ситуация обычно именно такая. 

Я рекомендую изучить Ansible и Terraform — это пара самых популярных решений. Можно для начала выбрать один: когда освоите его, переехать на другой будет легко.

Мониторинг и логирование. Систему недостаточно просто автоматизировать — нужно будет ещё следить за её состоянием, собирать информацию о проблемах, чтобы их можно было быстро устранить и предотвратить дальнейшее появление. Инструментов очень много: Prometheus для микросервисов, Zabbix, VictoriaMetrics, Loki, EFK. Умение настраивать и поддерживать эти вещи даст вам серьёзное преимущество при трудоустройстве.

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

Что ещё полезно уметь DevOps-инженеру


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

Знание баз данных: MySQL, PostgreSQL, Redis, MongoDB. Некоторые считают это обязательным, но в крупных компаниях, где строят DevOps, базами обычно занимаются специальные сотрудники.

Знание языков программирования, хотя бы на базовом уровне. Это поможет лучше понимать разработчиков. Хотя кодить вам, скорее всего, не придётся.

Знание облачных технологий. Сейчас почти все компании живут в облаках, поэтому важно уметь с ними работать. Из зарубежных это AWS и Google Cloud. В России тоже есть свои облачные провайдеры, но они преимущественно проще и разберётесь вы с ними быстро.

Английский. На мой взгляд фраза «без английского в IT делать нечего» — миф. Для начала вам будет достаточно английского на уровне «могу переводить со словарём». Уметь свободно говорить на английском и на ходу переводить тексты, как правило, не требуется. Если планируете выходить на иностранный рынок, язык пригодится, но стартовать можно и без него.

В заключение: немного о смене профессии


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

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

Если желание есть, то нужно учиться. И тут одной теории не хватит — обязательно нужна практика. Пробуйте разворачивать операционную систему Debian на своем ноутбуке, работать в системе управления версиями кода Git, изучать конкретные приложения. И обязательно даже в начале обучения найдите стажировку или работу, чтобы решать реальные прикладные задачи и получать коммерческий опыт.

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

Если вы прочитали эту статью и поняли, что DevOps не для вас, то можно выбрать другое направление в IT.  В этой сфере есть огромное количество профессий, причём некоторые из них даже «гуманитарные». Например, можно быть менеджером продукта или HR-oм — они всегда нужны.

А если вы осознали, что DevOps как раз для вас — приходите к нам в «Слёрм» на

курс DevOps Upgrade. Там будет и теория, и практика — кейсы, основанные на реальных задачах.