Инцидент с доступностью сервиса 27 марта 2026
Разбор причин и хронология инцидента с недоступностью сервиса 27 марта 2026 года.
Резюме инцидента
Что произошло
27 марта 2026 с 09:44 до 12:59 (UTC+3) наш сервис был недоступен для пользователей на всех платформах — веб, Android и iOS. Некоторые пользователи кратковременно попадали в систему, но сессии обрывались.
Потери данных не произошло.
База данных вошла в деградированное состояние: время ответа на запросы резко возросло без соответствующего роста нагрузки. Ни добавление мощностей, ни снижение нагрузки не помогли — БД не смогла восстановиться самостоятельно. Сервис был восстановлен после перезагрузки базы данных.
Мы приносим извинения за этот инцидент. Ниже — хронология, анализ причин и меры, которые мы принимаем.
Хронология
Все отметки времени — UTC+3.
- 09:44 – Мониторинг зафиксировал резкое увеличение времени ответа БД при нормальном уровне нагрузки. Начато расследование. Опубликовали факт начала в клиентских чатах, где были первые обращения.
- ~09:50 – Сработал автоскейлинг, добавлены мощности — ситуация не улучшилась.
- 09:54 – Пользователи уведомлены в официальном канале.
- ~10:00 – Вручную добавлены дополнительные ресурсы — не помогло. Даже простые запросы выполнялись аномально долго.
- 10:19 – Подтверждена серьёзная деградация. Дополнили вручную инцидент на статусной странице.
- ~10:30 – Стало понятно, что проблема точно в самой БД. Попробовали снизить нагрузку, частично ограничив доступ к сервису — не повлияло.
- ~10:30–11:58 – Пробовали стабилизировать БД и параллельно рассматривали вариант переключения на рабочую реплику БД, но приняли решение в пользу ребута, как более проверенного решения.
- 11:58 – Запущена перезагрузка БД.
- 12:59 – Перезагрузка завершена. Сервис восстановлен.
Цепочка причин
- Почему сервис стал недоступен? — БД перестала обрабатывать запросы в приемлемое время.
- Почему? — БД вошла в деградированное состояние без видимого роста нагрузки.
- Почему добавление мощностей и снижение нагрузки не помогли? — Проблема была не в нехватке ресурсов, а во внутреннем состоянии БД.
- Почему БД не восстановилась самостоятельно? — Предварительная гипотеза: потенциальный баг на уровне СУБД. Точная причина — предмет расследования.
Что мы делаем, чтобы это не повторилось
Точная причина деградации БД — предмет расследования. Но мы фокусируемся на архитектурных изменениях, которые сократят влияние и время восстановления независимо от причины.
Снижение влияния
- Шардирование базы данных. Разделяем БД на независимые сегменты, чтобы аналогичная проблема затрагивала не всех пользователей и база могла быть быстрее восстановлена.
Ускорение восстановления
- Отладка переключения на реплику. Переключение работает, но обратный возврат на основную БД был ещё в процессе отладки — из-за чего мы не применили этот вариант во время инцидента. Отрабатываем полный цикл и проводим учения.
Обновление от 28 марта 2026: корневая причина установлена
По результатам расследования мы установили наиболее вероятную причину деградации БД.
На протяжении нескольких дней к продуктивной базе данных было открыто сервисное подключение мониторинга в режиме, при котором все операции оборачиваются в одну транзакцию на весь сеанс. Пока эта транзакция была открыта, БД не могла очищать накопившуюся историю изменений — это штатное поведение СУБД, необходимое для обеспечения целостности данных.
Когда сессию перезапустили, БД начала массовую очистку накопленных за несколько дней данных. Эта внутренняя операция заняла все доступные ресурсы и заблокировала нормальную обработку пользовательских запросов.
Этим объясняется поведение, которое мы наблюдали во время инцидента: нагрузка от пользователей не росла, добавление мощностей и снижение внешней нагрузки не помогали — потому что ресурсы потреблял внутренний процесс БД.
Дополнительные меры по итогам расследования
- Запрет на долгоживущие сервисные сессии к продуктивной БД. Такие сессии больше не допускаются в рабочем процессе.
- Ограничение времени жизни транзакций. Устанавливаем таймаут на уровне БД — транзакции, открытые дольше заданного порога, будут автоматически завершены.
- Алерт на долгие транзакции. Добавляем мониторинг транзакций старше N минут — чтобы обнаруживать подобные ситуации до того, как они повлияют на сервис.