✅ Работа 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 минут.

Обновление по проблеме.

Ориентировочное время восстановления 40 минут, максимальное до 2х часов.

Апдейт через 40 минут.

Обновление.

Работа сервисов восстановлена. Проводится финальная проверка функциональности сервисов.

Пока что сохраняются трудности с созданием новых сервисов в панели управления.

Инженеры продолжают работы над устранением причин неполадок.

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

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

Сегодня с 11:15 до 11:30 мск были сетевые проблемы на VDS, связанные с проведением профилактических работ в нашем ДЦ в СПб.

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

1. С 10:30 проводились работы по переключению первых стоек в новый коммутатор QFX10008 — для поднятия емкости с 80 Гбит/c до 160 Гбит/c. Это была первая итерация работ для увеличения стабильности и качества нашей сети. Из-за сложности и критичности они проводились в дневное время с привлечением большого количества инженеров.

Само переключение стоек с ИЦОД прошло корректно и без деградации сети.

2. В 11:15 возникли флапы BGP-сессий, связанные с ошибкой в конфигурации оборудования. Проблема была исправлена за 15 минут.

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

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

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

Действия с облачными ресурсами недоступны. Сами сервисы работают корректно.

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

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

По проблеме с сетями

У части клиентов кратковременно прерывается коннект до нашей инфраструктуры.

Внешне и по трассировкам от клиентов видим, что трафик ходит свободно. Что уже сделали:

1. Изучили трассировки клиентов — визуально проблем не обнаружено, трафик доходит до конечного хоста.

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

Проблема плавающая, продолжаем разбираться.

🛑 Наблюдаем проблемы в работе Frontend Apps.

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

✅ Работа Frontend Apps восстановлена