ما هو التحليل اللاحق للحوادث البرمجية (Post-Mortem) وكيف تكتبه بفعالية؟

كل شركة لديها تسميتها الخاصة للأخطاء البرمجية ذات الأولوية القصوى: أولوية أولى، حالات طوارئ، إصلاحات حرجة، أو إصلاحات عاجلة. هناك أخطاء برمجية يمكن أن تتسبب في شل عمل الشركات إذا لم يتم التعامل معها بسرعة. على سبيل المثال، كانت مجموعة Knight Capital Group شركة خدمات مالية أمريكية. نسي فني نسخ بعض الأكواد الجديدة إلى خادم كمبيوتر، وتسبب هذا الإصدار البرمجي في خسارة الشركة 440 مليون دولار. حدث هذا لأن أحد خوادم الكمبيوتر بدأ في شراء الأسهم بسرعة جنونية (أكمل أكثر من 4 ملايين عملية شراء وبيع) خلال فترة 45 دقيقة.

ليست كل الأخطاء البرمجية بهذه الدرامية، ولكن هناك لحظات في حياة المطور البرمجي حيث يتعين عليه حل الأخطاء بأسرع ما يمكن. لقد تعلمت مؤخراً عن الشركات التي تنشر تحليلاتها اللاحقة للحوادث (Post-Mortems) المتعلقة بأخطائها الطارئة بشكل علني، وتعمقت في دراستها.

ما هو التحليل اللاحق للحوادث البرمجية (Post-Mortem)؟

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

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

لماذا يجب علينا إجراء تحليل لاحق للحوادث البرمجية؟

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

أمثلة عملية على التحليلات اللاحقة للحوادث

أردت بعض التنوع في الشركات واللغات، لذا دعنا نراجع بعض الأمثلة من Google و Microsoft و Flowdock. عادةً ما يتضمن نموذج التحليل اللاحق للحوادث الشائع بعض التفاصيل الرئيسية مثل:

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

لنتعمق في الأمثلة.

حادثة Google: “هذا الموقع قد يضر جهاز الكمبيوتر الخاص بك” (2009)

إذا أجريت بحثاً على Google بين الساعة 6:30 صباحاً و 7:25 صباحاً بتوقيت المحيط الهادئ في 31 يناير 2009، لكنت رأيت رسالة “This site may harm your computer” مصاحبة لكل نتيجة بحث.

ماذا حدث؟ تقوم Google بوضع علامة على نتائج البحث بهذه الرسالة إذا كان الموقع معروفاً بتثبيت برامج ضارة. هذا تحذير لحماية مستخدمي Google، ويتم تجميعه بواسطة خوارزميات Google التلقائية، وإدخال البيانات يدوياً، ومنظمة غير ربحية تسمى StopBadWare.com. قام أحد المطورين بتحديث القائمة وأدخل عن طريق الخطأ حرف /، مما أدى إلى تطبيق التحذير على كل موقع! نعلم أن هذا كان خطأ بشرياً، وبسبب ذلك، طبقت Google بعض الاختبارات والفحوصات كلما تغير هذا الملف. (ولم أرَ ذلك يحدث مرة أخرى منذ عام 2009!)

يمكن العثور على التحليل اللاحق الكامل هنا.

انقطاع خدمة Microsoft لمدة 12 ساعة (2012)

شهدت Microsoft انقطاعاً لمدة 12 ساعة في 29 فبراير 2012.

ماذا حدث؟ لدى Microsoft ما يسمى بـ Fabric Controllers وهي أجهزة كمبيوتر تتحكم في حوالي 1000 خادم. تدير دورات حياتها، وتراقب صحتها، وتعيد تشغيل الخوادم عند تعطلها. يساعد عزل جميع هذه الخوادم في مجموعات من 1000 خادم في الحفاظ على مرونة النظام ويجعل الأعطال محصورة في Fabric Controller واحد (بدلاً من تعطل جميع خوادمها). يحتوي كل خادم في المجموعة على ما يسمى بـ Host Agent، ويستخدمه Fabric Controller لأداء المهام التي يراها ضرورية. أحد الأشياء التي يتعامل معها هو نشر شهادات SSL للحفاظ على استخدام الخوادم لبروتوكول HTTPS، وهي طريقة لتشفير البيانات.

لمعرفة متى تحتاج شهادات SSL هذه إلى إعادة التوليد، فإنها تأخذ اليوم التالي عند منتصف الليل وتضيف عاماً واحداً. لذلك إذا كان Fabric Controller ينشئ شهادة جديدة لخادم في 19 مارس 1990، فستنتهي صلاحيتها في 20 مارس 1991. هل ترى إلى أين يتجه هذا؟ حاولت هذه الخوادم إنشاء شهادة لمدة عام واحد لخادم في سنة كبيسة. كانت تحاول تعيين انتهاء صلاحية الشهادات في 30 فبراير 2020. عندما تفشل الشهادات في الإنشاء للخادم، فإنه يتوقف. وإذا توقف ثلاث مرات متتالية، يعتبر ذلك فشلاً في الأجهزة، ثم يخبر Fabric Controller بأنه معيب. يقوم Fabric Controller، في محاولة “لإصلاح” الخادم الفاشل، بتحويل العمل إلى خادم آخر. واحداً تلو الآخر، ستتعطل جميع الخوادم أثناء محاولة إنشاء هذه الشهادات. وهذا يؤدي في النهاية إلى إغلاق Fabric Controller (مع 1000 خادم تابع له!).

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

