✅ 45 минут DDoS-атак не наблюдается.

🛑 Функция создания и управления балансировщиками, базами данных и кластерами Kubernetes в Москве и Санкт-Петербурге временно недоступна по техническим причинам. Не переживайте, скоро включим обратно.

✅ Возможность создания и управления балансировщиками, базами данных и кластерами Kubernetes в Москве и Санкт-Петербурге восстановлена.

🛑 Часть виртуальных серверов могут создаваться с ошибками или дольше обычного. Уже исправляем.

✅ Проблема решена
В 16:15 по МСК проблема устранена нашими инженерами. Все сервисы работают штатно.

22 апреля 2025 г. произошел сбой в работе баз данных PostgreSQL во всех регионах. Проблема фактически началась около 14:40, была обнаружена в 15:10 и полностью устранена к 15:40. Общее время инцидента составило 1 час.

Причиной стало добавление нового расширения PostgreSQL, вызвавшее массовый перезапуск серверов из-за нестрогого порядка выполнения задач в Salt. Другие типы баз данных не пострадали.

Алерт не сработал своевременно, так как мониторинговая система интерпретировала перезапуски как часть штатного процесса обновления. Примем меры по улучшению системы мониторинга и настройке строгого порядка задач в Salt.

🔴 Технический инцидент с libvirt

В связи с внеплановым обновлением libvirt самопроизвольно выключился 1% виртуальных серверов. Наши инженеры уже включают их.

❗Текущий статус:
- Выясняем причины сбоя libvirt
- Постепенно включаем серверы. Ожидаем восстановление их работы в течение 15 минут.

Подробности о причинах будут в течение часа.

✅ Работа серверов полностью восстановлена в 19:50 мск

Постмортем инцидента с обновлением libvirt

Сегодняшний инцидент, затронувший ~1% виртуальных серверов, был связан с редкой ошибкой в автоматизированном процессе обновления libvirt. Ранее на этапах автоматических и ручных тестов проблема не воспроизводилась.

⏳ Хронология событий

1. 4 года назад была внедрена автоматизация для плановых обновлений libvirt (ежедневно 17:00–23:00 мск).

2. Вчера было проведено плановое обновление пакетов, включая libvirt.

3. Сегодня вечером сработал мониторинг на аномальные отключения серверов. Процесс обновления был экстренно остановлен, запущен процесс включения серверов. К 19:50 мск работа серверов была полностью восстановлена.

🔎 Корневая причина

Некорректный сброс флагов cgroups в процессе обновления (уникальный, ранее не встречавшийся кейс).

🛠️ Принятые меры

1. Полная остановка «виновного» скрипта обновлений, заморозка обновлений libvirt.

2. Пересмотр процесса тестирования: увеличение этапов постепенного rollout, расширение тестовых сценариев.

Инцидент с аварийным отключением электропитания в московском ЦОД

7 июня 2025 с 10:01 до 10:41 мск в одной из наших стоек в дата-центре IXcellerate Moscow South отказал автомат защиты питания во время работ на резервном вводе, из-за чего 5 нод с виртуальными серверами стали недоступны по сети.

⏳ Хронология событий

10:01 - мониторинг зафиксировал падение сетевых портов
10:02 - инженеры сообщили в NOC о недоступности серверов
10:18 - 10:23 - к устранению инцидента подключились инженеры ЦОД и представители дата-центра
10:41 - питание в стойке восстановлено, начат процесс анализа дисков и поэтапного запуска отключенных VDS

⚠️ Текущий статус

11:52 - работа всех виртуальных серверов полностью восстановлена

🔎 Причина

Выбило автомат защиты электропитания во время проведения плановых работ, которые проводил наш дата-центр. Иначе говоря, внеплановая аварийная ситуация на стороне ЦОД.

🛠️ Принятые меры

- Перераспределение питания в стойке силами дата-центра
- Проверка дисков и восстановление работы всех затронутых серверов

🛑 Возник программный сбой с S3 хранилищем. Уже решаем проблему. Все данные на месте.

По решению опишем причины инцидента.

✅ Работа S3 полностью восстановлена, все данные на месте. Продолжаем разбираться в причинах.

Подробности об инциденте опубликуем отдельно.

Постмортем сбоев в работе S3

17 июня 2025 с 15:30 до 18:20 мск в S3 были зафиксированы два последовательных сбоя.

⏳ Хронология

15:30 - 15:50 - на одной из нод Ceph произошел сбой SFP-модуля. За ним последовали потеря доступа к объектам и блочным устройствам для части клиентов.

Через 20 минут проблемный линк был отключен, модуль заменен, а доступы восстановлены.

18:00 - 18:20 - при регистрации новых доменов для бакетов, Nginx начал часто перезагружаться, уперся в лимит открытых файлов, и перестал запускать воркеры. Как итог - полная недоступность S3 и сбой балансировки.

⚒️ Принятые меры

1. В первом случае заменили SFP-модуль на Ceph-ноде.

