Инциденты Yandex Cloud в 2026 году
Инциденты Yandex Cloud в 2026 году
Последняя проверка: 21 августа 2026 года.
Краткий вывод
Официальная хронология Yandex Cloud за 2026 год показывает не только глобальную потерю внешней связности 27 мая, но и локальные проблемы создания ресурсов, Managed Databases, VPC, OpenSearch и AI Studio. Самым масштабным событием остаётся ошибка сетевой конфигурации 27 мая: она затронула внешний трафик во всех российских зонах, а провайдер опубликовал технический разбор причины и мер предотвращения.
Хронология подтверждённых событий
| Дата | Зона или сервис | Что произошло | Публичное окно | Источник |
|---|---|---|---|---|
| 27 мая | Все российские зоны, внешняя сеть | Ошибочная конфигурация сетевого оборудования нарушила внешнюю связность публичных сервисов | 15:22–15:36 МСК; основное воздействие примерно до 15:29 | Инцидент и технический разбор |
| 22 мая | VPC и зависимые сервисы, ru-central1-a | Проблема Virtual Private Cloud затронула Compute Cloud, Managed Kubernetes и несколько управляемых СУБД | Около 5 ч 5 мин по status-панели | Официальная хронология |
| 19 мая | Создание ресурсов, ru-central1-a | Возникали ошибки создания ресурсов | 14:50–15:23 UTC, 33 мин | Официальная хронология |
| 20 апреля | Yandex AI Studio | Часть моделей была недоступна | 16:16–17:03 UTC, 47 мин | Status-панель |
| 27 февраля | Compute Cloud, Managed Databases и Managed Kubernetes, ru-central1-b | Возникали ошибки создания ВМ, узлов баз данных и Kubernetes | 14:20–14:42 UTC, 22 мин | Официальная хронология |
| 29 января | Managed Databases, российские зоны | Были затруднены операции с кластерами управляемых баз данных | 13:30–22:45 UTC, 9 ч 15 мин | Хронология Managed Services |
| 20 января | Managed Service for OpenSearch | API OpenSearch работал с ошибками | 09:25–14:08 UTC, 4 ч 43 мин | Хронология Managed Services |
| 19 января | Создание ВМ и зависимых ресурсов, ru-central1-a | Нельзя было создавать виртуальные машины; проблема затрагивала зависимые операции Kubernetes и Managed Databases | 08:01–11:30 UTC, 3 ч 29 мин | Официальная хронология |
Время в таблице передано так, как оно опубликовано в источнике. Status-панель может показывать время записи и наблюдения, а не непрерывный простой каждого отдельного ресурса.
27 мая — временная недоступность внешних сервисов
| Параметр | Значение |
|---|---|
| Публичное окно status-панели | 15:22–15:36 МСК |
| Основное воздействие на внешний трафик | примерно 15:22–15:29 МСК |
| Зоны | ru-central1-a, ru-central1-b, ru-central1-d, ru-central1-e |
| Уровень | внешняя сетевая связность |
| Статус | устранено, опубликован разбор |
По отчёту Yandex Cloud, ошибочная конфигурация сетевого оборудования привела к некорректному распространению маршрутной информации. В результате была потеряна связность с пограничными виртуальными маршрутизаторами и оборвались BGP-сессии между ключевыми сетевыми устройствами.
Проблема затронула публичные IP-адреса и сервисы, зависящие от внешнего трафика, включая Network Load Balancer, Egress NAT, Cloud Interconnect и Private Endpoint. При этом внутренние пользовательские ресурсы и основная передача данных внутри платформы продолжали работать.
Другие существенные события
Январь — создание ресурсов и Managed Databases
19 января около трёх с половиной часов нельзя было создавать виртуальные машины и связанные ресурсы в ru-central1-a. 29 января более девяти часов были затруднены операции с кластерами Managed Databases в российских зонах.
Это не обязательно означает остановку всех уже работающих ВМ или СУБД. Практический риск заключается в другом: во время аварии может не сработать масштабирование, замена узла или восстановление инфраструктуры из шаблона.
22 мая — VPC в ru-central1-a
Проблема Virtual Private Cloud затронула сразу несколько зависимых сервисов в одной зоне. Для приложения важно отдельно контролировать:
- доступность уже работающих ресурсов;
- создание новых экземпляров;
- внутреннюю сеть;
- внешний маршрут;
- работу API управления.
Один общий health-check приложения не различает эти уровни.
Что сделал провайдер после события 27 мая
В опубликованном разборе указаны:
- откат ошибочной конфигурации;
- восстановление корректной маршрутной информации;
- дополнительные проверки сетевых изменений;
- меры по снижению риска распространения некорректных маршрутов.
Практический вывод
- многозонность внутри одного облака не защищает от общей ошибки пограничной сети;
- доступность работающей ВМ не гарантирует возможность создать замену или выполнить операцию Managed Service;
- для критичного внешнего API нужен мониторинг не только VM, но и публичного маршрута;
- полезно иметь резервный внешний endpoint или вторую площадку;
- внутренний health-check не заменяет проверку из интернета;
- IaC-сценарий должен корректно повторять операции после временных ошибок API;
- публикация технического постмортема является сильным плюсом к прозрачности провайдера.
Ограничение проверки
В журнал включены подтверждённые события, которые заметно влияли на доступность или создание ресурсов. Короткие локальные предупреждения и плановые работы могут отсутствовать. Большое количество опубликованных записей следует оценивать вместе с прозрачностью status-панели, длительностью воздействия и качеством постмортемов.