Атака затрагивает локации Нидерланды и Казахстан.
Атакованные подсети заведены под защиту — из-за этого возможны временные просадки скорости и доступности сервисов.

Если сервисы недоступны — обращайтесь в поддержку.

Upd. Оптимизировали правила, доступность до сервисов должна восстановиться.

✅ Доступность большинства сетей восстановлена.

Атака полностью отражена в 22:21 мск.

Разбор сетевого инцидента 10 февраля во Франкфурте

В дата-центре партнера сработала пожарная сигнализация из-за возгорания на одном из узлов — это привело к аварийному отключению электропитания всего здания. Доступ к оборудованию был закрыт примерно на 2 часа: партнер проводил расследование на своей стороне.

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

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

🛑 Недоступность части серверов в локации МСК

Во время плановых работ на одной стойке в дата-центре возникла аварийная ситуация. Часть серверов, расположенных в локации МСК, может работать с перебоями или быть недоступны с 14:55 мск.

Инженеры занимаются восстановлением работы серверов, ориентировочно потребуется до 30 минут.

В процессе восстановления доступности нод не удалось примонтировать систему хранения.

Инженеры проводят перенос виртуальных машин на другие ноды для восстановления доступности. На работы потребуется дополнительное время, от 30 до 60 минут.

Начали процесс восстановления виртуальных серверов в порядке очереди.

Миграция не потребовалась.

В процессе восстановления доступности серверов инженеры столкнулись с каскадом неполадок, восстановление происходит в ручном режиме, подключена вся команда инженеров.

Больше половины виртуальных машин с 17 затронутых нод уже запущены, работы на завершающей стадии.

✅ Работа серверов восстановлена.

Отчет об инциденте в инфраструктуре Timeweb Cloud 24.03.2026

Таймлайн (время московское):

14:45 — обнаружение проблем с доступностью виртуальных машин на узлах kvmnvm-867, kvmnvm-886.
14:55 — начало аварийно-восстановительных работ (АВР). Зафиксирована проблема еще на 15 нодах, ноды выведены из регистрации и балансировки.
15:30 — диагностика подтвердила сетевой сбой, в результате которого гипервизор не запускался из-за блокировки части дисков виртуальных машин на сетевом хранилище.
16:00–20:25 — поэтапное ручное восстановление ВМ силами дежурных инженеров и команды cloud-инфраструктуры.
21:26 — массовое снятие локов для сегмента VDS.
22:05 — восстановление штатной работы сервисов. Инцидент закрыт.

Технический анализ:

Первопричиной стал флап сети, который вызвал каскадную проблему на уровне гипервизоров. Специфика работы протоколов доступа к СХД такова, что при таком сбое сетевая сессия может не закрыться корректно. В результате СХД продолжает считать, что данные используются «старым» гипервизором, и блокирует доступ для «нового». Автоматика в данном случае оказалась бессильна, так как требовалось подтверждение целостности данных перед форсированным снятием блокировки.


Работа над ошибками:

1. Сейчас мы работаем над инструментом, который позволит автоматизировано сбрасывать локи на СХД при подтверждении падения гипервизора.

2. Настроены дополнительные алерты на аномальное количество ошибок I/O на уровне гипервизоров для более раннего обнаружения подобных проблем.

3. В планах — изменение композиции архитектуры с учетом вскрывшихся технических ограничений, направленное на стабилизацию работы гипервизоров и автоматизацию аварийного восстановления клиентских нагрузок в сценариях отказа.

🛑 Фиксируем периодические проблемы с доступностью по сети до части серверов

Инженеры подключены к диагностике неполадок. Влияет в том числе на отображение информации в панели управления.

Дадим апдейт после уточнения информации по проблеме.

Неполадки затронули сервисы в локации AMS. Временно аффект мог затронуть локацию SPB, а также работу AI-агентов.

Сейчас работа всех сервисов восстанавливается.

✅ Работа сервисов восстановлена, трафик вернулся в нормальным значениям.

Причиной стал программно-аппаратный сбой на маршрутизаторе, который привел к ошибке в работе сети. Сейчас сбой устранён.

⚠️ Временные задержки в работе дисковой подсистемы

В данный момент часть виртуальных машин в Москве может работать с повышенными задержками (latency).

Причина: выявлены программные несоответствия в работе подсистемы хранения.

В настоящий момент инженеры проводят оптимизацию работы СХД.

⚙️ Апдейт по работам в Москве

Продолжаем поэтапный ввод исправлений для подсистемы хранения.

Обновлено 4 из 8 сегментов инфраструктуры. На модернизированных сегментах фиксируем стабилизацию нагрузки и возвращение latency к нормативным значениям.

Ожидаемое время завершения всех работ — в течение 2-2.5 часов.

✅ Работа инфраструктуры в Москве полностью восстановлена

Мы завершили обновление программного обеспечения на всех узлах кластера хранения. Все системы работают в штатном режиме, показатели производительности и latency вернулись к целевым значениям.

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

Наши специалисты уже занимаются этим вопросом, доступ будет восстановлен в ближайшее время.

Чуть позже будет детальный технический разбор.

Мы локализовали проблему с частичным отсутствием доступа по SSH и зависанием части виртуальных машин. Для их возвращения в строй инженерам необходимо провести перезагрузку нескольких нод в Москве.

Суммарное время работ составит до 2 часов, и до 15-20 минут для конкретных виртуальных машин в рамках этого окна.

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

Параллельно исправляем зависшие статусы сервисов в панели управления. На доступность это не влияет.

Разбор инцидента опубликуем позднее.

Фиксируем массовые сообщения о недоступности сервисов Telegram (включая api.telegram.org).

Симптомы
• Ошибки подключения (timeout) при обращении к Bot API.
• Нестабильная работа интеграций и уведомлений через Telegram-ботов.
• Задержки в обновлении статусов в веб-версии мессенджера.

Данная проблема не связана с работами на стороне Timeweb Cloud и наблюдается у большинства провайдеров и дата-центров.

Рекомендуем временно использовать альтернативные каналы уведомлений, если ваши бизнес-процессы завязаны на Telegram API.

Постмортем инцидента в зоне MSK-1 (09.04-10.04)

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

Подробный технический разбор →

Коротко о причинах
• Ошибка СХД спровоцировала reboot loop узлов хранения. Рекурсивные перезагрузки вызвали оверлоад шины данных.
• Зависание процессов виртуальных машин на уровне гипервизоров, I/O wait и сетевая недоступность из-за блокировки системных процессов ОС.

Что сделано
• Внедрены сценарии каскадных отказов в протоколы тестирования.
• Запущен подбор альтернативных СХД для диверсификации рисков.
• Автоматизирован сброс сессий гипервизора при зависшем I/O.

⚠️ Модернизация зарубежной инфраструктуры: локация Амстердам

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

Старт работ: сегодня в 11:45 мск
Длительность: до 30 мин

Влияние на сервисы:

• Временная недоступность сервисов в Амстердаме на период перезагрузки
• В остальных локациях возможно снижение скорости из-за автоматического перестроения маршрутов

Инфраструктура в РФ работает в штатном режиме. О завершении работ тоже проинформируем.

Работы полностью завершены. Работоспособность серверов в Амстердаме восстановлена в 12:00 мск.

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