Инциденты Selectel в 2026 году

• Карточка Selectel
• Все инциденты 2026 года
• Официальная история событий

3 октября 2026 года повторно прочитаны карточка DNS № 401606 и текущая status-панель. В карточке уже опубликован Resolved 2 октября в 13:25 МСК, а компонент DNS-hosting на общей панели доступен. Таблица и подробное описание ниже синхронизированы; прежний snapshot от 2 октября не является актуальным статусом. Создание VDS в Москве и новых MKS ru-3 по-прежнему ограничено. Это выборочная проверка, не переаттестация всего журнала.

2 октября 2026 года в прочитанном тогда представлении status-панели DNS-инцидент от 30 сентября оставался в Issue: Selectel предупреждал о возможной недоступности добавления и редактирования записей, но не заявлял отказ разрешения существующих зон. Ограничения создания VDS в Москве и новых MKS ru-3 также оставались текущими. Этот исторический snapshot уточнён повторным чтением 3 октября: финальное сообщение DNS датировано 2 октября, 13:25 МСК.

1 октября 2026 года добавлено открытое сообщение DNS-хостинга от 30 сентября: затруднены добавление и редактирование записей, не подтверждён отказ DNS-разрешения. Компонент AI Router на общей панели уже доступен; точное время закрытия его отдельной записи не подтверждено. Создание VDS в Москве и MKS ru-3 остаётся ограниченным. Отдельно добавлено объявление сетевых работ ru-2 5 октября. Это выборочная проверка; исторические даты ниже сохранены.

30 сентября 2026 года выборочно проверены S3 ru-1, новый инцидент интерфейса AI Router и две записи provisioning. S3 объявлен восстановленным 28 сентября в 16:15 МСК. AI Router от 29 сентября, создание VDS в Москве от 27 сентября и создание MKS ru-3 от 7 сентября остаются в текущих сообщениях общей панели. Обещанный срок восстановления AI Router не принят за фактический финал. Это проверка отдельных записей, не всего журнала; прежние даты ниже сохранены.

28 сентября 2026 года повторно проверена общая status-панель. Ошибки создания VDS в Москве из-за временного отсутствия свободных хостов, опубликованные 27 сентября в 18:32 МСК, остаются текущим Minor incident; Selectel предлагает временно использовать Санкт-Петербург или Cloud Servers. Проблема создания новых MKS-кластеров в ru-3, опубликованная ещё 7 сентября, также остаётся текущей; существующие кластеры провайдер заявляет работающими штатно. Отдельно 28 сентября в 14:20 МСК открыт Major incident сетевой доступности S3 в ru-1; Selectel сообщает, что содержимое контейнеров не затронуто. Это текущие статусы на момент проверки, а не итоговая длительность.

26 сентября 2026 года добавлены сетевой Major и дефицит ёмкости VDS 24 сентября, недоступность панели 25 сентября и отчётность AI-router 25–26 сентября. AI-router уже объявлен восстановленным на общей панели; отстающее представление отдельной карточки отмечено ниже. Остальные исторические статусы не переаттестованы.

22 сентября 2026 года добавлено уже закрытое событие доставки писем в Mail.ru за 21–22 сентября. Остальные записи сохраняют прежние даты проверки.

21 сентября 2026 года добавлено закрытое сообщение о создании VDS в ru-7a от 20 сентября и выборочно сверены четыре незакрытые записи. Источник нового VDS-события — блок прошедших инцидентов общей status-панели; отдельную карточку прочитать не удалось. Старые даты проверок ниже сохранены как история, не заменены массово на 21 сентября.

19 сентября 2026 года добавлен подтверждённый инцидент доступности ресурсов kz-1 за 16–17 сентября. Проверена отдельная официальная карточка; статусы прежних событий этим дополнением не переаттестованы.

17 сентября 2026 года добавлена проверка отдельного MKS-инцидента от 15 сентября в kz-1, ke-1, ru-1, ru-8: в карточке опубликован Resolved. При повторном чтении карточки iOS Mobile Farm по-прежнему отображалось только сообщение Issue; отсутствие финального update не превращено в измеренный непрерывный простой. Более ранние статусы сохраняют свои даты проверки.

15 сентября 2026 года выборочно проверен инцидент iOS Mobile Farm от 14 сентября: карточка остаётся в Issue, финального сообщения о восстановлении нет. Статусы других событий этим дополнением не переаттестованы.

Выборочное дополнение сети ru-3 / ru-9 и сайта за 12–13 сентября проверено 14 сентября 2026 года. Предыдущая выборочная проверка KVM, MKS и сетевого окна VMware — 10 сентября; внешней связности и других окон — 7 сентября, дополнение MKS — 8 сентября. Более ранняя хронология и даты её проверок сохранены; это не полная повторная проверка всех событий.

Краткий вывод

У Selectel одна из наиболее подробных публичных status-панелей среди провайдеров в подборке. Поэтому событий видно больше, чем у компаний без открытой истории.

В журнале важно разделять:

• data plane уже работающих ресурсов;
• provisioning новых ресурсов;
• API и панель управления;
• локальные события Bare Metal и сетей конкретного ЦОД;
• отдельные сервисы S3, DNS, Container Registry, Kubernetes и CDN;
• сторонние продукты резервного копирования;
• внешнюю связанность;
• плановые работы и реальные аварии;
• время жизни записи и фактическое окно воздействия.

12 сентября опубликованы две отдельные карточки деградации сети ru-3 / ru-9. В вечернем Major связность объявлена восстановленной через шесть минут после первого сообщения, но запись закрыта только 13 сентября после monitoring. Это дополнительный сигнал повторяемости сети, не доказательство семнадцатичасового непрерывного outage. Техническая связь с событием 1–2 сентября не установлена.

7 сентября в 13:28 МСК опубликовано сообщение о проблемах создания Managed Kubernetes в ru-3a, ru-3b, ru-3c. На повторную проверку 3 октября оно остаётся в текущих инцидентах со статусом Issue. По сообщению Selectel, уже созданные и запущенные кластеры работают штатно.

Storage-инцидент universal.ru-7b закрыт 5 сентября. Восстановление KVM-консолей части dedicated servers с AMI BIOS объявлено завершённым 8 сентября в 16:43 МСК.

Отдельно 5 сентября закрыта проблема создания VDS в ru-7b. Это provisioning, а не подтверждённая недоступность уже работающих серверов. Совпадение времени её начала с закрытием storage-записи не устанавливает общую причину.