يمكن العثور على التحليل اللاحق الكامل هنا.

حادثة Google: انقطاع خدمات Google Cloud (2015)

من الخميس 13 أغسطس 2015 إلى الاثنين 17 أغسطس 2015، حدثت بعض الأخطاء في خدمات Google Cloud، بالإضافة إلى فقدان دائم للبيانات بنسبة 0.000001% من بعض الأقراص الصلبة.

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

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

يمكن العثور على التحليل اللاحق الكامل هنا.

انقطاع خدمة Flowdock (2020)

أصبح تطبيق المراسلة الفورية Flowdock غير متاح لمدة 32 ساعة تقريباً بين 21 و 22 أبريل 2020. تم رصد سلوك غريب أيضاً، مثل عدم قدرة بعض المستخدمين على تسجيل الدخول. كما وجد بعض الأشخاص مستخدمين من مؤسسة أخرى في مؤسستهم (مثل اختلاط موظفي Amazon مع Microsoft، على سبيل المثال).

ماذا حدث؟ تسبب فيروس كورونا في زيادة مفاجئة في عدد الأشخاص الذين يعملون من المنزل، مما أدى إلى استخدام أعلى من المعتاد لـ Flowdock. تسبب هذا في استخدام عالٍ جداً لوحدة المعالجة المركزية (CPU) وتسبب في توقف قاعدة البيانات أثناء محاولة التعامل مع الحمل. كان هناك أيضاً بعض فقدان دائم للبيانات.

يمكن العثور على التحليل اللاحق الكامل هنا.

اعتبارات أساسية عند إجراء تحليل لاحق للحوادث

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

• لا تقم بتحليلات الحوادث لإلقاء اللوم على الأشخاص أو الفرق أو المؤسسات. بدلاً من ذلك، ركز على العمليات التي فشلت وسمحت بحدوث هذه الأخطاء.
• لا تقم أبداً بتحليل حادثة لمعاقبة شخص ما. لا توجد قيمة في ذلك، ولن تجد تحسينات.
• لا تفترض أن الأحداث التي وقعت كانت أكثر قابلية للتنبؤ مما كانت عليه. فقط لأنها حدثت أصبحت واضحة الآن. (Hindsight bias – انحياز الإدراك المتأخر).
• تأكد من التعمق بما فيه الكفاية. لا تقل فقط “رأينا خطأ في كود الواجهة الأمامية”. بل تعمق حقاً في الخطأ المحدد والظروف التي أدت إليه. كيف يمكن للعملية أن تكتشف هذا في المرة القادمة؟ عملية ضمان جودة أفضل؟ المزيد من مراجعات الأقران؟ تسجيل أخطاء أفضل؟
• اجعل خطوات الحل قابلة للتنفيذ وملموسة. إذا كانت خطوات الحل لمنع تكرار الخطأ غامضة مثل “تحسين التوثيق” أو “تدريب أفضل”، فأنت لا تفهم المشكلة بوضوح كافٍ لتكون أكثر تحديداً.
• حاول أن تبقي خطوات الحل ضمن الأشياء التي يمكن القيام بها على المدى القصير. نحن نحاول منع حدوث هذه الأخطاء مرة أخرى في أقرب وقت ممكن. يمكن أن تؤدي تحليلات الحوادث إلى تغييرات في العمليات على المدى الطويل، ولكن هذا ليس ما تركز عليه في الوقت الحالي.
• لا تحاول إعادة هيكلة شيء أساسي أو محاولة تغيير اللغة التي كتب بها جزء كبير من الكود.
• دع تحليلك للحوادث يتحدى ما يعتقده فريقك حالياً أنه صحيح. لا تفترض أنه لمجرد أن الجميع يعتقدون أن شيئاً ما صحيح فهو كذلك بالضرورة (Common belief fallacy – مغالطة الإجماع).

لمزيد من التعلم

إذا استمتعت بهذا المقال، يمكنك العثور على المزيد من التحليلات اللاحقة للحوادث العامة هنا. تتضمن هذه الأمثلة تحليلات من الشركات التي ناقشناها بالفعل، بالإضافة إلى أمثلة من Amazon، GitHub، Linux، Heroku، Spotify، Valve، Cloudfare، Etsy، GoCardless، Travis CI والمزيد.

الخلاصة التقنية

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