Slack جعل الاعتماد على عبور السحابة اختبارًا للمساءلة في انقطاع العمل عن بُعد

الملخص

• يقول حساب Slack الهندسي إن AWS Transit Gateway الذي يربط شبكات VPC الخاصة به لم يتسع بالسرعة الكافية لزيادة حادة في حركة المرور بعد العطلة. أضاف مهندسو AWS السعة يدويًا، وفقًا لـ Slack. [1]
• تسبب مشكلة البوابة في فقدان الحزم وزيادة زمن الاستجابة، لكن تأثير العميل ظهر من خلال سلسلة داخل بيئة Slack: تباطأت مكالمات التبعية، امتلأت العمال، تم استبدال الحالات، قرر التوسع التلقائي أولاً انخفاض طلب وحدة المعالجة المركزية ثم طلب نموًا سريعًا، وواجه التزويد حدود الموارد والحصص. [1]
• لم يفقد Slack كل مصادر بيانات التشغيل. أصبحت لوحات المعلومات والتنبيهات العادية غير متاحة لأنها اعتمدت على مسار العبور المتأثر، بينما بقيت أنظمة القياس الخام والسجلات ووحدات التحكم وصفحات الحالة متاحة. كان فشل التحكم هو تقليل القوة التفسيرية، وليس العمى التام. [1]
• في الساعة 6:57 صباحًا بتوقيت المحيط الهادئ، قال Slack إن 99% من الرسائل كانت لا تزال تُرسل بنجاح، مقارنة بمعدل طبيعي يزيد عن 99.999%. حوالي الساعة 7:00 صباحًا، واجهت ذروة حركة مرور عادية الشبكة المتدهورة بالفعل وأصبحت الخدمة غير قابلة للاستخدام على نطاق واسع. [1][3]
• حاول Slack إضافة 1200 خادم ويب بين الساعة 7:01 و7:15 صباحًا. تعذر تزويد الكثير منها بالكامل. ثم احتلت الحالات غير المزوّدة الحد الأقصى المُعد لمجموعة التوسع التلقائي، مما حول محاولة التعافي إلى قيد آخر. [1]
• حدث التعافي على مراحل. عادت خدمة التزويد للعمل حوالي الساعة 8:15 صباحًا؛ تمكن معظم العملاء من استخدام الخدمة الأساسية حوالي الساعة 9:15 صباحًا؛ عادت أخطاء الشبكة وزمن الاستجابة إلى طبيعتها في الساعة 10:40 صباحًا. اتبع التقويم والبريد الإلكتروني والتكاملات ذات الصلة مسار تعافي منفصل. [1][3]
• لا يدعم السجل العام عددًا دقيقًا للمستخدمين المتأثرين، أو خسارة اقتصادية محددة للحادث، أو تعرض بيانات العملاء، أو نتيجة قانونية، أو دليل على أن كل علاج مذكور قد اكتمل. يثبت الإبلاغ المعاصر اضطرابًا عالميًا واسعًا واعتمادًا على العمل عن بُعد، وليس عددًا إجماليًا قابلاً للدفاع عنه. [4]-[9][11]-[21]
• معيار المساءلة هو دليل على التحكم في ظل انقطاع حركة مرور مماثل: قابلية المراقبة المستقلة، التزويد المُختبر، الأتمتة المحدودة، سعة عبور مرئية، أوضاع متدهورة مُمارَسة، ودليل على أن العلاجات تعمل عندما تفشل عدة ضوابط معًا.

ما يثبته السجل العام

أقوى حساب تقني هو تقرير ما بعد الحادث الهندسي لـ Slack نفسه. يصف 4 يناير كأول يوم عمل في العام للعديد من المستخدمين. كانت حركة المرور في منطقة آسيا والمحيط الهادئ وخلال صباح أوروبا والشرق الأوسط وأفريقيا هادئة. تغيرت الظروف مع بداية صباح الأمريكتين. خدمة مراقبة خارجية نبهت Slack عندما ارتفعت معدلات الخطأ، وبدأت الشركة عملية الحادث. [1]

ثم أصبحت خدمة لوحات المعلومات والتنبيهات العادية في Slack غير متاحة. من السهل المبالغة في هذا التفصيل. لا تزال أنظمة تخزين المقاييس تقبل الاستعلامات المباشرة، واحتفظ المستجيبون بالسجلات ووحدات التحكم وصفحات الحالة. لم تُحرم الشركة من كل القياسات عن بُعد. لقد فقدت المشاهدات والتنبيهات المُعدة التي تضغط عادةً حالة النظام الكبير في إشارات تشغيلية قابلة للاستخدام. لا يزال بإمكان المستجيبين البحث عن الأدلة، لكن كان عليهم القيام بالمزيد من العمل اليدوي بينما كانت الخدمة تتدهور. [1]

يسجل الحادث أخطاءً متفرقة وزمن استعادة حوالي الساعة 6:00 صباحًا بتوقيت المحيط الهادئ. في الساعة 6:57 صباحًا، أبلغ Slack أن 99% من الرسائل كانت لا تزال تُرسل بنجاح. في العديد من الإعدادات، تبدو 99% قريبة من الطبيعي. لكن خط الأساس لـ Slack كان أعلى من 99.999%. انخفاض نقطة مئوية واحدة يمثل تغييرًا كبيرًا في حالات الفشل على نطاق المنصة حتى قبل عدم التوفر الكامل. حوالي الساعة 7:00 صباحًا، وصلت ذروة حركة المرور العادية نصف الساعة لـ Slack. ساء فقدان الحزم، استغرقت المكالمات من طبقة الويب إلى الخدمات الخلفية وقتًا أطول، امتلأت موارد العمال وأصبحت الخدمة غير قابلة للاستخدام على نطاق واسع. [1][3]

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

قال Slack إن المراقبة الداخلية لـ AWS نبهت مهندسي AWS. زاد AWS سعة البوابة يدويًا، ووصل تغيير السعة هذا إلى جميع مناطق التوفر بحلول الساعة 10:40 صباحًا بتوقيت المحيط الهادئ. ثم عادت معدلات خطأ الشبكة وزمن الاستجابة إلى طبيعتها. لا يوجد تقرير ما بعد حادث مستقل من AWS في السجل المستخدم لهذا الحساب، لذا فإن مراقبة AWS وتدخلها يُنسبان إلى Slack بدلاً من تقديمهما كنتائج AWS مؤكدة بشكل منفصل. [1]

يدعم سجل الحالة المواجه للعملاء والتقارير المعاصرة التسلسل العام والتأثير. تسجل مشاكل الاتصال، الرسائل المتأخرة أو الفاشلة، الأخطاء المتزايدة، عدم التوفر الواسع والعودة على مراحل. وصفت التقارير من أمريكا الشمالية وأوروبا ومناطق أخرى الانقطاع في سياق العمل عن بُعد والتعليم عن بُعد في عصر الجائحة. تثبت تلك الحسابات أن Slack أصبح مهمًا من الناحية التشغيلية. لا تثبت عدد المستخدمين الفرديين المتأثرين أو مقدار الأموال التي كلفها الانقطاع. [3]-[9][11]-[18][20][21]

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

الحقيقة والاستدلال وعدم اليقين

يصبح تحليل المساءلة غير موثوق عندما تُكتب حقيقة حدث وتفسير تقني وتوصية حوكمة كما لو كانت تحمل نفس الوزن الإثباتي. تتطلب هذه الحالة ثلاث فئات صريحة.

الحقائق الثابتةهي عبارات مدعومة مباشرة بسجل الحادث. تتضمن AWS Transit Gateway المحموم الموصوف من قبل Slack؛ فقدان الحزم وزمن استجابة الواجهة الخلفية؛ فشل لوحات المعلومات العادية مع بقاء المقاييس المباشرة متاحة؛ محاولة إضافة 1200 خادم ويب؛ حد الملفات المفتوحة لخدمة التزويد وحصة AWS؛ سقف مجموعة التوسع التلقائي؛ زيادة السعة اليدوية المبلغ عنها من AWS؛ أوقات التعافي المرحلية؛ واتجاهات العلاج المذكورة من Slack. [1][3]

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

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

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

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

حول العمل عن بُعد التوفر إلى تبعية تشغيلية

حدث الانقطاع خلال فترة غير عادية في تنظيم العمل. وصفت تقارير معاصرة من رويترز وأسوشيتد برس وواشنطن بوست وجارديان وسي بي إس وفورتشن وتيك كرانتش وتقارير تقنية متخصصة عودة الناس من العطلات إلى وظائف وفصول دراسية عن بُعد أثناء جائحة كوفيد-19. لم يكن Slack مجرد وسيلة راحة لهؤلاء المستخدمين. في العديد من المنظمات أصبح طريقًا للتنسيق والرسائل والقنوات ومناقشة الحوادث والتواجد اليومي. [4]-[9][11]-[21]

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

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

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

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

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

أخفى فترة هدوء انقطاعًا

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

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

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

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

كما يغير كيفية تفسير التحذيرات المبكرة. في الساعة 6:57 صباحًا، أبلغ Slack عن نجاح 99% من الرسائل. مقابل معدله الطبيعي الذي يزيد عن 99.999%، كان ذلك بالفعل انحرافًا شديدًا. يمكن لمجموع يظل سطحيًا عاليًا أن يخفي خطر الذيل سريع الحركة. يحتاج المشغلون إلى عتبات مرتبطة بالأداء الطبيعي ومعدل التدهور، وليس فقط نسبة توفر واسعة تبدو مطمئنة خارج السياق.

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

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

تحول فقدان الحزمة إلى شلال خدمة

يشرح تشبع Transit Gateway فقدان الحزمة الأولي، ولكن ليس كل فشل لاحق. احتاجت طبقة الويب في Slack إلى استدعاء الخدمات الخلفية عبر الشبكة المتأثرة. مع تباطؤ تلك المكالمات، انتظر العمال لفترة أطول وامتلأت موارد العمال المتاحة. تم وضع علامة على الحالات التي لا يمكنها الوصول إلى التبعيات على أنها غير صحية. ثم حاولت الأتمتة استبدال بعضها. [1]

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

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

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

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

لا يكشف السجل العام عما إذا كان Slack لديه كل هذا التمييز متاحًا في يناير 2021. الاستدلال مبني على معدل التغيير المبلغ عنه وفقدان جلسات SSH عندما تم إلغاء تزويد الحالات قيد التحقيق. يُظهر هذا التفصيل التشغيلي أن الأتمتة لم تكتف بإضافة السعة؛ بل أزالت أيضًا الأدلة وقاطعت التشخيص. [1]

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

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

أنتج التوسع التلقائي إشارات متناقضة

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

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

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

محاولة Slack لإضافة 1200 خادم ويب بين الساعة 7:01 و7:15 صباحًا توضح الجانب الآخر من المشكلة. أمر التوسع العدواني مفيد فقط إذا كان النظام يمكنه تكوين تلك الحالات وتسجيلها وخدمتها منها. حجم الأسطول المطلوب ليس سعة مسلمة. أثناء الحادث، أصبحت الفجوة بين هذه الحالات حاسمة.

المساءلة عن التوسع التلقائي لا يمكن أن تتوقف عند سياسة التوسع. إنها تمتد عبر مسار التنفيذ. يجب أن يعرف مالك التحكم:

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

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

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

كان التزويد جزءًا من نظام الخدمة

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

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

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

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

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

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

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

فشلت المراقبة كتبعية تشغيلية

اعتمدت خدمة لوحات المعلومات والتنبيهات العادية في Slack على نفس مسار العبور المتأثر بالانقطاع. كانت حالات لوحة المعلومات في VPC مختلفة عن قاعدة البيانات الخاصة بها، لذا قطع مشكلة Transit Gateway المشاهدات التشغيلية المعدة. لا يزال Slack يملك استعلامات المقاييس المباشرة والسجلات ووحدات التحكم وصفحات الحالة. [1]

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

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

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

قال Slack إنه خطط لنقل حالات لوحة المعلومات إلى نفس VPC مثل قاعدة البيانات الخاصة بها. [1] هذا العلاج تناول مباشرة تبعية العبور عبر VPC الموصوفة في تقرير ما بعد الحادث. لا ينبغي تعميمه كقاعدة بأن جميع مكونات المراقبة يجب أن تشارك دائمًا VPC واحد. يمكن أن يزيل التجميع تبعية واحدة مع خلق حد مشترك آخر. معيار الدليل هو ما إذا كان مسار المراقبة ينجو من أوضاع الفشل التي من المتوقع أن يشرحها.

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

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

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

كان التعافي على مراحل، وليس لحظة استعادة واحدة

لم يحدث تعافي Slack في طابع زمني واحد. يضع أرشيف الحالة إصلاح التزويد حوالي الساعة 8:13 صباحًا بتوقيت المحيط الهادئ، بينما يصف تقرير ما بعد الحادث لـ Slack خدمة التزويد وهي تعمل مرة أخرى حوالي الساعة 8:15. ظهر تحسن العميل الأولي حوالي الساعة 8:45. بحلول الساعة 9:15، كان لدى طبقة الويب عدد كافٍ من المضيفات العاملة لمعظم العملاء لاستخدام Slack، على الرغم من أن فقدان الحزم ومعدلات الخطأ ظلت مرتفعة. عادت ظروف الشبكة إلى طبيعتها في الساعة 10:40 بعد أن وصلت زيادة السعة إلى جميع مناطق التوفر. [1][3]

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

كان للتقويم والبريد الإلكتروني والتكاملات ذات الصلة مسار تعافي منفصل. [1][3] عبارة أن "Slack تعافى في الساعة 9:15" ستكون واسعة جدًا. تمكن معظم العملاء من استخدام الخدمة الأساسية حوالي ذلك الوقت، لكن أخطاء الشبكة المرتفعة ظلت قائمة وبعض التكاملات لم تكن على نفس الجدول. عبارة أن الانقطاع استمر بالضبط حتى 10:40 ستسوي أيضًا العودة التدريجية التي اختبرها العملاء.

الاستدلال التحليلي هو أن تعافي الخدمة يحتاج إلى مقاييس متعددة. على الأقل، يجب على المشغل التمييز بين:

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

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

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

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

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

تبعت مساءلة AWS سطح التحكم في العبور المُدار

قامت AWS بتشغيل Transit Gateway كخدمة مُدارة. وفقًا لـ Slack، لم تتسع البوابة بالسرعة الكافية لزيادة الحزم في الثانية المفاجئة. نبهت المراقبة الداخلية لـ AWS مهندسي AWS، الذين زادوا السعة يدويًا. قال Slack أيضًا أن AWS كانت تراجع خوارزميات توسع Transit Gateway للزيادات السريعة في حركة المرور. [1]

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

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

المساءلة التشغيلية لا تزال ممكنة بدون تلك التفاصيل الخاصة. يجب أن تعطي الخدمة المُدارة العملاء أدلة كافية لفهم حدود التوسع المادية وسلوك الاستجابة. الأسئلة ذات الصلة تشمل:

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

هذه أسئلة حوكمة، وليست ادعاءات حول ميزات AWS غير المعلنة في 2021. إنها تتبع من الفجوة بين التحكم الذي امتلكته AWS والأعراض التي يمكن لـ Slack رؤيتها.

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

قال Slack إنه سيطلب توسع Transit Gateway استباقيًا قبل ذروة ما بعد العطلة التالية. [1] هذا الاقتراح يعترف بحد مشترك: Slack يعرف تقويمه ونمط الطلب، بينما AWS تسيطر على إجراء السعة. التحكم الدائم لن يكون الطلب وحده. سيكون مشغلًا قابلًا للتكرار، وملكية مسماة، وتأكيدًا أن السعة موجودة، وخطة احتياطية إذا لم يحدث التوسع المتوقع.

اتبعت مساءلة Slack الهندسة والأتمتة

لم يتحكم Slack في التوسع الداخلي لـ AWS Transit Gateway، لكنه تحكم في النظام الذي اعتمد عليه. هذا النظام وضع الخدمات عبر حسابات وشبكات VPC متعددة، واستخدم بوابات عبور كمحاور، وأرسل حركة مرور المراقبة عبر نفس التبعية، وفسر الصحة من خلال فحوصات آلية، ووسع طبقة الويب من إشارات الاستخدام، واعتمد على خدمة تزويد بقيود الموارد والحصص الخاصة بها. [1]

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

يحدد تقرير ما بعد الحادث عدة مساهمين تحت سيطرة Slack:

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

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

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

تتبعت العلاجات المذكورة من Slack المساهمين الملاحظين. خطط لطلب توسع البوابة استباقيًا، ونقل حالات لوحة المعلومات بالقرب من قاعدة البيانات الخاصة بها، واختبار التزويد تحت الحمل بانتظام، وإعادة تقييم تكوينات فحص الصحة والتوسع التلقائي. [1] هذه اتجاهات ذات مصداقية لأن كل واحد يرتبط بآلية فشل محددة.

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

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

يمتلك عملاء المؤسسات الاستمرارية، وليس خطأ البنية التحتية

بالنسبة للمؤسسات التي تستخدم Slack، خلق الحادث اختبار مساءلة مختلف. لم يستطع العملاء توسيع Transit Gateway، أو إصلاح خدمة التزويد في Slack، أو تغيير فحوصات الصحة الخاصة به. سيكون من غير الدقيق إسناد مسؤولية الفشل التقني إليهم. كان سطح التحكم الخاص بهم هو الاستمرارية الداخلية.

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

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

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

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

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

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

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

القضية ضد قصة سبب واحد

الانقطاعات الشديدة تخلق ضغطًا لتسمية بسيطة. في هذه الحالة، "زيادة تحميل AWS Transit Gateway" هو محفز مدعوم. إنه ليس تفسيرًا كاملاً.

خريطة سببية مفيدة لها خمس طبقات على الأقل:

1. حالة الطلب:زيادة حادة في حركة المرور بعد العودة إلى العمل بعد فترة عطلة هادئة، مع ذاكرات تخزين مؤقت باردة تزيد من الاسترجاع.
2. محفز البنية التحتية:لم يتسع Transit Gateway المُدار بالسرعة الكافية، مما أنتج فقدان حزم وزمن استجابة.
3. تضخيم الخدمة:انتظرت مكالمات طبقة الويب، امتلأت موارد العمال، فشلت فحوصات الصحة، وغيرت الأتمتة الأسطول.
4. قيد التعافي:اعتمد التزويد على الشبكة المتدهورة وواجه حد الملفات المفتوحة وحصة AWS وسقف المجموعة.
5. قيد التشخيص:كانت لوحات المعلومات والتنبيهات العادية غير متاحة عبر نفس مسار العبور، على الرغم من بقاء القياس عن بُعد الآخر.

أضاف التعافي طبقة سادسة: زاد AWS سعة العبور بينما استعاد Slack التزويد وعددًا كافيًا من المضيفات الخدمية، واستخدم ضوابط الوضع المتدهور، وأعاد التكاملات في جداول زمنية منفصلة.

تدعم هذه الخريطة مساءلة متباينة. امتلك AWS سلوك العبور المُدار والتدخل. امتلك Slack هندسة الخدمة وضوابط التضخيم. امتلك عملاء المؤسسات فقط اعتمادهم وخيارات الاستمرارية. لا يشرح أي مالك تحكم واحد كل مرحلة.

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

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

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

خطر التركيز يتعلق بفقدان التحكم المترابط

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

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

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

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

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

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

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

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

يجب أن يعيد الاختبار إنتاج شكل الفشل

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

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

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

هذه التفاصيل هي متطلبات اختبار تحليلية. لا يقول السجل العام أن Slack اعتمد هذا التصميم الدقيق. إنها مشتقة من كل نقطة مبلّغ عنها حيث غير تسلسل يناير اتجاهه.

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

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

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

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

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

تحتاج المعالجة إلى إثبات، وليس فقط التزامات

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

كل إجراء يحتاج إلى ادعاء إغلاق:

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

هذه الادعاءات بالإغلاق تحليلية. إنها تنص على الأدلة التي من شأنها أن تجيب على الفشل المعروف، وليس ما أثبته Slack أو AWS علنًا.

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

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

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

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

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

ما لا يثبته الحادث

العديد من الاستنتاجات تتجاوز الأدلة.

لا يثبت أن AWS وحدها تسببت في الانقطاع بأكمله. نسب Slack المحفز الشبكي إلى Transit Gateway لم يتسع بالسرعة الكافية، لكن المراقبة تحت سيطرة Slack، والتوسع التلقائي، واستبدال الصحة، وحدود التزويد، وسقوف المجموعة شكلت تأثير الخدمة والتعافي. [1]

لا يثبت أنه لم يكن لدى Slack مراقبة. المراقبة الخارجية نبهت المستجيبين، وبقيت المقاييس المباشرة قابلة للاستعلام، وكانت السجلات ووحدات التحكم وصفحات الحالة متاحة. كانت لوحات المعلومات والتنبيهات العادية غير متاحة، وهو أمر خطير لكنه مختلف عن العمى التام. [1]

لا يثبت فشل منطقة توفر واحدة. قال Slack إن زيادة سعة AWS وصلت إلى جميع مناطق التوفر بحلول الساعة 10:40. الحالة الموصوفة كانت سعة عبور مشتركة وفقدان حزم، وليس فقدان منطقة واحدة. [1]

لا يثبت أن كل عميل كان غير متصل لمدة خمس ساعات ثابتة. بدأت الأخطاء قبل عدم التوفر الواسع، واستعاد معظم العملاء الاستخدام الأساسي قبل تطبيع الشبكة، واتبعت التكاملات مسارًا منفصلاً. [1][3]

لا يثبت خرقًا أمنيًا أو تعرضًا لبيانات العملاء. الحدث الموصوف هنا كان حادث توفر ولا ينبغي دمجه مع أحداث أمنية غير ذات صلة.

لا يثبت عددًا دقيقًا للمستخدمين المتأثرين. تستخدم التقارير الإعلامية وأرقام حجم العملاء وتقارير Downdetector مقامات مختلفة. لا يوفر أي منها عدد سكان الحادث مؤكدًا.

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

لا يثبت أن كل علاج معلن قد تم تنفيذه. يذكر تقرير ما بعد الحادث اتجاهات والتزامات. يتطلب الإكمال والفعالية أدلة لاحقة.

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

معيار المساءلة

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

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

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

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

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

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

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

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

المصادر

1. https://slack.engineering/slacks-outage-on-january-4th-2021/
2. https://status.slack.com/2021-01/3086c30c080cc1f1
3. https://slack-status.com/2021-01/9ecc1bc75347b6d1
4. https://www.investing.com/news/stock-market-news/slack-outage-disrupts-remote-working-for-users-2379391
5. https://www.washingtonpost.com/business/2021/01/04/slack-outage-work-disruption/
6. https://techcrunch.com/2021/01/04/its-not-just-you-slack-is-struggling-this-morning/
7. https://www.cbsnews.com/news/slack-down-2020-01-04/
8. https://www.theguardian.com/technology/2021/jan/04/slack-messaging-service-suffers-global-outage
9. https://www.theregister.com/2021/01/04/slack_down/
10. https://www.theregister.com/2021/02/02/slack_fingers_aws_auto_scaling_failure_in_january_outage_postmortem/
11. https://www.forbes.com/sites/roberthart/2021/01/04/slack-is-down-office-messaging-app-begins-2021-with-massive-outages-as-workers-return/
12. https://www.engadget.com/slack-outage-161114877.html
13. https://fortune.com/2021/01/04/slack-down-outage-stock-work-from-home-wfh-remote/
14. https://www.independent.co.uk/tech/slack-down-not-working-messages-server-status-b1782075.html
15. https://www.latimes.com/world-nation/story/2021-01-04/slack-starts-the-year-with-a-global-outage
16. https://toronto.citynews.ca/2021/01/04/slack-investigating-outage-and-connectivity-issues-with-its-communications-platform/
17. https://elpais.com/tecnologia/2021-01-04/slack-sufre-una-caida-de-sus-servicios.html
18. https://www.techtarget.com/searchunifiedcommunications/news/252494328/Slack-starts-the-new-year-with-a-global-outage
19. https://www.techtarget.com/searchunifiedcommunications/news/252495267/Massive-Slack-outage-caused-by-AWS-gateway-failure
20. https://www.computerworld.com/article/1644334/enterprise-collaboration-services-creak-as-world-returns-to-work.html
21. https://www.itpro.com/marketing-comms/business-communications/358219/slack-starts-2021-with-a-major-outage