Многие, кто изучают DevOps, ориентируются на Roadmap.sh. Это классный ресурс, который помогает понять, какие компетенции нужно приобрести в профессии. Но в нём очень много информации, начинающие специалисты рискуют утонуть в деталях. Мы разработали свой Roadmap на основе опыта спикеров Слёрма. Он сделан с учётом российских реалий, разбит на уровни, фокусирует внимание на том, что в первую очередь понадобится для старта и роста в профессии и содержит ссылки на наши платные и бесплатные курсы. Статья будет полезна разработчикам и системным администраторам, которые хотят перейти в DevOps. 

В августе 2023 года мы сделали вебинар Roadmap для DevOps, который провёл SRE-инженер Dodo Максим Гусев. Сейчас предлагаем ознакомиться с этим Roadmap в виде статьи, дополненной подробностями. Пойдём от простого к сложному. Если вы уже владеете основными навыками, то сразу переходите к Basic Skills.

Основные навыки

Это навыки, без которых в DevOps вообще никак. Если заглянуть в вакансии, то можно заметить, что практически везде будет указано: «Требуется уверенное знание Linux и Git».

Уверенно пользоваться Linux

Большинство серверов и сетевых устройств работают на Linux (хотя встречаются и другие Unix-подобные ОС). Поэтому путь в DevOps стоит начать именно с подробного изучения Linux. Часто в DevOps идут Linux-администраторы, которым захотелось сменить задачи.

Для DevOps-инженера важно разбираться в устройстве Linux, загрузке и инициализации системы, структуре каталогов и уметь работать в терминале:

  • Создавать и редактировать файлы.

  • Запускать программы и настраивать сервисы (например, в Systemd).

  • Управлять пользователями, группами и правами доступа.

  • Устанавливать ПО из репозиториев, производить сборку и компиляцию.

  • Делать обновления и бэкапы.

  • Настраивать сетевые соединения и фаерволы.

  • Мониторить процессы.

  • Автоматизировать рутину, писать скрипты на Bash.

С технической точки зрения Linux — это ядро операционной системы, но обычно, когда говорят о Linux, имеют в виду GNU/Linux — комбинацию ядра Linux и GNU-компонентов (ПО и библиотек). Для удобства использования и настройки Linux-систем существуют различные «сборки» или дистрибутивы. Разумеется, не нужно сразу осваивать все дистрибутивы, лучше сосредоточиться на самых популярных или тех, которые используются в вашей компании. Например, RHEL и его семейство (CentOS, Fedora), Debian, Ubuntu и специфичные для России: Astra Linux, ALT Linux и т. д.

В Слёрме есть несколько курсов по Linux:

  • Linux База — бесплатный курс, который поможет сформировать навыки Linux-администратора.

  • Linux Мега — практический курс с best practices, написанием скриптов и заглядыванием под капот Linux.

«Нужно чётко понять, насколько человек разбирается в сетях, в линуксовом ядре, в том, как работает память и процессы. Ещё важно, какие команды он знает и как их применяет. Я должен быть уверен, что человек в Linux не вводит каждую команду в обнимку с гуглом», — Максим Гусев, SRE-инженер в Dodo.

Работать с Git

Git — это система контроля версий. DevOps-инженер должен знать этот инструмент немного глубже, чем разработчик. Проверьте себя: знаете ли вы эти команды, понимаете ли, для чего они нужны и как ими пользоваться?

  • git diff

  • git add

  • git commit

  • git log

  • git reset

  • git branch

  • git merge

  • git rebase

  • git cherry-pick

  • git stash

  • git push

  • git fetch

  • git pull

  • git remote

Если не удалось без гугла вспомнить хотя бы треть этих команд, то рекомендуем пройти бесплатный курс Git для начинающих. В нём рассматривается бо́льшая часть из этого списка.

Стратегии ветвления GitHub Flow и GitLab Flow. Источник: GitKraken
Стратегии ветвления GitHub Flow и GitLab Flow. Источник: GitKraken

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

