گزارش قطعی فستلی در 8 ژوئن 2021 (18 خرداد 1400)

8 ژوئن 2021 (18 خرداد 1400)، صدها سایت به مدت یک ساعت از دسترس خارج شدند. مشکل از CDN ارائه‌دهنده‌ی سرویس‌های خدمات ابری آنها بود: فستلی. یک سرویس بزرگ که مجموعه خدمات ابری متنوعی به مشتریانش ارائه می‌دهد. در این مطلب، ابتدا به نقل از گاردین (و این گزارش) کمی تاثیرات این اتفاق را گفته‌ام و سپس به نقل از پست وضعیت و خلاصه گزارش فستلی، مشکل پیش‌آمده و اقداماتی را که برای حل آن انجام دادند، آورده‌ام.

چه سرویس‌هایی دچار مشکل شدند؟

سایت‌ها و سرویس‌های زیادی در سراسر جهان از این حادثه تاثیر گرفتند و کمی بیش از یک ساعت از دسترسی خارج بودند. این اتفاق در اوایل صبح انگلستان و پیش از آغاز روز کاری در ایالات متحده‌ی آمریکا رخ داد. در همین مدت کوتاه این حادثه باعث قطع شدن درآمد میلیونی سایت هایی مثل آمازون، بوتز و eBay شد و درگاه‌های کلیدی دولتی را از دسترس خارج کرد.

تمام سرویس‌های .gov.uk (دامنه‌ی دولتی انگلستان) از دسترس خارج شدند و از جمله سیستم آنلاین مالیاتی و گمرک انگلستان و همچنین رزرو آنلاین آزمایش‌های اورژانسی کرونا مختل شد. همچنین وب‌سایت رسمی کاخ سفید از دسترس خارج شد (خطای 503).

همچنین با توجه به گزارش فروش سالانه‌ی 25 میلیارد پوندی آمازون و بوتز، این قطعی باعث حدود 3 میلیون پوند (نزدیک به 100 میلیارد تومان) ضرر به این دو شرکت شده است. قطعی پی‌پال هم (با توجه به گزارش معاملات 661 میلیارد پوندی آن در سال 2020) باعث شد حدود 106 میلیون دلار (بیش از 2860 میلیارد تومان) جریان پول این درگاه پرداخت قطع شود. سرویس‌های Etsy، سرویس تجارت الکترونیک Shopify و برنامه‌ی سفارش آنلاین غذای Deliveroo هم تحت تاثیر قرار گرفتند.

قطعی این سرویس برای رسانه‌های خبری ضرر تقریبی 300 هزار دلار (حدود 8 میلیارد تومان) را به همراه داشت (طبق تحلیل داده های پلتفرم AdSense گوگل). سایت نیویورک‌تایمز، فایننشال‌تایمز، سی‌ان‌ان، الجزیره، بلومبرگ، ایندیپندنت و بی‌بی‌سی تحت تاثیر این مشکل قرار گرفتند. سایت گاردین برای رفع مشکل، اطلاع‌رسانی‌های خود را در توئیتر انجام داد و بخش فناوری Verge اخبار را در یک سند اشتراکی در گوگل‌داک منتشر کرد (اما خبرنگار به شکل تصادفی لینکی را توئیت کرد که امکان ویرایش این سند را به مخاطبان می‌داد).

سایت پخش موسیقی اسپاتیفای با این قطعی حدود 100 هزار پوند (حدود 3 میلیارد تومان) ضرر کرد. ردیت، پینترست، توئیچ، HBO، ویمئو، کیک‌استارتر، گیت‌هاب، کوئرا، ایمگور و سرویس‌های دیگر هم قطع شدند. نکته‌ی جالب عدم امکان استفاده‌ی کاربران توئیتر از شکلک‌ها به علت این مشکل بود.

چنین مشکلاتی که سرویس‌های زیادی در سراسر جهان را تحت‌الشعاع قرار می دهند، پیش از این هم رخ داده است و علت آن این است که هر روز زیرساخت‌های اینترنت بیشتر در دست چند شرکت بزرگ قرار می گیرد. سال 2017، وب‌سرویس آمازون (AWS) دچار مشکل شد و سال 2020 کلافلر مشکل پیدا کرد.

گزارش اتفاق

این گزارش را نیک راکول (معاون ارشد بخش مهندسی و زیرساخت) در همان روز 8 ژوئن در وبلاگ فستلی نوشت:

سرویس فستلی 8 ژوئن به خاطر یک «باگ نرم‌افزاری حل‌نشده» دچار قطعی گسترده شد. این باگ وقتی رخ داد که یک «تغییر درست در تنظیمات سرویس مشتری» ایجاد شد. اختلال یک دقیقه بعد شناسایی شد، سپس مورد اشکال شناسایی و جداسازی شد و تنظیمات غیرفعال شد. بعد از 49 دقیقه، 95% شبکه به حالت عادی بازگشت.

فستلی به خاطر این قطعی گسترده و شدید از مشتریانش و همه‌ی کسانی که به این مشتریان مرتبط بودند، عذرخواهی می‌کند.

اما ماجرا چه بود؟

