Сбой Yandex Cloud в 2026 году: что делать владельцу сайта
- С 8 по 11 октября 2026 года атаки беспилотников повредили три дата-центра Яндекса. Дата-центры в Сасово и Владимире остановлены полностью, из четырёх зон облака перестали работать ru-central1-b и ru-central1-a, и Yandex Cloud объявил режим работы платформы аварийным.
- Сайты лежали днями: ресурсы в одной зоне сами не переезжают, часть кластеров баз осталась без кворума, а с 11 октября облако приостановило выдачу квот. Простой сайт из копии у другого провайдера поднимают за часы, а сложному проекту без заранее собранной площадки нужно несколько дней, и это нормально.
- Проверить у себя: в скольких зонах работает сайт, есть ли проверенная копия у другого провайдера, за какой срок сайт можно поднять заново, где обслуживается DNS домена.
- Копии с персональными данными россиян переносят только к провайдеру с базами в России: часть 5 статьи 18 152-ФЗ запрещает хранить их в базах за рубежом.
- Компании без своей команды эксплуатации нужен подрядчик, который знает проект и переносит сайт по действующему договору, без новой сметы: схема, доступы и место у второго провайдера у него готовы заранее.
Что случилось в дата-центрах Яндекса 8–11 октября, почему сайты восстанавливались днями, как проверить зоны, копии, DNS и 152-ФЗ и как подрядчик ведёт переезд.
Антон Тарасенко, сооснователь и CEO NerdSquad. Обновлено 23 октября 2026 года.
Сбой Yandex Cloud 8–11 октября 2026 года показал, что одной облачной площадки сайту мало. Если сайт работает в облаке Яндекса или другом облаке, проверьте сейчас, в скольких зонах он запущен, есть ли проверенная копия у второго провайдера и кто её поднимет. Без этого авария в облаке Яндекса превращается для бизнеса в простой на дни.
Что случилось с Yandex Cloud в октябре 2026 года?
С 8 по 11 октября атаки беспилотников повредили три дата-центра Яндекса: в Сасово, Калуге и Владимире (заявление Яндекса). На двух из них работали зоны доступности облака: ru-central1-b в Сасово, а одновременно с остановкой Владимира облако сообщило об отказе питания в зоне ru-central1-a. Из четырёх зон облака (a, b, d, e) остались две. Yandex Cloud написал клиентам: «Оставшуюся конфигурацию ресурсов считаем неустойчивой. Режим работы платформы является аварийным» (карточки инцидентов на статус-странице Yandex Cloud, канал Yandex Cloud Alerts).
| Дата | Что произошло |
|---|---|
| ночь на 8 октября | дата-центр в Сасово повреждён и остановлен полностью, зона ru-central1-b недоступна |
| 9 октября, утро | атака на дата-центр в Калуге, часть инфраструктуры вышла из строя |
| 9 октября | Yandex Cloud договорился с Selectel, K2Cloud и VK Cloud об ускоренном размещении и резервировании ресурсов клиентов на их площадках |
| 10 октября | облако перешло на ручное управление квотами на вычислительные ресурсы и диски |
| ночь на 11 октября | остановлен дата-центр во Владимире, платформа в аварийном режиме, облако советует восстанавливать ресурсы на внешних площадках |
| 11 октября, день | выдача квот на дополнительные ресурсы приостановлена |
| 13 октября | все сервисы облака в зонах РФ бесплатны для текущих клиентов с 8 по 31 октября |
| 16 октября | платформа по-прежнему работает в ограниченном режиме |
В карточке инцидента 11 октября перечислено 84 сервиса облака, среди них виртуальные машины, базы данных, хранилище объектов, Cloud DNS и Cloud Backup. Вместе с сервисами Яндекса сбоили сайты и приложения других компаний: «Лента.ру» называет 19 таких сервисов, среди них «Циан», «М.Видео», Lamoda и сайт аэропорта Пулково (обзор «Ленты.ру»).
Почему сайты не работали по несколько дней?
Облако рассчитано на потерю одной зоны, а в октябре выпало две.
Отдельные виртуальные машины, диски и группы в одной зоне сами в другую зону не переезжают. Документация Yandex Cloud прямо пишет, что при зональном инциденте клиенту «важно самостоятельно принять меры» и создать ресурсы в зоне, не затронутой сбоем (зональный инцидент в документации). Сайт, который стоял в одной зоне, ждал, пока кто-то перенесёт его руками. Группы машин в нескольких зонах и отказоустойчивые кластеры баз потерю одной зоны пережили сами, а потерю двух пережили не все.
Кластеру базы для автоматического переключения нужно, чтобы уцелело большинство узлов, которые голосуют за выбор главного: самих реплик или отдельного арбитра. Автор разбора на Хабре объясняет так: после потери двух зон из трёх у такого кластера остаётся один узел, и автоматика не вправе сделать его главным. 11 октября облако сообщило, что большинство отказоустойчивых кластеров баз переключились, но часть может работать только на чтение или быть недоступна. Такой кластер переключают вручную, рискуя потерять последние изменения.
Пока не работала одна зона, сайт из неё можно было поднять в соседней, а 10 октября облако дало всем небольшой запас ресурсов для восстановления из копий, сверх него квоты выдавали вручную. После остановки Владимира 11 октября выдачу квот на дополнительные ресурсы приостановили, и восстанавливаться внутри облака стало негде. Хранилище объектов 11 октября утром было доступно на чтение, днём и на запись, так что копию оттуда можно было скачать. Развернуть её быстро мог тот, у кого уже было место у другого провайдера и человек, знающий проект.
Пример «Циана», который «Лента.ру» называет среди пострадавших. Сайт и приложение были недоступны после аварии 11 октября на объекте инфраструктурного партнёра, а 12 октября компания запустилась в ограниченном режиме и продолжала «переносить данные из резервных копий на новые мощности» (канал «Циана»). Инфраструктура «Циана» была распределена по нескольким площадкам партнёра, копии были, а восстановление всё равно заняло больше суток: в штатном режиме ключевые сервисы заработали 13 октября. После аварии компания переносит резервные копии на инфраструктуру других провайдеров (пост «Циана»). Переезд к другому провайдеру для сложного проекта занимает ещё дольше, почему, разберу ниже.
Что проверить в своей инфраструктуре сейчас?
Вот что я бы спросил первым делом у того, кто ведёт сайт.
| Что проверить | Признак риска | Что сделать |
|---|---|---|
| зоны доступности | сайт и база в одной или двух зонах | разнести по трём зонам: узлам, которые голосуют за выбор главного (кворум базы, etcd у Kubernetes), для автоматического переключения нужно большинство, а при двух зонах потеря любой оставляет половину; зоны спасают от потери одной зоны, от потери двух и отказа облака спасает только второй провайдер |
| резервные копии | копии только в том же облаке: снимки дисков, Cloud Backup, данные под ключами облачного KMS | хранить у второго провайдера в России дамп базы, файлы и загрузки, настройки, секреты и образы контейнеров: снимки и Cloud Backup вне облака не восстановить; запись копий под отдельными учётными данными с запретом удаления; раз в квартал проверять восстановление |
| время восстановления | никто не знает, за сколько поднимется сайт | записать два числа: за какой срок сайт должен заработать (RTO) и данные за сколько последних часов работы допустимо потерять (RPO); их же пишут в договор поддержки |
| зависимость от одного провайдера | сайт, почта, DNS и копии у одной компании | вынести копии и DNS к другим провайдерам |
| DNS домена | зона домена в Cloud DNS того же облака | перенести DNS к отдельному DNS-провайдеру или держать вторичный DNS у второго; короткое время кеширования важных записей, например 300 секунд, выставить заранее: в день аварии поздно, старое значение уже в кешах |
| репозиторий, сборка, мониторинг | код, CI/CD и проверки доступности в том же облаке | зеркало репозитория и сборка вне основного облака, внешняя проверка доступности с оповещением в мессенджер |
| аккаунты | облако и домен оформлены на бывшего подрядчика | переоформить на компанию, доступы хранить у двух человек |
| инструкция переезда | её нет, всё знает один разработчик | описать шаги переезда и прогнать их хотя бы раз |
DNS проверяют отдельно, потому что от него зависит само переключение. Если записи домена обслуживает то же облако, что упало, перевести сайт на новый адрес сложнее: сначала придётся менять серверы имён у регистратора и ждать, пока изменение разойдётся по сети.
Инфраструктуру, описанную кодом, тоже нужно готовить заранее. В разборе на Хабре отмечено, что модули Terraform для облака Яндекса к Selectel или VK Cloud напрямую не применить: у каждого провайдера свои типы ресурсов. Переписывать их в день аварии долго.
Нужен ли сайту второй облачный провайдер?
Копия у второго провайдера нужна любому сайту с базой. Нужна ли ещё и запасная площадка с аккаунтом и квотами, зависит от того, сколько времени без сайта компания переживёт.
| Сайт | Сколько простоя выдержит бизнес | Минимум резервирования |
|---|---|---|
| сайт-визитка, лендинг, заявки дублируются по телефону | день-два | копия сайта и базы у второго провайдера, проверенное восстановление, DNS отдельно от облака: простой сайт на одном сервере из копии поднимают за часы, с поиском доступов и проверкой до суток |
| интернет-магазин или сайт, через который идут заказы | день-два | всё из строки выше плюс заранее заведённый аккаунт у второго провайдера с квотами, собранные там образы серверов, настроенная выкладка кода и записанный порядок переезда: в аварию останется перенести свежие данные |
| личный кабинет, онлайн-сервис для клиентов | минуты или час | копии мало, переезд из неё занимает дни: три зоны у основного провайдера и запасная площадка у второго с постоянной репликацией базы; она асинхронная, несколько последних секунд или минут данных может потеряться, а переключают по отрепетированной инструкции с решением человека |
| сайт на конструкторе или виртуальном хостинге | зависит от платформы | спросить у платформы, где копии и как она переживает отказ дата-центра, регулярно выгружать заявки и контент к себе |
Для любого сайта с персональными данными россиян второй провайдер выбирают только с базами в России. Об этом следующий раздел.
Посчитать просто: хранение копии и пустой аккаунт у второго провайдера сравнивают с выручкой за день простоя, умноженной на число дней, которые займёт переезд. По оферте Yandex Cloud клиент сам обеспечивает резервное копирование своей информации (пункт 7.4.3), так что копия вне облака это ваша задача, а не облака.
Как перенести копии с персональными данными и не нарушить 152-ФЗ?
Копию базы, где есть данные клиентов из России, переносят только на серверы в России. Часть 5 статьи 18 закона 152-ФЗ запрещает запись, хранение и обновление персональных данных граждан РФ в базах за пределами России, кроме нескольких случаев из статьи 6. Зарубежное облако как запасная площадка для такой базы не подходит, даже на неделю.
Что добавил бы юрист:
- Сервер в России сам по себе требования закона не закрывает. И второй провайдер, и подрядчик обрабатывают данные по вашему поручению, поэтому с обоими нужен договор с условиями части 3 статьи 6 152-ФЗ и мерами защиты по статье 19. Площадка должна давать нужный уровень защищённости по постановлению Правительства № 1119, для медицинских данных он выше, а для систем, связанных с ГИС, нужен аттестованный сегмент облака. Договоры оформляют до аварии.
- Уведомление об обработке персональных данных по части 1 статьи 22 обязательно почти для всех компаний. Если его нет, его подают. Если есть, после переезда обновляют сведения о месте базы, мерах защиты и трансграничной передаче не позднее 15-го числа следующего месяца (часть 7 статьи 22).
- Сбой у провайдера сам по себе не освобождает вас от обязательств перед своими клиентами: по пункту 3 статьи 401 ГК РФ нарушение обязанностей контрагентами к непреодолимой силе не относится, если договор не говорит иное. Форс-мажор и ответственность за срок восстановления прописывают в своих договорах с клиентами и с подрядчиком. Клиентов облака связывает оферта Yandex Cloud, а не общее пользовательское соглашение Яндекса: что считается непреодолимой силой, смотрят в ней.
Кто переносит сайт, если своей эксплуатации нет?
Этот раздел для компаний без своей команды эксплуатации. Если у вас есть свой администратор или DevOps, подрядчик для переезда не обязателен, но схема, доступы, место у второго провайдера и прогнанная инструкция нужны и вашей команде.
Время уходит на четыре вещи: найти доступы, понять, какие сервисы облака использует сайт, найти копии и понять, какие интеграции сломаются на новом адресе. Если это записано заранее, переносит любой инженер; если нет, разбор чужого проекта добавляет дни.
Поддержка облака 11 октября, по словам самого облака, отвечала со значительными задержками. Даже те, кто восстановился сам, получили второй удар. Глава TelecomDaily Денис Кусков, у которого сайт и приложение на Яндексе, рассказал «Фонтанке», что после первых атак «едва смогли восстановить в пятницу всё самостоятельно», а в ночь на 11 октября «опять всё легло» («Фонтанка»).
Даже подрядчику, который знает проект, на переезд без заранее собранной запасной площадки нужно несколько дней. Без договора поддержки к ним добавляются поиск команды, договор и смета. Если пункты из последнего раздела есть в договоре, переезд для подрядчика задача по действующему договору.
Сколько времени занимает переезд сайта к другому провайдеру?
Простой сайт на одном сервере с небольшой базой из готовой копии поднимают у другого провайдера за часы. Проекту с несколькими сервисами, управляемыми базами и выкладкой кода, привязанной к облаку, без заранее собранной площадки нужно несколько дней, даже когда копии готовы, и это нормальный срок. Перенос такого проекта состоит не из одного шага:
- Заново создать и настроить образы серверов: у нового провайдера свои типы машин, сети и сервисы, готовые настройки облака Яндекса туда не переносятся.
- Перенести все данные: базы, файлы, загрузки пользователей, и сверить, что ничего не потерялось.
- Заново выстроить выкладку кода (CI/CD): сборку, проверки и доставку новых версий на новые серверы. Если репозиторий и сборка тоже были в Yandex Cloud, сначала нужно поднять их зеркало, иначе выкладывать код нечем.
- Проверить интеграции: оплату, почту, обмен с CRM и внешние сервисы на новом адресе.
В аварию всё это идёт медленнее, чем в спокойное время: переезжают сразу многие компании, а каждый шаг делают руками. Поэтому даже компаниям со своим штатом на смену провайдера для сложного проекта без заранее собранной площадки нужно несколько дней. Подготовка заранее сокращает срок, но не превращает переезд в час работы. Если образы серверов, выкладка кода и аккаунт с квотами у второго провайдера готовы, в аварию остаётся перенести свежие данные и проверить интеграции: на это закладывают от нескольких часов до суток. Без такой подготовки дни уходят ещё и на поиск доступов и разбор проекта.
Как подрядчик ведёт переезд сайта после отказа облака?
Порядок такой, если план и копии готовы заранее:
- Понять по статус-странице облака и консоли, в каких зонах стоят ваши машины, диски и узлы кластеров и что не работает: сайт, база, хранилище файлов или часть сервисов. Затем решить, ждать или переезжать: если облако не называет срок восстановления или он больше вашего RTO, переезжать. 8 октября облако уже писало, что возобновить работу зоны в ближайшее время не удастся, и советовало альтернативные планы.
- Открыть место у второго провайдера или проверить заведённое заранее: аккаунт на компанию заказчика, нужные квоты, сеть.
- Развернуть сайт из последней проверенной копии.
- Если основная площадка частично жива, остановить на ней приём данных: заглушка или режим только чтения, отключённые фоновые задачи и обмены. Затем снять свежий дамп или выгрузить изменения с момента копии и загрузить их на новую площадку. Иначе заказы, принятые после копии, потеряются или уйдут в старую базу, и её придётся сводить вручную.
- Сверить данные (последние заказы, заявки, пользователи) и проверить формы, оплату, отправку писем и обмен с CRM на новом адресе, до переключения трафика.
- Переключить DNS и следить за ошибками первые часы.
- Если переехала база с персональными данными, обновить сведения в уведомлении Роскомнадзора.
- Написать короткий отчёт: что перенесли, какие данные потеряны, что и когда вернуть на основную площадку. Возвращаются по той же процедуре, с переносом данных, записанных на запасной площадке.
Для проекта с несколькими сервисами, если серверы у второго провайдера заранее не собраны, эти шаги даже по готовому плану занимают несколько дней, с собранными от нескольких часов до суток; простой сайт на одном сервере переносят за часы. Без плана к ним добавляются поиск доступов, разбор чужого кода и переписывание инфраструктуры под нового провайдера.
Что записать в договор поддержки сайта?
Чтобы переезд при следующей аварии шёл по договору, а не по новой смете, в договоре нужны такие пункты:
- за какой срок подрядчик поднимает сайт при отказе площадки и данные за сколько часов работы допустимо потерять;
- отказ облака или дата-центра не освобождает подрядчика от переезда на запасную площадку, а за срыв срока есть неустойка или снижение оплаты;
- переезд на запасную площадку входит в поддержку или оплачивается по ставке, согласованной заранее;
- копии хранятся у второго провайдера в России, у заказчика есть свой доступ к ним, восстановление проверяют по графику и пишут короткий акт;
- кто оплачивает ресурсы запасной площадки в аварию;
- у подрядчика актуальная схема инфраструктуры и инструкция переезда, он передаёт их по запросу;
- аккаунты облака, второго провайдера, регистратора домена и DNS оформлены на компанию заказчика;
- если подрядчику доступна база с персональными данными, есть поручение на обработку с мерами защиты и сроком, в который он сообщает вам об инциденте.
NerdSquad ведёт ИТ-аутсорсинг и поддержку проектов (страница услуги), делает работы по 152-ФЗ и пентесты. Если хотите подготовить запасную площадку до следующей аварии, напишите: заявку я читаю сам и отвечаю в течение двух рабочих часов. Как устроено сопровождение после запуска, разобрано в статье о технической поддержке приложения после релиза, а что спросить у подрядчика до договора, в чек-листе выбора подрядчика.
Об авторе. Антон Тарасенко, сооснователь и CEO NerdSquad, сооснователь YotaPhone и экс-CTO Yota Devices. NerdSquad (nerdsquad.ru) основана в 2015 году, разрабатывает веб-сервисы, мобильные приложения и ИИ-решения и усиливает ИТ-команды компаний специалистами: в команде 150+ специалистов, за плечами 70+ проектов. У компании сертификат ГОСТ Р ИСО/МЭК 27001:2021, услуги по 152-ФЗ и пентестам.
Услуга по теме: IT-аутсорсинг
Источники и методика
Хронология и цитаты сверены 23 октября 2026 года по сообщениям Яндекса и компаний.
- Заявление Яндекса о дата-центрах в Сасово, Калуге и Владимире, 9 октября 2026 года, обновлено 11 октября.
- Канал Yandex Cloud Alerts: сообщения с 8 по 16 октября 2026 года о зонах ru-central1-b и ru-central1-a, договорённости с Selectel, K2Cloud и VK Cloud, квотах, аварийном режиме и бесплатном октябре.
- Карточки инцидентов на статус-странице Yandex Cloud: зона ru-central1-b, 8–10 октября и отказ зон с 11 октября: состояние баз, хранилища объектов и квот.
- Документация Yandex Cloud: зональный инцидент.
- Разбор на Хабре о кворуме кластеров и переносе модулей Terraform.
- Обзор «Ленты.ру» о затронутых компаниях, сообщения «Циана» от 12 октября и 14 октября, «Фонтанка» с комментарием Дениса Кускова.
- Оферта Yandex Cloud: условия о непреодолимой силе и резервном копировании.
- Соглашение об уровне обслуживания Yandex Cloud: порядок, срок и предел компенсации.
- Закон 152-ФЗ: часть 5 статьи 18, статья 19, статья 22, часть 3 статьи 6; статья 401 ГК РФ.
- Сведения о NerdSquad по данным компании и странице ИТ-аутсорсинга.
Частые вопросы
Мой сайт не в Yandex Cloud. Меня это касается?
Да. Отказ дата-центра может случиться у любого провайдера, а слабые места те же: одна зона, копии у того же провайдера, DNS там же, нет плана переезда. Проверку из таблицы выше проходят с любым хостингом и облаком.
Можно ли получить компенсацию за простой от Yandex Cloud?
Рассчитывать стоит на бесплатный октябрь: Yandex Cloud не брал с текущих клиентов плату за сервисы в зонах РФ с 8 по 31 октября 2026 года. По соглашению об уровне обслуживания (SLA) компенсацию дают скидкой по запросу в течение 30 дней, она не больше стоимости потреблённого сервиса, а при непреодолимой силе её нет.
Можно ли держать резервную копию в зарубежном облаке?
Если в копии персональные данные граждан России, нельзя: часть 5 статьи 18 152-ФЗ запрещает хранить их в базах за пределами России, кроме случаев из статьи 6. Код и оформление сайта за рубежом хранить можно, но в папке картинок бывают загрузки пользователей, а в репозитории дампы базы и журналы с телефонами: это тоже персональные данные.
Как часто проверять, что резервная копия восстанавливается?
Я бы проверял раз в квартал и после каждого крупного изменения сайта: развернуть копию у второго провайдера без доступа к основному облаку, сверить время последнего заказа и число записей, пройти форму заявки и оплату на тестовом стенде и записать, сколько заняло восстановление. Копия, которую ни разу не восстанавливали, в день аварии может оказаться неполной или слишком старой.