اختلال دوباره AWS در us-west-2؛ همان مسیر شبکه‌ای قطعی ژوئیه دوباره دچار مشکل شد

اگر قرار باشد یک قاعده طلایی در مهندسی قابلیت اطمینان نام ببریم، این است که «دو بار افتادن در یک چاله، دیگر اتفاق نیست؛ الگوست». در میانه اوت ۲۰۲۶، ریجن us-west-2 (اورگان) آمازون برای دومین بار در عرض یک ماه دچار اختلال اتصال شد و تحلیل منتشرشده توسط Pagerly در ۲۰ اوت نشان می‌دهد که ریشه مشکل دوباره به تجهیزات شبکه‌ای برمی‌گردد که ترافیک را به‌سوی کلان‌شهر سیاتل هدایت می‌کنند — دقیقاً همان مسیری که در قطعی ژوئیه مقصر شناخته شده بود.

#چه اتفاقی افتاده است؟

بر اساس تحلیل Pagerly، اختلال اخیر حدود ۲۰ دقیقه طول کشید و پس از آن یک رویداد ۱۲ دقیقه‌ای «همگرایی مجدد» (reconvergence) شبکه رخ داد تا جداول مسیریابی به وضعیت پایدار بازگردند. این چهارمین رخداد قابل‌توجه قابلیت اطمینان AWS از می ۲۰۲۶ تاکنون است. هرچند ۲۰ دقیقه در مقایسه با قطعی‌های تاریخی چندساعته AWS ناچیز به نظر می‌رسد، اما برای بارهای کاری حساس به زمان — Jobهای دسته‌ای، سرویس‌های پرداخت، صف‌های پیام و پایپ‌لاین‌های داده — همین پنجره کوتاه می‌تواند به شکست کامل یک چرخه پردازش منجر شود.

اختلال حدود ۲۰ دقیقه‌ای و همگرایی ۱۲ دقیقه‌ای شبکه در us-west-2. — Pagerly

#جزئیات فنی

نکته فنی کلیدی، تکرار همان «مسیر شبکه» است. در معماری AWS، ترافیک بین‌ریجنی و خروجی به اینترنت از طریق ستون فقرات داخلی آمازون و نقاط تبادل منطقه‌ای عبور می‌کند. وقتی دو اختلال پشت سر هم به تجهیزات مسیریابی یک کریدور مشخص (در اینجا مسیر سیاتل) نسبت داده می‌شوند، فرضیه «نقطه شکست منفرد در لایه ترانزیت» تقویت می‌شود. پدیده reconvergence پس از رفع اختلال هم نشان می‌دهد که پروتکل‌های مسیریابی (احتمالاً BGP در مقیاس داخلی) برای بازگشت به حالت پایدار به زمان نیاز داشته‌اند — یعنی حتی پس از رفع علت ریشه‌ای، کاربران نهایی تا پایان همگرایی، ناپایداری را تجربه می‌کنند. از منظر معماری اپلیکیشن، این یعنی Timeoutهای پیش‌فرض کوتاه‌تر از پنجره همگرایی، خطاهای آبشاری ایجاد می‌کنند.

با نگاهی به الگوی کلی‌تر، این چهارمین رخداد قابل‌توجه AWS از می ۲۰۲۶ است و همین تراکم، خودش یک سیگنال است. مشتریان سازمانی بزرگ معمولاً پس از دو یا سه رخداد مرتبط در یک ریجن، بازنگری معماری چندریجنی را از سطح «توصیه» به سطح «الزام پروژه» می‌برند. نکته دیگر، محدودیت ذاتی ابزارهای پایش است: AWS Health Dashboard معمولاً رخدادهای کوتاه را با تأخیر و گاه به‌صورت خلاصه منعکس می‌کند و تیم‌هایی که صرفاً به همان داشبورد تکیه دارند، تصویر ناقصی از قابلیت اطمینان واقعی خواهند داشت. پایش مستقل از بیرون — با پروب‌های مصنوعی روی مسیرهای واقعی کاربر — در چنین شرایطی از تجملات به ضرورت تبدیل می‌شود.

#چرا مهم است؟

از منظر تحریریه، مهم‌ترین پیام این رخداد، عدد ۲۰ دقیقه نیست؛ تکرار الگوست. وقتی دو اختلال در یک ماه روی یک مسیر فیزیکی-منطقی رخ می‌دهد، فرض «قطعی‌های تصادفی و مستقل» فرو می‌ریزد و تیم‌های زیرساخت باید در طراحی failover چندریجنی خود، همبستگی ریسک را لحاظ کنند. نکته دوم، شکاف میان آستانه‌های رسمی و تجربه واقعی است: اختلال‌های زیر آستانه گزارش رسمی (SLO/SLA) ممکن است هرگز در صورتحساب جبران مشتری ظاهر نشوند، اما برای کاربران نهایی همان‌قدر واقعی‌اند. توصیه عملی برای معماران: Health Checkهای مستقل از AWS Health Dashboard، تایم‌اوت‌های سازگار با پنجره‌های همگرایی شبکه، و تست GameDay برای سناریوی «اختلال کوتاه اما تکرارشونده» باید در برنامه باشد.

#اعداد و ارقام

• حدود ۲۰ دقیقه اختلال + ۱۲ دقیقه همگرایی مجدد شبکه
• دومین اختلال us-west-2 در یک ماه؛ روی همان مسیر شبکه سیاتل
• چهارمین رخداد قابل‌توجه قابلیت اطمینان AWS از می ۲۰۲۶

برای مدیران زیرساخت، درس عملی این رخداد سه‌گانه است: نخست، فرض «استقلال رخدادها» را در مدل ریسک خود کنار بگذارید و برای سناریوی «تکرار اختلال در همان مسیر» برنامه داشته باشید؛ دوم، تایم‌اوت‌ها و مکانیزم retry را با پنجره‌های واقعی همگرایی شبکه هم‌راستا کنید تا خطاهای گذرا به شکست‌های دائمی تبدیل نشوند؛ و سوم، گزارش رخدادهای زیر آستانه SLA را در بررسی‌های فصلی ارائه‌دهنده ابری مطالبه کنید — چیزی که در صورتحساب دیده نمی‌شود، در مذاکره قرارداد هم دیده نخواهد شد.

#منابع

• Pagerly — تحلیل رخدادها
• AWS Health Dashboard