رایانش ابری به ستون فقرات فناوری مدرن تبدیل شده است. از استارتاپهای کوچک گرفته تا شرکتهای بینالمللی، همگی برای میزبانی دادهها، اجرای برنامهها و ارائه خدمات آنلاین خود به بسترهای ابری تکیه دارند. با این حال، حتی بزرگترین و قدرتمندترین زیرساختهای ابری هم از بروز اختلال در امان نیستند.
وقوع خاموشی خدمات ابری یا همان Cloud Outages میتواند تاثیرات گستردهای بر عملکرد کسبوکارها بگذارد. از در دسترس نبودن وبسایت گرفته تا از کار افتادن سرویسهای حیاتی، هر اختلال حتی کوتاهمدتی میتواند به از دست رفتن درآمد، بیاعتمادی کاربران و حتی نقض توافقنامههای سطح خدمت (SLA) منجر شود.
در روزهای اخیر، اختلال گستردهای در زیرساخت ابری Amazon Web Services (AWS) رخ داد که باعث از کار افتادن موقت دهها سرویس و وبسایت در سراسر جهان شد. این رویداد، که از منطقه US-EAST-1 آغاز شد، موجب قطع دسترسی به پلتفرمهایی مانند Fortnite، Roblox، Snapchat و Amazon Alexa گردید. طبق اعلام رسمی آمازون، علت اصلی این مشکل به اختلال در سیستم DNS و سرویس پایگاه داده DynamoDB برمیگشت که منجر به بروز خطاهای زنجیرهای در سرویسهای وابسته شد. این حادثه بار دیگر اهمیت حیاتی طراحی زیرساختهای مقاوم در برابر خطا (Fault-Tolerant) و توزیع جغرافیایی سرویسها را یادآوری کرد، موضوعی که در ادامه این مطلب به بررسی آن و راهکارهای مشابه برای کاهش ریسک در زیرساختهای ابری خواهیم پرداخت.
در این مطلب به بررسی ماهیت خاموشیهای ابری، علل رایج وقوع آنها، وضعیت پایداری در میان ارائهدهندگان بزرگ، و در نهایت، راهکارهایی برای مقابله و کاهش اثرات احتمالی میپردازیم.
واقعیت خاموشیهای ابری
هرچند شرکتهای ارائهدهنده خدمات ابری معمولا وعده «۹۹.۹۹٪ در دسترس بودن» را میدهند، اما هیچ زیرساختی صددرصد پایدار نیست. دادههای سالهای اخیر نشان میدهد که در میان ارائهدهندگان بزرگ، هر یک بهطور میانگین چندین مورد اختلال در سال را تجربه کردهاند.
بهعنوان نمونه:
- برخی سرویسهای ابری در طول سال بیش از ۷۰ مورد اختلال جزئی یا عمده گزارش کردهاند.
- میانگین زمان هر خاموشی از کمتر از دو ساعت تا بیش از پنج ساعت متغیر بوده است.
- گاهی تنها یک منطقه جغرافیایی یا سرویس خاص دچار مشکل میشود، اما در مواردی دیگر، دامنه اختلال سراسری است و چندین مرکز داده را درگیر میکند.
اگرچه این خاموشیها معمولا موقتی هستند، اما تاثیر واقعی آنها بستگی به نوع و اهمیت سرویس درگیر دارد. برای مثال، قطع چندساعته سرویس احراز هویت یا پایگاه داده مرکزی ممکن است کل عملیات یک سازمان را مختل کند، در حالی که قطعی موقت یک سرویس جانبی ممکن است تقریباً بدون اثر باشد.
چرا خاموشیهای ابری رخ میدهند؟
هیچ سیستم توزیعشدهای از خطا در امان نیست. علل خاموشیهای ابری را میتوان در چند دسته کلی خلاصه کرد:
خطاهای نرمافزاری
بهروزرسانیهای نادرست، اشکالات در سورس کد، یا تغییرات ناهمخوان در نسخههای مختلف نرمافزار میتوانند موجب از کار افتادن بخشی از سرویس شوند. گاهی یک اصلاح جزئی در سیستم احراز هویت یا شبکه باعث زنجیرهای از خطاها در سایر بخشها میشود.
نقص سختافزاری
خرابی سرور، سوختن تجهیزات ذخیرهسازی یا قطع جریان برق از شایعترین دلایل اختلال فیزیکی هستند. با وجود مکانیسمهای افزونگی (redundancy)، در موارد نادر ممکن است چند مولفه همزمان از کار بیفتند و موجب توقف سرویس شوند.
مشکلات شبکه
اتصالات میان مراکز داده، سیستمهای DNS یا خطوط انتقال ممکن است دچار اختلال شوند. در بسیاری از خاموشیهای بزرگ، دلیل اصلی مربوط به پیکربندی اشتباه در شبکه یا خطای انسانی در اعمال تغییرات بوده است.
عوامل محیطی
بلایای طبیعی مانند زلزله، طوفان، آتشسوزی یا سیلاب نیز میتوانند منجر به از دست رفتن موقت دسترسی به مراکز داده شوند. هرچند مراکز مدرن برای چنین شرایطی طراحی میشوند، اما هیچ تمهیدی صددرصد تضمینکننده نیست.
حملات سایبری
حملات DDoS یا نفوذهای هدفمند میتوانند موجب از کار افتادن موقت بخشی از خدمات ابری شوند. اگرچه ارائهدهندگان بزرگ معمولا دارای سامانههای دفاعی گسترده هستند، اما هیچ زیرساختی در برابر حملات پیچیده کاملا ایمن نیست.
مدت زمان و دامنه خاموشی، دو عامل کلیدی
وقتی درباره خاموشیها صحبت میشود، بسیاری تنها به مدت زمان آن توجه دارند، در حالی که عامل مهمتر، دامنه تاثیر است.
برای مثال:
- یک قطعی ۳۰ دقیقهای در سامانه احراز هویت جهانی میتواند صدها سرویس وابسته را از کار بیندازد.
- در مقابل، یک خاموشی ۱۰ ساعته در یک منطقه خاص ممکن است تنها گروه محدودی از کاربران را تحت تاثیر قرار دهد.
از این رو، هنگام تحلیل دادههای مربوط به اختلال، باید هر دو بُعد زمان و دامنه را در نظر گرفت. در واقع، آنچه برای مدیران فناوری اهمیت دارد، نه فقط مدت خاموشی، بلکه پاسخ به این پرسش است که کدام بخش از سرویس و چه تعداد کاربر تحت تاثیر قرار گرفتهاند.
تفاوت در نحوه گزارشدهی و درک اشتباه از آمار
تمام ارائهدهندگان ابری روش واحدی برای گزارش اختلال ندارند. برخی از شرکتها هرگونه اختلال کوچک را بهعنوان حادثه ثبت میکنند، در حالی که برخی دیگر تنها خاموشیهای گسترده را گزارش میدهند.
همین تفاوت باعث میشود مقایسه مستقیم آمار بین شرکتها چندان دقیق نباشد.
برای نمونه، ممکن است یک ارائهدهنده تعداد زیادی رویداد ثبت کرده باشد، اما بیشتر آنها اختلالهایی بسیار کوتاهمدت یا محدود بودهاند. در مقابل، ارائهدهندهای دیگر با تعداد کمتر، اما با زمانهای طولانیتر، تصویر متفاوتی از پایداری ارائه میدهد.
بنابراین، تعداد رویدادها حتما به معنای کیفیت پایینتر سرویس نیست. باید جزئیات هر رویداد و تاثیر واقعی آن بررسی شود.
برای پروژههای مهم خود به دنبال سرور مطمئن هستید؟ خرید سرور مجازی با IP ثابت و سرعت بالا در پارسدو، گزینهای ایدهآل است.
پیامدهای خاموشی برای کسبوکارها
خاموشیهای ابری فقط مسئلهای فنی نیستند، بلکه میتوانند مستقیم بر جنبههای اقتصادی، عملیاتی و اعتباری سازمان اثر بگذارند.
زیان مالی
اختلال در فروشگاههای آنلاین یا سامانههای پرداخت، حتی برای چند دقیقه، میتواند خسارت مالی قابلتوجهی ایجاد کند. بر اساس برآوردهای جهانی، میانگین هزینه هر دقیقه از کار افتادن سرویسهای حیاتی بین چند هزار تا چند صد هزار دلار برآورد میشود.
آسیب به اعتماد کاربران
کاربران انتظار دارند سرویسهای ابری همیشه در دسترس باشند. تکرار خاموشیها یا پاسخگویی ضعیف در زمان بحران، باعث از بین رفتن اعتماد و در نهایت مهاجرت کاربران به رقبا میشود.
اختلال در عملیات داخلی
اگر زیرساخت ابری میزبان سیستمهای حیاتی شرکت باشد (مانند ERP، CRM یا سیستمهای پایگاه داده)، خاموشی میتواند فعالیت روزمره کارکنان را مختل کرده و موجب کاهش بهرهوری شود.
چالشهای حقوقی و قراردادی
در صورت نقض توافقنامههای سطح خدمت (SLA)، مشتریان ممکن است مستحق جبران خسارت باشند یا روابط قراردادی با ارائهدهنده دچار تنش شود.
چگونه میتوان اثر خاموشیهای ابری را کاهش داد؟
استفاده از چند منطقه جغرافیایی
طراحی معماری بهصورت Multi-Region یا Multi-Availability Zone یکی از بهترین روشها برای حفظ دسترسپذیری است. با توزیع منابع در چند منطقه، در صورت بروز مشکل در یک منطقه، سایر نواحی میتوانند به کار ادامه دهند.
بهرهگیری از چند ارائهدهنده ابری
استفاده از معماری Multi-Cloud (مانند ترکیب AWS و Azure یا Google Cloud ) اگرچه پیچیدگی بیشتری دارد، اما وابستگی به یک ارائهدهنده را کاهش میدهد و ریسک خاموشیهای سراسری را پایین میآورد.
طراحی مقاوم در برابر خطا
برنامهها باید طوری طراحی شوند که در زمان بروز خطا بتوانند با حداقل کارایی ادامه فعالیت دهند. استفاده از صفهای پیام، کش و نسخههای بکاپ از پایگاه داده میتواند در پایداری سیستم موثر باشد.
مانیتورینگ و هشدار پیشرفته
پیادهسازی سامانههای مانیتورینگ مستقل از زیرساخت ابری ضروری است. این ابزارها باید بتوانند در لحظه وقوع اختلال، هشدار ارسال کنند تا تیم فنی پیش از کاربران متوجه مشکل شود.
تهیه طرح بازیابی از فاجعه
داشتن برنامه بازیابی از فاجعه (Disaster Recovery Plan) که شامل نسخههای بکاپ، رویههای جایگزین و زمانبندی تست منظم باشد، یکی از ارکان حیاتی مدیریت ریسک در فضای ابری است.
انتخاب زیرساخت متناسب با نیاز
برای برخی از بارهای کاری حیاتی که نیازمند کنترل کامل و جداسازی فیزیکی هستند، استفاده از سرورهای اختصاصی یا زیرساختهای Bare Metal میتواند گزینهای مطمئنتر باشد. در چنین شرایطی وابستگی به لایههای مجازی مشترک کاهش مییابد.
درک درست از پایداری
درک عمومی از پایداری ابری معمولا اغراقآمیز است. پایداری واقعی نهتنها به توان فنی ارائهدهنده بستگی دارد، بلکه به طراحی و تصمیمات کاربر نیز مربوط است.
اگر معماری سرویس بهدرستی طراحی نشده باشد، حتی کوچکترین اختلال در زیرساخت میتواند کل سیستم را از کار بیندازد. در مقابل، سامانهای که از ابتدا بر پایه افزونگی، مانیتورینگ و بازیابی سریع طراحی شده باشد، حتی در زمان خاموشیهای بزرگ نیز میتواند بخش عمدهای از سرویس را فعال نگه دارد.
جمعبندی
رایانش ابری بدون تردید یکی از بزرگترین دستاوردهای فناوری در دهههای اخیر است، اما همانند هر سیستم پیچیدهای، آسیبپذیریهایی دارد. خاموشیهای ابری اجتنابناپذیرند، اما اثر آنها قابل کنترل است.
کسبوکارهایی که تنها به وعدههای «۹۹.۹۹٪ در دسترس بودن» اکتفا میکنند، در زمان بحران غافلگیر خواهند شد. در مقابل، سازمانهایی که از قبل برای چنین سناریوهایی برنامهریزی کردهاند، میتوانند با کمترین آسیب به فعالیت خود ادامه دهند.
طراحی چندلایه، استفاده از مناطق جغرافیایی متعدد، مانیتور دائمی و طرح بازیابی از فاجعه، چهار ستون اصلی تابآوری در برابر خاموشیهای ابری هستند.
در نهایت، پایداری واقعی تنها زمانی حاصل میشود که مسئولیت در دسترس بودن میان ارائهدهنده و کاربر تقسیم شود؛ یکی زیرساخت را فراهم میکند و دیگری آن را هوشمندانه به کار میگیرد.