Интернет-провайдеры и сетевая инфраструктура — события 2026 года
Интернет-провайдеры и сетевая инфраструктура: события 2026 года
Этот журнал посвящён операторам фиксированного и мобильного доступа, магистральным сетям, маршрутизации, DNS и CDN. Хостинги и облака ведутся отдельно в разделе хостинга.
Дополнено 11 октября 2026 года (Екатеринбург, UTC+5): проверены первичные сообщения TENET за 10–11 октября, включая обновление в 14:27 по часам сайта оператора. Ранние записи АСТ и Ростелекома сохранены с проверкой от 10 октября; новая дата не означает их повторную проверку.
10–11 октября — TENET: повреждение площадки и локальные переключения
Оператор и география: TENET, Одесса, Украина. Приоритет наблюдения: средний. Это событие сети доступа, а не изменение категории хостинг-провайдера.
| Дата события / состояния | Публикация оператора | Что подтверждает источник |
|---|---|---|
| 10 октября 2026; точное время повреждения не указано | 10 октября, 19:29 | Сообщено о повреждении систем охлаждения и энергогенерирующего оборудования технологического комплекса. Оператор предупредил о возможных перебоях у части абонентов и переносе трафика. Первичное уведомление |
| 11 октября, состояние на момент сообщения | 11 октября, 10:43 | На отдельных участках периодически возникает пиковая нагрузка; аварийные и балансировочные работы могут вызывать локальные перерывы. По заявлению компании, общей ёмкости сети достаточно. Уточнение оператора |
| 11 октября, состояние на момент сообщения | 11 октября, 14:27 | Магистрали заявлены работающими; продолжаются локальные переключения, возможны короткие перерывы в центральной части города. Фиксированного графика нет. Дневное обновление |
Время публикаций передано как показано на сайте TENET: явный часовой пояс в прочитанном тексте не указан. Это не московское время и не автоматически установленное время начала аварии; перевод в UTC без проверки часового пояса не выполнялся.
Граница подтверждения. Повреждение инфраструктуры и ход восстановления описаны самим оператором. Число затронутых абонентов, непрерывная длительность простоя каждого подключения и полная недоступность ASN не установлены. Независимые активные измерения и данные BGP для этого случая редакцией не выполнялись и не получены. Заявление о работающих магистралях не означает завершения всех локальных работ или восстановления повреждённой площадки.
Для сайтов. Ошибки у посетителей из затронутой сети могут не совпадать с состоянием сервера. Проверять следует конкретные URL через несколько операторских сетей; причинную связь с изменением индексирования или метрик SEO Recipes здесь не установили. До подтверждения проблемы на origin не стоит переносить сайт или менять DNS только по сообщениям об аварии ISP.
Сообщения за 9–10 октября
АСТ: запланированное обновление сетевого оборудования 9 октября
- Оператор: АСТ; география затронутых абонентов не установлена из уведомления.
- Дата объявления: 30 сентября 2026 года.
- Плановое окно: 9 октября 2026 года, 00:01–01:00 МСК.
- Подтверждено: оператор заранее объявил обновление ПО сетевого оборудования и возможный перерыв связи до 40 минут.
- Не подтверждено: фактический простой, продолжительность, число затронутых абонентов. Указанное окно уже прошло; само объявление не доказывает, что был инцидент.
- Практический вывод: заранее переносить чувствительные к связи операции и сверять уведомления о работах с независимым мониторингом. Для сайтов проверять доступность из нескольких автономных систем, прежде чем относить сбой к серверу.
- Источник: официальное объявление АСТ.
Ростелеком: сообщения абонентов 9–10 октября — не подтверждение общей аварии
- География: сообщения из нескольких регионов РФ; единая причина не установлена.
- Даты публикаций: 9 и 10 октября 2026 года.
- Что известно: СМИ приводят число обращений в пользовательские сервисы мониторинга. Это сообщения абонентов, а не измерение доли недоступных префиксов и не официальное признание оператором массового сетевого инцидента.
- Ограничения: нельзя суммировать показатели разных сервисов, сравнивать неполные и полные сутки или считать все сообщения одной аварией. Независимой проверки через BGP/активные пробы для этих сообщений здесь нет.
- Практический вывод: при жалобах на недоступность сайта проверять статус конкретного региона и оператора, DNS, IPv4/IPv6, HTTP/TLS из разных сетей, а не менять хостинг на основании графика жалоб.
- Источники (вторичные, не подтверждают масштаб): Инфо24, 9 октября, Инфо24, 10 октября.
- Статус: сигнал для наблюдения, не подтверждённая общероссийская авария.
Правила ведения журнала
- Для каждой записи указывать дату события, дату публикации и дату проверки, сохраняя часовой пояс. Дата обновления страницы не означает новое событие.
- Сначала искать подтверждение у оператора/регулятора и в измерительных данных: RIPE RIS, RIPEstat, IODA, Cloudflare Radar, RouteViews. Сами по себе жалобы и графики мониторингов не устанавливают причину.
- Различать доступность сайта, доступность сети оператора, BGP-видимость префиксов и жалобы пользователей — эти показатели не эквивалентны.
- Не объявлять сбой общероссийским без независимого подтверждения географии. Не приписывать отключения DPI, ТСПУ или блокировкам без проверяемых данных.
- Фиксировать тип воздействия: потеря связности, повышенный RTT или loss, DNS, IPv4/IPv6, маршруты/пиринг, тарифы и ограничения. Для каждого указывать практические последствия для сайтов, ботов поиска, мониторинга и аналитики.
- Не создавать отдельные статьи по небольшим локальным жалобам; сначала накапливать датированные наблюдения. По подтверждённым крупным случаям заводить отдельный разбор с измерениями и ограничениями вывода.
Как проверять сетевую проблему сайта
- Сверить часы и окно события в UTC и МСК, затем проверить URL из нескольких провайдерских сетей и регионов.
- Отдельно проверить DNS-ответы, IPv4 и IPv6, TCP/TLS и HTTP-коды; успех на одной сети не доказывает доступность во всех остальных.
- Сопоставить RTT, packet loss, трассировки и маршруты с контрольным периодом. Не принимать один traceroute или ICMP timeout за доказательство сбоя на конкретном узле.
- Если есть BGP-аномалия, зафиксировать ASN, затронутые префиксы и время по нескольким коллекторам; BGP withdrawal не всегда означает полную пользовательскую недоступность.
- Только после проверки влияния на конкретные URL решать, нужны ли изменения CDN/DNS, инфраструктуры или уведомление пользователей. Не запускать автоматические переключения по единичной жалобе.
Карточка воспроизводимого наблюдения
Ниже — редакционный шаблон проверки, а не результаты измерения TENET или SEO Recipes. Проверки выполняет владелец сайта либо уполномоченный оператор с небольшим числом запросов, без нагрузочного тестирования чужих сервисов.
| Поле | Что записать |
|---|---|
| Время | Начало и конец пробы в UTC, часовой пояс исходного уведомления и дата его публикации |
| Точка проверки | Идентификатор пробы, ASN и регион, источник этих сведений; отдельно наличие VPN или прокси |
| Цель | Один и тот же разрешённый URL, метод GET и ожидаемый признак страницы; без токенов в query string |
| DNS | Использованный резолвер, ответы A/AAAA, TTL или точная ошибка; отсутствие AAAA не считать сбоем IPv6 |
| IPv4 / IPv6 | Две отдельные пробы при наличии соответствующих DNS-записей и связности у проверяющего узла |
| TCP / TLS | Подключение, ошибка или тайм-аут, имя SNI и результат проверки сертификата; не отключать TLS-проверку |
| HTTP | Код, цепочка редиректов и ожидаемое содержимое; страница ошибки или входа с кодом 200 не считается успехом |
| Время ответа | DNS, TCP, TLS, TTFB и общее время, версия инструмента, тайм-аут и число повторов |
| Сопоставление | Те же URL из независимых ASN в близком временном окне и контроль до/после события; одинаковый IP CDN не предполагается |
| Вывод | Что наблюдалось, возможные альтернативные причины и что осталось неизвестным |
Отсутствие проверки помечать как «не измерено», а не как «доступно» или нулевое время. Проверка из одной домашней сети не заменяет независимые пробы. Из публичного отчёта исключать cookies, токены, личные адреса абонентов и приватные адреса инфраструктуры; исходные чувствительные логи хранить в закрытом доступе.
Ограничение: это редакционный журнал подтверждённых уведомлений и осторожно отмеченных сигналов, а не сервис онлайн-мониторинга и не рейтинг качества интернет-провайдеров.
