Повышенная задержка API, 2026-08-12
Деградация 42 мин. Данные не пострадали, потерянных запросов нет.
| Что | Как было |
|---|---|
| Длительность | 11:18-12:00 MSK, 42 мин |
| Влияние | Медиана ответа /v1/products 2,1 с вместо 91 мс, около 3% запросов завершились таймаутом на стороне клиентов |
| Обнаружение | Автоматическая проверка, 11:19 |
| Данные | Не затронуты, потерь нет |
Хронология
| 11:18 | Медиана ответа списка товаров начала расти, очередь запросов к хранилищу удлинилась |
| 11:19 | Сработала проверка задержки, дежурный поднят |
| 11:26 | Исключили внешние причины: сеть и нагрузка в норме, число запросов обычное |
| 11:34 | Нашли запрос с планом без индекса, подтвердили по журналу медленных запросов |
| 11:47 | Начали строить индекс на реплике |
| 11:58 | Индекс переключён на основной узел, план запроса вернулся к прежнему |
| 12:00 | Задержка вернулась к обычной, инцидент закрыт |
Медиана ответа API по внешним проверкам за 30 дней: та же полоса, что и на странице состояния.
Что произошло
Ночная выгрузка добавила в таблицу остатков заметно больше строк, чем обычно. Планировщик запросов пересчитал статистику и выбрал для выборки списка товаров другой путь - без нужного индекса. На небольших контурах это осталось незаметным, а на крупных выборка стала перебирать миллионы строк.
Почему не заметили раньше
Проверка следила за долей ошибок, а не за временем ответа: формально сервис отвечал, и ошибок не было. Оповещение по времени ответа существовало, но с порогом в 5 секунд - между обычными 91 мс и порогом помещалась вся деградация.
Что сделали
- Добавили составной индекс, вернувший план запроса.
- Опустили порог оповещения по медиане до 500 мс и добавили отдельное - по 95-му перцентилю.
- Ограничили размер одной ночной выгрузки, чтобы статистика не менялась скачком.
Что меняем
- Журнал медленных запросов теперь собирается постоянно, а не включается руками во время инцидента.
- План ключевых запросов проверяется на копии рабочих данных перед каждым выкатом.
- Дежурному добавлена готовая карточка: что смотреть первым при росте времени ответа.
Вопросы по разбору принимаем из кабинета: приложите время и X-Request-Id своих неудачных запросов, если они были.