Проблемы найма DevOps

P.S. Ещё и HR захвачен сектой балбесов, которые заваливают годных инженеров вопросами «как бороться с патриархатом и восстановить гендерное равенство среди IT-инженеров».

беги оттуда

Ещё и HR захвачен сектой балбесов, которые заваливают годных инженеров вопросами «как бороться с патриархатом и восстановить гендерное равенство среди IT-инженеров».

Ни разу не слышал от HR таких вопросов и ни разу не был отсеян на стадии HR. Стоит ли беспокоиться?

А вот честно, не знаю какой ответ должен удовлетворять hr. Я бы ответил, что 90% it-инженеров в компании мужчины, потому что 90% it-инженеров вообще мужчины. Так что при прочих равных это вполне ожидаемое соответствие. Но чую я, этот ответ неправильный.

Одна из идей: предоставить доступ к поломанному окружению на AWS и сказать — чини! Одна беда, требует времени, чтобы придумать чего бы такого наворотить.

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

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

1. Как бороться с unconscious biases?

2. Какое местоимение использовать для обозначения трансгендеров?

А на вторую я не ходил.

А был случай, когда американская мода не распространялась на весь мир? Богоспасаемое отечество эта шиза ударит позднее, но в конечной победе прогрессивных ценностей я не сомневаюсь.

А был случай, когда американская мода не распространялась на весь мир?

мода на жирноавтомобили, американский футбол, лапту (простите, бейсбол), житьё-бытьё в трейлерах, так и не распространилась

а ещё мерзкая мода ходить дома в ботинках и класть ноги на стол

Вот, кстати да. Со спортом у США не получилось. Регби (тот же ам. футбол) местами довольно популярен, насчёт бейсбола не знаю, но в целом тут у них провал, да. Остальное — так это либо денег нет, либо климат не позволяет. В России попробуй, проживи в трейлере зимой. Сначала разоришься на отоплении, потом смертию умрёшь.

потому что 90% it-инженеров вообще мужчины.

А если это не справедливо то это в первую очередь - социальная защита женщин, решивших стать it инженерами в виде декретных оплачиваемых отпусков и доступных детских садов, «а это не моя проблема».

мода на жирноавтомобили

Ну, в горных городах Италии не распространилась. А в Московской области очень даже.

житьё-бытьё в трейлерах

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

А в Московской области очень даже.

где? они уже в самих США модными быть перестали, не то что в МО

цыгане

цыгане так жили, ещё когда США в проекте не было

Значит, как-то надо избавиться от злой собаки

и класть ноги на стол

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

А если это не справедливо то это в первую очередь - социальная защита женщин, решивших стать it инженерами в виде декретных оплачиваемых отпусков и доступных детских садов

Кто в женщину писей тыкает, тот пусть её социальную защиту и обеспечивает лично, а остальные при чём

проживи в трейлере зимой

на стройках же живут - вообще в гаражах, а ещё в списанных вагонах поездов

С чего бы им отдыхать, если кровь до них плохо доходит? Хочешь, чтобы ноги отдохнули - полежи на диване, положи на табуретку, но никак не задирай выше задницы.

Пардон, а какая разница между IT и всеми остальными профессиями?

Тогда поток желающих уменьшается и наступает демографический кризис. Что, собственно и характерно для 20-21вв

Желающих чего, извиняюсь?

Желающих трахаться с целью заведения детей. Не извиняйтесь, всё в порядке.

Но почему-то в странах без социальной защиты рождаемость выше.

Полицейский носит бронежилет, а вы - нет. Шанс получить пулевое ранение у вас ниже. Значит ли, что полицейскому не надо носить бронежилет?

и наступает демографический кризис.

Товарищ, а можно на него посмотреть, на этот кризис ваш ? Куда идти ? Где людей не хватает ?

Это не настолько меня напрягает, чтобы помимо рабочих обязанностей заниматься и оптимизацией бизнес-процессов.

А в чём проблема прогнать по девопсовым вопросам?

• что такое докер, где и для чего используется?
• реальные кейсы с kubernetes?
• что такое ci/cd?
• best practices по load balancing?
• best practices по безопасности?

Ну и так далее. Поспрашивать про автоматизацию, утилиты, nginx, базы данных, фаерволлы, сеть. Даже по этим пяти можно понять глубину знаний, потому что по каждому можно читать многочасовую лекцию или же ответить как в википедии написано.

