Методика и охват журнала инцидентов за 2026 год

• Все инциденты 2026 года
• Провайдеры

Описанный ниже исторический охват проверялся 22 августа 2026 года. 17 сентября методика дополнена правилами учёта личных наблюдений и повторяющихся жалоб; это не новая полная проверка всех провайдеров или старых событий.

Уровни источников

Уровень / тип	Источник	Как используется
A	Официальная status-панель, постмортем или сообщение провайдера	Основной источник заявленных времени, охвата и причины; не заменяет измерение доступности конкретного клиента
B	Сообщение дата-центра, оператора связи, регулятора или правоохранительного органа	Подтверждает внешний уровень проблемы
C	Крупное профильное СМИ, архив status-панели или независимый мониторинг	Указываются ограничения архива или конкретные проверенные адреса, интервалы и точки измерения
D	Форумы, отзывы, комментарии детекторов сбоев и сообщения без документов	Сохраняются как пользовательские сообщения с датой и симптомами; сами по себе не устанавливают причину, общий масштаб или точный uptime
Личный опыт	Наблюдение автора или предоставленные им результаты мониторинга	Подтверждает описанный опыт для наблюдавшихся ресурсов; приблизительная длительность не превращается в точное измерение

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

Короткие сбои и повторяющиеся жалобы

Кратковременная недоступность, задержка выдачи оплаченного сервера, периодические потери пакетов и долгое ожидание поддержки тоже влияют на пригодность хостинга. Журнал не ограничивается крупными авариями из официальных status-панелей.

Для каждого сообщения разделяются:

• дата публикации, дата проверки и время самого события;
• VPS или сервис клиента, сайт хостера, кабинет, API, DNS и выдача нового заказа;
• локация и исходная сеть, если они известны;
• наблюдавшиеся симптомы и предполагаемая причина;
• время восстановления у наблюдателя и официальный статус провайдера.

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

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

Личные наблюдения, пользовательские сообщения, независимые измерения и официальное подтверждение обозначаются отдельно. Они могут описывать одно событие и не суммируются автоматически. Зелёная панель после восстановления, отсутствие новых жалоб или успешное открытие сайта не опровергают прошедший простой клиентского VPS.

Пример такого разделения — журнал HSHP: почти часовая недоступность со слов автора, серия комментариев о VPS и отдельно официальное уведомление об отзыве IPv4.

Охват очередной проверки

Основной список — текущий каталог провайдеров, а не только несколько компаний с удобными status-панелями. Для каждой позиции полезно отдельно отмечать чтение официальных уведомлений и поиск пользовательских сигналов. Успешное чтение продуктового changelog не заменяет проверку аварий.

Результат проверки должен различать «найдено официальное событие», «есть пользовательские сообщения», «есть измерения», «новых сообщений в прочитанном источнике нет» и «источник недоступен / не проверен». Поисковый запрос без результата не считается прочитанным архивом. Только перечисленные реально прочитанные источники можно включать в подтверждённый охват; выборочный проход нельзя называть полной перепроверкой списка.

На страницах детекторов сбоев используются датированные комментарии и конкретные результаты проверок, а не автоматически сгенерированные описания типичных неисправностей. Кэшированная страница и её счётчики не выдаются за live-измерение. При неоднозначном бренде, например Timeweb и Timeweb Cloud или Sprinthost и Sprintbox, принадлежность жалобы конкретному продукту уточняется отдельно.

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

Проверялись провайдеры из текущего каталога, их официальные status-панели, новостные разделы, публичные каналы, сообщения партнёрских дата-центров и крупные события Рунета.

Углублённая проверка 21–22 августа дополнительно охватила отдельные записи и постмортемы:

• Timeweb Cloud — критическую деградацию СХД 9–10 апреля;
• Selectel — облачные пулы, IPMI, Container Registry, сервисы резервного копирования, интерфейсы управления и текущие внешние сетевые события;
• Yandex Cloud — создание ресурсов, Managed Databases, VPC и AI Studio;
• IONOS Cloud — AI Model Hub и provisioning;
• VDSka — отказ силового трансформатора финской площадки;
• сообщения СМИ о возможном воздействии нидерландской операции на клиентов UFO.Hosting.

Наиболее полные публичные журналы в этой проверке обнаружены у:

• Selectel;
• Yandex Cloud;
• IONOS Cloud;
• Timeweb Cloud.

Частичная история или отдельные официальные сообщения найдены у:

• Beget;
• FirstVDS;
• REG.RU;
• Contabo;
• McHost;
• VDSina;
• VDSka.

