Инциденты Selectel в 2026 году
Инциденты Selectel в 2026 году
Последняя проверка: 21 августа 2026 года.
Краткий вывод
У Selectel одна из наиболее подробных публичных status-панелей среди провайдеров в подборке. Поэтому событий видно больше, чем у компаний без открытой истории. В журнале важно разделять:
- собственные аварии облачных пулов и VDS;
- проблемы отдельных сервисов вроде S3, DNS, Container Registry и CDN;
- сторонние сервисы резервного копирования Veeam;
- внешнюю связанность до Cloudflare, Hetzner или российских операторов;
- время жизни записи и фактическое время непрерывного простоя.
Крупные и длительные события
| Дата | Сервис или уровень | Что произошло | Статус | Источник |
|---|---|---|---|---|
| 19 августа, 13:29 МСК | Veeam VAC / резервное копирование | Стала недоступна консоль управления Veeam VAC; Selectel предупреждал о возможных проблемах с выполнением запланированных backup jobs | Устранено через 18 минут; после восстановления задачи резервного копирования работали штатно | Status-панель |
| 18 августа, 21:21 МСК | CDN | Глобальная недоступность CDN и ошибки 500; партнёр сообщил об аварии в дата-центре и массовом падении аплинков | Устранено, запись длилась 1 ч 32 мин | Status-панель |
| 18 августа, 21:02 МСК | Внешняя сеть / Cloudflare | Из части подсетей Selectel были недоступны некоторые ресурсы за Cloudflare; при TLS-сессиях терялись пакеты на магистральных узлах | Диагностика с вышестоящими операторами; финального апдейта на странице не было | Status-панель |
| 17–18 августа | Veeam Cloud Connect / Veeam Agent | Возникли проблемы с Cloud Repository и Agent-Based Backup | Устранено 18 августа в 12:23 МСК; запись длилась 1 день 2 ч 59 мин | Status-панель |
| 15 августа | Внешняя сеть / Hetzner | Нарушилась связность с Hetzner | Связность восстановлена перемаршрутизацией; окончательное устранение зависело от внешней площадки | Status-панель |
| 12 августа | Облачная платформа ru-2 | Нарушилась сетевая доступность части ресурсов пула | Устранено, запись длилась 1 ч 1 мин | Status-панель |
| 6 августа | Внешняя связность в Рунете | Массовые сбои у сторонних сервисов и операторов; дата-центры и внутренние сети Selectel работали штатно | Устранено, запись длилась 3 ч 39 мин | Status-панель |
| 20 июля | Container Registry | Реестр контейнеров был недоступен | Устранено, запись длилась 1 ч 42 мин | Status-панель |
| 15 июля | Облачная платформа ru-7 | Произошли два отдельных сетевых сбоя ресурсов с Floating IP; опубликован постмортем | Устранено; окна воздействия 14:30–14:56 и 19:30–20:11 | Постмортем |
| 15 июля | Облачная платформа ru-2 | Возникли проблемы работы существующих ВМ и создания новых серверов | Устранено, запись длилась 51 мин | Status-панель |
| 19 июня | Облачная платформа ru-3 | Деградация связности с интернетом | Устранено, запись длилась 4 ч 47 мин | Status-панель |
| 19 июня | Облачная платформа ru-3 | Часть облачных серверов была недоступна | Устранено, запись длилась 2 ч 18 мин | Status-панель |
| 11 июня | VDS, Санкт-Петербург | Массовые обращения по недоступности VDS | Устранено, запись длилась 2 ч 25 мин | Status-панель |
| 29–30 мая | Панель, HTTPS/TLS | Часть пользователей не могла открыть панель и отдельные ресурсы; Selectel предположил влияние новых правил DPI-фильтрации на внешних маршрутах | Внутренняя связность и DNS были исключены как причина; запись закрыта через 1 день 4 ч 47 мин | Status-панель |
| 18–21 мая | IPMI выделенных серверов | IPMI было недоступно в нескольких пулах Санкт-Петербурга, Москвы и Алматы | Восстановлено; запись была открыта 2 дня 23 ч 27 мин | Status-панель |
| 15 мая | DNS, регион uz-1 | DNS-серверы региона были недоступны | Устранено, запись длилась 2 ч 4 мин | Status-панель |
| 13–14 мая | Алматы, Ташкент, Найроби | DDoS-атака на инфраструктуру регионального партнёра повлияла на связанность, DNS и часть сервисов | Связность восстановлена после переключения фильтрации | Status-панель |
| 20–21 апреля | Пулы ru-7a, ru-7b | Проблемы создания ВМ и обращения по недоступности существующих ресурсов | Полностью восстановлено через 6 ч 8 мин | Status-панель |
| 5–15 апреля | VDS, Москва | Публичные адреса из подсети 77.105.168.0/24 были недоступны | Устранено; запись была открыта 9 дней 20 ч 38 мин | Status-панель |
| 28–29 января | DNS, S3, Managed Databases | Возникли проблемы разрешения служебных доменов кластеров баз данных и S3 | Устранено; запись длилась 20 ч 59 мин | Status-панель |
Короткие локальные события
| Дата | Сервис | Воздействие | Источник |
|---|---|---|---|
| 9 апреля | S3 ru-7 | Ошибка сертификата или доступности endpoint S3 | Status-панель |
| 25 марта | S3 ru-7 | Бакеты не открывались в панели, ссылки могли быть недоступны | Status-панель |
| 11 января | Cloud Platform ru-7a | Не создавались ВМ с публичными IP-адресами | Status-панель |
| 6 января | S3 gis-1 | Нарушение доступности объектного хранилища | Status-панель |
15 июля — автоматизация удалила критический интерфейс в ru-7
В ru-7 произошло два разных сетевых инцидента: с 14:30 до 14:56 и с 19:30 до 20:11. Воздействие касалось ресурсов с Floating IP.
В опубликованном постмортеме Selectel сообщил, что ошибка автоматизации удаляла критический интерфейс виртуальных маршрутизаторов. После первого восстановления сценарий повторился вечером, поэтому событие важно рассматривать не как один непрерывный простой, а как два окна воздействия с общей причиной.
Отдельно в тот же день возникла локальная проблема ru-2, затронувшая работу и создание виртуальных машин. Источники не дают оснований объединять её с ошибкой маршрутизаторов ru-7.
17–19 августа — два разных события Veeam
В середине августа status-панель зафиксировала два связанных с Veeam, но разных события.
17–18 августа: Cloud Connect и Agent
17 августа в 09:24 МСК Selectel сообщил о проблемах с:
- Veeam Cloud Connect Cloud Repository;
- Agent-Based Backup / Veeam Agent.
Запись была закрыта 18 августа в 12:23 МСК. Status-панель сообщает об устранении проблемы, но не дает оснований автоматически трактовать всю длительность записи как непрерывную потерю всех backup jobs у каждого клиента.
19 августа: Veeam VAC
19 августа в 13:29 МСК стала недоступна управляющая консоль vac.selectel.ru. Selectel отдельно предупредил, что из-за этого могли возникать проблемы с выполнением запланированных заданий резервного копирования.
Через 18 минут доступ к консоли был восстановлен. В финальном апдейте Selectel указал, что backup jobs снова выполняются штатно.
Как это интерпретировать
Эти события важны не как доказательство потери данных — официальный источник такого не утверждает, — а как напоминание, что управляемая система бэкапов сама является зависимостью.
Для критичного проекта стоит контролировать не только наличие услуги Veeam, но и факт успешного выполнения задания:
backup scheduled
↓
job completed successfully
↓
copy exists outside production VM
↓
restore periodically tested
Если резервная копия существует только в одном сервисе того же провайдера, это не полноценная защита от провайдерского или аккаунтного инцидента.
18 августа — несколько разных инцидентов
События CDN, Cloudflare и авария ММТС-9 начались близко по времени, но источники описывают разные уровни проблемы:
- партнёрский CDN Selectel был недоступен глобально;
- доступ к ресурсам за Cloudflare ухудшился только из части подсетей Selectel;
- на ММТС-9 отдельно сообщалось о перебоях электропитания.
Без общего постмортема их нельзя автоматически считать одной аварией или неисправностью облачных серверов Selectel.
Как интерпретировать длительность
Запись status-панели может оставаться открытой после частичного восстановления или во время наблюдения. Особенно это относится к подсети VDS, событию DPI-фильтрации, IPMI и проблемам внешних партнёров. Указанная длительность — время между созданием и закрытием записи, а не гарантированное непрерывное отсутствие сервиса у каждого клиента.
Практический вывод
- проверять сервис через несколько операторов и регионов;
- собирать
mtrилиtracerouteв обе стороны; - не смешивать доступность виртуальной машины, внешнего маршрута, панели управления и CDN;
- для критичного S3, Container Registry или CDN иметь резервный endpoint или план переноса;
- для Veeam и других backup-сервисов мониторить успешность каждого задания, а не только доступность VM;
- периодически выполнять реальный restore-test;
- иметь независимую копию критичных данных вне основного production-контура;
- учитывать открытую status-панель как плюс к прозрачности, а не как автоматический минус к рейтингу;
- для облачных пулов распределять нагрузку между зонами и хранить бэкап вне провайдера.