Инциденты Timeweb Cloud в 2026 году
Инциденты Timeweb Cloud в 2026 году
Последняя проверка: 27 августа 2026 года.
Краткий вывод
В 2026 году у Timeweb Cloud совпали разные классы риска:
- критическая деградация сетевого хранилища;
- крупные DDoS-атаки;
- повторные проблемы охлаждения внешнего дата-центра в Амстердаме;
- потеря связности
de-1из-за аварии промежуточного узла Equinix FR5; - отдельный сетевой сбой оборудования в
ams-125 августа; - кратковременные локальные деградации.
Их нельзя объединять в одну техническую причину. Но европейские локации в августе получили два разных Major-инцидента с интервалом десять дней. Для критичных проектов нужны внешние бэкапы, независимый мониторинг и резервная площадка вне одного провайдера и телеком-маршрута.
При проверке 27 августа официальная live-панель показывала облачные серверы и основные сервисы доступными. Это текущий статус, а не отмена истории инцидентов.
Хронология
| Дата | Локация или сервис | Симптомы | Причина | Статус | Источник |
|---|---|---|---|---|---|
| 25 августа | ams-1, Нидерланды | Major-инцидент: сервисы в локации стали недоступны по сети | Сетевое оборудование перестало отвечать; провайдер отправил его в принудительную перезагрузку | Первый alert — 16:10 МСК; сеть восстановлена в 16:18; запись закрыта в 16:33 | Официальный канал |
| 19 августа | spb-1, spb-3 и зависимые сервисы | Утром live-панель показывала частичную доступность; позднее все сервисы отображались доступными | Не опубликована | Восстановлено при повторной проверке | Официальная live-панель |
| 15 августа | de-1, Германия | Major-инцидент: потеря сетевой связности с площадкой, на которой размещены серверы Timeweb Cloud | Протечка системы охлаждения на промежуточном телеком-узле Equinix FR5 привела к перегреву и массовому отключению сетевого оборудования | Связность восстановлена; финальное закрытие опубликовано в 23:38 МСК | Официальный канал |
| 29–30 июня | ams-1, Qupra | Повторная недоступность серверов и восстановительные работы | Отказ системы охлаждения дата-центра | Восстановлено на внешнем чиллере | 29 июня, 30 июня |
| 26 июня | ams-1 | Major-инцидент и нарушение доступности | Проблемы дата-центра и охлаждения | Устранено | Официальный канал |
| 25 июня | Несколько зон | Деградация сети во время атаки заявленной мощностью до 3 Тбит/с | DDoS | Устранено | Официальный канал |
| 5–7 и 21–25 июня | Российские зоны | Серия сетевых деградаций и усиление фильтрации | DDoS-атаки | Устранено | Официальная live-панель |
| 9–10 апреля | MSK-1, сетевое хранилище | Высокая задержка дискового ввода-вывода, зависание части ВМ в I/O wait, ограничения операций управления; отдельные полные паузы I/O доходили до 30 минут | Программный дефект низкоуровневого кода СХД вызвал циклические перезапуски узлов и перегрузку шины данных | Кластер стабилизирован 10 апреля; целостность данных сохранена | Технический отчёт Timeweb Cloud |
25 августа — сетевое оборудование ams-1
В 16:10 МСК Timeweb Cloud опубликовал Major-alert о сетевой недоступности сервисов в Нидерландах.
В 16:20 провайдер уточнил, что сетевое оборудование перестало отвечать и было отправлено в принудительную перезагрузку. Финальное сообщение указывает, что сетевая доступность фактически восстановилась в 16:18, а оборудование после проверки работало штатно. Запись была окончательно закрыта в 16:33.
16:10 — первый публичный alert
16:18 — заявленное время восстановления сети
16:20 — опубликовано техническое уточнение
16:33 — инцидент закрыт
Это не даёт оснований утверждать, что простой длился ровно восемь минут: фактическое воздействие могло начаться до первого сообщения, а у разных клиентов отличаться.
Событие отличается от июньских проблем Qupra:
- в июне причиной называлось охлаждение внешнего дата-центра;
- 25 августа перестало отвечать сетевое оборудование;
- оба класса проблем затронули
ams-1, но не должны объединяться в одну причину.
15 августа — потеря связности de-1 через Equinix FR5
15 августа произошёл Major-инцидент во Frankfurt-направлении.
Timeweb Cloud сообщил, что авария случилась не на площадке с пользовательскими серверами, а на промежуточном узле Equinix FR5, через который проходили каналы связи до de-1.
По опубликованному обновлению:
- в системе охлаждения машинных залов FR5 обнаружили протечку;
- температура поднялась выше 50 °C;
- сработала противопожарная система;
- сетевое и операторское оборудование начало отключаться;
- серверы и данные Timeweb Cloud на целевой площадке не были повреждены;
- пользователи потеряли сетевую связность до работающего оборудования.
Опубликованный провайдером таймлайн по МСК:
05:33 — первые потери пакетов на линках через FR5
05:41 — обнаружена протечка системы охлаждения
06:32 — зафиксирован рост температуры в залах
07:25 — критическая температура и массовые обрывы связи
19:34 — питание на часть стоек операторов ещё восстанавливалось
23:38 — связанность с площадкой восстановлена, инцидент закрыт
Нельзя считать всё окно с 05:33 до 23:38 одинаковым непрерывным простоем каждого сервера. Но событие показывает важный класс отказа: сервер может быть исправен, а сервис недоступен из-за промежуточного узла и общей трассы операторов.
Практический вывод по de-1
- резерв в том же городе не гарантирует независимый маршрут;
- health-check должен идти через несколько операторов;
- резервная площадка должна иметь независимый network path;
- DNS failover должен быть заранее проверен;
- внешние backup и secrets должны быть доступны без
de-1; - нужно различать повреждение сервера и потерю сетевой связности.
19 августа — частичная доступность в Санкт-Петербурге
Утром на live-панели наблюдалась частичная доступность облачных серверов и связанных сервисов в зонах spb-1 и spb-3. При повторной проверке все зоны уже показывались доступными.
Исторической записи с причиной и длительностью на публичной странице не найдено, поэтому событие отмечено как наблюдение live-панели, а причина не предполагается.
9–10 апреля — критическая деградация СХД в MSK-1
По опубликованному провайдером техническому отчёту, 9 апреля в 19:39 началась критическая деградация сетевого хранилища в зоне MSK-1. У части виртуальных машин выросла задержка дисковых операций, процессы зависали в состоянии I/O wait, а некоторые операции управления серверами временно блокировались.
Причиной назван программный дефект в низкоуровневом коде СХД. Он запускал циклические перезапуски узлов хранения и создавал дополнительную нагрузку на шину данных. К 10:30 10 апреля кластер был стабилизирован, после чего восстановительные операции продолжались примерно до 17:30.
Timeweb Cloud сообщил, что целостность пользовательских данных не была нарушена. Для отдельных ВМ при этом фиксировались полные остановки дискового ввода-вывода продолжительностью до 30 минут и периоды сетевой недоступности.
Июнь — DDoS и аварии Qupra
Июньские события относятся к двум независимым группам:
- атаки на сеть и инфраструктуру Timeweb Cloud;
- инженерные проблемы площадки Qupra в зоне
ams-1.
Провайдер отдельно сообщал о перегретом дата-центре, проблемах подрядной площадки и поиске варианта миграции. Защита сети не решает отказ охлаждения, а резервирование внутри одного проблемного ЦОД не заменяет внешнюю площадку.
Источник: Timeweb — «Про перегретый дата-центр».
Обычный Timeweb-хостинг — отдельный продукт
Инциденты shared-хостинга не переносятся в этот журнал, а события Cloud нельзя автоматически приписывать обычному хостингу.
Влияние на оценку провайдера
Timeweb Cloud остаётся в категории «Рискованные / спорные».
Август добавил два разных Major-события в европейских направлениях:
- 15 августа — внешний промежуточный узел FR5 и потеря связности
de-1; - 25 августа — зависшее сетевое оборудование
ams-1.
Сильные результаты личных тестов производительности не заменяют анализ повторяемости и типов отказа.
Практический вывод
- держать резервные копии вне Timeweb Cloud и вне той же площадки;
- иметь план переключения на другой регион или провайдера;
- мониторить приложение, сеть, базу данных и дисковую задержку отдельно;
- проверять контрольное чтение/запись, а не только ping VM;
- не считать одну исправную площадку гарантией доступности промежуточного маршрута;
- фиксировать конкретную зону и время, пока live-панель не изменилась;
- различать время восстановления и время закрытия status-записи;
- не смешивать Timeweb Cloud с обычным shared-хостингом.