Есть такое в данный момент... Поделюсь своим опытом на сегодняшний день: - через карьерный сайт мне ответил Uber - по постам на Blinde стало понятно, что сейчас хайрит Amazon Dublin => cо мной связались после отклика на карьерном сайте (остальные локации вроде Нидерландов, Великобритании в игноре) - периодически прошу на Blinde зарефералить меня (работает далеко не в 100% случаев, скорее в 10% - желающие зарефералить или пропадают, или уходят в игнор)
Добрый день, в доковидные и ковидные времена мне с вполне обычным опытом рекрутеры(мета, амазон, убер) активно писали в linkedin. Во время текущих кризисов бигтеха активность рекрутеров в линкеде сошла на нет, однако, по своему опыту и моих коллег (не из бигтеха) все ещё работают отклики через карьерные сайты компаний, которые нанимают и рефералы в них же (можно получать просьбами в blinde). В данный момент (09.02.2024) на отклики через карьерные сайты хорошо отвечает Uber и Meta(чуть охотнее и быстрее если будет реферал) - резюме может быть абсолютно стандартным (главное одностраничным), на практике условное наличие так называемого русского "бигтеха" или других говорящих названий вообще необязательно. К сожалению, игнорирование резюме, на сегодняшний день не редкость, к примеру мои недавние отклики через рефералов в Гугл и Тикток так и остались незамеченными
В ЛС предпочитаю обсуждать именно процесс реферала (как минимум человеку нужно знать в какую компанию я могу зареферить, чтобы посмотреть открытые позиции + если человеку интересно - мне нужна его почта). По Вашей ситуации: на мой взгляд, можно начать откликаться и пытаться проходить скрининги (если какой-то скрининг будет пройден - то взять перерыв ~1месяц для усиленной подготовки). Почему я считаю что можно начинать сейчас: - если откликаться не через реферала, то на связь компании выходят не очень быстро (убер - исключение). После initial контакта с рекрутером не обязательно ставить скрининг через 2 дня, можно взять недельку на подготовку - в случае не удачных собесов cooldown начнется раньше )) (все равно прям активный хайринг сейчас на паузе, подъем ожидается в следующем году)
Для бигтехов бонус, причитающийся рекомендующему, несоизмерим (в разы меньше, а в некоторых случаях в десятки раз меньше) signin бонусу реферала. Обычно в referral форме, возможно указать, что человек, сам попросил себя порекомендовать и указать что лично с ним не знаком => на blind достаточно людей предпочитающих полностью утилизировать свой лимит на рефералов, чтобы, не прилагая особых усилий со своей стороны, получить приятную прибавку
Да, приходится постоянно сталкиваться с такой проблемой (и не всегда строчка c бигтехом в резюме помогает). В случаях полного игнорирования моего резюме все же пытаюсь найти реферал, если не получается - то дописываю/переписываю резюме в соответствии с описанием вакансии. По поводу реферала - не стоит бояться его просить, так как в большинстве бигтехов, порекомендовавший Вас получит вознаграждение после того как Вы отработаете полгода/год (в каких-то компаниях самому рекомендующему не обязательно продолжать работать до конца этого срока). Однако, прося реферал, стоит упомянуть, что к литкоду/cистем дизайну вы готовы, так как, зачастую кол-во рефералов ограничено (~50-100). Если все сложится, Вас порекомендуют сами или же вышлют реферал-ссылку, пройдя по которой, будет возможность выбрать интересные позиции (обычно есть ограничение в 3 штуки)
Сложно не согласиться, но, на мой взгляд, массовые увольнения не самая большая проблема, с которой можно столкнуться в бигтехе. Если говорить только об увольнениях, то за последних 2 года сокращения происходили далеко не только в бигтехах. Скажу честно, что предпочел бы быть сокращенным именно бигтехом (а не какой-то другой компанией) по нескольким причинам: - не нужно возвращать signon бонус/расходы на релокацию, если не успел отработать прописанный в контракте срок - как правило, по EU законодательству, в отличие от US, уволить одним днем невозможно. В случае массовых увольнений возможен процесс консультаций, во время которых обсуждается размер "отступных" и предоставляется возможность подыскать себе место в другом проекте/подразделении компании - в случае визовых вопросов, можно договориться на увеличенный garden leave - в дни массовых увольнений происходит активизация всевозможных рекрутеров, предлагающих различные возможности - и т.д
спасибо за интересную к прочтению статью, особенно за описание некоторых особенностей/багов JVM в контейнерной среде. Правильно ли я понимаю, что одна из целей выставления "правильного" cpu request - ускорение старта JVM(ведь после старта сpu утилизировалась в меньшей мере)? Если это так, то почему в системе время старта JVM based пода настолько критично, ведь скорее всего он реплицирован и обновляется gradually (или же нет)? Или же имеет место ситуация, когда все поды сервисы перезагружаются одновременно?
Добрый день. Краткий ответ - да, затраты окупились.
Здесь не указаны все детали продукта, поэтому соглашусь, что понятно "а стоит ли оно того?". В рамках данного продукта это был большой профит. Эта была не единственная инсталляция и при запуске новых мы уже могли полагаться на архитектуру с HDD, что значительно сокращало начальную стоимость. По поводу просадки в производительности не соглашусь, т.к. она для конечного пользователя не пострадала на видимом уровне за счет уменьшения изначального размера partition с которым работал запрос на чтение. Фактически, overuse iops'ов не давал никакого преимущества и был спокойно упразднен в пользу HDD
Пожалуй, главный посыл этой заметки был о важности выбора правильной структуры хранения данных и как это помогает снизить затраты на инфраструктуру. А вот уж момент, когда делать/не делать этот выбор, зависит от многих факторов
Добрый день. Спасибо. Пока нет, но хотелось бы. По производительности резолвинг выглядит для меня в пределах нормы, хотя и требует еще улучшений в рамках кэша (кстати поэтому и не хотелось выключать systemd-resolved на машинах для всех запросов). Все это чудо разворачивается на AWS, а у него есть явные лимиты по кол-ву запросов внутри VPC (https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-limits). Ну и кол-во трафика никто не отменял. А так, в дальнейшем, мне было бы очень интересно сравнить результаты systemd-resolved + "Go" resolver, ходящий на127.0.0.53 и "Cgo" resolver.Мне кажется, преимущества go рутин здесь может сыграть
Спасибо, интересная идея! Надо бы протестировать. Через kube-api идея сразу отвалилась, т.к. он и так достаточно нагружен (crossplane и еще всякое). Еще не уверен, насколько сильно rsync ударит по iops, т.к. мы все таки это не в in-memory храним, а перегнать надо в сумме около 1 Гб мелких файлов. Если доберусь - обязательно отпишусь о результатах.
Без упоминания про необходимость платить за мастеров, lb для них и т.д. в "своём" k8s это как-то странно.
Да, согласен, упустил этот момент, спасибо. Добавил упоминание.
Плохой пример и регионов всё больше и больше
Я лишь описал с каким примером столкнулся на практике. Дело было в 2019-2020 и в ОАЭ балом правил Azure. Сейчас появляется все больше и больше регионов, это не может не радовать. Однако мой главный посыл был не только про AWS, а про любые облака в целом.
То что он становится мощнее и круче - не значит проще. Согласен, что до сих пор появляются какие-то решения, которые упрощают жизнь. Однако вместе с ними появляется куча нововведений за которыми нужно следить и знать как они работают. Для этого порой changelog'a недостаточно и нужно лезть в сорцы. А там ты натыкаешься на такое... ну например на то, что я описал касательно protokube.service
Спасибо, что поделились своим опытом! Тоже юзали Rancher и выглядел он довольно неплохо на тот момент, однако с ним также возникало немало других проблем. Возможно, как Вы выразились, у нас был недостаточный коэффициент прямоты рук, но когда строили свой private cloud, мы много где отгребли.
Зачастую обновления кластера проще сделать созданием нового, переносом нагрузки и тестированием с откатом
Мне всегда было интересно почитать материалы на такие темы, особенно когда там описана миграция каких-нибудь сложных stateful сервисов. У меня как-то был опыт перетаскивания cassandra и postgres на другие k8s без простоя, но эти сервисы как бы подразумевают такую возможность. А вообще эта тема интересная, но как по мне это усложнение инфраструктуры. Кстати когда я описывал миграцию с KIAM, то да, это самый простой вариант обновления без простоя в нашей ситуации
А вот в одном облаке не удалось потушить часть нод на время и это вылезло в $$$
Можете поподробнее описать как так получилось, в чем была проблема и какое это было облако?
Про обновления вообще молчу - ни разу не удалось качественно обновиться без простоев.
Почему-то у меня складывается ощущение, что речь о каком-то конкретном облаке. Можете поделиться?
Managed Kubernetes это про удобство и квалификацию команды
Это имеет место быть. Однако здесь важно еще упомянуть размер команды. Когда команда небольшая, вы скорее всего будете стремиться к максимальному упрощению своей инфраструктуры
Мне кажется даже в вашем примере все зависит от обстоятельств, не говоря уж о k8s. Я не призываю всех поголовно отказываться от своего k8s, а просто рассказываю, что проблем у него хватает. С каждым новым релизом k8s становится все сложнее и сложнее, как по мне, а соответственно его поддержка все дороже и дороже. И с точки зрения оптимизации расходов важно найти ту самую грань, где выгоднее ставить свой k8s, а где воспользоваться готовым платным решением.
Добрый день, спасибо за замечание. Действительно минио неплохой инструмент, однако в нашей команде довольно много сервисов на поддержке и добавление еще одного согласовать проблематично. Особенно только для какой-то одной задачи. Поэтому данный вариант нам не подходил
Добрый день, спасибо за комментарий! 1) Да, прошу прощения, не нашел как в дженкинсе отобразить время выполнения всех шагов для наглядности. Самые тяжеловесные это тесты jest и enzyme + linting тоже не всегда легковесный и занимает достаточно времени 2) Совсем забыл в статье упомянуть какая еще проблема решалась. Стабильность. В такой сборке довольно непросто контролировать память и кол-во порождаемых сборщиком процессов. А так-как мы вращаем все сборки в k8s на одном пуле машин, то мы явно задаем лимиты для пода по используемой памяти. Ответ на вопрос - да, сначала так и делали, но на больших сборках тесты были нестабильные и часто валились по OOM, т.к. на больших сборках часто выставлялись большие значения --parallel , чтобы хоть как-то ее ускорить. На самом деле после рефакторинга стоит переосмыслить такой вариант и как-то гибко распределять тяжеловесные задачи по более мощным инстансам, которые можно поднимать по требованию. Спасибо за идею!
SELECT TrackId, SUM(Quantity) as total FROM InvoiceLine il
JOIN Invoice i ON i.InvoiceId = il.InvoiceId
WHERE strftime('%Y', i.InvoiceDate) >= '2010'
GROUP BY TrackId ORDER BY total DESC, TrackId ASC
проходило ровно половину тестов, что с ним не так, я не смог разобраться...
Есть такое в данный момент...
Поделюсь своим опытом на сегодняшний день:
- через карьерный сайт мне ответил Uber
- по постам на Blinde стало понятно, что сейчас хайрит Amazon Dublin => cо мной связались после отклика на карьерном сайте (остальные локации вроде Нидерландов, Великобритании в игноре)
- периодически прошу на Blinde зарефералить меня (работает далеко не в 100% случаев, скорее в 10% - желающие зарефералить или пропадают, или уходят в игнор)
Добрый день, в доковидные и ковидные времена мне с вполне обычным опытом рекрутеры(мета, амазон, убер) активно писали в linkedin. Во время текущих кризисов бигтеха активность рекрутеров в линкеде сошла на нет, однако, по своему опыту и моих коллег (не из бигтеха) все ещё работают отклики через карьерные сайты компаний, которые нанимают и рефералы в них же (можно получать просьбами в blinde). В данный момент (09.02.2024) на отклики через карьерные сайты хорошо отвечает Uber и Meta(чуть охотнее и быстрее если будет реферал) - резюме может быть абсолютно стандартным (главное одностраничным), на практике условное наличие так называемого русского "бигтеха" или других говорящих названий вообще необязательно. К сожалению, игнорирование резюме, на сегодняшний день не редкость, к примеру мои недавние отклики через рефералов в Гугл и Тикток так и остались незамеченными
В ЛС предпочитаю обсуждать именно процесс реферала (как минимум человеку нужно знать в какую компанию я могу зареферить, чтобы посмотреть открытые позиции + если человеку интересно - мне нужна его почта).
По Вашей ситуации: на мой взгляд, можно начать откликаться и пытаться проходить скрининги (если какой-то скрининг будет пройден - то взять перерыв ~1месяц для усиленной подготовки). Почему я считаю что можно начинать сейчас:
- если откликаться не через реферала, то на связь компании выходят не очень быстро (убер - исключение). После initial контакта с рекрутером не обязательно ставить скрининг через 2 дня, можно взять недельку на подготовку
- в случае не удачных собесов cooldown начнется раньше )) (все равно прям активный хайринг сейчас на паузе, подъем ожидается в следующем году)
Для бигтехов бонус, причитающийся рекомендующему, несоизмерим (в разы меньше, а в некоторых случаях в десятки раз меньше) signin бонусу реферала.
Обычно в referral форме, возможно указать, что человек, сам попросил себя порекомендовать и указать что лично с ним не знаком => на blind достаточно людей предпочитающих полностью утилизировать свой лимит на рефералов, чтобы, не прилагая особых усилий со своей стороны, получить приятную прибавку
На мой взгляд, вполне (дальше в ЛС).
Да, приходится постоянно сталкиваться с такой проблемой (и не всегда строчка c бигтехом в резюме помогает). В случаях полного игнорирования моего резюме все же пытаюсь найти реферал, если не получается - то дописываю/переписываю резюме в соответствии с описанием вакансии.
По поводу реферала - не стоит бояться его просить, так как в большинстве бигтехов, порекомендовавший Вас получит вознаграждение после того как Вы отработаете полгода/год (в каких-то компаниях самому рекомендующему не обязательно продолжать работать до конца этого срока). Однако, прося реферал, стоит упомянуть, что к литкоду/cистем дизайну вы готовы, так как, зачастую кол-во рефералов ограничено (~50-100). Если все сложится, Вас порекомендуют сами или же вышлют реферал-ссылку, пройдя по которой, будет возможность выбрать интересные позиции (обычно есть ограничение в 3 штуки)
Сложно не согласиться, но, на мой взгляд, массовые увольнения не самая большая проблема, с которой можно столкнуться в бигтехе.
Если говорить только об увольнениях, то за последних 2 года сокращения происходили далеко не только в бигтехах. Скажу честно, что предпочел бы быть сокращенным именно бигтехом (а не какой-то другой компанией) по нескольким причинам:
- не нужно возвращать signon бонус/расходы на релокацию, если не успел отработать прописанный в контракте срок
- как правило, по EU законодательству, в отличие от US, уволить одним днем невозможно. В случае массовых увольнений возможен процесс консультаций, во время которых обсуждается размер "отступных" и предоставляется возможность подыскать себе место в другом проекте/подразделении компании
- в случае визовых вопросов, можно договориться на увеличенный garden leave
- в дни массовых увольнений происходит активизация всевозможных рекрутеров, предлагающих различные возможности
- и т.д
спасибо за интересную к прочтению статью, особенно за описание некоторых особенностей/багов JVM в контейнерной среде.
Правильно ли я понимаю, что одна из целей выставления "правильного" cpu request - ускорение старта JVM(ведь после старта сpu утилизировалась в меньшей мере)? Если это так, то почему в системе время старта JVM based пода настолько критично, ведь скорее всего он реплицирован и обновляется gradually (или же нет)? Или же имеет место ситуация, когда все поды сервисы перезагружаются одновременно?
Добрый день. Краткий ответ - да, затраты окупились.
Здесь не указаны все детали продукта, поэтому соглашусь, что понятно "а стоит ли оно того?". В рамках данного продукта это был большой профит. Эта была не единственная инсталляция и при запуске новых мы уже могли полагаться на архитектуру с HDD, что значительно сокращало начальную стоимость. По поводу просадки в производительности не соглашусь, т.к. она для конечного пользователя не пострадала на видимом уровне за счет уменьшения изначального размера partition с которым работал запрос на чтение. Фактически, overuse iops'ов не давал никакого преимущества и был спокойно упразднен в пользу HDD
Пожалуй, главный посыл этой заметки был о важности выбора правильной структуры хранения данных и как это помогает снизить затраты на инфраструктуру. А вот уж момент, когда делать/не делать этот выбор, зависит от многих факторов
На мой взгляд, вполне хорошая и реализуемая "претензия". "Войти в FAANG" так же реально, как и в другие компании с таким же процессом.
Базовая рекомендация абсолютно всех подборок - https://habr.com/ru/companies/piter/articles/309106/
"Золотой сборник" с разбором наиболее популярных систем - System Design Interview An Insider’s Guide by Alex Xu. Если основная цель подготовка к СД, можно рассмотреть этот материал как отправную точку.
https://github.com/weeeBox/mobile-system-design. Уклон на мобильные платформы, однако, очень много ценных мыслей для любого направления.
Добрый день. Спасибо. Пока нет, но хотелось бы. По производительности резолвинг выглядит для меня в пределах нормы, хотя и требует еще улучшений в рамках кэша (кстати поэтому и не хотелось выключать systemd-resolved на машинах для всех запросов). Все это чудо разворачивается на AWS, а у него есть явные лимиты по кол-ву запросов внутри VPC (https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-limits). Ну и кол-во трафика никто не отменял. А так, в дальнейшем, мне было бы очень интересно сравнить результаты systemd-resolved + "Go" resolver, ходящий на127.0.0.53 и "Cgo" resolver.Мне кажется, преимущества go рутин здесь может сыграть
Спасибо, интересная идея! Надо бы протестировать. Через kube-api идея сразу отвалилась, т.к. он и так достаточно нагружен (crossplane и еще всякое). Еще не уверен, насколько сильно rsync ударит по iops, т.к. мы все таки это не в in-memory храним, а перегнать надо в сумме около 1 Гб мелких файлов. Если доберусь - обязательно отпишусь о результатах.
Да, согласен, упустил этот момент, спасибо. Добавил упоминание.
Я лишь описал с каким примером столкнулся на практике. Дело было в 2019-2020 и в ОАЭ балом правил Azure. Сейчас появляется все больше и больше регионов, это не может не радовать. Однако мой главный посыл был не только про AWS, а про любые облака в целом.
Добрый день.
К тому, что managed k8s чаще выходит дешевле, чем использование своего, в статье после этих расчетов я об этом как раз и рассуждаю.
Если нужно развернуть свой SaaS в регионе без AWS. ОАЭ например.
Spot instances можно как раз отнести к специфике использования облака, потому что не все облака это предоставляют
То что он становится мощнее и круче - не значит проще. Согласен, что до сих пор появляются какие-то решения, которые упрощают жизнь. Однако вместе с ними появляется куча нововведений за которыми нужно следить и знать как они работают. Для этого порой changelog'a недостаточно и нужно лезть в сорцы. А там ты натыкаешься на такое... ну например на то, что я описал касательно protokube.service
Спасибо, что поделились своим опытом! Тоже юзали Rancher и выглядел он довольно неплохо на тот момент, однако с ним также возникало немало других проблем. Возможно, как Вы выразились, у нас был недостаточный коэффициент прямоты рук, но когда строили свой private cloud, мы много где отгребли.
Мне всегда было интересно почитать материалы на такие темы, особенно когда там описана миграция каких-нибудь сложных stateful сервисов. У меня как-то был опыт перетаскивания cassandra и postgres на другие k8s без простоя, но эти сервисы как бы подразумевают такую возможность. А вообще эта тема интересная, но как по мне это усложнение инфраструктуры. Кстати когда я описывал миграцию с KIAM, то да, это самый простой вариант обновления без простоя в нашей ситуации
Можете поподробнее описать как так получилось, в чем была проблема и какое это было облако?
Почему-то у меня складывается ощущение, что речь о каком-то конкретном облаке. Можете поделиться?
Это имеет место быть. Однако здесь важно еще упомянуть размер команды. Когда команда небольшая, вы скорее всего будете стремиться к максимальному упрощению своей инфраструктуры
Мне кажется даже в вашем примере все зависит от обстоятельств, не говоря уж о k8s. Я не призываю всех поголовно отказываться от своего k8s, а просто рассказываю, что проблем у него хватает. С каждым новым релизом k8s становится все сложнее и сложнее, как по мне, а соответственно его поддержка все дороже и дороже. И с точки зрения оптимизации расходов важно найти ту самую грань, где выгоднее ставить свой k8s, а где воспользоваться готовым платным решением.
Добрый день, спасибо за замечание. Действительно минио неплохой инструмент, однако в нашей команде довольно много сервисов на поддержке и добавление еще одного согласовать проблематично. Особенно только для какой-то одной задачи. Поэтому данный вариант нам не подходил
Добрый день, спасибо за комментарий!
1) Да, прошу прощения, не нашел как в дженкинсе отобразить время выполнения всех шагов для наглядности. Самые тяжеловесные это тесты jest и enzyme + linting тоже не всегда легковесный и занимает достаточно времени
2) Совсем забыл в статье упомянуть какая еще проблема решалась. Стабильность. В такой сборке довольно непросто контролировать память и кол-во порождаемых сборщиком процессов. А так-как мы вращаем все сборки в k8s на одном пуле машин, то мы явно задаем лимиты для пода по используемой памяти. Ответ на вопрос - да, сначала так и делали, но на больших сборках тесты были нестабильные и часто валились по OOM, т.к. на больших сборках часто выставлялись большие значения
--parallel, чтобы хоть как-то ее ускорить. На самом деле после рефакторинга стоит переосмыслить такой вариант и как-то гибко распределять тяжеловесные задачи по более мощным инстансам, которые можно поднимать по требованию. Спасибо за идею!Задача «Треки».
Решение вида:
проходило ровно половину тестов, что с ним не так, я не смог разобраться...