انهيار شبكة AT&T؛ سطر برمجي تسبّب في شلّ شبكة بأكملها

قررت شركة AT&T ترقيةَ برنامج بقصد تسريع المكالمات لتقديم خدمة أفضل للعملاء، ولكنّ سطرًا واحدًا من التعليمات البرمجية في برنامج الترقية تسبّب في وقوع كارثة كبيرة.

يُعدّ فقدان الاتصالات من أحد المخاطر التي تحاول الشركات تجنب الوقوع فيها، لكنّ هناك عدة أسباب لفقدان الاتصالات منها الكوارث الطبيعية؛ فإذا حدث زلزال أو إعصار شديد غالبًا سوف تسبب خللًا في الألياف البصرية المدفونة، أو خللًا في محطات الإرسال والاستقبال؛ مما يسبب فقدان الخدمة وانقطاع الاتصالات. وغالبًا ما يوجد خطط طوارئ لمثل هذه الحالات، ولكن ما حدث مع شركة AT&T كان حدثًا غيرَ مسبوق.

إنّ شركة AT&T هي شركة أمريكية، يقع مقرها الرئيس في وسط مدينة دالاس في ولاية تكساس، وهي مصنّفة في المركز الأول بوصفها أكبر شركة اتصالات في العالم، وفي المركز الثاني بوصفها أكبر مزوّد لخدمات الهاتف المحمول (1).

الترقية وبداية ظهور المشكلة

كان لدى الشركة 114 مفتاحًا (Switch) للإرسال والاستقبال في جميع أنحاء الولايات المتحدة الأمريكية مَهمّتها معالجة المكالمات وتوجيهها، وهذه المفاتيح جميعها مرتبطة بعضها ببعض بواسطة شبكة متتالية تُعرَف بنظام إشارات القنوات المشتركة (Common Channel Signaling System). يستطيع كلٌّ من هذه المفاتيح التعامل مع ما يصل إلى 700000 مكالمة في الساعة، وهذا ما كان يسمح للشركة بنقل 70% من حركة الاتصالات وتوجيه أكثر من 115 مليون مكالمة هاتفية (1-3).

قبل الترقية

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

بطبيعة الحال بعد إصلاح المفتاح X وعودته إلى العمل يجب أن يرسل رسالة إلى المفاتيح المتصلة به ليخبرهم أنه الآن متوفر وجاهز للعمل؛ مما يؤدي إلى إعادة تعيين في جميع المفاتيح المتصلة بالمفتاح X  للاعتراف بعودته، وهذا ما يسمح للمفاتيح بالتفاعل معه من جديد (1,2).

بعد الترقية

لم يرسل المفتاح X إلى المفاتيح المتصلة به الرسالة التي مفادها أنه عاد إلى الخدمة، بل بدأ مراسلة المفاتيح كالمعتاد. وكما نعلم؛ إن المفاتيح الأخرى يجب عليها إعادة تعيين نفسها لبدء التفاعل مع المفتاح X مرة أخرى.

هذه الترقية سمحت بوقت إعادة تعيين أسرع، ومن ثم أصبحت سرعات التوجيه أسرع.

قد تتساءل هنا ماذا يعني ذلك؟ سوف نوضّح ما تسببت به هذه الترقية (2,1).

ما الخطأ الذي حدث؟ ولماذا؟

الخطأ الذي حدث

عندما حُمِّلت الترقية إلى المفتاح X أعاد تعيين نفسه وأرسل إلى المفاتيح المتصلة به أنه الآن في حالة ازدحام؛ أي إنه خارج الخدمة.

