ما أظهره لنا "صيف الانقطاع" وما الذي يمكننا فعله حيال ذلك

كان صيف 2019 عامًا تقريبيًا بالنسبة للإنترنت ، حيث تحدث حالات انقطاع النظام بشكل متكرر وبتتابع سريع.

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

وكانت الانقطاعات الرئيسية:

• في 2 حزيران (يونيو) ، عانت Google من انقطاع الخدمة الذي ألقت الشركة باللوم فيه على "مستويات عالية من ازدحام الشبكات في شرق الولايات المتحدة". العديد من الخدمات الأكثر شعبية ، بما في ذلك Search ، Nest ، YouTube و Gmail الأرض إلى توقف. لم يمض وقت طويل بعد ذلك ، انخفض تقويم Google ، مما يمنح الكثير من المستخدمين النهائيين ذريعة لإعلان يوم عطلة.
• انخفض Cloudflare في 24 يونيو بسبب تسرب ثانوي للشبكة ، مما أثر على المجالات التي تعتمد على شبكة تسليم المحتوى الرائدة هذه (CDN). تم حجب المستخدمين النهائيين عن الخدمات الشائعة بما في ذلك Discord و Google و Amazon و اكثر.
• في 3 يوليو ، تعرضت كل من Google و Cloudflare لانقطاع إضافي.
• أيضا في 3 يوليو ، Facebook واجه مشاكل في تحميل الصور ومقاطع الفيديو وغيرها من البيانات عبر التطبيقات والخدمات الرئيسية ، بما في ذلك Instagram، واتس اب ورسول. Facebook ألقى باللوم على هذا "خطأ حدث أثناء عملية صيانة روتينية."
• Apple انضم إلى النادي بعد يوم ، مع انقطاع سحابة واسع النطاق لمدة ثلاث ساعات أثر على متجر التطبيقات ، Apple الموسيقى و Apple تلفزيون.
• وأخيرا ، في 11 يوليو ، Twitter واجهت انقطاعًا لمدة ساعة في تطبيق الويب والجوال ، مما نتج عن ما أسمته الشركة "تغيير نظام داخلي".

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

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

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

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

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

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

أحد الأمثلة الواضحة على تسرب BGP شمل Google في نوفمبر الماضي. في حالة "الإنترنت الكبير للسرقة" ، تم توجيه حركة مرور خدمات Google من مجموعة متنوعة من البلدان ومواقع الويب إلى عناوين IP الخاصة بمزودي خدمة الإنترنت في الخارج بما في ذلك TransTelekom Russia و China Telecom ، بدلاً من خوادم Google. وقد أدى ذلك إلى إرسال الحزم إلى وجهات غير مقصودة مختلفة قبل إنهاؤها ، أو ثقب أسود.

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

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

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

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

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

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

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

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

رصيد الصورة: pathdoc / Shutterstock

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