معالجة الأعطال لا تنتهي بالاستعادة ── قالب postmortem (منع التكرار) للفرق الصغيرة

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

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

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

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

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

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 16، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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

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

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

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

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

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

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

3. ما هو postmortem ── تكييف قالب SRE لصيانة صغيرة

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

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

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

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

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

4. أدنى قالب لـ postmortem

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

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

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

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

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

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

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

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

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

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

نضع أيضاً قالباً فارغاً يمكن نسخه كما هو. ضعه في المستودع باسم docs/postmortem/_template.md، وعند وقوع عطل انسخه باسم يحمل التاريخ. هذا الأسهل.

# postmortem: الظاهرة في سطر واحد (YYYY-MM-DD)

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

## الملخص (3 أسطر أو أقل)

## الأثر (من / ماذا / كم)
- المتأثرون:
- المحتوى:
- المدة: MM/DD HH:MM ~ HH:MM (نحو   ساعة)

## التسلسل الزمني
- HH:MM  (اكتشاف: من اكتشف وكيف)
- HH:MM
- HH:MM  (معالجة مؤقتة)
- HH:MM  (تأكيد الاستعادة)

## السبب المباشر

## العوامل المساهمة
- (الشرط الذي سمح بالاختلاط)
- (الشرط الذي سمح بالإغفال)
- (الشرط الذي وسّع الضرر)

## ما نجح
-

## إجراءات منع التكرار (المسؤول والأجل)
- [ ]  (المسؤول, MM/DD)
- [ ]  (المسؤول, MM/DD)

نقاط ينبغي الانتباه إليها في الكتابة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.1 كيف نحكم أن الأمر «بنيوي»

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

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

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

7.2 كيف تُدار جلسة المراجعة (30 دقيقة)

جلسة المراجعة في الأعطال ذات الأثر الكبير تُدار بتحديد الوقت واتباع القالب.

• المشاركون 3 إلى 5. من عالج العطل، وعضو آخر قد يلمس الشيفرة نفسها، ومن يتولى واجهة العميل. لا تُدخل من موقعه الحكم على المسؤولية. في اللحظة التي يدخل فيها يصبح الكلام دفاعياً، وتتوقف العوامل المساهمة عن الظهور. إن لزم الأمر تكفي مشاركة النتيجة.
• وزّع المسودة مسبقاً. لا تبدأ الكتابة في الجلسة. ومع ذلك لا تفترض أن الجميع قرأ، فأدرج وقت قراءة في البداية.
• توزيع الثلاثين دقيقة. (1) 0 إلى 5 دقائق: يقرأ كل شخص بصمت. (2) 5 إلى 10: تأكيد وقائع التسلسل الزمني. سد فجوات الفهم والأوقات الناقصة. (3) 10 إلى 20: إضافة عوامل مساهمة. هنا جوهر الجلسة. (4) 20 إلى 28: تقييم قوّة الإجراءات (جدول الفصل 6) وتثبيت المسؤول والأجل. (5) 28 إلى 30: تحديد يوم التحقق التالي من التقدم.
• منظوران فقط للتحقق. «أين كان يمكن الاكتشاف أيضاً» و«هل الثغرة نفسها موجودة في موضع آخر». طرح هذين السؤالين على الجميع يُخرج عوامل مساهمة لا تظهر من المعالج وحده.
• يدير الجلسة شخص غير من عالج العطل. إن ظهر كلام فاعله اسم شخص، يستبدله المدير بفاعل هو الآلية. «نسي A التحقق» ← «التحقق لم يكن في الإجراء». مجرد إجراء هذا الاستبدال آلياً يغيّر جو الجلسة.
• لا تترك إجراء غير محدد. ما لا يمكن تقريره في الجلسة حوّله إلى إجراء «تقرير التوجه بحلول يوم كذا» وأغلقه بأجل.

7.3 أين يوضع سجل إدارة الأعطال

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

تكفي الأعمدة: «التاريخ / النظام والشاشة / الظاهرة / حجم الأثر / السبب المباشر / المعالجة / رابط إلى postmortem / هل هو تكرار». المهم ليس الأداة بل نقطتان: أن يزيد سطر حتى للعطل الطفيف، وأن يمكن البحث بعد سنوات بـ«الظاهرة نفسها». الاكتفاء بخيوط الدردشة والبريد لا يحقّق أياً منهما.

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

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

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

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

8.1 كيف تتغيّر الصياغة فعلاً

التجريد يصعّب الفهم، لذا نستخدم مثال القالب في الفصل 4 كما هو، ونقابل الوصف الداخلي بصياغة تقرير العميل.

مبادئ إعادة الكتابة ثلاثة.

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

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

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

9. خلاصة

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

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

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

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

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

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

روابط مرجعية

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

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

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

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

ما هو postmortem؟ وهل يختلف عن تقرير العطل؟

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

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

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

في تطوير البرمجيات المخصّصة (Custom Software Development) بفريق صغير، لا نملك وقتاً لكتابة postmortem لكل عطل.

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

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

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

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

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

غو كومورا

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

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