Основное про 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% интервьюируемых собеседование валят несмотря на то что это просто беседа, о заявленном кандидатом опыте, без каверзных вопросов. По сути, на интервью нужно показать что вы знаете, с чем сталкивались и имеете опыт, чего не знаете но хотели бы развиваться и мотивацию. Адекватная оценка своего опыта, общая эрудиция и мотивация, это ключ к позитивному собеседованию.
