ملخص

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

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

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

ملخص AWS العام بعد الحدث على source: aws.amazon.com هو مصدر الأدلة الرئيسي لهذه القضية. ذكر الملخص أنه في الساعة 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 على source: aws.amazon.com عائلة الخدمة وتأطير المتانة. يقدم دليل مستخدم S3 على source: docs.aws.amazon.com نقطة الدخول التشغيلية للجرافات والكائنات وفئات التخزين وضوابط الوصول والميزات. وثائق نسخ S3 على source: docs.aws.amazon.com، ووثائق الإصدار على source: docs.aws.amazon.com، ووثائق قفل الكائن على source: docs.aws.amazon.com ليست نتائج حول ما استخدمه عميل معين في عام 2017، لكنها ذات صلة لأنها تحدد ضوابط جانب العميل للمرونة وحماية التغيير وأدلة التعافي.

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

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

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

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

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

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

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

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

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

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

يجب اختبار الخطة البديلة للعميل ضد التبعية المشتركة

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

توفر وثائق S3 العديد من أدوات المرونة من جانب العميل، لكن الأدوات تصبح ضوابط فقط عندما يتم تنفيذها واختبارها وإدارتها. يمكن أن تساعد نقاط الوصول متعددة المناطق على source: docs.aws.amazon.com في توجيه الطلبات عبر المناطق لبعض البنيات. تشرح وثائق التحكم في وقت النسخ على source: docs.aws.amazon.com ميزة نسخ مع توقعات زمنية. يمكن أن تدعم S3 Storage Lens على source: docs.aws.amazon.com الرؤية في استخدام التخزين والنشاط. يمكن أن تساعد وثائق إشعارات الأحداث على source: docs.aws.amazon.com في دمج أحداث الكائنات في سير العمل. لا يثبت أي من هذه المستندات أن العميل كان لديه مرونة في عام 2017. إنها تظهر مفردات التحكم التي يجب على العميل تطبيقها الآن.

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

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

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

إنها مفيدة لأنها تطابق نمط الفشل الذي يجب على العملاء التصميم حوله.

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

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

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

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

تساعد مواد AWS العامة حول الهندسة والعمليات في تأطير هذا. تركز ركيزة الموثوقية في Well-Architected على source: docs.aws.amazon.com على تصميم عبء العمل للتعافي من الفشل والتوسع وإدارة التغيير. توفر إرشادات المرونة من AWS على source: aws.amazon.com لغة على مستوى المزود حول المرونة. مقالة مكتبة المطورين حول تنفيذ فحوصات الصحة على source: aws.amazon.com ذات صلة لأن فحوصات الصحة مفيدة فقط إذا كانت تعكس التبعيات التي تحدد تجربة المستخدم الحقيقية. يمكن أن تبدو الخدمة صحية في طبقة واحدة بينما تفشل في عملية التخزين التي يحتاجها المستخدم.

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

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

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

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

يجب التعامل مع أدلة الإصلاح كادعاء تحكم

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

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

مقالة مكتبة AWS للمطورين حول أتمتة النشر الآمن بدون تدخل على source: aws.amazon.com ذات صلة لأنها تظهر مفردات الهندسة الأوسع لـ 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، وضوابط العميل، وفجوات الأدلة، والجماهير المتأثرة، وأدلة الإصلاح التي من شأنها تغيير قرار شراء سحابي أو بنية مستقبلية.