Is Mindbox Down?

20 июля 2026 года с 16:25 до 16:45 \(мск\) у 5% клиентов Mindbox не создавались и не изменялись заказы в процессинге. **Корневая причина — программная ошибка в утилите миграций схемы базы данных: на части проектов шаги миграции применились в некорректном порядке, из-за чего операции создания и изменения заказа завершались ошибкой. Просмотр заказов оставался доступен.** ### **Влияние на клиента** В период инцидента создание и изменение заказов было недоступно во всех каналах: кассы не могли создавать заказы, онлайн-заказы не создавались, не работало изменение статусов заказов. Чтение заказов было доступно.  После устранения инцидента все заказы из асинхронных операций были обработаны. ### **Как выявляли и устраняли инцидент** * **16:25** — сработала эскалация систем мониторинга * **16:31** — дежурные инженеры локализовали проблему * **16:38** — исправлена миграция схемы базы данных на одном клиенте, процессинг заказов на нём восстановился * **16:40** — исправление запущено на всех клиентах * **16:45** — работа процессинга заказов полностью восстановлена ### **Отчёт** **Подробнее о причине сбоя** В одной из таблиц базы данных процессинга заказов была устаревшая колонка, которую код не использовал. Её удаление — двухшаговая операция: сначала снимается значение по умолчанию, затем удаляется сама колонка. Из-за программной ошибки в утилите миграций схемы базы данных на некоторых проектах эти два шага применились в некорректном порядке. В результате база временно оказалась в некорректном состоянии: колонка оставалась обязательной, но уже без значения по умолчанию. Любая запись в таблицу, а значит, любое создание или изменение заказа — завершалась ошибкой. После выполнения оставшегося шага \(удаления колонки\) состояние нормализовалось и ошибки прекратились. ### **Что улучшим** **В работе:** * Доработаем утилиту миграций схемы базы данных для корректного последовательного применения нескольких связанных изменений — август 2026 * Добавим в утилиту миграций валидацию корректности запрошенных изменений с точки зрения схемы базы данных — август 2026 --- [2026-07-20T14:03:33.102Z] (resolved) С 16:25 до 16:45 (мск) для 5% клиентов наблюдалась частичная недоступность сервисов расчета и сохранения заказов. С 16:45 работа сервисов восстановлена. Дежурная команда продолжает наблюдать за стабильностью работы систем. Вернёмся с детальным разбором в течение 2 недель.

17 июня 2026 года с 10:31 до 11:30 \(мск\) у клиентов Mindbox не отображался список клиентов на странице «Клиенты». **Корневая причина — некорректное изменение логики подсчёта количества клиентов в релизе вызвало самоподдерживающийся цикл запросов, который удерживал страницу в бесконечной загрузке.** ### **Влияние на клиента** В период инцидента страница «Клиенты» находилась в постоянной загрузке и не отображала список клиентов.  ### **Как выявляли и устраняли инцидент** * **10:31** — заведен ручной дефект после жалоб клиентов * **10:38** — инженеры приступили к анализу проблемы * **10:58** — обнаружена корневая причина в последнем релизе * **11:30** — выполнен откат некорректного изменения, работоспособность страницы восстановлена ### **Отчёт** **Подробнее о причине сбоя** Страница «Клиенты» использует функцию запроса счётчика клиентов, ссылка на которую передается через цепочку зависимостей в эффект фильтра. В штатном режиме эта ссылка стабильна. Релиз содержал оптимизационную правку. Побочным эффектом правки стало то, что при каждом изменении состояния загрузки страница воспринимала это как повторное применение фильтра и заново загружала список — что снова меняло состояние загрузки. Образовался самоподдерживающийся цикл: страница навсегда зависала в загрузке, нагрузка на API кратно возрастала. ### **Что улучшим** **В работе:** * Настроим мониторинг работоспособности ключевых страниц панели управления \(SLO\) с автоматической эскалацией до дежурной команды — Q3 2026 * Добавим тесты, исключающие возможность повторения подобной ошибки — Q3 2026 --- [2026-06-17T08:48:34.292Z] (resolved) С 11:30 (мск) работа страницы "Клиенты" восстановлена. Вернемся с подробным разбором и следующими шагами в течение двух недель. --- [2026-06-17T08:34:14.969Z] (investigating) Выполняются работы по восстановлению сервиса. Вернемся с обновлением статуса в течение часа.