Начать изучение Git можно с философии командной разработки и принципов контроля версий кода. В дальнейшем нужно научиться работать с популярными платформами GitHub и GitLab и уметь:

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

  • Решать сложные кейсы по слиянию веток и разрешению конфликтов слияния.

  • Иметь представление, что такое CI/CD (а ещё лучше — разбираться) и как в этом задействован Git.

«Я хочу убедиться, что человек реально понимает, чем отличается GitHub Flow от GitLab Flow и как тот или иной flow может повлиять на процессы разработки», — Максим Гусев, SRE-инженер в Dodo.

Есть и другие Flow: Forking workflow, Centralized workflow. Подробное описание и сравнение различных Flow можно найти в материалах от Atalassian (на русском) и от GitKraken (на английском).

Basic Skills

Владеть инструментами автоматизации

Для DevOps-инженера каждый раз выполнять повторяющиеся действия вручную — плохая практика. Он должен уметь две очень важные вещи: 

  1. Автоматизировать рутину. То есть всё, что можно относительно просто и надёжно автоматизировать у себя, у разработчиков, у тестировщиков, у саппорта и других команд, нужно постараться автоматизировать. 

  2. Добиваться оптимизации. Оптимизация — это уже результаты проделанной работы по автоматизации, когда процессы разработки становятся быстрее и проще и никому при этом не вредят.

DevOps-инженерам и системным администраторам когда-то потребовалось избавиться от однотипной работы с сотнями серверов. Так появились инструменты автоматизации развёртывания: Ansible, Puppet, Chef. С их помощью один DevOps-инженер может в короткий срок поднять целую армию серверов с заранее сконфигурированными настройками. 

В большинстве вакансий DevOps-инженеров сейчас требуется знание Ansible. Поскольку это самый популярный инструмент, мы рекомендуем изучать его. Что точно нужно знать и уметь в Ansible: 

  • Знать основные примитивы (плейбуки, модули, плагины).

  • Знать, что такое идемпотентность.

  • Уметь читать и писать плейбуки.

  • Уметь работать с модулями, ролями и плагинами.

«Я люблю спрашивать разницу между модулем и плагином. Потому что оказывается, что многие вообще не знают, что есть что и за что это всё отвечает», — Максим Гусев, SRE-инженер в Dodo.

Многочисленные конфиги и скрипты — это тоже код, который нужно бережно хранить. За это также отвечает DevOps-инженер. Поэтому Ansible тесно связан со знанием концепции Infrastructure as Code (IaC). Об этом мы подробно рассказываем в курсе Ansible: Infrastructure as Code.

Уметь собирать образы контейнеров в Docker

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

Технология контейнеризации перекочевала в разработку из Linux. В 2013 году появился инструмент Docker, с которым связывают бурное развитие контейнеризации. Из репозитория с исходным кодом и доступных образов можно за пару минут без танцев с бубном упаковать своё приложение в образ. Поднять инфраструктуру на контейнерах можно за несколько часов. 

Однако DevOps-инженеру недостаточно только копипастить образы и делать docker run/docker compose up. Вот что понадобится в реальной работе:

  • Знать абстракции и команды Docker и Docker Compose (один из плагинов Docker).

  • Уметь собирать свои образы контейнеров.

  • Знать, что под капотом у Docker.

  • Запускать контейнеры в Kubernetes.

  • Писать Dockerfile, знать ключевые инструкции и их применение.

  • Работать с образами и реестрами образов.

  • Знать о существующих альтернативах и иметь общее представление об их отличиях от Docker’а.

Проверить, насколько вы готовы к реальным кейсам сборки образов, можно на открытых кейсах – DevOps Cases.

Разумеется, полезно изучить best practices по Docker. Они доступны в официальной документации по этой ссылке.

Уметь строить CI/CD

Непрерывная интеграция (Continuous Integration, CI) и непрерывная доставка (Continuous Delivery, CD) — это концепция и набор принципов, которые помогают разработчикам быстрее выкатывать новые фичи и при этом сохранять надёжность своего программного обеспечения.

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

