Comments 81

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


  • бывает, что человек рассказывает, какой он был на прошлом месте крутой, сыплет терминами. Тут трудно понять, он сам что-то делал или просто рядом стоял и наслушался. Потому приходится просить написать код, или спрашивать как работает SSL или git. Какие-то базовые вещи, но вы не поверите, как много народа на этом валятся. Хотя из резюме кажется, что человек просто лорд devops-а
  • технические вопросы, особенно для уровня senior, это лишь необходимая часть. Человеку придется самому ставить себе (а может и джунам) задачи, коммуницировать с другими разработчиками, с тестировщиками и менеджерами. Но иногда чувствуешь какое-то противостояние со стороны кандидата, вроде того "ну ты ж не HR, такие вопросы задавать". А потом выясняется, что человек с сеньерским техническим уровнем не может самостоятельно решить простейшие организационные задачи.
Согласен, не все так просто :)
на первое я бы сказал стоит как то внимательнее слушать, что говорит, возможно распросить по какому то кейсу, таких встречал соискателей, обычно они валятся на распросе подробном как что сделать, но да, тут все неоднозначно
на второе и соглашусь и нет, иногда, на мой взгляд бывает потребность в технаре, который вот может решить сложные проблемы, готов много дизайнить и экспериментировать, но например, с взаимодействием у него сложно, для такого человека всегда можно найти и место и ему задачи подобрать. Так же есть мнение, что такой человек может со временем например вырости в хорошего ТехЛида, архитектора и это будет всем плюс, либо научиться взаимодействовать.
Ну и возможно потеряете отличного специалиста. Большая часть разрабов не могут писать код на собеседованиях потому что привыкли писать код в удобной и спокойной обстановке. Есть отличное правило, что контролируете то и получаете. Если кандидат хорошо пишет код на листочке значит это он умеет делать хорошо а остальное не факт. Если хорошо решает абстрактные задачки, то же самое.

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

Я не прошу писать на листочке. Я задаю вопросы по структурам данных и прошу решить одну из задачек на одном онлайн сервисов. При этом даже если человек не решает эту задачу (что конечно плохо), уровень можно оценить.

Вечная проблема — адекватная оценка компетенции. Были на собеседованиях ребята с сертификатами от Cisco, MS, Oracle и многие другие, которые сыпались на простейших вопросах, но при этом в резюме писали, что имеют экспертные знания и решают какие-то нереальные задачи :) Другая сторона — человек на собеседовании показывает крутые знания теории, но когда доходит до реального применения этой теории — пшик и все, сидит и ничего не может сделать без подсказки. Тупо зазубрил теорию :)
Чтобы оценить уровень соискателя собеседующий должен быть выше уровнем.
Обычно адекватно оценить соискателя просто — «поговорить за жизнь».
Т.е. о работе что делал, с какими проблемами сталкивался, как решали.
Вот тут «теоретиков» видно сразу, т.к. они вряд ли смогут предъявить практические навыки.

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

Во время разговора «за жизнь» эти вопросы можно задать, никто не мешает.
Но только в контексте реального использования.
А так зазаубрить теорию это не проблема.

Я как подумаю о мотивации человека, который зазубрил теорию в тех областях, по которым я задаю вопросы, так мне сразу хочется его нанять!

Ага, только что такого собеседовал. В начале я прям плюсики на бумажку ставил — и это хорошо, и это отлично. Потом его попросили описать как бы он внедрил CI/CD для группы программистов, у которых используется git и ftp на папочку на сервер для деплоя. Zero restrictions. Начал бодро, но уж очень поверхностно. Потом после пары уточняющих вопросов выяснилось, что слова знает, а что слова означает — нет.


А потом я его попросил сказать, как посмотреть какой интерфейс на сервере используется для отправки трафика в интернет… И мне сказали, что traceroute'ом. Ну, в вопросе же было "через какой интерфейс маршрутизируется трафик в интернет" — значит маршрут, а что нам показывает маршрут? traceroute. Логично? Логично!


devops, блин.

Ахах. А можно мне к вам? Я знаю что такое icmp!) Правда на вопрос ответил бы что надо подумать(ну, не решал такого — сисадмин я) и вероятно предложил бы изменить способ деплоя.

Спасибо. К сожалению не подхожу по навыкам. Как сетевик работал 2 года, домен win, потом ушел на администрирование Z/os и немного centos — отвечаю буквально за все(кроме DB2 и WS. спасите, меня не выпускают из подвала). А у вас релокация и, думаю, никто не будет тащить джуна=)
Но было интересно посмотреть список требований — на удивление кажется адекватным(с некоторыми уточнениями)

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