Вопросы должны быть такими, чтобы подразумевался большой ответ. А про всякие http любая макака зазубрит.

Так админа или девопса? Это разные люди, хоть и похожие. Надо исходить из задач - девопс больше про облака, контейнеры, ci/cd и всё такое, админ - про ковыряние линукса, прокси, почтовые сервера и локалку. Наверно поэтому хрень выходит. Тут на лоре была тема, называлась как-то вроде «что нужно уметь сисадмину», я там тоже отвечал (можно найти по комментам) - почитай.

Как бороться с unconscious biases?

и как же?

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

У вас автомобиль есть? Попробуйте провести эксперимент: зимой заглушить мотор и замерить время, через сколько минут температура перестанет быть комфортной. Я пробовал, и при -10 для меня после нескольких минут уже тянет запустить обогрев. В Калифорнии таких температур не бывает, а вот в средней полосе России — это реальность, данная нам в ощущении.

Задача у обоих одна и та же: сделать продакшену хорошо. Толковый админ делал CI и облака во времена, когда термин DevOps еще не был придуман. Остальное - словоблудие.

Отвечая на изначальный вопрос ugoday: если тебе нужен человек, который может разобраться с подземным стуком, то кроме рассказа о прошлой работе можно показать ему несколько скриншотов vmstat/iostat/top с боевых серверов и спросить, что он на них видит. Без фундаментальных знаний синьоров не бывает, зато полно ямл-девелоперов.

А про всякие http любая макака зазубрит.

Не всякая, поверьте мне, далеко не всякая.

best practices по …

Неплохой вариант. Если добавить с обратным вопросом «расскажите о недостатках/чем вам не нравится …» может и толк выйти.

Так админа или девопса?

Это одно и то же. По крайней мере я нигде (кроме статей в интернетах и жёлтой книжечки) не встречал между ними какой-либо разницы.

девопс больше про облака дмин - про ковыряние линукса

Тенденция последних дней — появились люди, которые прошли какие-то курсы про кубернетес, но в базовых линуксовых технология вообще не разбираются. Мы их не нанимаем, конечно, потому что они заведомо бесполезные. Современный специалист должен знать всё. От как настроить DKIM, чтобы почта в спам не уходила. До как запихнуть postfix в k8s в aws через ci/cd.

Не помню. Когда на митингах дольше 15 минут начинают фигню всякую обсуждать, срабатывают защитные механизмы мозга и я начинаю думать о своём. А на удалёнке — просто переключаюсь на другую вкладку в браузере и стараюсь мычать/задавать уточняющие вопросы время от времени. Кажется, тогда мы устроили мозговой штурм, писали какие бывают unconscious biases на стикерах, а потом переклеивали липучки с места на место. А потом время вышло и все пошли по своим делам. Может на второй сессии с этим что-то сделали, этого я уже не знаю. А может и просто забили.

показать ему несколько скриншотов vmstat/iostat/top с боевых серверов и спросить, что он на них видит.

Point! Интересная идея.

Это одно и то же. По крайней мере я нигде (кроме статей в интернетах и жёлтой книжечки) не встречал между ними какой-либо разницы.

Между ними разница не в навыках, а в задачах. Поэтому в небольших проектах админ и devops совмещены, а чем больше проект тем дальше они расходятся.

Админ - это тот кто администрирует кластер. Devops - это тот кто администрирует приложение пользуясь кластером.

С точки зрения админа, все приложения - одинаковые черные ящики на его кластере. С точки зрения девопса, все облака - одинаковые облачные интерфейсы для его приложения.

показать ему несколько скриншотов vmstat/iostat/top с боевых серверов и спросить, что он на них видит.

Point! Интересная идея.

Это вот как раз пример админского вопроса.

А для devops-а логичнее будет garbage collection для Java-приложений в контейнерах обсуждать.

Это одно и то же

У них разные задачи. Админы всё ещё нужны, чтобы обслуживать внутреннюю инфраструктуру компаний, они не занимаются продуктом. Лучше чтоб не было путаницы названий, девопсы могут бояться, что их после оффера заставят провода крутить.

Известный фразеологизм «Фома неверующий» (или «Фома неверный»), который употребляют для именования человека, которого сложно в чём-либо убедить, связан с одним из эпизодов Евангелия от Иоанна: апостол Фома не смог поверить в Воскресение Христово до тех пор, пока своими глазами не увидел Христа воскресшим.

