اللوم بعد العطل Blame: حين يلومك الفريق على ما لم تسببه

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

وهذا المقال عن هذا الموقف بالتحديد: أن يلومك الفريق أو المدير على عطل لم تسببه، أو تسببت في جزء منه فقط، أو أن يتحول اللوم إلى نمط يتكرر معك في كل مشكلة. ولن نتحدث عن إدارة الحادثة Incident Management نفسها تقنياً، فهذه لها أدواتها، وإنما عن الجانب الذي لا يتعلمه المهندس في الجامعة: ماذا تقول في الساعة الأولى، وكيف تجمع الحقائق دون أن تبدو كمن يدافع عن نفسه، ومتى تطلب من مديرك أن يتدخل، ومتى يكون الحل أن تبحث عن فريق آخر.

وسوف نناقش في هذا المقال ما يلي:

• لماذا يبحث الفريق عن شخص يلومه بعد العطل، وما الذي يخسره عندما يفعل ذلك.
• الحالة الأولى: اتهام علني بعد نشر لا علاقة له بالعطل، وكيف ترد في الساعة الأولى.
• الخط الزمني الشخصي Personal Timeline: كيف توثق ما حدث بالأوقات والمصادر.
• الحالة الثانية: عندما يكون لتغييرك دور حقيقي، وكيف تعترف دون أن تتحمل ما ليس عليك.
• حالتان موثقتان من GitLab وAmazon تعاملت فيهما الشركة مع الخطأ البشري على أنه مشكلة نظام.
• الحالة الثالثة: عندما يصبح اللوم نمطاً، ويظهر في تقييم أدائك Performance Review أو في إجراء تأديبي Disciplinary Action.
• متى تصعد ولمن، وما يقوله نظام العمل السعودي عن الجزاءات، ومتى تغادر.
• ما يفعله قائد الفريق Team Lead حتى لا يتكرر هذا الموقف، وقالب الخط الزمني الشخصي.

لماذا يبحث الفريق عن شخص يلومه؟ (Blame)

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

وهناك سبب ثان أعمق: في كثير من الفرق يكون السؤال المعتاد بعد كل مشكلة هو «من؟» وليس «كيف؟»، لأن الإدارة تريد اسماً تضعه في التقرير، أو لأن الفريق تعود أن العطل يعني أن شخصاً قصر. وفي فريق كهذا يتعلم الناس شيئاً واحداً بسرعة، وهو أن يخفوا أخطاءهم. ويشرح فصل ثقافة المراجعة بعد الحادثة Postmortem Culture في كتاب Google عن هندسة موثوقية المواقع SRE هذه النتيجة بوضوح: إذا كانت المراجعة تبحث عن مذنب فإن الناس لن يكشفوا المشكلات خوفاً من العقاب، وتبقى المشكلات مخفية حتى تظهر في عطل أكبر. ولذلك تقوم المراجعة دون لوم Blameless Postmortem على افتراض أن كل من شارك في الحادثة تصرف بنية حسنة وبما كان يعرفه وقتها، وأن السؤال الصحيح هو: ما الذي في النظام سمح لهذا الخطأ أن يحدث ويصل للإنتاج؟

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

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

الحالة الأولى: اتهام علني بعد نشر لا علاقة له (Wrongly Blamed)

لنفرض أن مهندساً في فريق خدمة الدفع في شركة تبيع عبر الإنترنت نشر صباحاً إصداراً صغيراً يغير طريقة عرض رسالة خطأ للعميل، ومر التغيير بمراجعة الكود Code Review والاختبارات كالمعتاد، وبقيت الخدمة سليمة قرابة ساعة. ثم بدأت عمليات الدفع تفشل، وكتب أحد الزملاء في قناة الفريق التي يقرؤها مديرو الأقسام: «النشر حق الصبح خرب الدفع، من راجع الكود؟». وبعد نصف ساعة ظهر أن فريق البنية التحتية Infrastructure حدث شهادة الاتصال ببوابة الدفع Payment Gateway في نفس الصباح، وأن الشهادة الجديدة لم تكن مقبولة لدى البوابة.

ماذا يحدث عادة؟ (What Usually Happens)

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

ما الذي يزيد الموقف سوءاً؟ (What Makes It Worse)

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

ما الذي ينجح؟ (What Works)

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

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

عبارات تقولها أو تكتبها (What to Say)

أثناء العطل، في القناة:

«ممكن، خلنا نتأكد. نشرت الإصدار 4.12 الساعة 9:10، والخدمة كانت سليمة حتى 10:04 حسب لوحة المراقبة Dashboard. أبدأ الآن بالتراجع عن النشر حتى نستبعده، وأحتاج من يراجع أي تغيير آخر حدث بين 10:00 و10:05.»

بعد عودة الخدمة، في القناة:

«تحديث: التراجع عن الإصدار 4.12 الساعة 10:31 لم يغير شيئاً، والخدمة عادت الساعة 10:44 بعد إعادة الشهادة السابقة لبوابة الدفع. سوف أعيد نشر 4.12 بعد موافقة قائد الحادثة Incident Commander، والتفاصيل في وثيقة المراجعة.»

