С 11:43 до 12:08 наблюдалась деградация сервиса рекомендаций.
За это время ~40% запросов не удалось обработать (статус-код 500).
Причиной стала ошибка в обновлении сервиса. Планируем сделать поэтапный процесс обновления в Q1’2022.
Во время инцидента часть клиентских запросов по получению рекомендаций завершалась ошибкой. Примерно половина виджетов и запросов по API не работали.
11:41 Разработчик запустил процесс автоматического обновления сервисов рекомендаций.
11:43 Начались проблемы в работе сервиса.
11:48 Пришли уведомления из-за нарушения SLA синхронных операций персонализации на нескольких проектах.
11:52 Команда сервиса рекомендаций подключилась на разбор дефекта.
11:59 Запустили откат сервиса на предыдущую версию.
12:08 Работоспособность сервисов рекомендаций восстановлена.
Команда рекомендаций приняла решение уменьшить значения request и limit для подов kubernetes, на которых развернут сервис рекомендаций. На регулярном планировании модели ресурсов команда обнаружила, что сервисы синхронных операций недоутилизируют выделенные ресурсы.
Выбранные значения оказались недостаточными, чтобы выдерживать нагрузку сервиса. Новой версии приложения для обработки первых запросов потребовалось больше CPU, чем было выделено в лимитах, в результате чего оно тротлилось. Время на обработку запросов деградировало, приложение столкнулось с нехваткой потоков. В такой ситуации liveness probe перестали укладываться в таймауты, и kubernetes рестартовал поды приложения. После рестарта проблема повторялась, и новые поды также не справлялись с нагрузкой.
Возврат к предыдущей версии приложения с повышенным объемом ресурсов помог и сервис рекомендаций продолжил работу в штатном режиме.
“Заморозили” количество ресурсов в модели железа, чтобы избежать подобного сценария оптимизации затрат в ближайшем будущем.
Улучшили инструкции дежурных (ранбуки), чтобы быстрее диагностировать и восстанавливаться от проблем при выкладке.
В Q1’2022 поэтапное обновление сервиса рекомендаций (canary deployment), чтобы избежать отказа для всех пользователей в случае возникновения проблем во время выкладки. Только после этого пересмотрим модель ресурсов и используемые проверки доступности.