سبعة دروس يمكن تعلمها من انقطاع خدمة أمازون

اعتبارًا من آخر تحديث بعد ظهر اليوم لوحة معلومات صحة خدمة أمازون، لا يزال عدد قليل من العملاء ينتظرون استعادة مثيلات EBS وRDS الخاصة بهم بعد ذلك انقطاع مروع يوم الخميس. ولكن بالنسبة لجميع المشاركين (وليس أقلهم موظفي العمليات في أمازون) فقد كانت أربعة أيام طويلة جدًا (انظر أحدث مناقشة Techmeme). ما هي الدروس التي يجب تعلمها؟

1. اقرأ اتفاقية مستوى الخدمة الخاصة بموفر الخدمة السحابية جداً بحرص

ومن المثير للدهشة أن هذا الانقطاع استمر لمدة أربعة أيام تقريبًا لا انتهكت اتفاقية مستوى الخدمة EC2 الخاصة بأمازون، والتي كما يوضح الأسئلة الشائعة، "يضمن توفر الخدمة بنسبة 99.95% داخل المنطقة على مدى 365 فترة." نظرًا لأنها كانت خدمات EBS وRDS بدلاً من EC2 نفسها التي فشلت (وكانت جميع حالات الفشل مقتصرة على مناطق توافر الخدمات داخل منطقة واحدة)، لم يتم انتهاك اتفاقية مستوى الخدمة، بشكل قانوني تكلم. وهذا ليس عزاءً للمتضررين بالطبع، كما أنه ليس عذرًا للاضطراب الذي عانوا منه. لكنه بالتأكيد يدعو إلى وقفة للتفكير.

2. لا تأخذ ضمانات مزود الخدمة الخاص بك كأمر مسلم به

كان العديد من العملاء المتأثرين يدفعون مبالغ إضافية لاستضافة مثيلاتهم في أكثر من منطقة توافر خدمات (AZ). توصي أمازون في الواقع بمسار العمل هذا لضمان المرونة في مواجهة الفشل. كل منطقة من الألف إلى الياء، وفقًا للأسئلة الشائعة الخاصة بأمازون، "يعمل على بنيته الأساسية المستقلة والمتميزة ماديًا، وتم تصميمه ليكون موثوقًا للغاية. لا تتم مشاركة نقاط الفشل الشائعة مثل المولدات ومعدات التبريد عبر مناطق توافر الخدمات. بالإضافة إلى ذلك، فهي منفصلة ماديًا، بحيث أنه حتى الكوارث غير المألوفة للغاية مثل الحرائق أو الأعاصير أو الفيضانات لن تؤدي إلا إلى تؤثر على منطقة توافر خدمات واحدة." لسوء الحظ، تبين أن هذا عبارة عن مواصفات فنية وليس ضمانًا تعاقديًا. سوف يستغرق الأمر من أمازون بعض الجهد لإصلاح الضرر الذي سببه هذا الحدث لها.

كان جوستين سانتا باربرا، المؤسس والرئيس التنفيذي لشركة FathomDB صريحًا في منشور مدونته حول لماذا السماء تسقط:

"لقد خالفت AWS وعودها بشأن سيناريوهات الفشل لمناطق توافر الخدمات... المواقع التي تم إيقافها كانت مصممة بشكل صحيح وفقًا لـ "العقد"؛ المشكلة هي أن AWS لم تتبع مواصفاتها الخاصة. سواء حدث ذلك بسبب عدم الكفاءة أو عدم الأمانة أو شيء يمكن التسامح معه تمامًا، فإننا ببساطة لا نعرف في هذه المرحلة".

في حين أنه من السهل أن تكون حكيمًا بعد الحدث، إلا أن تعرض أمازون لهذا النوع من الفشل ربما كان واضحًا في ممارسة العناية الواجبة العميقة بما فيه الكفاية. بصفته كبير العلماء المنافس لشركة أمازون جوينت، جيسون هوفمان ملاحظات على مدونة الشركة"هذا ليس" مطبًا سريعًا "أو" فشلًا سحابيًا "أو" آلامًا متزايدة "، بل هو نتيجة متوقعة للقرارات المعمارية الأساسية التي اتخذتها أمازون."

3. سيظل معظم العملاء يسامحون أمازون على إخفاقاتها

ومهما كان مدى تأثرهم، فقد أشاد مقدمو الخدمة بأمازون تقديراً لمدى مساعدتهم في تشغيل بنية تحتية قوية بتكلفة وجهد أقل. استهل العديد من الانتقادات بالامتنان لما جعلته أمازون ممكنًا، مثل الرئيس التنفيذي لشركة BigDoor كيث سميث:

"لقد أتاحت لنا AWS توسيع نطاق نظام معقد بسرعة وبتكلفة منخفضة للغاية. في أي وقت من الأوقات، لدينا 12 خادم قاعدة بيانات، و45 خادم تطبيقات، وستة خوادم ثابتة، وستة خوادم تحليلية قيد التشغيل. تتكيف أنظمتنا تلقائيًا عندما ترتفع حركة المرور أو متطلبات المعالجة، وتتقلص تلقائيًا عند عدم الحاجة إليها من أجل الحفاظ على الأموال."

4. هناك العديد من الطرق التي يمكنك من خلالها تعزيز مرونة موفر الخدمة السحابية

مثل يشير جورج ريس من أورايلي إلى ذلك"إذا تعطلت أنظمتك في سحابة أمازون هذا الأسبوع، فهذا لم يكن خطأ أمازون. إما أنك اعتبرت انقطاعًا من هذا النوع خطرًا مقبولاً أو أنك فشلت في التصميم لسحابة أمازون نموذج الحوسبة." من المفيد مراجعة التقنيات التي استخدمها العملاء لتقليل تعرضهم للفشل في أمازون.