Major-инцидент сети ru-3 и ru-9 1–2 сентября хранится отдельно от volumes, provisioning и out-of-band KVM.

Крупные и свежие события

Дата	Сервис или уровень	Что произошло	Статус	Источник
30 сентября, 15:36 — 2 октября, 13:25 МСК	DNS-хостинг; Minor	Могли быть недоступны добавление и редактирование DNS-записей	Resolved 2 октября, 13:25 МСК; проверено 3 октября. 1 д 21 ч 49 мин между сообщениями — не измеренный простой каждого домена; отказ DNS-разрешения не заявлен	№ 401606
29 сентября, 14:18 МСК — первое сообщение	Интерфейс AI Router; Minor	Сообщалось о недоступности интерфейса; создание роутера и API-ключа, а также model API заявлялись работающими	На проверку 1 октября компонент на общей панели доступен; финальный статус отдельной карточки и точное время восстановления не подтверждены	Общая панель · Ссылка на № 401313
28 сентября, 14:20–16:15 МСК	S3, ru-1a / ru-1b / ru-1c; Major	Трудности сетевой доступности S3; содержимое контейнеров заявлено незатронутым	Resolved 16:15 МСК; 1 ч 55 мин между сообщениями, не измерение простоя каждого клиента	№ 401112
с 27 сентября, 18:32 МСК	VDS, Москва / provisioning; Minor	Ошибки создания из-за временного отсутствия свободных хостов	На проверку 3 октября Issue; временно предложены Санкт-Петербург или Cloud Servers	№ 400894 · Текущие сообщения
с 7 сентября, 13:28 МСК	Managed Kubernetes / provisioning, ru-3a, ru-3b, ru-3c; Minor	Затруднено создание новых кластеров MKS	На проверку 3 октября Issue; существующие кластеры заявлены работающими штатно	№ 396842 · Текущие сообщения
25–26 сентября	AI-router / отчётность; Minor	Недоступна вкладка Overview, детальный отчёт мог содержать неполные данные; API и начисления заявлены штатными	Resolved 26 сентября, 13:38 МСК по общей панели; отдельная карточка при чтении отставала	№ 400439 · Финальное сообщение
25 сентября	my.selectel, панель управления; Major	Недоступность панели	Сообщения 16:27–17:02 МСК, 35 минут между ними; шапка карточки показывает 38 минут	№ 400541
24 сентября	VDS, Москва / provisioning; Minor	Ошибки создания из-за временного отсутствия свободных хостов	Resolved 13:06 после сообщения 12:35 МСК; 31 минута между сообщениями	№ 400300
24 сентября	Московская сеть Bare Metal, Cloud Platform и VMware; Major	Частичная недоступность ресурсов	Issue 00:51, восстановление / Monitoring 01:45, Resolved 04:11 МСК; monitoring не равен downtime	№ 400159
21–22 сентября	Доставка писем в Mail.ru; Interfaces / Control Panel / Billing / Website	Проблема доставки писем	Resolved: сообщение 22 сентября, 15:24 МСК; точный интервал воздействия не установлен	Общая status-панель · № 399573
20 сентября, отображаемая отметка 21:56 МСК	VDS / provisioning, Москва, ru-7a; Minor	Затруднения при создании VDS	В блоке прошедших инцидентов Resolved; начало воздействия, точная длительность и причина не установлены	Общая status-панель · Ссылка на карточку № 399355
16–17 сентября	Cloud Platform, kz-1a, Network; Minor	Много обращений по недоступности ресурсов kz-1	Issue 16 сентября 22:39, Resolved 17 сентября 08:37 МСК; 9 ч 58 мин — жизнь записи, не измеренный downtime каждого ресурса	Карточка № 398594
15 сентября	MKS provisioning, ru-1a, ru-1b, ru-1c, kz-1a, ke-1a, ru-8a	Не создавались новые кластеры; существующие заявлены работающими штатно	Issue 14:47, Resolved 15:51 МСК. Шапка показывает 1 ч 49 мин, разность update-времён — 64 мин; расхождение не устранено предположением	Карточка № 398351
с 14 сентября, сообщение в 11:23 МСК	Mobile Farm / iOS, Minor	Проблемы взаимодействия с iOS-устройствами могут приводить к их недоступности	На проверку 15 сентября Issue; время восстановления и итоговая длительность не опубликованы. Не подтверждает сбой VM/VDS или всех устройств фермы	Карточка № 398048
12–13 сентября	Внешняя сеть Cloud Platform, ru-3a, ru-3b, ru-3c, ru-9a	Вечерний Major: повторная деградация сети	Первое сообщение 12 сентября 20:29 МСК; связность восстановлена в 20:35; Resolved 13 сентября 13:26. Отображаемые 17 часов включают monitoring	Карточка № 397799
12 сентября	Внешняя сеть Cloud Platform, ru-3a, ru-3b, ru-3c, ru-9a	Отдельный более ранний Minor: деградация сети	В шапке 07:28 МСК и 37 минут; в доступном update 11:59 — Monitoring, проблема решена. Точное время восстановления из этого update не следует	Карточка № 397778
5 сентября, 14:55–16:08 МСК	VDS / provisioning, ru-7b	Затруднено создание новых VDS	Устранено; окно записи — 1 ч 13 мин; остановка существующих VDS не заявлена	Status-панель
2–8 сентября	Dedicated Servers / KVM / AMI BIOS	Нестабильно работали KVM-консоли части выделенных серверов	Восстановление объявлено 8 сентября в 16:43 МСК; разность отметок — 6 д 1 ч 8 мин, не downtime самих серверов	Карточка · Обновление status-панели
1–2 сентября	Cloud Platform, ru-3a, ru-3b, ru-3c, ru-9a / Network	Наблюдались потери связности; панель могла возвращать HTTP 500 и 503	Проблема локализована в 00:01 и закрыта 2 сентября в 00:35 МСК; окно записи — 2 ч 25 мин	Status-панель
31 августа — 5 сентября	Network Volumes, universal.ru-7b	Деградация производительности сетевых дисков	Закрыто 5 сентября в 14:55 МСК; панель указывает 4 д 20 ч 30 мин; технического RCA нет	Status-панель
26 августа, 15:25 МСК	Managed Kubernetes / provisioning	Возникли проблемы с созданием новых кластеров во многих российских и зарубежных пулах	Устранено в 16:50 МСК; существующие кластеры, по сообщению Selectel, продолжали полноценно работать; окно записи — 1 ч 25 мин	Status-панель
26 августа, 12:00 МСК	Официальный сайт / interfaces	Возникли проблемы доступности selectel.ru	Устранено в 13:07 МСК; окно записи — 1 ч 7 мин; нет подтверждения влияния на data plane	Status-панель
25 августа, 09:12 МСК	MSK-4, Bare Metal / Dedicated Servers / Colocation / Racks / Network	Частичная недоступность серверов в локации MSK-4	Устранено в 10:00 МСК; официальная длительность записи — 48 минут	Status-панель
21–24 августа	Интерфейсы / сайт и панель	Возникли проблемы доступности selectel.ru и my.selectel.ru	Устранено 24 августа в 15:39 МСК; запись была открыта 3 дня 3 ч 10 мин, что не обязательно равно непрерывному простою	Status-панель
19 августа, 13:29 МСК	Veeam VAC / резервное копирование	Стала недоступна консоль управления; могли возникать проблемы с запланированными backup jobs	Устранено через 18 минут; после восстановления задания работали штатно	Status-панель
18 августа, 21:21 МСК	CDN	Глобальная недоступность CDN и ошибки 500; партнёр сообщил об аварии в дата-центре и падении аплинков	Устранено, запись длилась 1 ч 32 мин	Status-панель
с 18 августа, 21:02 МСК	Внешняя сеть / Cloudflare	Из части подсетей Selectel недоступны некоторые ресурсы за Cloudflare; теряются пакеты при TLS-сессиях на магистральных узлах	На проверку 7 сентября Issue; финальной причины и длительности нет	Status-панель
17–18 августа	Veeam Cloud Connect / Veeam Agent	Проблемы с Cloud Repository и Agent-Based Backup	Устранено 18 августа в 12:23 МСК; запись длилась 1 день 2 ч 59 мин	Status-панель
с 15 августа	Внешняя сеть / Hetzner	Нарушилась связность с Hetzner	Связность восстановлена перемаршрутизацией; на проверку 7 сентября Monitoring до устранения внешней аварии	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	Часть пользователей не могла открыть панель и отдельные ресурсы; предполагалось влияние внешних правил DPI	Запись закрыта через 1 день 4 ч 47 мин; внутренняя сеть и DNS были исключены как причина	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-панель

