Как стать автором
Обновить

Комментарии 21

С фидбеком, конечно, пятая точка.
Причём, как в шаражкиных конторах, так и в крупнейших IT-гигантах страны.
Интересно, кстати, на Западе культура фидбека более развита? Чаще обосновывают отказ? Или так же молча кидают резюме в Корзину, а вакансию в Архив.

На западе с фидбеком очень плохо, особенно в больших конторах. Некоторые даже пишут об этом явно в начале рекрутинг процесса, мол в случае отказа деталей «почему» раскрывать не будем. Кажется Amazon AWS таким страдал.
В прошлом на собеседованию в одну фирму среднего размера на собеседовании с технарями я даже вежливо попросил дать фидбек в случае отказа, мол интересно знать свои слабые стороны с точки зрения внешнего наблюдателя. Их, как мне кажется, эта просьба положительно настроила. Но меня туда взяли и фидбек не понадобился.

Статья зачетная как и для рекрутеров так и для самих DevOps. Вот бы большинство рекрутеров следовало этому. А то в профайле написано что всегда работал только с AWS и Linux, а рекрутеры иногда присылают роль по Azure+Windows и говорят что я отлично подхожу на эту роль, трудно прочитать что-ли пару строчек и не тратить ни свое ни мое время.
Спасибо!
Стремимся повышать культуру HR!

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

Должно быть: GitLab, GitLab CI, Ansible, Docker, Terraform, Zabbix, KVM, MySQL and PostgreSQL, Prometheus, Grafana, ELK-стек, Jenkins, K8S/Kubernetes, AWS\Azure\GCP\Яндекс-облако\Mail Cloud.

Это — девопс.


Тут слишком много ни на чем не основанных обобщений: GitLab, GitLab CI — с какой бы стати, если бывают bitbucket и jenkins? Или вы девопс, а не HR, или вы не слишком ли много на себя берете, оценивая специалиста таким образом?

MySQL and PostgreSQL — это почему же только они? А где Oracle и MS SQL, а еще скажем терадата и greenplum (впрочем, у нас на эти занятия есть выделенные люди, и они девопсами не являются, строго говоря, а являются как и раньше, DBA)? И никаких этих ваших облаков от Яндекса, а вместо них что-то другое. Например OpenShift. А вообще см. п.1. — это вот все должна определять заявка на поиск, а не фантазия HR.

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

Хотя в целом да, советы скорее годные. Про вилку, ну и многое другое тоже.
Спасибо за комментарий!
Да, безусловно, есть и bitbucket и jenkins, и OpenShift и многое-многое другое!

В одной статье объять необъятное — нереально и моей целью было подсветить рекрутерам некоторые моменты в поиске и на что в первую очередь обращать внимание.

И что в первую очередь надо выяснять подробности по вакансии и читать то, что указано в резюме, а не только должность и зарплату )

Про 3-5 секунд — это правда, опытный рекрутер за 10 секунд читает первые 2-3 места работы. Да, лаги случаются, как и у всех.

Спасибо еще раз за комментарий, учту в следующих выпусках!
>в первую очередь обращать внимание
На описание вакансии? :) Ну в общем, ничего страшного конечно, просто вот такая ошибка — она, к сожалению для рекрутеров весьма типична. Считать, что уже разбираешься в технологиях, и можешь принимать решения без команды.
В резюме — на стек и опыт, в описании вакансии — таки тоже на стек и задачи =)
Рекрутер без команды не может принимать решение о найме и я нигде этого не пишу.
Но отсев делать рекрутеру приходится, вот для первичного скрининга и есть эта статья =)
>Рекрутер без команды не может принимать решение о найме и я нигде этого не пишу.
Явно не пишете, но впечатление такое складывается.

Собственно, комментарий ниже — где-то мои впечатления, только чуть более прямолинейно изложеные. Особенно про облака, потому что девопс в закрытом контуре… это девопс например банка. А это далеко не самые маленькие компании, и не самые простые задачи.
Относительно неплохое начало, но чем дальше читал — тем больше «скрежетал мозг».
Не знаю зачем это пишу, просто делюсь мнением, возможно будет интересен взгляд со стороны инженера.

Технические моменты:
  • Не «CitHub Actoinс», а «GitHub Actions»
  • Для контейнеризации не «OpenStack», а «OpenShift»


Лингвистические:
  • «Откуда есть быть пошли и пришли...»

    АААА… кхм… иногда хочется чтобы KISS применялся не только в проектировании


Поведенческие:
  • «Девопс-инженеры… будем называть их так. Потому что деваться им некуда… Придется им смириться»

    А с какого такого, простите, невероятного события «деваться им некуда» и «придется им смириться»?
    Подход, в котором кто-либо решает за группу людей, к которой никакого отношения не имеет — вызывает только отторжение.


  • "… мы с вами не инженеры и углубляться не будем."

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


