Сервисы Albert Khabibrakhimov
8 313

«Яндекс» объяснил ошибкой удаление виртуальных машин части пользователей «Облака»

Это первый крупный сбой в работе сервиса с момента его запуска.

В закладки

«Яндекс» по ошибке удалил данные с виртуальных машин некоторых пользователей платформы «Яндекс.Облако». Пользователи рассказали об инциденте на «Пикабу» и «Хабре», представитель «Яндекса» подтвердил vc.ru случившееся.

16 мая «Яндекс» проводил плановые технические работы по остановке и удалению виртуальных машин пользователей, которые не оплатили использование сервиса или нарушили правила. Удаление виртуальных машин началось в 16:35 Мск, но было остановлено в срочном порядке в 16:51, когда специалисты заметили, что в загруженный список попали активные виртуальные машины, объяснил представитель «Яндекса».

В результате инцидента были удалены 0,77% от общего числа виртуальных машин и boot-дисков. При этом были затронуты виртуальные машины только в зоне ru-central1-c. Дополнительно созданные диски остались в сохранности. Пользователи, у кого были сделаны снимки дисков, смогли восстановить свои данные.

Мы хотим принести извинения каждому, кого затронул технический сбой в работе «Облака». На данный момент наша техническая поддержка работает в формате «горячей линии» и мы оперативно помогаем всем. В качестве компенсации всем будут начислены гранты, о размере и порядке получения которых мы сообщим дополнительно не позднее начала следующей недели.

пресс-служба «Яндекса»

Абсолютное число пострадавших пользователей, как и размер всей аудитории «Облака», представитель «Яндекса» не раскрывает. Он добавил, что компания работает над мерами, которые позволят избежать подобных ошибок в будущем.

«Яндекс» запустил облачную платформу для бизнеса «Облако» в сентябре 2018 года. Это первый серьёзный инцидент в его истории, отмечает «Хабр».

#новость #яндекс

{ "author_name": "Albert Khabibrakhimov", "author_type": "editor", "tags": ["\u044f\u043d\u0434\u0435\u043a\u0441","\u043d\u043e\u0432\u043e\u0441\u0442\u044c","\u043d\u043e\u0432\u043e\u0441\u0442\u0438"], "comments": 68, "likes": 38, "favorites": 11, "is_advertisement": false, "subsite_label": "services", "id": 67801, "is_wide": false, "is_ugc": false, "date": "Fri, 17 May 2019 18:37:12 +0300" }
{ "id": 67801, "author_id": 53259, "diff_limit": 1000, "urls": {"diff":"\/comments\/67801\/get","add":"\/comments\/67801\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/67801"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 200396, "last_count_and_date": null }

68 комментариев 68 комм.

Популярные

По порядку

Написать комментарий...
3

Оч к месту)))

Ответить
1

«Яндекс» проводил плановые технические работы по остановке и удалению виртуальных машин пользователей

Ответить
2

Админ яндекса за работой:

Ответить

Комментарий удален

39

Это первый крупный сбой в работе сервиса с момента его запуска.

звучит как "то-ли еще будет!"

Ответить
8

С почином! 🍺 (эмодзи с кружкой пива)

Ответить
1

Начало положено

Ответить
0

Начало положено Яндекс.Диском

Ответить
20

А если не успел обновить цену на Маркете - забанят и никаких извинений не примут 🤷‍♂️

Ответить
12

Не, ну а чо - сисадмины делятся на тех, кто делает резервные копии и на тех, кто их не делает. А еще есть гуру, которые проверяют состояние копий. ;)

Короче. Перед запуском любого проекта, офиса, сайта и так далее, нужно ответить себе на один вопрос - какой уровень отказоустойчивости вам необходим.
Копируете на тот же диск? Полетел диск
Копируете на тот же сервер? Сервер может сгореть или маски-шоу
Копируете на соседний сервер? Маски-шоу или пожар в серверной
Копируете в серверную на другом этаже? Пожар, теракт
И только копирование в другой дц, в другие дц, в других странах обеспечат тотальный уровень защиты данных.

Лично я делаю так - копирую самое важное на этот же сервак, на медленные большие диски. Копия всего тома создается на сервере бекапов. И периодически сервер бекапов сливает в удаленное хранилище.

