Как войти в DevOps

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

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

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

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

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

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

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

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

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

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

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

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

На словах звучит замечательно — за все хорошее, против всего плохого. На деле это выросло в ряд инструкций, а впоследствии в ряд инструментов. И все ради того, чтобы оптимизировать процессы, повысить стабильность ПО и сократить time-to-market, то есть время до выпуска готового продукта.

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

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

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

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

Если зайти на HeadHunter и посмотреть вакансии 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 — это особый подход к построению ИТ-инфраструктуры. Суть в том, что мы не заходим на серверы и пишем конфигурации, а делаем всё через специальные текстовые файлы: меняем конфигурации, задаём параметры, отслеживаем версии. Это критично, когда серверов много, их нужно постоянно обновлять и мониторить состояние. В DevOps ситуация обычно именно такая.

Я рекомендую ознакомиться с Ansible и Terraform — это пара самых популярных решений.

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

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

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

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

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

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

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

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

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

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

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

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

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