CI/CD можно реализовать как с контейнерами, так и без них. DevOps-инженеру нужно хорошо знать хотя бы один CI/CD-инструмент. Например, Jenkins или GitLab CI/CD. На самом деле их намного больше, но на собеседованиях обычно проверяют знание основных принципов и того инструмента, который кандидат указал в резюме. То есть нужно набить руку в использовании хотя бы одного инструмента, а потом при необходимости изучить остальные — больших проблем не будет. Например, можно начать с видеокурса по работе с Gitlab CI/CD, а потом изучить CI/CD с Jenkins.

Знать, что такое микросервисы, оркестрация контейнеров и иметь базовые навыки работы в Kubernetes

Микросервисная архитектура — это архитектура, в которой приложение разбито на несколько отдельных сервисов. Они взаимодействуют между собой путём прямых запросов или передачи сообщений через специальные системы-посредники (например, Apache Kafka). У каждого сервиса своя бизнес-задача: например, управлять каталогом, хранить и обновлять содержимое корзины или проводить оплату заказа.

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

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

Де-факто стандартом в отрасли сейчас является Kubernetes. Это сложный в освоении инструмент, и существует несколько уровней работы с ним:

1) Базовый. Этот уровень подразумевает, что вы:

  • Знаете компоненты и абстракции Kubernetes.

  • Понимаете, как устроен и работает кластер.

  • Можете поднять кластер с помощью одного из готовых инструментов (например, Kubespray).

  • Знаете, как реализованы сетевые абстракции в K8s.

  • Умеете создавать Helm-чарты и темплейтировать приложение.

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

  • Можете автоматизировать работу с сертификатами.

  • Понимаете, как строить пайплайны доставки приложения в кластер Kubernetes.

2) Продвинутый. Он подразумевает, что вы можете проектировать архитектуру и смело залезаете под капот Kubernetes для тонкого тюнинга. На этом уровне нужно уметь:

  • Настраивать аутентификацию пользователей в кластере.

  • Работать с сетевыми плагинами для Kubernetes.

  • Настраивать безопасность кластера.

  • Понимать, как работают компоненты Kubernetes под капотом.

  • Создавать собственные операторы.

  • Понимать, как работает автоскейлинг приложений в кластере.

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

  • Реализовывать Blue-Green, Canary deployment.

  • Использовать Open Policy Agent.

  • Выстраивать service mesh. 

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

  • администратора кластера;

  • разработчика;

  • архитектора;

  • специалиста по мониторингу;

  • специалиста по безопасности.

Сориентироваться в курсах и материалах по Kubernetes поможет Навигатор курсов по Kubernetes. Но начинать нужно с базовых курсов: Kubernetes: База или Kubernetes для разработчиков. На нашем youtube-канале есть бесплатные вебинары Вечерней школы Kubernetes: для инженеров и для разработчиков. Тем, кто уже имеет опыт работы с Kubernetes, рекомендуем обратить внимание на Kubernetes: Мега.

Знать языки программирования

