در ماه گذشته، مشتریان AWS در صورت استفاده از VPN سایت به سایت و اتصال اینترنت شرکت از طریق منطقه در دسترس بودن US-East-2، با قطعی مواجه شدند. این قطعی دقیقاً 40 دقیقه از ساعت 12:26 بعد از ظهر تا 1:06 بعد از ظهر PST به طول انجامید.
در طول آن بازه زمانی، مشتریان AWS که به آن منطقه در دسترس بودن وابسته بودند، با مشکلات بیشماری مواجه شدند. برخی از آنها توسط مشتریان خود از قطع شدن مطلع شدند، که باعث شرمساری اگر نگوییم تخریب برند یا حتی از دست دادن مشتریان شد. آنها همچنین از سوی مدیران اجرایی برای ارائه یک طرح کاهش در صورت وقوع قطعی مشابه تحت فشار قرار گرفتند. برای ارائه چنین طرحی، سازمان ها به یک عنصر کلیدی نیاز دارند: علت قطعی.
تا زمان انتشار، AWS چیزی را که برخی «پس از مرگ» یا خلاصهای از قطعی پس از حادثه میخوانند، منتشر نکرده است. زمانی که از AWS پرسیده شد که چه زمانی یا اینکه آیا AWS یک پس از مرگ را ارائه می دهد، یکی از مقامات این شرکت این را گفت:
سخنگوی AWS در این باره نوشت: «ما خلاصههای پس از رویداد را برای هر رویداد سرویس منتشر نمیکنیم. دانش مرکز داده در پاسخ ایمیلی به درخواست ما در این هفته. هنگامی که یک مشکل تأثیر گسترده و قابل توجهی بر مشتری دارد که منجر به شکست درصد قابل توجهی از تماسهای API هواپیمای کنترلی میشود، درصد قابلتوجهی از زیرساختها، منابع یا APIهای سرویس را تحت تأثیر قرار میدهد یا نتیجه قطعی کامل برق یا خرابی قابلتوجه شبکه است، AWS متعهد به ارائه یک خلاصه عمومی پس از رویداد (PES) پس از بسته شدن موضوع است.”
مشتریان AWS که کسبوکارشان به منطقه دسترسپذیری US-East-2 شرکت متکی است، سر خود را میخراشند و به این فکر میکنند که چگونه یک مشکل را بدون هیچ دلیل گزارش شده کاهش دهند.
AWS سال گذشته یک قطعی دیگر در منطقه دسترسی US-East-2 داشت
حادثه در 5 دسامبر دومین مورد در سال جاری در منطقه در دسترس بودن US-East-2 برای AWS است. در 28 جولای، حادثه قطعی گستردهتر بود و میتوان گفت که الزاماتی را که نماینده AWS به اشتراک گذاشته بود، برآورده میکرد.
به مدت 2.8 ساعت، مشتریان AWS به 38 سرویس ارائه دهنده خدمات ابری پیشرو در منطقه در دسترس بودن US-East-2 دسترسی نداشتند. این 38 سرویس عبارتند از: API Gateway، CloudWatch، DynamoDB، و پرچمدار شرکت ارائه دهنده Elastic Compute Cloud (که معمولاً به عنوان EC2 نامیده می شود).
EC2 به عنوان کاهش خدمات در داشبورد سلامت AWS در طول دوره زمانی حادثه “از دست دادن نیرو” فهرست شد.
در حال حاضر AWS هیچ خلاصه ای پس از حادثه منتشر نکرده است که علت و کاهش آن مشکل را نیز شرح دهد.
در حالی که هیچ راهنمایی اضافی AWS در این موارد از قطعی های کوچکتر ارائه نمی دهد، مشتریان به داشبورد سلامت AWS و داشبورد سلامت شخصی (که داشبورد خدمات و محیط های خاص مشتری است) دسترسی دارند.
آخرین خلاصه پس از حادثه AWS ارائه شده برای هرگونه اختلال در سرویس مربوط به یک مشکل اتصال داخلی در 10 دسامبر 2021 بود که بر EC2 API و Container API، در میان سایر مشکلات دسترسی به سرویس، تأثیر گذاشت.
برنامه ریزی در مورد CSP ها برای کاهش تأثیر قطعی ها
در پوشش قبلی خود در مورد قطعی AWS در ماه دسامبر، ما یک طرح پنج مرحله ای برای رفع قطعی ها به اشتراک گذاشتیم. دو نکته کلیدی از آن پوشش مستقیماً به موضوع CSP ها و برنامه ریزی بلایا اعمال می شود.
ما از مایک گیبز، مدیر عامل Go Cloud Careers خواستیم تا راهنمایی های خود را گسترش دهد.
1. در مورد خرابی های ابر و خود CSP ها برنامه ریزی کنید.
شرکتها معماری ابری را حول برندها طراحی نمیکنند، بلکه بیشتر برای حل چالشهای مشتری طراحی میکنند. برای تداوم کسب و کار، نمی توان از در نظر گرفتن برندها اجتناب کرد.
ابر در واقع چیزی بیش از یک شبکه مجازی / مرکز داده نیست و این سیستم ها از کار می افتند. به دلیل نرم افزار ابری اضافی، در محیط محاسبات ابری اشتباهات بیشتری نسبت به یک مرکز داده سنتی و داخلی وجود دارد. برای معماران ابری که سیستمهای مشتری حیاتی را طراحی میکنند، ضروری است که از چندین ابر و چندین ارائهدهنده شبکه برای اتصال سیستمهای خود به چندین ابر استفاده کنند. این از شعار نیروی دریایی SEAL پیروی می کند، “دو یکی است و یکی هیچ است.”
2. تداوم کسب و کار در C-suite شروع می شود.
معماران بهتر است هنگام طراحی سیستم های ابری، هر تهدیدی را در نظر بگیرند و تهدیدات را کاهش دهند.
الزامات تجاری تعیین می کند که چه نوع برنامه ریزی اضطراری باید رخ دهد. برای مثال:
• یک کسب و کار چقدر می تواند زمان توقف را تحمل کند؟
• چند درصد از سیستم های کسب و کار باید در شرایط فاجعه کار کنند؟
• نگرانی های امنیتی چیست؟
اینها الزاماتی است که معمار ابر باید بداند تا بتواند به درستی یک طرح بازیابی بلایا و فناوری پشتیبانی از آن طرح را طراحی کند.