Методика и охват журнала инцидентов за 2026 год
Методика и охват журнала инцидентов за 2026 год
Последняя проверка: 22 августа 2026 года.
Уровни источников
| Уровень | Источник | Как используется |
|---|---|---|
| A | Официальная status-панель, постмортем или сообщение провайдера | Основной источник факта, времени, затронутых сервисов и причины |
| B | Сообщение дата-центра, оператора связи, регулятора или правоохранительного органа | Подтверждает внешний уровень проблемы |
| C | Крупное профильное СМИ, архив status-панели или независимый мониторинг | Используется, когда официальный архив недоступен; ограничение явно указывается |
| D | Форумы, отзывы и сообщения без документов | Не считаются достаточным подтверждением аварии, но могут стать поводом для проверки |
Что проверялось
Проверялись провайдеры из текущего каталога, их официальные 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.
Как отмечается связь бренда с массовым событием
Правоохранительный орган, дата-центр или оператор связи может подтвердить само событие, но не назвать коммерческий бренд, через который клиент покупал услугу.
В таком случае журнал разделяет два утверждения:
- официально подтверждённый факт — например, изъятие оборудования, авария электропитания или отключение стойки;
- атрибуция бренда — сообщение профильного СМИ, клиентов или партнёров о том, какие услуги могли использовать эту инфраструктуру.
Если бренд отсутствует в первичном документе, связь не повышается до уровня A только из-за повторения в нескольких публикациях. В тексте сохраняется оговорка и указывается уровень источника. Именно так оформлено возможное воздействие нидерландского изъятия серверов на клиентов UFO.Hosting.
Когда добавлять новую запись
Инцидент добавляется, если выполняется хотя бы одно условие:
- есть официальный источник;
- событие затронуло несколько клиентов, сервисов или локаций;
- простой был заметен внешним мониторингом и подтверждён поддержкой;
- проблема изменила доступность площадки, тарифов или данных;
- опубликован постмортем, компенсация или план миграции.
Плановые работы отмечаются отдельно и не называются аварией, если провайдер заранее сообщил об окне и уложился в заявленное воздействие.
