cut lan
IT outages

هشت قطعی بزرگ فناوری اطلاعات در تاریخ

اینترنت بخشی جدایی‌ناپذیر از زندگی روزمره ماست. وقتی چنین منبعی از کار می‌افتد، تأثیرات آن می‌تواند فلج‌کننده باشد.

برای رتبه بندی این دست مشکلات در فناوری ها مواردی چون مقیاس ، مدت زمان و خسارت وارده حائز اهمیت هستند اما ما در این مقاله مواردی را لیست کرده ایم که بیشتر در ذهن مردم باقی مانده و اثر آن برایشان ملموس تر بوده است.

What-is-a-DDoS-attack

۱. Dyn (2016)

تنها مورد این لیست که تحت یک حمله سایبری قرار گرفت شرکت Dyn است . این شرکت ارائه‌دهنده سرویس DNS ، که مسئول ترجمه آدرس‌های URL قابل فهم برای انسان‌ها به آدرس‌های IP بود و پس از این حمله توسط اوراکل خریداری شد.

 Dyn در تاریخ 21 اکتبر 2016 حدود دو ساعت از دسترس خارج شد ، این حمله از طریق یک بات‌نت انجام شد (مجموعه‌ای از دستگاه‌های متصل به اینترنت که با بدافزار Mirai آلوده شده بودند ) که به صورت هماهنگ به سرورهای Dyn حمله می‌کردند و آنها را کاملاً از کار می‌انداختند و باعث شد یکی از بزرگترین حملات  (DDoS) در تاریخ رخ دهد و در نتیجه بسیاری از سایت‌ها و خدمات بزرگ مانند CNN، Netflix، Twitter و Reddit که در اروپا و آمریکا برای خدمات DNS به Dyn وابسته بودند، به مدت دو ساعت از دسترس خارج شدند.

 

(DNS: Domain Name System، سیستمی که آدرس‌های وبسایت‌ها را به آدرس‌های IP قابل‌فهم برای ماشین‌ها تبدیل می‌کند تا مرورگرها بتوانند به سایت‌ها دسترسی پیدا کنند.)

amazon

2. Amazon Web Services (AWS)(2017)

در مثالی از یک اشتباه پرهزینه تایپی در فوریه 2017 ، آنچه باید یک رفع اشکال ساده در  Simple Storage Service (S3) آمازون می‌بود، به‌سرعت به یک مشکل پیچیده تبدیل شد و خدمات را برای تقریباً چهار ساعت متوقف کرد.
(S3: یکی از خدمات ذخیره‌سازی ابری AWS است که به کاربران اجازه می‌دهد داده‌های خود را به صورت ایمن ذخیره و بازیابی کنند.)

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

این سرورها از دو زیربخش کلیدی در منطقه ویرجینیای شمالی پشتیبانی می‌کردند و اختلال به این معنی بود که آنها به یک راه‌اندازی کامل مجدد نیاز داشتند. در طول این مدت، سایر خدمات AWS که به S3 برای ذخیره‌سازی وابسته بودند، مانند Elastic Compute Cloud و Elastic Block Store نیز از دسترس خارج شدند.

(Elastic Compute Cloud و Elastic Block Store: سرویس‌های ابری AWS که منابع محاسباتی و ذخیره‌سازی فراهم می‌کنند.)

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

verizon

3. Verizon (2019)

در اتفاقی که می‌توان آن را به یک ازدحام ترافیک اینترنتی تشبیه کرد، Verizon دچار قطعی‌ای شد که حدود سه ساعت، از حدود 6:30 صبح در تاریخ 24 ژوئن 2019 آغاز شد. این مشکل به دلیل نقص در پروتکل Border Gateway Protocol (BGP) بود که مسئول اتصال شبکه‌ها به یکدیگر و هدایت ترافیک بین آنهاست.
(BGP: پروتکل مسیریابی بین شبکه‌ای که تعیین می‌کند بسته‌های داده به چه مسیری در اینترنت باید هدایت شوند.)

در این حادثه، تمامی ترافیک اینترنتی Verizon از طریق DQE Communications، یک ارائه‌دهنده کوچک خدمات اینترنتی (ISP) در پنسیلوانیا، هدایت شد. DQE از یک بهینه‌ساز BGP از شرکت Noction استفاده می‌کرد که اطلاعات مسیریابی را ابتدا به یک مشتری – Allegheny Technologies – و سپس به Verizon منتقل کرد. این مسیریابی به جای اینکه متوقف شود، به اینترنت منتشر شد، مشکلی که باید با فیلتر کردن مسیریابی توسط Verizon جلوگیری می‌شد اما این فیلتر وجود نداشت. بخش‌های بزرگی از ترافیک اینترنتی از طریق DQE و Allegheny هدایت شدند، که شبکه‌های آنها قادر به مدیریت چنین بار سنگینی نبودند. علاوه بر Cloudflare، خدمات بزرگی مانند Amazon، Google و Facebook نیز دچار اختلال شدند.

google-authenticator