Короткие локальные события

Дата	Сервис	Воздействие	Источник
13 сентября	selectel.ru, официальный сайт	Resolved в 10:13 МСК после сообщения 09:24; панель показывает 48 минут, разность отметок — 49 минут. Не подтверждает отказ VM или API	Карточка № 397888
9 апреля	S3 ru-7	Ошибка сертификата или доступности endpoint S3	Status-панель
25 марта	S3 ru-7	Бакеты не открывались в панели, ссылки могли быть недоступны	Status-панель
11 января	Cloud Platform ru-7a	Не создавались ВМ с публичными IP-адресами	Status-панель
6 января	S3 gis-1	Нарушение доступности объектного хранилища	Status-панель

30 сентября — 2 октября — изменение DNS-записей

Карточка № 401606, повторно прочитанная 3 октября, содержит первое сообщение 30 сентября 2026 года в 15:36 МСК и Resolved 2 октября в 13:25 МСК. Между сообщениями — 1 день 21 час 49 минут, как и в шапке карточки. На текущей общей панели DNS-hosting уже отмечен Operational. Это уточняет прежнее представление от 2 октября с одним Issue; дата проверки не подменяет дату восстановления.

Сообщение касалось добавления и редактирования DNS-записей. Недоступность разрешения существующих зон, потеря записей и техническая причина не заявлены. Время жизни записи не является измерением одинакового простоя каждого домена; собственные проверки операций и DNS-ответов не выполнялись.

Такое ограничение может помешать переключению DNS при миграции или аварии, даже если текущие ответы DNS продолжают работать. Проверяйте изменение записей отдельно от DNS-разрешения; не меняйте production-зону ради теста. Категория «Рекомендую» сохраняется с прежними оговорками. Плановые работы ru-2 5 октября ниже и график отключения legacy DNS — отдельные события, не установленные причины этого сбоя.

28 сентября — 1 октября — S3, интерфейс AI Router и provisioning

Карточка S3 № 401112 содержит Issue 28 сентября в 14:20 МСК и Resolved в 16:15 МСК. Уровень — Major, затронуты S3 ru-1a/b/c. Между сообщениями — 1 ч 55 мин, как и в шапке карточки. Selectel заявил, что содержимое контейнеров не затронуто; собственная проверка объектов не выполнялась. Запись больше не обозначается текущей, но закрытие не подменяет измерения доступности конкретного бакета.

29 сентября в 14:18 МСК опубликовано отдельное сообщение об интерфейсе AI Router. При проверке 30 сентября общая панель сохраняла его в Issue: интерфейс недоступен, но создание роутера, получение нового API-ключа и обработка запросов к моделям заявлены работающими. 1 октября компонент «ИИ-роутер» на общей панели уже отмечен как доступный и сообщение отсутствует в текущем списке. Отдельная карточка № 401313 по-прежнему не загрузилась: финальный статус самой карточки и точное время восстановления не подтверждены. Поэтому не подставляем прежний ETA 30 сентября, 01:00 МСК как время закрытия и не рассчитываем длительность. Это не продолжение закрытой записи 25–26 сентября без подтверждения общей причины и не доказательство остановки model API.

На повторную проверку 3 октября текущая общая панель по-прежнему перечисляет создание VDS в Москве (№ 400894) и новых MKS ru-3 (№ 396842) как ограниченные. Длительность жизни открытых записей не приравнивается к остановке существующих серверов или кластеров. Категория «Рекомендую» сохранена с прежним флагом пересмотра; для аварийного развёртывания нужно оценивать доступную ёмкость отдельно от работающего приложения. Другие инциденты и результаты плановых работ этим дополнением не переаттестованы.

24–26 сентября — сеть Москвы, ёмкость VDS, панель и AI-router

Источники выборочно проверены 26 сентября. Это четыре разных события, не одна непрерывная авария.

24 сентября — частичная недоступность московских ресурсов

Карточка № 400159 перечисляет сеть Bare Metal MSK-1/2/3, Cloud Platform ru-2a/b/c, ru-6a/b/c, ru-7a/b и VMware Cloud. Между сообщением 00:51 МСК и объявленным восстановлением 01:45 — 54 минуты; финальное закрытие — 04:11. Интервал до закрытия составляет 3 ч 20 мин, а шапка показывает 3 ч 22 мин. Причина расхождения не установлена. Ни одна из этих величин не измеряет одинаковый простой каждого ресурса; после 01:45 шло наблюдение. Технический RCA и подтверждённая связь с плановыми работами в прочитанной карточке отсутствуют.

