ملخص

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

تخزين الكائنات أصبح سجل اعتماد عام

غالبًا ما يوصف Amazon S3 بأنه تخزين كائنات دائم، لكن حادثة 28 فبراير 2017 كشفت عن دور أوسع. لم يكن S3 مجرد مكان لتخزين الملفات. كان سجل اعتماد للمواقع الإلكترونية والتطبيقات المحمولة ومسارات نشر البرمجيات وأعباء عمل التحليل ونشر الوسائط وتبادل البيانات وبوابات العملاء وصفحات الخدمة العامة وأدوات المراقبة وخدمات AWS الأخرى. عندما شهدت منطقة US-EAST-1 من S3 أخطاء عالية وعمليات غير متاحة، لم يقتصر التأثير على واجهة التخزين. انتشر الحدث عبر البنى التي استخدمت S3 بشكل صامت كافتراض أساسي.

الملخص العام للحادثة من AWS علىhttps://aws.amazon.com/message/41926/هو مصدر الأدلة الرئيسي لهذه الحالة. ذكر الملخص أنه في الساعة 9:37 صباحًا بتوقيت المحيط الهادئ، قام عضو مخول في فريق S3 بتنفيذ دليل إجراءات معتمد لإزالة سعة من نظام فرعي من S3 يستخدم في عملية الفوترة الخاصة بـ S3. أدى الأمر إلى إزالة سعة أكثر من المتوقع. كتبت AWS أن هذا أدى إلى إزالة سعة كبيرة من نظامين فرعيين: النظام الفرعي للفهرس، الذي يدير البيانات الوصفية ومعلومات موقع الكائنات في المنطقة، والنظام الفرعي للتخصيص، الذي يخصص التخزين الجديد. هذا التأطير مهم. لم تُوصف الحادثة على أنها انقطاع طاقة أو قطع ألياف أو كارثة طبيعية أو خطأ تكوين من جانب العميل. كانت حدثًا للتحكم التشغيلي من جانب المزود قلل من السعة في الأنظمة الفرعية الداخلية الحرجة.

ثم يحول الجدول الزمني العام الانقطاع إلى سجل للمسؤولية. ذكرت AWS أن النظام الفرعي للفهرس كان بحاجة إلى إعادة التشغيل، وأن إعادة التشغيل استغرقت وقتًا أطول من المتوقع لأن الأنظمة لم يتم إعادة تشغيلها بالكامل منذ سنوات عديدة. أفاد الملخص أنه تمت استعادة سعة كافية من الفهرس لدعم طلبات GET وLIST وDELETE الساعة 11:54 صباحًا، وأن هذه العمليات تعافت بالكامل الساعة 12:26 ظهرًا. ثم أفاد باستعادة كافية للنظام الفرعي للتخصيص لبدء معالجة طلبات PUT الساعة 1:18 مساءً، وأن عمليات PUT تعافت تمامًا الساعة 1:54 مساءً. الفرق بين القراءة/القائمة/الحذف ووضع الكتابة مهم لأن العملاء لا يعيشون "S3" كمفتاح واحد مجرد.

إنهم يعيشون عمليات معينة تفشل وتتعافى وتتراكم وتعاد وتعود إلى طبيعتها بالتسلسل.

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

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

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

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

الملخص بعد الحادثة يحدد سطح التحكم

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

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

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

هذا التصنيف هو نقطة البداية للعناية الواجبة للعميل. عميل يعتمد على S3 لا ينبغي أن يسأل فقط ما إذا كان S3 دائمًا. بل يجب أن يسأل كيف يتصرف عبء العمل الخاص به عندما تتعطل عمليات GET أو LIST أو DELETE أو PUT من S3 بشكل منفصل. يجب أن يسأل ما إذا كان عبء العمل يمكنه تحمل توفر القراءة مع عدم توفر الكتابة، أو تعافي الكتابة قبل تصفية التراكم. يجب أن يسأل ما إذا كان التطبيق يعيد المحاولة بأمان، وما إذا كانت إعادة المحاولة يمكن أن تضخم الحمل، وما إذا كانت إصدارات الكائنات محمية من الكتابة العرضية، وما إذا كانت قائمة الانتظار تحافظ على الترتيب، وما إذا كان المستخدمون على علم بما حدث.

سطح التحكم الخاص بالمزود يصبح قائمة التحقق من الأدلة للعميل.

صفحات المنتج والوثائق العامة الحالية لـ AWS S3 توفر السياق الحديث لقائمة التحقق هذه. صفحة خدمة S3 علىhttps://aws.amazon.com/s3/تصف عائلة الخدمة وتأطير المتانة. دليل مستخدم S3 علىhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.htmlيعطي نقطة الدخول التشغيلية للدلائل والكائنات وفئات التخزين وضوابط الوصول والميزات. وثائق النسخ المتماثل لـ S3 علىhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html، ووثائق الإصدارات علىhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html، ووثائق قفل الكائنات علىhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/الكيان-lock.htmlليست استنتاجات حول ما استخدمه عميل معين في عام 2017. إنها ذات صلة لأنها تحدد عناصر التحكم من جانب العميل للمرونة والحماية من التغيير وأدلة التعافي.

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

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

