Инциденты Timeweb Cloud в 2026 году
Инциденты Timeweb Cloud в 2026 году
Последняя проверка: 21 августа 2026 года.
Краткий вывод
В 2026 году у Timeweb Cloud совпали разные классы риска: критическая деградация сетевого хранилища, крупные DDoS-атаки, повторные проблемы охлаждения внешнего дата-центра в Амстердаме и кратковременные локальные деградации. Их нельзя объединять в одну причину, но для критичных проектов совокупность событий требует внешних бэкапов, мониторинга дискового ввода-вывода и резервной площадки.
Хронология
| Дата | Локация или сервис | Симптомы | Причина | Статус | Источник |
|---|---|---|---|---|---|
| 19 августа | spb-1, spb-3 и зависимые сервисы | Утром live-панель показывала частичную доступность; позднее все сервисы отображались доступными | Не опубликована | Восстановлено при повторной проверке | Официальная live-панель |
| 29–30 июня | ams-1, Qupra | Повторная недоступность серверов и восстановительные работы | Отказ системы охлаждения дата-центра | Восстановлено на внешнем чиллере | 29 июня, 30 июня |
| 26 июня | ams-1 | Major-инцидент и нарушение доступности | Проблемы дата-центра и охлаждения | Устранено | Официальный канал |
| 25 июня | Несколько зон | Деградация сети во время атаки заявленной мощностью до 3 Тбит/с | DDoS | Устранено | Официальный канал |
| 5–7 и 21–25 июня | Российские зоны | Серия сетевых деградаций и усиление фильтрации | DDoS-атаки | Устранено | Официальная status-панель |
| 9–10 апреля | MSK-1, сетевое хранилище | Высокая задержка дискового ввода-вывода, зависание части ВМ в I/O wait, ограничения операций управления; отдельные полные паузы I/O доходили до 30 минут | Программный дефект низкоуровневого кода СХД вызвал циклические перезапуски узлов и перегрузку шины данных | Кластер стабилизирован 10 апреля; целостность данных сохранена | Технический отчёт Timeweb Cloud |
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.
Провайдер отдельно сообщал о перегретом дата-центре, проблемах подрядной площадки и поиске варианта миграции. Это важно учитывать отдельно от DDoS: защита сети не решает отказ охлаждения, а резервирование внутри одного проблемного ЦОД не заменяет внешнюю площадку.
Источник: Timeweb — «Про перегретый дата-центр».
Практический вывод
- держать резервные копии вне Timeweb Cloud и вне той же страны или площадки;
- для критичного сервиса иметь план переключения на другой регион или провайдера;
- отдельно мониторить доступность приложения, сети, базы данных и дисковую задержку;
- проверять не только uptime ВМ, но и время выполнения контрольной операции чтения или записи;
- не считать завершённый DDoS доказательством неисправности виртуальной машины;
- при новом инциденте фиксировать конкретную зону, сервис и время, пока live-панель не изменилась.