24 сентября — нехватка хостов для новых VDS

Отдельная запись № 400300 сообщает о недостатке свободных хостов, а не об остановке уже созданных VDS. Окно сообщений — 12:35–13:06 МСК. До восстановления провайдер предлагал Санкт-Петербург или облачные серверы как альтернативу. Это не доказательство общей причины с ночным сетевым Major. Проверяйте возможность аварийного создания ресурса отдельно от доступности работающей VM; не удаляйте её ради проверки provisioning.

25 сентября — панель my.selectel

Запись № 400541 относится к Interfaces / Control Panel. Между Issue 16:27 и Resolved 17:02 МСК — 35 минут, тогда как шапка показывает 38 минут; оба значения сохранены без догадки о причине. Недоступность интерфейса затрудняет управление, но карточка не подтверждает отказ всех VM или public API. Для аварийного плана заранее проверяйте отдельный канал управления, а не предполагайте его работоспособность во время сбоя.

25–26 сентября — отчётность AI-router

Первое сообщение № 400439 опубликовано 25 сентября в 03:07 МСК: проблема затронула Overview и полноту выгружаемого отчёта. API и корректность начислений провайдер объявлял незатронутыми. ETA сначала составлял 15:00, затем был перенесён на 22:00 того же дня.

При проверке 26 сентября общая панель уже содержит Resolved 13:38 МСК. Отдельная карточка в доступном представлении ещё показывает старый update и счётчик: финальный статус указан по более позднему сообщению общей панели. После восстановления стоит заново выгрузить отчёт и сверить месячный итог с собственными записями; эти проверки нами не выполнялись. Сбой отчётности не объявляется ошибкой списаний или простоем model API.

Категория «Рекомендую» сохранена с флагом пересмотра сети и provisioning. Широкий московский Major усиливает основание для отдельной оценки по регионам; закрытие карточек не стирает историю. Не складывайте время network, UI и отчётности в общий downtime. Новые окна обслуживания находятся в сентябрьском материале.

21–22 сентября — доставка писем в Mail.ru

В истории Selectel событие датировано 21 сентября. При проверке 22 сентября общая панель уже показывает Resolved с отметкой 15:24 МСК и сообщает о штатной отправке писем на домены Mail.ru. В компонентах указаны Interfaces / Control Panel / Billing / Website, не клиентские VDS. Отдельная карточка № 399573 не загрузилась; точное начало воздействия, причина и длительность не установлены.

Не распространяем событие на весь SMTP клиентов или весь почтовый сервис Selectel. При задержке важного уведомления проверьте кабинет и ответ поддержки; не полагайтесь только на получение письма. Категория «Рекомендую» сохранена. Новые окна API и S3 записаны отдельно в сентябрьском обслуживании.

20 сентября — создание VDS в Москве, ru-7a

При проверке 21 сентября общая status-панель показывает в прошедших инцидентах сообщение «Затруднения при создании VDS в Московском регионе» с отметкой 20 сентября, 21:56 МСК, уровнем Minor и статусом Resolved. Перечислены Cloud Platform / ru-7a / VDS by Selectel / Moscow; в тексте сообщено об устранении проблемы.

Панель ведёт на карточку № 399355, но отдельная загрузка этой карточки при подготовке материала не удалась. Поэтому используются только прочитанные сведения общей панели: 21:56 не выдано за независимо установленное начало сбоя, причина, точный интервал воздействия и охват клиентов не реконструируются.

Это создание новых VDS, не подтверждённая остановка уже работающих серверов. Событие добавляет сигнал повторяемости provisioning, но не доказывает общую причину со сбоем VDS ru-7b 5 сентября, storage или MKS. Для проверки восстановления нужен отдельный тестовый ресурс с лимитом расходов; удалять production-VDS ради повторного создания нельзя. Категория «Рекомендую» сохраняется с прежним флагом пересмотра provisioning и сети.

Незакрытые записи: выборочная проверка 21 сентября

Статусы сверены по текущим сообщениям общей панели и доступным отдельным карточкам. Это повторная проверка прежних событий, не четыре новые аварии 21 сентября.

Начальная дата события	Сервис	Статус в прочитанных источниках	Ссылка
14 сентября	Mobile Farm, iOS	Issue; финального восстановления не опубликовано	№ 398048
7 сентября	MKS ru-3	Issue; проблема создания новых кластеров, существующие заявлены работающими	№ 396842
18 августа	Внешние ресурсы за Cloudflare	Issue; выборочная связность из части подсетей, не отказ всех ресурсов Selectel	№ 393251
15 августа	Связность с Hetzner	Monitoring; связность объявлена восстановленной перемаршрутизацией	№ 392429

Возраст записи не равен непрерывному простою. Для незакрытых событий финальную длительность не считаем; наличие Monitoring не отменяет уже опубликованное восстановление связи. Собственные проверки устройств, кластеров, сети и VDS в рамках дополнения не выполнялись; остальные исторические статусы сохраняют прежние даты проверки.

16–17 сентября — доступность ресурсов kz-1

Официальная карточка № 398594, проверенная 19 сентября, относится к Cloud Platform / kz-1a / Network, уровень — Minor. Первое сообщение о большом числе обращений опубликовано 16 сентября в 22:39 МСК. В 08:37 МСК 17 сентября Selectel объявил проблему устранённой и ресурсы доступными штатно.

Указанные 9 часов 58 минут совпадают с интервалом сообщений, но не доказывают одинаковый непрерывный простой каждого сервера. Причина, полный охват клиентов и результаты проверки их данных в карточке не опубликованы. Это отдельный инцидент доступности, а не продолжение MKS provisioning 15 сентября; связь с прежними L3VPN-работами также не установлена.

Для оценки Казахстана сохраните внешние пробы конкретного ресурса, ошибки приложения и ответ поддержки; резерв проверяйте вне той же сетевой зависимости. Категория «Рекомендую» сохраняется с существующим флагом пересмотра: событие kz-1 нужно учитывать отдельно по региону, не приписывая его всем площадкам. Эксплуатационные тесты в рамках этого дополнения не выполнялись.

15 сентября — создание MKS в kz-1, ke-1, ru-1 и ru-8

Карточка № 398351 перечисляет ru-1a, ru-1b, ru-1c, kz-1a, ke-1a, ru-8a. Сообщение Issue опубликовано 15 сентября в 14:47 МСК, Resolved — в 15:51 МСК: создание новых ресурсов объявлено доступным во всех пулах. Ранее созданные кластеры, по сообщению Selectel, продолжали штатную работу.

