من اللوم إلى التعلم: كيف حررتنا “استبيانات ما بعد الحادث” من ثقافة الخوف؟

يا جماعة الخير، خلوني أحكيلكم قصة صارت معي قبل كم سنة، قصة ما بنساها. كنا في عز الشغل على مشروع ضخم لأحد العملاء الكبار، والموقع شغال زي الحلاوة. فجأة، الساعة 2 بعد نص الليل، والتلفون برن… صوت زميلي بالطرف الثاني كله ذعر: “أبو عمر، الحق! الموقع كله واقع!”.

قلبي صار يدق بسرعة، فتحت اللابتوب وأنا مش مجمّع. لوحة المراقبة (Dashboard) كلها حمرا، وكأنها بتحكيلي “صباح الخير يا حلو”. كل الخدمات طافية، والعميل ببعت إيميلات زي المطر. بعد ساعتين من التوتر والبحث، اكتشفنا المشكلة: تحديث صغير في إحدى المكتبات (libraries) عمل تعارض وسبب انهيار لكل النظام. صلحنا المشكلة ورجعنا النظام يشتغل، بس الكارثة الحقيقية ما كانت تقنية، بل كانت باليوم اللي بعده.

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

هذاك اليوم، أدركت إنه مشكلتنا مش بالأخطاء التقنية، الأخطاء هاي جزء من شغلنا. مشكلتنا الحقيقية كانت في ثقافة اللوم والخوف من الفشل. ومن يومها، بلشت رحلتي في البحث عن حل، ولقيته في مفهوم بسيط بس قوي جداً: استبيانات ما بعد الحادث بدون لوم (Blameless Postmortems).

ما هو “جحيم الخوف من الفشل”؟

قبل ما نحكي عن الحل، خلينا نفهم أبعاد المشكلة. لما تكون ثقافة “مين الغلطان؟” هي السائدة في فريقك، بتصير عندك هالمصايب:

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

الخروج من الجحيم: فلسفة “استبيانات ما بعد الحادث بدون لوم”

الفكرة بسيطة بشكل عبقري. بدل ما نسأل “مين اللي غلط؟”، بنسأل “ليش نظامنا سمح لهالغلط إنه يصير؟”.

المبدأ الأساسي: البشر يخطئون، وهذا طبيعي. وظيفتنا مش نمنع البشر من الخطأ، بل نبني أنظمة (Systems) قوية ومرنة، تتحمل الأخطاء البشرية وتحد من تأثيرها، وتساعدنا نكتشفها بسرعة. الفشل مش غلطة شخص، هو فرصة لتحسين النظام.

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

كيف نطبق هذا المفهوم عملياً؟

بعد أي حادث (سواء كبير أو صغير)، بنعمل اجتماع وبنكتب تقرير اسمه “Postmortem”. الهدف من هذا التقرير مش التوثيق وبس، بل التعلم العميق. التقرير هذا لازم يجاوب على أسئلة محددة، والأهم، لازم يكون “بدون لوم”.

خلونا نمشي خطوة بخطوة في كيفية بناء هذا التقرير، بناءً على تجربتي الشخصية في تطبيقه مع فريقي.

الخطوات العملية لإجراء استبيان ما بعد الحادث

1. تحديد وقت ومكان آمن

بعد ما تهدأ العاصفة مباشرة (خلال يوم أو يومين من الحادث)، حدد اجتماعاً لكل من له علاقة بالحادث، من المهندس اللي كان مناوب (on-call) إلى مدير المنتج. الأهم هو أن يبدأ من يدير الجلسة (Facilitator) بالعبارة التالية: “نحن هنا اليوم لنفهم ما حدث، وليس لنلوم أحداً. كلنا نؤمن بأن الجميع كان يعمل بأفضل ما لديه بالمعلومات والأدوات المتاحة له في ذلك الوقت.”

2. بناء الخط الزمني للحادث (Timeline)

هذه أول وأهم خطوة. قبل التحليل، لازم نوثق الحقائق المجردة. شو صار ومتى صار بالضبط. بدون آراء، بدون تحليلات، فقط حقائق.

14:05 UTC: انطلاق أول إنذار (Alert) بوجود أخطاء 5xx على واجهة برمجة التطبيقات (API).
14:07 UTC: المهندس المناوب "سامي" يستلم الإنذار ويبدأ التحقيق.
14:15 UTC: سامي يشك أن المشكلة من قاعدة البيانات بسبب بطء في الاستعلامات.
14:25 UTC: يتم إشراك مهندس قواعد البيانات "علي".
14:40 UTC: علي يكتشف أن pool الاتصالات بقاعدة البيانات ممتلئ تماماً.
14:50 UTC: يتم اتخاذ قرار بإعادة تشغيل خدمة الـ API كحل مؤقت.
15:00 UTC: الخدمة تعود للعمل بشكل طبيعي بعد إعادة التشغيل.
15:15 UTC: إعلان انتهاء الحادث وبدء المراقبة المكثفة.

هذا الخط الزمني بيساعدنا نشوف الصورة كاملة وبشكل موضوعي.

3. تحليل السبب الجذري (Root Cause Analysis) بطريقة “الخمسة لماذا” (5 Whys)

هنا يبدأ السحر الحقيقي. بدلاً من التوقف عند السبب السطحي (“سامي عمل تحديث غلط”)، نتعمق أكثر باستخدام تقنية “الخمسة لماذا”.

المشكلة: الخدمة توقفت بسبب امتلاء pool الاتصالات بقاعدة البيانات.

• 1. لماذا امتلأ pool الاتصالات؟ لأن ميزة جديدة تم إطلاقها كانت تقوم بعمل استعلامات كثيرة جداً داخل حلقة (loop).
• 2. لماذا لم يتم اكتشاف هذا الأمر قبل الإطلاق؟ لأن مراجعة الكود (Code Review) ركزت على منطق العمل (Business Logic) ولم تنتبه لأثر الأداء.
• 3. لماذا لم تنتبه مراجعة الكود للأداء؟ لأن قائمة المراجعة (checklist) الخاصة بنا لا تحتوي على بنود واضحة لفحص الأداء أو الاستعلامات غير الفعالة.
• 4. لماذا لا تحتوي قائمتنا على هذه البنود؟ لأننا لم نقم بتحديث عملياتنا الهندسية لمواكبة نمو النظام وتعقيده. كنا نعتمد على “الخبرة الشخصية” للمراجعين.
• 5. لماذا كنا نعتمد على الخبرة الشخصية فقط؟ لأننا لم نخصص وقتاً كفريق لوضع وتوثيق أفضل الممارسات (Best Practices) بشكل منهجي، وكنا دائماً في “وضع إطفاء الحرائق”.

شايفين الفرق؟ انتقلنا من “غلطة المبرمج” إلى اكتشاف ضعف عميق في عملياتنا الهندسية. المشكلة ليست في المبرمج، بل في النظام الذي لم يزوده بالأدوات والدعم الكافي ليقوم بعمله على أكمل وجه.

4. تحديد الإجراءات التصحيحية (Action Items)

التحليل بدون إجراءات لا قيمة له. بناءً على تحليل “الخمسة لماذا”، نخرج بقائمة مهام واضحة، لكل مهمة مسؤول وتاريخ إنجاز متوقع.

• [مهمة 1] – الإجراء: تعديل الكود للميزة الجديدة لتقليل عدد الاستعلامات. المسؤول: فريق الميزات. التسليم: السبرنت القادم.
• [مهمة 2] – الإجراء: تحديث قالب مراجعة الكود (Code Review Template) ليشمل بنداً عن “تقييم أثر الأداء” و “فحص كفاءة استعلامات قاعدة البيانات”. المسؤول: أبو عمر. التسليم: نهاية الأسبوع.
• [مهمة 3] – الإجراء: البحث عن أداة تحليل كود ثابتة (Static Code Analysis) يمكنها اكتشاف الحلقات غير الفعالة تلقائياً ودمجها في الـ CI/CD pipeline. المسؤول: فريق البنية التحتية. التسليم: نهاية الربع الحالي.
• [مهمة 4] – الإجراء: عقد ورشة عمل للفريق بأكمله حول أفضل الممارسات في التعامل مع قاعدة البيانات. المسؤول: علي. التسليم: الشهر القادم.

هذه الإجراءات تحول الحادث من كارثة إلى استثمار في تحسين النظام للمستقبل.

نصائح من مطبخ أبو عمر 👨‍🍳

بعد سنين من تطبيق هذه المنهجية، تعلمت كم شغلة على الطريق الصعب، وخلوني أشاركم إياها:

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

الخلاصة: من ثقافة الخوف إلى ثقافة النمو 🪴

التحول إلى ثقافة “بدون لوم” ليس سهلاً ويحتاج وقتاً وجهداً وصبراً. هو ليس مجرد تطبيق عملية جديدة، بل تغيير جذري في العقلية. لكن النتائج تستحق كل هذا العناء.

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

تذكروا دائماً، هدفنا ليس بناء أنظمة لا تفشل أبداً، فهذا مستحيل. هدفنا هو بناء فرق وأنظمة تتعلم من الفشل بسرعة وفعالية. وهذا هو جوهر الهندسة الحقيقية، وجوهر القيادة الناجحة. جربوها، وأنا أضمن لكم أنكم لن تندموا أبداً.