الإبلاغ عن حالة الخدمة كان جزءًا من الانقطاع

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

صفحة حالة AWS Health الحالية علىhttps://health.aws.amazon.com/health/statusونقطة دخول لوحة تحكم حالة خدمة AWS القديمة علىhttps://status.aws.amazon.com/ليست مجرد روابط معلوماتية. إنها تمثل القناة العامة التي يبدأ من خلالها العديد من العملاء تصنيف الحوادث. قد يرى العميل تحميلات فاشلة، وانتهاء مهلة، ومعدلات خطأ عالية، وأصولًا فارغة، ونشرًا محظورًا، أو لوحات تحكم معطلة. السؤال الأول هو ما إذا كانت المشكلة محلية، أو من جانب المزود، أو إقليمية، أو عالمية، أو متعلقة بالمصادقة، أو متعلقة بالشبكة، أو خطأ تطبيق نهائي. إذا كانت قناة حالة المزود بطيئة أو واسعة جدًا أو متدهورة هي نفسها، يضيع العملاء الوقت في التشخيص الخاطئ.

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

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

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

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

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

يجب اختبار تعافي العميل ضد الاعتماد في الوضع المشترك

غالبًا ما يوصف التعافي باستخفاف شديد. قد يقول العميل أنه يمكنه استخدام دلو آخر أو منطقة أخرى أو مزود آخر أو ذاكرة تخزين مؤقت محلية أو شبكة توصيل محتوى أو عمليات يدوية. سؤال المسؤولية هو ما إذا كان هذا التعافي ينجو من نفس الانقطاع. دلو مختلف في نفس المنطقة المتأثرة قد لا يساعد. كائن منسوخ قد لا يساعد إذا كان التطبيق يكتب في منطقة وليس لديه مسار قراءة مختبر في مكان آخر. ذاكرة تخزين مؤقت لشبكة التوصيل قد تساعد للأصول العامة ولكن ليس للتحميلات الجديدة أو البيانات الخاصة أو عمليات القائمة أو حالة سير العمل. مزود ثانٍ قد لا يساعد إذا كانت مزامنة البيانات أو الهوية أو موافقة الامتثال أو توجيه التطبيق لم تُختبر أبدًا.

توفر وثائق S3 العديد من أدوات المرونة من جانب العميل، لكن الأدوات تصبح ضوابط فقط عندما يتم تنفيذها واختبارها وإدارتها. نقاط الوصول متعددة المناطق علىhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.htmlيمكن أن تساعد في توجيه الطلبات بين المناطق لبعض البنى. وثائق التحكم في وقت النسخ المتماثل علىhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-time-control.htmlتشرح ميزة النسخ المتماثل مع توقعات زمنية. S3 Storage Lens علىhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens.htmlيمكن أن تدعم الرؤية في استخدام التخزين والنشاط. وثائق إشعارات الأحداث علىhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.htmlيمكن أن تساعد في دمج أحداث الكائنات في سير العمل. لا تثبت أي من هذه المستندات أن عميلًا كان لديه مرونة في عام 2017. إنها تظهر مفردات التحكم التي يجب على العميل تطبيقها الآن.

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

يجب أن يشمل الاختبار الانقطاع الخاص بالعملية. هل يمكن للمستخدمين قراءة المحتوى الحرج إذا فشل PUT؟ هل يمكن للشركة وضع الكتابات في قائمة انتظار لوقت لاحق دون فقدان الترتيب أو حالة المعالجة المكررة؟ هل يمكن للتطبيق التدهور بلطف إذا كانت LIST بطيئة أو غير متاحة؟ هل يمكن لموظفي الدعم التمييز بين المحتوى المفقود والتحميل الجديد الفاشل؟ هل يمكن للموقع عرض رسالة مفيدة إذا كانت الأصول الخاصة غير متاحة؟ هل يمكن للنشر التوقف دون إفساد حالة الإنتاج؟ هل يمكن التوفيق بين سجلات الفوترة والتحليل والامتثال بعد الحادثة؟ هذه الأسئلة ليست غريبة. إنها تنبع من تسلسل العمليات في ملخص AWS.

سلوك إعادة المحاولة يستحق اهتمامًا خاصًا. غالبًا ما يعيد عملاء الأنظمة الموزعة المحاولة بعد الأخطاء، ويمكن أن تكون إعادة المحاولة مفيدة. يمكنها أيضًا تضخيم الحمل وزيادة التكلفة وإنشاء عمل مكرر وإخفاء تأثير المستخدم. مقالة AWS Builders Library حول المهلات وإعادة المحاولة والتراجع مع التشتت علىhttps://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/ذات صلة لأنها تشرح كيف يمكن لتصميم إعادة المحاولة منع الحمل الزائد وعواصف إعادة المحاولة المتزامنة. مقالة حول تجنب التعافي في الأنظمة الموزعة علىhttps://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/ذات صلة أيضًا لأنها تحذر من أن مسارات التعافي يمكن أن تكون غير موثوقة إذا نادرًا ما تمارس. هذه مراجع هندسية حالية من AWS، وليست استنتاجات حول حادثة 2017. إنها مفيدة لأنها تتوافق مع نمط الفشل الذي يجب على العملاء تصميمه ضده.