Шапка карточки показывает 1 час 49 минут, а между опубликованными update-временами — 64 минуты. Причина расхождения не установлена; ни одно значение не выдаётся за измеренный простой каждого workload. Проверка карточки — 17 сентября.

Событие добавляет ещё один случай MKS provisioning после 26 августа и 7 сентября, но не доказывает общую техническую причину. Для аварийного развёртывания проверяйте создание ресурсов отдельно от health-check работающего приложения, ограничивайте retry и не удаляйте production-кластер ради теста. Категория «Рекомендую» сохраняется с ранее установленным флагом переоценки.

14 сентября — частичная недоступность iOS Mobile Farm

Карточка № 398048 опубликована 14 сентября 2026 года в 11:23 МСК, уровень — Minor incident. Selectel сообщает о проблемах взаимодействия с iOS-устройствами, которые могут приводить к их недоступности.

На проверку 15 сентября статус — Issue. В прочитанной карточке нет сообщения о восстановлении, технической причины, полного перечня затронутых устройств или итоговой длительности. Время публикации не является независимо измеренным началом воздействия; растущий счётчик карточки не доказывает непрерывный простой каждого устройства.

Это отдельный сервис тестирования, а не подтверждение недоступности Android-устройств, VM/VDS или сети всего облака. Причинная связь с сетевыми событиями 12 сентября и плановым обслуживанием фермы 7 сентября не установлена.

Для CI и ручного тестирования фиксируйте устройство, время, идентификатор сессии и ошибку без секретов; отличайте недоступность стенда от падения теста приложения. Ограничьте автоматические повторы и используйте независимый тестовый стенд для критичного релиза. После официального восстановления проверьте подключение и контрольный сценарий на нужном iOS-устройстве, затем обновите статус записи. Эти проверки не выполнялись в рамках подготовки материала.

Категория Selectel «Рекомендую» сохраняется: отдельный сбой Mobile Farm учитывается по сервису и не заменяет оценку надёжности VPS и облачной сети.

12–13 сентября — повторная деградация сети ru-3 / ru-9

Обе карточки перечисляют ru-3a, ru-3b, ru-3c, ru-9a и внешний сетевой слой. Они сохраняются раздельно, а не превращаются в одно непрерывное событие.

Более ранний Minor, № 397778

В карточке начало указано 12 сентября, 07:28 МСК, отображаемая длительность — 37 минут. Доступное сообщение в 11:59 МСК говорит, что проблема решена, и имеет статус Monitoring.

11:59 — время обновления, а не начало сбоя. Разность отметок 07:28–11:59 не равна указанным 37 минутам; по этому сообщению нельзя восстановить точное время устранения или финального закрытия. Не вычисляем предполагаемое восстановление сложением 07:28 и 37 минут.

Вечерний Major, № 397799

Отдельная карточка содержит три этапа:

Время, МСК	Сообщение
12 сентября, 20:29	Опубликовано сообщение о повторной деградации сети
12 сентября, 20:35	Связность восстановлена, продолжается наблюдение
13 сентября, 13:26	Resolved

Между первым сообщением и восстановлением — 6 минут. Это интервал опубликованных сообщений, не независимо измеренная длительность воздействия на каждого клиента. Жизнь записи по временным отметкам — 16 ч 57 мин, панель отображает 17 часов; большая часть этого периода прошла после восстановления в monitoring.

В прочитанных сообщениях нет технической причины и подтверждения общей причины с событием 1–2 сентября. Формулировка «повторная» подтверждает повторяемость сетевой проблемы, но не позволяет объединить network, storage и MKS provisioning в одну аварию.

Для собственной оценки сохраните внешний HTTP/TCP-мониторинг по каждому пулу, ошибки приложений и временную шкалу переподключений. Проверяйте независимость резервной площадки и способность клиента восстановить соединение; не используйте время жизни карточки как готовую метрику SLA приложения.

Отдельный сайт 13 сентября

Инцидент selectel.ru относится к Interfaces / Website: сообщение 09:24 МСК, Resolved 10:13 МСК. Панель указывает 48 минут, разность опубликованных отметок — 49 минут. Причина минутного расхождения не установлена; оба значения сохранены без подмены одного другим.

Это не подтверждение недоступности my.selectel.ru, public API или пользовательских VM. Не складывайте его длительность с сетевыми событиями.

Новые плановые работы ru-3 и VMware 17 сентября записаны отдельно в сентябрьских изменениях Selectel. Они не объявлены причиной этих инцидентов.

7 сентября — создание MKS в ru-3

Официальная status-панель показывает сообщение от 7 сентября 2026 года, 13:28 МСК о затруднениях развёртывания новых кластеров Managed Kubernetes Service в ru-3. В компонентах перечислены ru-3a, ru-3b, ru-3c; уровень события — Minor incident.

На повторную проверку 3 октября сообщение находится в разделе текущих инцидентов со статусом Issue; оно уже было открыто при проверках 10 и 30 сентября. В доступном сообщении нет финального времени восстановления и технической причины. Время публикации не следует выдавать за независимо измеренный момент начала воздействия; итоговую длительность до закрытия не рассчитываем.

Это сбой создания новых ресурсов, а не подтверждённая остановка приложений: Selectel отдельно сообщает о штатной работе ранее созданных и запущенных кластеров. Влияние на масштабирование существующих node groups из этого сообщения не следует — такую операцию нужно проверять отдельно.

Инцидент 26 августа также касался создания Managed Kubernetes, но имел более широкий охват и был закрыт через 85 минут. Повторяется класс проблемы, однако это не доказывает общую причину. Сетевой сбой ru-3 / ru-9 1–2 сентября, VDS ru-7b и MKS 7 сентября остаются отдельными событиями.

Практические проверки

• Разделяйте мониторинг работающего приложения, Kubernetes API и создания нового кластера: успешный HTTP health-check не проверяет provisioning.
• Сохраняйте время, пул, идентификатор операции и ошибку API/CI без токенов и kubeconfig. После timeout сначала выясните, создан ли ресурс, прежде чем повторять запрос.
• Не удаляйте работающий production-кластер для проверки повторного создания. Контрольный запуск проводите только в отдельном тестовом проекте с лимитом расходов и последующим удалением тестовых ресурсов.
• Для аварийного восстановления заранее проверяйте конфигурацию, квоты и доступность альтернативного пула; не рассчитывайте только на создание кластера по требованию во время аварии.
• После официального восстановления добавьте время закрытия и результат тестового создания, а при публикации RCA — причину и корректирующие меры.