در تاریخ 12 می (22 اردیبهشت) یک پیاده‌سازی نرم افزاری آغاز شد که باعث می‌شد اگر یک مشتری در شرایطی خاص تغییری در تنظیمات انجام می‌داد، یک باگ ایجاد شود. در ساعات اولیه‌ی 8 ژوئن، یک مشتری چنین تغییرات درستی را در تنظیمات انجام داد و این باگ ایجاد شد. باگی که 85% شبکه‌ی فستلی را مختل کرد.

تایم‌لاین اتفاقات به این شرح است (زمان‌ها طبق «ساعت هماهنگ جهانی» -UTC- نوشته شده‌اند):

9:47 : شروع اولیه اختلال گسترده.
9:48 : اختلال گسترده توسط سیستم مونیتورینگ فستلی شناسایی شد.
9:58 : پست وضعیت منتشر شد.
10:27 : بخش مهندسی فستلی تنظیمات مشتری را شناسایی کرد.
10:36 : شروع پشتیبان‌گیری از سرویس‌های تاثیرگرفته.
11:00 : بیشتر سرویس‌ها بازیابی شدند.
12:35 : خطر حادثه کم‌تر شد.
12:44 : تغییر حالت پست وضعیت به «حل شده».
17:25 : پیاده‌سازی رفع باگ آغاز شد.

وقتی تاثیرات مشکل روی سرویس‌ها کاهش یافت، توجه ما به رفع اشکال و برقراری ارتباط با مشتریان معطوف شد. ساعت 17:25 رفع اشکال اصلی آغاز شد.

از این به بعد چه می کنیم؟

در کوتاه مدت:

در حال رفع مشکل در شبکه‌ی خود در سریع‌ترین و ایمن‌ترین حالت ممکن هستیم.
در حال تهیه‌ی یک «مستندسازی کالبدشکافی» کامل (post mortem) از فرایندها و رویه‌هایی هستیم که در این حادثه دنبال کرده‌ایم.
خواهیم فهمید که چرا باگ را در فرایندهای تضمین کیفیت و تست نرم افزار شناسایی نکردیم.
راه‌های بهبود مدت زمان اصلاح خود را ارزیابی خواهیم کرد.

همان طور که تاکنون تغییراتی اساسی و نوآورانه در امنیت پلتفرم‌های اصلی خود داده‌ایم، در ادامه هم خواهیم داد. به طور کلی، این یعنی از ظرفیت‌های جداسازی کامل WebAssembly و Compute@Edge برای ایجاد انعطاف اساسی استفاده کنیم. وقتی به این هدف نزدیک شویم، به‌روزرسانی بخش «انجمن» خود را ادامه خواهیم داد.

نتیجه گیری

حتی وقتی فقط شرایط خاصی باعث قطعی شود، باید از قبل این مسئله را پیش‌بینی کنیم. ما خدمات حساسی ارائه می‌دهیم و هر اقدامی می‌تواند باعث مشکلاتی در خدمات ما شود. به همین دلیل باید با نهایت حساسیت و اولویت به این مشکلات رسیدگی کنیم. از همه ی مشتریان خود و کسانی که به مشتریان ما وابسته بودند عذرخواهی می‌کنیم و صمیمانه از جامعه‌ی رایانه‌ای برای حمایتشان تشکر می‌کنیم. مشتریان همیشه می‌توانند برای اطلاعات بیشتر به ایمیل پشتیبانی ما، پیام دهند.

جزئیات اتفاق

این جزئیات شامل مواردی است که فستلی همزمان با بررسی و رفع مشکل به صورت عمومی منتشر می کرد (زمان‌ها باز هم طبق UTC است). برخی از تناقض‌ها از خود متن است و احتمالن به علت سرعت بالای به‌روزرسانی وضعیت رخ داده است:

9:58- بررسی: بررسی تاثیر احتمالی بر عملکرد سرویس های CDN
10:07- به‌روزرسانی: ادامه ی بررسی موضوع
10:11- به‌روزرسانی: ادامه ی بررسی موضوع
10:21- به‌روزرسانی: ادامه ی بررسی موضوع
10:23- به‌روزرسانی: ادامه ی بررسی موضوع
10:26- به‌روزرسانی: ادامه ی بررسی موضوع
10:44- به‌روزرسانی: مشکل تشخیص داده شد و رفع مشکل در حال پیاده سازی است.
10:57- به‌روزرسانی: مشکل تشخیص داده شد و رفع مشکل انجام شد. مشتریان ممکن است تا بازگشت سرویس‌های جهانی، با افزایش بار روبرو شوند.
11:57- به‌روزرسانی: رفع مشکل در ساعت 10:36 انجام شده. مشتریان ممکن است همچنان شاهد کاهش cache hit ratio (CHR: نسبت خواندن اطلاعات از کش) باشند.
12:41- حل شده: فستلی بازیابی همه ی سرویس ها را انجام داده است و این حادثه را حل کرده است. مشتریان ممکن است همچنان شاهد افزایش بار و کاهش CHR باشند.

(در ادامه ی گزارش فهرستی از مراکز تحت تاثیر قرار گرفته آمده است که شامل شهرهای مختلفی در سراسر جهان است).