Чем там занимается яндекс, что у них даже вчерашних копий нет? Что это - издержки экономии на дисках или банальная безалаберность и вера в железо?

Ответить
5

сисадмины делятся на тех, кто делает резервные копии и на тех, кто их не делает

Я кстати думал что в Яндексе виртуалтные машины бекапятся по умолчанию. В ажуре к примеру 2 копии делается by design

Ответить
0

Они "бэкапятся" в двух логиках, двумя разными сторонами процесса.

Одно дело когда, как Александр выше — сам сисадмин бэкапит свои данные, пусть даже на том же самом Облаке, рядышком. Это от ошибок самого сисадмина. Но есть и другой бэкап, который он не видит, это бэкап самого Облака, от ошибок админов Облака, от посыпавших или ушедши на плановую замену дисков… На эту устойчивость, высокого уровня, админ, покупающий услуги, никак не влияет.

Ответить
2

Но-но, я попрошу. Не надо додумывать, что делаю я.

Бекапить данные облака в само же облако - это глупость. Если не подключено к облаку еще для бекапов нечто, то варианты
1. самый ламерский - заархивируй и положи к себе на комп
2. по крону простеньким скриптиком можно утягивать в другие облака и прочие хранилища. И даже на почту - часто просто бывает, что ценного буквально на 1 мегабайт, конфиги, например. Или база.

Но самое главное, что делаю я - не пользуюсь облаками :) Все, что у меня облачного - это впски по 2 бакса штучек десять под всякие тесты и хулиганства.

А так висят серваки на колокейшен в разных дц, друг в друга бекапят и нормально. В 1U очень много можно напихать, а стоимость размещения 1U около 3т.р. в месяц.

Очень, знаете ли, люблю и уважаю услугу колокейшн. Серваки все мои (или клиентов), размещение такой мощи дешево обходится. Да, на старте надо вложиться, но это все окупается за пару лет.

п.с. вот написал и подумал - иначе ведь написал. внесу ясность - раньше я был сисадмином, а теперь вебмастер типа - ну, вебстудия своя и клиенты есть крупные, что на моих серваках висят.
поэтому стратегия резервного копирования для сисадмина и для вебмастера немного отличны.
у вебмастера негде взять сервак чисто под резервные копии, уж больно жирно получится. зато сайты не терабайты весят, как обменники юзеров и промышленные базы у сисадмина

Ответить
0

В теории - сервис должен обладать определённой устойчивостью, что достигается резервированием. Сервер приложения - кластер. Перед ним - балансировщик. Хранилище - кластер. Перед ним - балансировщик. Элементы кластеров (vm) должны подниматься по шаблону. Такой резерв может работать в рамках одной зоны (не очень надежно) или пары-тройки зон (оч хорошо). И бекапы тут - горячие, переключение на другого мастера в кластере должно быть автоматом. Поднятие нового элемента кластера вместо упавшего - автоматом.

А вот бэкапы - они в таком конфиге нужны только внешние, для надёжности.

Ответить
0

Вот я и удивлен что бэкап облака не справился со своей функцией. Видимо эти копии удалились вместе с основной vm

Ответить
2

Стратегия копий - она ж логична: быстрая полная и самая актуальная копия - поближе к оригиналу. Регулярная - недалёко. И совсем резервная - далеко.

Только резервирование создаёт надежность. Любители ещё несколько способов копирования применяют. Типа - вот дамп БД, а ещё мы регулярно снэпшот контейнера снимаем с остановленной субд.

Ответить
0

Да. Если ресурсы есть. И, если мы резервные копии уже создаем.
Все верно написано, не добавить, не прибавить.

Ответить
0

Там копии дисков ответственность пользователей. За что платишь то и будет.

Ответить
1

Да знаю я такую схему. За резервное хранилище еще и доплати. А потом все нахрен рухнет вместе с резервным хранилищем. ;)

Вместе с этим, есть нормальные хостеры, у которых услуга впс включает резервное копирование, хотя бы 1 снепшотик вручную.

Но. По-хорошему, надо бекапить данные с облака куда-то еще.
Мне бы лично было очень неспокойно, не забекапившись-то.