Источник события: MKS ru-3, запись № 396842. Текст, время публикации и текущий статус сверены по общей status-панели; запись также присутствует в истории событий.

31 августа — 5 сентября: деградация сетевых дисков ru-7b

Первое сообщение опубликовано 31 августа в 18:24 МСК, финальное Resolved — 5 сентября в 14:55 МСК. Провайдер сообщил о решении проблемы, но на проверку 7 сентября не опубликовал на карточке технический RCA.

Панель показывает длительность 4 дня 20 часов 30 минут. Разность опубликованных времён с точностью до минут составляет 4 дня 20 часов 31 минуту; эти значения сохраняются раздельно, без предположения о причине минутного расхождения.

Источник: карточка Network Volumes.

Время жизни записи не равно доказанному непрерывному простою каждого volume. Не опубликованы одинаковый охват всех дисков и измерения воздействия на каждое приложение. Потеря или повреждение данных не заявлены, но отсутствие такого сообщения не заменяет проверку данных клиента.

Storage-деградация может выглядеть не как полное падение VM, а как:

рост disk latency
    ↓
медленные запросы БД
    ↓
queue и HTTP timeout
    ↓
ошибки приложения при формально доступной VM

На затронутом workload полезно сохранить безопасную диагностику:

iostat -xz 1 30
pidstat -d 1 30
vmstat 1 30
journalctl -k --since '2026-08-31 18:00'
dmesg -T | tail -n 200

Не запускайте разрушающий или тяжёлый fio на production volume во время деградации. Для синтетического теста нужен отдельный тестовый диск, согласованный размер файла и ограничения нагрузки.

После закрытия события стоит проверить:

• latency до, во время и после события;
• пропущенные backup jobs и пригодность restore points;
• состояние БД и очередей;
• filesystem/application errors;
• наличие postmortem или corrective action.

5 сентября — создание VDS в ru-7b

В 14:55 МСК открыта отдельная запись о затруднениях создания VDS. В 16:08 МСК она закрыта; окно — 1 час 13 минут.

Источник: ошибки создания VDS.

Сообщение касается provisioning. Оно не доказывает остановку уже работающих VDS. Начало записи совпадает с опубликованным временем закрытия storage-инцидента, однако официального объяснения причинной связи нет — окна нельзя складывать в один непрерывный outage.

После ошибки создания сначала проверьте, появился ли ресурс в панели/API, и только затем повторяйте запрос: это уменьшает риск дублирующего заказа после timeout.

1–2 сентября — сеть ru-3 и ru-9

Major-инцидент начался 1 сентября в 22:09 МСК. Selectel сообщил о сетевых проблемах Cloud Platform в пулах:

ru-3a ru-3b ru-3c ru-9a

Панель также могла отвечать HTTP 500 и 503. В 00:01 проблему локализовали, а в 00:35 МСК 2 сентября закрыли. Официальное окно записи — 2 часа 25 минут.

В это же время для ru-9 было заранее объявлено плановое окно 1 сентября 21:00 — 2 сентября 01:00. В maintenance notice говорилось, что работа текущих серверов и сервисов не должна была быть затронута.

Нельзя автоматически утверждать, что плановые работы вызвали Major-инцидент:

• авария затронула не только ru-9, но и три пула ru-3;
• в status-записи нет root cause;
• Selectel не опубликовал причинную связь между maintenance и потерями сети.

До появления postmortem эти два события нужно хранить рядом по времени, но не объединять причинно.

2–8 сентября — KVM-консоли выделенных серверов

С 15:35 МСК 2 сентября наблюдались проблемы доступа к KVM-консолям выделенных серверов с AMI BIOS. Selectel сообщил о завершении восстановления 8 сентября в 16:43 МСК в разделе прошедших инцидентов официальной status-панели. Карточка события сохраняется как постоянная ссылка.

Разность опубликованных временных отметок — 6 дней 1 час 8 минут. Это не доказанный непрерывный простой всех консолей и тем более не время остановки dedicated servers. Старые кэшированные представления страницы могут содержать только первоначальное сообщение; финальный статус здесь указан по более позднему официальному обновлению.

Это control/out-of-band layer:

сервер может продолжать работать по сети
    ↓
SSH/RDP доступны
    ↓
но аварийная KVM-консоль недоступна

Риск проявляется при отдельной сетевой или загрузочной проблеме: если SSH уже недоступен, отсутствие KVM увеличивает recovery time.

После объявления восстановления владельцу затронутого dedicated server полезно:

• проверить KVM своего сервера до удалённого изменения bootloader или сетевой конфигурации;
• проверить альтернативный IPMI/KVM access, если он предусмотрен;
• сохранить актуальные контакты поддержки;
• убедиться, что есть внешний backup;
• не считать недоступность KVM доказательством остановки самого сервера.

26 августа — создание Managed Kubernetes clusters

В 15:25 МСК Selectel сообщил о проблемах с созданием новых кластеров Managed Kubernetes.

Status-запись перечисляет пулы:

ru-1a ru-1b ru-1c
ru-2a ru-2b ru-2c
ru-3a ru-3b ru-3c
ru-6a ru-6b ru-6c
ru-7a ru-7b ru-8a ru-9a
uz-1a uz-2a kz-1a ke-1a

В 16:50 МСК provisioning восстановили. Запись длилась 1 час 25 минут.

Ключевое уточнение официального сообщения: существующие кластеры продолжали полноценно работать.

Поэтому событие относится к provisioning/control plane:

создать новый кластер — ошибка
существующий кластер — продолжает работать

Это важно для правильного мониторинга. Успешный health-check существующего workload не проверяет возможность срочно создать новый кластер, а ошибка provisioning не доказывает downtime приложений.

Что проверять

• создание тестового кластера через API;
• масштабирование node groups;
• создание новых node groups;
• доступность Kubernetes API существующего кластера;
• scheduling pods;
• load balancers и public IP;
• Terraform/CI timeout и retry;
• fallback-регион для disaster recovery.

Retry создания инфраструктуры должен быть идемпотентным: слепой повтор после timeout может создать дублирующий ресурс, если первая операция всё же завершилась.

26 августа — selectel.ru

С 12:00 до 13:07 МСК наблюдались проблемы доступности официального сайта selectel.ru.

Status-запись относится к интерфейсам и control panel layer, но не сообщает о недоступности работающих VM, VDS, S3 или Managed Kubernetes.

Необходимо разделять:

