Хехе, ну да, если посмотреть с такой стороны, действительно кейс выглядит забавно))
Там под капотом этой истории, конечно, еще желание руководства сделать бэкенд микросервисным, комплексный рефактор для повышения SLA сервиса, и вообще переезд, в том числе, связан с закупками новых железок и еще много иного контекста. Наверно даже его бы стоило добавить в статейку, для ясности. Ну что ж, в следующий раз учту.
А по тезисам - база, опыт сын ошибок трудных, 100% согласия. Спасибо за комментарий, еще раз)
Кейс Алексея здесь, конечно, гиперболизирован, просто такой выбран формат повествования, по сути это обычная рабочая рутина, не расскажи я об этом, никто бы особенно не заметил, как и сам Алексей. Такие героические эпосы каждую неделю происходят, просто это мой способ благодарить надежных сотрудников.
Про инфру и 90% поддержки. Ну, тут соглашусь, каждая компания и каждый техлид выбирает свой подход к построению сервисов, чем синьорнее - тем злее. Я здесь пробежался по типичныму кейсу, которые я часто видел. Чем больше энтерпрайз бизнес, тем больше предъявляется требований к масшабируемости, отказоустойчивости, безопасности и управляемости, а-ля cloud native подход. По этой причине у нас такие относительно долгие аналитические процессы по закатыванию фич и сервисов в облако, да и не только у нас.
Хочется по быстрому и, иногда, на коленке, но зачастую так просто нельзя, иначе получается безидейные продукты, которые не будут жить в долгосроке, отсюда и кубер и хелм чарты и прочее. Если у вас не так, ну что ж, значит вам повезло чуть больше :)
Во-первых, этот тред начался с размера компенсации по SLA, вы сами то в эту табличку что ли посмотрите, внимательно, размер выплат зависимости выплат от простоя :)
Во-вторых, вы знаете реальные кейсы выплат, как и сколько и когда возвращают, особенно вот у этих товарищей из таблицы? Я знаю, я в некоторых из них работал. Какие условия возврата средств? Ну вот. В cloud.ru честные.
Во-третьих, это рейтинг c-news. Если вы правда в него верите, ну, что ж, что-то не знаете. Да и просто достаточно посмотреть кто в топах.
В-четвертых, у cloud.ru 3 облака на текущий момент, да, разные облака: Evolution, Advanced, VMWare, и еще ML Space, но это не совсем облако в привычном смысле. Какого облака SLA измерялся? Да, они разные. И я не нашел, если честно, в рейтинге cloud.ru вообще, возможно, мы просто не участвовали, то 2024 года исследование, без учета наших последних модернизаций инфры. Значит в 2025 опять будем в топах, как и во всех остальных рейтингах. Не раз такое было.
В-пятых, вы когда-нибудь слышали про то, что cloud.ru упал? Хотя бы один из облаков? Хотя бы один раз? А если посмотреть в топ-10, как минимум по разу каждое падало. Тогда что вы хотите компенсировать?
Если честно, немного устал от этого треда, вы что-то как-то по-трольски вкидываете, плохо аргументируете, а я трачу на это время. Поэтому, с вашего позволения, предлагаю закончить.
Ну, судя по комментарию, предположу, что вы наш не очень доброжелатель :) Но это нормально, так бывает)
На самом деле, если капнуть глубже, мы почти единственные кто пишет об этом в открытую, поскольку мы за прозрачность. Если капнете глубже в другие облака, прочитаете договоры, удивитесь, что мы даем хорошие условия. Лучше чем большинство.
Ссылки есть, если поискать, но неправильно с моей стороны их здесь оставлять.
Также парирую ссылкой про SLA 99,95%, это отдельная услуга и другой контур, но инфа валидная.
Ну, я имею ввиду, что редиска используется, например в ecom, где в черную пятницу нагрузка до х20 вырастает. Это хорошо, если у вас он прем стоит и выдерживает стабильно х нагрузку, но когда становится х20, тут либо железо менять, либо как-то горизонтально ресурс масштабировать. Как раз история 2-3 кластера и еще куча нод/реплик. Хорошо, если он поверх кубера, и еще есть возможность отбалансировать. Но даже в этом случае, когда закончится черная пятница - нужно будет обратно скукоживать кластер.
Я чего только на редисе не видел. Ладно кэш, но в большинстве POSM-терминалов, например, он стоит как логер действий пользователя. И тут уже не смешно, когда каждые сутки он через AOF пишет на диск результаты, а потом приходит инженер и забирает диск с собой, меняя его, и потом загружая данные в hadoop, откуда потом забирают на анализ.
Кейс как есть, вполне живой, Алексей - реальный человек. Я с вами согласен, но в жизни вы не представляете, как часто вижу похожий кейс. Бизнес тревожится за скорость внедрения, часто задача прилетает специалисту, который в первый раз видит редис, отсюда и редис стейтфул. Да, пальцы в розетку.
Про брокер сообщений, вы говорите как человек, сведующий в опенсорсе. А если у вас большой монолит с уже заданными компонентами, тут не так смешно становится. Такие кейсы я видел, и тонные легаси вокруг тоже.
Это вы хорошо понимаете проблему и понимаете, что она легко решается, но когда у вас FQDN за семью печатями и вам нужно получить 4 уровня доступа, чтобы просто получить запись, становится не так смешно)) Не технически, но административно)
Отнюдь, кейс вполне реальный, буквально живой человек с живыми проблемами. Да, конечно, в реальности еще и другие проблемы могут всплывать, и всплывают, но кейс как есть, не больше - не меньше. А что касается экспертизы, у нас ребята и с 12 и с 15 годами опыта в devops направлении работают, в этом плане, не жалуемся, кто-кто, а девопсеры у нас мощные.
На голых железках любая СУБД работает быстрее, это правда. Но вот администрация зоопарка (я сейчас не только про Редиску) - это обычно 30-40% времени. Плюс басфактор в виде маленькой команды. Всегда можно вручную и на голом железе, тут я согласен, просто накладные расходы большие.
Это да, но учитите миграцию, и настройку инфры. Мониторинг нужно повесить, ci/cd поправить, а если у вас много данных и разные пайплайны, это точно не пару часов. Ну и я молчу про хайлоад / лоадбалансеры, безопасность. Так или иначе, конечно, можно, но в облаке еще быстрее будет.
Не навязываюсь с решением, но не все за пару часов с нуля могут кластер без ошибок поднять, об этом и статья. Алексей, кстати, в статье, вполне живой человек. Ну и опять же, у нас все PaaS в платформе Evolution поверх k8s, там файловер встроенный.
Конкретно ваш кейс, к сожалению, не знаю. По описанию выглядит так, что вы уперлись в сетевой ресурс группы ресурсов, которые, в свою очередь, упираются в железку. Там есть в группе ресурсов железный ограничитель, который меняется только через кастомную сетевую настройку, и это может повлиять на соседние кластера. Поэтому, в тот момент, возможно, не решили. У нас 3 месяца назад поменялся парк оборудования, поставили leaf маршрутизаторы с высокой пропускной способностью, нарезали группы ресурсов поверх нового парка, теперь проблема решена, но, если решите вернуться, нужно будет отдельно обговорить ваши нагрузки, чтобы на ваш проект отдельные аффинити рулы на уровне виртуализации повесили. Так что да, этой проблемы не будет.
Согласен с вами, но с небольшой оговоркой. Есть отраслевые облака, которые задуманы таковыми на уровне продукта. А есть такие, где принадлежность к отрасли — скорее вопрос упаковки. Поэтому в каждом случае лучше смотреть индивидуально
Да, это было в планах. MySQL освежили, последняя версия - 8.
Maria DB имеет, удивительно, низкие показатели потребления в РФ, по этой причине разрабатывать этот продукт не имеет большого смысла. Готов подискутировать на этот счет.
Да, таких историй слышали достаточно. Да, и что говорить, сам "обжигался", только с AWS, а не с Google Cloud.
Для таких случаев у нас предусмотрены квоты. Вы не можете выйти за рамки используемых ресурсов и тем более уйти в минус баланса, просто потому что у вас всегда есть ограничения по квотам, и вы тратите только то, что реально потребляете. Все стоимости прозрачно видны в момент создания инстанса.
Также, напомню, что всегда можно выключить инстанс, чтобы он не тратил средства ;)
Эх, статья вообще не про SLA, лучше бы про Редис над кубером)
Энивэй, спасибо вам за ваше внимание)
Хехе, ну да, если посмотреть с такой стороны, действительно кейс выглядит забавно))
Там под капотом этой истории, конечно, еще желание руководства сделать бэкенд микросервисным, комплексный рефактор для повышения SLA сервиса, и вообще переезд, в том числе, связан с закупками новых железок и еще много иного контекста. Наверно даже его бы стоило добавить в статейку, для ясности.
Ну что ж, в следующий раз учту.
А по тезисам - база, опыт сын ошибок трудных, 100% согласия.
Спасибо за комментарий, еще раз)
Соглашусь с тезисами, спасибо за них.
Кейс Алексея здесь, конечно, гиперболизирован, просто такой выбран формат повествования, по сути это обычная рабочая рутина, не расскажи я об этом, никто бы особенно не заметил, как и сам Алексей. Такие героические эпосы каждую неделю происходят, просто это мой способ благодарить надежных сотрудников.
Про инфру и 90% поддержки. Ну, тут соглашусь, каждая компания и каждый техлид выбирает свой подход к построению сервисов, чем синьорнее - тем злее. Я здесь пробежался по типичныму кейсу, которые я часто видел. Чем больше энтерпрайз бизнес, тем больше предъявляется требований к масшабируемости, отказоустойчивости, безопасности и управляемости, а-ля cloud native подход. По этой причине у нас такие относительно долгие аналитические процессы по закатыванию фич и сервисов в облако, да и не только у нас.
Хочется по быстрому и, иногда, на коленке, но зачастую так просто нельзя, иначе получается безидейные продукты, которые не будут жить в долгосроке, отсюда и кубер и хелм чарты и прочее. Если у вас не так, ну что ж, значит вам повезло чуть больше :)
Кхм. Серьезно?
Во-первых, этот тред начался с размера компенсации по SLA, вы сами то в эту табличку что ли посмотрите, внимательно, размер выплат зависимости выплат от простоя :)
Во-вторых, вы знаете реальные кейсы выплат, как и сколько и когда возвращают, особенно вот у этих товарищей из таблицы? Я знаю, я в некоторых из них работал. Какие условия возврата средств? Ну вот. В cloud.ru честные.
Во-третьих, это рейтинг c-news. Если вы правда в него верите, ну, что ж, что-то не знаете. Да и просто достаточно посмотреть кто в топах.
В-четвертых, у cloud.ru 3 облака на текущий момент, да, разные облака: Evolution, Advanced, VMWare, и еще ML Space, но это не совсем облако в привычном смысле. Какого облака SLA измерялся? Да, они разные. И я не нашел, если честно, в рейтинге cloud.ru вообще, возможно, мы просто не участвовали, то 2024 года исследование, без учета наших последних модернизаций инфры. Значит в 2025 опять будем в топах, как и во всех остальных рейтингах. Не раз такое было.
В-пятых, вы когда-нибудь слышали про то, что cloud.ru упал? Хотя бы один из облаков? Хотя бы один раз? А если посмотреть в топ-10, как минимум по разу каждое падало. Тогда что вы хотите компенсировать?
Если честно, немного устал от этого треда, вы что-то как-то по-трольски вкидываете, плохо аргументируете, а я трачу на это время. Поэтому, с вашего позволения, предлагаю закончить.
Вы повторяетесь без аргументации и деталей :)
Тезис простой - cloud.ru дает почти лучшие условия на рынке по компенсации SLA за простои.
Все просто: если не так, давайте пруфы, обсудим.
Ну, судя по комментарию, предположу, что вы наш не очень доброжелатель :)
Но это нормально, так бывает)
На самом деле, если капнуть глубже, мы почти единственные кто пишет об этом в открытую, поскольку мы за прозрачность. Если капнете глубже в другие облака, прочитаете договоры, удивитесь, что мы даем хорошие условия. Лучше чем большинство.
Ссылки есть, если поискать, но неправильно с моей стороны их здесь оставлять.
Также парирую ссылкой про SLA 99,95%, это отдельная услуга и другой контур, но инфа валидная.
Ну, я имею ввиду, что редиска используется, например в ecom, где в черную пятницу нагрузка до х20 вырастает. Это хорошо, если у вас он прем стоит и выдерживает стабильно х нагрузку, но когда становится х20, тут либо железо менять, либо как-то горизонтально ресурс масштабировать. Как раз история 2-3 кластера и еще куча нод/реплик. Хорошо, если он поверх кубера, и еще есть возможность отбалансировать. Но даже в этом случае, когда закончится черная пятница - нужно будет обратно скукоживать кластер.
Про порты согласен, не биг дил
Я чего только на редисе не видел. Ладно кэш, но в большинстве POSM-терминалов, например, он стоит как логер действий пользователя. И тут уже не смешно, когда каждые сутки он через AOF пишет на диск результаты, а потом приходит инженер и забирает диск с собой, меняя его, и потом загружая данные в hadoop, откуда потом забирают на анализ.
Кейс как есть, вполне живой, Алексей - реальный человек. Я с вами согласен, но в жизни вы не представляете, как часто вижу похожий кейс. Бизнес тревожится за скорость внедрения, часто задача прилетает специалисту, который в первый раз видит редис, отсюда и редис стейтфул. Да, пальцы в розетку.
Про брокер сообщений, вы говорите как человек, сведующий в опенсорсе. А если у вас большой монолит с уже заданными компонентами, тут не так смешно становится. Такие кейсы я видел, и тонные легаси вокруг тоже.
Давай, жду )
Это вы хорошо понимаете проблему и понимаете, что она легко решается, но когда у вас FQDN за семью печатями и вам нужно получить 4 уровня доступа, чтобы просто получить запись, становится не так смешно)) Не технически, но административно)
Отнюдь, кейс вполне реальный, буквально живой человек с живыми проблемами. Да, конечно, в реальности еще и другие проблемы могут всплывать, и всплывают, но кейс как есть, не больше - не меньше. А что касается экспертизы, у нас ребята и с 12 и с 15 годами опыта в devops направлении работают, в этом плане, не жалуемся, кто-кто, а девопсеры у нас мощные.
Не совсем реклама, конечно, но описание кейса. Спасибо за хороший фидбек)
На голых железках любая СУБД работает быстрее, это правда. Но вот администрация зоопарка (я сейчас не только про Редиску) - это обычно 30-40% времени. Плюс басфактор в виде маленькой команды. Всегда можно вручную и на голом железе, тут я согласен, просто накладные расходы большие.
Это да, но учитите миграцию, и настройку инфры. Мониторинг нужно повесить, ci/cd поправить, а если у вас много данных и разные пайплайны, это точно не пару часов. Ну и я молчу про хайлоад / лоадбалансеры, безопасность. Так или иначе, конечно, можно, но в облаке еще быстрее будет.
Не навязываюсь с решением, но не все за пару часов с нуля могут кластер без ошибок поднять, об этом и статья. Алексей, кстати, в статье, вполне живой человек. Ну и опять же, у нас все PaaS в платформе Evolution поверх k8s, там файловер встроенный.
Конкретно ваш кейс, к сожалению, не знаю. По описанию выглядит так, что вы уперлись в сетевой ресурс группы ресурсов, которые, в свою очередь, упираются в железку. Там есть в группе ресурсов железный ограничитель, который меняется только через кастомную сетевую настройку, и это может повлиять на соседние кластера. Поэтому, в тот момент, возможно, не решили. У нас 3 месяца назад поменялся парк оборудования, поставили leaf маршрутизаторы с высокой пропускной способностью, нарезали группы ресурсов поверх нового парка, теперь проблема решена, но, если решите вернуться, нужно будет отдельно обговорить ваши нагрузки, чтобы на ваш проект отдельные аффинити рулы на уровне виртуализации повесили. Так что да, этой проблемы не будет.
Согласен с вами, но с небольшой оговоркой. Есть отраслевые облака, которые задуманы таковыми на уровне продукта. А есть такие, где принадлежность к отрасли — скорее вопрос упаковки. Поэтому в каждом случае лучше смотреть индивидуально
Кажется, у вас ошибка. У VK CS в терраформе можно деплоить redis, mongo и clickhouse, просто нет примеров деплоя в провайдере именно этих БД.
Да, это было в планах. MySQL освежили, последняя версия - 8.
Maria DB имеет, удивительно, низкие показатели потребления в РФ, по этой причине разрабатывать этот продукт не имеет большого смысла. Готов подискутировать на этот счет.
Да, таких историй слышали достаточно. Да, и что говорить, сам "обжигался", только с AWS, а не с Google Cloud.
Для таких случаев у нас предусмотрены квоты. Вы не можете выйти за рамки используемых ресурсов и тем более уйти в минус баланса, просто потому что у вас всегда есть ограничения по квотам, и вы тратите только то, что реально потребляете. Все стоимости прозрачно видны в момент создания инстанса.
Также, напомню, что всегда можно выключить инстанс, чтобы он не тратил средства ;)