Пользователи сообщили о сбое в сервисах «Яндекс.Еда» и Delivery Club Статьи редакции
Обе компании справились со сбоями за вечер.
Вечером 14 февраля 2020 года пользователи сообщили о проблемах с загрузкой приложений «Яндекс.Еда» и Delivery Club. Об этом они написали в Twitter.
На сайте Delivery Club также написано о проблемах в работе сервиса. Сайт «Яндекс.Еды» открывается, но при попытке оформить заказ возникает ошибка.
В «Яндексе» подтвердили vc.ru, что у некоторых пользователей возникали кратковременные трудности с доступом к «Яндекс.Еде», но сейчас сервис работает в штатном режиме.
«Некоторые пользователи сейчас могут столкнуться со сложностями при входе в приложение на фоне аномально высокого спроса, мы занимаемся решением этой проблемы. С операционной точки зрения сервис работает в штатном режиме», — сообщили в Delivery Club.
Обновлено в 21:20. В Delivery Club сообщили vc.ru об устранении сбоя. Компания выплатит компенсацию курьерам, которым пришлось ждать новые заказы, и примет меры, чтобы всплески спроса не влияли на работу сервиса в будущем.
Яндекс и Mail.ru: "ребята, бросайте свои выделенные сервера, переходите на наши облачные платформы, они мгновенно масштабируются под любую нагрузку, резервируются и никогда не упадут!"
Яндекс и Mail.ru: *падают, когда чуть больше чем обычно влюбленных парочек решают заказать похавать.
А вообще наверное Яндекс с Mail.ru в день Святого Валентина просто решили отключиться от всего мира и побыть вдвоём...
Вы путаете тёплое с мягким. Облака созданы для более плотной утилизации ресурсов. Само облако не знает что внутри него запущено. Система оркестрации может выполнять простые сценарии по разворачиванию инстансов. Динамическое выделение ресурсов практически никто не использует, тк держать пару тысяч серверов прозапас дорого как в плане покупки, так и обслуживания. Условно говоря если сервис обычно имеет 3х запас и это окупает железо, то уже 5х на случай такого выброса может увести сервис глубоко в минус.
Кмк, более плотная утилизация ресурсов - это ближе к контейнерам и прочим микросервисам.
А вот облако без масштабирования под нагрузкой - уже не облако.
К слову, думаю, в Яндексе недооценили пик спроса и настройки масштабирования недокрутили. Но это спекулятивная гипотеза. Интересно будет услышать разбор от самой компании
Кмк, более плотная утилизация ресурсов - это ближе к контейнерам и прочим микросервисам.
Почему же? Контейнеризация имеет ограничение по версии ядра. Плюс полная виртуализация, например, позволяет использовать bbr без включения оного на хостовой машине.
А вот облако без масштабирования под нагрузкой - уже не облако.
Под какой нагрузкой и как облако должно масштабироваться? Вот кончилась у вас сеть, что должно делать облако?
Если упала одна зона вся - балансировщик должен поднимать инстансы в других зонах. Безусловно, репликация базы тоже должна работать
В какой зоне? Построить за 5 минут в другом регионе еще один ДЦ? Яндекс нагрузку пускает в ближайший для пользователя ДЦ, они об этом говорили на конференциях. Если складывается один, то нагрузка просто уходит в другой. У Яндекса YDB, которые они открыли наружу, он изначально геораспределенный.
Облако Яндекса работает в трёх датацентрах (пока)
А почему вы считаете, что динамическое управление ресурсами никто не использует ? И на других проектах видел, и у себя используем scale up и scale out весьма активно, тк это не означает держать про запас (это же не дэдики), а за предоставление инфраструктуры отвечает PaaS-провайдер. И платится не за то, сколько может быть использовано, а за фактическое использование.
А почему вы считаете, что динамическое управление ресурсами никто не использует ?
Используют, но либо мелкие стартапы, либо что-то внутреннее очень специфичное.
И на других проектах видел, и у себя используем scale up и scale out весьма активно, тк это не означает держать про запас (это же не дэдики), а за предоставление инфраструктуры отвечает PaaS-провайдер. И платится не за то, сколько может быть использовано, а за фактическое использование.
Это вы платите сколько использовали, а оператор в эти услуги уже заложил стоимость простаивающего железа. Яндекс сам покупает и сам обслуживает железо. Ему некуда сходить и попросить ещё тысячу серверов.
Ну и опять же, вот вы используете и что? У вас там ещё один под аллоцируется и все ваши потребности закрыты. У вас же нет распределённого общего стораджа под данные, нет всяких балансировок хитрых на L3/L7 чтобы уводить нагрузку в другие ДЦ. Больше инстансов - больше нагрузка на мониторинг, надо ещё и мониторинг покрыть ресурсами. В общем все что может работать на мелких сервисах далеко не факт что будет работать на больших.
Но я же не говорил, что у нас мелкий сервис :) Документооборот бухгалтерский на 3 скандинавские страны у крупного игрока рынка.
Отлично, только население всех скандинавских стран около 20 млн человек. Это всего лишь Москва и Московская область или Москва и Питер, а у Еды 31 город без Питера и Москвы, из которых 16 миллионники. Ну и документооборотом пользуется далеко не все население, Едой пользуется гораздо больше людей.
Вы мне хотите до сих с пеной у рта доказывать, что скейлинг только для проектов в сотни миллионов пользователей ?)) Так вот это чушь. Скейлинг применим везде, где есть существенная разница в моменты пиковой нагрузки, когда есть возможность вне пиковой нагрузки не платить за ресурсы. Если работа сотрудника, который занимается DevOps, меньше, чем срезаемые на проекте косты за счёт скейлинга (читай как затраченная работа не превышает по стоимости выгоду), то в этом всегда есть смысл. Я не говорю уже про ремутационные риски. Проекты по размеру меньше яндексовских в первую очередь должны думать об отказоустойчивости, тк просто не выживут, если лягут в критичный момент. А с Яндексом не надо говорить, что они типа сами у себя не могли взять ресурсов. Во-первый, еда и датацентры у них разные бизнесы и не так, что пришел и бесплатно юзай. Это нормально, если Еда платит Облаку за услуги, просто по себестоимости. А значит в Еде не предусмотрели нагрузку. А если не хватает ресурсов, то ничего зазорного, если Яндекс часть нагрузки вынесет на сторонние цоды. Или халатность, или глупая корпоративная гордость.
Я говорю, что то, что работает быть может у вас, не работает на крупных проектах. У нас только мониторинг потребляет порядка 3800 ядер. Если вдруг к нам придёт ddos или настоящие пользователи в размере больше, чем 4x, то нужно будет на каждый добавленный под добавить ещё 20 ядер в мониторинг. Дальше доставка логов, на каждый под нужно будет по два ядра только, чтобы отправлять, но ещё и с принимающей стороны тоже растить. Ещё новые поды нужно будет аллоцировать только на тех машинах, где сеть а) без переподписки б) есть полоса без уже промаркированного трафика итд итп. И это мы пока не храним стейт и не используем БД пока. А еще может случиться так, что в локацию пришёл клиент и вдруг Еда легла, кому в такой ситуации дать ресурсы?
Именно потому, что запасов по ресурсам нужного много и сам процесс масштабирования очень сложный, является ещё одной точкой отказа. Люди держат большой запас на балансерах, а дальше сэмплируют запросы и пускают только какой-то процент, который могут переварить. Ровно это и произошло, Еда была недоступна только у части пользователей.
Короче Яндекс не может попросить включить Яндекс ещё виртуалок, всё ясно
Особенно в день всех влюбленных, просто экология плохая да и неделя тяжелая, стресс
Не понял, как это с "менеджерского перевеcти", дженерик Виагры локальной сборки?
Если у вас есть что то маленькое, попробуйте это увеличить, если получится, вуаля вы сделали масштабирование.
"Если у вас есть что то маленькое, попробуйте это увеличить,"
А понял, чуть чуть ошибся в определении , но все равно это "хуевая" тема.
Ну так заставило думаю некоторых выйти на улицу и поесть где то в кафе, чем сидеть дома :)
Нехер сидеть дома и откармливать задницу холодным джанк-фудом, разработчиков f2p игр и продюссеров сериалов, сегодня тяпница, идите жрать, пить и общаться в реал.
Смотря какая книжка, если такая, как Исинбаева первый раз в жизни недавно прочитала, тогда можно. Потому что, это «очень важная книга и читать ее нужно всем», даже олимпийская чемпионка «узнала очень много интересного».
Ну все, сейчас мы узнаём какие доставки есть кроме Яндекс.Еда и Деливери клаб
В Ярославле полегли додо, местная популярная пиццерия, суши из суши.лав не привезли. Хорошо такси не отвалилось, сами поработали себе курьерами.
Деньги сняли, заказ не доставили. Будем есть пельмени в романтической атмосфере, класс)
"С операционной точки зрения сервис работает в штатном режиме". Delivery Club, это по-вашему штатный режим?
Это потому что архитектура сайта получше чем у Яндекс и устойчивее к нагрузкам или сервис не особо кому нужен? :)))
В Краснодаре моя любовь - это приложение Антей, ужин я уже заказала, так что мне бояться нечего, не благодарите:)
В Казахстане опять заблокировали телеграм, еще об этом напишите пожалуйста!
У мужчин 3 праздника: 14 февраля у них есть шанс поздравить любимых, потом 23 февраля их самих поздравят, а потом снова 8 марта есть шанс поздравить милых дам!
Комментарий удален
Интересно как справлялись сами кафе и рестораны с заказами, если Деливери и Яндекс пали? Или это от них и была просьба «горшочек не Вари»)
Преимущество уметь готовить самому, не зависеть от приложений. 😁
ладно.., в ресторан для романтики можно и пешком ребята., ну на крайний случай такси 😂
Как мне самому за полчаса свободного времени накрутить сет на 10 видов суши и роллов?
Или может купить нормальную печь для пиццы?
И мангал на балконе для шашлычка?
Блоги компаний
Комментарии