بتذكرها زي كأنها مبارح. كانت ليلة خميس، والكل متحمس لسهرة نهاية الأسبوع. كنا بنعمل آخر “deployment” (نشر للكود) لتحديث بسيط على نظامنا الأساسي. الأمور كانت ماشية زي الحلاوة، المؤشرات كلها خضرا، والشباب بلشوا يسلموا على بعض ويحكوا “يعطيكم العافية”.
أنا، كعادتي، كنت متخوّف شوي. عندي قاعدة بحبها: “لا تنشر كودك يوم الخميس!”. بس الفريق كان مصر، والتغيير كان صغير. قلت “يلا، توكلنا على الله”. بعد نص ساعة، وأنا قاعد بعمل كاسة شاي بالمرمية، بلش تلفوني يولّع. إشعارات من نظام المراقبة، رسائل على Slack، الدنيا قايمة قاعدة.
النظام واقع. مش بس بطيء، واقع تماماً. صفحة بيضا وعليها خطأ 503 Service Unavailable. العرق بلش ينزل على جبيني، ورجعت جري على المكتب. غرفة الدردشة تبعت الفريق كانت عبارة عن ساحة حرب. المدير التقني بيسأل بصوت عالي (يعني بالكتابة كابيتال): “مين آخر واحد عمل PUSH للكود؟؟”.
العيون كلها توجهت نحو “بشار”، مهندس جديد معنا، شب شاطر بس لسا بخطواته الأولى. بشار كان عامل تعديل بسيط على ملف الإعدادات (configuration). فوراً، بلش الدفاع عن النفس: “أنا متأكد إنه الكود تبعي سليم!”، “راجعت كل شي قبل ما أرفع الكود!”. التوتر كان قاتلاً. بدل ما نحل المشكلة، كنا بندور على “مين الغلطان”.
في هذيك اللحظة، شعرت بغصة. مش بس لأنه النظام واقع، بس لأنه شفت الخوف في عيون فريقي. شفت كيف ثقافة “البحث عن كبش فداء” بتشلّنا، بتحولنا من فريق متعاون لوحوش بتنهش بعضها. أخذنا ساعات طويلة لنرجع النظام، وفي النهاية اكتشفنا إنه المشكلة ما كانت من كود بشار مباشرة، بل كانت تفاعل معقد بين تغييره وخدمة ثانية ما كنا عاملين حسابها.
هذيك الليلة كانت نقطة تحول. قررت إنه لازم نغير. لازم نقتل وحش “اللوم” قبل ما يقتل روح الفريق. ومن هنا بدأت رحلتنا مع ما يسمى بـ “Blameless Postmortems”.
الكارثة: ثقافة “مين الغلطان؟”
قبل ما نحكي عن الحل، خلونا نحكي بصراحة عن المشكلة. ثقافة اللوم، أو الـ “Blame Culture”، هي السم الصامت في أي شركة تقنية. شكلها الخارجي ممكن يبين إنه في “مسؤولية” و”محاسبة”، لكن باطنها خراب بيوت. ليش؟
- الخوف من التجربة: لما يكون الفشل عقابه الإحراج أو التوبيخ، مين رح يتجرأ يجرب شي جديد؟ المبرمجين بصيروا يلعبوا في “المنطقة الآمنة” فقط، والإبداع بموت.
- إخفاء الأخطاء: بدل ما الموظف يجي يحكي “يا جماعة أنا عملت مشكلة، تعالوا نلحقها”، رح يحاول يخبيها أو يلف ويدور. والمشاكل الصغيرة اللي بتتخبى بتصير كوارث كبيرة بعدين.
- بطء في حل المشاكل: زي ما صار معنا، بدل ما نركز 100% على حل المشكلة، ضيعنا وقت وطاقة ثمينة في لعبة “مين السبب؟”.
- فقدان المواهب: البيئة السامة بتطرد الناس الشاطرة. محدش بحب يصحى الصبح ويروح على شغل هو خايف فيه من زملائه ومديره.
النقلة النوعية: ثقافة ما بعد الوفاة بلا لوم (Blameless Postmortem Culture)
الـ “Postmortem” بالترجمة الحرفية هي “تشريح ما بعد الوفاة”. في عالم الهندسة، هي جلسة تحليل بتصير بعد وقوع حادث أو مشكلة كبيرة (outage) عشان نفهم شو صار، ليش صار، وكيف نمنعه يصير مرة تانية. لكن الكلمة السحرية هي “Blameless” (بلا لوم).
المبدأ الأساسي: الناس مش أغبياء، الأنظمة هي اللي فيها ضعف
هذا المبدأ، المقتبس من ثقافة هندسة موثوقية المواقع (SRE) في جوجل، هو حجر الأساس. الفكرة بتقول:
“نحن نؤمن إيماناً راسخاً بأن كل من شارك في الحادثة كان يتصرف بأفضل النوايا بناءً على المعلومات المتاحة له في ذلك الوقت، وبناءً على مهاراته وقدراته.”
يعني، بشار ما صحي الصبح وقال “اليوم بدي أوقع النظام”. هو عمل اللي بشوفه صح. المشكلة مش في بشار، المشكلة في “النظام” (الـ System) اللي سمح لخطأ بشري بسيط إنه يسبب كارثة. النظام هون مش بس الكود، هو العمليات (Processes)، الأدوات (Tools)، وثقافة الفريق ككل.
التركيز على “لماذا” وليس “من”
في ثقافة اللوم، السؤال هو: “من تسبب في المشكلة؟”.
في ثقافة “بلا لوم”، السؤال هو: “لماذا حدثت المشكلة؟”. وبنضل نسأل “لماذا” لحد ما نوصل للسبب الجذري الحقيقي.
- لماذا وقع النظام؟ لأن ملف الإعدادات كان خاطئ.
- لماذا كان الملف خاطئاً؟ لأن بشار ارتكب خطأ أثناء تعديله. (هون ثقافة اللوم بتوقف وبتحكي “امسكوا بشار!”)
- طيب، لماذا تمكن بشار من رفع ملف خاطئ إلى الإنتاج؟ لأنه لا يوجد نظام فحص آلي (automated validation) لملفات الإعدادات قبل النشر.
- لماذا لا يوجد نظام فحص آلي؟ لأننا لم نعتبره أولوية من قبل.
- لماذا لم نعتبره أولوية؟ لأننا لم نكن ندرك حجم الخطر.
شفتوا كيف؟ انتقلنا من “بشار غلطان” إلى “عملياتنا الهندسية فيها ثغرة لازم نسدها”. هذا هو الفرق الجوهري.
كيف نطبقها على أرض الواقع؟ دليل أبو عمر العملي
الحكي حلو، بس كيف التطبيق؟ خليني أعطيكم الخطوات العملية اللي اتبعناها ونجحت معنا.
الخطوة الأولى: بعد الحادثة مباشرة (The Immediate Aftermath)
- أولاً، أصلح المشكلة: لا تبدأ أي تحليل والمشكلة لسا قائمة. كل التركيز لازم يكون على إعادة النظام للعمل (stabilization).
- عيّن مُيسّر (Facilitator): اختار شخص ليدير جلسة الـ Postmortem. الأفضل إنه ما يكون مدير مباشر للأشخاص المتورطين، ولا يكون هو الشخص اللي “تسبب” في المشكلة. دوره هو إدارة الحوار وضمان بقائه “بلا لوم”.
- اجمع البيانات، مش الآراء: اطلب من الفريق يجمع كل شي ممكن: سجلات (logs)، رسوم بيانية (graphs)، لقطات شاشة (screenshots)، محادثات Slack. الحقائق هي صديقنا في هذه المرحلة.
الخطوة الثانية: جلسة التحليل (The Postmortem Meeting)
اجمع كل المعنيين في اجتماع (ممكن يكون عن بعد). ابدأ الاجتماع بالتأكيد على القاعدة الذهبية: “هذه الجلسة ليست للمحاسبة أو اللوم، بل للفهم والتعلم. نحن هنا لنصلح الأنظمة، لا لنوجه أصابع الاتهام للأشخاص.”
الجلسة لازم تجاوب على الأسئلة التالية:
- الخط الزمني للأحداث (Timeline): شو صار ومتى بالضبط؟ من أول تغيير أدى للمشكلة، لحظة اكتشافها، محاولات الإصلاح، وحتى عودة النظام للعمل. كونوا دقيقين بالدقائق والثواني.
- الأثر (Impact): ما هو تأثير المشكلة على المستخدمين والعمل؟ (مثال: 30% من المستخدمين لم يتمكنوا من تسجيل الدخول لمدة 45 دقيقة).
- الأسباب الجذرية (Root Causes): باستخدام تقنية مثل “الأسئلة الخمسة لماذا” (5 Whys)، حاولوا توصلوا للأسباب الحقيقية. غالباً بيكون في أكثر من سبب جذري.
- نقاط التحسين (Action Items): هون مربط الفرس. كل سبب جذري لازم يقابله إجراء تصحيحي واضح وقابل للتنفيذ.
الخطوة الثالثة: كتابة ونشر التقرير
بعد الجلسة، المُيسّر بيكتب تقرير مفصل وبشاركه مع كل الشركة (أو على الأقل كل القسم الهندسي). الشفافية مهمة جداً. التقرير لازم يكون بسيط وواضح، وهذا نموذج بنستخدمه كثير:
# تقرير Postmortem: [اسم المشكلة] - [تاريخ المشكلة]
## ملخص (Summary)
وصف موجز للمشكلة في جملة أو جملتين.
مثال: في يوم 25 أكتوبر 2023، عند الساعة 10:00 مساءً، تسبب نشر خاطئ لملف الإعدادات في توقف خدمة تسجيل الدخول لمدة 45 دقيقة.
## الخط الزمني للأحداث (Timeline)
- 09:45 PM: تم دمج التغيير X في الفرع الرئيسي.
- 10:00 PM: تم نشر النسخة 1.2.3 إلى بيئة الإنتاج.
- 10:05 PM: بدأت أنظمة المراقبة بإرسال تحذيرات حول ارتفاع أخطاء 5xx.
- 10:15 PM: تم إعلان الحادثة في قناة #incidents.
- 10:45 PM: تم إعادة النظام للنسخة السابقة 1.2.2، وعادت الخدمة للعمل.
## الأسباب الجذرية (Root Causes)
1. **غياب التحقق الآلي:** لا يوجد لدينا عملية آلية للتحقق من صحة ملفات الإعدادات قبل نشرها.
2. **صلاحيات واسعة:** المهندس الجديد كانت لديه صلاحية النشر المباشر على الإنتاج دون مراجعة إضافية.
3. **بطء في الكشف:** استغرق نظام المراقبة 5 دقائق ليكتشف المشكلة.
## الإجراءات التصحيحية (Action Items)
| الإجراء | المسؤول | الموعد النهائي |
| ------------------------------------------------- | ------------ | -------------- |
| بناء سكربت للتحقق من ملفات الإعدادات ضمن الـ CI/CD | فريق البنية التحتية | 15-11-2023 |
| مراجعة صلاحيات النشر على الإنتاج للمهندسين الجدد | أبو عمر | 01-11-2023 |
| تحسين نظام المراقبة ليعطي تنبيهات أسرع (أقل من دقيقة) | فريق الـ SRE | 20-11-2023 |
## ماذا تعلمنا (Lessons Learned)
- أهمية وجود شبكة أمان (safety net) للعمليات الحساسة.
- النشر يوم الخميس لا يزال فكرة سيئة إذا لم تكن عملياتنا آلية 100% :)
الخطوة الرابعة: المتابعة ثم المتابعة
التقرير بدون متابعة هو مجرد حبر على ورق. لازم يكون في شخص مسؤول عن متابعة تنفيذ الإجراءات التصحيحية (Action Items). اعملوا اجتماعات دورية قصيرة بس لمتابعة هذه النقاط. لما الفريق يشوف إنه المشاكل بتتحول لتحسينات حقيقية على أرض الواقع، الثقة في العملية كلها بتزيد.
قصة بشار… والنهاية السعيدة
نرجع لقصة بشار. ثاني يوم الصبح، عملنا أول جلسة Postmortem بلا لوم حقيقية. كنت أنا المُيسّر. بلشت الاجتماع وحكيت: “يا جماعة، اللي صار مبارح مش غلطة بشار، هي غلطتنا كلنا كـ’نظام’. تعالوا نفهم كيف نظامنا خذلنا”.
شفت بشار كيف أخذ نفس عميق وارتخى. خلال الجلسة، بدل ما يدافع عن حاله، صار يشارك بمعلومات قيمة عن اللي صار معه. اكتشفنا الثغرات اللي حكيت عنها فوق (غياب الفحص الآلي، الصلاحيات الواسعة). الإجراءات التصحيحية كانت واضحة: نبني أدوات أفضل، ونحسن عملياتنا.
النتيجة؟ بشار ما ترك الشغل. بالعكس، صار من أكثر المدافعين عن هذه الثقافة. صار عنده ثقة أكبر، وصار يبادر ويقترح تحسينات. والفريق كله تعلم درس لا يقدر بثمن: الفشل ليس النهاية، بل هو فرصة للتعلم والنمو إذا تعاملنا معه صح.
خلاصة أبو عمر: نصيحة من القلب 🧡
يا جماعة الخير، بناء ثقافة “بلا لوم” مش رفاهية، هي ضرورة للبقاء والنمو في عالم التكنولوجيا سريع التغير. الموضوع مش سهل وبده وقت وصبر، خصوصاً من الإدارة العليا.
ابدأوا بخطوات صغيرة. في المرة القادمة اللي بتصير فيها مشكلة (وهي رح تصير، هذا وعد!)، جربوا تقاوموا غريزة البحث عن “مين الغلطان”، وبدلاً من ذلك، اسألوا بهدوء وفضول: “ليش نظامنا سمح لهالشي يصير؟ وكيف فينا نخليه أذكى وأقوى للمرة الجاي؟”.
تذكروا دائماً: الشركات العظيمة لا تبنى بأشخاص لا يخطئون، بل تبنى بأنظمة وفرق تتعلم من أخطائها بسرعة وفعالية. خليكم بخير، والله يعطيكم العافية.