26 мая 2026 года с 15:42 до 16:41 \(мск\) у 50% клиентов наблюдалась частичная недоступность панели управления Mindbox. **Корневая причина — ошибка в облачном сервисе балансировки \(Yandex NLB\) привела к недоступности при штатном обновлении прокси серверов, обслуживающих административную панель.** ### **Влияние на клиента** В период инцидента примерно у 50% клиентов в половине случаев не срабатывал вход в административную панель, а также не открывались страницы рассылок и сценариев. ### **Как выявляли и устраняли инцидент** * **15:32** — начаты плановые работы по обновлению Haproxy * **15:42** — система мониторинга зафиксировала рост ошибок, заведен дефект * **15:45** — инженеры Mindbox подключились к диагностике * **15:48** — определены нарушения связности между Yandex NLB и Haproxy, проблема эскалирована в поддержку Яндекса * **15:56** — раскатка предыдущего релиза вручную остановлена, чтобы предотвратить отключение работающих машин Haproxy * **16:20** — большинство новых машин, не получавших трафик, выведены из работы * **16:41** — вывод затронутых машин завершён, работоспособность восстановлена ### **Отчёт** **Подробнее о причине сбоя** Все входящие соединения Mindbox, включая административную панель, проходят через балансировщик Yandex NLB и горизонтально масштабируемую группу прокси-серверов \(Haproxy\). У API, панели управления и отдельных продуктовых сервисов развернуты изолированные группы Haproxy. Инженеры платформы проводили плановые работы по обновлению Haproxy. Выкладка происходит постепенно: старые машины отключаются только после того, как новые прошли проверки работоспособности и готовы принимать трафик. В ходе выкладки новые машины штатно прошли все проверки, однако трафик от Yandex NLB на них так и не пришёл. Причина установлена совместно с Яндекс Облаком: в момент, когда балансировщик начинал направлять трафик на новую машину, сетевое оборудование Яндекса \(vrouter\) несколько минут продолжало использовать устаревшие правила маршрутизации для ответного трафика. Из-за этого ответы новых машин уходили клиентам «не тем путём» — клиент не мог сопоставить ответ со своим запросом и разрывал соединение. Для клиента это выглядело как таймауты и ошибки входа.  ### **Что улучшим** **Уже сделано:** * Выкладка Haproxy временно ограничена еженедельным ночным окном планового обслуживания, обычные пайплайны заблокированы * Авто-масштабирование Haproxy временно отключено — кластер работает на максимальном количестве машин **В работе:** * Яндекс Облако применило первую итерацию исправления, существенно сокращающей время некорректной маршрутизации обратного трафика. Что значительно снижает вероятность и длительность подобной проблемы, однако не устраняет её полностью * Разработка окончательного решения на стороне Яндекс Облака продолжается, сроков пока нет — продолжаем сопровождать тикет --- [2026-06-10T12:20:00.936Z] (resolved) 26.05.2026 с 15:42 до 16:41 (мск) наблюдалась частичная недоступность панели управления для 50% клиентов. Мы вернёмся с подробным разбором и следующими шагами в течение 2 недель. Обновление на 10.06.2026: расследование причин не завершено и продолжается совместно с Яндекс Облаком. 26 мая 2026 года с 15:42 до 16:41 (мск) у 50% клиентов наблюдалась частичная недоступность панели управления Mindbox. Корневая причина — ошибка в облачном сервисе балансировки (Yandex NLB) привела к недоступности при штатном обновлении прокси серверов, обслуживающих административную панель. > Влияние на клиента В период инцидента примерно у 50% клиентов в половине случаев не срабатывал вход в административную панель, а также не открывались страницы рассылок и сцена > Как выявляли и устраняли инцидент 15:32 — начаты плановые работы по обновлению Haproxy 15:42 — система мониторинга зафиксировала рост ошибок, заведен дефект 15:45 — инженеры Mindbox подключились к диагностике 15:48 — определены нарушения связности между Yandex NLB и Haproxy, проблема эскалирована в поддержку Яндекса 15:56 — раскатка предыдущего релиза вручную остановлена, чтобы предотвратить отключение работающих машин Haproxy 16:20 — большинство новых машин, не получавших трафик, выведены из работы 16:41 — вывод затронутых машин завершён, работоспособность восстановлена > Подробнее о причине сбоя Все входящие соединения Mindbox, включая административную панель, проходят через балансировщик Yandex NLB и горизонтально масштабируемую группу прокси-серверов (Haproxy). У API, панели управления и отдельных продуктовых сервисов развернуты изолированные группы Haproxy. Инженеры платформы проводили плановые работы по обновлению Haproxy. Выкладка происходит постепенно: старые машины отключаются только после того, как новые прошли проверки работоспособности и готовы принимать трафик. В ходе выкладки новые машины штатно прошли все проверки, однако трафик от Yandex NLB на них так и не пришёл. Причина такого поведения балансировщика всё еще устанавливается совместно с поддержкой Яндекс Облака. > Что улучшим >> Уже сделано: - Выкладка Haproxy временно ограничена еженедельным ночным окном планового обслуживания, обычные пайплайны заблокированы - Автомасштабирование Haproxy временно отключено — кластер работает на максимальном количестве машин >> В работе: - Совместно с поддержкой Яндекс Облака продолжаем расследование причин отказа балансировщика — по результатам определим системные меры для предотвращения повторения.