Ответить
9

Яндекс, сука, суров. Могли бы просто пока приостановить VM на недельку, а потом спокойно удалить. Кто ими пользуется - не завидую, даже за бесплатно такого не надо.

Ответить
1

Вот именно так сейчас и собираются делать - установить такой принципе как правило.

Ответить
0

Почему только сейчас-то? Раньше что мешало? Админ, который к людям не очень?

Ответить
1

Все мы крепки задним умом!

Ответить
0

Погубят Яндекс такие кадры с задним умом..

Ответить
0

Вряд ли украсят, конечно, но кто не без греха - покажите идеальных! Думаю, не стоит драматизировать

Ответить
1

Не припомню такого фэйла у GCP/AWS. Может кадры с задним умом у них тоже есть, только им не дают принимать такие важные решения, как удаление VM.

Ответить
0

Вы действительно не понимаете разницы между намеренным удалением VM Яндексом "0,77% от общего числа виртуальных машин и boot-дисков" и разовым сбоем в AWS из-за ошибок в конфигах провайдера?

Ответить
0

Да. У яндекса был неправильный конфиг фильтра на удаление машин. Обычный факап. Даже если была бы политика недельного отстоя vm перед удалением, баг в отборе машин на удаление привёл бы к такому же результату.

Не вижу ничего гипер-трагичного. Их не взломали, данные не украли. Данные в облаке обычно дублируют с целью увеличения скорости обработки (кластера хранилища, например) и резервируют в другой ДЦ как минимум. Пожар/затопление в датацентре никто не отменял

Ответить
0

Ну если Вы хотите кушать кактус - пользуйтесь Яндексом. Мне это видится не очень разумным вариантом, пока есть GCP и AWS.

Ответить
0

Подумать и проверить раз это пять-семь перед запуском скрипта — быть идеальным? Да если на то пошло, с их ебанутыми интервью они там должны быть мега супер идеальными.

Ответить
2

С их ебанутыми интервью не обязательно быть суперидеальными. Возможно, кроме ебанутости там ничего и нет.

Ответить
5

Молодцы, признали вину, извинились и пытаются компенсировать. В отличие от других хостеров, которые замалчивают и пытаются все свалить в первую очередь и сделать виноватыми клиентов.

Ответить
10

Единственная возможная компенсация - сделать как было до. Если не восстановлено - это не компенсация. Каким образом - это уже их проблемы.

Ответить
3

Ничего они не компенсируют. Кому эти гранты сдались, когда у тебя простой в сутки, уходят тысячи пользователей, в сторе /маркете волна негативных отзывов. Даже если вернут как было - это не полная компенсация.

Ответить
0

Пожалуй - сепукку от их ответственного инженера ждать не стоит. Они конечно косячнули, тих вина, но ...

Но ваша инфраструктура таки подвержена сбою. Видимо, есть определённые архитектурные недочеты: возможно, недостаточно используете облако как облако: нет полноценного резервирования, раз у вас простой был. Умершие vm должны были быть восстановлены и нагрузка перераспределена. В теории, смерть vm - плановое событие.

Ответить
–1

У меня реально вопрос назревает уже последние пару лет, как здравомыслящий человек, может пользоваться сервисами яндекса? это же боль сплошная

Ответить
5

Что не так с сервисами Яндекса? Обычные сервисы. Факапы у всех случаются

Ответить
0

Стараюсь по возможности не по льзоваться сервисами Яндекса, и при этом постоянно имею проблемы с ними. И хоть у Яндекса факапов больше чем у других, дело не в их количестве, а в отношении к пользователям. И тут Яндекс обсирается почти непрерывно

Ответить
0

Звучит немного голословно и тенденциозно. Особенно насчёт - факапов больше чем у других.

И в моей практике яндекс всегда выдавал плюшки после факапов. А как ещё компенсировать? Кмк, норм

Ответить
0

Буквально на днях накосячил Беру, в письме извинились, обещали через сутки прислать код на скидку 500 р, хотя эта скидка у меня итак была. Через сутки не прислали, сказали что на решение вопроса понадобится немного больше времени... То есть все извинения фактически только словесные.
Иду покупать тот же товар на озоне