Для ряда провайдеров из каталога — Cloud.ru, MWS, SpaceWeb, Sprinthost / Sprintbox, Jino, Fornex, AdminVPS, FASTVPS и части небольших VPS-сервисов — удобного публичного архива инцидентов в рамках этой проверки не найдено.

Что означает отсутствие записи

Фраза «публичных подтверждённых инцидентов не найдено» означает только результат текущей проверки. Она не доказывает, что:

• аварий не было;
• поддержка не рассылала уведомления клиентам;
• короткий простой не остался только во внешнем мониторинге;
• событие не было опубликовано в закрытой панели;
• провайдер не удалил старую историю со status-панели.

Если при этом найдены пользовательские сообщения, их следует назвать отдельно: общее «новостей нет» скрывает полезные сведения. Поэтому рейтинг нельзя строить простым подсчётом официальных записей или жалоб.

Классы событий

Status-панели часто смешивают несколько типов operational events. В журнале их нужно разделять.

Incident

Незапланированная деградация или недоступность:

работало
  ↓
возникла проблема
  ↓
диагностика / восстановление

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

Scheduled maintenance

Провайдер заранее объявил окно, ожидаемое воздействие и затронутые сервисы.

Плановые работы не называются аварией, если:

• уведомление опубликовано заранее;
• фактическое воздействие укладывается в заявленное;
• не появилось отдельного незапланированного отказа.

При этом maintenance может быть полезен для практической карточки провайдера: он показывает, какие control plane, backup или network операции могут временно быть недоступны.

Если работы вышли за окно или воздействие оказалось существенно шире обещанного, это уже может стать отдельным incident.

Monitoring

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

Нельзя трактовать всю длительность статуса Monitoring как непрерывный downtime.

External / partner incident

Проблема может находиться за пределами инфраструктуры провайдера:

• магистральный оператор;
• Cloudflare/другая внешняя сеть;
• дата-центр партнёра;
• внешний CDN;
• санкционное решение партнёра.

Журнал сохраняет уровень проблемы и не записывает автоматически внешнюю аварию как отказ собственных ВМ провайдера.

Открытые события

Если incident еще не закрыт:

• записываются доступные время события и время сообщения с источником; при неизвестном начале оно не выводится из даты публикации;
• официальный статус сохраняется как открыт / идёт диагностика / monitoring, а без него пишется «пользователь сообщает о недоступности; официальный статус неизвестен»;
• не публикуется финальная длительность;
• не предполагается причина, которой нет в источнике;
• после сообщения о восстановлении запись нужно перепроверить.

Например, проблемы доступа к selectel.ru и my.selectel.ru, начавшиеся 21 августа, утром 22 августа оставались открыты на status-панели. Поэтому журнал фиксирует факт и scope, но не финальную длительность.

Как учитывать длительность

Время жизни записи на status-панели не всегда равно непрерывному простою. Статус может оставаться открытым во время наблюдения, частичного восстановления или ожидания подтверждения от партнёра. В таблицах это отдельно уточняется, когда источник не позволяет определить чистое время недоступности.

Для открытого события разница между now и временем публикации — только возраст status-записи, а не доказанный downtime.

Как отмечается связь бренда с массовым событием

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

В таком случае журнал разделяет два утверждения:

1. официально подтверждённый факт — например, изъятие оборудования, авария электропитания или отключение стойки;
2. атрибуция бренда — сообщение профильного СМИ, клиентов или партнёров о том, какие услуги могли использовать эту инфраструктуру.

Если бренд отсутствует в первичном документе, связь не повышается до уровня A только из-за повторения в нескольких публикациях. В тексте сохраняется оговорка и указывается уровень источника. Именно так оформлено возможное воздействие нидерландского изъятия серверов на клиентов UFO.Hosting.

Когда добавлять новую запись

Запись с соответствующим типом подтверждения добавляется, если выполняется хотя бы одно условие:

1. есть официальный источник;
2. событие затронуло несколько клиентов, сервисов или локаций;
3. есть независимые измерения с известными проверяемыми ресурсами и временем; ответ поддержки полезен, но не обязателен;
4. проблема изменила доступность площадки, тарифов или данных;
5. опубликован постмортем, компенсация или план миграции;
6. автор непосредственно наблюдал недоступность и сообщил, что именно не работало; точность времени и недостающие параметры отмечаются;
7. найдена серия содержательных пользовательских сообщений о похожих симптомах — она сохраняется как серия сообщений, без выдуманного числа независимых аварий.

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