По состоянию на 15.10.2026 Yandex Cloud и сервисы «Яндекса» восстанавливаются после остановки дата-центров 8–11 октября. Ниже — что известно о сбое облака, со ссылками на источники. Затем — план непрерывности e-commerce: карта зависимостей, резерв, протокол первых 60 минут.
Что произошло: сбой Yandex Cloud 8–11 октября 2026
Сбой шёл волнами: с 8 по 11 октября 2026 года из строя последовательно вышли три дата-центра, на которых работали Yandex Cloud и сервисы «Яндекса». Ниже только то, что подтверждают публикации и официальные сообщения. Последние данные в источниках датированы 14 октября.
- 8 октября. Yandex Cloud сообщил о перебоях электропитания в зоне доступности ru-central1-b, по данным iXBT, к 8:26 мск зона оставалась недоступной. Дата-центр в Сасове, где она размещена, был остановлен полностью (Хабр).
- 9 октября. В дата-центре в Калуге, по словам «Яндекса», несколько модулей полностью выведены из строя (Хабр).
- Ночь на 11 октября. Остановлен дата-центр во Владимире, облако перешло в аварийный режим и приостановило выдачу квот на дополнительные ресурсы (Коммерсантъ, Хабр).
- 11 октября, день. Сбои затронули маркетплейсы, службы доставки и ретейлеров: у части компаний были недоступны сайты, приложения и оформление заказов. «Яндекс Маркет» исключил заказы от 11 октября из индекса качества и не будет начислять плату за опоздания. ПВЗ и склады работали штатно, сортировочные центры были временно недоступны. В 18:02 мск Yandex Cloud сообщил об ограниченном режиме (Хабр).
- 13–14 октября. Платформа остаётся в ограниченном режиме, плата за сервисы не взимается с 8 по 31 октября (Anti-Malware). По сообщению пресс-службы «Яндекса», восстановлена работа ряда корпоративных ИИ-сервисов, восстановительные работы продолжаются (Ведомости).
Сроки восстановления оборудования компания не называет (Хабр). Первоисточник по облаку — страница статуса Yandex Cloud, актуальное состояние смотрите там.
Карта зависимостей: что падает вместе с облаком
По нашей оценке, главный вывод из событий выше — общий корень. Недоступными оказались сразу две зоны доступности, ru-central1-b и ru-central1-a, поэтому резерв в соседней зоне того же облака не помог бы. Помогает канал без общего корня с основным.
Заказ проходит цепочку: витрина, корзина, оплата, учётная система, склад, служба доставки, уведомление клиенту. Каждое звено живёт у своего провайдера. Если у двух звеньев общий корень, например одно облако или один DNS-провайдер, они упадут одновременно.
Нарисуйте цепочку на одном листе. Для каждого звена запишите, где оно размещено, что остановится при его отказе и кто принимает решение. Ниже пример заполнения для типового магазина.
| Звено цепочки | Что ломается при отказе | Что подготовить заранее |
|---|---|---|
| Витрина и корзина | Покупатель не открывает сайт | Статическая страница с телефоном и режимом работы на другом хостинге |
| Приём оплаты | Заказ оформлен, платёж не проходит | Второй способ оплаты и оплата по счёту |
| Учётная система и CRM | Менеджеры не видят новые заказы | Ежедневная выгрузка заказов в таблицу вне облака |
| Обмен с площадками | Остатки и статусы не обновляются | Запас в остатках и порядок ручной выгрузки |
| Сценарии автоматизации | Накладные и уведомления не уходят | Список сценариев и порядок их ручного запуска |
Вывод: у каждого звена должен быть запасной путь. Он не должен лежать у того же провайдера, иначе резерв упадёт вместе с основой.
Отдельно найдите общие корни. Если домен, DNS, сайт и автоматизация лежат у одного провайдера, это одна точка отказа, а не пять. Проверьте и доступы: почта на домене, который лежит у того же провайдера, не поможет войти в его кабинет во время сбоя.
Резервные каналы и мониторинг: что подготовить заранее
Резерв нужен там, где остановка бьёт по деньгам сразу: приём заказов, оплата, связь с клиентом. Для каждого такого звена выберите канал, у которого нет общего корня с основным.
Ниже минимальный набор для небольшого магазина. Каждый пункт выполним без программиста.
- Заведите страницу статуса и канал рассылки на отдельном хостинге.
- Храните копию заказов и остатков вне основного облака.
- Заведите вторых администраторов в кабинетах провайдера, площадок и платёжного сервиса.
- Сохраните коды восстановления доступа офлайн.
- Запишите, кто и как переключает DNS на резервную страницу.
Резервная копия считается рабочей только после пробного восстановления. Файл на диске ничего не доказывает: проверьте, что из него поднимается магазин или хотя бы читаются заказы.
Мониторинг отвечает на вопрос: узнаете ли вы о сбое раньше клиента. Проверяйте путь заказа, а не сервер: открывается ли главная, добавляется ли товар в корзину, отвечает ли обмен с площадкой. Уведомления направляйте в канал, который не зависит от проверяемой системы. Мониторинг на том же облаке замолчит вместе с ним.
Протокол первых 60 минут: что делать во время сбоя
Во время сбоя каждый открывает свою вкладку и перепроверяет одно и то же. Протокол заранее распределяет роли, поэтому в первый час люди делают разные вещи. Так устроено и управление инцидентами в практике Google SRE: один человек держит общую картину, изменения вносит отдельная группа, за сообщения отвечает третий.
Тайминг ниже — наш ориентир, подстройте его под свой магазин. Минуты задают порядок действий, а не жёсткий регламент.
- Минуты 0–10. Подтвердите сбой: откройте статус-страницу провайдера и зайдите на магазин из другой сети. Назначьте координатора.
- Минуты 10–20. Отметьте затронутые звенья по карте зависимостей: витрина, оплата, обмен, учёт.
- Минуты 20–30. Включите резерв: страницу-заглушку и ручной приём заказов. Остановите рекламу, которая ведёт на недоступные страницы.
- Минуты 30–45. Сообщите клиентам и площадкам, что работает и когда будет следующее обновление.
- Минуты 45–60. Зафиксируйте решение: ждёте провайдера, переключаетесь на резерв или остаётесь в ручном режиме до конца дня.
Координатора и его заместителя назначьте заранее. В момент сбоя выбирать некогда, а общий чат без ведущего превращается в споры о причине.
Что сказать клиентам
Пишите короткими фактами: что не работает, что работает, когда будет следующее обновление. Причину называйте только тогда, когда знаете её точно. Догадки вызывают больше вопросов, чем честное «причина уточняется».
Пример для страницы статуса: «Оформление заказов на сайте временно не работает. Заказы принимаем по телефону и в мессенджере. Следующее обновление — в 15:00».
Если клиент уже оплатил заказ, а срок сорвать придётся, предложите новый срок или возврат сразу. Статья 23.1 закона о защите прав потребителей обязывает продавца платить неустойку за просрочку передачи предоплаченного товара по ставке 0,5% суммы предоплаты за каждый день. Ставку и порядок расчёта сверьте с актуальной редакцией закона.
Что сообщить площадкам
Если вы работаете по FBS и не успеваете собрать заказы, напишите в поддержку продавцов с номерами заказов и временем начала сбоя. Порядок штрафов за срыв отгрузки смотрите в правилах конкретной площадки: он различается.
Главный риск здесь — остатки. Когда обмен остановлен, площадка показывает старые числа, и вы продаёте товар, которого уже нет. Пока обмен не работает, выставьте нулевые или заниженные остатки по ходовым позициям вручную. О том, как держать остатки едиными между системами, мы писали в материале Автоматическая синхронизация остатков Ozon: как настроить.
Ручной режим заказов
Ручной режим держится на одном правиле: один журнал, один ответственный. Заведите общую таблицу вне упавшего облака и ведите в ней все заказы.
- Записывайте номер заказа, состав, способ оплаты, адрес, статус и того, кто взял заказ.
- Принимайте заказы по телефону и в мессенджере, дублируя каждый в журнал.
- Сверяйте наличие по складу, а не по учётной системе.
- Отмечайте оплаты отдельной колонкой, чтобы сверить их с платёжным сервисом после сбоя.
Сколько часов съедает ручная обработка, посчитайте по формуле расчёта часов ручной обработки заказов. Умножьте результат на число часов сбоя, и получите оценку своих потерь.
После сбоя: разбор и договор с провайдером
Когда магазин снова работает, самая полезная часть только начинается. Разбор должен быть безвинным: он ищет слабое место в процессе, а не виноватого. Такой формат описан в книге Google SRE. Сделайте его в первые дни, пока никто не забыл детали.
- Восстановите хронологию по минутам: когда начался сбой, когда его заметили, когда сообщили клиентам.
- Сверьте данные между системами: заказы, оплаты, остатки.
- Посчитайте потери: заказы, которые не пришли, возвраты и расходы на рекламу.
- Решите, что меняете в карте зависимостей, резерве и мониторинге.
- Назначьте владельца и срок для каждого изменения.
SLA: что читать в договоре с провайдером
SLA, соглашение об уровне обслуживания, обычно открывают после сбоя. Откройте его до. Процент доступности ничего не говорит без периода расчёта.
Таблица переводит процент в минуты. Расчёт: в году 525 600 минут, в 30 днях 43 200 минут, их умножают на долю недоступности.
| Гарантия SLA | Недоступность за год, мин | Недоступность за 30 дней, мин |
|---|---|---|
| 99,5% | 2 628 | 216 |
| 99,9% | 526 | 43 |
| 99,95% | 263 | 22 |
| 99,99% | 53 | 4 |
Вывод: между 99,5% и 99,99% разница в 50 раз. В договоре обе цифры выглядят как «почти сто процентов».
Реальные условия видны в самом документе. Возьмём SLA на аренду VDS у Timeweb по состоянию на 15.10.2026. Провайдер гарантирует доступность не ниже 99,9% по итогам года, то есть около 526 минут недоступности. Отсчёт идёт с момента, когда поддержка приняла обращение в работу, а не с момента отказа.
Обходное решение считается решением инцидента. Компенсация положена при остановке от 6 часов, равна стоимости услуги за сутки и выдаётся продлением срока услуги. Заявку подают в течение 30 дней.
Вывод: компенсация измеряется стоимостью сервера, а ваши потери измеряются выручкой магазина. SLA не заменяет резерв: он фиксирует лишь то, что провайдер вам должен.
Условия компенсации лежат в договоре и в SLA, а не на рекламной странице. Перед подписанием или продлением договора задайте провайдеру пять вопросов:
- С какого момента начинается отсчёт недоступности?
- За какой период считается процент: месяц или год?
- Какие события исключены из расчёта?
- Как и в какой срок подать заявку на компенсацию?
- Что происходит с вашими данными и резервными копиями при долгой остановке?
Чек-лист плана непрерывности
Соберите план в одном документе и пройдите по списку раз в квартал. Так карта зависимостей не устареет вместе с вашим набором сервисов.
До сбоя
- Нарисуйте цепочку заказа и отметьте общие корни.
- Заведите страницу статуса на отдельном хостинге.
- Выгружайте заказы и остатки вне основного облака каждый день.
- Настройте мониторинг пути заказа с оповещением вне проверяемой системы.
- Проверьте восстановление из резервной копии.
Во время сбоя
- Назначьте координатора и подтвердите сбой из другой сети.
- Включите страницу статуса и журнал ручных заказов.
- Выставьте заниженные остатки на площадках.
- Остановите рекламу, которая ведёт на недоступные страницы.
- Назовите клиентам время следующего обновления.
После сбоя
- Восстановите хронологию и сверьте данные между системами.
- Посчитайте потери в часах и в рублях.
- Подайте заявку на компенсацию в срок, который задаёт SLA.
- Обновите карту зависимостей и протокол.
- Назначьте владельца и срок для каждого изменения.
Частые вопросы
Что случилось с облаком Яндекса и когда оно восстановится?
С 8 по 11 октября 2026 года вышли из строя дата-центры в Сасове, Калуге и Владимире, платформа Yandex Cloud работает в ограниченном режиме. Сроки восстановления оборудования компания не называет. Хронология с источниками — в разделе «Что произошло», актуальный статус — на странице статуса Yandex Cloud.
Нужен ли малому магазину второй облачный провайдер?
Не всегда. Для витрины хватает статической страницы-заглушки и выгрузки заказов на другом хостинге. Полный второй контур оправдан, когда час остановки стоит дороже его содержания. Считайте так: выручку за сутки поделите на число рабочих часов и умножьте на часы сбоя из прошлого разбора.
Что делать, если сбой у самой площадки, а не у моего облака?
Ваш магазин остаётся рабочим, но заказы с площадки не приходят. Сообщите клиентам по своим каналам и направьте рекламу на собственную витрину. Зафиксируйте время начала и окончания сбоя: оно понадобится для обращения в поддержку. Условия компенсации ищите в оферте площадки.
Как проверить, что резервная копия рабочая?
Восстановите её в отдельном окружении и сверьте с боевыми данными: число заказов, сумму остатков, дату последней записи. Если восстановление не удалось, копии у вас нет. Повторяйте проверку после каждого изменения структуры данных.
Что делать с автоматизациями, которые упали вместе с облаком?
Держите список сценариев с порядком ручного запуска: что запускать первым, какие данные подставлять, как проверять результат. Храните выгрузку сценариев вне сервера, на котором они работают. n8n сохраняет сценарии в файлы JSON, поэтому их можно развернуть на другом сервере, а не собирать заново.
Что делать дальше
Выпишите цепочку заказа от витрины до доставки и отметьте звенья, которые лежат у одного провайдера. Это ваши общие точки отказа. Начните с тех, где остановка бьёт по оплате и приёму заказов.
Если среди них есть автоматизации, придите на бесплатный экспресс-разбор на 20–30 минут. Покажем, какие сценарии завязаны на один сервер. Объясним, как перенести их на n8n на вашем сервере с мониторингом и резервными копиями. Подробности — на странице автоматизация e-commerce.