Должно быть где-то это так работает, но на практике я ни разу такого не видел. А пока сам не увижу …

Вы рассказываете это основываясь на собственной практике?

ну ничего, не помнишь так не помнишь. главное ведь мнение иметь об этом

Как девопс должен понять, что проблема не в приложении, а на кластере, если он не знает, что именно написано в колонке io в выхлопе топа? Знание особенностей работы GC это прекрасно, но фундаментальные понятия обязаны присутствовать.

Алсо, девопс без контейнеров не девопс? ;)

Должно быть где-то это так работает, но на практике я ни разу такого не видел. А пока сам не увижу …

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

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

это уже пофиксили.

Я бы предпочёл сосредоточиться в этой теме над вопросом «как определить хорошего исполнителя». Это гораздо более примитивная задача и она уже очень сложная. Вопросы «как нанять кого-то умнее себя» и «как определить, реально может человек переделать процессы, или только будет имитацией бурной деятельности в jira заниматься» действительно важные и интересные. Но я пока боюсь даже затрагивать этот уровень.

Алсо, девопс без контейнеров не девопс? ;)

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

фундаментальные понятия обязаны присутствовать

С модели OSI ещё начни, ага.

Как девопс должен понять, что проблема не в приложении, а на кластере

Как обычно, сесть и начать дебажить. И если надо будет дебажить до уровня io - значит и до него тоже.

В прошлый раз когда приложения упирались в CPU, пришлось учить cpu throttling. Причем учить самой и объяснять как раз таки админам кластера, а то они всё норовили мне на графике CPU с шагом в 5 секунд показать спад из-за cpu throttling-а.

Низкоуровневые вещи - это прикольно, и закопаться в них иногда можно, но ставить их во главу угла давно нет смысла.

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

Низкоуровневые вещи - это прикольно, и закопаться в них иногда можно, но ставить их во главу угла давно нет смысла.

Зависит сугубо от аппов и инфры, если у тебя latency-critical аппы крутятся на bare-metal, без понимания низкоуровневых вещей ты полгода будешь танцевать вокруг бага с неподгружающимся ядерным модулем, вместо того, чтобы прописать его в конфиг - просто потому, что не понимаешь, что это и как оно влияет на общую работу систем. А если у тебя все в облаках, то оно тебе реально не уперлось, ты с этим не столкнешься никогда.

Но я пока боюсь даже затрагивать этот уровень.

пока

Почему ты считаешь что это «пока»? Какие из принятых тобой сейчас шагов ведут к тому чтобы текущее состояние как-то изменилось?

Почему ты считаешь что это «пока»?

Потому что я не хочу учить таблицу интегралов вперёд таблицы умножения.

Какие из принятых тобой сейчас шагов ведут к тому чтобы текущее состояние как-то изменилось?

Учу таблицу умножения.

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

зависит сугубо от аппов и инфры, если у тебя latency-critical аппы крутятся на bare-metal, без понимания низкоуровневых вещей ты полгода будешь танцевать вокруг бага с неподгружающимся ядерным модулем

Если это будет моя область деятельности, то за пару месяцев я выучу.

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

К примеру я никогда не писала на Java, но надо было нам разобраться в GC - пришлось выучить. Будет необходимо работать с модулями ядра - это тоже выучивается. Это полезные и нужные, но не фундаментальные знания.

Как в программировании, фундаментальным является понятие асимптотической сложности алгоритма, а не асимптотическая сложность конкретного алгоритма на конкретных данных. У devops фундаментальным является понимание архитектуры и уровней абстракции и изоляции. Я могу проверить гипотезу о том влияет ли железо на поведение приложения, до того как закопаюсь в то, какое конкретно там железо. И в 99% процентах случаев этого навыка будет достаточно, потому что анализ битой памяти на серваке - это уже работа совсем другого подразделения, а мои обязанности оканчиваются на том чтобы доказательно исключить возможные факторы со своей стороны.

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

расширять понятие devops

Как можно расширить нечто крайне аморфное? Это понятие все понимают как угодно, нет ни RFC. ни ISO, никаких других стандартов. Кто-то понимает под этим идеологию, кто-то конкретный набор практик, а для большинства - это вообще модный баззворд, являющийся синонимом чего угодно, от DBA до системного инженера или банального админа. И так как стандартов нет, все правы. :)