2. Во втором - повысили лимиты open files для Nginx и оптимизировали логику конфигурации доменов.

PS вчера ночью некоторые получили через нашего бота в телеге уведомление о сбое с поплывшим форматированием. Отправили по ошибке 🥲🙏

🛑 Возник программный сбой в работе фронтенд apps.

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

После решения инцидента опишем причины и принятые меры.

✅ Работа фронтенд apps полностью восстановлена.

Подробности об инциденте опубликуем отдельно.

Разбор инцидента с Frontend Apps

25 июня 2025 с 15:30 до 16:45 мск из-за массового запуска сборок в кластере с фронтенд-приложениями переполнился диск. Это вызвало приостановку работы эпсов.

⏳ Хронология

15:30 - зафиксировали рост нагрузки и заполнение диска в кластере
15:40 - нагрузка кратно выросла из-за десятков процессов npm build / start, появившихся после запуска сервисных компонентов
15:45 - 15:55 - вручную завершили лишние процессы, нагрузка начала снижаться
16:00 - фронтенд-приложения начали восстанавливаться
16:45 - запустили сервисные компоненты в штатном режиме, стабилизировали работу кластера

🛠️ Принятые меры

Чтобы избежать повторения подобных ситуаций и повысить устойчивость систем, мы:

1. Увеличим емкость кластера.

2. Пересмотрим механизм обработки очередей в сервисном агенте.

3. Ограничим число одновременных процессов для сервисных служб.

🛑 Сетевые проблемы на сервисах в СПб — наши инженеры уже занимаются восстановлением.

Подробности будут чуть позже.

Возникла аппаратная проблема с роутером. Переключились на резерв.

Маршруты восстанавливаются, это займет некоторое время.

Сейчас большая часть маршрутов восстановлена. В ближайшие 15 минут будем продолжать оптимизацию.

Могут наблюдаться потери из-за повышенной нагрузки на линии. Часть внутренних сервисов в процессе перезагрузки и скоро станут доступны.

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

Подробности об инциденте опубликуем отдельным сообщением.

Разбор сетевого сбоя на роутере в Санкт-Петербурге

Друзья, сегодня днем, примерно с 12:00 до 15:46 мск, многие из вас могли испытывать серьезные проблемы с доступом к сети. Это был сложный и многоэтапный сбой на нашем центральном маршрутизаторе в СПб.

Считаем правильным не просто отписаться, что «все починили», а честно рассказать, что произошло, какая цепочка событий к этому привела, и что мы делаем, чтобы минимизировать риски в будущем.

⏳ Хронология событий: как всё ломалось и чинилось

1. Начало (12:00): мы заметили нестабильную работу одной из сетевых карт (MPC) в маршрутизаторе. Это вызывало частичную деградацию трафика — у некоторых из вас могли медленно открываться проекты или расти потери пакетов.

2. Первая попытка изоляции (12:30): чтобы стабилизировать ситуацию, мы программно отключили неисправную карту. Это помогло: лавинообразная нагрузка на процессор роутера прекратилась, и трафик временно восстановился.

3. Критический сбой (13:50): здесь проявился программно-аппаратный баг. Маршрутизатор перестал корректно обновлять информацию о маршрутах и начал отправлять часть трафика «в никуда» — на интерфейс уже отключенной карты. Это привело к массовой недоступности ресурсов.

4. Кульминация (14:00): в этот момент мы осознали масштаб проблемы — из строя выведены две ключевые карты, на которых находились каналы общей емкостью 400 Гбит/с, включая стыки с Ростелекомом, Ретном, магистраль на Москву и пиринг Cloud-IX.

5. Восстановление (14:00 – 15:46):

• Чтобы оживить маршрутизацию, мы принудительно переключили управление на резервный модуль (RE).

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

• К 15:46 основные восстановительные работы были завершены. Сеть стабилизировалась, но пока работает без двух вышедших из строя карт.

🛠️ Выводы и дальнейшие шаги

Эта авария выявила несколько слабых мест, над которыми мы уже работаем:

1. Производительность узла: стало очевидно, что текущий маршрутизатор в СПб работает на пределе своих возможностей. Мы ускорим плановый проект по его замене. Новое, более мощное оборудование уже заказано и находится в процессе поставки. В будущем сервисы на этой локации будут разнесены для повышения отказоустойчивости.

2. Побочный эффект при переключении: во время смены управляющего модуля (RE) проявилась неприятная особенность — сброс динамической конфигурации. Это вызвало кратковременный наплыв трафика на и без того «умирающий» узел и просадку общей производительности сети. Чтобы исключить такое в будущем, мы решили отказаться от использования этого функционала.

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

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

🛑 Наблюдаются проблемы в работе панели управления сервисов Cloud для всех локаций.

Может затронуть управление сетями, создание бэкапов в панели управления, создание и управление VDS, почтовые сервисы. Сами сервисы работают корректно.

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

Апдейт информации через 25 минут.