ساعاتی پس از نیمهشب ۱۷ ژوئیه، هزاران کاربر AWS کنسول خود را باز کردند و با ارقامی وحشتناک مواجه شدند: صورتحسابهای برآوردی چند میلیون، چند میلیارد و حتی چند تریلیون دلاری. یکی از حسابهایی که هزینه ماهانهاش زیر ۵ دلار بود، برآورد ۱.۷ میلیارد دلار نشان میداد. کاربری در Reddit اسکرینشاتی منتشر کرد که مبلغ ۲۲۵٬۵۷۹٬۲۱۰٬۱۶۴ دلار را نمایش میداد. داشبورد دیگری ادعای ۷.۱ تریلیون دلار هزینه از ابتدای ماه کرد؛ مبلغی که بیش از دو برابر ارزش بازار آمازون است.
ارقام اشتباه بودند و فاکتورهای واقعی هرگز تحت تأثیر قرار نگرفتند، اما این رویداد بیش از ۲۴ ساعت طول کشید و نحوه وقوع آن، بیش از اعداد مضحک، درباره نقطهضعف مدیریت هزینههای ابری سخن میگوید.
آغاز ماجرا: خطای پیکربندی در خط لوله صورتحساب
بر اساس گزارش داشبورد سلامت AWS، مشکل در ۱۶ ژوئیه ساعت ۷:۴۶ عصر به وقت محلی آغاز شد. یک تغییر پیکربندی در سیستم محاسبه صورتحساب، خطای قیمتگذاری واحد را به خط لوله صورتحساب برآوردی تزریق کرد. آنچه پس از آن رخ داد، بخشی است که هر مهندس دواپس باید آن را با دقت بخواند. AWS در گزارش رسمی خود نوشت:
«در ۱۶ ژوئیه ساعت ۷:۴۶ عصر، هشدارهای ما ناهنجاریهای هزینه را تشخیص دادند اما نتوانستند روند تولید صورتحساب برآوردی را متوقف کنند یا تیمهای مهندسی را مطلع سازند. ما در ۱۷ ژوئیه ساعت ۱۲:۱۹ بامداد از طریق درخواستهای پشتیبانی مشتریان متوجه این مشکل شدیم و بلافاصله تحقیقات را آغاز کردیم.»
هشدارها به صدا درآمدند، خط لوله همچنان به تولید صورتحساب ادامه داد و هیچ مهندسی پیج دریافت نکرد. درخواستهای پشتیبانی مشتریان چهار ساعت و نیم پس از فعال شدن سیستم تشخیص خود شرکت به AWS رسید. AWS متوجه خراب بودن سیستم صورتحساب خود شد چون مشتریان به آن گفتند. این دقیقاً همان روشی است که بیشتر تیمها هزینههای خارج از کنترل خود در AWS را کشف میکنند — فقط این بار نقشها برعکس بود.
علت ریشهای: خطای واحد در قیمتگذاری
مکانیسم احتمالی پشت این خطا برای حداقل یک مهندس که قبلاً دقیقاً همین دست باگ را منتشر کرده، آشناست. یکی از کاربران Hacker News با توصیف تجربه دستاول خود در AWS، توضیح داد که خط لوله صورتحساب چگونه دادههای اندازهگیری را به برنامههای قیمتگذاری متصل میکند:
«من در AWS با این خطا برخورد کردهام. یک خطای واحد بود. قرار بود حدود ۵ سنت به ازای هر گیگابایت هزینه دریافت کنیم، اما واحد GB را فراموش کردیم و سیستم صورتحساب به طور پیشفرض به بایت تغییر کرد. ۵ سنت به ازای هر بایت داده منتقلشده به این معنا بود که برخی مشتریان در عرض چند ساعت با صورتحسابهای میلیونی مواجه شدند. حدود ساعت ۲ بامداد توسط تیم پشتیبانی پیج شدم، تا ساعت ۳-۴ بامداد اصلاح و اصلاحیهها صادر شد و کمی بعد ایمیلهای عذرخواهی ارسال شد.»
سرویسها مقادیر اندازهگیری را بدون قیمت صادر میکنند. هر آیتم در یک برنامه قیمتگذاری با یک نوع واحد تعریف میشود و نوع واحد اشتباه، تبدیل را به کل خراب میکند. تضاد این رویداد با ملاحظه برچسبهای زمانی مشخص میشود: آن باگ قبلی از پیج تا اصلاح حدود دو ساعت طول کشید، اما این بار چهار ساعت و نیم صرف شد تا اصلاً درخواستهای پشتیبانی مشتریان به مهندسان AWS برسد.
چرا تستها این باگ را ندیدند؟
یکی دیگر از کاربران Hacker News توضیح ساختاری برای نادیده گرفته شدن این نوع خرابی در تستها ارائه کرد:
«آزمایشهایی وجود داشته، اما آزمایشهای سرتاسری از قلم افتادهاند. آزمایش ۱ تأیید میکند که سیستم جدید ورودیهای صورتحساب را به روشی مورد انتظار صادر میکند. آزمایش ۲ در سیستم صورتحساب انجام میشود. اما این دو مورد با هم آزمایش نمیشوند چون سختتر است و تیمها زنجیرههای مدیریتی متفاوتی دارند. این را چند بار در چندین شرکت دیدهام.»
این توضیح، یکی از رایجترین الگوهای شکست در سیستمهای توزیعشده را روشن میکند: تیمها ماژولهای خود را بهطور ایزوله تست میکنند و ادغام سرتاسری یا فراموش میشود یا به دلیل پیچیدگیهای سازمانی به تعویق میافتد.
راهکار موقت که طنز ماجرا را کامل کرد
پس از آنکه عقبگرد تغییر پیکربندی نتوانست مشکل را حل کند، AWS ساعت ۸:۲۴ صبح تولید صورتحساب برآوردی را متوقف کرد، اعداد متورمشده را فریز کرد و هشدارهای بودجه و ناهنجاری هزینه را به عنوان اقدام احتیاطی خاموش کرد. در طول این مدت، دو مکانیسمی که AWS به عنوان تور ایمنی کنترل هزینه توصیه میکند، در سطح کل پلتفرم غیرفعال شدند.
هر تیمی که پاسخهای خودکار را به این هشدارها متصل کرده بود — از ارسال پیام در Slack و پیوست SCP تا خاموش کردن بار کاری — یا قبل از توقف توسط دادههای غلط فعال شده بود یا بعد از آن کاملاً نابینا شده بود. وضعیتی که پارادوکس کامل کنترل هزینه ابری را به نمایش گذاشت.
واکنش جامعه و کارشناسان
تالار گفتوگوی AWS در Reddit با پست کاربری مواجه شد که صورتحساب ۱.۷ میلیارد دلاری خود را گزارش کرد:
«مصرف عادی زیر ۵ دلار است. طبیعتاً تیکت پشتیبانی فوری AWS ایجاد کردهام. آیا کس دیگری هم چنین چیزی میبیند؟»
کوری کوئین، اقتصاددان ارشد ابری در The Duckbill Group، مقیاس ماجرا را در لینکدین به تصویر کشید و به حجم ناباوری اشاره کرد. این رویداد، در حالی که فاکتورهای واقعی آسیبی ندیدند، پرسشهای جدی درباره اتکاپذیری سیستمهای پایش هزینه در بزرگترین ارائهدهنده سرویسهای ابری جهان مطرح کرد.
درسهای قابل برداشت برای تیمهای مهندسی
- اتکاپذیری هشدارها: تشخیص ناهنجاری بدون توقف خط لوله و اطلاعرسانی به تیمهای مهندسی، عملاً بیفایده است. یک سیستم هشدار باید بتواند در صورت تشخیص خطای بحرانی، جریان دادهها را متوقف کند.
- اهمیت تستهای سرتاسری: تستهای ایزوله هر ماژول بهتنهایی کافی نیستند. یکپارچگی میان سرویسهای انتشار داده و سیستمهای پردازش باید بهطور کامل آزمایش شود.
- وابستگی به گزارش مشتری: زمانی که خود پلتفرم باید نخستین راوی خرابیهایش باشد، اتکا به گزارش مشتری نشاندهنده شکست لایههای پایش داخلی است.
باگ ۱۷ ژوئیه شاید فاکتورهای واقعی را دستنخورده گذاشته باشد، اما نمایشی شفاف از شکنندگی ابزارهای کنترل هزینههای ابری ارائه کرد — ابزارهایی که شرکتها روزانه میلیاردها دلار بودجه خود را به آنها گره میزنند و انتظار دارند در لحظه بحران، نخستین خط دفاعی عمل کنند.
