Comments 41
Согласен, тема достаточно глубокая для дискуссии, но тем не менее можно ответить в нескольких предложениях, без полного обзора и понять, что у человека имеется представление о данной метрике и он понимает в процессе траблшутинга, какие операции могут увеличивать значение load average.
github.com/torvalds/linux/blob/7426cedc7dad67bf3c71ea6cc29ab7822e1a453f/kernel/sched/loadavg.c#L5. Хватит спрашивать эту дичь
Это уже не первая статья, про поиск человека
Я завис на этом вопросе потому что написано сокращением. Какое такое LA? Аааа, load average.
Наверное по линуксу можно придумать вопросы получше. Например где крутить параметры ядра, как работает фс, симлинки vs хардлинки, айноды, процессы и дебаг процессов и т.д.
Поэтому LA полезен.
Если кандидат скажет про зависимость не только от CPU, но и от дисковой системы, и скажет про ожидающие потоки/ядра — этого в принципе достаточно для ответа на собеседовании.
А ковыряться внутри реализации метрики, которую все используют косвенно — в общем случае не нужно.
Когда я провожу собеседования всегда использую такой подход:
Чётко смотрю резюме человека и описанный стек.
Спрашиваю уровень знаний по каждой теме, чтобы человек сам сказал как он чувствует что знает каждый из интересующих меня стеков технологий.
Плюс если вопросы реально касаются техники и знаний Docker,Ansible итд обычно даю пример -тот же докерфайл или плейбук и спрашиваю чтобы человек обьяснил что там происходит сообственно. А мучить человека командами, особенно в части сети (дальше базовых ) я точно не буду и считаю это не целесообразно, важно понять что его понимание соответствует тому что в резюме и он умеет мыслить и искать инфу. а по поводу LA там человек отписал и я с ним согласен
/*
* kernel/sched/loadavg.c
*
* This file contains the magic bits required to compute the global loadavg
* figure. Its a silly number but people think its important. We go through
* great pains to make it work on big machines and tickless kernels.
*/
Судя по описанию вы ищете не человека, который занимается DevOps практиками, а хорошего OPS. Если нужен человек в эксплуатацию, то вполне себе.
Вопросов, касаемо DevOps практик, или вопроса на понимание этих практик я почему то в статье не увидел. Или вы ищиье спецов Junior уровня.?
Те-же вопросы про докер и принцип изоляции контейнеров, зачем они? Скорее всего docker вы используете как CRI и не более, и зачем лезть в дебри мне не очень понятно. Что вам даст ответ про сgroups и namespace?
Я обычно спрашиваю про то, какие человек знает инструменты.Потом привожу какую нибудь гипотетическую задачку, что бы понять как человек будет рассуждать и куда пойдёт в своих мыслях. Я считаю, что если человек мне рассказывает, как он тарбшутил CNI в кубе, то уж точно он знает что такое базовые понятия сети и уж тем более shell. К счастью в нашей команде с выбором мы пока не ошиблись.
охохо, такие простые инструменты, когда k не дядин, а свой. Я предпочитаю на bare metal микросервисы гонять, по определению проще )
Ещё в копилку детектор: если админ на сервер тянет докер (без kuber-а и подобного) то он или сильно ленивый или сильно глупый. В любом случае гнать тапком )
Вам нужно запустить пяток контейнеров, чтобы они чего-то там крутили, разбирали данные и предоставляли интерфейс к этим данным паре человек внутри компании. Будете поднимать кубер? Да там даже супервизор или юнит системд не нужен! Через пару дней заметят что обработка не идет и пнут админа перезапустить.
Или чатик корпоративный на 100 человек запустить, чтобы не вносить руками каждого — вбил в АД и все само подтянулось. Сейчас все контейнерами распространяется.
Или Nextcloud, onlyoffice.
Или…
Таких или может быть миллион. До Kubernetes надо дорасти. В противном случае только его и будешь админить, на лстальную работу уже времени не хватит.
Я вот фуллстек админ(по старым меркам, железо-виртуализация-сеть), в паровоз моды зарождающейся контейнеризации не впрыгнул в свое время. Докер и кубер изучены на уровне "поднял - посмотрел - прикольно - прибил". В не ИТ компаниях их применимость часто сомнительна. Старая добрая обычная виртуализация на esxi\hyper-v\kvm\openvz достаточна для задач не ИТ бизнеса.
И если к своим текущим знаниям решу добавить требуемое в DevOps, то работа будет искаться с вероятностью 90% вне РФ. "Хорошие условия" и "высокие зарплаты" даже Москвы в сравнении с середнячковыми валютными аналогами смотрятся так себе(в большинстве, может есть и сравнимые, но я не встречал и не знаю людей, которые бы встречали).
Не знаю как у вас в РФ, у нас в Украине уже 90% работы на внешнего заказчика. И вся она связана с облаками, кубами, и т. Д.
По зарплатам... Ну 2K реально. 4к реально. 5К реально. И даже на 7К проскакивают вакансии... Но всё что выше чем 2К надо знать ещё и английский на достаточном для обсуждения проблемы уровне.
И с этим английским всё сложнее. Если с хорошим сисадминским бекграундом ты возьмёшь на обслуживание кубернетис, то через пол года ты будешь как рыба в воде, ничего сложного в нём нет.
А вот с английским всё сложнее. Пол года это чуть подтянуть уровень... Потом ещё чуть... И я вроде как уже лет 5 его учу с перерывами, и всё равно очень далеко до иделал.
2к у меня и сейчас есть в Москве, в классическом сисадминстве не в ИТ компании. Как говорят знакомые, это весьма неплохо по отрасли, выше среднего. Но в сравнении с западными зарплатами, где 60к в год в ИТ для инженера это скромненько, почти любые зарплаты в СНГ это слезки.
Английский да, объемный весьма вопрос. Native уровень скорей всего недостижим, если не работать над этим плотно с самого детства. Но достаточное для понимание знание нагоняется довольно быстро. База и так есть, поскольку большая часть документации, статей, вспомогательной всякой информации и так на английском(читаем/пишем/спрашиваем). Сложно с разговором и с пониманием речи людей, у которых английский не родной или с различными акцентами. Иногда с индусами-саппортами европейских хостеров общаться приходится - мозг плавится.
А чтобы прям значительно больше типа 10 тыс, ну тоже реально, наверно в штатах, но это надо быть действительно крутым специалистом. В шататх тоже всем подряд по десятке не раздают.
150тыр в москорепе нормально? что-то они гонят…
только bare metal, только хардкор.
«esxi\» денег стоит
hyper-v маздай
в kvm live-миграции vm вроде недавно появились (или ещё нет)
«достаточна для задач не ИТ бизнеса.»
неИТбизнесы это замшелые монстры, где заявка в хелпдеск «прошу добавить ОЗУ в виртуалку 10.10.20.30» бродит неделями. сначала «open-vm-tools не стоит, не знаем что за виртуалка», потом «админ вася в отгуле», потом «для увеличения ОЗУ надо заглушить машину»? )
150тыр в москорепе нормально? что-то они гонят…
Исключая ориентированные за западные валютные заказы ИТ компании — да. Ну и не забывайте, что я не программист все же. Там рынок выше.
Любой способ виртуализации решает свои задачи. ESXi так то бесплатен сам по себе. live-миграция в kvm есть давно, но работает нормально только при наличии общего хранилища. Например, СХД с SAS линками в несколько физических серверов. По сети гонять машинки вместе с переносом диска в live режиме не пробовал. Может в последних релизах есть.
неИТбизнесы это замшелые монстры, где заявка в хелпдеск «прошу добавить ОЗУ в виртуалку 10.10.20.30» бродит неделями. сначала «open-vm-tools не стоит, не знаем что за виртуалка», потом «админ вася в отгуле», потом «для увеличения ОЗУ надо заглушить машину»? )
Перегибаете. Просто бизнес. Логистика, производства, оптовая торговля, офисы, магазины, склады. И такие задачи, как вы описали, просто решаются или звонком или письмом и закрываются в течении дня.
Много людей на хабре живет в мире FAANG мысленно. Забывая, что есть совсем другие бизнесы, не ИТ, у которых есть своя инфраструктура под их запросы со своими особенностями.
Сейчас сложно сказать, что считать не-IT компаниями. Банки, ритейл, энергетика, логистика, медицина, производство - сейчас предприятии любой индустрии может быть очень сильная IT-команда.
Тут скорее вопрос не отрасли. По сути, если на предприятии ведется собственная разработка, то это уже IT-компания.
Заводу, который варит алюминий, приносит деньги алюминий. Какой-то складской-логистической компании приносят деньги склады и фуры. В ритейле и оптовке приносит деньги сама торговля. ИТ во всех этих отраслях вещь вспомогательная. Вероятные исключения это банки со своими ИТ фирмами-спутниками, которых можно считать ИТ фирмами, но не генерирующими деньги.
В Почте России ведется очень много разработки своих продуктов, сугубо внутренних, но назвать эту компанию ИТ-компанией нельзя никак.
По мне можно за ИТ компании считать всего два типа. Первый это софтверные фирмы, где деньги приносит код. Второй это ИТ аутсорсинг, где деньги приносит условное комплексное обслуживание инфраструктуры.
Не могу с вами согласиться. Uber, Netflix, Amazon, наш Озон - это всё IT-компании, хотя деньги им приносит не разработка, а эксплуатация софта.
Я всё же склоняюсь к своему мнению — если в фирме ведется разработка, то это уже IT-фирма. Она может заниматься чем угодно еще и зарабатывать (или не зарабатывать, если это НКО) на чем-то другом, но в ней будут присутствовать все процессы, свойственные IT-компаниям соответствующих их отделу разработки размеров.
Вообще многие крупные компании выделяют разработку в дочернюю компанию (Сбертех, Альфа-лаборатория, есть у нефтянки такие же), но это вопрос администрирования скорее. Они и отдел кадров могут в отдельную компанию вынести.
Но точно могу сказать работать айтишником не в IT компаниях такое себе счастье.
А мне наоборот как-то приятнее, хоть и менее оплачиваемо. Я всю инфраструктуру строил сам, от сборки железа в стойках. Знаю что, где и как.
А под ИТ компаниями можно очень разное понимать. Условный Ланит — это ИТ компания. Но работа админом там — это работа на чужие инфраструктуры, в которых еще поди разберись.
Возможно в ИТ-софтверных компаниях, чей конечный продукт именно ПО, работа сисадмином/девопсом будет и комфорта и интересна, но у меня такого личного опыта не было, не могу утверждать.
Я бы хотел развернуть категорию Я - DevOps (раз уж мы говорим про DevOps). Вот мы ищем как раз из этой категории.
Что тут важно? Чтобы специалист понимал, как вообще происходит разработка софта. Желательно, чтоб знал разные жизненные циклы продуктов, разные модели ветвлений. Знал бы, как приложения собираются и пакуются. Понимал, как происходит тестирование и валидация, зачем нужны и как строятся тестовые контуры. Понимал, какие проблемы возникают при работе конвейера у разработчиков и тестировщиков.
Ну и плюс конечно широкий админский базис (но не обязательно глубокий), понимание проблем эксплуатации в проде (мониторинг, безопасность, отказоустойчивость) и умение автоматизировать задачи.
Конкретно нам еще важно, чтоб у специалиста был опыт работы с облаками, с дизайном и построением облачной инфраструктуры для современных приложений.
Мы считаем, что именно такие специалисты помогают улучшать процесс разработки приложений.
Реальность порою сильно отличается от представлений о ней. Вот вам кажется, что вы написали что-то осмысленное, а в реальности это не так.
Вместо меня максимум нужен нормальный разраб, который бы занимался разработкой инструментов для внутреннего использования.
Зачем, если этот разраб вы? Можно легко научить разработчика писать хорошие Dockerfile-ы, создавать инфраструктуру терраформом, настраивать CI/CD. Хороший разработчик этому легко научится. Потом его надо будет мотивировать заниматься этими вещами для остальных (чтоб каждого не учить): поднять зарплату на 20% и назвать модным словом DevOps.
Это не делает меня особенным.
Особенных в мире вообще единицы. Если вы считаете, что каждый должен быть особенным, то это невозможно просто в силу, что если все такими будут, они уже не будут особенными.
Вдобавок devops позиция как Devops специалиста по вашему определению, в принципе не может существовать, потому что налаживание DevOps — это уровень менеджмента, причем желательно не мелкого звена. Иначе полномочий не хватит даже построить работу дев команд.
Фраза "DevOps это методология" осталась в 2017. Сейчас DevOps это набор скилов.
В поисках идеального DevOps. Кого сейчас ищут на рынке IT?