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

Ключевая причина в том, что сегодня поведение повторных попыток не учитывает контекст. Хотя мы можем контролировать, сколько повторных попыток происходит, мы не можем точно контролировать, когда они происходят. Это проистекает из сложности надёжного различения ошибок, порождённых сервисом, и тех, что лишь передаются через него. В результате повторные попытки применяются единообразно, а не условно. Этот подход работает для временных или низкочастотных сбоев. Однако при умеренной или серьёзной деградации он становится контрпродуктивным.

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

Можно возразить, что коды ошибок от нижестоящих сервисов можно транслировать вверх по стеку, чтобы обеспечить контекст для повторных попыток. Хотя это теоретически возможно, такой подход не масштабируется в Uber из-за большого количества входящих и исходящих связей, развивающихся потоков вызовов и необходимости частых адаптивных изменений. Поэтому мы разработали контекстно-зависимый механизм в общей инфраструктуре для более эффективной обработки ошибок. Этот блог объясняет механизм.