Субъективное мнение о том, что выглядит иллюзорным:
  • «Первая и самая многочисленная группа: бывшие и действующие системные администраторы. Им проще всего: освоили доп. инструменты и готово.»

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

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

    Почти всем разрабам, кто запускает приложения в контейнерах и/или на linux-серверах приходится знать ряд нюансов работы Linux-систем. Так что момент спорный.
    По поводу админства промолчу, т.к. не знаю какой смысл вложен в этот термин.
    При этом, не раз встречал сильных системных инженеров, пришедших из разработки в SRE. С точки зрения глубины (в т.ч. Linux систем) познания часто лучше, чем у среднего админа (увы, с кругозором не всегда также хорошо).


  • «Третья группа: “я проснулся и понял, что это — мое” — ребята, прошедшие курсы “Девопс за 3 недели” или что-то более внятное.»
    "… нет опыта и понимания ни в администрировании, ни в разработке"

    и тут же
    «Есть фраза: учил на курсах… — это студент.»

    Курсы в IT это уже часть посведневности. Даже senior инженеры и архитекторы их проходят.
    Тут ключевой момент что на middle и senior позицию человека, без опыта, в принципе не рассматривают.
    А человек прошедший «Linux за 3 недели, Сети за 3 недели, DevOps за 3 недели» (в идеале с кейсами и практикой)- интересный на рассмотрение джун, мотивированный развиваться.

  • Блок «Джун-миддл-синьор» — крайне субъективный.
    Пожалуй скажу что ожидание «может поставить все девопс-практики с 0» — слишком оптимистично.
    Ставить (внедрять) организационную структуру это больше про Team Lead и в целом руководителей.
    Задача senior специалистов (как я это привык видеть) — быть способным разобраться в любой задаче конкретного стека (а где-то даже и смежных) и решить её.


  • «Должно быть:
    GitLab, GitLabCI, Ansible, Docker, Terraform, Zabbix, KVM, MySQL and PostgreSQL, Prometheus, Grafana, ELK-стек, Jenkins, K8S/Kubernetes, AWS\Azure\GCP/Яндекс-облако/Mail Cloude.
    Это — девопс.»
    М… нет, это перечень инструментов и технологий, большая часть из них существует и используется без всякого DevOps.
    «Есть что-то из этого и слова Windows 7\8\10\Server 2012\Server 2016 и п.р. — бывший админ винды.»
    почему бывший?
    Винда до сих пор актуальна в ряде проектов. И даже больше скажу, если говорить о виндовом облаке — CI/CD там тоже есть (привет, Azure Pipelines!).

  • «Azure...GCP, AWS и пр. — это облака… С облаками работают не все.
    Девопс, не работающий с облаками — это девопс, работающий в закрытом контуре, ЦОД, ДЦ и пр. Ему нужно развиваться =) За облачными технологиями — будущее.»

    Что, правда? А кто будет тогда обслуживать эти самые облака изнутри? (тут вот можно написать про OpenStack)
    Да и потом, не говоря о бэкенде облаков и внутренних облаках (о которых умалчивается), есть множество проектов, где облачные технологии вообще не нужны.
    Облака, если грубо обобщать — сервис выделения мощностей оборудования пользователям.
    Если компания не предоставляет услуги по использованию каких-либо мощностей (внутри компании или внешним клиентам) — облаков там может не быть и на качество сервисов это не повлияет.


Из того, что понравилось:
  • Задумка. Донести до коллег-рекрутеров чуть больше про инженеров и нюансы их найма это хорошо.

  • Условия, стек, вилка и бонусы это действительно важно.

  • Фидбек — крайне важен, особенно когда его запрашивают.


Искренне желаю успехов как в найме инженеров, так и в дальнейшем изучении нюансов IT индустрии.
Ваш senior system engineer.
Спасибо за такой развернутый комментарий!
Очепятки поправляю, волновалась, это моя первая статья =)

По остальному: просто спасибо! Мне есть, над чем работать )))

И да, по поводу «девопс-инженеров». Это не какие-то невероятные хотелки рекрутеров или еще кого-то. Это экономия строчек и времени. Писать «Вакансия Синьор Инженер, применяющий на практике DevOps-методологию» — длинно и неуютно в поиске, как вакансий, так и резюме. Поэтому и пишут senior DevOps.

Почему не прижилось «системный инженер» — не могу сказать, так повелось и привело вот к такому.

Спасибо!

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

Это точно :)
Системный инженер, это всё-таки немного другое, где-то между системным администратором и системным архитектором. Профессиональный уровень тот же, что и у девопса, просто он не занимается доставкой кода.
Если верить вот этой ссылке, то системный инженер это программист с дополнительными навыками.

Я бы сказал, по моему мнению, что на текущем рынке, фидбэк важен только когда кандидат сам откликнулся на вакансию. В текущих реалиях, когда перекос сильно в строну кандидатов, при 5-7 собеседованиях в день, на чтение фидбэков времени не остается, обращают внимание только на оффер.

Надежда, что же вы делаете. Сейчас рекрутеры вытащат из вашей статьи все ключевые слова/термины и обзовут их фильтром на devops/sre инженера. И удачи нам всем потом объяснять, что если ты использовал ansible, но имеешь очень поверхностное представление, что такое chef, то это не значит, что ничего не знаешь о configuration management systems.
Девопс — это сотрудник, который является коммуникационной структурой между бизнесом и IT.
А то, что вы понаписывали в требованиях — это просто «програмист yaml»

Если уж на то пошло, то это методология. Сказать "я DevOps" по смыслу примерно так же абсурдно, как сказать "я Scrum" или "я ITIL", но так уж повелось, в том числе и на западе, так что предлагаю смириться.

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