Twilio، على سبيل المثال، لم ينزل. على الرغم من أن الشركة لم توضح بالضبط طبيعة تعرضها لمناطق توافر الخدمات المتأثرة في شمال فيرجينيا، إلا أنها وصفت مبادئ التصميم المعماري الخاصة بها في الإدخال الأول في مدونتها الهندسية الجديدة من قبل المؤسس المشارك و CTO إيفان كوك. يتضمن ذلك تحليل الموارد إلى مجموعات مستقلة، ودعم المهلات السريعة وإعادة المحاولة، والحصول على عاجز الواجهات التي تسمح بمحاولات متعددة للطلبات الفاشلة. بالطبع، قول كل هذا أسهل من فعله إذا كانت تجربتك كلها في تصميم مجموعات تطبيقات مؤسسية مقترنة بإحكام والتي تفترض وجود شبكة محلية مرنة. يستمر منشور Cooke في وصف بعض الخصائص التي تجعل بنية Twilio قادرة على العمل بهذه الطريقة الأكثر تحملاً للخطأ. لنبدأ بـ "فصل منطق الأعمال إلى خدمات صغيرة عديمة الحالة يمكن تنظيمها في مجموعات متجانسة بسيطة." خطوة أخرى هي تقسيم قراءة البيانات وكتابتها: "إذا كان هناك مجموعة كبيرة من البيانات التي تتم كتابتها بشكل غير متكرر، فافصل بين عمليات القراءة والكتابة لذلك بيانات... على سبيل المثال، من خلال الكتابة إلى مدير قاعدة البيانات والقراءة من تابعي قاعدة البيانات، يمكنك زيادة عدد التابعين المقروءين لتحسين التوفر والأداء."

الموقع الآخر الذي لم يتعطل هو NetFlix، الذي يدير كل بنيته التحتية في سحابة أمازون. مرة أخرى، ليس من الواضح مدى تعرض عملياتها لموارد أمازون المتضررة، ولكن أ موضوع أخبار الهاكر يلخص بشكل مفيد بعض المبادئ المستخدمة.

5. بناء المزيد من المرونة يأتي بتكلفة

بوب وارفيلد يصف كيف استخدمت شركة سابقة البنية التحتية لموقع Amazon.com بطريقة أتاحت لها "إعادة الخدمة إلى منطقة أخرى في حال تعطلت الخدمة التي كنا فيها كلياً خلال 20 دقيقة وبما لا يزيد عن 5 دقائق من البيانات الخسارة." كما يقول، فإن الاختيارات التي تتخذها بشأن مدة انقطاع التيار الكهربائي والتي تكون على استعداد لدعمها لها عواقب على التكلفة التي يجب أن يتحملها عملاؤك أو مؤسستك تمويل. "سيبحث المستخدمون الأذكياء وموردو PaaS في تعبئة العديد من الخيارات لأنه يجب أن يتم نسخك احتياطيًا إلى S3 بغض النظر، فماذا في ذلك؟ أنت تتجادل بشكل أساسي حول مدى "دفء" الموقع البديل والدفع الإضافي مقابله والمبلغ الذي يجب أن يتم إنشاؤه من الصفر عبر S3."

6. يساعدك فهم المقايضات على تحديد ما يجب طرحه

هناك أسئلة يجب أن تطرحها حتى تتأكد من أن الخدمة السحابية التي تعتمد عليها لا تعرضك لمثلها الفشل (أو على الأقل، إذا كان الأمر كذلك، فأنت تفهم ذلك وترغب في تحمل العواقب مقابل سعر أرخص يكلف). بالإشارة إلى ممارسة NetFlix لـ قتل الموارد والخدمات بشكل عشوائي من أجل اختبار مرونتها, يضيف بوب وارفيلد هذه النصيحة:

"من المحتمل أن يكون هذا سؤالًا جيدًا آخر يجب طرحه على موردي PaaS وCloud - "هل تقوم بإيقاف الإنتاج البنية التحتية لاختبار تجاوز الفشل؟" بالطبع ترغب في رؤية ذلك وليس مجرد الأخذ بكلامهم على محمل الجد أيضاً."

7. الافتقار إلى الشفافية قد يكون "كعب أخيل" في أمازون

اشتكى العديد من العملاء المتأثرين من نقص المعلومات المفيدة الواردة من أمازون أثناء انقطاع الخدمة. الرئيس التنفيذي لشركة BigDoor كيث سميث كتبوأضاف: "لو كانت أمازون أكثر تفاعلاً مع ما تعانيه، لكنا قادرين على استعادة أنظمتنا عاجلاً". دعا رومان ستانيك من GoodData أمازون إلى ذلك هدم جدارها السرية:

"لا يستطيع فريق التطوير لدينا أن يقرأ من الأوراق الأساسية كيفية تنظيم أنظمتنا من أجل الأداء وقابلية التوسع والأهم من ذلك التعافي من الكوارث. الفرق بين اتفاقيات مستوى الخدمة "المعقولة" و"الخمسة والتسعة" هو الفرق بين الارتجال والمواءمة الكاملة للعمليات التشغيلية الخاصة بنا... لا ينبغي أن تكون هناك جدران اتصال بين IaaS وPaaS وSaaS وطبقات العملاء في البنية التحتية السحابية."

ويتمثل التحدي الذي تواجهه أمازون في الأسابيع المقبلة في إظهار استعدادها لتزويد عملائها بالمعلومات التي تحتاجها لبناء تلك المرونة بشكل موثوق. إذا لم تلبي هذه الحاجة وسمحت للآخرين بالقيام بعمل أفضل، فقد تبدأ تدريجياً في فقدان موقعها المهيمن اليوم في توفير البنية التحتية كخدمة (IaaS).