Ну вот если про CI/CD я бы с вами бы поговорил с удовольствием, то вопрос про сеть меня бы очень смутил. Я бы често ответил, что нагуглил бы это за 2 минуты, но так не знаю — не приходилось как-то, или просто не запомнил.
При этом не считаю себя плохим devops-ом, если честно.

В вакансии сеть указана как отдельное требование (см в комментах ссылку на вакансию). Алсо, я не понимаю, как может быть хорошее понимание работы современных систем оркестрации (от k8s до системного пакетирования) без уверенного знания хост-системы. Т.е. человек гит/гитлаб умеет, файлик в kubectl засунуть умеет, а когда оно чуть-чуть начнёт по сети прогибаться, то всё? Контрек? Какой контрек? Посмотри что там с unknown unicast в сети? Ой, нам это не рассказывали...

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

Как узкая специализация — может быть. Но если мы говорим про легендарный T-shaped, знание основ маршрутизации — это как знание 16-ричной системы счисления. Она вам никогда не понадобится, пока не понадобится.


Можно не знать. Но я обычно ставлю большой минус на CV. Если он не компенсируется большим плюсом за отличные знания в другой области, несколько таких минусов, и человек уже не очень годится.


Алсо, как вы собираетесь настраивать мониторинг без минимального знания сети? Реагировать на метрики приложения и только? А как насчёт старых добрых "один из дисков в рейде сыпет некритичными ошибками из-за которых скорость упала до 2Мб/с?"

Реагировать на метрики приложения и только?
может так получится, что только на них реагировать и фиксить можно несколько месяцев :) Собственно, ответа на вопрос «как» у меня нет — я лишь написал, что я видел своими глазами, как бывает. Бывает, что широта опыта в одной части — следствие проблем по ней в конкретной компании, вот и пришлось туда копать и узнавать. А по другой части проблем особо и не было, вот и опыта там мало.

Во, я понял. Вы считаете, что люди знают, только то, что у них случалось. Опыт — это важно и ценно, но если все знания человека состоят из опыта, то это эникейщик-переросток.


Книги по теории, общее видение — это обязательно. Чтобы когда очередной "опыт" в компании случится, было на базе чего этот опыт развивать.

Книги по теории, общее видение — это обязательно.

Я с этим согласен и тоже так считаю. Да, возвращаясь к изначальному сообщению — конкретно про контрак можно прочитать в книге и запомнить. Но я лично честно на такие случаи рассказываю, что «слышал — но не делал». Считаю, что практический опыт даёт на порядок больше знаний, чем теория (возможно потому, что я сам с книжек и статей начинал, не имея возможности сразу это проверять. А когда возможность появилась — всегда находил в практическом применении очень много того, чего не описывалось в теории. Зато было очень важным, чтоб всё заработало наконец).
Это вы говорите о профессионализме и профнепригодности. Профессионал — человек который знает(в той или иной мере) не только рабочую среду, но и наилучшим(быстро+эффективно) образом обращается с рабочим инструментарием. Зачастую имеет узкую специализацию.
Профнепригодность — незнание рабочей среды.

Человек может работать в той или иной области но не быть профессионалом — ему для выполнения работы нужны определенные условия(погуглить к примеру, предварительно сравнить какие-либо методы и сделать выводы). Но человек не может работать если он не только не профессионал но и профнепригоден.

У нас тоже все работает(администрирую/автоматизирую Z/OS в основном, но так же и всякие автоматизации по домену и средам выполнения) — но назвать себя профессионалом я не могу(хоть и знаю больше чем остальные в отделе) — просто потому что круг инструментов настолько велик что задача сводится от наилучшего решения к удовлетворяющему интересы(тактические и стратегические) работодателя решению.

Могу сказать по своему опыту, что имея изначально хорошее железо, по сети ничего прогибаться не будет долго
— тут, как и во многих других случаях, следует уточнять — каковы цели, задачи.
может так получится, что только на них реагировать и фиксить можно несколько месяцев :)
— как раз таки из-за отсутствия профессионалов в команде(тот случай когда непонятно — как проект еще живет)
Считаю, что практический опыт даёт на порядок больше знаний, чем теория
— и практика и теория забываются быстро, если поток работ обширен и разнообразен. Практика имеет определяющее значение для профессионала — человека узкой специализации, знающего среду и доводящего навыки работы с инструментарием до совершенства.
и практика и теория забываются быстро, если поток работ обширен и разнообразен
такой фактор конечно есть, но все-таки не бесследно же забывается! Да, я не помню особенностей реализации каких-то скриптов двухлетней давности, но помню идею общую. Возможно сейчас я его напишу абсолютно не так, а может даже и не буду писать. а смогу нагуглить готовый — но так или иначе я повторно решу такую задачу очень быстро. Собственно наличие практики и даёт это вот «быстро решу повторно». А голая теория — не даёт.
нет. не дает гарантии быстрого решения в случае повторения. так я научился писать документацию и комментарии, а потом отдел подсадил на локальную wiki в которой описаны основы встречавшихся затруднений и выполненных работ.
исключение основополагающие вещи — ОС к примеру изучается и повторяется все время, а те же инструменты мониторинга\деплоя\логирования сильно изменчивы

Во, если человек "слышал", то я как раз и хочу узнать, что человек слышал. Ещё лучше, если на основании "слышал" и поставленной задачи, он может попытаться предположить, как оно сработает или нет.


Кстати, из своего опыта могу сказать, что у нас в компании был человек, который считал, что "важно, чтобы заработало, наконец". И если заработало, то всё, на этом задача сделана.


… Последствия коммитов этого человека мы разгребаем до сих пор. Т.е. оно у него работает (работало) — но почему не понятно, что в голове было не понятно и какую задачу он там решал тоже непонятно. Прибито гвоздями под ситуацию и всё. Чуть тест тронешь, и всё обсыпается.


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

Надо, чтобы ещё было понятно почему заработало, причём понятно не только починившему, но и тому, кто git blame сделает через 3 года. А ещё желательно, чтобы оно заработало не только «тут», но и в общем случае. А для этого общий случай надо уметь увидеть. А это требует некоторого ухода в теорию.
Да, с такой формулировкой полностью согласен! С людьми такого подхода работать хорошо и продуктивно получается.
А потом я его попросил сказать, как посмотреть какой интерфейс на сервере используется для отправки трафика в интернет… И мне сказали, что traceroute'ом.

Эм, ну без знания маршрутов в общем-то бессмысленно гадать, какой из интерфейсов на сервере для чего используется, если их там конечно не два, вообще есть маршрутизация наружу и route table максимум в десяток маршрутов.
Какой вы вообще ответ ожидали?
В целом то ответ кандидата валидный (ну то есть информацию из трейса и пожалуй даже нужно использовать во многих случаях), хоть и не совсем правильный, скажем так.
Понятно что можно таблицу маршрутизации глянуть, посмотреть source на нужный диапазон, а потом посмотреть какому интерфейсу он принадлежит, но я могу влет придумать несколько кейсов, когда реально трейсроутом до какого-нибудь внешнего адреса(ов) посмотреть быстрее, чем разбираться в паре сотен маршрутов в таблице. А ведь таблиц еще и несколько бывает, да еще и маршруты могут быть одинаковые в них, но с разными источниками, они еще и приезжать могут откуда-нибудь и вообще сопутствующих условий может быть много.
Хотя конечно если вопрос был в формулировке «какой способ наиболее верный», то конечно в этом случае ответ так себе, а если «вы тут чините какой-то ад и надо быстренько глянуть через что ходит сейчас трафик наружу» — то вполне себе ок.
Да, но видно с какого адреса он это пытается, после чего надо просто бинд нужного адреса найти среди интерфейсов.
вы начинаете смотреть с последствий, а я бы предпочел начинать смотреть на причины
И все таки я не согласен. Можно конечно дернуть ip route get 1.1.1.1 или что то подобное, как вариант.
Дело в том, что маршрутов бывает много. Очень много.
И смотреть на «причины» можно, но с точки зрения скорости и правдивости подход с трейсроутом не так уж и плох. Более того, быстрые подходы вроде «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?

Ну, допустим я:)
Но по моим наблюдениям очень много моих коллег при словах «посмотри че там в 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 хопа короче нормальной магистрали.
Но, как я и говорил, это все совсем не про кубик и даже не про девопсов, это все про сетевых инженеров. По крайней мере в реалиях современных крупных компаний.
Внутри кубика вообще про сеть ничего нет по сути, кроме скромного и плоского оверлея в виде одной широченной подсети для подов и другой для сервисов.

Вы так говорите, будто бы это не повышает ценность отдельных специалистов.

О, ситуационные вопросы мои любимые. "Вот есть задача <такая-то>, как будете решать?"