Уже на старте DevOps-инженеру нужно уверенно писать на одном из скриптовых языков и уметь читать скрипты, написанные на Bash и Python.

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

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

  • JVM-стек (Java, Scala и Kotlin для JVM);

  • .Net-стек (C#);

  • Go;

  • Python;

  • JS/TS;

  • C/C++.

На собеседовании у вас спросят про тот язык, который вы указали в резюме. Но в будущем, разумеется, придётся подстраиваться под стек компании. В Слёрме можно изучить Python для инженеров и Golang для инженеров

«Python и Go хороши для начала, Java — сложнее, придётся сильно углубиться. Нужно знать, какие типы там есть, как с ними работать, какой синтаксис у языка, как правильно применить линтеры, чтобы они не мешали разработчикам. Хороший вариант — знать best practices по языкам и по паттернам безопасности и кода», — Максим Гусев, SRE-инженер в Dodo.

Уметь строить систему мониторинга

Развитие любого приложения невозможно без мониторинга. Он нужен как для обеспечения надёжности и доступности сервисов, так и для бизнес-аналитики. В задачи DevOps-инженера входит:

  • Выбор ключевых метрик. Нужно понимать основные подходы: Blackbox & Whitebox, уметь настраивать 4 golden signals, понимать предназначение RED и USE.

  • Организация и автоматизация их сбора. Работать с экспортёрами, настраивать Prometheus и его аналоги.

  • Хранение метрик. Знать типы данных и способы их хранения, PromQL.

  • Визуализация метрик. Устанавливать и настраивать Grafana. Уметь собирать дашборды и формировать графики.

  • Настройка алертинга. Проектировать правила и настраивать системы алертинга.

  • Внедрение улучшений на разных этапах развития проекта. Развивать observability системы, работать с инцидентами, анализировать метрики.

Связка двух инструментов Prometheus & Grafana — популярный способ организовать мониторинг. Чтобы освоить сбор метрик, обратите внимание на видеокурс по Prometheus, для сбора и визуализации — «Мониторинг в Grafana». Отдельный курс есть по Мониторингу и логированию в Kubernetes.

Знать методологии DevOps

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

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

  • Улучшать сотрудничество и коммуникации. DevOps-инженер снимает барьеры между разработчиками и операционными командами. 

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

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

В зависимости от процессов компании задачи DevOps-инженера могут отличаться: где-то он отвечает за продакшн, где-то за всё, что связано с CI/CD и тестовыми контурами. А где-то DevOps-инженеры отвечают исключительно за развитие продуктов, внедрение новых технологий и всего, что связано с CI/CD-конвейером. 

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

Заключение

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

Во второй части статьи мы расскажем об Intermediate уровне и специализациях для middle+ инженеров.


Статья подготовлена по материалам вебинара Roadmap для DevOps-специалистов. Спикер — Максим Гусев, SRE-инженер в Dodo Engineering. 

Редактор: Андрей Удалов.

Оформление: Екатерина Игумнова.

Комментарии (17)


  1. saboteur_kiev
    13.11.2023 14:27
    +7

    Многие, кто изучает DevOps, ориентируются на Roadmap.sh. Но в нём очень много информации, начинающие специалисты рискуют утонуть в деталях.

    Так там же кнопочкой можно переключить на Beginner View - https://roadmap.sh/devops?r=devops-beginner


  1. 0Bannon
    13.11.2023 14:27
    +1

    За пять месяцев? И тераформ и кубернетис, и остальное? Там на один линукс только апгрейдиться минимум полгода, наверное. Что за темп, интересно, будет.


    1. Liloon21 Автор
      13.11.2023 14:27

      Да, вы верно заметили, что там интенсивный темп. Поэтому заранее настраиваем студентов на то, что это «курс с высокой нагрузкой» :)

      Мы думаем о том, чтобы некоторые темы рассмотреть подробнее, но тогда придётся растягивать учёбу, жертвовать чем-то другим или увеличить цену. Это может быть неприемлемо для других.

      Может быть, в скором будущем DevOps Upgrade тоже ждёт какой-нибудь свой upgrade. Но пока мы видим этот баланс именно таким. Расчёт на то, что студент получает неплохой буст и базу, которая помогает ему понять свои собственные пробелы, задать себе правильные вопросы и без особых сложностей нарастить скиллы по этим темам. Либо самостоятельно, либо, взяв отдельный курс по инструменту.


  1. Melonom
    13.11.2023 14:27
    +4

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

    Когда переходил в devops прочитал целиком книжку по гиту пробую чуть ли не каждый пример из неё. Попав на работу, оказалось что кроме базовых команд ничего остальное и не нужно...


    1. Liloon21 Автор
      13.11.2023 14:27

      Бывает и так. За это время задачи по работе с Git'ом вообще не усложнялись?


      1. Melonom
        13.11.2023 14:27

        Смотря что под этим считать.
        Как можно усложнить задачи по созданию/удалению веток, МР и коммитов?)


  1. o_f
    13.11.2023 14:27

    Я не девопс, но абсолютно тоже самое делаю в автоматизации... Насколько теперь расплылись границы кто есть кто


    1. Liloon21 Автор
      13.11.2023 14:27
      -1

      А как у вас должность звучит? Если не секрет)


      1. o_f
        13.11.2023 14:27
        +1

        Qa auto


  1. renewid
    13.11.2023 14:27
    +2

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

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

    С тех пор мое мнение о "пятимесячных курсах" резко отрицательное, заявленные сроки для такой специализации - полный отстой.

    Выбиваешься из сроков бумажку не получаешь. Имеем конфликт интересов - либо пашем на бумажку, либо забиваем на бумажку и пашем на знания.


    1. SaM1808
      13.11.2023 14:27

      либо пашем на бумажку, либо забиваем на бумажку и пашем на знания

      Респект за фразу.


    1. Liloon21 Автор
      13.11.2023 14:27

      А вы с каким бэкграундом приходили на курс? Был уже какой-то опыт?

      Если отмотать время назад, то сейчас как бы вы поступили: поискали курс с более длительным обучением или брали бы несколько маленьких по нужным инструментам? Или как-то иначе?


      1. renewid
        13.11.2023 14:27

        1. администратор MDM системы, в крупной западной.

        2. Брать тематические курсы по технологиям.


  1. Quackerjack
    13.11.2023 14:27

    Для DevOps должна быть не Roadmap, а Playbooks - как развернуть специалиста из студента / разраба / системного администратора (что "установить"). Это было бы антуражнее для статьи.
    Сарказм =)
    Вообще, в энтерпрайзе, меня отпугивает требование для некоторых девопс уметь прям в настоящее сетевое администрирование, хотя это прям отдельная ветка со своими сертификатами и неочевидными приколами на конкретных сетевых железках и под эту ветку точат свои навыки отдельные специалисты. Фаервол - это только пол "беды". Понятно, что такой спрос с девопса не везде, но на мой взгляд это оправданно.


    1. thunderspb
      13.11.2023 14:27
      +3

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

      Т.е. девопс ДОЛЖЕН объяснить что и как нужно. Как это будет реализовано -- задача этих опсов.


  1. jenki
    13.11.2023 14:27
    -1

    Спасибо за ваш труд и проделанную работу, только боюсь, что от неё больше вреда чем пользы. Это больше напоминает гайд по силовым проводам, электрическим щиткам и изолентам для электриков. К сожалению, нет ни слова о законах электротехники. Девопс это не набор инструментов - это методология. Инструменты перечислили (те самые провода различного сечения, электрические щитки, защитные автоматы), хотя многие довольно спорные, только о самом главном ни слова (законы электротехники).

    Вы пишите, почти поголовно все твердят, что девопс - это про автоматизацию. Разве только про неё? А как же культура, средства измерения и взаимодействие (culture, automation, measurement, sharing)? Сколько читаю статей, об этом практически не слова, только без этого никуда. DevOps - это совсем не про Kubernetes и микросервисы его никак не касаются, это про взаимодействие между отделами разработки и эксплуатации. И человек приходящий к разработчикам, должен уметь разговаривать с ними на их языке (а они редко говорят про микросервисы), а когда приходит в отдел эксплуатации должен уметь общаться на языке этого отдела - те самые culture и sharing.

    Также не по себе становится, когда во время беседы узнаёшь, что человек, реализующий эту методологию не знает такие вещи как "12 Factors" и такой подход как "Инфраструктура как код", не говоря уже различиях между процедурной и декларативной реализациях.

    Другой момент, почему почти во всех статьях про девопс красной нитью, если архитектура, то микросервисная? Ну во-первых, надо ещё посмотреть насколько микросервисный этот распределённый монолит (в подавляющем числе случаев). Во-вторых, почему не сервис ориентированная или событийно ориентированная архитектуры? Тоже очень распространены. Почему, если девопс, то сразу кубернетес? Есть довольно неплохой serverless подход, причём, с заметно низким порогом входа, чем в случае с кубернетес. Кубернетес это про высокую доступность сервисов, но у многих облачных провайдеров из коробки куча инструментов для обеспечения высокой доступности и их часто достаточно для многих проектов. Тем более девопс - это про облачные решения, когда специалист больше занимается продуктом, а не поддержкой и настройкой серверов.


  1. Protosuv
    13.11.2023 14:27

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