4. Google (2020)

با اینکه زمان قطعی فقط 47 دقیقه بود اما کاربران سراسر جهان در صبح روز 14 دسامبر 2020 تأثیرات آن را حس کردند، زیرا نتوانستند به هیچ سرویسی که به حساب Google نیاز داشت، دسترسی پیدا کنند. این سرویس‌ها شامل Gmail، Google Drive و YouTube بودند.
(Google authentication services: خدمات احراز هویت گوگل که برای دسترسی به سرویس‌های گوگل نیاز است.)

گوگل از یک سیستم سهمیه‌بندی (quota system) برای مدیریت و تخصیص فضای ذخیره‌سازی برای خدمات احراز هویت خود استفاده می‌کند و اوایل همان سال به یک سیستم جدید سوئیچ کرده بود که متأسفانه بخش‌هایی از سیستم سهمیه‌بندی قدیمی در طول این جابجایی بدون تغییر باقی ماند و باعث شد که به‌طور نادرست استفاده از منابع را گزارش کند. اگرچه برخی سیستم‌های پشتیبان وجود داشت، اما هیچ‌کدام از آنها این سناریو را پیش‌بینی نکرده بودند. داده‌های جدید احراز هویت نمی‌توانستند نوشته شوند و به سرعت منقضی شدند، که منجر به خطاهای جستجوی احراز هویت و در نهایت سقوط سیستم شد.

Fastly-Coverage.original

5. Fastly (2021)

Fastly یک شبکه تحویل محتوا (Content Delivery Network یا CDN) است که مجموعه هایی مانند BBC، Shopify، Amazon، CNN و دولت‌های ایالات متحده و بریتانیا را پشتیبانی می‌کند. تمامی این خدمات هنگامی که Fastly در 8 ژوئن 2021 قطع شد، تحت تأثیر قرار گرفتند.
(CDN: Content Delivery Network، شبکه‌ای از سرورها که محتوا را با سرعت بیشتر به کاربران نهایی ارائه می‌دهد.)

Fastly در ماه مه 2021 یک به‌روزرسانی نرم‌افزاری منتشر کرد که حاوی یک باگ بود. اما این باگ فقط در شرایط خاصی فعال می‌شد، به همین دلیل حدود یک ماه طول کشید تا شناخته شود. در حدود ساعت 5:47 صبح به وقت استاندارد شرقی در 8 ژوئن، یکی از مشتریان یک تغییر پیکربندی را ارسال کرد که باعث فعال شدن این باگ شد. مقیاس این قطعی بسیار بزرگ بود و Fastly گزارش داد که 85 درصد از شبکه‌اش دچار خطا شده است.

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

meta

6. Meta (Facebook, Instagram, WhatsApp) (2021)

سیستم‌های ایمنی فقط زمانی مفید هستند که خودشان دچار نقص نشوند. Meta، شرکت مادر Facebook، Instagram و WhatsApp، این موضوع را به سختی در 4 اکتبر 2021 تجربه کرد.

در حین انجام تعمیرات دوره‌ای، یک دستور صادر شد تا ظرفیت شبکه Facebook ارزیابی شود. اما این دستور تمامی مراکز داده شرکت را در سراسر جهان قطع کرد. طبق گفته Meta، باید توسط سیستم‌های نظارت (auditing)  از وقوع این رویداد جلوگیری می‌شد، اما یک باگ در ابزار نظارت باعث شد که این دستور اجرا نشود در نتیجه تمامی خدمات Meta به مدت نزدیک به هفت ساعت از دسترس خارج شدند.

(Auditing: فرآیندی که در آن سیستم‌ها به‌طور خودکار دستورات و تغییرات را قبل از اجرا بررسی می‌کنند تا از خطاها جلوگیری شود.)

در حالی که خسارت‌های ناشی از این قطعی دشوار است که به‌طور دقیق ارزیابی شوند، Facebook در طول این قطعی 47.3 میلیارد دلار از ارزش بازار خود را از دست داد.

rogers

7. Rogers Communications (2022)

مشابه با قطعی Verizon در سال 2019، ارائه‌دهنده خدمات مخابراتی کانادایی Rogers Communications در 2022 دچار یک قطعی بزرگ به دلیل مشکل مسیریابی شد. طبق گزارشی از کمیسیون رادیو-تلویزیون و ارتباطات کانادا (CRTC)، این قطعی بیش از 12 میلیون کاربر را در سراسر کشور تحت تأثیر قرار داد.

در این مورد نیز خطای انسانی نقش مهمی ایفا کرد. در هنگام پیکربندی روترهای توزیع‌کننده که مسئول هدایت ترافیک اینترنتی هستند، کارکنان Rogers یکی از فیلترهای کلیدی به نام  Access Control List یا ACL را حذف کردند. نتیجه این بود که تمامی مسیرهای احتمالی به اینترنت از طریق روترهای شبکه اصلی Rogers عبور کردند، که در نهایت باعث شد این روترها از ظرفیت خود عبور کرده و دچار اختلال شوند. این قطعی نزدیک به یک روز طول کشید و طی آن شبکه‌های موبایل، اینترنت و حتی خدمات اضطراری 911 از دسترس خارج شدند.
(Access Control List یا ACL: لیستی از قوانین که دسترسی به منابع شبکه را کنترل می‌کند.)