الأمر نفسه ينطبق على نطاق الانفجار. مقالة AWS Builders Library حول تقليل نطاق التأثير بالهندسة المعمارية القائمة على الخلايا علىhttps://aws.amazon.com/builders-library/reducing-scope-of-impact-with-cell-based-architecture/ومقالة حول الاستقرار الثابت باستخدام مناطق التوفر علىhttps://aws.amazon.com/builders-library/static-stability-using-availability-zones/تعطي لغة عامة لتصميم أنظمة تحتوي أعطالها. S3 نفسه خدمة إقليمية، وبنى العملاء تختلف، لكن المفهوم العام للمسؤولية واضح: النظام الذي يعتمد على مكون مشترك دون حدود احتواء مختبرة يمكن أن يحول حادثة مزود إلى حادثة عميل أوسع بكثير.

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

الخدمات التابعة لـ AWS جعلت نطاق الانفجار مرئيًا

أثر انقطاع S3 أيضًا على خدمات AWS الأخرى التي تعتمد على S3 في US-EAST-1. ذكر ملخص AWS أن بعض الخدمات تأثرت وأنها تعافت بعد استعادة عمليات S3. هذا مهم لأن عملاء السحابة غالبًا ما يجمعون خدمات من نفس المزود بافتراض أن الخدمات المُدارة تفشل بشكل مستقل بما يكفي لأغراض العميل. أحيانًا يكون هذا هو الحال. أحيانًا تشترك في اعتماد غير واضح حتى وقوع حادثة. دور S3 في النظام البيئي لـ AWS جعل حدث 2017 درسًا في تخطيط اعتماد الخدمة.

المواد العامة حول بنية وعمليات AWS تساعد في تأطير هذا. عمود الموثوقية في AWS Well-Architected علىhttps://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.htmlيركز على تصميم عبء العمل للتعافي من الفشل والتوسع وإدارة التغيير. إرشادات المرونة من AWS علىhttps://aws.amazon.com/resilience/توفر لغة على مستوى المزود حول المرونة. مقالة Builders Library حول تنفيذ فحوصات الصحة علىhttps://aws.amazon.com/builders-library/implementing-health-checks/ذات صلة لأن فحوصات الصحة مفيدة فقط إذا كانت تعكس الاعتمادات التي تحدد تجربة المستخدم الفعلية. قد تبدو الخدمة صحية على مستوى واحد بينما تفشل في عملية التخزين التي يحتاجها المستخدم.

يجب أن يكون تخطيط الاعتماد ملموسًا. يجب أن يعرف العميل ما إذا كانت أصول التطبيق والسجلات والنسخ الاحتياطية وحزم النشر ومدخلات التعلم الآلي ومرفقات الدعم وتحميلات المستخدم والمواقع الثابتة والتنزيلات العامة ووظائف التحليل تعتمد جميعها على S3 في منطقة واحدة. يجب أن يعرف أي خدمات AWS المُدارة في بنيته تستخدم S3 أو تتأثر بتوفر S3. يجب أن يعرف أي الاعتمادات مرئية عبر القياس عن بعد الخاص به وأيها مرئية فقط من خلال حالة المزود. يجب أن يعرف أي عملية تجارية تتوقف إذا كانت عملية تخزين كائن واحدة غير متاحة.

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

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

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

يجب معالجة أدلة الإصلاح كادعاء للسيطرة

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

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

مقالة AWS Builders Library حول أتمتة النشر الآمن بدون تدخل علىhttps://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/ذات صلة لأنها تظهر المفردات الهندسية الأوسع لـ AWS حول أمان التغيير والأتمتة ووقت الطهي والإنذارات والتراجع. حادثة S3 2017 لم تكن مشكلة نشر عادية موجهة للعملاء، لكنها تشارك نفس منطق الحوكمة: التغييرات الخطيرة تحتاج إلى ضوابط أمان آلية وتأثير تدريجي واكتشاف سريع وتراجع أو تعافي مختبر. دليل الإجراءات اليدوي لا يصبح آمنًا لمجرد أنه معتمد. يصبح أكثر أمانًا عندما تفرض الأدوات القيود التي قد يفوتها البشر.

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

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

يجب أن ينجو ملف أدلة العميل من نفس الانقطاع

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

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

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

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

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

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

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

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

ملف الأدلة للقارئ

يستخدم هذا المقال المصادر العامة التالية كملف أدلة لانقطاع S3 في US-EAST-1 واتصال حالة AWS وسياق خدمة S3 وضوابط المرونة من جانب العميل وتصميم فشل النظام الموزع. يتم معالجة المصادر التي كتبها المزود كدليل على ما قالته AWS علنًا وكيف توثق AWS الخدمات الحالية. لا يتم معالجتها كدليل مستقل على كل سجل خاص أو تأثير عميل أو علاج تعاقدي أو نتيجة تدقيق داخلي.

أسئلة لمجلس الإدارة

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

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

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