✅ Возможность создания и управления балансировщиками, базами данных и кластерами 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 минут.

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

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

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

Обновление.

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