• marketing/documentation website;
• панель управления;
• public API;
• data plane пользовательских сервисов.

Недоступность сайта усложняет получение документации и коммуникацию, но не равна падению всего облака.

25 августа — MSK-4

С 09:12 до 10:00 МСК была зафиксирована частичная недоступность серверов в MSK-4.

Затронутые компоненты:

• Bare Metal;
• Dedicated Servers;
• Colocation;
• Racks;
• Network.

Источник не сообщает техническую причину и не указывает, что были затронуты Cloud Platform или VDS во всех московских площадках.

Ближайшие и недавние плановые работы

Плановые работы ниже не являются подтверждёнными авариями. Их нужно использовать для изменения расписания backup/restore, проверки failover и усиленного мониторинга в объявленное окно. Само наступление или окончание окна не подтверждает фактический downtime и результат работ.

5 октября — виртуальные роутеры и Floating IP в ru-2

Объявление опубликовано 30 сентября 2026 года в 17:15 МСК и прочитано 1 октября на общей status-панели. Окно — 5 октября, 20:00–22:00 МСК (22:00 5 октября — 00:00 6 октября по Екатеринбургу, UTC+5). Для части виртуальных роутеров ru-2 и обслуживаемых ими плавающих IP заявлена сетевая недоступность до одной минуты внутри окна. В компонентах перечислены ru-2a, ru-2b, ru-2c.

Это будущие сетевые работы, а не двухчасовая авария и не остановка всех VM региона. Проверьте персональное уведомление в панели, резервный путь и переподключение долгих соединений; после окна сопоставьте внешние пробы. Отдельная карточка при чтении недоступна; источник текста и дат — общая панель. Результат работ заранее не заявляется.

7 сентября — электропитание ru-2c и Мобильная ферма

Окно, МСК	Продукт	Заявленное воздействие	Источник
10:00–14:00	Cloud Platform, ru-2c	Обслуживание электропитания, downtime не заявлен	Уведомление
10:00–20:00	Мобильная ферма	Возможны периодическая недоступность устройств и ограничения аренды новых/отказа от существующих устройств	Уведомление

Оба уведомления опубликованы 27 августа; объявленные окна 7 сентября уже прошли, что само по себе не подтверждает фактический результат работ. Не объединяйте их: обслуживание электропитания облачного пула не объявлено причиной ограничений Мобильной фермы.

9 сентября — пограничные маршрутизаторы Санкт-Петербурга

Окно:

9 сентября 2026, 00:00–06:00 МСК

На время работ объявлялось снижение резервирования услуги BGP-подключения и последовательное отключение BGP-сессий с IPv4- и IPv6-соседями. Окно уже прошло; отдельного подтверждения фактического результата в это дополнение не внесено.

Практически стоит проверить:

• наличие второй BGP-сессии и корректность failover;
• IPv4 и IPv6 отдельно;
• route flap и convergence time;
• внешний мониторинг из нескольких операторов;
• отсутствие статических зависимостей от одного next hop.

В заголовке и календарной карточке status-page указан 2026 год, тогда как в тексте уведомления фигурирует 09.09.2025. В этом журнале используется дата карточки — 9 сентября 2026 года, а расхождение источника зафиксировано явно.

Источник: работы BGP в Санкт-Петербурге.

9 сентября — Veeam Cloud Connect и Agent Backup

Окно:

9 сентября 2026, 10:00–14:00 МСК

Selectel предупреждал, что во время работ будут недоступны:

• Agent Backup;
• Veeam Cloud Connect Repository;
• Veeam Cloud Connect Replication.

Для активных backup, restore и replication sessions было объявлено прерывание. Объявленное окно прошло; по одному календарю нельзя подтвердить успешный результат каждой сессии.

После окна нужно проверить запуск новых заданий, наличие пригодных restore points и незавершённые либо пропущенные задания. Длительные backup/restore jobs при следующих работах следует переносить за пределы maintenance window.

Источник: работы Veeam 9 сентября.

10 сентября — сетевая плоскость VMware в Санкт-Петербурге

В официальном уведомлении, опубликованном 8 сентября в 17:11 МСК, задано окно 10 сентября, 10:00–12:00 МСК. Дата публикации не является началом работ.

Для публичного VMware Cloud в Санкт-Петербурге заявлено снижение резервирования сетевой связности до N+0. Перечислены пулы DUB3 | GOLD-1, DUB3 | SILVER-1 и DUB3 + CVT2 | GOLD-1.

Это отдельное сетевое обслуживание, не то же самое, что работы VMware Backup 10:00–16:00 и L3VPN Казахстана 10:00–17:00. Снижение резервирования не следует записывать как подтверждённый двухчасовой outage. Полезно проверить резервный доступ, поведение долгих соединений и мониторинг из внешней сети; результат фиксировать по фактическим измерениям и финальному уведомлению.

10 сентября — VMware Public Cloud Backup

Окно:

10 сентября 2026, 10:00–16:00 МСК

Сервис VMware Public Cloud Backup будет недоступен во всех регионах. Все активные backup- и restore-сессии будут прерваны.

Перед работами следует:

• завершить длительные restore заранее;
• перенести расписание backup за пределы окна;
• проверить наличие независимой копии критичных данных;
• после 16:00 убедиться, что новые задания запускаются и создают пригодные restore points.

Источник: работы VMware Public Cloud Backup.

10 сентября — глобальные маршрутизаторы Казахстана

Окно:

10 сентября 2026, 10:00–17:00 МСК

Работы относятся к ALM-1, kz-1 и Global Router L3VPN. На всё окно резервирование gateway для L3VPN-сетей во всех пулах Казахстана будет снижено до N+0. Провайдер ожидает два перерыва сервиса продолжительностью до 10 секунд каждый для всех типов L3VPN networks.

Для чувствительных приложений нужно проверить:

• retry и timeout клиентов;
• переподключение БД и message broker;
• поведение long-lived TCP-сессий;
• health checks и failover;
• доступность сервиса из внешнего региона;
• отсутствие deployment или schema migration в окно работ.

Источник: работы Global Router в Казахстане.

11 сентября — пограничные маршрутизаторы Москвы

Окно:

11 сентября 2026, 00:00–06:00 МСК

Во время работ будет снижено резервирование BGP-подключения и последовательно отключаться IPv4- и IPv6-сессии с соседними маршрутизаторами.

Проверки аналогичны Санкт-Петербургу: отдельно контролировать обе IP-версии, route convergence, доступность из нескольких сетей и корректность резервного BGP-пути.