Вопрос про интерфейс прост и хорош, сразу уровень видно.

Погодите, шифт это энтерпрайзная поделка (здесь в очень хорошем смысле) над ванильным кубером, как можно знать шифт без знания кубера?

да, хороший вопрос
Есть компании, которые предоставляют шифт как сервис, такие компании знаю :)
То есть выдается неймспейс, туда можно деплоить, можно создавать сущности, но нет доступа до кластер админа, нет доступа к ингресу, нет доступа к созданию неймспейсов. Нет возможности конфигурировать сам OpenShift, что-то еще ограничено.
Вполне жизнеспособный вариант, у всех процессы построенны различно. Естественно, соискатель может прочитать документацию, поэкспериментировать локально с k8s или k3s — но тут упор на узкий взгляд на опыт больше.
Когда есть «инфраструктурные девопсы» и «девопсы в команде прогеров», то уметь в куб первые будут, но если они развернули опеншифт — второй будет «уметь в опеншифт», у него очень узкие возможности будут. В гитлаб например будет уметь, во что-то еще… а с кубом «туда не ходи, сюда не пиши, только так делай».

У нас всё немного не так. Основные вопросы обсуждаемые на собесе:


  • деплой системы на микросервисах в managed private k8s кластер. Разработка по гитфлоу, три тестовых окружения/неймспейса и продакшен. GitLab CI/CD. Релизный цикл две недели, где-то раз в месяц новый сервис и постоянное изменение среды исполнения существующих (новые енв переменные, конфиги, роуты и т. п.)
  • возможность временно задеплоить систему с "патчем" (фиче ветка в мерж реквесте) в одном или нескольких микросервисах и прогнать на ней автоматическое и ручное тестирование, после чего погасить
  • локальная разработка и тестирование этой системы
  • как работает Докер :)

Причём просим рассказать концептуально как подойти, без особой привязки к инструментам кроме git и k8s, но без публичных облаков (а-ля GDPR для health). Чаще всего всплывает "на каждую ветку нужно поднять кластер в AWS терраформом, подключить Route53, генерировать letenscrypt (если ничего не путаю)", а о локальной разработке системы ничего внятного вообще сказать не могут.

UFO landed and left these words here

Ключевые ограничения были озвучены: реальный кластер один, никаких облаков, потому что GDPR. Но нет, "динамически поднимим кластер..."

Хорошие вопросы :) тут уже на заучивании теории не выехать на мой взгляд, про локальную разработку интересно, какие подходы кто использует — можно оценить кругозор
UFO landed and left these words here

Что делают линейные разработчики? Пайплайны пишут на yaml (хороший вариант) или специфическом DSL типа Jenkins (плохой)? Пайплайны — это же и есть "может автоматизировать все, что ему хочется".


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


Есть developers, которые пишут код на одном или нескольких ЯП, и юнит-тесты, запускаеиые из консоли, максимум наивный Докерфайл напишут ещё для сборки работающего образа. Есть QA, которые e2e тесты пишут, также запускаемые из консоли, и принимающие как параметр несколько url, развернутой где-то системы с почти пустыми базами. Есть внешние operations, которые поддерживают кластер, базы данных, очереди и т. п., в общем IaaS. Есть требования бизнеса, что время от коммита в девелоп ветку до выкатки на продакшен должно быть минимальным и ручным операциям там место только для ручного тестирования. Разве не девопс должен всё это координировать, связывать воедино и автоматизировать? Если не он, то кто?


И где вы вычитали про админов, что-то навязывающих? А, ну да, из навязываемых девопсов интструментов — git и k8s. На SVN разработчики категорически отказываются переходить, а от k8s бизнес не откажется, если его очень настоятельно не убедить, что CTO и архитектор ошиблись с выбором инфраструктуры для масштабируемой (как в техническом, там и бизнес смысле) мультитенант системы. А использование публичных облаков запрещено законом по факту, не обеспечивают они выполнения требований о хранении медицинских данных. И никаких админов просто нет.

UFO landed and left these words here

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


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

UFO landed and left these words here

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


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

UFO landed and left these words here

Нам не консультации нужны, а человек, который хочет и может решать наши задачи, в том числе путём составления нам, разработчикам, требований по поведению наших сервисов в кластере k8s.

UFO landed and left these words here

Глянул Rio — он бы нас сначала ускорил, а потом, скорее всего, затормозил бы — даже в документации чуть ли не половина примеров с инлайн манифестами в одном yaml, а, например, джобы не поддерживаются.


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


