Яндекс объяснил происшествие на Яндекс.Облаке. Сервис Яндекс.облако был запущен в 2018 году. Это первый серьезный инцидент в его истории, но не первый в истории всей компании, напомнил Хабр.
16 мая были запланированы регулярные технические работы по остановке и удалению виртуальных машин в заблокированных облаках пользователей по причине неоплаты или нарушения правил использования сервисов Яндекс.Облака. Это стандартная процедура по высвобождению ресурсов Облака.
В 16:35 (MSK) была запущена команда по удалению виртуальных машин согласно сформированному списку. В 16:51 была обнаружена ошибка и в 16:56 выполнение команды было остановлено в срочном порядке. Выяснилось, что при формировании был применен неверный принцип фильтрации, вследствие чего в список попали активные виртуальные машины. Сейчас мы в процессе расследования ситуации и выяснения деталей.
В результате инцидента были удалены 0,77% от общего числа виртуальных машин и boot-дисков. При этом были затронуты виртуальные машины только в зоне ru-central1-c. Дополнительно созданные диски остались в сохранности. Пользователи, у кого были сделаны снимки дисков, смогли восстановить свои данные.
Мы не считаем это рядовой ситуацией, для нас каждый пользователь важен, и мы осознаем свою полную ответственность за надежность нашей платформы. Мы уже работаем над формированием мер для предотвращения повторения подобного инцидента в будущем и в ближайшее время проинформируем о дальнейших шагах всех пользователей.
Мы хотим принести извинения каждому, кого затронул технический сбой в работе Облака. На данный момент наша техническая поддержка работает в формате «горячей линии» и мы оперативно помогаем всем. В качестве компенсации всем будут начислены гранты, о размере и порядке получения которых мы сообщим дополнительно не позднее начала следующей недели.
Добавить 14 комментариев
Политика конфиденциальности. Дата публикации: 26 марта 2019
Текущая версия доступна по адресу: https://yandex.ru/legal/confidential/
¯\_(ツ)_/¯
Удалять неоплачиваемые машины — это нормально. Не очень нормальна ситуация (мягко говоря), когда список подлежащих расстрелу формирует криворукий админ на коленке, при этом приводя приговор в исполнение сразу же в продакшн, не протестировав процедуру в тестовой среде.
Похоже, скопировать у Амазона получилось не совсем «всё».
Почему никто не обсуждает КАК это произошло? А вы попробуйте подумать.
И неожиданно выясняется, что Яндекс — это компания уровня «хуяк-хуяк и в продакшн» и «мы правим сразу же на проде» и все остальное в эту сторону. Т.е. проблема совершенно не в том «человеческом факторе» какого-то там операционного инженера-админа, который написал кривой SQL-запрос или grep-фильтр (неважно там что), получив список систем не с последним (текущим статусом) SUSPENDED, а тех, у которых он когда-либо был вообще.
Любой человек совершает ошибки. Вопрос в том, как организован труд человека, чтобы эти ошибки были если не исключены, то минимизированы. Т.е. процесс работы и систематизация.
Вопрос в том, что:
— операция, которая является базовой, не написана в коде, не протестирована тщательно (не тем, кто пишет, конечно же), не зафиксирована (т.е. человек должен либо вызвать одну команду, которая делает это, либо просто нажать одну кнопочку) [отмазы про тестирование — классика Яндекса, в этот раз наверно кто-то еще заболел и они торопились]
— операции массового характера и особенно удаления не имеют степеней защиты (типа той же временной пометки на удаление и удаление лишь позже)
— операции массового характера и особенно удаления не подлежат контролью по принципу 4-х, 6-и и проч. глаз (как применяется в банковской и других сферах)
Вы понимаете, что фактически Яндекс.Облако расписалось в том, что они — это шараж-монтаж? Этот инцидент ВСЕЦЕЛО показывает ОРГАНИЗАЦИОННЫЙ подход.
Вдумайтесь только. Какой-то условный админ (операционный инженер) может написать кривой запрос — и его результатом воспользуются. А вообще, фактически есть лицо (и, полагаю, далеко не одно), которое может (будучи мстительным, пьяным, со съехавшей крышей или еще по каким причинам, за бабло) — грохнуть вообще все у всех.
Собственно, описал тут.
Но зато Яндекс делает запреты на SSJ100. Не нужно ли сделать запреты на Яндекс.Облако, Яндекс.Почту (потеря данных) или Яндекс.Такси (при куче ДТП)?
Я бы не стал делать далеко идущие выводы о какой-то особенно неверной организации труда в Яндексе. С AWS гуглится сходная история:
https://www.businessinsider.com/amazon-lost-data-2011-4
Детальных объяснений от AWS не нашёл в статье, но они ссылаются на сбой железа. Похоже на то, что банально не было дублирования дисков с данными на разных машинах. И это лидер рынка, и это потеря данных, и это уже на 5ом году его существования.
Объяснений вы не нашли, но далеко идущие выводы сделали. Официальный репорт от AWS гуглится за секунду: https://aws.amazon.com/message/65648/
В любом случае, показательно, что коллеги из мэйлру также не чувствуют разницу между непредвиденным сбоем и банальной халатностью.
>коллеги из мэйлру также не чувствуют разницу между непредвиденным сбоем и банальной халатностью.
Если вы лояльны бренду, будете верить в «непредвиденный сбой», если нет, то в халатность.
Практической разницы нет, «непредвиденный сбой» возможен благодаря чей-то халатности.
Робинзон,
Спасибо за ссылку! Прочитал. Сбой был не в железе.
Про железо я взял из этой цитаты Амазона
The hardware failed in such a way that we could not forensically restore the data.
Про диски сделал далее предположение, а не вывод.
Наверняка, вы сами читали вашу ссылку. Там написано, что проблема была вызвана ручным изменением конфигурации сетевого оборудования, сделанным с ошибкой. В чем принципиальное отличие от запуска скрипта руками сотрудником Яндекса?
Вот конкретно про ручное действие: » The configuration change was to upgrade the capacity of the primary network. During the change, one of the standard steps is to shift traffic off of one of the redundant routers in the primary EBS network to allow the upgrade to happen. The traffic shift was executed incorrectly and rather than routing the traffic to the other router on the primary network, the traffic was routed onto the lower capacity redundant EBS network»
Удивительно, что вы в mail.ru работаете с такими комментариями. Не опасаетесь? Потому что сошлюсь еще раз на свой комментарий.
Вы понимаете, что выполнялась базовая операция: поиск и удаление неоплаченных систем. Так вот ее выполнение производилось, очевидно из случившегося, вручную. Некий человек, которому это поручили, выполнил некий написанный скрипт (неважно, SQL-запрос, grep-команду или еще что), отфильтровав системы по нужному ему признаку (с кривым кодом запроса), и подал этот список на удаление.
Базовая операция по поиску и удалению неоплаченных систем должна быть:
— написана в коде (как функция)
— протестирована (не разработчиком)
— иметь либо API для вызова, либо интерфейс
— (в идеале) запускаться самостоятельно/автоматически по расписанию
— любые иные пожелания
Последние три пункта значения не имеют. А вот первые два говорят об очень многом именно в организации проекта Яндекс.Облака. Что там внутри с процессами. И разница между тем, что транслируется вовне (профессионализм, все дела) и тем, что есть на практике (наколенный шараш-монтаж с «правим на проде» (здесь это не буквально, а аналогия)).
И если в mail.ru у людей мнение типа «а что, нормально, что такого, все так делают [, мы так делаем]«, то у меня печальные новости для mail.ru и их пользователей тоже.
И да, все так не делают. Вот именно так делают непрофессионалы.
Самое главное, защищать такой вне-процессовый подход — это прежде всего непрофессионально.
Менять сетевую конфигурацию вручную — нормально. Удаление неиспользуемых машин должно быть систематезировано, автоматизировано и с возможностью откатить назад.
*систематизировано
Проблема возможно связана с последними уязвимостями в процессорах интел, если йандекс не обновил вовремя микрокод на всех процессорах облака, из любой виртуальной машины в облаке злономеренный пользователь мог получить доступ к коду и данным других виртуальных машин и (или) удалить их. Сейчас виртуалки «трещат» по всему миру :)
ps.
Лирика: Тяга покрыть всё юнит тестами понятна, вроде что то делаешь и зпэшка капает, а вроде и делать ничего не надо. Вместо юнит тестов и организации процессов в ораганизации процессов для организации процессов, можно любителям подобного рукоблудия выделять вменяемый доход, в реале подобные граждане вполне профессионально утилизируются в чопах и гвардиях и различных госструктурах.
По этой проблеме: обновление микрокода снижает производительность чуть ли не на 40 процентов. Это первая серьёзная атака на любителей виртуалочек :) учитывая некоторые малоизвестные широкой публике факты :) я могу предположить, что не последняя :) дело в том, что сейчас процессор, не освобождает физически память при её высбождении из процесса и при чтении мусора из памяти другими процессами в процессоре :) они читают не мусор, а чужие данные, для того чтобы прекратить это безобразие необходимо внести изменение в процесс высбождения памяти это возможно нормально сделать только изменив спецификации самих микросхем, логично именно там стирать память, а не перезаписывать её нулями из процессора или другой переферии, это можно сделать на уровне организации JEDEC, регулирующей стандраты различных DRAM, но всё это равносильно тектоническому сдвигу в отрасли.