في اليوم التالي، مع الزميل على انفراد:

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

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

الخط الزمني الشخصي: كيف توثق (Personal Timeline)

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

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

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

وقالب الخط الزمني الكامل في آخر المقال، ومحفوظ في ملف lab/incident-timeline.md مع المقال، وهو نفس القالب الذي يستخدمه المهندس في الحالات الثلاث.

متى تصعد، ومتى تغادر في هذه الحالة؟ (Escalate or Leave)

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

الحالة الثانية: لتغييرك دور حقيقي (Partial Fault)

لنفرض الآن أن مهندسة في فريق آخر نشرت ترحيلاً Migration لقاعدة البيانات يضيف عموداً إلى جدول الطلبات، وكان الترحيل يعمل في ثوان على بيئة الاختبار Staging، ولكن الجدول في الإنتاج فيه عشرات الملايين من الصفوف، فقفل الترحيل الجدول Table Lock عشرين دقيقة وتوقفت الطلبات. وفي اجتماع المراجعة سأل المدير أمام الجميع: «مين اللي سوى الترحيل بدون ما يختبره على بيانات حقيقية؟».

ماذا يحدث عادة؟ (What Usually Happens)

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

ما الذي ينجح؟ (What Works)

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

عبارات تقولها في اجتماع المراجعة (What to Say)

عندما يسأل المدير «مين اللي سوى الترحيل؟»:

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

وإذا استمر المدير في التركيز على الشخص:

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

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

كيف توثق، ومتى تصعد؟ (Document and Escalate)

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

حالتان موثقتان من GitLab إلى Amazon S3 (Real Postmortems)

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

الأولى في يناير 2017، عندما كان مهندس في GitLab يحاول إعادة بناء النسخ المتماثل Replication لقاعدة بيانات PostgreSQL، وأراد حذف مجلد البيانات على السيرفر الثانوي Replica، فنفذ الحذف على السيرفر الرئيسي Primary وهو يظن أنه على الثانوي. وأوقف الأمر خلال ثانية أو ثانيتين، ولكن قرابة 300 جيجابايت كانت قد حذفت، وتوقف الموقع قرابة 18 ساعة، وفقدت بيانات قرابة ست ساعات. ويلفت النظر في المراجعة التي نشرتها GitLab أنها لم تتوقف عند المهندس، وإنما شرحت لماذا لم تنجح أي طريقة من طرق النسخ الاحتياطي Backup: النسخ عبر pg_dump كانت تفشل بصمت لأن أداة الإصدار 9.2 تعمل على قاعدة إصدارها 9.6، ورسائل الفشل كانت ترفض في البريد، والـ Snapshots لم تكن مفعلة لسيرفرات قاعدة البيانات. وكتبت في تحليل السبب أنه لم يكن لهذا الإجراء مالك، ولذلك لم يكن أحد مسؤولاً عن اختباره، وجعلت تركيزها على تحسين التعافي من الكوارث Disaster Recovery وعلى أن يكون واضحاً للمهندس على أي سيرفر يعمل.

والثانية في 28 فبراير 2017، عندما توقفت خدمة Amazon S3 في منطقة شمال فيرجينيا قرابة أربع ساعات. وفي ملخص الحادثة الذي نشرته AWS أن عضواً مصرحاً له في الفريق نفذ أمراً من دليل تشغيل Runbook معتمد لإزالة عدد صغير من السيرفرات، وأدخل أحد مدخلات الأمر بشكل خاطئ فأزيل عدد أكبر بكثير، وكانت تلك السيرفرات تدعم أنظمة فرعية أساسية في الخدمة. ولم يذكر الملخص اسم الشخص، وكتب أن الأداة سمحت بإزالة سعة كبيرة بسرعة كبيرة، ولذلك عدلت AWS الأداة لتزيل السعة ببطء، ولترفض أي إزالة تنزل بنظام فرعي تحت الحد الأدنى من السعة، وبدأت مراجعة أدواتها الأخرى بحثاً عن نفس المشكلة.

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

الحالة الثالثة: عندما يصبح اللوم نمطاً (Repeated Blame)

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

ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse)

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

ما الذي ينجح؟ (What Works)

الذي ينجح ثلاث خطوات بالترتيب. الأولى أن تجمع حقائقك: لكل عطل نسب إليك افتح وثيقة المراجعة وخطك الزمني، واكتب في جدول واحد: العطل، ما قيل عنك، ما تقوله الوثيقة. والثانية أن تطلب محادثة فردية One-on-One مع القائد عن نقطة واحدة محددة، وأوضحها عادة هي العبارة في التقييم، لأن لها أثراً مكتوباً. والثالثة أن تطلب في نهاية المحادثة شيئاً محدداً يمكن التحقق منه: تعديل العبارة، أو ذكر الأعطال بأسمائها، أو إضافة ملاحظتك على التقييم.

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