В заголовке и календарной карточке status-page указан 2026 год, а в тексте уведомления — 11.09.2025. В журнале используется дата карточки — 11 сентября 2026 года — с явной отметкой расхождения.

Источник: работы BGP в Москве.

Архив объявленных окон: 1–4 сентября

Selectel объявлял обслуживание управляющих компонентов нескольких регионов с 1 сентября 12:00 до 4 сентября 18:00 МСК без downtime серверов, дисков и сетей. Объявленное окно уже прошло; это не самостоятельное подтверждение фактического результата работ.

Плановые работы не считаются аварией, пока нет подтверждения незапланированного воздействия.

21–24 августа — сайт и панель

21 августа Selectel сообщил о проблемах доступности:

• selectel.ru;
• my.selectel.ru.

24 августа событие было закрыто. Status-панель показывает жизнь записи 3 дня 3 ч 10 мин.

Это не доказывает непрерывную недоступность обоих интерфейсов для каждого клиента всё окно и не является автоматическим downtime data plane.

15 июля — ошибка автоматизации ru-7

В ru-7 произошло два сетевых инцидента: с 14:30 до 14:56 и с 19:30 до 20:11. Воздействие касалось ресурсов с Floating IP.

В постмортеме Selectel сообщил, что ошибка автоматизации удаляла критический интерфейс виртуальных маршрутизаторов. После первого восстановления сценарий повторился вечером.

Отдельная проблема ru-2 того же дня не должна автоматически объединяться с ошибкой маршрутизаторов ru-7.

Veeam и backup jobs

17–19 августа status-панель зафиксировала два разных события:

• Cloud Connect / Agent;
• управляющая консоль Veeam VAC.

Они не доказывают потерю данных, но показывают, что managed backup сам является зависимостью.

backup scheduled
    ↓
job completed successfully
    ↓
copy exists outside production VM
    ↓
restore periodically tested

Мониторить нужно успешность каждого задания, а не только доступность VM и панели.

Внешняя связность Cloudflare и Hetzner

На проверку 7 сентября:

• Cloudflare — открытый Issue; проблемы отдельных внешних ресурсов фиксируются из части подсетей Selectel;
• Hetzner — Monitoring после перемаршрутизации; провайдер ожидает устранения аварии на сторонней европейской площадке.

Это внешняя связанность, а не доказательство неисправности VM или внутренней сети Selectel. Финальную длительность нельзя фиксировать до закрытия записей.

Как интерпретировать длительность

Время жизни status-записи не всегда равно непрерывному простою каждого клиента.

Запись может оставаться открытой:

• после частичного восстановления;
• во время monitoring;
• в ожидании исправления внешнего партнёра;
• до завершения диагностики.

Для открытых событий финальная длительность не публикуется. Отображаемую панелью длительность и разность округлённых временных отметок нужно различать.

Влияние на категорию

Selectel остаётся в категории «Рекомендую», с явным флагом на пересмотр после длительного storage-инцидента и повторных сетевых событий ru-3 / ru-9.

Закрытие события не делает почти пятисуточное окно несущественным. При этом нельзя приписывать одинаковый downtime всем клиентам, суммировать storage и provisioning или считать проблемы KVM падением dedicated servers. Отсутствие заявления о потере данных не является доказательством её невозможности.

Повторно рассмотреть перевод в «Норм» стоит при повторных data-plane сбоях, подтверждённых проблемах целостности данных или неудовлетворительном разборе причин и корректирующих мер. KVM-инцидент закрыт 8 сентября, но сохраняется в истории как пример риска аварийного доступа.

Событие MKS 7 сентября добавляет отдельный сигнал повторяемости сбоев создания кластеров после 26 августа. Его длительность, возможность аварийного развёртывания и подтверждённое влияние на другие операции следует учитывать при следующем пересмотре. Пока сообщение касается только новых кластеров и не подтверждает остановку существующих, категория автоматически не меняется.

События 12 сентября усиливают уже обозначенный сетевой риск. Следующая оценка должна учитывать фактический impact по пулам и RCA, а не сумму времён monitoring. Предстоящие maintenance и новый маркетинговый продукт сами по себе не являются основанием для изменения категории.

Один факт большого числа записей недостаточен для сравнения с провайдерами, которые вообще не публикуют status history. Но прозрачность status-page не должна заменять оценку длительности и реального data-plane impact.

Практический вывод

• проверять сервис через несколько операторов и регионов;
• не смешивать VM, volumes, provisioning, API, панель, KVM, сайт, Bare Metal и CDN;
• мониторить не только workload, но и disk latency и возможность создания/масштабирования ресурсов;
• собирать mtr или traceroute в обе стороны;
• для критичного S3, Registry или CDN иметь резервный endpoint;
• для backup-сервисов проверять завершение job и restore;
• хранить независимую копию данных вне production-контура;
• учитывать planned maintenance отдельно от аварий;
• распределять нагрузку между зонами и иметь резерв вне провайдера;
• не связывать плановые работы ru-9 и Major-инцидент 1 сентября без официальной root cause;
• перед BGP/L3VPN maintenance проверять failover, IPv4/IPv6 и поведение приложений при коротком route flap.

Источники по свежим событиям

• DNS-хостинг: добавление и редактирование записей, 30 сентября — 2 октября
• Текущие статусы AI Router и provisioning; объявление работ ru-2 5 октября
• Создание MKS в kz-1, ke-1, ru-1, ru-8, 15 сентября
• Частичная недоступность iOS Mobile Farm, 14 сентября
• Повторная деградация сети 12–13 сентября, Major
• Более ранняя деградация сети 12 сентября, Minor
• selectel.ru, 13 сентября
• История событий Selectel
• Создание MKS ru-3, 7 сентября
• Status-панель: закрытие KVM и окно сети VMware 10 сентября
• Деградация сетевых дисков universal.ru-7b
• Создание VDS ru-7b, 5 сентября
• Потери связи ru-3 и ru-9
• Проблемы KVM-консолей
• Работы электропитания ru-2c, 7 сентября
• Работы Мобильной фермы, 7 сентября
• Работы BGP в Санкт-Петербурге 9 сентября
• Плановые работы Veeam 9 сентября
• Работы VMware Public Cloud Backup 10 сентября
• Работы Global Router L3VPN в Казахстане 10 сентября
• Работы BGP в Москве 11 сентября
• Плановые работы ru-9, 1–2 сентября
• Managed Kubernetes, 26 августа
• selectel.ru, 26 августа
• MSK-4, 25 августа
• Cloudflare
• Hetzner