Добрый день. Спасибо. Пока нет, но хотелось бы. По производительности резолвинг выглядит для меня в пределах нормы, хотя и требует еще улучшений в рамках кэша (кстати поэтому и не хотелось выключать 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
проходило ровно половину тестов, что с ним не так, я не смог разобраться...
Добрый день. Я согласен, с тем что All Cups не выполнил свои обязательства перед Ozon, не выдержав нагрузки. Однако, решения о проведении контеста любой ценой и со странными правилами, как мне кажется, принимал не All Cups: я искренне уверен в том, что более честным решением было бы вовсе отменить проведения турнира в тот день, нежели проводить его со странными не озвученными ранее правилами (понимаю что Озон понес бы репутационные потери, однако, в любом случае, потери и так были). К тому же совершенно не представляю как сейчас Озон сформирует списки зачисленных, поэтому проведение данного контеста любой ценой выглядит для меня тем самым "выстрелом в ногу" Также в статье затронуты проблемы, которые, как мне кажется, не связаны с All Cups:
неочевидных формулировок задач
ошибок в условиях задач
странных ошибок в тестах на задачи
бального ранжирования задач (переоцененность задач на Bash)
анкеты, заполняемой в конце состязания (ссылка на резюме, которого может не быть в открытом доступе, возраст...)
В любом случае, надеюсь, что обе компании получили бесценный опыт и сделали очень важные для себя выводы.
Ozon Tech Также для ребят, прошедших на курс, думаю будет интересным и полезным разбор постмортема о случившемся на All Cups (хотя, думаю, всем участникам турнира это было бы интересно).
Т.е. вы не используете ни Java, ни c++ ни go? Может быть вы еще и свои компиляторы, интерпретаторы и виртуальные машины создали? И никаких сторонних библиотек из опенсорса не подключали? Всё сами пишите?
Думаю, здесь лучше справятся рекрутеры Озона, но пока попробую ответить я. При беглом просмотре нашел вот эту открытую вакансию и еще заметил, что все проекты используют Keycloak, который, подозреваю, используется не в сыром виде, а скорее всего расширен плагинами (а их уж точно лучше писать на Java).
Спасибо за рекомендацию, уже давно засматриваюсь на Авито) По RSU уточню: во многих зарубежных компаниях они начисляются раз в квартал в зависмости от схемы выплат, в Ozon - вроде бы раз в год (но тут я у них не уточнял). Для себя рассматриваю RSU как более удачную альтернативу премиям.
Знаете, это как обзорщики еды: на свой адрес еду не заказывают... )) Я думаю, по статьям, компании не трудно понять кто автор. P.S. "Тайнсвенный аноним ..." - мне понравилось, добавил в описание профиля
Видеозаписи не было, просто интервьюер уточнил, что будет иногда "подвисать" из-за фиксации моих ответов "на бумаге", фактически вести лог интервью)) Решил отметить данный факт, так как в России впервые столкунулся с данной практикой.
Т.к. это первая статья, возможно не везде удалось передать ее главный смысл. А смысл - не нужно бездумно копировать подходы, которые используют big tech компании, т.к. для таких подходов нужно специально обучать интервьюеров. Конкретно по пунктам:
1) IDE при таких задачах не должно быть основным инструментом. У вас не проверяют специфичные особенности языка при коддинге. В инструкции Тинькоффа заявлено, что у них есть онлайн редактор, поэтому есть шанс, что некоторые кандидаты могут использовать ноутбук/компьютер без IDE
2) Хорошие интервьюеры стараются заботится о комфорте кандидата и никогда не предложат использовать что-либо, не предоставив никакого интро по тулам. FAANG всегда делает подробные интро по тому, что они используют во время интервью (Могу ошибаться насчет всех, но больше половины пробовал - знаю). Да что далеко ходить, даже тот же Яндекс дает шанс ознакомиться с их системой для коддинга перед интервью.
3) В статье никоим образом не высказываются обиды, т.к. их в принципе нет. Единственное, что меня огорчило, так это абсолютное безразличие к моему фидбэку со стороны Тинькоффа, который я отправлял ему на почту.
По поводу задачи я согласен, что для кого-то она выглядит довольно легкой. Для меня - не очень. Это только мои проблемы :) По поводу ACID я с вами соглашусь. Приколов очень много, и сам с ними ни раз сталкивался. Но в статье все же поднимается проблема поверхностных вопросов. К сожалению ни одного доп. вопроса по этой теме у меня не спросили
Добрый день. Спасибо. Пока нет, но хотелось бы. По производительности резолвинг выглядит для меня в пределах нормы, хотя и требует еще улучшений в рамках кэша (кстати поэтому и не хотелось выключать 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, чтобы хоть как-то ее ускорить. На самом деле после рефакторинга стоит переосмыслить такой вариант и как-то гибко распределять тяжеловесные задачи по более мощным инстансам, которые можно поднимать по требованию. Спасибо за идею!Задача «Треки».
Решение вида:
проходило ровно половину тестов, что с ним не так, я не смог разобраться...
Добрый день. Я согласен, с тем что All Cups не выполнил свои обязательства перед Ozon, не выдержав нагрузки. Однако, решения о проведении контеста любой ценой и со странными правилами, как мне кажется, принимал не All Cups: я искренне уверен в том, что более честным решением было бы вовсе отменить проведения турнира в тот день, нежели проводить его со странными не озвученными ранее правилами (понимаю что Озон понес бы репутационные потери, однако, в любом случае, потери и так были). К тому же совершенно не представляю как сейчас Озон сформирует списки зачисленных, поэтому проведение данного контеста любой ценой выглядит для меня тем самым "выстрелом в ногу"
Также в статье затронуты проблемы, которые, как мне кажется, не связаны с All Cups:
неочевидных формулировок задач
ошибок в условиях задач
странных ошибок в тестах на задачи
бального ранжирования задач (переоцененность задач на Bash)
анкеты, заполняемой в конце состязания (ссылка на резюме, которого может не быть в открытом доступе, возраст...)
В любом случае, надеюсь, что обе компании получили бесценный опыт и сделали очень важные для себя выводы.
Ozon Tech Также для ребят, прошедших на курс, думаю будет интересным и полезным разбор постмортема о случившемся на All Cups (хотя, думаю, всем участникам турнира это было бы интересно).
Т.е. вы не используете ни Java, ни c++ ни go? Может быть вы еще и свои компиляторы, интерпретаторы и виртуальные машины создали? И никаких сторонних библиотек из опенсорса не подключали? Всё сами пишите?
Спасибо) Рад, что растёте и улучшаете процессы
Думаю, здесь лучше справятся рекрутеры Озона, но пока попробую ответить я. При беглом просмотре нашел вот эту открытую вакансию и еще заметил, что все проекты используют Keycloak, который, подозреваю, используется не в сыром виде, а скорее всего расширен плагинами (а их уж точно лучше писать на Java).
Спасибо за рекомендацию, уже давно засматриваюсь на Авито)
По RSU уточню: во многих зарубежных компаниях они начисляются раз в квартал в зависмости от схемы выплат, в Ozon - вроде бы раз в год (но тут я у них не уточнял). Для себя рассматриваю RSU как более удачную альтернативу премиям.
Знаете, это как обзорщики еды: на свой адрес еду не заказывают... ))
Я думаю, по статьям, компании не трудно понять кто автор.
P.S. "Тайнсвенный аноним ..." - мне понравилось, добавил в описание профиля
А вот с ними мне не повезло, но офер тоже был на почте. Возможно, стоит попробовать еще один раз)
Видеозаписи не было, просто интервьюер уточнил, что будет иногда "подвисать" из-за фиксации моих ответов "на бумаге", фактически вести лог интервью)) Решил отметить данный факт, так как в России впервые столкунулся с данной практикой.
Т.к. это первая статья, возможно не везде удалось передать ее главный смысл. А смысл - не нужно бездумно копировать подходы, которые используют big tech компании, т.к. для таких подходов нужно специально обучать интервьюеров. Конкретно по пунктам:
1) IDE при таких задачах не должно быть основным инструментом. У вас не проверяют специфичные особенности языка при коддинге. В инструкции Тинькоффа заявлено, что у них есть онлайн редактор, поэтому есть шанс, что некоторые кандидаты могут использовать ноутбук/компьютер без IDE
2) Хорошие интервьюеры стараются заботится о комфорте кандидата и никогда не предложат использовать что-либо, не предоставив никакого интро по тулам. FAANG всегда делает подробные интро по тому, что они используют во время интервью (Могу ошибаться насчет всех, но больше половины пробовал - знаю). Да что далеко ходить, даже тот же Яндекс дает шанс ознакомиться с их системой для коддинга перед интервью.
3) В статье никоим образом не высказываются обиды, т.к. их в принципе нет. Единственное, что меня огорчило, так это абсолютное безразличие к моему фидбэку со стороны Тинькоффа, который я отправлял ему на почту.
По поводу задачи я согласен, что для кого-то она выглядит довольно легкой. Для меня - не очень. Это только мои проблемы :) По поводу ACID я с вами соглашусь. Приколов очень много, и сам с ними ни раз сталкивался. Но в статье все же поднимается проблема поверхностных вопросов. К сожалению ни одного доп. вопроса по этой теме у меня не спросили