crowdstrike

8. CrowdStrike (2024)

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

در ساعات اولیه 19 جولای 2024 به وقت استاندارد شرقی، شرکت امنیت سایبری CrowdStrike به‌روزرسانی‌ای برای Falcon Sensors بر روی سیستم عامل های Microsoft Windows در سراسر جهان منتشر کرد. اما این به‌روزرسانی حاوی یک فایل پیکربندی معیوب بود که باعث خرابی ماشین‌ها و نمایش صفحه آبی مرگ (Blue Screen of Death یا BSOD) شد. CrowdStrike مشکل را شناسایی کرد و به‌روزرسانی را پس از حدود یک ساعت لغو کرد، اما برای سیستم‌هایی که در آن بازه زمانی به سرویس ابری CrowdStrike متصل شده بودند، این اقدام بسیار دیر بود. بر اساس تخمین‌های Microsoft، حدود 8.5 میلیون دستگاه در صنایع مختلف، از جمله سفر، امور مالی و بهداشت و درمان، تحت تأثیر قرار گرفتند.
(Falcon Sensors: یکی از محصولات امنیتی CrowdStrike که برای نظارت بر فعالیت‌های مشکوک در دستگاه‌های میزبان استفاده می‌شود.)

به دلیل اینکه فایل مشکل‌دار مانع از راه‌اندازی Windows می‌شد، راه‌حل توصیه‌شده زمان‌بر بود و نیاز داشت که کاربران سیستم‌ها را در حالت Safe Mode راه‌اندازی کرده و به دایرکتوری مربوطه مراجعه کنند تا فایل مشکل‌دار را حذف کنند. Microsoft و CrowdStrike در نهایت دستورالعمل‌هایی را برای حل مشکل با استفاده از درایوهای USB بوت‌پذیر منتشر کردند. اما با توجه به مقیاس گسترده این قطعی، فرایند رفع مشکل بسیار زمان‌بر و دشوار بود.

اگرچه برخی سیستم‌ها طی چند ساعت بازیابی و آنلاین شدند، اما تا 29 جولای ساعت 8 عصر، یعنی 10 روز بعد، CrowdStrike اعلام کرد که تقریباً 99% از سنسورهای Windows آنلاین شده‌اند. اثرات ماندگار این قطعی به‌طور مشهود در مشکلات شرکت‌هایی مانند American Airlines، United Airlines و Delta Airlines دیده شد که حتی روزها پس از این نقص همچنان مشکلاتی داشتند.

علل رایج قطعی‌های فناوری اطلاعات

یکی از نکات مهمی که هنگام بررسی بزرگترین قطعی‌های IT تاریخ باید به آن توجه داشت این است که این قطعی‌ها می‌توانند ناشی از عوامل مختلفی باشند و تا حدی اجتناب‌ناپذیر هستند. برخی از رایج‌ترین علل این قطعی‌ها عبارتند از:

– خطای انسانی:

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

– خرابی سخت‌افزاری:

برخی از قطعی‌های پیش‌بینی‌نشده به خرابی‌های سخت‌افزاری مربوط می‌شوند. قطعی‌های برق و بلایای طبیعی نیز می‌توانند سخت‌افزارها را تحت تأثیر قرار دهند.

– رفتار مخرب:

یک قانون خوب این است که همیشه مراقب فعالیت‌های مشکوک آنلاین باشید، زیرا حملات سایبری می‌توانند رخ دهند. این شامل حملات DDoS، نقض داده‌ها و حملات باج‌افزار است.

چگونه برای قطعی‌ها آماده شویم:

آمادگی کامل برای قطعی‌ای که پیش‌بینی نمی‌شود، غیرممکن است. اما برخی اقدامات وجود دارند که هم ارائه‌دهندگان و هم کاربران نهایی می‌توانند برای کاهش اثرات قطعی‌ها انجام دهند:

– داشتن شبکه ایمنی:

 شاید بی‌نقص نباشند، اما سیستم‌های افزونگی (redundancy) و سیستم‌های failover که اجازه می‌دهند یک سیستم به‌صورت خودکار به زیرساخت‌های پشتیبان سوئیچ کند، می‌توانند نقش بزرگی در حفاظت داشته باشند. سیستم هشدار و نظارت نیز کمک‌کننده هستند.

– آزمایش و ارتباط:

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

– پشتیبان‌گیری:

کاربران نهایی همیشه باید منابع آفلاین در اختیار داشته و از داده‌ها و زیرساخت‌های خود نسخه پشتیبان تهیه کنند تا در صورت بروز قطعی به آنها دسترسی داشته باشند. پشتیبان‌گیری‌های منظم نیز می‌تواند کمک‌کننده باشد.

Scroll to Top