Ответить
1

Так они же стоЯт на FreeBDSM )

Ответить
6

помню, они с яндекс-диском похожее выдали, потерев народу файлы, а потом извинившись на 256 гигов.

Ответить
0

Я один из этих «счастливчиков».

Ответить
0

И как? Скомпенсировали - на ваше мнение?

Ответить
4

Лично я более чем доволен.

Ответить
0

Да, с лихвой, как и Тимуру, но у меня были резервные копии отдельных данных на ПК не в папке Диска. Думаю, что были люди, которые с концами потеряли что-то важное. Ну и было забавно наблюдать, как Диск, синхронизируя данные, трёт их на ПК. :-)

Есть разные облачные диски, но от Яндекса больше всего нравится, активно им пользуюсь.

Ответить
0

Ну и было забавно наблюдать, как Диск, синхронизируя данные, трёт их на ПК. :-)

Интересно, как в других сервисах этот момент проработан. iCloud, GDrive. Не хотелось бы проебать терабайт данных (пусть и не очень критичных)

Ответить
0

Видя надпись "навсегда" хочется вставить мем из войны бесконечности.

Ответить
0

у меня не потерлось ничего, но компенсировали тк юзал ту версию клиента бажного, доволен

Ответить
0

У меня такое было, сносило .exe. Винда рухнула, переставил - получил 200 гб навсегда.

Ответить
3

Не зря мой вебадмин отговаривал пока от Я.Облака. Предупреждал, как там на ходу всё постоянно допиливается и глючит :( Сырой продукт выкатили ребята.

Ответить
6

Любое правильное облако - штука наживная! Образ vm восстанавливается по шаблону, кластер собирается заново, бэкапы поднимаются из соседней зоны или внешнего сервера. Поэтому подобные сбои - не должны быть фатальными.

Просто облако - это все равно с определенного масштаба бизнеса надо, кмк.

Ответить
0

Вот как наживут, так и часть проекта улетит на их облако.

Ответить
1

Конечно, фейл яндекса неприятный. Явный баг

Ответить
3

Любое облако не дает гарантий, у всех были факапы — AWS, GCP, Azure...

Ответить
0

Вот я и жду их выход из детского возраста )

Ответить
1

Была пятница, рабочая неделя подходила к концу...

Ответить
14

и трансляция из офиса яндекса подоспела https://www.youtube.com/watch?v=SOuhTLeyVCE&feature=youtu.be

Ответить
4

Гранты... Мне предложили вернуть сумму одного месяца (около 7,000 руб) за потерянные данные и информацию, которая стоит в сотни раз больше. Спасибо, Яндекс, но до свидания. Позор просто.

Ответить
2

Бакапы не делали?

Ответить
0

700 000 , мелочь, нах бэкаы

Ответить
2

Как же хорошо жить в своём внутреннем мирке и не переживать за чужие проблемы…

Ответить
1

Как минимум могли бы просто отключить на месяц, прежде чем удалить. С чем связано такое торопливость?

Ответить

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

0

с каких пор обычный хостинг вдруг стали называть "Облаками" ? Облако это когда твои данные лежат одновременно на over100500 серверах и удаление / падение одного сервера ни приводит ни к каким сбоям именно отсюда и название "облако"

А тут какая-то шляпа, удалили "из облака" это как вообще?

Ответить
1

Это именно что облако. Для клиентов сервисы, которые созданы в такой инфраструктуре - будут надежными - но только если правильно созданы, с обеспечением этой надёжности в инфраструктуре. А яндекс потёр одни элементы инфраструктуры - виртуальные машинки. У кого архитектура была правильная, сами восстановились от сбоя. Но такой подход к надёжности - это не так просто и дёшево.

Ответить
0

Вот админу, конечно, досталось. Зато будет, что вспомнить, рассказать из своей насыщенной приключениями айтишной жизни.

Фейл, конечно, феерический, выполнять операции удаления без тестирования и резервных копий на проде. Прям высший пилотаж.

Ответить
0

Я плачу за возможность делать бэкапы?

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Нейронная сеть научилась читать стихи
голосом Пастернака и смотреть в окно на осень
Подписаться на push-уведомления
{ "page_type": "default" }