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

Ичи31.08.2026Около 13 минОколо 3850 слов

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

Последняя выборочная проверка свежих событий, внешней связности и ближайших окон: 7 сентября 2026 года. Дополнение по созданию MKS в ru-3: 8 сентября 2026 года. Более ранняя хронология сохранена из предыдущих проверок.

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

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

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

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

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

На проверку 7 сентября storage-инцидент universal.ru-7b закрыт. Проблема KVM-консолей части dedicated servers с AMI BIOS остаётся открытой.

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

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

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

Дата	Сервис или уровень	Что произошло	Статус	Источник
с 7 сентября, сообщение в 13:28 МСК	Managed Kubernetes / provisioning, `ru-3a`, `ru-3b`, `ru-3c`	Затруднено создание новых кластеров MKS	На проверку 8 сентября `Issue`; существующие кластеры, по сообщению провайдера, работают штатно; финального времени восстановления нет	Инцидент · Текущие сообщения
5 сентября, 14:55–16:08 МСК	VDS / provisioning, `ru-7b`	Затруднено создание новых VDS	Устранено; окно записи — 1 ч 13 мин; остановка существующих VDS не заявлена	Status-панель
с 2 сентября, 15:35 МСК	Dedicated Servers / KVM / AMI BIOS	Нестабильно работают KVM-консоли части выделенных серверов	На проверку 7 сентября `Issue`; источник локализован, финального сообщения нет	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 мин	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-панель

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

Дата	Сервис	Воздействие	Источник
9 апреля	S3 `ru-7`	Ошибка сертификата или доступности endpoint S3	Status-панель
25 марта	S3 `ru-7`	Бакеты не открывались в панели, ссылки могли быть недоступны	Status-панель
11 января	Cloud Platform `ru-7a`	Не создавались ВМ с публичными IP-адресами	Status-панель
6 января	S3 `gis-1`	Нарушение доступности объектного хранилища	Status-панель

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

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

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

Это сбой создания новых ресурсов, а не подтверждённая остановка приложений: 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 сентября — KVM-консоли выделенных серверов

С 15:35 МСК 2 сентября наблюдаются проблемы доступа к KVM-консолям выделенных серверов с AMI BIOS. Selectel сообщил, что источник проблемы найден и ведётся исправление.

На проверку 7 сентября запись остаётся в Issue; финального срока восстановления нет. Длительность открытой записи не фиксируется как итоговая.

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

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

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

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

не выполнять удалённое изменение bootloader или сетевой конфигурации без recovery plan;
проверить альтернативный 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 и результат работ.

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-подключения. Selectel планирует последовательно отключать 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 будут прерваны.

До окна нужно:

перенести длительные backup/restore jobs;
проверить, что критичная копия завершена заранее;
не запускать replication, которая не успеет закончиться до 10:00;
после работ проверить статус следующего задания и наличие restore point;
отдельно расследовать любой job, который остался Success, хотя сессия фактически была прервана.

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

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-инцидента.

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

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

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

Один факт большого числа записей недостаточен для сравнения с провайдерами, которые вообще не публикуют 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.

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

Описание