Увидеть разницу между junior, middle и senior специалистами, т.е. рядовыми специалистами, но с разным уровнем hard skills (не путать с позициями требующими какого-то менеджмента) по резюме далеко не всегда можно. Много раз сталкивался, что в резюме всё красиво, 15+ лет опыта, иногда даже умеют красиво рассуждать про какие-то технологии, а копнешь чуть поглубже, оказывается, что просто наслушавшись насмотрелись, но руками не трогали и вообще по факту как DevOps даже не Junior. И такое встречал не один раз. И резюме я просматриваю не один.
Не соглашусь, бизнесмен продает результаты чужого труда.
Если он продает свое время, то он не бизнесмен, а наемный работник.
Как минимум Индивидуальные Предприниматели с вами не согласятся (а это чаще всё таки бизнесмены).
Напомню, что ИП по закону могут зарабатывать до 150+ миллионов в год, а некоторые зарабатывают и больше, но занимаются дроблением бизнеса на разные ИП, чтобы продолжать платить меньше налогов, например топовые инфоцыгане.
Всё -таки немного странно задавать на собеседовании только базовые вопросы. Прощупать глубину знаний то точно как то нужно.
Но, если честно, я не очень верю в live coding собеседования и предпочитаю давать тестовые задания на несколько дней, чтобы человек в комфорной ему обстановке всё обдумал, реализовал, а по результатам можно поговорить и поспрашивать.
девопс инженеры считают разворачивание nginx базовой задачей и не знают с какой стороны к лежачему куберу подойти
Не понятно, как первая часть предложения относится ко второй, ведь разворачивание nginx в кубере и есть базовая задача, а лежащий кубер уже не такая базовая.
Очень больно бывает когда в компании неожиданно падает мэнеджед кубер
И часто у вас такое бывает в большой тройке облаков AWS/GCP/Azure ?
Это я к тому, что есть очень длинный список того, что гораздо более важно проверить, чем troubleshooting etcd. Я не говорил, что это не нужно делать вообще.
А вот в статье вроде как рассказывается про якобы хороший инструмент для собеседования, но пример выбран настолько неудачно базовый, но не понятно получилось ли сделать действительно хороший инструмент.
Если бы он был очень капризен, то по этому поводу было бы очень много статей даже на Хабре, а их почти нет.
У вас какой-то очень специфический сценарий его использования?
Имхо в минимум 3 экземплярах, с достаточным количеством ресурсов (cpu, memory и нормальные диски) + настроенным мониторингом не вижу повода для его капризности даже в on prem, если не пишете в него что-то "левое" или не растянули кластер по разным дц, а уж в нормальных облаках (читай AWS) так и вообще о нём редко когда вспоминаешь (за последние несколько лет ни на одном проекте не вспоминали ни разу, хотя некоторые проекты вполне нагруженные, но это мой опыт да).
Повторюсь: для ежедневных DevOps задач знания об эксплуатации etcd не нужны.
нужно поднимать инфраструктуру, на которой будет решаться задача
Не понимаю почему это не может быть частью задачи (если речь про AWS/... + Terraform) или почему нельзя заранее выделить под тест что нужно и потом удалить? А то и, прости Господи, развернуть динамический стенд в namespace? :))
Если не поднимать инфраструктуру, получится просто задачка ради задачки
Т.е. с деплоем nginx в кубер это не так? Задача ради задачи же (точнее её оценки).
Было бы интересно увидеть задачу на Senior (не Middle+), в т.ч. т.к. подозреваю, что в том числе в вашей системе такой задачи в нормально оформленном виде просто нет.
SRE - это DevOps с упором на обеспечение надёжности, доступности и т.п., что возникает при сколько нибудь имеющейся нагрузке, а если таковой нет, то нет и SRE. Часто на должностях SRE люди дежурят, в т.ч. по ночам (что совсем не означает, что люди участвующие в дежурствах и имеющие такую должность действительно являются SRE).
Работа с любыми метриками, в т.ч. а ля бюджет ошибок, должна вестись и ведётся не только SRE, но и DevOps, а если она не ведётся, значит что-то делается не так, значит работаете вслепую, наугад и т.д. и это не совсем DevOps и не совсем SRE и попахивает просто плохим системным администрированием (при всём уважении к хорошим системным администраторам). И всякие отговорки вроде "некогда" и т.п. на самом деле не катят.
Вот с таким хабом я работал на Galaxy Note 2 в 2012 году со внешним монитором и беспроводными клавиатурой и мышкой полностью заменив им на какое-то время свой офисный комп https://phandroid.com/2012/10/31/galaxy-note-2-smart-dock
Привет от Бауманца, выпуск 2007 года, 6 лет, специалитет, ИУ8, изначально и всю жизнь я в IT. Аналогично и одногруппники, но специальность такая, странно, если было бы как то иначе. Языки программирования, представьте себе, преподавали, включая C++ по Страуструпу и не только :)
С 9,5 баллами из 10 я еле попал на свою кафедру/специальность на бюджет, но попал :) Вступительные были математика + физика. ещё был экзамен по русскому литературе, но там не помню были ли даже баллы :) Никакого ЕГЭ естественно.
Большинство людей не москвичи, а ребята со всей страны (не включая меня).
Холиварная тема, но поделюсь личным опытом: при приёме на работу на начальных этапах Бауманка безусловно даёт преимущество. Более того, это работало и при приёме на работу в США в силиконке, т.к. бренд и позитивная репутация Бауманки международные.
Одногруппники сходу по памяти работают/ли в таких компаниях, как Google, Intel, Samsung, Яндекс, Касперский, Сбер и т.д.
Вы забыли добавить, что VictoriaMetrics (VM) является in place replacement Prometheus'а, т.е. она практически полностью дублирует весь функционал, api и т.д Vm'а, поэтому, если вы используете Prometheus или знаете как его использовать, то с высокой долей вероятности вы можете просто заменить его на VM и остальные компоненты системы этого даже не поймут.
Более того, у VM есть отличный собственный функционал длительного хранения метрик без необходимости подключения какого-нибудь внешнего решения вроде Thanos, который для этого нужен Prometheus.
Рад за вас, но это не совсем релевантно.
Увидеть разницу между junior, middle и senior специалистами, т.е. рядовыми специалистами, но с разным уровнем hard skills (не путать с позициями требующими какого-то менеджмента) по резюме далеко не всегда можно. Много раз сталкивался, что в резюме всё красиво, 15+ лет опыта, иногда даже умеют красиво рассуждать про какие-то технологии, а копнешь чуть поглубже, оказывается, что просто наслушавшись насмотрелись, но руками не трогали и вообще по факту как DevOps даже не Junior. И такое встречал не один раз. И резюме я просматриваю не один.
Как минимум Индивидуальные Предприниматели с вами не согласятся (а это чаще всё таки бизнесмены).
Напомню, что ИП по закону могут зарабатывать до 150+ миллионов в год, а некоторые зарабатывают и больше, но занимаются дроблением бизнеса на разные ИП, чтобы продолжать платить меньше налогов, например топовые инфоцыгане.
Всё -таки немного странно задавать на собеседовании только базовые вопросы. Прощупать глубину знаний то точно как то нужно.
Но, если честно, я не очень верю в live coding собеседования и предпочитаю давать тестовые задания на несколько дней, чтобы человек в комфорной ему обстановке всё обдумал, реализовал, а по результатам можно поговорить и поспрашивать.
Не понятно, как первая часть предложения относится ко второй, ведь разворачивание nginx в кубере и есть базовая задача, а лежащий кубер уже не такая базовая.
И часто у вас такое бывает в большой тройке облаков AWS/GCP/Azure ?
Это я к тому, что есть очень длинный список того, что гораздо более важно проверить, чем troubleshooting etcd. Я не говорил, что это не нужно делать вообще.
А вот в статье вроде как рассказывается про якобы хороший инструмент для собеседования, но пример выбран настолько неудачно базовый, но не понятно получилось ли сделать действительно хороший инструмент.
А я и не писал, что все используют managed. Но многие таки используют.
Вообще не показательно, о чём я и написал. И недоумеваю что это за деплой nginx тут в статье и больше ничего.
Примеров нормальных kubernetes troubleshooting exercises полным полно, технология уже достаточно старая.
Если бы он был очень капризен, то по этому поводу было бы очень много статей даже на Хабре, а их почти нет.
У вас какой-то очень специфический сценарий его использования?
Имхо в минимум 3 экземплярах, с достаточным количеством ресурсов (cpu, memory и нормальные диски) + настроенным мониторингом не вижу повода для его капризности даже в on prem, если не пишете в него что-то "левое" или не растянули кластер по разным дц, а уж в нормальных облаках (читай AWS) так и вообще о нём редко когда вспоминаешь (за последние несколько лет ни на одном проекте не вспоминали ни разу, хотя некоторые проекты вполне нагруженные, но это мой опыт да).
Повторюсь: для ежедневных DevOps задач знания об эксплуатации etcd не нужны.
Пробовали использовать VictoriaMetrics вместо Prometheus? По ресурсам точно должен быть сильный выигрыш.
Не понимаю почему это не может быть частью задачи (если речь про AWS/... + Terraform) или почему нельзя заранее выделить под тест что нужно и потом удалить? А то и, прости Господи, развернуть динамический стенд в namespace? :))
Т.е. с деплоем nginx в кубер это не так? Задача ради задачи же (точнее её оценки).
Сомнительно.
Понимать как устроен куб, конечно, нужно, но часто ли вам на практике приходится чинить etcd/..., особенно если вы в используете managed куб ?
Мне для найма сотрудника/коллеги было бы интереснее увидеть выполнение более практических задачи.
Например, видел такой проект, который не использовал сам, но описание очень даже интересное ссылка
Умение DevOps'а задеплоить nginx в куб это даже не уровень джуна и есть даже в базовой доке куба ссылка
Только вот нигде не встречаю "развития темы".
Было бы интересно увидеть задачу на Senior (не Middle+), в т.ч. т.к. подозреваю, что в том числе в вашей системе такой задачи в нормально оформленном виде просто нет.
Плюс за заголовок, хоть какой-то креатив! :)
А по сути: вот все говорят про какие-то сложные задачи, а показывают деплой nginx, что является очень очень базовой задачей. Скучно и не интересно.
Схожие цели? Разные подходы? Нет.
Даже сам Google говорит: "class SRE implements DevOps"
What's the Difference Between DevOps and SRE? (class SRE implements DevOps)
Want to supercharge your DevOps practice? Research says try SRE
SRE - это DevOps с упором на обеспечение надёжности, доступности и т.п., что возникает при сколько нибудь имеющейся нагрузке, а если таковой нет, то нет и SRE. Часто на должностях SRE люди дежурят, в т.ч. по ночам (что совсем не означает, что люди участвующие в дежурствах и имеющие такую должность действительно являются SRE).
Работа с любыми метриками, в т.ч. а ля бюджет ошибок, должна вестись и ведётся не только SRE, но и DevOps, а если она не ведётся, значит что-то делается не так, значит работаете вслепую, наугад и т.д. и это не совсем DevOps и не совсем SRE и попахивает просто плохим системным администрированием (при всём уважении к хорошим системным администраторам). И всякие отговорки вроде "некогда" и т.п. на самом деле не катят.
Вот с таким хабом я работал на Galaxy Note 2 в 2012 году со внешним монитором и беспроводными клавиатурой и мышкой полностью заменив им на какое-то время свой офисный комп https://phandroid.com/2012/10/31/galaxy-note-2-smart-dock
У вас бы и не получилось использовать CI/CD без того, чтобы разобраться, что именно этот CI/CD должен делать.
Мягко говоря, не очень хорошее решение.
Логичнее было бы cron, а так для Docker есть более нативные решения, например https://github.com/mcuadros/ofelia
в Ubuntu 22.04 python3 ставить не нужно, он и так там есть
а мы накатим прошивку с 4pda/xda и всё :)
Привет от Бауманца, выпуск 2007 года, 6 лет, специалитет, ИУ8, изначально и всю жизнь я в IT. Аналогично и одногруппники, но специальность такая, странно, если было бы как то иначе. Языки программирования, представьте себе, преподавали, включая C++ по Страуструпу и не только :)
С 9,5 баллами из 10 я еле попал на свою кафедру/специальность на бюджет, но попал :) Вступительные были математика + физика. ещё был экзамен по русскому литературе, но там не помню были ли даже баллы :) Никакого ЕГЭ естественно.
Большинство людей не москвичи, а ребята со всей страны (не включая меня).
Холиварная тема, но поделюсь личным опытом: при приёме на работу на начальных этапах Бауманка безусловно даёт преимущество. Более того, это работало и при приёме на работу в США в силиконке, т.к. бренд и позитивная репутация Бауманки международные.
Одногруппники сходу по памяти работают/ли в таких компаниях, как Google, Intel, Samsung, Яндекс, Касперский, Сбер и т.д.
Tier 1? Tier 0!
del
Вы забыли добавить, что VictoriaMetrics (VM) является in place replacement Prometheus'а, т.е. она практически полностью дублирует весь функционал, api и т.д Vm'а, поэтому, если вы используете Prometheus или знаете как его использовать, то с высокой долей вероятности вы можете просто заменить его на VM и остальные компоненты системы этого даже не поймут.
Более того, у VM есть отличный собственный функционал длительного хранения метрик без необходимости подключения какого-нибудь внешнего решения вроде Thanos, который для этого нужен Prometheus.