تصور کنید مدیر یک رستوران هستید که فقط تعداد مشتریان پشت میزها را می‌شمارد تا پیشخدمت جدید استخدام کند، اما متوجه نمی‌شود که صف طولانی در آشپزخانه است و غذاها هرگز به میز نمی‌رسند. این دقیقاً همان اتفاقی است که برای گیت‌هاب (GitHub) افتاد و منجر به یک قطعی گسترده شد.
این حادثه ثابت کرد که رفع یک قطعه «خراب» به‌تنهایی هرگز ناپایداری سیستمی را حل نمی‌کند. طبق گزارش منتشر شده، دلیل شکست این بود که سیاست مقیاس‌دهی خودکار (Autoscaling) — شبیه به یک ترموستات که با گرم شدن اتاق، کولر را روشن می‌کند — فقط وضعیت سرویس میزبان را می‌پایید و از محدودیت‌های پادِ ساید‌کار (Sidecar Pod) در ایستیو (Istio) غافل بود. در نتیجه، ساید‌کار به سقف ظرفیت هم‌زمانی (Concurrency Limits) خود رسید، اما چون سرویس اصلی «سالم» به نظر می‌رسید، هیچ گره جدیدی برای توزیع بار اضافه نشد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مدیریت پیچیدگی در زیرساخت‌های ابری اشاره کردیم، وابستگی‌های پنهان بین اجزا اغلب خطرناک‌تر از نقص‌های آشکار هستند.
درک مکانیزم مقیاس‌دهی خودکار
اکثر معماری‌های مدرن ابری برای مدیریت ترافیک نوسانی به مقیاس‌دهی خودکار متکی هستند. مقدار منابع پردازشی و حافظه‌ای که یک سرویس نیاز دارد، مستقیماً به باری که روی آن قرار می‌گیرد بستگی دارد؛ باری که معمولاً همان درخواست‌های خارجی (ترافیک) است. در پلتفرمی مثل گیت‌هاب، فشار روی منابع احتمالاً در ساعات کاری به اوج می‌رسد و در شب‌ها و آخر هفته‌ها کاهش می‌یابد.
مهندسان برای مدیریت این وضعیت، دو استراتژی کلی دارند. آن‌ها یا می‌توانند زیرساخت را برای «پیک ترافیک» (Peak Load) آماده کنند (که منجر به اتلاف منابع می‌شود) یا منابع را به‌صورت پویا بر اساس بار فعلی تنظیم کنند. مورد دوم همان مقیاس‌دهی خودکار است. برای اجرای این استراتژی، مهندسان باید یک «سیاست» (Policy) تعریف کنند. این سیاست باید معیارهای خاصی را برای نمایش میزان بار انتخاب کند و مشخص کند که با تغییر این معیارها، منابع چگونه باید اضافه یا حذف شوند.
محدودیت‌های معیارهای CPU
استفاده از میزان بهره‌وری CPU یکی از رایج‌ترین معیارها برای مقیاس‌دهی خودکار است، اما این معیار می‌تواند فریب‌دهنده باشد. یک سرویس می‌تواند کاملاً اشباع شود، در حالی که مصرف CPU همچنان پایین باقی مانده است.
این چالش در مدیریت منابع سخت‌افزاری رایج است؛ برای مثال، برخی شاخص‌های نظارتی در GPUها نیز می‌توانند تصویری نادرست از کارایی واقعی مدل ارائه دهند و منجر به تصمیمات مدیریتی غلط شوند.
به عنوان مثال، در حادثه‌ای که سال ۲۰۲۱ برای اسلک (Slack) رخ داد، سرویسی که از مدل «یک رشته برای هر درخواست» (thread-per-request) به همراه یک Threadpool استفاده می‌کرد، دچار اشباع شد. دلیل این اتفاق افزایش تأخیر (Latency) در درخواست‌های پایین‌دستی بود. در آن حالت، تمام رشته‌های موجود در استخر (Pool) در انتظار پاسخ‌های I/O متوقف شدند. در حالی که سرویس اشباع شده بود و به پادهای جدید نیاز داشت، مصرف CPU پایین بود زیرا رشته‌ها در حالت بیکار (Idle) بودند. اسلک این مشکل را با افزودن قوانینی برای مقیاس‌دهی سریع بر اساس «تعداد رشته‌ها» حل کرد.
در مورد گیت‌هاب، مالکان سرویس مسئولیت هر دو بخش «منطق تجاری» و «سیستم کنترل عملیاتی سفارشی» را بر عهده داشتند. از آنجایی که هر سرویس تحت فشار بار رفتاری متفاوت دارد، این سیاست‌های مقیاس‌دهی در واقع «سفارشی» (Custom) هستند. این موضوع ریسکی بزرگ ایجاد می‌کند؛ زیرا مالکان سرویس که لزوماً متخصص مقیاس‌دهی خودکار نیستند، پارامترهای پیچیده‌ای را مدیریت می‌کنند که تنها از طریق تست‌های فشار (Load Testing) قابل تأیید هستند.
تحلیل فنی شکست
طبق گزارشی که در ۲۰ اوت ۲۰۲۶ در وبلاگ surfingcomplexity.blog منتشر شد، این قطعی حاصل زنجیره‌ای از شکست‌های متقابل بود:
- اشباع ساید‌کار ایستیو: ساید‌کار به محدودیت‌های هم‌زمانی رسید، در حالی که سرویس میزبان همچنان سالم به نظر می‌رسید. در معماری‌های مشابه، استفاده از ساید‌کارها برای بهینه‌سازی مصرف منابع و مدیریت درخواست‌ها بسیار رایج است، اما همان‌طور که در مورد گیت‌هاب دیدیم، این لایه می‌تواند به یک نقطه شکست تبدیل شود.
- نقطه کور سیاست: قوانین مقیاس‌دهی از معیارهای باری استفاده می‌کردند که فقط خودِ سرویس را در نظر می‌گرفت و محدودیت‌های ساید‌کار را نادیده می‌گرفت.
- جهش‌های ترافیکی: تغییر در الگوهای ترافیکی، از جمله فعالیت ربات‌های استخراج داده (Scrapers)، روند اشباع را تسریع کرد.
- اثرات آبشاری: این شکست با منطق تلاش مجدد (Retry logic)، ترافیک احراز هویت و اشباع گره‌های HAProxy تداخل پیدا کرد.
این اتفاق مصداق «مغالطه جایگزینی قطعات» (Component Substitution Fallacy) است؛ مفهومی که توسط پژوهشگری به نام دیوید وودز (David Woods) مطرح شده است. این مغالطه یعنی باور به این که پایداری سیستم صرفاً با شناسایی و تعویض قطعات معیوب بهبود می‌یابد.
پایداری سیستمی در مقابل اصلاحات قطعه‌ای
در واقعیت، اکثر سیستم‌ها پر از نقص‌های نهفته (Latent Defects) هستند که تا زمانی که مجموعه‌ای خاص از تعاملات رخ ندهد، باعث کرش کردن نمی‌شوند. اگر نقص‌های تک‌تک قطعات به تنهایی برای از کار انداختن سیستم کافی بودند، سیستم‌ها همین حالا هم از کار افتاده بودند.
قطعی گیت‌هاب فقط به دلیل یک سیاست اشتباه نبود، بلکه حاصل تلاقی الگوهای ترافیکی، بار احراز هویت و محدودیت‌های ساید‌کار بود. برای مهندسان، این یعنی باید «تعاملات بین اجزا» را به عنوان شهروند درجه اول در طراحی سیستم در نظر بگیرند.
تکیه بر گزارش‌های عمومی (Write-ups) اغلب ناکافی است، زیرا حیاتی‌ترین داده‌ها در گزارش‌های داخلی باقی می‌مانند. برای درک واقعی شکست، باید سوالات عمیق‌تری پرسید: آیا این سیاست پیش از استفاده از ساید‌کارهای ایستیو تعریف شده بود؟ آیا افزایش ترافیک یک جهش ناگهانی بود یا یک صعود تدریجی؟ چه نوع درخواست‌های خاصی در این فرآیند دخیل بودند؟
اگر شما فقط باگی را که در یک حادثه کشف شده اصلاح کنید، سیستم را در برابر نقص نهفته بعدی آسیب‌پذیر می‌گذارید. پایداری واقعی از تست فشار روی تعاملات بین اجزا به دست می‌آید، نه فقط تست تک‌تک قطعات.
گام بعدی شما
- بازبینی سیاست‌های مقیاس‌دهی خودکار و اطمینان از اینکه تمام لایه‌های مسیر درخواست (از جمله Sidecars و Gateways) پایش می‌شوند.
- جایگزینی معیارهای ساده مانند CPU با معیارهای عملیاتی‌تر مانند تعداد درخواست‌های در جریان (In-flight requests).
- اجرای تست‌های فشار سناریو-محور برای شناسایی نقاط شکست در تعاملات بین سرویس‌ها.
اما داستان سخت‌افزاری این تحولات حتی پیچیده‌تر است — به تحلیل ما درباره‌ی بهینه‌سازی لایه‌ی شبکه در مراکز داده مراجعه کنید.
گفتگو