التعامل مع الأعطال لا ينتهي بالاستعادة ── نمط ما بعد الحادثة (منع التكرار) للفِرَق الصغيرة

«المشكلة نفسها التي أصلحتموها لنا الشهر الماضي ظهرت مجدّداً في شاشة أخرى» ── هل سبق أن تلقّيت هذه العبارة من عميل يستخدم نظاماً تُصيِّنونه، وارتبكت في الردّ؟

التعامل مع العطل نفسه، أي: الاكتشاف، وتحديد موضع السبب، والإصلاح، والإصدار، والاعتذار ── حتّى هذه المرحلة تُنجزها معظم الفِرَق بإتقان. المشكلة تكمن فيما بعد ذلك. بمجرّد الاستعادة، يعود الجميع إلى العمل اليوميّ، ويبقى سجلّ العطل مبعثراً في صندوق بريد شخص ما وسجلّات دردشة حتّى يتلاشى مع الوقت. وبعد ستّة أشهر، يتكرّر عطل بالبنية نفسها في موضع مختلف، ويُعاد التحقيق نفسه من الصفر مجدّداً. التعامل مع العطل بـ«الإصلاح والاعتذار ثمّ الانتهاء» تشغيلٌ يدفع فيه الفريق الرسوم الدراسيّة نفسها مرّات متكرّرة.

تناولنا في مدوّنتنا الجانب التقنيّ من التحقيق في الأعطال في مقالات مثل «مقدّمة عمليّة لجمع crash dumps في تطبيقات Windows» و«الممارسة العمليّة لالتقاط الاستثناءات وتسجيلها ومعالجة الأخطاء»، وشرحنا فيها «كيفيّة الوصول إلى السبب». هذا المقال يتناول الخطوة التالية لذلك، وهي كيفيّة إدارة المراجعة (ما بعد الحادثة) لمنع تكرار العطل نفسه بعد معرفة السبب. لن نتناول خدمة ويب كبيرة، بل نُركِّز على النمط القابل للاستمرار الفعليّ في فريق صغير من شخصين إلى خمسة أشخاص يُصيِّن تطبيقات أعمال وبرمجيّات Windows.

1. الخلاصة أوّلاً

• الاستعادة، وتحقيق السبب، ومنع التكرار عمليّات مختلفة. الاستعادة هي «إعادة عمل اليوم»، وتحقيق السبب هو «جعل تفسير سبب الحدوث ممكناً»، ومنع التكرار هو «تغيير الآليّة». الخلط بينها يجعل الكلّ ناقصاً.
• عدم البحث عن الجاني (blameless) ليس أخلاقاً بل منفعة عمليّة. في الجلسات التي يُلام فيها الأفراد، تتوقّف المعلومات عن الظهور، فيتعذّر الوصول إلى السبب. مبدأ blameless postmortem الذي استقرّ في مجال SRE يفترض أنّ «كلّ من له علاقة تصرَّف بشكل صحيح ضمن نطاق المعلومات التي كانت متوفّرة لديه» ويبحث عن ثغرات الآليّة انطلاقاً من ذلك.¹
• تُصاغ إجراءات منع التكرار كآليّة (شيفرة، اختبار، مراقبة، إجراء) لا كـ«الحرص». الإجراء المعتمِد على انتباه الأفراد يزول مع تبديل الموظّفين. نُقدِّم في الفصل 6 جدولاً لتقييم قوّة الإجراء.
• يُقسَّم السبب إلى «سبب مباشر» و«عوامل مُساهِمة». ما يُصلَح غالباً هو العوامل المُساهِمة، والحيلة هي عدم إيقاف «تحليل لماذا-لماذا» عند سلوك فرد بل حفر ما بعده حتّى الآليّة.
• لا تُنفَّذ ما بعد الحادثة الكاملة لكلّ الأعطال. رتِّب الأولويّات حسب حجم الأثر × إمكانيّة التكرار (الفصل 7)، واكتفِ بتسجيل فقرة واحدة للأعطال الطفيفة. الحفاظ على حجم يمكن الاستمرار فيه هو أهمّ شرط لعدم قتل النظام.
• اجعل ما بعد الحادثة بحجم يُكتَب في ساعة واحدة. نُقدِّم في الفصل 4 قالباً أدنى. وثيقة رائعة تُكتَب صفراً في الشهر أقلّ قيمةً من سجلّ خام يُترَك في كلّ مرّة.
• في التطوير بالتعهيد، افصل الهدف عن تقرير العطل الموجَّه للعميل، مع نقل المحتوى من ما بعد الحادثة (الفصل 8). عدم خلط وثيقة تحديد المسؤوليّة بوثيقة منع التكرار يحمي جودة الاثنتين.

2. لماذا يتكرّر العطل نفسه

للأعطال المتكرِّرة نمط تشغيليّ لا تقنيّ.

بمجرّد الاستعادة، يُعتبَر الأمر «انتهى». التعامل مع العطل مقاطعة طارئة، لذا بمجرّد الاستعادة، يعود الجميع إلى العمل المعتاد المتراكم. وقت المراجعة غير مُدرَج في تقويم أحد، و«سنفعلها حين نهدأ» لا تأتي أبداً.

ينتهي التقرير بـ«سنحرص مستقبلاً بما يكفي». يُكتَب في خانة منع التكرار الخاصّة بالتقرير المُقدَّم للعميل أو المدير عبارات مثل «سنُشدِّد على التحقّق» أو «سنُجري فحصاً مزدوجاً»، وتُختَتم بذلك. هذه العبارة لا تُغيِّر أيّ آليّة، لذا بعد أشهر حين يخفّ الانتباه، يقع الفريق في الحفرة نفسها.

تحويلها إلى مسؤوليّة فرديّة دون إصلاح البنية. إن انتهى الأمر بعبارة «لأنّ ذلك الشخص أهمل الاختبار»، فإنّ البنية التي سمحت بإهمال الاختبار (لا توجد بوّابة اختبار في إجراء الإصدار، ويُتغاضى عن الحذف تحت ضغط المواعيد) تبقى كما هي. في المرّة القادمة، سيُهمِل شخص آخر الأمر نفسه.

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

كلّ هذا ليس مشكلة قدرة، بل نتيجة عدم تعريف المراجعة كجزء من العمل. لهذا السبب بالذات، فإنّ تحديد النمط (القالب ومعيار التنفيذ) مسبقاً له قيمة.

3. ما هي ما بعد الحادثة ── ترجمة نمط SRE للصيانة الصغيرة

ما بعد الحادثة (postmortem) نمط مراجعة يُوثَّق فيه الأثر، والسبب الجذريّ، والتسلسل الزمنيّ للتعامل، وإجراءات منع التكرار، كسجلّ للحادث، واستقرّ على نطاق واسع من خلال ممارسة SRE (هندسة موثوقيّة المواقع) في Google. جوهره هو مبدأ blameless (بلا لوم). «تُكتَب ما بعد الحادثة بلا لوم بافتراض أنّ جميع من له علاقة تصرَّفوا بحسن نيّة وبشكل صحيح بناءً على المعلومات التي كانت لديهم في تلك اللحظة» ── بدل معاقبة الأشخاص، تُصلَح الآليّة التي منعت التصرّف الصحيح.¹

هذا التفكير ليس حكراً على Google؛ ففي إرشادات العمارة الخاصّة بـ Microsoft (Azure Well-Architected Framework) أيضاً، تُعرَّف ما بعد الحادثة بأنّها «مراجعة منظَّمة بلا لوم يشارك فيها جميع أعضاء الفِرَق المعنيّة»، ويُوصى بإعادة نتائج تحليل السبب الجذريّ (RCA) إلى النظام في صورة تحسين عمليّة التعامل، وتعزيز الاكتشاف (القابليّة للملاحظة)، وتحسين التصميم.²

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

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

كمعيار تقريبيّ للهدف الذي تُكتَب من أجله ما بعد الحادثة، يذكر كتاب SRE أمثلة على معايير التنفيذ مثل التوقّف المرئيّ للمستخدمين، وفقدان البيانات، وتدخّل المناوبة الطارئة (on-call).¹ سنُعيد تنظيم المعايير الخاصّة بالفِرَق الصغيرة في الفصل 7.

4. أدنى قالب لما بعد الحادثة

أهمّ شرط للاستمرار هو الحجم. نُقدِّم قالب Markdown صُمِّم بحدّ أقصى هو إمكانيّة كتابة النسخة الأولى في ساعة واحدة. يُوصى بوضعه في ملفّ مؤرَّخ ضمن docs/postmortem/ في المستودع أو ما شابه، وإدارة إصداره في المكان نفسه مع الشيفرة.

# ما بعد الحادثة: عرض بيانات مكرَّرة في قائمة الطلبات عبر تجاوز التاريخ (2026-07-15)

- الحالة: مكتمل / الإجراءات قيد التنفيذ / مسجَّل فقط
- الكاتب: كومورا
- الخطورة: متوسّطة (استمرّ العمل لكن تطلَّب تسوية يدويّة)

## الملخّص (3 أسطر أو أقلّ)
عند فتح قائمة الطلبات أثناء تشغيل عمليّة الإغلاق الشهريّة، ظهرت
فواتير اليوم السابق مكرَّرة. المشكلة في العرض فقط، والبيانات في
قاعدة البيانات كانت صحيحة.

## الأثر (من / ماذا / كم)
- المتأثّرون: 3 موظّفين بمكتب المبيعات
- ما حدث: صفوف مكرَّرة في شاشة القائمة. حالة واحدة كادت فيها شحنة
  تُرسَل مرّتين بالخطأ
- المدّة: من حوالي 09:10 إلى 11:40 بتاريخ 7/15 (نحو ساعتين ونصف)

## التسلسل الزمنيّ
- 09:10 اتّصل مستخدم: «نفس الفاتورة تظهر في صفّين» (اكتُشِف)
- 09:30 مشاركة الشاشة عن بُعد؛ تأكيد شروط إعادة الإنتاج
- 10:15 إصلاح مؤقّت: طلب من المستخدمين عدم فتح القائمة أثناء تشغيل
  عمليّة الإغلاق
- 11:40 نُشِرت النسخة المُصلَحة وتأكَّد التعافي

## السبب المباشر
كان استعلام القائمة يُنفِّذ UNION ALL بين الجدول الرئيسيّ والصفوف
التي نسختها عمليّة الإغلاق إلى جدول مؤقّت (بلا تحكّم حصريّ).

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

## ما نجح
- كان المستخدم قد دوَّن الوقت في سجلّ عملياته الخاصّ، ممّا سرَّع
  تحديد شروط إعادة الإنتاج
- كانت آليّة النشر مؤتمَتة، فأمكن توزيع النسخة المُصلَحة في اليوم
  نفسه

## إجراءات منع التكرار (المسؤول والموعد النهائيّ)
- [ ] إضافة تأكيد لاكتشاف التكرار في استعلام القائمة (كومورا، 7/22)
- [ ] إضافة اختبار للتنفيذ المتزامن لعمليّة الإغلاق ومسار القراءة (كومورا، 7/29)
- [ ] دراسة إلغاء أسلوب الجدول المؤقّت لصالح عزل باللقطات (snapshot isolation) (كومورا، تحديد التوجّه بنهاية أغسطس)

نذكر بعض النقاط الواجب الانتباه إليها في الكتابة:

• اجعل «الملخّص» في 3 أسطر أو أقلّ. من سيبحث عن هذه الوثيقة لاحقاً هو أنت في المستقبل. فهم المحتوى في 3 أسطر عند العثور عليها بالبحث أهمّ من جمال تقسيم الفصول.
• اكتب في التسلسل الزمنيّ الوقائع فقط مصحوبةً بالوقت. افصل التفسير (كان ينبغي أن يكون كذا، كان يجب فعل كذا) في فقرة السبب. إن اختلط التفسير بالتسلسل الزمنيّ، يتعذَّر لاحقاً إعادة بناء ما حدث فعلاً.
• اكتب دائماً «ما نجح». يمنع ذلك تحوُّل المراجعة إلى جلسة لوم، ويكون مدخلاً لترقية ما نجح بالصدفة (وجود سجلّ بالمصادفة مثلاً) إلى آليّة.
• أضِف دائماً مسؤولاً وأجلاً لكلّ إجراء. الإجراء بلا مسؤول وأجل لا يُنفَّذ. تُحدَّد فعاليّة ما بعد الحادثة بمدى مراجعتها وتتبّع تنفيذ الإجراءات.¹

5. عمليّة تحليل السبب ── الفصل بين السبب المباشر والعوامل المُساهِمة

هناك سبب لتقسيم فقرة السبب في القالب إلى قسمَين.

السبب المباشر (direct cause) هو الحدث التقنيّ الذي تسبَّب مباشرةً في العطل. مثل «استثناء بسبب نسيان فحص NULL»، أو «UNION ALL بلا تحكّم حصريّ». هذا ما تُصلِحه رقعة الإصلاح (patch).

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

سبب هذا التقسيم بسيط: فحتّى لو أُصلِح السبب المباشر وحده، إن بقيت العوامل المُساهِمة، سيدخل سبب مباشر آخر من المسار نفسه. عبارة الافتتاح «الخطأ نفسه في شاشة أخرى» هي بالضبط هذا.

5.1 لا تُوقِف تحليل لماذا-لماذا عند «سلوك فرد»

«تحليل لماذا-لماذا» (5 Whys) أداة فعّالة لحفر السبب، لكن إن أخطأتَ اتّجاه الحفر، تصبح أداة للبحث عن الجاني. الفشل النموذجيّ هو التوقّف عند «لماذا ← لأنّ المسؤول نسي التحقّق». لا تتوقّف هناك، بل احفر خطوة أخرى.

• لماذا أمكن نسيان التحقّق ← لأنّ التحقّق لم يكن في دليل الإجراءات أو قائمة التحقّق، وكان معتمِداً على الذاكرة
• لماذا كان معتمِداً على الذاكرة ← لأنّ إجراء الإصدار لم يكن موثَّقاً، وكان يُنظَّم في كلّ مرّة على الفور

حين يظهر سلوك فرد كإجابة، فهذا ليس نهاية المطاف بل مدخلاً لـ«السؤال التالي الذي يستجوب الآليّة». إذا انطلقنا من فرضيّة أنّ الإنسان يخطئ حتماً، يتحوّل السؤال الواجب حفره من «لماذا أخطأ» إلى «لماذا وصل الخطأ إلى الإنتاج كما هو».

5.2 لا يبدأ التحليل بلا دليل

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

• crash dump: بتجهيز WER LocalDumps مسبقاً، يبقى dump التعطُّل غير الطبيعيّ دون الحاجة إلى طلب أيّ إجراء من المستخدم. طريقة الإعداد موضَّحة في «مقدّمة عمليّة لجمع crash dumps في تطبيقات Windows»، وطريقة القراءة في «قراءة crash dump عبر WinDbg + SOS».
• سجلّ التطبيق: الوقت، ومُعرِّف قابل للربط (correlation ID)، والكتابة المتزامنة للأحداث الحرِجة. راجع «تصميم الاحتفاظ بالسجلّ والـ dump عند تعطُّل تطبيقات Windows» للتصميم الذي يضمن بقاء السجلّ حتّى عند الانهيار.
• سجلّ الأحداث (Event Log): حتّى لو تعطَّل سجلّك الخاصّ، يبقى في سجلّ أحداث نظام التشغيل القياسيّ (Application Error) سجلّ انهيار التطبيق. طريقة الاستفادة منه مُلخَّصة في «مقدّمة إلى Windows Event Log وETW».

إن كتبتَ ما بعد الحادثة ولم يمتلئ التسلسل الزمنيّ، فهذا بحدّ ذاته عامل مُساهِم بمعنى «آليّة الاكتشاف والتسجيل غير كافية»، ومرشَّح لإجراء منع تكرار.

6. جودة إجراءات منع التكرار ── جدول تقييم القوّة

بعد كتابة إجراءات منع التكرار، يُقيَّم قوّتها. محور التقييم هو «إلى أيّ مدى تعتمد على انتباه الأفراد».

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

عندما لا يظهر سوى إجراءات ضعيفة، أعِد طرح هذه الأسئلة:

• «هل يتكرّر هذا العطل لو وُضِع موظّف جديد في الموقف نفسه؟» ── إن كانت الإجابة لا، فهذا يعني أنّه لم يصبح آليّةً بعد.
• «هل يمكن جعل المُترجِم أو الاختبار أو CI يكتشف هذا الخطأ؟» ── فمثلاً، إن كان «الاستثناء يُبتلَع دون معالجة عند الإنهاء»، فإنّ الإجراء القويّ ليس التوعية بل تنفيذ سياسة كتلك المُنظَّمة في «جدول قرار الإنهاء أو الاستمرار عند استثناء غير متوقَّع» كمعالج استثناء مشترَك في الشيفرة.
• «هل يمكن منع الخطأ؟ أو الإسراع في اكتشافه؟» ── إن كان المنع مكلفاً، فإنّ التوجّه نحو الاكتشاف (مراقبة، تنبيه، عمليّة دفعيّة للمطابقة) إجراء قويّ أيضاً. إعادة درس العطل إلى تعزيز الاكتشاف وتحسين التصميم توصية موجودة بالبنية نفسها في إرشادات Microsoft.²

الإجراءات القويّة تستهلك وقتاً، لذا من الناحية العمليّة، من الأنسب وضع «إجراء متوسّط يُنفَّذ هذا الأسبوع» و«إجراء قويّ يُنفَّذ الشهر القادم» معاً في قائمة الإجراءات، وإدارتهما عبر أجل محدَّد.

7. أيّ الأعطال تُطبَّق عليها ── ترتيب أولويّات التنفيذ

إلزام كتابة ما بعد الحادثة الكاملة لكلّ الأعطال يجعل الجميع يتوقّف عن الكتابة خلال ثلاثة أشهر. نُقرِّر مستوى التنفيذ حسب حجم الأثر × إمكانيّة التكرار.

نقاط التشغيل ثلاث:

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

8. التعامل في التطوير بالتعهيد ── العلاقة مع تقرير العطل الموجَّه للعميل

في التعاقد أو عقود الصيانة، يُطلَب من العميل «تقرير عطل» بعد وقوعه. تنظيم العلاقة بين ما بعد الحادثة والتقرير هنا يمنع ازدواج العمل.

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

لكن، انتبه إلى أنّهما وثيقتان مختلفتا الهدف وافصلهما.

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

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

9. خلاصة

• التعامل مع العطل لا ينتهي بالاستعادة. اجعل الاستعادة، وتحقيق السبب، ومنع التكرار عمليّات مستقلّة، وأدرِج المراجعة (ما بعد الحادثة) ضمن العمل.
• blameless (بلا لوم) مبدأ أساسيّ لما بعد الحادثة. إن لُمتَ الأفراد، تتوقّف المعلومات عن الظهور، فيتعذّر الوصول إلى السبب. لا تُوقِف التحليل عند سلوك فرد، بل احفر حتّى ثغرة الآليّة (العامل المُساهِم).¹
• تكفي الوثيقة بـأدنى قالب يُكتَب في ساعة واحدة (الملخّص، الأثر، التسلسل الزمنيّ، السبب المباشر، العوامل المُساهِمة، ما نجح، إجراء مع مسؤول وأجل). كأساس لملء التسلسل الزمنيّ، جهِّز مسبقاً حفظ الدليل من crash dump والسجلّات وسجلّ الأحداث.
• ارفع إجراءات منع التكرار من «الحرص» (ضعيف) إلى دليل الإجراءات (متوسّط)، وإن أمكن إلى المنع الآليّ عبر الاختبار والتأكيدات والمراقبة وتغيير التصميم (قويّ). إعادة الدرس إلى الاكتشاف والتصميم بنية مشترَكة بين إرشادات SRE وMicrosoft.¹²
• لا تُنفَّذ ما بعد الحادثة الكاملة لكلّ الأعطال. رتِّب الأولويّات حسب حجم الأثر × إمكانيّة التكرار، واترك دائماً فقرة واحدة كسجلّ حتّى للأعطال الطفيفة.
• في التطوير بالتعهيد، اكتب ما بعد الحادثة الداخليّة أوّلاً، ثمّ حرِّر تقرير العطل الموجَّه للعميل انطلاقاً منها. الفصل بين وثيقة المسؤوليّة/التعويض ووثيقة منع التكرار يحمي جودة الاثنتين.

مقالات ذات صلة

• مقدّمة عمليّة لجمع crash dumps في تطبيقات Windows - WER/ProcDump/WinDbg
• قراءة crash dump عبر WinDbg + SOS ── مقدّمة عمليّة للتحليل بعد الجمع
• تصميم الاحتفاظ بالسجلّ والـ dump عند تعطُّل تطبيقات Windows
• مقدّمة إلى Windows Event Log وETW ── وضع سجلّ تطبيقات الأعمال ضمن آليّة نظام التشغيل القياسيّة
• الممارسة العمليّة لالتقاط الاستثناءات وتسجيلها ومعالجة الأخطاء
• جدول قرار الإنهاء أو الاستمرار عند استثناء غير متوقَّع

مجالات الاستشارة ذات الصلة

تتعامل شركة Komura Soft LLC مع التحقيق في الأعطال المستعصية على إعادة الإنتاج وتحليل أسبابها، وبناء آليّة حفظ الدليل (السجلّات وجمع الـ dumps)، وتنظيم هيكل التشغيل والصيانة بما يشمل منع التكرار. نرحّب بالاستشارات حتّى من مراحل مثل «العطل نفسه يتكرّر» أو «إجراءات منع التكرار في تقرير العطل أصبحت شكليّة».

• تحقيق الأخطاء وتحليل الأسباب
• تعديل وصيانة برامج Windows القائمة
• الاستشارة التقنيّة ومراجعة التصميم
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

ما هي ما بعد الحادثة (postmortem)؟ وما الفرق بينها وبين تقرير العطل؟

ما بعد الحادثة هي وثيقة ونشاط مراجعة منظَّمة تُجرى بعد استعادة النظام من عطل، وهو أسلوب استقرّ في مجال SRE (هندسة موثوقيّة المواقع). بافتراض أنّها بلا لوم (blameless) للأفراد، تُسجَّل فيها التسلسلات الزمنيّة، والسبب المباشر، والعوامل المُساهِمة، وإجراءات منع التكرار. بينما تقرير العطل الموجَّه للعميل وثيقة تفي بمسؤوليّة الشرح عن «ما الذي حدث وكيف عولِج»، فإنّ ما بعد الحادثة وثيقة داخليّة تُقرِّر «كيف نُغيِّر الآليّة كي لا نُكرِّر الأمر نفسه». مع ذلك، بما أنّ معظم المحتوى يتداخل، فإنّ كتابة ما بعد الحادثة أوّلاً ثمّ تحرير تقرير العميل انطلاقاً منها ممارسة فعّالة.

إجراءات منع التكرار عندي تنحصر في «سنحرص مستقبلاً بما يكفي». ماذا أفعل؟

«الحرص/التوعية» يعتمد على ذاكرة الأفراد وحسن النيّة، فيزول أثره حتماً مع مرور الوقت وتبديل الموظّفين. عند التفكير في إجراء، أعِد طرح السؤال: «هل يتكرّر هذا العطل لو وُضِع موظّف جديد في الموقف نفسه؟» إن كانت الإجابة لا، فهذا يعني أنّه لم يصبح آليّةً بعد. الإجراءات القويّة هي التي تُكتشَف أو تُمنَع آليّاً دون اعتماد على انتباه الأفراد، مثل الاختبارات، والتأكيدات (assertions)، والقيود عبر الأنواع أو التصميم، وتنبيهات المراقبة. إن تعذَّر اتّخاذ إجراء قويّ فوراً، ضَع قائمة تحقّق أو دليل إجراءات كمرحلة وسيطة، وسجِّل الحلّ الدائم كإجراء ذي أجل محدَّد.

في التطوير بالتعهيد لفريق صغير، لا نملك وقتاً لكتابة ما بعد الحادثة لكلّ عطل.

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

عدم البحث عن الجاني (blameless) ── أليس هذا تغييباً للمسؤوليّة؟

لا. مبدأ blameless يهدف إلى تحويل التركيز من «من أخطأ» إلى «لماذا كانت الآليّة تسمح لهذا الشخص بالخطأ». إن أخطأ مُشغِّل في عمليّة، فالعامل المُساهِم موجود في الواجهة أو الإجراء الذي سمح بالخطأ. في المنظّمات التي تُعاقِب الأفراد، تُخفى المعلومات في العطل التالي، فيتعذَّر الوصول إلى السبب. في المقابل، مسؤوليّة الشرح تجاه العميل (ما الذي حدث وكيف يُعوَّض) ينبغي أن تُؤدَّى كوثيقة وعمليّة منفصلة، ولا تتعارض مع المراجعة بلا لوم. الفصل بين وثيقة تحديد المسؤوليّة ووثيقة منع التكرار هو النقطة العمليّة الأساسيّة.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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