بعد الانتهاء من تحميل الترقية للمفتاح X وعودته إلى العمل؛ راسل مجددًا المفاتيح المتصلة به (سوف نسمّيه المفتاح Y لتسهيل الشرح) وأخبرهم أنه عاد إلى العمل، مما جعل المفتاح Y يعيد تعيين نفسه من أجل الاعتراف بعودة المفتاح X. ولكن بينما كان المفتاح Y على قيد إعادة التعيين للاعتراف بعودة المفتاح X؛ أرسل المفتاح X رسالة ثانية إلى المفتاح Y، وكانت هذه الرسالة تحمل الترقية؛ مما جعل المفتاح Y يعتقد أنه عليه إعادة تعيين نفسه مرة أخرى لتحميل الترقية، ومن ثم يخبر المفاتيح المتصلة به أنه الآن في حالة ازدحام (أي إنه خارج الخدمة)، وبمجرد تحميل الترقية وعودة المفتاح راسل المفاتيح المتصلة به (سنسمّيه المفتاح Z) وأخبرهم أنه عاد إلى العمل، وبينما كان المفتاح Z في قيد إعادة التعيين للاعتراف بعودة المفتاح Y إلى الخدمة، أرسل المفتاح Y رسالة أخرى إلى المفتاح Z والتي كانت تحمل الترقية، وهذا ما جعل المفتاح Z يعتقد أنه عليه إعادة تعيين نفسه مرة أخرى؛ مما جعله يخبر المفاتيح الأخرى أنه خارج الخدمة الآن، وهكذا تكررت المشكلة على نحو مستمر في مفاتيح الشبكة كلها (114 مفتاحًا)؛ مما جعل المفاتيح تعيد تعيين نفسها وإرسال إشارات ازدحام باستمرار بدون توقف (2,1).

لماذا حدث الخطأ؟

صُمِّم نظام الاتصال لشركة AT&T بحيث لا يمكن لمفتاح واحد تعطيل النظام بأكمله، والمفتاح الواحد له الصلاحية بمراقبة المفاتيح الأخرى المتصلة به، وهذا من شأنه أن يسمح للمفاتيح بمعرفة ما إذا كانت المفاتيح الاخرى متاحة أم لا.

جاءت المشكلة في التعليمات البرمجية عندما أُضيفَ سطرٌ واحد -على نحو غير مقصود- إلى برنامج إعادة التعيين في المفاتيح كلها. كان الخطأ في برنامج C عندما ظهرت عبارة break ضمن جملة if التي أُدخِلَت ضمن جملة Switch. وبينما كان المفتاح (Switch) مشغول في الرسالة الأولى تلقى الرسالة الثانية (سطر 7)، كان على البرنامج إنهاء جملة if (سطر 7)، وتعيين المؤشر إلى قاعدة البيانات (السطر 11)، ولكن بسبب عبارة break في السطر 10؛ خرج البرنامج من case statement تمامًا وذهب إلى السطر 13 الذي ينصّ على تفعيل المعيار الأمثل (Optimum Parametre)، وهذا يعني أنّ كلَّ مفتاح سوف يَعدّ المفاتيح الأخرى غير متاحة، وفي هذه الحالة أصبحت المفاتيح كلها لا يمكن الاعتماد عليهم في الوقت نفسه؛ أي أصبحوا جميعًا خارج الخدمة، مما تسبب في حدوث الفشل المتتالي (Cascading failure) وشلّ نظام الاتصال (1).

سودوكود الخطأ الذي أصاب شبكة AT&T بالشلل (1).

متى حُلَّت المشكلة؟

توقفت هذه المشكلة بعد 9 ساعات، عندما اكتشف المهندسون ما كان يجري خفّضوا حمولة الشبكة بما يكفي للسماح للنظام بالاستقرار وإعادة إصلاح الشبكة بأكملها (1,3).

ما الذي كان يمكن فعله لتجنب المشكلة؟

لم يكن سهلًا إيجاد أساس المشكلة وحلها لأن البروتوكول مشفرٌ ومجمع باستخدام لغة C؛ مما يعني أنّ هذه المشكلة بالذات لم تكن واضحة كما لو كانت في لغة برمجية منظّمة مع مترجم أكثر صرامة مثل ++C.

والعامل الآخر الذي ساهم في ذلك هو أنّ المفاتيح تعيد تعيين نفسها عند حدوث أي تغيير في النظام. هذه الممارسة ضعيفة لأنها طريقة سهلة لتعطيل المفاتيح.

إنّ وجود جهاز ونظام برمجي أكثرُ تحمّلًا للخطأ ويمكنه التعامل مع المشكلات البسيطة دون إعادة تعيين كان سيقلل هذا الخلل على نحو كبير (1). 

النتيجة

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

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

تعديل الصورة: Ziad Nofal

المصادر: