Основное про DevOps и про обязанности

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

Основная цель подхода - убрать "стену" между командой разработки и командой Operations (Operations также называют: System Administration, System Engineering) и увеличить скорость релизов. "Стена" образуется из-за того, что у команд разные цели. Разработчики преследуют цель выпускать релизы как можно чаще, а Operations - снизить количество отказов или держать энвайрмент стабильным и безопасным. DevOps подход объединяет команды, цели и делит риски.

Основные практики DevOps это:

• Continuous Integration

• Continuous Delivery

• Continuous Deployment

• Continuous Testing

• Continuous Monitoring

• Infrastructure as Code

Некоторые практики разделяются между инженерами, например, QA может отвечать за Continuous Testing а Security за Continuous Monitoring. Как правило, инженер, который получил роль DevOps (не принято говорить "DevOps инженер", но рынок уже взял в оборот, звучит так же неопределенно, как "Scrum инженер") отвечает за все, что происходит с момента, как команда разработки пушнула код в репозиторий или выпустила релиз. Т.е за CI/CD пайплайны, энвайрменты проекта и базовый мониторинг.

Сколько инструментов в домене DevOps и что именно нужно знать?

PROD Grade инфраcтруктура, CI/CD пайплайны и мониторинг - это целая экосистема инструментов. Сейчас это более 100 популярных названий. Какие-то из них нужно знать глубоко и уметь конфигурировать. Некоторые достаточно настроить однажды, прочитав короткую документацию.

В области технической экспертизы DevOps возникает вопрос: что именно выбирать, сколько вообще инструментов нужно знать и что показывать на собеседовании?

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

Если выбор происходит при запуске нового проекта, появляется страх перед неверным выбором инструмента. Тут тоже не стоит тратить много энергии. Рано или поздно вам придется мигрировать с инструмента на инструмент, такова жизнь инженера. Миграция - это бесценный опыт, так что вместо того, чтобы исследовать все риски, можно следовать Agile принципам и просто сделать MVP вашей автоматизации. В большинстве случаев MVP перерастает в основное решение.

Какое количество инструментов/платформ и насколько глубоко вам нужно знать

Чтобы облегчить задачу выбора, все инструменты DevOps можно поделить на домены:

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

IaC: Terraform

CM: Ansible

Cloud: AWS

CI/CD: CircleCI

Scripting: Python, Bash

Containerization: Kubernetes

Monitoring: ELK, Prometheus

OS: Linux

SQL: Postgres, MongoDB

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

Novice - использовал инструмент/технологию однажды или читал документацию. (Эта категория имеет право на существование, например я устанавливал и настраивал MySQL для различных проектов, делал это раз тридцать точно, но каждый раз читая инструкции. Без предварительной подготовки я не расскажу хорошо про MySQL. Тем не менее не стоит увлекаться, если указать в CV все что вы "читали", резюме потеряет конкретику).

Intermediate - уверенное использование технологии/инструмента (важное замечание: этот уровень может достигаться через обучение).

Advanced - широкий опыт использования на проектах, неоднократно приходилось конфигурировать/писать код, hands-on experience от года. Продолжительность hands-on experience очень важна, в IT это как боевые вылеты в авиации, если вы не просидели за консолью или IDE свои боевые часы решая задачу или выполняя issue troubleshooting, вы не обретете экспертизу и не погрузитесь в технологию. (Здесь не надо беспокоиться, если вам скучно в консоли или в IDE, иногда вкус не сразу приходит). Можно говорить, что Advanced уровень приобретается на PROD проектах, но иногда учебный проект может быть сложнее реального PROD заказчика.

Expert - использовал технологию на сложных проектах продолжительное время от года и выше. Знает лучше чем производитель технологии или является коммиттером.

*эти категории можно критиковать в комментариях, это позволит выработать более точную модель!!

Теперь получилась следующая матрица:

IaC: Terraform - Advanced

CM: Ansible - Intermediate

Cloud: AWS - Intermediate

CI/CD: CircleCI - Novice

Scripting: Python, Bash - Novice

Containerization: Kubernetes - Intermediate

Monitoring: ELK, Prometheus - Novice

OS: Linux - Advanced

SQL: Postgres, MongoDB - Novice

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

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

Тут можно добавить еще один уровень оценки: если вы претендуете на позицию Senior DevOps Engineer, нужно владеть 3-4 инструментами на Advanced уровне и одним инструментом как Expert. Для Middle DevOps достаточно работать с 2-3 на Advanced.

Итого, ваша матрица компетенций:

Middle DevOps Engineer

Terraform, Linux - Advanced: основные инструменты

AWS, Ansible, Kubernetes - Intermediate: регулярно приходится решать задачи

ELK, Prometheus, CircleCI, Python, Bash, Postgres, MongoDB - Novice: общее понимание

Конкретика в CV и на собеседовании избавляет от разочарования, вызывает доверие, и освобождает вас от траты времени на подготовку (например, если вы не хотите учить SQL), позволяя сконцентрироваться на том, что реально нужно подтянуть.

За последние 3 года я провел около 180 собеседований на роли DevOps, Senior DevOps и Team Lead в различные команды и с разными интервьюверами. Мне самому приходится проходить собеседования к различным заказчикам внутри компании. На интервью моя цель состоит в том, чтобы раскрыть, насколько опыт кандидата соответствует заявленному и как отвечает ожиданиям заказчика. Я также проверяю, насколько наши ожидания к открытой вакансии соответствуют с рынком, являются ли они ниже или выше и можем ли мы влиять на это. Опыт интервьюируемого не должен совпадать с требованиями к позиции на 100%. Но к сожалению, приблизительно 70% интервьюируемых собеседование валят несмотря на то что это просто беседа о заявленном кандидатом опыте, без каверзных вопросов. По сути, на интервью нужно показать, что вы знаете, с чем сталкивались и имеете опыт, чего не знаете, но хотели бы развиваться и мотивацию. Адекватная оценка своего опыта, общая эрудиция и мотивация - это ключ к позитивному собеседованию.