🛑 Недоступность локации Франкфурт

Инженеры погружены в выявление проблемы и её решение.

Недоступность локации вызвана неполадками на стороне дата-центра.

Ожидаем информацию о сроках восстановления доступности наших сервисов.

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

Мы получили подтверждение наличия питания на самих серверных стойках. Ожидаем устранение неполадок со стороны инженерных служб подрядчиков.

Продолжаются восстановительные работы в ЦОД. Часть оборудования оператора вышла из строя в связи с аварией по электропитанию.

В течение часа ожидается подвоз исправного оборудования для последующей замены.

Оборудование поступило на площадку. Производится установка.

Работы по обновлению и настройке оборудования продолжаются.

Сообщим сроки завершения восстановительных работ сразу, как получим информацию.

Работы на завершающем этапе. Соединения поднимаются. Наблюдаем за стабильностью.

✅ Соединение стабильно, проблемы не наблюдаются.

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

🛑 Аварийная ситуация на магистральном оборудовании.

Сетевые инженеры занимаются восстановлением.

На сетевом оборудовании в дата-центре возникла аварийная ситуация вызванная переключением магистрального оборудования на резервный Routing Engine, что привело к перезапуску сессий.

Сейчас часть сетевых маршрутов перестраивается, трафик восстанавливается. Авария могла затронуть трафик в локациях SPB, MSK, AMS.

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

🛑 Наблюдаются трудности в работе панели управления. Инженеры восстанавливают работу. Ориентировочное время решения проблемы — 10 минут.

✅ Работа панели управления восстановлена.

При выполнении плановых работ на служебных сервисах возникла непредвиденная ошибка.

Разбор сетевого инцидента 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. В планах — изменение композиции архитектуры с учетом вскрывшихся технических ограничений, направленное на стабилизацию работы гипервизоров и автоматизацию аварийного восстановления клиентских нагрузок в сценариях отказа.

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

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

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