Цель: внести ясность рекрутерам в том, что такое этот ваш девопс, как хантить, на что обращать внимание в резюме
Вопросы:
1. Что такое методология девопс, роль в производстве программных продуктов
Девопс — акроним от слов development и operations — разработка и эксплуатация ПО.
DevOps, в первую очередь, философия и методология по повышению инженерной и разработческой культуры не только внутри одной команды или проекта, но в рамках всей компании, т.к. внедрение DevOps вносит изменения не только в процесс разработки, но и в бизнес-процессы компании.
Роль этой методологии в производстве ПО: упрощение процессов, избегание ошибок, налаживание коммуникаций, контроль, мониторинг и логирование, контроль безопасности.
Применение девопс-методологии можно сравнить с цементом, скрепляющим кирпичики кода, процессов и результатов или с конвейером, благодаря которому процесс разработки, исправления багов и доставка новых функциональностей ускоряется.
2. Виды специалистов, применяющих методологию девопс
Кто работает по методологии девопс? Вся команда разработки целиком. Тестировщики, админы, разработчики, ИБ-спецы Это как аджайл/ITSM/ITIL, только DevOps.
Упрощенный конвейер (пайплайн) разработки: Код пишется (дев) — объединяется, если написан несколькими программистами (мёрж) — тестируется (тест) — отправляется на сборку (билд) — продакшн :)
Т.е., все ит-специалисты на всех этапах используют методологию и инструменты девопс:
CI/CD — инструменты непрерывной интеграции кусков кода друг с другом и доставки кода туда, куда требуется: пакеты, контейнеры и пр. Конечный вид приложения.
CI часть:
Development — разработка и анализ кода, его части:
Git — инструменты контроля версий, слияние кода. Сначала код мержится в рамках одного репозитория, а потом билдится и потом тестируется;
Build — сборка;
Test — инструменты непрерывного тестирования, которые обеспечивают обратную связь по бизнес-рискам;
CD часть:
Release+ Deploy — управление изменениями, официальное утверждение выпуска, автоматизация выпуска;
Конфигурация — Конфигурация и управление инфраструктурой, Инфраструктура как код;
Мониторинг — мониторинг производительности приложений, опыт работы с конечным пользователем.
Что для чего, краткий гайд
//чтобы вам не втирали дичь на собеседовании:
для построения инфраструктуры — Terraform или утилиты провайдера облака
системы управления конфигурациями — Ansible, Chef, Salt, Puppet
распространенные инструменты CI/CD — GitLabCI, GitHub Actions, Jenkins, TeamCity и пр.
для контейнеризации — Docker, Kubernetes, Nomad, OpenStack и пр.
Когда ты в курсе, для чего нужен докер — с тобой общаться будут совсем другим тоном.
3. Откуда есть быть пошли и пришли на рынок Девопс-инженеры
Да, будем называть их так. Потому что деваться им некуда, все остальное очень громоздко, плохо понимаемо и незапоминаемо. Придется им смириться, что рекрутеры называют и будут называть вакансии “Синьор Девопс”.
В основном, есть 3 источника, откуда на рынок приходят те, которых мы хантим по заявке “Срочно нужен девопс”:
Первая и самая многочисленная группа: бывшие и действующие системные администраторы. Им проще всего: освоили доп. инструменты и готово.
Вторая группа: разработчики, которые решили уйти в девопс-практики. Их меньше, им нужно осваивать линукс и админство.
Третья группа: “я проснулся и понял, что это — мое” — ребята, прошедшие курсы “Девопс за 3 недели” или что-то более внятное. Цели рекламировать у меня нет, поэтому сами можете нагуглить. С этими, с точки зрения рекрутинга, работать и проще, и сложнее. С одной стороны — им преподают современные и востребованные инструменты. С другой — нет опыта и понимания ни в администрировании, ни в разработке. Хороший плюс для менеджмента: их зарплатные ожидания ниже, чем у первой и второй группы.
Джун-миддл-синьор
Джун — знает, как поддерживать уже внедренные инструменты, но не может внедрять с 0. Нуждается в менторстве. При этом может быть хорошим админом. Глубокого понимания методологии у него нет
Миддл — некоторые инструменты может с 0 внедрить и научить других.
Миддл хорошо должен понимать методологию, понимать практики, РнД, может самостоятельно выбрать инструмент для применения
Синьор — может поставить все девопс-практики с 0. Отстоять архитектурные решения. Понимает риски для развития ПО, сам выбирает все инструменты. Аргументированно доказывает свой выбор.
4. Нужен ли вам девопс/SRE? Если да — то какой?
Если заказчик вакансии продуктовая команда, имеющая внутреннюю разработку — да, нужен.
Если просто код на аутсорс — то не обязательно.
Какой девопс нужен именно вашей команде: зависит от продукта.
Чаще всего нужны линуксовые админы с опытом написания скриптов на популярных языках.
Если ПО разрабатывается специфическое — девопс должен понимать нюансы этой разработки и стоит поискать тех, кто перешел в эту сферу из разработки на похожем стеке.
И немного про SRE:
Site Reliability Engineering — это практически то же самое, что и девопс, если не углубляться в тонкости. Но мы с вами не инженеры и углубляться не будем.
SRE — набор методов, показателей и предписывающих способов обеспечения надежности систем. Слово «site» в данном контексте читается как «система» или «платформа», а не веб-сайт в привычном нам представлении. SRE — обеспечение надежности всех уровней системы: от физических до логических, это значит, что SRE — это своеобразный конгломерат из разработчика (да, SRE должны уметь в код) и системного администратора со всеми вытекающими.
SRE — это своеобразное ответвление, а точнее — своя реализация направления DevOps от Google.
5. Каналы поиска
Основной канал поиска девопсов: телеграм-канал DevOps Jobs — работа и аналитика.
Хорошо себя показывает Хабр и линк, чуть хуже ФБ и вообще не подходит для поиска HH.ru и SuperJob, при этом там вполне ищутся приличные админы.
Отличие от поиска разработчиков: девопс-сообщество очень дружное и общительное ))) Если вакансия опубликована так, что вызывает только смех или фейспалм — будьте уверены, ее уже обсуждают в телеграме.
6. На что обратить внимание в резюме
Мы все знаем, что рекрутер оценивает резюме за 3-5 секунд.
Кроме общих правил оценки резюме, которые вы и так знаете:
Должно быть: GitLab, GitLab CI, Ansible, Docker, Terraform, Zabbix, KVM, MySQL and PostgreSQL, Prometheus, Grafana, ELK-стек, Jenkins, K8S/Kubernetes, AWS\Azure\GCP\Яндекс-облако\Mail Cloud.
Это — девопс.
Есть что-то из этого и слова Windows 7\8\10\Server 2012\Server 2016 и п.р. — бывший админ винды.
Если видите слово Azure — это облако от Винды
Все остальное: GCP, AWS и пр. — это облака, в которых преобладают линукс-системы и их большинство.
Есть фраза: учил на курсах GitLab, GitLabCI, Ansible, Docker, Terraform, Zabbix, KVM, MySQL and PostgreSQL, Prometheus, Grafana, ELK-стек — это студент.
С облаками работают не все. Девопс, не работающий с облаками — это девопс, работающий в закрытом контуре, ЦОД, ДЦ и пр. Ему нужно развиваться =) За облачными технологиями — будущее.
7. Как завязать диалог
Очень просто. Добрый вечер, ищу девопса. Вот описание, вот вилка, вот условия. Жду ответа, как соловей лета.
В вакансии ОБЯЗАТЕЛЬНО должно быть:
Вилка. Вилка — 2 понятных числа. От 0 до 800к — это не вилка, это чушь.
Условия: офис/удаленка, что еще дополнительно: проект\частичная\фулл-тайм
Описание стека разработки. Это важно.
Описание задач. Поддержка существующего и внедрение с 0 — очень разные вещи.Если у вас есть архитектор это одно (ему просто нужны руки), а если его нет, то вам нужен еще и спец который умеет в архитектуру, а не просто тяп-ляп и готово
Лайфхаки: читайте ранний баш.орг (пока он не стал баш.им), смотрите аниме, играйте в игры, будьте адекватными, не пропадайте без фидбека и вас сразу заметят.
8. Мы Вам перезвоним — почему так нельзя и к чему это приводит в сфере поиска девопс
Как мы уже говорили: сообщество дружное и обсудит Вас сразу. Репутацию проще не терять, чем восстанавливать.
Неважно, кого вы хантите: ВЫ ОБЯЗАНЫ ДАТЬ ФИДБЕК. Даже печальный. Сформулируйте его адекватно. Лучше плохой конец, чем ожидание без конца.
Вопросы:
- Что такое методология девопс, роль в производстве программных продуктов, в чем сложность поиска.
- Виды специалистов, применяющих методологию девопс
- Откуда есть быть пошли и пришли на рынок ДевОпс-инженеры/SRE
- Нужен ли вам ДевОпс-инженер/SRE? Если да — то какой?
- Каналы поиска
- На что обратить внимание в резюме
- Как завязать диалог
- Мы Вам перезвоним — почему так нельзя и к чему это приводит в сфере поиска девопс
1. Что такое методология девопс, роль в производстве программных продуктов
Девопс — акроним от слов development и operations — разработка и эксплуатация ПО.
DevOps, в первую очередь, философия и методология по повышению инженерной и разработческой культуры не только внутри одной команды или проекта, но в рамках всей компании, т.к. внедрение DevOps вносит изменения не только в процесс разработки, но и в бизнес-процессы компании.
Роль этой методологии в производстве ПО: упрощение процессов, избегание ошибок, налаживание коммуникаций, контроль, мониторинг и логирование, контроль безопасности.
Применение девопс-методологии можно сравнить с цементом, скрепляющим кирпичики кода, процессов и результатов или с конвейером, благодаря которому процесс разработки, исправления багов и доставка новых функциональностей ускоряется.
2. Виды специалистов, применяющих методологию девопс
Кто работает по методологии девопс? Вся команда разработки целиком. Тестировщики, админы, разработчики, ИБ-спецы Это как аджайл/ITSM/ITIL, только DevOps.
Упрощенный конвейер (пайплайн) разработки: Код пишется (дев) — объединяется, если написан несколькими программистами (мёрж) — тестируется (тест) — отправляется на сборку (билд) — продакшн :)
Т.е., все ит-специалисты на всех этапах используют методологию и инструменты девопс:
CI/CD — инструменты непрерывной интеграции кусков кода друг с другом и доставки кода туда, куда требуется: пакеты, контейнеры и пр. Конечный вид приложения.
CI часть:
Development — разработка и анализ кода, его части:
Git — инструменты контроля версий, слияние кода. Сначала код мержится в рамках одного репозитория, а потом билдится и потом тестируется;
Build — сборка;
Test — инструменты непрерывного тестирования, которые обеспечивают обратную связь по бизнес-рискам;
CD часть:
Release+ Deploy — управление изменениями, официальное утверждение выпуска, автоматизация выпуска;
Конфигурация — Конфигурация и управление инфраструктурой, Инфраструктура как код;
Мониторинг — мониторинг производительности приложений, опыт работы с конечным пользователем.
Что для чего, краткий гайд
//чтобы вам не втирали дичь на собеседовании:
для построения инфраструктуры — Terraform или утилиты провайдера облака
системы управления конфигурациями — Ansible, Chef, Salt, Puppet
распространенные инструменты CI/CD — GitLabCI, GitHub Actions, Jenkins, TeamCity и пр.
для контейнеризации — Docker, Kubernetes, Nomad, OpenStack и пр.
Когда ты в курсе, для чего нужен докер — с тобой общаться будут совсем другим тоном.
3. Откуда есть быть пошли и пришли на рынок Девопс-инженеры
Да, будем называть их так. Потому что деваться им некуда, все остальное очень громоздко, плохо понимаемо и незапоминаемо. Придется им смириться, что рекрутеры называют и будут называть вакансии “Синьор Девопс”.
В основном, есть 3 источника, откуда на рынок приходят те, которых мы хантим по заявке “Срочно нужен девопс”:
Первая и самая многочисленная группа: бывшие и действующие системные администраторы. Им проще всего: освоили доп. инструменты и готово.
Вторая группа: разработчики, которые решили уйти в девопс-практики. Их меньше, им нужно осваивать линукс и админство.
Третья группа: “я проснулся и понял, что это — мое” — ребята, прошедшие курсы “Девопс за 3 недели” или что-то более внятное. Цели рекламировать у меня нет, поэтому сами можете нагуглить. С этими, с точки зрения рекрутинга, работать и проще, и сложнее. С одной стороны — им преподают современные и востребованные инструменты. С другой — нет опыта и понимания ни в администрировании, ни в разработке. Хороший плюс для менеджмента: их зарплатные ожидания ниже, чем у первой и второй группы.
Джун-миддл-синьор
Джун — знает, как поддерживать уже внедренные инструменты, но не может внедрять с 0. Нуждается в менторстве. При этом может быть хорошим админом. Глубокого понимания методологии у него нет
Миддл — некоторые инструменты может с 0 внедрить и научить других.
Миддл хорошо должен понимать методологию, понимать практики, РнД, может самостоятельно выбрать инструмент для применения
Синьор — может поставить все девопс-практики с 0. Отстоять архитектурные решения. Понимает риски для развития ПО, сам выбирает все инструменты. Аргументированно доказывает свой выбор.
4. Нужен ли вам девопс/SRE? Если да — то какой?
Если заказчик вакансии продуктовая команда, имеющая внутреннюю разработку — да, нужен.
Если просто код на аутсорс — то не обязательно.
Какой девопс нужен именно вашей команде: зависит от продукта.
Чаще всего нужны линуксовые админы с опытом написания скриптов на популярных языках.
Если ПО разрабатывается специфическое — девопс должен понимать нюансы этой разработки и стоит поискать тех, кто перешел в эту сферу из разработки на похожем стеке.
И немного про SRE:
Site Reliability Engineering — это практически то же самое, что и девопс, если не углубляться в тонкости. Но мы с вами не инженеры и углубляться не будем.
SRE — набор методов, показателей и предписывающих способов обеспечения надежности систем. Слово «site» в данном контексте читается как «система» или «платформа», а не веб-сайт в привычном нам представлении. SRE — обеспечение надежности всех уровней системы: от физических до логических, это значит, что SRE — это своеобразный конгломерат из разработчика (да, SRE должны уметь в код) и системного администратора со всеми вытекающими.
SRE — это своеобразное ответвление, а точнее — своя реализация направления DevOps от Google.
5. Каналы поиска
Основной канал поиска девопсов: телеграм-канал DevOps Jobs — работа и аналитика.
Хорошо себя показывает Хабр и линк, чуть хуже ФБ и вообще не подходит для поиска HH.ru и SuperJob, при этом там вполне ищутся приличные админы.
Отличие от поиска разработчиков: девопс-сообщество очень дружное и общительное ))) Если вакансия опубликована так, что вызывает только смех или фейспалм — будьте уверены, ее уже обсуждают в телеграме.
6. На что обратить внимание в резюме
Мы все знаем, что рекрутер оценивает резюме за 3-5 секунд.
Кроме общих правил оценки резюме, которые вы и так знаете:
Должно быть: GitLab, GitLab CI, Ansible, Docker, Terraform, Zabbix, KVM, MySQL and PostgreSQL, Prometheus, Grafana, ELK-стек, Jenkins, K8S/Kubernetes, AWS\Azure\GCP\Яндекс-облако\Mail Cloud.
Это — девопс.
Есть что-то из этого и слова Windows 7\8\10\Server 2012\Server 2016 и п.р. — бывший админ винды.
Облачные технологии
Если видите слово Azure — это облако от Винды
Все остальное: GCP, AWS и пр. — это облака, в которых преобладают линукс-системы и их большинство.
Есть фраза: учил на курсах GitLab, GitLabCI, Ansible, Docker, Terraform, Zabbix, KVM, MySQL and PostgreSQL, Prometheus, Grafana, ELK-стек — это студент.
С облаками работают не все. Девопс, не работающий с облаками — это девопс, работающий в закрытом контуре, ЦОД, ДЦ и пр. Ему нужно развиваться =) За облачными технологиями — будущее.
7. Как завязать диалог
Очень просто. Добрый вечер, ищу девопса. Вот описание, вот вилка, вот условия. Жду ответа, как соловей лета.
В вакансии ОБЯЗАТЕЛЬНО должно быть:
Вилка. Вилка — 2 понятных числа. От 0 до 800к — это не вилка, это чушь.
Условия: офис/удаленка, что еще дополнительно: проект\частичная\фулл-тайм
Описание стека разработки. Это важно.
Описание задач. Поддержка существующего и внедрение с 0 — очень разные вещи.Если у вас есть архитектор это одно (ему просто нужны руки), а если его нет, то вам нужен еще и спец который умеет в архитектуру, а не просто тяп-ляп и готово
Лайфхаки: читайте ранний баш.орг (пока он не стал баш.им), смотрите аниме, играйте в игры, будьте адекватными, не пропадайте без фидбека и вас сразу заметят.
8. Мы Вам перезвоним — почему так нельзя и к чему это приводит в сфере поиска девопс
Как мы уже говорили: сообщество дружное и обсудит Вас сразу. Репутацию проще не терять, чем восстанавливать.
Неважно, кого вы хантите: ВЫ ОБЯЗАНЫ ДАТЬ ФИДБЕК. Даже печальный. Сформулируйте его адекватно. Лучше плохой конец, чем ожидание без конца.
podde
С фидбеком, конечно, пятая точка.
Причём, как в шаражкиных конторах, так и в крупнейших IT-гигантах страны.
Интересно, кстати, на Западе культура фидбека более развита? Чаще обосновывают отказ? Или так же молча кидают резюме в Корзину, а вакансию в Архив.
r00mka
На западе с фидбеком очень плохо, особенно в больших конторах. Некоторые даже пишут об этом явно в начале рекрутинг процесса, мол в случае отказа деталей «почему» раскрывать не будем. Кажется Amazon AWS таким страдал.
В прошлом на собеседованию в одну фирму среднего размера на собеседовании с технарями я даже вежливо попросил дать фидбек в случае отказа, мол интересно знать свои слабые стороны с точки зрения внешнего наблюдателя. Их, как мне кажется, эта просьба положительно настроила. Но меня туда взяли и фидбек не понадобился.
Статья зачетная как и для рекрутеров так и для самих DevOps. Вот бы большинство рекрутеров следовало этому. А то в профайле написано что всегда работал только с AWS и Linux, а рекрутеры иногда присылают роль по Azure+Windows и говорят что я отлично подхожу на эту роль, трудно прочитать что-ли пару строчек и не тратить ни свое ни мое время.
hope_dies_last_HR Автор
Спасибо!
Стремимся повышать культуру HR!