يا جماعة الخير، بدي أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه طول عمري. كنا في عز الشغل على مشروع ضخم لأحد العملاء، والسيرفرات شغالة زي الساعة. وفجأة، وبدون سابق إنذار، وقع النظام كله. الشاشة صارت سوداء، والعميل على التلفون بصيح، والفريق كله في حالة هلع. بعد ساعات من التوتر والضغط، اكتشفنا المشكلة: تحديث بسيط لقاعدة البيانات عمله واحد من المبرمجين الجداد، شب اسمه “سامر”، هو اللي سبب كل هالكارثة.
اليوم التالي، المدير دعا لاجتماع “ما بعد الكارثة”. والله يا جماعة، ما كان اجتماع، كان محكمة تفتيش. كل العيون كانت على سامر. أسئلة مثل “كيف بتعمل هيك؟”، “ما قرأت التوثيق؟”، “أنت السبب في خسارتنا!”. الشب وجهه صار أصفر، وحسيت روحه بتنسحب منه. خرج سامر من الاجتماع وهو شخص محطّم. والأسوأ؟ إنه بعد فترة قصيرة ترك الشركة. لكن الكارثة الأكبر كانت إنه بعد ستة أشهر، وقعنا بنفس الخطأ تقريباً، لكن مع مبرمج مختلف. وقتها أدركت إنه المشكلة ما كانت في سامر، المشكلة كانت فينا، في ثقافتنا اللي بتبحث عن كبش فداء بدل ما تبحث عن حل جذري.
جحيم ثقافة اللوم: عندما يصبح البحث عن “المُذنب” هو الهدف
الحكي بينا، معظم الشركات اللي اشتغلت فيها أو شفتها في بداياتي كانت عايشة في “ثقافة اللوم” (Blame Culture). لما تصير مشكلة، أول سؤال بينطرح مش “شو صار؟”، بل “مين عملها؟”. هاي الثقافة الهدّامة بتخلق بيئة عمل سامة، الها آثار كارثية:
- الخوف من التجربة والإبداع: بصير الموظف يخاف يجرب أي إشي جديد أو ياخد أي مبادرة، لأنه لو فشل، هو اللي رح ياكلها. الإبداع بموت في بيئة زي هاي.
- إخفاء الأخطاء: بدل ما المبرمج يجي ويحكي “يا جماعة أنا شكلي خبّصت في الكود الفلاني”، بصير يغطي على أخطائه ويدعي إنها مش منه، وهاد بخلي المشاكل الصغيرة تكبر وتصير كوارث.
- تركيز على الأشخاص بدل الأنظمة: بدل ما نحلل ليش نظامنا سمح لهاد الخطأ يصير، بنركز على معاقبة الشخص. بنفصل سامر، بس بننسى نصلح عملية مراجعة الكود (Code Review) اللي سمحت لكوده يوصل للإنتاج أصلاً.
- تآكل الثقة والسلامة النفسية: الفريق اللي بعيش في خوف دائم هو فريق مفكك. ما في ثقة، وما في إحساس بالأمان. كل واحد بحاول يحمي حاله على حساب زميله.
هاي البيئة مش بس بتقتل الروح المعنوية، هي بتمنع الشركة من أهم إشي: التعلم من الأخطاء. ولما ما نتعلم، بنضل نكرر نفس الغلطات مرة ورا مرة.
الخلاص: ما هي “ثقافة ما بعد الوفاة الخالية من اللوم” (Blameless Postmortems)؟
بعد كارثة سامر والكارثة اللي بعدها، قررت إني لازم أغير إشي. بلشت أقرأ وأبحث، ووقعت عيني على مصطلح غيّر حياتي المهنية: Blameless Postmortems. الاسم ممكن يكون غريب شوي، “ما بعد الوفاة”، لكن الفكرة عبقرية وبسيطة.
الفلسفة الأساسية وراها بتقوم على مبدأ جوهري:
“الناس لا يهدفون إلى الفشل، لكن الأنظمة المعقدة تفشل بطرق معقدة. نحن نفترض أن كل شخص قام بأفضل ما يمكنه بناءً على المعرفة والأدوات والموارد المتاحة له في تلك اللحظة.”
ببساطة، بدل ما نسأل “مين اللي غلط؟”، بنسأل مجموعة أسئلة مختلفة تماماً:
- ماذا حدث؟ (سرد موضوعي للوقائع)
- لماذا حدث؟ (تحليل عميق للأسباب الجذرية)
- كيف يمكننا منع حدوثه مرة أخرى؟ (وضع إجراءات عملية قابلة للتنفيذ)
الانتقال من “مَن” إلى “لماذا وكيف” هو جوهر الثورة. إحنا ما بنبحث عن مذنب، إحنا بنبحث عن نقاط الضعف في نظامنا (النظام التقني، نظام العمل، نظام التواصل) اللي سمحت بحدوث المشكلة.
خطوات عملية لتطبيق “جلسات ما بعد الوفاة” الفعالة
الحكي سهل، بس التطبيق هو المحك. عشان هيك، بدي أعطيكم الخطوات العملية اللي اتبعناها ونجحت معنا بشكل مذهل. خلينا نرجع لمثال سامر، بس هالمرة رح نتعامل مع الموقف بثقافة خالية من اللوم.
الخطوة الأولى: التحضير وجمع البيانات (بدون تحيّز)
قبل الاجتماع، لازم نجمع كل الحقائق الممكنة بشكل موضوعي. مدير الجلسة (Facilitator) هو المسؤول عن هاي المهمة. البيانات بتتضمن:
- الجدول الزمني (Timeline): متى بدأ الخطأ؟ متى تم اكتشافه؟ متى تم إصلاحه؟ لازم يكون دقيق بالدقيقة.
- السجلات (Logs): سجلات الأخطاء من السيرفرات وقواعد البيانات.
- المقاييس (Metrics): رسوم بيانية بتوضح أداء النظام (استهلاك المعالج، الذاكرة، …إلخ).
- التنبيهات (Alerts): كل التنبيهات اللي أطلقها نظام المراقبة.
- سجلات التواصل: المحادثات اللي صارت على Slack أو Teams وقت الحادثة.
الخطوة الثانية: عقد الاجتماع (الأمان النفسي أولاً)
أهم إشي في بداية الاجتماع هو ترسيخ مبدأ “الأمان النفسي”. مدير الجلسة لازم يبدأ بعبارة واضحة، مثل:
“يا جماعة الخير، أهلاً فيكم. هدفنا اليوم هو أن نفهم ما حدث لنتمكن من تحسين أنظمتنا. هذا الاجتماع خالٍ من اللوم. نحن نفترض أن الجميع، بمن فيهم سامر، كانوا يحاولون القيام بالعمل الصحيح. لن نبحث عن مذنب، بل عن فرصة للتعلم.”
هاي الجملة بتغير جو الاجتماع 180 درجة. بتشيل الخوف من قلوب الناس وبتخليهم يشاركوا بصدق.
الخطوة الثالثة: تحليل الأسباب الجذرية (Root Cause Analysis)
هون بتبلش المتعة الحقيقية. بنستخدم تقنية اسمها “الخمسة لماذا” (The 5 Whys) عشان نوصل للسبب الجذري، مش بس السبب السطحي.
المشكلة: الموقع توقف عن العمل.
- لماذا (1)؟ لأن قاعدة البيانات توقفت عن الاستجابة.
- لماذا (2)؟ لأنها استهلكت كل الذاكرة المتاحة (Memory Leak).
- لماذا (3)؟ لأن استعلاماً (Query) معيناً تم تشغيله آلاف المرات في حلقة لا نهائية تقريباً.
- لماذا (4)؟ لأن الكود الذي كتبه سامر لم يأخذ في الحسبان حالة نادرة (Edge Case) أدت إلى هذه الحلقة.
- لماذا (5)؟ وهنا مربط الفرس: لأن عملية مراجعة الكود (Code Review) لدينا لم تكن دقيقة بما يكفي لاكتشاف هذا النوع من الأخطاء المنطقية، ولا يوجد لدينا نظام اختبارات آلية (Automated Tests) يغطي هذه الحالة النادرة.
شفتوا كيف؟ بطلت المشكلة “سامر مبرمج سيء”، صارت المشكلة “عملياتنا وإجراءاتنا فيها ضعف وتحتاج لتحسين”. سامر هو مجرد عرض للمرض، مش المرض نفسه.
الخطوة الرابعة: تحديد الإجراءات التصحيحية (Action Items)
بناءً على تحليل الأسباب الجذرية، بنطلع بقائمة إجراءات واضحة ومحددة. هاي الإجراءات لازم تكون موجهة للنظام، مش للأشخاص.
مثلاً، بدل ما نحكي “يجب على سامر أن يكون أكثر حذراً”، بنحكي:
- إجراء 1: إضافة اختبارات آلية تغطي الحالة النادرة X. (المسؤول: فريق الجودة، الموعد: نهاية الأسبوع).
- إجراء 2: تحديث قائمة مراجعة الكود (Code Review Checklist) لتشمل التحقق من الحلقات اللانهائية المحتملة. (المسؤول: أبو عمر، الموعد: غداً).
- إجراء 3: إعداد نظام مراقبة لإطلاق تنبيه عند ارتفاع استهلاك ذاكرة قاعدة البيانات فوق 80%. (المسؤول: فريق العمليات، الموعد: خلال 48 ساعة).
- إجراء 4: سامر، بالتعاون مع مطور أقدم، سيقوم بإعادة كتابة الجزء المتسبب بالمشكلة. (المسؤول: سامر وزميله، الموعد: اليوم).
لاحظوا الإجراء الأخير: إحنا ما عزلنا سامر، بل دمجناه في الحل وعطيناه فرصة يتعلم من مطور خبير. هيك بنبنيه، ما بنحطمه.
الخطوة الخامسة: كتابة ومشاركة التقرير
كل اللي صار لازم يتوثق في تقرير واضح ومختصر ويتم مشاركته مع كل الفرق الهندسية في الشركة. الشفافية بتبني الثقة وبتضمن إنه الكل يتعلم من الدرس. التقرير عادةً بكون فيه:
- ملخص: شو صار وشو تعلمنا.
- التأثير: على العملاء والنظام.
- الجدول الزمني للأحداث.
- تحليل الأسباب الجذرية.
- قائمة الإجراءات التصحيحية مع المسؤولين والمواعيد النهائية.
من الخوف إلى الإبداع: الثمار التي جنيناها
لما طبقنا هاي الثقافة، التغيير كان زي السحر. الاجتماعات اللي كانت محاكم تفتيش صارت ورشات عمل بناءة. سامر (اللي في قصتنا الحقيقية ما ترك الشغل) تحول من شب خايف ومنعزل لواحد من أكثر المطورين جرأة وثقة، وصار هو نفسه يساعد المبرمجين الجداد. الثمار كانت واضحة:
- سرعة في اكتشاف الأخطاء: صار المطور أول ما يشك إنه عمل إشي غلط، يجي يحكي مباشرة، فبنلحق المشكلة وهي صغيرة.
- تعلم حقيقي ومستمر: كل مشكلة صارت فرصة ذهبية لتحصين نظامنا وتقويته.
- جودة أعلى: الإجراءات التصحيحية خلت الكود والأنظمة أفضل بشكل تراكمي.
- روح فريق أقوى: الإحساس بالأمان خلى الناس تشتغل كفريق واحد ضد المشكلة، مش ضد بعض.
خلاصة الحكي والنصيحة الأخيرة مني إلكم 💡
يا جماعة الخير، الكوارث التقنية رح تضل تصير، هاي طبيعة شغلنا في عالم معقد. الخطأ مش في وقوع المشكلة، الخطأ الحقيقي هو في كيفية تعاملنا معها.
نصيحتي لكم: توقفوا عن البحث عن الساحرات وحرقهن، وابدأوا في إصلاح الأدوات والعمليات التي سمحت بحدوث “السحر الأسود” في المقام الأول.
ابنوا ثقافة تحتفي بالشفافية والتعلم، ثقافة تسمح للناس بالنمو من أخطائهم، مش تكسرهم. لما تعملوا هيك، مش بس رح تقللوا من تكرار الأخطاء، بل رح تبنوا فريقاً قوياً ومبدعاً لا يهاب التحديات، وهذا هو المكسب الحقيقي.
