Комментарии 89
В последнее время собеседую много devops-ов. Кажется, антипаттерны не использую, по крайней мере хочется надеяться. Но вот несколько замечаний:
- бывает, что человек рассказывает, какой он был на прошлом месте крутой, сыплет терминами. Тут трудно понять, он сам что-то делал или просто рядом стоял и наслушался. Потому приходится просить написать код, или спрашивать как работает SSL или git. Какие-то базовые вещи, но вы не поверите, как много народа на этом валятся. Хотя из резюме кажется, что человек просто лорд devops-а
- технические вопросы, особенно для уровня senior, это лишь необходимая часть. Человеку придется самому ставить себе (а может и джунам) задачи, коммуницировать с другими разработчиками, с тестировщиками и менеджерами. Но иногда чувствуешь какое-то противостояние со стороны кандидата, вроде того "ну ты ж не HR, такие вопросы задавать". А потом выясняется, что человек с сеньерским техническим уровнем не может самостоятельно решить простейшие организационные задачи.
на первое я бы сказал стоит как то внимательнее слушать, что говорит, возможно распросить по какому то кейсу, таких встречал соискателей, обычно они валятся на распросе подробном как что сделать, но да, тут все неоднозначно
на второе и соглашусь и нет, иногда, на мой взгляд бывает потребность в технаре, который вот может решить сложные проблемы, готов много дизайнить и экспериментировать, но например, с взаимодействием у него сложно, для такого человека всегда можно найти и место и ему задачи подобрать. Так же есть мнение, что такой человек может со временем например вырости в хорошего ТехЛида, архитектора и это будет всем плюс, либо научиться взаимодействовать.
P.S. Я действительно видел человека хорошо воспринявшего эту парадигму. Он отлично решал абстрактные задачи и выучил О нотацию по википедии. Но при этом пишущего очень запутанный и медленный код, но это на собеседованиях никто не проверял в результате ему очень быстро удалось занять высокооплачиваемое неотствечивающее место в крупной компании.
Я не прошу писать на листочке. Я задаю вопросы по структурам данных и прошу решить одну из задачек на одном онлайн сервисов. При этом даже если человек не решает эту задачу (что конечно плохо), уровень можно оценить.
Обычно адекватно оценить соискателя просто — «поговорить за жизнь».
Т.е. о работе что делал, с какими проблемами сталкивался, как решали.
Вот тут «теоретиков» видно сразу, т.к. они вряд ли смогут предъявить практические навыки.
Есть большие специалисты — "поговорить за жизнь". И расскажут, как делали, и почему там говно, а там мёд. Особенно когда ваш стек отличается от его, и вы не знаете, как оно у них там точно.
И ещё, когда у вас есть несколько кандидатов, как вы выберете? На личных ощущениях? А вы вдвоем собеседовали, и ощущения разные.
Так что я за измеримый подход: вот есть вопросы из необходимых областей знания, простые и сложные. Не ответил — прости, чувак, нам с тобой не по пути. Ответил на простые — молодец, ответил на сложные — вот теперь давай о жизни поговорим.
Ага, только что такого собеседовал. В начале я прям плюсики на бумажку ставил — и это хорошо, и это отлично. Потом его попросили описать как бы он внедрил CI/CD для группы программистов, у которых используется git и ftp на папочку на сервер для деплоя. Zero restrictions. Начал бодро, но уж очень поверхностно. Потом после пары уточняющих вопросов выяснилось, что слова знает, а что слова означает — нет.
А потом я его попросил сказать, как посмотреть какой интерфейс на сервере используется для отправки трафика в интернет… И мне сказали, что traceroute'ом. Ну, в вопросе же было "через какой интерфейс маршрутизируется трафик в интернет" — значит маршрут, а что нам показывает маршрут? traceroute. Логично? Логично!
devops, блин.
Ахах. А можно мне к вам? Я знаю что такое icmp!) Правда на вопрос ответил бы что надо подумать(ну, не решал такого — сисадмин я) и вероятно предложил бы изменить способ деплоя.
Можете попробовать (я без шуток).
https://hh.ru/vacancy/36113395
Но было интересно посмотреть список требований — на удивление кажется адекватным(с некоторыми уточнениями)
Ну вот если про CI/CD я бы с вами бы поговорил с удовольствием, то вопрос про сеть меня бы очень смутил. Я бы често ответил, что нагуглил бы это за 2 минуты, но так не знаю — не приходилось как-то, или просто не запомнил.
При этом не считаю себя плохим devops-ом, если честно.
В вакансии сеть указана как отдельное требование (см в комментах ссылку на вакансию). Алсо, я не понимаю, как может быть хорошее понимание работы современных систем оркестрации (от k8s до системного пакетирования) без уверенного знания хост-системы. Т.е. человек гит/гитлаб умеет, файлик в kubectl засунуть умеет, а когда оно чуть-чуть начнёт по сети прогибаться, то всё? Контрек? Какой контрек? Посмотри что там с unknown unicast в сети? Ой, нам это не рассказывали...
Как узкая специализация — может быть. Но если мы говорим про легендарный T-shaped, знание основ маршрутизации — это как знание 16-ричной системы счисления. Она вам никогда не понадобится, пока не понадобится.
Можно не знать. Но я обычно ставлю большой минус на CV. Если он не компенсируется большим плюсом за отличные знания в другой области, несколько таких минусов, и человек уже не очень годится.
Алсо, как вы собираетесь настраивать мониторинг без минимального знания сети? Реагировать на метрики приложения и только? А как насчёт старых добрых "один из дисков в рейде сыпет некритичными ошибками из-за которых скорость упала до 2Мб/с?"
Реагировать на метрики приложения и только?может так получится, что только на них реагировать и фиксить можно несколько месяцев :) Собственно, ответа на вопрос «как» у меня нет — я лишь написал, что я видел своими глазами, как бывает. Бывает, что широта опыта в одной части — следствие проблем по ней в конкретной компании, вот и пришлось туда копать и узнавать. А по другой части проблем особо и не было, вот и опыта там мало.
Во, я понял. Вы считаете, что люди знают, только то, что у них случалось. Опыт — это важно и ценно, но если все знания человека состоят из опыта, то это эникейщик-переросток.
Книги по теории, общее видение — это обязательно. Чтобы когда очередной "опыт" в компании случится, было на базе чего этот опыт развивать.
Книги по теории, общее видение — это обязательно.
Я с этим согласен и тоже так считаю. Да, возвращаясь к изначальному сообщению — конкретно про контрак можно прочитать в книге и запомнить. Но я лично честно на такие случаи рассказываю, что «слышал — но не делал». Считаю, что практический опыт даёт на порядок больше знаний, чем теория (возможно потому, что я сам с книжек и статей начинал, не имея возможности сразу это проверять. А когда возможность появилась — всегда находил в практическом применении очень много того, чего не описывалось в теории. Зато было очень важным, чтоб всё заработало наконец).
Профнепригодность — незнание рабочей среды.
Человек может работать в той или иной области но не быть профессионалом — ему для выполнения работы нужны определенные условия(погуглить к примеру, предварительно сравнить какие-либо методы и сделать выводы). Но человек не может работать если он не только не профессионал но и профнепригоден.
У нас тоже все работает(администрирую/автоматизирую Z/OS в основном, но так же и всякие автоматизации по домену и средам выполнения) — но назвать себя профессионалом я не могу(хоть и знаю больше чем остальные в отделе) — просто потому что круг инструментов настолько велик что задача сводится от наилучшего решения к удовлетворяющему интересы(тактические и стратегические) работодателя решению.
Могу сказать по своему опыту, что имея изначально хорошее железо, по сети ничего прогибаться не будет долго— тут, как и во многих других случаях, следует уточнять — каковы цели, задачи.
может так получится, что только на них реагировать и фиксить можно несколько месяцев :)— как раз таки из-за отсутствия профессионалов в команде(тот случай когда непонятно — как проект еще живет)
Считаю, что практический опыт даёт на порядок больше знаний, чем теория— и практика и теория забываются быстро, если поток работ обширен и разнообразен. Практика имеет определяющее значение для профессионала — человека узкой специализации, знающего среду и доводящего навыки работы с инструментарием до совершенства.
и практика и теория забываются быстро, если поток работ обширен и разнообразентакой фактор конечно есть, но все-таки не бесследно же забывается! Да, я не помню особенностей реализации каких-то скриптов двухлетней давности, но помню идею общую. Возможно сейчас я его напишу абсолютно не так, а может даже и не буду писать. а смогу нагуглить готовый — но так или иначе я повторно решу такую задачу очень быстро. Собственно наличие практики и даёт это вот «быстро решу повторно». А голая теория — не даёт.
исключение основополагающие вещи — ОС к примеру изучается и повторяется все время, а те же инструменты мониторинга\деплоя\логирования сильно изменчивы
Во, если человек "слышал", то я как раз и хочу узнать, что человек слышал. Ещё лучше, если на основании "слышал" и поставленной задачи, он может попытаться предположить, как оно сработает или нет.
Кстати, из своего опыта могу сказать, что у нас в компании был человек, который считал, что "важно, чтобы заработало, наконец". И если заработало, то всё, на этом задача сделана.
… Последствия коммитов этого человека мы разгребаем до сих пор. Т.е. оно у него работает (работало) — но почему не понятно, что в голове было не понятно и какую задачу он там решал тоже непонятно. Прибито гвоздями под ситуацию и всё. Чуть тест тронешь, и всё обсыпается.
Так что не надо про "если заработало, то этого достаточно". Не достаточно. Надо, чтобы ещё было понятно почему заработало, причём понятно не только починившему, но и тому, кто git blame сделает через 3 года. А ещё желательно, чтобы оно заработало не только "тут", но и в общем случае. А для этого общий случай надо уметь увидеть. А это требует некоторого ухода в теорию.
Надо, чтобы ещё было понятно почему заработало, причём понятно не только починившему, но и тому, кто git blame сделает через 3 года. А ещё желательно, чтобы оно заработало не только «тут», но и в общем случае. А для этого общий случай надо уметь увидеть. А это требует некоторого ухода в теорию.Да, с такой формулировкой полностью согласен! С людьми такого подхода работать хорошо и продуктивно получается.
А потом я его попросил сказать, как посмотреть какой интерфейс на сервере используется для отправки трафика в интернет… И мне сказали, что traceroute'ом.
Эм, ну без знания маршрутов в общем-то бессмысленно гадать, какой из интерфейсов на сервере для чего используется, если их там конечно не два, вообще есть маршрутизация наружу и route table максимум в десяток маршрутов.
Какой вы вообще ответ ожидали?
В целом то ответ кандидата валидный (ну то есть информацию из трейса и пожалуй даже нужно использовать во многих случаях), хоть и не совсем правильный, скажем так.
Понятно что можно таблицу маршрутизации глянуть, посмотреть source на нужный диапазон, а потом посмотреть какому интерфейсу он принадлежит, но я могу влет придумать несколько кейсов, когда реально трейсроутом до какого-нибудь внешнего адреса(ов) посмотреть быстрее, чем разбираться в паре сотен маршрутов в таблице. А ведь таблиц еще и несколько бывает, да еще и маршруты могут быть одинаковые в них, но с разными источниками, они еще и приезжать могут откуда-нибудь и вообще сопутствующих условий может быть много.
Хотя конечно если вопрос был в формулировке «какой способ наиболее верный», то конечно в этом случае ответ так себе, а если «вы тут чините какой-то ад и надо быстренько глянуть через что ходит сейчас трафик наружу» — то вполне себе ок.
Дело в том, что маршрутов бывает много. Очень много.
И смотреть на «причины» можно, но с точки зрения скорости и правдивости подход с трейсроутом не так уж и плох. Более того, быстрые подходы вроде «ip route|grep default» тоже могут показать неправду во некоторых не особо экзотичных случаях.
Единственный способ быстро достать внешний маршрут и интерфейс с более-менее приемлимой достоверностью — это ip route get $external_addr, и то это всего лишь значит что до конкретного адреса вот прямо сейчас пойдет вот так и в простой ситуации это можно расширить до «и до остальных внешних тоже пойдет так». Попытка посмотреть глазами в маршруты вполне может обернуться итоговым фейлом, т.к. мозг человека не очень хорошо парсит битовые маски и списки на десятки и сотни позиций.
Я ожидал ответ "запущу ip route". Если кандидат хитрый, мог сказать про ip rule, или там, про SDN-правила в OVS'е, про то, что у системы может не быть дефолтного гейтвея и т.д. если очень олдфаг, route или netstat -r, но базовый ответ — ip route. В вопросе было всё просто: у вас сервер с двумя интерфейсами, через один есть выход в интернет, другой в локалку. Как узнать, какой из них "в интернет?".
Любой уровень выкрутасов тут приветствуется (т.е. можем обсудить любимые сетевые технологии), но не знать про default в таблице маршрутизации хоста...
В вопросе было всё просто: у вас сервер с двумя интерфейсами, через один есть выход в интернет, другой в локалку. Как узнать, какой из них «в интернет?».
Откровенно говоря, при определенном уровне стресса наверно даже я бы ответил «дернуть трейсроут и посмотреть адрес, а потом найти интерфейс», смотря какой контекст был до этого и вообще в каком стиле разговор.
Тем более, если понимаешь, что говоришь с человеком который о сети явно знает больше, чем ты, что еще больше стресса добавляет.
Все-таки надо отличать девопсов, пусть и немного трогающих сеть от людей, которые плотно именно сетью занимаются, а там тонкостей вагон и маленькая тележка, которые тем более сейчас практически всегда скрыты платформой (привет облака). На сколько я знаю у вас критерии отбора достаточно сильно завязаны на сеть, что как раз создает весьма специфичный стек требований, под которого найти человека весьма сложно (я тут немного повыяснял вокруг вашей вакансии, был определенный интерес).
Сисадмины с подобным стеком нынче редкий, практически вымирающий вид, т.к. в большинстве случаев те, кто шарит в сеть, CI/CD не настраивают, равно как и те, кто шарит в CI/CD и всяких кубиках сеть (всякое вроде ECMP routing) достаточно глубоко не знают или не знаю вообще, если только случайно нет подходящего бэкграунда. Специализация-с. Вкупе с кучей магии, которая «просто как-то работает». Печально, но все знать просто невозможно.
И что самое удивительное — оно им особо и не надо, задачи другие. Ну то есть я вот допустим вроде как знаю, что такое этот ECMP routing и зачем (хотя влет настроить не смогу, детали уже не помню, смогу наверно на листочке максимум суть нарисовать схемкой, да и то не факт что правильно), но с того момента, как ушел из провайдера (10 лет назад) мне это пригодилось ровно ноль раз. Сложно вам будет с поиском:)
Я вот тоже людей иногда собеседую (девопсов, собственно), сети мы конечно касаемся, но я все-таки стараюсь подобные вопросы задавать с большим контекстом, а-ля цепочкой «Что такое таблица маршрутизации?», «Как ее посмотреть?», «Как определить, через какой интерфейс пойдет трафик на адрес 1.1.1.1?». Вот последнее как раз превращает ответ про трейсроут в валидный (вместе с ip route get и еще пачкой вариантов).
P.S. Перечитал свой комментарий и сложилось ощущение что я выгораживаю неведомого мне человека, провалившего собеседование, но это не так:)
но не знать про default в таблице маршрутизации хоста...
Если все настолько плохо, то тут уже даже сказать нечего.
… инересно, если это вымирающий вид, то кто саппортит k8s?
Самые обычные люди, очень разные. Наш опыт преподавания показывает, что можно ставить, администрировать/поддерживать кубы и очень смутно представлять, как работает маршрутизация/коммутация или ядро линукса. И не иметь опыта работы в провайдере/хостере.
Наверное, это даже хорошо.
то кто саппортит k8s?
Ну, допустим я:)
Но по моим наблюдениям очень много моих коллег при словах «посмотри че там в ipvs, а то с сервисом какая-то херня, мож прокся херни наделала» впадает в уныние. Да и не часто надо туда ходить, если уж совсем откровенно. Там столько абстрацкий накручено, что в принципе при определенных условиях туда можно вообще никогда не дойти, и без этого будет чем заняться. Или, другими словами, там столько мест, где оно может как-нибудь сломаться, что всякие сетевые штуки наверно даже не в первой двадцатке проблем, о которые можно стукнуться.
Кубик и прекрасен, и ужасен тем, что достаточно быстро можно поднять чтобы работало и в простых случаях это почти всегда работает даже без понимания что внутри, особенно если облако и готовая автоматизация.
Просто кубик as-a-service или там over kops это сильно не то же самое что кубик поверх bare-metal c какой-нибудь сетью кроме flannel с дефолтными настройками.
В облаке оно в основном просто работает, а большинство проблем часто решаются методом «убей машину, пусть заново отскейлится».
Я вот одного не могу понять. Люди на k8s, это такие божьи одуванчики, которым никогда в жизни не приходилось решать проблемы с несимметричным роутингом эникаста их приложения в нескольких локациях? Или k8s — это новый php — залил страничку, работает?
т.е. у вас песочница, в которой микросервисы микросервят микросервисы чтобы микросервить микросервисы. А наружу там что? www.hoster.example.com/~pupkin? Или что-то поприличнее?
это такие божьи одуванчики, которым никогда в жизни не приходилось решать проблемы с несимметричным роутингом эникаста их приложения в нескольких локациях?
Ну, учитывая современный подход к эксплуатации — скорее не приходится, чем приходится и вот почему:
1. Проблемы реальной маршрутизации трафика вне оверлея лежат на платформе, которая либо не на столько сложна, либо берется как сервис (паблик-клауд), и то там на уровне ВМ не видно всей это магии, потому что сеть виртуалок тоже оверлей. Как оно там реально на уровне гипервизора работает знать не нужно (да и толку нет, доступа туда нет).
2. Магия сети автоматизирована в высокой степени. То есть из требований — low-latency прямая связность между нодами, без всякого NAT. Дальше оверлей (какой-то) поднимется сам и будет (как-то) работать. Обычно действительно сам и действительно работать, потому что половина оверлеев это автоматические ручки к системным штуками типа IPIP-тоннелей, iptables, ipvs и вот это все.
3. В кубике достаточно удачные абстракции из коробки и многие вещи вынесены вообще за его пределы по сути. То есть нет, несимметричный роутинг эникаста вообще никакого отношения к кубику не имеет и в рамках именно кубика сценария когда придется в это биться я не вижу. Если тебе нужен балансер — ты его как-то берешь снаружи (как сервис, делаешь сам, как угодно), и забираешь с него трафик себе уже без всякого эникаста, просто балансировкой по нескольким узлам.
4. Кубик совсем не про сеть. Все хитрое про сеть делается вне его. Внутри вполне обычный юникаст, даже мультикаста нет в популярных оверлеях, потому что в большинстве случаев он все-таки скорее не нужен, чем нужен. Но, к слову, его и в том же AWS нет, и вроде никто не плачет горючими слезами по этому, и правильно, мультикаст чуть менее ужасен чем бродкаст и контролировать его задачка такая себе.
5. Наружу там один или несколько ip:port, которые принимают трафик. Ничего особенного. В 95% это TCP порты на нодах, в которые смотрит вышестоящий балансер(ы) и который собственно на себе терминирует коннекты и все эникасты это его проблемы.
Ну блин, серьезно, я не поверю что вы никогда не пользовались AWS/Azure/GCE/DO или любым другим публичным облаком и не знаете абстракций, которые там видны пользователю. Там даже близко ничего нет про то, чтобы про сеть что-то понастраивать кроме маршрутов внутри VPC да firewall. Да оно и не нужно, пользователь видит красивые стройные абстракции без особой магии, а как оно там внутри устроено — не каждый сетевик разберется.
В целом дело в том, что область знаний же крайне обширна. Ну всмысле если речь идет не о команде в 3 человека и одном продукте, у тебя просто не будет времени заниматься всем подряд — и сетью с глобальными балансерами, и автоматизацией CI/CD, и платформой и все подряд. Естественная история со специализацией. Админы «по всему» это круто, но жизнь не резиновая и надо выбирать — или ты круто решаешь проблемы с эникастом и SDN можешь накрутить на всем, от джунов до микротиков и netbsd, либо ты классно умеешь автоматизировать всякие деплои с canary/AB со сбором статы и еще миллионом вещей.
P.S. Поверхностное знакомство со смежными областями конечно присутствует, но глубины нет, просто на нее нет времени (а часто и желания). Но я честно скажу — я очень рад, что наконец-то настали времена, когда можно фокусироваться только на нескольких конкретных вещах и позволить себе знать их хорошо и тратить на это время, а не делать все подряд, при этом упарываясь и все равно проигрывая по глубине знаний профильным спецам.
P.P.S. Проблемы асимметричной маршрутизации я решал последний раз те самые 10 лет назад и тогда умел это, но с того времени я настолько много всего другого начал уметь, что опять решать эти проблемы я совершенно не хочу, другая специализация просто. Я лучше оставлю это тем, чей профиль сеть и кто любит решать подобные проблемы и делает это хорошо.
окей, окей, вы меня убедили. Современный специалист по девопсу должен уметь программировать на ямле деплои, и на этом круг его обязанностей заканчивается.
… Почему мне 1С запахло?
Современный специалист по девопсу должен уметь программировать на ямле деплои, и на этом круг его обязанностей заканчивается.
Вы утрируете. Сильно утрируете. И в ваших словах сквозить какой-то налет «илиточки». Смею заметить — весьма неприятно.
Ведь вы тоже кучу вещей не знает из тех, что знаю люди, которые «на ямлах программирует», хехе:) Ну про ямл это конечно утрирование, но коли уж вы так считаете — то ладно.
Ну и эникаст накрутить не рокет сайнс, откровенно говоря, но видимо, «кто жунипер не гнул — не мужик»:)
P.S. Вот читаю я вас и думаю о том, что мне все таки повезло в том, что я отказался начинать с вами процесс собеседований на ту вышеупомянутую позицию, т.к. по финансам скромновато оказалось. Я бы просто не хотел оказаться в команде с человеком с подобными взглядами на мир и коллег.
Возможно мы не поняли друг друга. anycast — это не "внутри L2 сегмента". Это когда ваша сеть анонсируется пирам в разных географических локациях. Получается, что конечный пользователь (через AS своего провайдера) видит ваш адрес через несколько AS-path'ов, и часто оказывается, что AS-path до датацентра в его регионе меньше, чем до этого же адреса в (условном) Сингапуре. Трафик тогда уходит на него. А проблема с асимметричным роутингом начинается в ситуации, когда путь от AS клиента к вашей AS в одну сторону короткий и хороший, а в обратную сторону — длиннючий и страдающий из-за действий ОПГ. И вам бы хотелось, чтобы клиент пошёл через три AS и ответ получил через три AS, но получается, что клиент идёт через 2 AS, а ответ получает через 10.
Да нет, я думаю про anycast мы поняли друг друга вполне однозначно, упомянут мною жунипер исключительно для красного словца. Более того — я понимаю вашу боль по поводу этой проблемы и как сложно играть с магией этих ассиметричных маршрутов, чтобы и к тебе шло хорошо, и от тебя хорошо, когда посредине какой то мудак через дохлый линк полинтернета анонсит, ещё и по стечению обстоятельств на 2 хопа короче нормальной магистрали.
Но, как я и говорил, это все совсем не про кубик и даже не про девопсов, это все про сетевых инженеров. По крайней мере в реалиях современных крупных компаний.
Внутри кубика вообще про сеть ничего нет по сути, кроме скромного и плоского оверлея в виде одной широченной подсети для подов и другой для сервисов.
И вам бы хотелось, чтобы клиент пошёл через три AS и ответ получил через три AS, но получается, что клиент идёт через 2 AS, а ответ получает через 10.
На самом деле это задача ну вот совсем не девопса. Сетевика со знанием BGP — да. Как бывший сетевик, ушедший в сначала в юниксы, а потом в девопс, говорю.
Вы так говорите, будто бы это не повышает ценность отдельных специалистов.
Ага, например, saltstack с jinja )
О, ситуационные вопросы мои любимые. "Вот есть задача <такая-то>, как будете решать?"
Вопрос про интерфейс прост и хорош, сразу уровень видно.
Сеньор и не должен ничего организовывать. Это просто эксперт высокого уровня в своей области, возможно узкой. Да и вопросы про SSL чаще бывают из разряда энциклопедических, нежели направленных на понимание архитектурно-технических моментов. Для адекватной оценки кандидата нужно не только понимание кого конкретно ищите, но и применение вменяемых методов оценки их уровня знаний в нужном контексте. В большинстве случаев большинства компаний с этим большая беда. Один только этап общения с HR чего только стоит-потеря времени в 90% случаев. Далее следует энциклопедический опросник часто совмещенный с тупым экзаменом по типу ЕГЭ или подобной лабуды, либо одновременно, либо поэтапно. Никакой пользы в плане оценки реального уровня человека такой подход почти никогда не дает. Здесь больше подходит грамотный анализ резюме, и если впечатление более-менее положительное на первый взгляд, то затем проводится небольшое техническое собеседование в свободной форме по опыту кандидата и по некоторым житейским вопросам в рамках профессии, с обсуждением каких-то типичных или не очень типичных задач, с оценкой качества мышления в динамике. Опытному и грамотному специалисту-интервьюеру достаточно примерно 15 минут(а то и меньше), чтобы адекватно оценить компетентность кандидата и сделать соответствующие выводы. А иногда достаточно даже просто резюме посмотреть внимательно, порядок изложения мыслей на бумаге уже о многом говорит.
Погодите, шифт это энтерпрайзная поделка (здесь в очень хорошем смысле) над ванильным кубером, как можно знать шифт без знания кубера?
Есть компании, которые предоставляют шифт как сервис, такие компании знаю :)
То есть выдается неймспейс, туда можно деплоить, можно создавать сущности, но нет доступа до кластер админа, нет доступа к ингресу, нет доступа к созданию неймспейсов. Нет возможности конфигурировать сам OpenShift, что-то еще ограничено.
Вполне жизнеспособный вариант, у всех процессы построенны различно. Естественно, соискатель может прочитать документацию, поэкспериментировать локально с k8s или k3s — но тут упор на узкий взгляд на опыт больше.
У нас всё немного не так. Основные вопросы обсуждаемые на собесе:
- деплой системы на микросервисах в managed private k8s кластер. Разработка по гитфлоу, три тестовых окружения/неймспейса и продакшен. GitLab CI/CD. Релизный цикл две недели, где-то раз в месяц новый сервис и постоянное изменение среды исполнения существующих (новые енв переменные, конфиги, роуты и т. п.)
- возможность временно задеплоить систему с "патчем" (фиче ветка в мерж реквесте) в одном или нескольких микросервисах и прогнать на ней автоматическое и ручное тестирование, после чего погасить
- локальная разработка и тестирование этой системы
- как работает Докер :)
Причём просим рассказать концептуально как подойти, без особой привязки к инструментам кроме git и k8s, но без публичных облаков (а-ля GDPR для health). Чаще всего всплывает "на каждую ветку нужно поднять кластер в AWS терраформом, подключить Route53, генерировать letenscrypt (если ничего не путаю)", а о локальной разработке системы ничего внятного вообще сказать не могут.
Ключевые ограничения были озвучены: реальный кластер один, никаких облаков, потому что GDPR. Но нет, "динамически поднимим кластер..."
Что делают линейные разработчики? Пайплайны пишут на yaml (хороший вариант) или специфическом DSL типа Jenkins (плохой)? Пайплайны — это же и есть "может автоматизировать все, что ему хочется".
Или вашему девопсу просто не хочется заниматься мелочевкой типа поддержанием жизненного цикла нового сервиса, начиная с активного участия в сборе требований к нему, причём, скорее, как стейкхолдер для разработчиков, определяющий такие и вещи как способы конфигурирования, логирования, масштабирования, чем как помощник?
Есть developers, которые пишут код на одном или нескольких ЯП, и юнит-тесты, запускаеиые из консоли, максимум наивный Докерфайл напишут ещё для сборки работающего образа. Есть QA, которые e2e тесты пишут, также запускаемые из консоли, и принимающие как параметр несколько url, развернутой где-то системы с почти пустыми базами. Есть внешние operations, которые поддерживают кластер, базы данных, очереди и т. п., в общем IaaS. Есть требования бизнеса, что время от коммита в девелоп ветку до выкатки на продакшен должно быть минимальным и ручным операциям там место только для ручного тестирования. Разве не девопс должен всё это координировать, связывать воедино и автоматизировать? Если не он, то кто?
И где вы вычитали про админов, что-то навязывающих? А, ну да, из навязываемых девопсов интструментов — git и k8s. На SVN разработчики категорически отказываются переходить, а от k8s бизнес не откажется, если его очень настоятельно не убедить, что CTO и архитектор ошиблись с выбором инфраструктуры для масштабируемой (как в техническом, там и бизнес смысле) мультитенант системы. А использование публичных облаков запрещено законом по факту, не обеспечивают они выполнения требований о хранении медицинских данных. И никаких админов просто нет.
То есть в ашем мире конфиги кубера и пайплайны, включая деплои на продакшен пишут разработчики? Ну, может быть, я вот тоже пишу, пока девопса не нашли. Но это явно не то, что приносит мне удовольствие. Полезный скилл для общего понимания и форс-мажоров, но явно не то, чем я готов заниматься на постоянной основе.
В чём дебильность вопросов? И это не испытание на знание какого-то конкретного софта, это испытание на понимание проблематики разработки. Как раз на то, что человек не просто админ, а закроет дыру между админами и разработкой. И у нас эта дыра в конфигах кубернетеса и пайплайнах прежде всего.
Конечно лично воспринимаю, ведь я написал то о чём лично разговариваю на собеседованиях с кандидами на девопс инженера, а вы называете это бредом, оскорблениями и т. п.
И это не мои личные требования, Это то, что нужно нашей компании. Эти вопросы — это наша, разработчиков, QA и бизнеса боль. И нам нужен специалист, который сможет нас от этой боли профессионально избавить. Технических ограничений у нас меньше чем пальцев на одной руке. Но зачем нам специалист, который нашей боли не понимает?
Нам не консультации нужны, а человек, который хочет и может решать наши задачи, в том числе путём составления нам, разработчикам, требований по поведению наших сервисов в кластере k8s.
Глянул Rio — он бы нас сначала ускорил, а потом, скорее всего, затормозил бы — даже в документации чуть ли не половина примеров с инлайн манифестами в одном yaml, а, например, джобы не поддерживаются.
Конкретная задача у нас по сути одна: обеспечить безболезненную, автоматизированную выкатку сначала на тестовые среды, а потом на продакшен системы, которую мы сейчас развиваем качественно, в которой сейчас с пару десятков сервисов, и по одному-два в меясц добавляется, а существующие сильно изменяются. Ну и логирование, метрики и т. п.
В каком месте dev в devops значит device, а не development?
Джоб — в терминах кубернетеса, какой-то контейнер, запускаемый на один раз или по распиcанию, например для бэкапов или синков данных.
Ранчер у нас есть "в нагрузку" к managed кластеру, но он скорее для operations, разрабатываем IaC через чарты, за два десятка уже c более чем сотней шаблонов. Собственно и ищем человека, который либо возьмёт эти чарты под свой контроль (у меня от них уже скоро нервный тик будет, и вообще выгорание в легкой пока форме), либо реализует что-то подобное, но с помощью более удобной для всех технологии. Но на настоящем этапе жестких вводных немного:
- один managed кластер под ранчером для общих окружений, включая продакшен. на нём нам нужно настроить нормально логирование, метрики, роли и т. п., ограничить ресурсы и привелигии. Для разворачивания/обновления системы сейчас используются helm чарты — за два десятка, более сотни шаблонов
- окружение в этом кластере для каждого разработчика слишком дорого, на каждую фичу/фикс — только на время тестирования можно, желательно с ручным поднятием (кнопка в CI/CD UI)
- машины разработчиков (каждая) сравнимы по мощности с самим кластером (всем). Локальное окружение для разработки подразумевает доступность для разработчика всей системы с быстрой реакцией на его изменения. Текущее решение — minikube локально с полностью развернутой системой по тем же чартам, только value другие и немного баш обвязки. Тут полностью открыты к предложениям. Из вариантов, которые самим в голову пришли — поднять полноценный кластер на машинах разработчиков, выделив под ноды фиксированные ресурсы.
Это жёсткие ограничения для девопса, исключающие что к нам кто-то пойдёт за среднерыночные деньги для условного миддл девопса?
Бред какой-то. DevOps — это прежде всего командный игрок.
Как он будет предиктивно мониторить, если приложения бизнес-метрики не репортят, а он всех послал? Будет месяц выяснять, что и как этот сервис делает?
Как он будет масштабировать, если архитектура не предполагает масштабирования? Перепишет все сам?
То, что вы описали — это техлид, CTO, архитектор.
Обратите внимание. Все известен холивар на тему, как отличить джуниора от миддла и миддла от сениора. Я как-то обратил внимание, что каждый отвечающий человек условно представляет себе границы лучших спецов, что он видел и худших. Делит их на три части и примерно так себе представляет разницу.
К чему это я? Задайте этот вопрос любому и внимательно слушайте про сеньора. Он будет показывать свою верхнюю границу (если сеньор делал что-то за пределами его понимания, то эту магию он и представит как магию). И никакие гитхаб коммиты не нужны.
Так ведь весь смысл моего поста был в том, что нет никаких абсолютных сеньоров и джуниоров. Есть сеньор по чьей-то мерке в рамках чьих-то границ опыта.
На каждого сеньора встречается кто-то такой, кто еще прям на голову выше, на уровень. И тогда возникает вопрос: а если тот старый был сеньором, то этот кто? Суперсениор?
Человек, приблизившийся к потолку (назовем это небольшим процентом лучших) будет рассказывать свои собственные границы потолка. Другие, более высокие, он врядли видел.
Типа эксперт (сеньор) может быть в одном, а например в соседней, даже сильно пересекающейся теме типа новичок (джуниор). Это все условности для маркетинга и рынка, не более того, ну и разве что иногда как градация в рамках каких-то очень узких вещей, что к большому сожалению бывает редко в контексте большинства задач в современной ИТ отрасли. И именно бездумное и безудержное проталкивание всех этих практик и привело к такому вот плачевному результату и фактически это стангирует развитие отрасти и экономику вцелом, а вовсе не развивает, как принято ошибочно полагать.
Все эти так называемые границы сильно условны и весьма размыты. Это не более чем просто маркетинг, как и все эти типа новомодные девопс-практики и прочая лабудень.
1. Часто на собеседованиях гоняют по темам, которые просто гуглятся, т.е. проверяют фактически память кандидата, что он по этой теме что-то недавно делал. По смыслу это мало даёт.
2. По девопс именно части много технологий, и начинают расспрашивать о всех, это как программиста расспрашивать о всех библиотечных пакетах.
А вот что полезно спрашивать, то это сценарии: предложить вариант ошибки, связанной с конфигурацией системы, и спросить чтобы это могло быть, или спросить как развернуть то-то и то-то. Такие вопросы помогут понять кругозор кандидата. А детали он нагуглит.
Большая часть вакансий на присловутый девопс-статистические, не имеющие отношения к реальным вакансиям на рынке, потому и найти не можете. Да и само новомодное понятие девопс-раскручено некой сектой управленцев сайентологического толка в тренде создания рабства нового поколения. Сисадмин он и есть сисадмин, а функции автоматизации процессов в контексте администрирования-лишь часть контекста, и не более того. Ничего супер интересного и нового там нет. Результат пиара и возникшего в связи с этим массового психоза на рынке труда.
Антипаттерны DevOps собеседования