29 ноября с 15:34 до 20:23 (мск) до 100% клиентов испытывали недоступность сервиса api.mindbox.ru.

Корневая причина недоступности — отказ сети в зонах в облачном провайдере Yandex.Cloud

Влияние на клиента

С 15:34 до 20:23 клиенты сталкивались с ошибками и задержками при выполнении операций (в том числе на кассах), а также с задержками в работе сценариев и отправках транзакционных сообщений.

Вызовы с касс заканчивались ошибкой в промежутки времени:

• С 15:34 по 16:15 — для 20% вызовов
• С 16:35 по 16:36 — для 8% вызовов
• С 16:40 по 17:01 — для 30% вызовов
• С 17:14 по 17:17 — для 13% вызовов
• С 17:21 по 17:47 — для 50% вызовов

Вызовы всех синхронных операций заканчивались ошибкой в среднем в 9% случаев.

Вызовы асинхронных операций заканчивались ошибкой в среднем в 37% случаев.

С 15:36 по 18:10 транзакционные сценарии работали с задержкой у 2% клиентов.

С 15:53 по 19:48 массовые рассылки отправлялись с задержкой у 1% клиентов.

Как выявляли и устраняли инцидент

• 15:33 — Мониторинг зафиксировал нарушение SLA
• 15:38 — Диагностировали недоступность части серверов в зоне A в Yandex.Cloud
• 15:47 — Эскалировали ситуацию архитекторам для ускорения анализа
• 15:49 — Подтвердили наличие сетевого инцидента в зоне A с Yandex.Cloud и узнали текущий статус
• 15:50 — Начали вывод зоны A из продукта, чтобы минимизировать влияние на ваши сервисы
• 16:10 — Исключили проблемную зону из балансировки. Наблюдаем восстановление нормальной работы и прекращение нарушений SLA
• 16:43 — Выявили схожие проблемы в зоне B
• 16:50 — Информировали Yandex.Cloud о проблемах в зоне B
• 17:01 — Состояние в зоне B начало нормализовываться
• 17:09 — Уведомили Yandex.Cloud о возникновении ограничений в масштабировании мощностей из-за увеличенной нагрузки на API Yandex.Cloud
• 17:25 — Обнаружили аналогичные проблемы в зоне D и повторное их возникновение в зоне B. Передали информацию об этом в Yandex.Cloud
• 17:50 — Подтверждаем прекращение сетевых проблем, Yandex.Cloud также подтверждает устранение корневой причины инцидента. Наблюдаем значительное восстановление системы. Однако, ещё остаются нарушения SLA у нескольких клиентов, вызванные инцидентом и связанные с увеличенной нагрузкой на API Yandex.Cloud
• 18:38 — Информировали Yandex.Cloud о проблемах с сетевыми дисками в зоне A
• 20:23 — Фиксируем полное восстановление системы, перестали нарушать SLA у 100% клиентов
• 21:35 — Yandex.Cloud подтвердил полное разрешение инцидента, и наши инженеры начали возвращение нагрузки в зону A
• 21:55 — Вернули нагрузку в зону А, система работает в штатном режиме

Отчёт

Продукт Mindbox размещается в облачном вендоре Yandex.Cloud. Мы используем три зоны доступности, каждая из которых представляет собой независимый датацентр. Ресурсы Mindbox размещены одинаково в каждой из этих зон, а рабочая нагрузка равномерно распределяется.

Во время инцидента, мы столкнулись с несколькими проблемами:

• Полностью отказала одна из зон доступности
• Кратковременно отказывали две оставшиеся
• Заказ новых мощностей у вендора происходил очень медленно

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

В этом инциденте работа заказа мощностей всех зон нарушилась. Из-за дефицита серверов продолжительное время система работала недостатком ресурсов: у части клиентов работала с перебоями административная панель, снизилась скорость отправки рассылок и обработки сценариев, часть синхронных запросов обрабатывалась с ошибками.

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

Также мы обнаружили частичное несоответствие сервиса нашей стратегии:

• Некорректная настройка автоматического масштабирования приводит к усложнению аварийного вывода нагрузки из отказавшей зоны;
• Обработка синхронных вызовов (в том числе с касс) использует компонент очередей более низкого класса надежности чем должна. Во время отказа это привело к повышенному проценту ошибок в ответах.

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

Кроме вышеперечисленного, в этот раз кратковременно отказали и другие зоны. При одновременном отказе двух и более зон доступности, часть нашей инфраструктуры работать перестает — компоненты требуют обязательного резервирования и переходят в безопасный режим. Одновременный отказ двух зон является неприемлемым сценарием с точки зрения наших ожиданий от инфраструктурного вендора. Рассмотрим возможности мультиоблачной инсталляции.

Что улучшили

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

Что улучшим

• Откажемся от рассылочных групп серверов, не разделенных по признаку зоны доступности, для повышения стабильности сервисов рассылок — 4-й квартал 2024 года
• Откажемся от всех групп серверов, не разделенных по признаку зоны доступности, для повышения стабильности сервисов обработки синхронных и асинхронных операций — 2-й квартал 2025 года
• Реализуем регулярное полное тестирование отказа зоны, чтобы все новые изменения в продукте учитывали стратегию доступности — 2-й квартал 2025 года
• Рассмотрим бюджет и возможности мультиоблачной инсталляции, чтобы отказ одного вендора позволял перебалансировать нагрузку на ресурсы другого — 4-й квартал 2025 года