Сбой Yandex Cloud: почему сервис в одной зоне падает целиком
Опубликовано · 7 мин чтения
11 октября в 03:57 по Москве у WorkAI перестали открываться сайт workai.su, вход в редактор и чат с моделями. В 04:12 Yandex Cloud объявил о перебоях с электропитанием в зоне доступности ru-central1-a, а весь наш прод стоял именно в ней. Ниже хронология сбоя по сообщениям Яндекса, разбор того, почему одна зона положила сервис целиком, и что проверить у себя, если ваш сервис тоже живёт в одной зоне.
Коротко
- Зона ru-central1-b не работает с 8 октября, ru-central1-a с ночи 11 октября. По сообщениям Яндекса, дата-центры в Сасово и во Владимире остановлены после атак беспилотников.
- Региональные кластеры Kubernetes, размещённые в зонах d и e, продолжили работать.
- Перенос виртуальных машин командой relocate возможен только в ru-central1-d, публичные IP-адреса между зонами не переносятся.
Что случилось с Yandex Cloud 8–11 октября#
Сначала пропала зона ru-central1-b, через три дня ru-central1-a. Хронология ниже собрана по каналу оповещений Yandex Cloud, время московское.
| Когда | Что сообщил Яндекс |
|---|---|
| 8 октября, 01:44 | Перебои с электропитанием в зоне ru-central1-b, нагрузку рекомендуют перенести в другие зоны |
| 8 октября, 08:26 | Зона b по-прежнему недоступна, сервисы в остальных зонах работают штатно, но создание новых ресурсов в них может быть ограничено |
| 8 октября, 15:19 | Причина — пожар после атаки беспилотников на дата-центр Яндекса в Сасово, его работа полностью остановлена |
| 9 октября, 15:19 | Управляющие компоненты региональных кластеров Kubernetes можно вывести из зоны b, хосты в ней из отказоустойчивых кластеров баз — удалить |
| 10 октября, 09:00 | На выходные квоты на вычислительные ресурсы и диски переводятся на ручное управление, приоритет у клиентов, чьи критичные сервисы не восстановлены |
| 11 октября, 04:12 | Перебои с электропитанием в зоне ru-central1-a, тип инцидента «Недоступность», в нём 84 сервиса |
| 11 октября, 05:10 | Дата-центр во Владимире повреждён атакой беспилотников и полностью остановлен, платформа в аварийном режиме |
| 11 октября, 05:59 | Недоступны зоны a и b; консоль и API работают, Compute доступен в зонах d и e |
| 11 октября, 07:14 | Региональные кластеры Kubernetes в зонах d и e работают, региональные кластеры с мастером в одной из зон недоступны |
На 11 октября сроков восстановления зон a и b компания не называла. Клиентам она рекомендовала поднимать ресурсы на альтернативных площадках. Актуальный статус публикуется на status.yandex.cloud и в Telegram-канале yandexcloudalerts.
Зоны доступности Yandex Cloud: что это и где они#
Внутри региона ru-central1 выделены зоны доступности, и по документации каждая изолирована от аппаратных и программных сбоев в других. На 16 июня 2026 года их пять, и среди них ru-central1-a, ru-central1-b, ru-central1-d, ru-central1-e и ru-central1-m для выделенных серверов BareMetal. Платформа работает в четырёх дата-центрах Яндекса, для новых проектов компания рекомендует зону d.
Виртуальная машина, диск и зональный кластер живут ровно в одной зоне и падают вместе с ней. Бакет Object Storage по документации — глобальный ресурс и к зоне не привязан, поэтому 11 октября хранилище продолжало отдавать файлы, хотя лежали две из четырёх зон для виртуальных машин — a, b, d и e. Запись в него при этом могла не проходить.
Почему WorkAI упал целиком#
В системе аналитики последнее событие от нашего бэкенда записано в 03:56:53, после 04:05 не пришло ни одного. Ночью до этого каждые 15 минут приходило от 46 до 415 событий, так что обрыв не похож на тихий час.
Всё упирается в топологию. В ru-central1-a стояли три узла кластера Kubernetes, виртуальная машина-маршрутизатор к базам клиентских проектов и мастер кластера, а поскольку кластер зональный, вместе с зоной пропал и его API, через который можно было бы перенести нагрузку на уцелевшие зоны.
База PostgreSQL с боевыми данными жила внутри того же кластера, на диске в той же зоне. Большинство отказоустойчивых кластеров управляемых баз Яндекса при отказе переключились, часть работала только на чтение или была недоступна. Нашей базе переключаться было некуда.
Ежесуточно, в 05:00 по Москве, снимается копия базы и уходит в Object Storage на 30 дней. Последний дамп перед сбоем, 2,5 ГБ, загружен 10 октября в 05:15. Бакет к зоне не привязан, поэтому копия пережила её отказ. Цена суточного расписания в том, что данные за последние сутки в этот дамп не попадают, и здесь это почти 23 часа, с 05:00 10 октября до начала сбоя.
Как мы поднимались и что изменили в устройстве сервиса, расскажем отдельным разбором.
Что можно перенести между зонами, а что нет#
Пока зона жива, ресурсы из неё можно увезти заранее. Для переноса нужна работающая исходная машина или её снимок, поэтому при отказе зоны рассчитывать на него не стоит. Правила ниже — по документации Yandex Cloud о переносе между зонами, данные на 24 июня 2026 года.
| Ресурс | Как переносится | Ограничение |
|---|---|---|
| Виртуальная машина, диск | Командой relocate | Только в зону ru-central1-d; машину с подключённой файловой системой перенести нельзя |
| Группа виртуальных машин | Добавить новую зону в группу, затем убрать старую | — |
| Управляемая база | Добавить хост в новой зоне и сменить адрес в приложении | — |
| Кластер Managed Kubernetes | Сначала перенести мастер, затем группы узлов | — |
| Публичный IP-адрес | Не переносится | Входящий адрес сохраняется только через балансировщик |
| Object Storage, Cloud DNS, Cloud CDN | Переносить не нужно | Бакет Object Storage — глобальный ресурс |
Перед relocate Яндекс советует снять снимок диска или копию в Cloud Backup, потому что у машины меняется сетевое окружение, а без копии откатиться нечем. Подсеть в новой зоне нужно создать заранее.
Чек-лист: если ваш сервис стоит в одной зоне#
- Узнайте, в какой зоне ресурсы. У машин и дисков зона есть в списке, у кластера Kubernetes — в описании мастера, у управляемой базы — в списке хостов. Команды ниже, в консоли зона видна на странице ресурса.
- Составьте список зависимостей: база, очереди, хранилище файлов, DNS, почта, мониторинг, сторонние API. Для каждой отметьте зону или «не привязана к зоне».
- Проверьте тип мастера Kubernetes. Зональный падает вместе с зоной, высокодоступный можно разместить в трёх зонах.
- Найдите последнюю копию базы и посчитайте, сколько часов данных пропадёт, если восстанавливаться из неё прямо сейчас.
- Хотя бы раз разверните копию в пустую базу. Пока этого не сделано, неизвестно, восстановится ли она.
- Держите вторую копию данных у другого провайдера: при отказе облака целиком или блокировке аккаунта копия в том же облаке недоступна.
- Снизьте TTL записей DNS до нескольких минут и вынесите проверку доступности за пределы облака, иначе мониторинг упадёт вместе с сервисом.
yc compute instance list
yc compute disk list
yc managed-kubernetes cluster get <имя-кластера>
yc managed-postgresql host list --cluster-name <имя-кластера>Почему нескольких зон одного провайдера может не хватить#
Несколько зон спасают от отказа одного дата-центра, но в этот сбой лежали две зоны из четырёх, а на полностью ручное управление квотами на вычислительные ресурсы и диски Яндекс перешёл ещё утром 10 октября, до отказа зоны a. От такого, по нашему опыту, защищает прежде всего резерв у другого провайдера или готовый план переезда туда.
WorkAI — редактор кода с ИИ-агентом. Начать можно бесплатно: открытые модели доступны без карты.
Скачать WorkAIЧастые вопросы
Как понять, в какой зоне стоят мои ресурсы?
В выводе yc compute instance list и yc compute disk list есть колонка ZONE ID. У кластера Kubernetes зона мастера видна в yc managed-kubernetes cluster get, у управляемой базы — в списке хостов. В консоли зона видна на странице ресурса.
Что такое зоны доступности в Yandex Cloud?
Площадки региона ru-central1, изолированные от сбоев друг друга: ru-central1-a, -b, -d, -e и ru-central1-m для выделенных серверов. Сервис, разнесённый по нескольким зонам, переживает потерю одной площадки.
Можно ли перенести виртуальную машину в другую зону?
Да, командой yc compute instance relocate, но на 24 июня 2026 года только в ru-central1-d. Машину с подключённой файловой системой перенести нельзя, публичный IP-адрес не переносится. Перед переносом снимите снимок диска.
Что делать, если зона недоступна, а ресурсы в ней?
Поднимать сервис заново в работающей зоне из бэкапа или реплики, не дожидаясь восстановления площадки. 11 октября Яндекс советовал клиентам использовать альтернативные площадки.
Хватит ли резервной копии, если она лежит у того же провайдера?
От отказа одной зоны хватит, если копия в Object Storage, а не на диске рядом с базой. От отказа всего облака или блокировки аккаунта не хватит: нужна вторая копия у другого провайдера.
Нужно ли срочно переезжать к другому провайдеру?
Зависит от того, сколько часов простоя выдержит сервис. Минимум, который стоит сделать сразу: копия данных у другого провайдера и записанный план, как поднять сервис там. 11 октября Яндекс сам рекомендовал клиентам альтернативные площадки.