وإذا رد القائد بشيء عام مثل «الكل يعرف أن خدمتك فيها مشاكل»، فلا تجادل في الانطباع، وارجع إلى المطلوب:

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

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

متى تصعد ولمن؟ (Escalation)

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

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

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

متى يكون الحل أن تغادر؟ (When to Leave)

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

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

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

إذا كنت قائد الفريق (Team Lead)

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

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

وطريقة إدارة اجتماع المراجعة نفسه، خطوة بخطوة، موضوع مقال مستقل عن المراجعة دون لوم في مسار الفرق، وسوف تجد بطاقته في آخر المقال.

قالب الخط الزمني الشخصي (Timeline Template)

هذا القالب هو الأداة العملية في هذا المقال، وهو محفوظ في ملف lab/incident-timeline.md. اكتبه في يوم العطل، قبل أن تبدأ المراجعة، ولا ترسله كاملاً لأحد، وإنما خذ منه ما يحتاجه الموقف: الخط الزمني لوثيقة المراجعة، وقسم «ما قيل عني» لمحادثة مع مديرك إذا احتجت لها.

# الخط الزمني الشخصي بعد عطل (Personal Incident Timeline)

## 1. معلومات العطل
- اسم العطل أو رقم التذكرة:
- الخدمة المتأثرة:
- بداية التأثير (بتوقيت السعودية):
- نهاية التأثير:
- من كتب هذا الخط الزمني، ومتى:

## 2. الخط الزمني
| الوقت | ماذا حدث | من أو ماذا | المصدر (رابط أو اسم ملف) |
|---|---|---|---|
| 09:10 | نشر الإصدار 4.12 | أنا، طلب الدمج 812 | سجل CI |
| 10:02 | تحديث شهادة الاتصال ببوابة الدفع | فريق البنية | تذكرة التغيير |
| 10:04 | أول تنبيه: فشل اتصال TLS | نظام التنبيهات | التنبيه 3391 |

## 3. ما فعلته أثناء العطل
- الوقت، الإجراء، النتيجة (مثال: 10:31 تراجعت عن النشر، العطل مستمر).

## 4. ما أعرفه وما لا أعرفه
- ما تثبته السجلات:
- ما زال غير معروف، وما البيانات التي تحسمه:

## 5. دوري في العطل (بصدق)
- هل ساهم تغييري؟ نعم / لا / غير معروف بعد
- إذا نعم: ما الذي لم أتوقعه، وما الذي سمح له أن يصل للإنتاج:

## 6. اقتراحات على النظام لا على الأشخاص
- تنبيه أو فحص أو صلاحية أو اختبار يمنع تكرار السبب:

## 7. ما قيل عني ومتى (إن وجد)
| التاريخ والوقت | أين | ماذا قيل بالنص | من حضر أو قرأ | الرابط |
|---|---|---|---|---|

في القالب أعلاه لاحظ التالي:

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

قائمة تحقق عندما تلام على عطل (Checklist)

ومقالات هذه المرحلة من المسار تكمل بعضها، فإذا كان اللوم جزءاً من علاقة صعبة مع زميل أو مدير فستجد تفاصيلها في المقالات التالية:

دليلمن يتحمل المسؤولية Accountability عندما يتعطل الإنتاج؟كيف تحدد ملكية الخدمات وتدير الحادثة بأدوار واضحة، ثم تكتب تقرير ما بعد الحادثة دون لوم وبإجراءات تغلق فعلاً.دليلتقييم أداء تراه ظالماً Performance Review: كيف تعترض؟ماذا تفعل في الأيام الأولى بعد تقييم لا يعكس سنتك، وكيف تعترض بالأدلة دون أن تخسر علاقتك بمديرك، ومتى يكون التقييم عادلاً.دليلتجاوز المدير والتصعيد Skip-level: متى يجوز وكيف تفعلهمتى يكون رفع الموضوع إلى مدير مديرك مشروعاً، وكيف تكتب رسالة التصعيد وتخبر مديرك قبلها حتى تحل المشكلة دون أن تخسر العلاقة.دليلمتى تلجأ إلى الموارد البشرية HR؟ حقوقك في نظام العملما تفعله الموارد البشرية وما لا تفعله، والمواد التي تحتاجها من نظام العمل السعودي، وقنوات الشكوى بالترتيب وكيف تجهز ملفك.دليلضغط المناوبة On-call والحوادث: كيف تحمي نفسك وفريقكما الحدود التي يضعها كتاب Google SRE للمناوبة المستدامة، وكيف تقلل التنبيهات وتصمم الجدول وتطلب التعويض والراحة دون صدام.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

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

سجل التحديثات

• أكتوبر 2026: كتابة المقال، والتحقق من مراجعة GitLab لحادثة يناير 2017، وملخص AWS لحادثة S3 في فبراير 2017، وفصل ثقافة المراجعة في كتاب Google SRE، ومواد نظام العمل من موقع هيئة الخبراء بتاريخ 31 أكتوبر 2026.