Сбой PostgreSQL в Timeweb Cloud 22 апреля 2025: причины, последствия и меры

[Ryancoolround]

22 апреля 2025 года в облачной инфраструктуре Timeweb Cloud произошёл масштабный сбой в работе баз данных PostgreSQL, затронувший все регионы. Данный инцидент длился около одного часа и стал предметом детального анализа как внутри компании, так и среди специалистов, использующих облачные решения Timeweb. Ниже приводится подробный разбор произошедшего.

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

• 14:40 (МСК) — в инфраструктуре Timeweb Cloud начались массовые перезапуски серверов с PostgreSQL.
• 15:10 (МСК) — инцидент был зафиксирован как внештатный, начато расследование.
• 15:40 (МСК) — все сервисы восстановлены, нормальная работа баз данных PostgreSQL полностью возобновлена.

Общее время инцидента составило 60 минут.

Причина сбоя

Сбой был вызван внедрением нового расширения PostgreSQL, в процессе которого произошёл массовый перезапуск инстансов СУБД. Исследование показало, что в системе управления конфигурациями SaltStack использовался нестрогий порядок выполнения задач. В результате:

• Расширение было внедрено без должной последовательности действий.
• Серверы интерпретировали это как повод для перезапуска PostgreSQL.
• Все инстансы PostgreSQL во всех регионах оказались временно недоступны.

Это техническое решение само по себе не предусматривало сбоя, однако несовершенство orchestration-сценариев стало критическим триггером.

Поведение системы мониторинга

Мониторинг Timeweb Cloud не распознал инцидент своевременно. Причина — ошибочная интерпретация массовых перезапусков как штатной части процесса обновления. Таким образом, алертинговая система не зафиксировала аномалию до момента, пока не поступили сигналы от внешних пользователей и не произошло ручное вмешательство.

Это указывает на уязвимость мониторинга к массовым, но “легитимным” с точки зрения логики обновлений действиям.

Последствия

• Пользователи, использующие PostgreSQL в рамках Timeweb Cloud, столкнулись с полной недоступностью своих баз данных.
• Приложения и сайты, опирающиеся на PostgreSQL, оказывались недоступны или демонстрировали ошибки доступа к БД.
• Другие СУБД (MySQL, MariaDB и др.) не пострадали.

Важно: данные пользователей не были утрачены. После перезапуска все данные остались в целости и сохранности.

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

По итогам инцидента Timeweb объявил о следующих мерах:

Ужесточение порядка выполнения задач в Salt:

• Внедрение строгих зависимостей и порядка применения изменений.
• Применение валидации сценариев до продакшн-деплоя.

Улучшение системы мониторинга:

• Разделение алертов по типу: штатные перезапуски, массовые нестандартные действия, отклонения по SLA.
• Внедрение эвристик на основе поведения кластера в целом, а не отдельных инстансов.

Повышение прозрачности уведомлений:

• Быстрая публикация алертов и публичных пост-мортемов.
• Расширение каналов информирования (почта, Telegram-бот, панель управления).

Рекомендации пользователям

• Для критически важных систем рекомендуется использовать механизмы резервирования на уровне приложений (replica DB, failover).
• Следует регулярно тестировать поведение приложений при временной недоступности БД.
• Рассмотреть внедрение собственных внешних проверок доступности сервисов, не полагаясь исключительно на внутренние системы мониторинга облачного провайдера.

Заключение

Данный инцидент ещё раз подчёркивает важность строгого контроля за автоматизированными процессами обновлений и роли мониторинга как первого рубежа в обнаружении сбоев. Timeweb Cloud оперативно устранил последствия, однако именно такие ситуации становятся катализатором улучшений в архитектуре, автоматизации и мониторинге.

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