۴۵۴۳ درخواست با شکست مواجه شدند؛ یعنی تقریباً ۷.۵ برابر بیشتر از آنچه در یک افت ظرفیت معمولی انتظار می‌رود. در حالی که این افت ظرفیت تنها باید ۶۰۰ درخواست را تحت تأثیر قرار می‌داد، اما طبق داده‌های منتشر شده در ۲۳ اوت ۲۰۲۶ توسط Arc Ops، یک افت ظرفیت کوتاه در ۱۰ بازه زمانی (Tick)، به‌دلیل تکرارهای بدون بودجه (Unbudgeted Retries) به یک حلقه بازخورد مخرب و در نهایت یک قطعی گسترده تبدیل شد.
تصور کنید در یک کافه شلوغ، دستگاه اسپرسو برای ۵ دقیقه کند می‌شود. به‌جای منتظر ماندن، هر مشتری که نوشیدنی‌اش را بلافاصله دریافت نکرده، مدام و پشت‌سرهم سفارش خود را تکرار می‌کند. حتی پس از اینکه دستگاه درست می‌شود، کارکنان چنان غرق در کوهی از درخواست‌های تکراری و انباشته شده هستند که نمی‌توانند به مشتریان جدید خدمات دهند؛ این‌گونه یک اختلال کوتاه به هرج‌ومرج صبحگاهی تبدیل می‌شود.
Arc Ops این سناریو را با استفاده از یک شبیه‌ساز مرورگر مستقل با ۱۰۰ قصد (Intent) در هر بازه و ظرفیت ۱۲۰ مورد آزمایش کرد. وقتی ظرفیت برای ۱۰ بازه به ۴۰ کاهش یافت، نتایج بسته به استراتژی تکرار به‌شدت متفاوت بود:
- بدون بودجه (گروه کنترل): ۴۵۴۳ درخواست شکست خورد؛ از این تعداد، ۲۹۸۹ مورد حتی پس از رفع علت اصلی شکست خوردند و این امر باعث شد قطعی تا ۳۹ بازه طولانی شود.
- با بودجه (نسبت ۰.۱۰): تنها ۷۳۰ درخواست شکست خورد و سیستم فوراً (در ۰ بازه اضافی) بازیابی شد.
- بودجه + مدارشکن (Circuit Breaker): ۱۲۲۴ درخواست شکست خورد اما بازیابی در ۲ بازه رخ داد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی پایداری زیرساخت‌های توزیع‌شده اشاره کردیم، مدیریت ترافیک در لحظات بحرانی حیاتی است. این شبیه‌سازی ثابت می‌کند که تعیین محدودیت تکرار برای هر فراخوانی (مثلاً max_retries: 3) خطرناک است، زیرا تعداد خطاها را در تعداد کل کلاینت‌ها ضرب می‌کند و بار سیستم را به شدت افزایش می‌دهد. در مقابل، بودجه تکرار که به‌عنوان کسری از ترافیک موفق تعریف می‌شود، بار کل ناوگان (Fleet Load) را فارغ از تعداد کلاینت‌ها، در سطح ۱.۱ برابر حالت عادی محدود می‌کند.
با این حال، داده‌ها یک موازنه متناقض را فاش می‌کنند. در حالی که بودجه تکرار مانع از فروپاشی کامل سیستم می‌شود، اما در واقع تعداد درخواست‌های حذف‌شده (Dropped Intents) را برای برخی کاربران افزایش می‌دهد. در حالت کنترل (بدون بودجه)، سیستم در نهایت تمام درخواست‌ها را نجات می‌دهد، اما این کار را با تحمیل ۳۸۰۰ شکست اضافی به ترافیکی انجام می‌دهد که هرگز بخشی از حادثه اصلی نبودند. این پدیده یادآور مکانیزم‌های خودترمیمی در سیستم‌هاست که گاهی با پنهان کردن خطاهای حیاتی، ریشه اصلی مشکل را نامرئی می‌کنند.
این تغییر در رویکرد عملی نشان می‌دهد که هدف از بودجه تکرار، کوچک کردن ابعاد حادثه نیست، بلکه تصمیم‌گیری درباره این است که «چه کسی هزینه را بپردازد». این استراتژی سلامت سرویس وابسته (Dependency) را به قیمت شکست درخواست‌های خاص تضمین می‌کند.
علاوه بر این، یافته‌های Arc Ops باورهای رایج درباره لرزش (Jitter) و مدارشکن‌ها را به چالش می‌کشد. لرزش کامل (Full Jitter) به‌تنهایی نتوانست پیک‌های ترافیکی را در شرایطی که ۲۰۰ کلاینت به‌طور هم‌زمان شکست می‌خوردند، جذب کند. همچنین مدارشکن‌ها بیش از حد سخت‌گیرانه و «کُند» عمل کردند؛ به‌طوری که وقتی یک سرویس وابسته ۳۰٪ دچار مشکل بود، مدارشکن ۱۰۰٪ ترافیک را قطع کرد و باعث شد پاسخ‌های سالم و قابل استفاده دور ریخته شوند.
توسعه‌دهندگان می‌توانند این مکانیسم‌ها را از طریق مخزن عمومی Arc Ops در گیت‌هاب (تحت لایسنس MIT) بررسی کنند. این مخزن شامل ۲۳۸ مورد تست pytest است تا حالت‌های شکست را بدون نیاز به شبکه یا مدل واقعی اعتبارسنجی کند.
گام بعدی شما
- بررسی مخزن عمومی Arc Ops در گیت‌هاب برای دسترسی به ۲۳۸ مورد تست pytest جهت اعتبارسنجی حالت‌های شکست.
- جایگزینی محدودیت‌های
max_retriesبا مدل بودجه‌بندی در سرویس‌های با ترافیک بالا. - بازنگری در تنظیمات مدارشکن‌ها برای جلوگیری از حذف ترافیک سالم.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو