أذكرها وكأنها البارحة، تلك الغرفة الباردة وذلك الاجتماع الذي لن أنساه ما حييت. كنت في بداية مسيرتي المهنية، وكنا قد واجهنا انقطاعاً كبيراً في الخدمة الرئيسية لشركتنا. بطل القصة، أو “المتهم” بالأحرى، كان مهندساً شاباً اسمه “كريم”، انضم للفريق قبل أشهر قليلة. كان كريم شعلة من الحماس، لكنه ارتكب خطأً في إعدادات أحد الخوادم أدى إلى الكارثة.
بدأ الاجتماع، والجو “مكهرب” كما نقول في فلسطين. المدير التقني بدأ حديثه بنبرة حادة، وعيناه تبحثان عن كبش فداء. لم يمر وقت طويل حتى تحول الاجتماع إلى محاكمة علنية لكريم. أسئلة مثل “كيف لم تنتبه لهذا؟” و “ألم تقرأ التوثيق؟” و “لماذا لم تسأل؟” كانت تنهال عليه كالسياط. رأيت وجه كريم الشاب وهو يذبل، وثقته بنفسه تتلاشى مع كل كلمة اتهام. في تلك اللحظة، لم نكن نحل مشكلة، بل كنا ندمر مهندساً واعداً ونزرع بذور الخوف في قلوب الجميع.
خرجنا من الاجتماع بقرار “تأديبي” لكريم، وببعض الإجراءات السطحية. لكن ما حدث حقاً هو أننا تعلمنا درساً واحداً فقط: “إذا حدثت مشكلة، إياك أن تكون أنت المسؤول، وإذا كنت، فافعل أي شيء لإخفاء الأمر”. هذا هو الجحيم الذي تبنيه ثقافة اللوم، وهو الجحيم الذي قررنا، بعد سنوات من المعاناة، أن نهرب منه.
ما هي مراجعة ما بعد الحادث (Postmortem)؟ ولماذا تحولت إلى كابوس؟
في عالم تطوير البرمجيات وهندسة المواقع (SRE)، “مراجعة ما بعد الحادث” أو الـ Postmortem هي عملية منظمة لتحليل حادث (مثل انقطاع خدمة، أو خرق أمني) بعد انتهائه. الهدف النظري هو فهم ما حدث، ولماذا حدث، وكيف يمكننا منع حدوثه مرة أخرى.
لكن للأسف، الطبيعة البشرية والضغوط الإدارية غالباً ما تحوّل هذا الهدف النبيل إلى ما أسميه “ثقافة البحث عن كبش فداء”. عندما تكون هناك خسائر مالية أو ضرر لسمعة الشركة، يكون من الأسهل نفسياً وإدارياً إلقاء اللوم على شخص واحد بدلاً من الاعتراف بوجود ضعف في النظام ككل.
الجحيم الصامت: الآثار المدمرة لثقافة اللوم
ثقافة اللوم لا تؤدي فقط إلى اجتماعات سيئة، بل تسمم بيئة العمل بأكملها وتترك آثاراً مدمرة على المدى الطويل:
- الخوف من التجربة والإبداع: يصبح الموظفون حذرين بشكل مبالغ فيه. لا أحد يجرؤ على تجربة شيء جديد أو اقتراح تحسين جريء خوفاً من أن ينقلب عليه ويصبح هو “المتهم” التالي.
- إخفاء المشاكل لا حلها: عندما يكتشف مهندس خطأً بسيطاً، فإنه قد يميل إلى إخفائه أو التستر عليه بدلاً من الإبلاغ عنه، لأن الإبلاغ قد يعرضه للمساءلة. هذه الأخطاء الصغيرة تتراكم لتصبح قنبلة موقوتة.
- هجرة العقول والكفاءات: المهندسون الموهوبون والمحترفون لا يبقون في بيئة سامة. يفضلون العمل في مكان يشعرون فيه بالأمان النفسي، حيث يُنظر إلى الأخطاء على أنها فرص للتعلم لا سبب للعقاب.
- بطء في التعافي من الحوادث: في خضم الحادث، بدلاً من أن يتعاون الجميع بسرعة لإيجاد حل، يبدأ البعض في قضاء وقت ثمين في جمع الأدلة التي تبرئ ساحتهم وتدين الآخرين.
الضوء في نهاية النفق: تقديم “ثقافة ما بعد الحوادث عديمة اللوم” (Blameless Postmortem)
بعد سنوات من تلك الاجتماعات العقيمة، بدأت شركات عملاقة مثل Google وEtsy وNetflix تروّج لمفهوم ثوري: Blameless Postmortem. الفكرة بسيطة في ظاهرها، لكنها عميقة في تأثيرها.
ما هي بالضبط؟
ثقافة ما بعد الحوادث عديمة اللوم هي الاعتقاد الراسخ بأن الأفراد لا يأتون إلى العمل بهدف إحداث فشل. الجميع يتخذ أفضل القرارات الممكنة بناءً على المعلومات المتاحة لديهم في تلك اللحظة، ومهاراتهم، والسياق المحيط بهم.
“نحن لا نبحث عن من الذي فشل، بل عن ماذا في النظام هو الذي فشل وسمح للخطأ بالحدوث والتأثير.”
هذا التحول في التفكير ينقل التركيز من “خطأ بشري” إلى “ضعف في النظام”. إذا كان خطأ شخص واحد يمكن أن يسقط النظام بأكمله، فإن المشكلة الحقيقية تكمن في هشاشة النظام، وليس فقط في الشخص.
كيف نطبّقها على أرض الواقع؟ دليل أبو عمر العملي
التحول إلى هذه الثقافة لا يحدث بين عشية وضحاها، بل يتطلب جهداً واعياً والتزاماً من الجميع، خاصة من القادة. إليك خطوات عملية يمكنك البدء بها اليوم:
1. تهيئة الأجواء (قبل الاجتماع)
دور قائد الاجتماع (Facilitator) حاسم. يجب أن يبدأ الاجتماع بعبارة واضحة وصريحة، مثل:
“يا جماعة، أهلاً بكم في مراجعة ما بعد الحادث. أود أن أذكر الجميع بأن هذا الاجتماع عديم اللوم. نحن هنا لنفهم ما حدث ونحسن نظامنا، وليس لإلقاء اللوم على أي شخص أو فريق. كلنا عملنا بأفضل نية، والآن دعونا نتعلم معاً.”
هذه العبارة البسيطة تضع قواعد اللعبة وتخلق مساحة آمنة للجميع للمشاركة بصدق.
2. لغة الحوار: استبدل “من” بـ “ماذا” و “لماذا”
الكلمات التي نستخدمها تشكل واقعنا. دربوا أنفسكم وفرقكم على تغيير طريقة طرح الأسئلة:
- لا تسأل: “يا كريم، لماذا قمت بتنفيذ هذا الأمر على الخادم الإنتاجي؟”
- اسأل بدلاً من ذلك: “ما هي الظروف التي جعلت تنفيذ هذا الأمر على الخادم الإنتاجي يبدو كأنه الإجراء الصحيح في تلك اللحظة؟” أو “ماذا في نظامنا سمح بتنفيذ أمر خطير كهذا دون وجود حماية كافية؟”
الفرق شاسع. السؤال الأول هجومي ويبحث عن مذنب. السؤال الثاني استكشافي ويبحث عن ضعف في العملية أو الأدوات.
3. استخدم تقنية “الأسباب الخمسة” (The 5 Whys)
هذه تقنية بسيطة وقوية للوصول إلى السبب الجذري الحقيقي للمشكلة، بدلاً من التوقف عند الأعراض السطحية.
مثال:
- لماذا توقفت الخدمة؟ -> لأن قاعدة البيانات استهلكت كل موارد المعالج.
- لماذا استهلكت كل الموارد؟ -> بسبب استعلام (Query) غير فعال تم إطلاقه.
- لماذا تم إطلاق هذا الاستعلام؟ -> لأنه كان جزءاً من تحديث جديد تم نشره.
- لماذا لم يتم اكتشاف الاستعلام غير الفعال أثناء المراجعة؟ -> لأن عملية مراجعة الكود لم تتضمن فحصاً للأداء، والمهندس الذي قام بالمراجعة لم يكن لديه خبرة في هذا الجانب.
- لماذا لا تتضمن عمليتنا فحص الأداء ولم يتم إسناد المراجعة لخبير؟ -> لأننا لم نقم بتعريف وتوثيق مسار واضح للمراجعات الحرجة التي قد تؤثر على الأداء. (هذا هو السبب الجذري الحقيقي!)
لاحظ كيف انتقلنا من “استعلام سيء” إلى “عملية مراجعة قاصرة”. الآن يمكننا وضع إجراءات تصحيحية حقيقية.
4. مخرجات الاجتماع: وثيقة تعلم قابلة للتنفيذ
يجب أن ينتهي كل اجتماع postmortem بوثيقة تتم مشاركتها مع الجميع، وتحتوي على الإجراءات التصحيحية (Action Items). كل إجراء يجب أن يكون محدداً، وقابلاً للقياس، ومُسنداً إلى شخص معين، وله موعد نهائي. إليك قالب بسيط يمكنك استخدامه:
# تقرير ما بعد الحادث: انقطاع خدمة واجهة برمجة التطبيقات (API)
**تاريخ الحادث:** 2023-10-26
**ملخص:** انقطاع كامل للخدمة لمدة 45 دقيقة بسبب استعلام قاعدة بيانات غير فعال.
**الأثر:**
- فشل 100% من طلبات الـ API.
- تأثر ~50,000 مستخدم نشط.
**الجدول الزمني للأحداث (بتوقيت UTC):**
- 14:05: بدء تلقي تنبيهات بارتفاع أخطاء 5xx.
- 14:10: إعلان الحادث وبدء التحقيق من قبل فريق SRE.
- 14:25: تحديد النشر الأخير كسبب محتمل للمشكلة.
- 14:30: بدء عملية التراجع عن النشر الأخير (Rollback).
- 14:50: عودة الخدمة إلى طبيعتها بنسبة 100%.
**الأسباب الجذرية (تحليل الـ 5 Whys):**
- تم نشر استعلام يفتقر إلى فهرس (index) مناسب في قاعدة البيانات.
- لم يتم اكتشاف المشكلة أثناء الاختبار الآلي لأن بيانات الاختبار لم تكن كبيرة بما يكفي لإظهار المشكلة.
- عملية مراجعة الكود لم تفرض فحص خطة تنفيذ الاستعلام (Query Plan).
**الإجراءات التصحيحية (Action Items):**
- [ ] **المهمة:** إضافة خطوة آلية في مسار النشر (CI/CD Pipeline) تقوم بتحليل خطط تنفيذ استعلامات قاعدة البيانات الجديدة وتحذر من الاستعلامات المكلفة.
- **المالك:** أبو عمر
- **الموعد النهائي:** 2023-11-15
- [ ] **المهمة:** تحديث بيئة الاختبار (Staging) بنسخة أكبر وأكثر واقعية من البيانات.
- **المالك:** فريق DevOps
- **الموعد النهائي:** 2023-12-01
نصيحة من القلب: دور القائد هو الحماية لا الاتهام
إذا كنت في موقع قيادي (مدير، قائد فريق)، فمسؤوليتك الأولى في هذه الثقافة هي حماية فريقك. أنت الدرع الذي يقف بينهم وبين الضغوط الخارجية التي تبحث عن شخص تلومه. عندما يسأل مدير أعلى “من المسؤول عن هذا؟”، يجب أن تكون إجابتك: “أنا المسؤول عن الفريق وعن النظام. دعنا نركز على كيفية إصلاح النظام لنتجنب تكرار المشكلة”.
عندما يرى فريقك أنك تحميهم وتتحمل المسؤولية، سيبادلونك بالولاء والثقة، وسيتحولون من أفراد خائفين إلى فريق متماسك وقوي يحل المشاكل.
الخلاصة: من ثقافة الخوف إلى ثقافة النمو 🚀
يا جماعة الخير، التحول من ثقافة اللوم إلى ثقافة ما بعد الحوادث عديمة اللوم ليس مجرد “موضة إدارية”، بل هو تغيير جوهري في كيفية النظر إلى الفشل والنمو. إنه الاستثمار الأفضل الذي يمكنك القيام به في أنظمتك التقنية، والأهم من ذلك، في أفراد فريقك.
قد لا تكون كل الاجتماعات مثالية، وقد تظهر النزعة القديمة للوم من وقت لآخر، لكن المهم هو الالتزام بالمبدأ والمحاولة المستمرة. تذكروا دائماً، الحادث هو هدية غير متوقعة، فرصة مجانية يمنحها لك نظامك لتكتشف نقاط ضعفه وتقويها.
فلا تضيعوا هذه الهدية بالبحث عن شخص تلومونه، بل استغلوها لبناء أنظمة أقوى وفرق أكثر سعادة وإنتاجية. كلنا في هذا المركب سوياً، والنجاة للجميع تكون بتقوية المركب، لا بإلقاء البحارة منه. 😉