В каком месте dev в devops значит device, а не development?

UFO landed and left these words here

Джоб — в терминах кубернетеса, какой-то контейнер, запускаемый на один раз или по распиcанию, например для бэкапов или синков данных.


Ранчер у нас есть "в нагрузку" к managed кластеру, но он скорее для operations, разрабатываем IaC через чарты, за два десятка уже c более чем сотней шаблонов. Собственно и ищем человека, который либо возьмёт эти чарты под свой контроль (у меня от них уже скоро нервный тик будет, и вообще выгорание в легкой пока форме), либо реализует что-то подобное, но с помощью более удобной для всех технологии. Но на настоящем этапе жестких вводных немного:


  • один managed кластер под ранчером для общих окружений, включая продакшен. на нём нам нужно настроить нормально логирование, метрики, роли и т. п., ограничить ресурсы и привелигии. Для разворачивания/обновления системы сейчас используются helm чарты — за два десятка, более сотни шаблонов
  • окружение в этом кластере для каждого разработчика слишком дорого, на каждую фичу/фикс — только на время тестирования можно, желательно с ручным поднятием (кнопка в CI/CD UI)
  • машины разработчиков (каждая) сравнимы по мощности с самим кластером (всем). Локальное окружение для разработки подразумевает доступность для разработчика всей системы с быстрой реакцией на его изменения. Текущее решение — minikube локально с полностью развернутой системой по тем же чартам, только value другие и немного баш обвязки. Тут полностью открыты к предложениям. Из вариантов, которые самим в голову пришли — поднять полноценный кластер на машинах разработчиков, выделив под ноды фиксированные ресурсы.

Это жёсткие ограничения для девопса, исключающие что к нам кто-то пойдёт за среднерыночные деньги для условного миддл девопса?

UFO landed and left these words here

Мы пока пробуем найти человека, который всё это уже прочитал, ну или хотя бы хочет целыми днями этим заниматься

UFO landed and left these words here

Мы нев Москве, но спасибо, попробую поискать что-то про Киев подобное

Бред какой-то. DevOps — это прежде всего командный игрок.
Как он будет предиктивно мониторить, если приложения бизнес-метрики не репортят, а он всех послал? Будет месяц выяснять, что и как этот сервис делает?
Как он будет масштабировать, если архитектура не предполагает масштабирования? Перепишет все сам?
То, что вы описали — это техлид, CTO, архитектор.

UFO landed and left these words here
DevOps — практики доставки ПО. Следовательно, собеседуя человека на работу с этими практиками логично будет спрашивать все, что касается доставки — билд артефактов, хранение, CI/CD, и т.д и т.п. Все зависит от того, кого вы ищете, какие реально он еще роли будет выполнять. CTO — это менеджер кстати в чистом виде. А про модель OSI — ну уж извините, если человек такого не знает, то он дверью ошибся.

Обратите внимание. Все известен холивар на тему, как отличить джуниора от миддла и миддла от сениора. Я как-то обратил внимание, что каждый отвечающий человек условно представляет себе границы лучших спецов, что он видел и худших. Делит их на три части и примерно так себе представляет разницу.
К чему это я? Задайте этот вопрос любому и внимательно слушайте про сеньора. Он будет показывать свою верхнюю границу (если сеньор делал что-то за пределами его понимания, то эту магию он и представит как магию). И никакие гитхаб коммиты не нужны.

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

Так ведь весь смысл моего поста был в том, что нет никаких абсолютных сеньоров и джуниоров. Есть сеньор по чьей-то мерке в рамках чьих-то границ опыта.


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


Человек, приблизившийся к потолку (назовем это небольшим процентом лучших) будет рассказывать свои собственные границы потолка. Другие, более высокие, он врядли видел.

Спасибо. Из своих наблюдений:
1. Часто на собеседованиях гоняют по темам, которые просто гуглятся, т.е. проверяют фактически память кандидата, что он по этой теме что-то недавно делал. По смыслу это мало даёт.
2. По девопс именно части много технологий, и начинают расспрашивать о всех, это как программиста расспрашивать о всех библиотечных пакетах.

А вот что полезно спрашивать, то это сценарии: предложить вариант ошибки, связанной с конфигурацией системы, и спросить чтобы это могло быть, или спросить как развернуть то-то и то-то. Такие вопросы помогут понять кругозор кандидата. А детали он нагуглит.
Only those users with full accounts are able to leave comments. Log in, please.