Uber تشرح آلية error ownership التي أوقفت 9.5 مليون طلب إضافي في عطل واحد
ما يُسقط الخدمة المتعثرة غالبًا ليس عطلها، بل محاولات الإنقاذ المتزامنة من كل الطبقات فوقها، والحل معلومة واحدة تنتقل مع الطلب.
نشرت Uber في 17 سبتمبر 2026 مقالًا هندسيًا بعنوان How Uber Protects Against Retry Storms، يشرح كيف تحمي أنظمتها مما يُعرف بعاصفة إعادة المحاولات. ووصل المقال إلى صدارة Hacker News.
العاصفة تحدث في الأنظمة المبنية من خدمات تنادي بعضها. تفشل خدمة، فتعيد الخدمة التي فوقها المحاولة، وتعيد التي فوقها أيضًا، وهكذا. وكل طبقة تضاعف الحمل. وبحسب الحساب الوارد في المقال، مع إعادة محاولة واحدة فقط لكل طبقة وخدمة فاشلة على عمق 3، تستقبل الخدمة في الأسفل 8 أضعاف حركتها الطبيعية. أما مع retry budget بنسبة 10%، أي سقف لنسبة الطلبات المعادة، فتستقبل 1.33 ضعف فقط.
من يملك الخطأ
الحل الذي تبنته Uber اسمه error ownership. كل خدمة تحدد ما إذا كانت هي مصدر الخطأ أم مجرد ناقل له. فإذا فشلت دون أن يفشل أي طلب أرسلته إلى خدمة أخرى، فالخطأ خطؤها. وإذا ارتبط فشلها بفشل خدمة أدنى، فهي تتبرأ منه.
يُحسب هذا القرار عبر نظام تسميه الشركة Service Dependency Analysis Solution، ويُنقل في ترويسة باسم x-uber-error-claim. والخدمة المستدعية لا تعيد المحاولة إلا إذا أعلنت الخدمة التي تحتها أن الخطأ خطؤها.
والنتائج المذكورة جاءت من عطل وقع في 18 نوفمبر 2025 في خدمة على عمق 5 طبقات. أوقفت الآلية 9.5 مليون طلب إضافي، وانخفض نصف قطر العاصفة من 25 طبقة إلى 3 في أقصى الحالات، ومن 20 إلى 2 في المتوسط.
ما يلفت في الحل أنه لا يعتمد على نظام ضخم أو مكتبة معقدة، بل على معلومة واحدة ترافق الطلب: هل هذه الخدمة مصدر المشكلة أم لا. ويمس هذا المبدأ أي فريق يبني خدمات تستدعي بعضها ويضع إعادة المحاولة على كل خطأ دون تمييز، إذ يكفي عمق بضع طبقات لتتحول آلية الحماية نفسها إلى مصدر الانهيار.