Timeweb Cloud Alerts

⚙️ Апдейт по работам в Москве Продолжаем поэтапный ввод исправлений для подсистемы хранения. Обновлено 4 из 8 сегментов инфраструктуры. На модернизированных сегментах фиксируем стабилизацию нагрузки и возвращение latency к нормативным значениям. Ожидаемое время завершения всех работ — в течение 2-2.5 часов.

⚠️ Временные задержки в работе дисковой подсистемы В данный момент часть виртуальных машин в Москве может работать с повышенными задержками (latency). Причина: выявлены программные несоответствия в работе подсистемы хранения. В настоящий момент инженеры проводят оптимизацию работы СХД.

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

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

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

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

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

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

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

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

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

Разбор сетевого инцидента 10 февраля во Франкфурте В дата-центре партнера сработала пожарная сигнализация из-за возгорания на одном из узлов — это привело к аварийному отключению электропитания всего здания. Доступ к оборудованию был закрыт примерно на 2 часа: партнер проводил расследование на своей стороне. После восстановления доступа часть инфраструктуры запустили сразу, но некоторые критичные компоненты из-за длительного обесточивания вышли из строя и потребовали замены. После замены оборудования все сервисы заработали в штатном режиме. Партнер обозначил меры со своей стороны. Мы тоже делаем выводы и прорабатываем дополнительные сценарии на случай подобных ситуаций.

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

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

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

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

🛑 Аварийная ситуация на магистральном оборудовании. Сетевые инженеры занимаются восстановлением.

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

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

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