> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# ضغط المناوبة On-call والحوادث: كيف تحمي نفسك وفريقك
- URL: https://arabroot.io/articles/ضغط-المناوبة-on-call-والحوادث-كيف-تحمي-نفسك-وفريقك/
- Published: 2026-10-31T08:04:58.000Z
- Updated: 2026-10-31T10:31:49.000Z
- Description: ما الحدود التي يضعها كتاب Google SRE للمناوبة المستدامة، وكيف تقلل التنبيهات وتصمم الجدول وتطلب التعويض والراحة دون صدام.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, المهارات المهنية للتقنيين

إذا كنت تحمل هاتف المناوبة On-call هذا الأسبوع، فأنت تعرف الشعور: تنام والهاتف بجانب رأسك والصوت مرتفع، وتستيقظ مرتين دون سبب لتتأكد أنه لم يرن، وعندما يرن فعلاً في الثالثة فجراً تقرأ التنبيه Alert بعين واحدة وتحاول أن تتذكر أين لوحة المراقبة Dashboard، ثم تكتشف بعد عشرين دقيقة أنه تنبيه يظهر كل أسبوع ويختفي وحده. وفي التاسعة صباحاً تجلس في الاجتماع اليومي Daily Standup كأن شيئاً لم يحدث، لأن أحداً لم يقل لك إنك تستطيع أن تبدأ متأخراً، ولأنك لا تريد أن تبدو الوحيد الذي يتعب من المناوبة.

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

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

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

## لماذا تضغط المناوبة On-call على من يحملها؟

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

وكتاب Google SRE في فصل [Being On-Call](https://sre.google/sre-book/being-on-call/?ref=arabroot.io) يتحدث عن هذا الجانب صراحة، فيذكر أن هرمونات الضغط تضعف الوظائف الذهنية وتؤدي إلى قرارات أسوأ، وأن المناوب تحت الضغط يميل إلى التحيز التأكيدي Confirmation Bias، فيرى تنبيهاً يشبه تنبيهاً سابقاً فيفترض أن السبب هو نفسه دون أن يتحقق. لذلك يكتب الكتاب أن الهدف ليس أن يكون المناوب بطلاً يعمل بسرعة، وإنما أن يتصرف بطريقة منهجية مدعومة بالبيانات، وهذا لا يحدث إلا إذا كانت المناوبة مصممة بحيث لا يكون المناوب منهكاً قبل أن يبدأ.

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

## ماذا يقول كتاب Google SRE عن المناوبة المستدامة؟ Sustainable On-call

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

![أربع بطاقات: 25 بالمئة أقصى نصيب للمناوبة من وقت المهندس مع 50 بالمئة على الأقل لأعمال الهندسة، وحادثتان كحد أقصى في نوبة مدتها 12 ساعة مع نحو 6 ساعات لكل حادثة، و8 مهندسين لموقع واحد أو 6 لكل موقع، و5 دقائق للاستجابة للخدمة أمام المستخدم و30 دقيقة للأقل حساسية. وتحتها مربع يشرح أن ثلاثة مهندسين في مناوبة أسبوعية على مدار الساعة يعني أن كل واحد مناوب أسبوعاً من كل ثلاثة أي نحو 33 بالمئة من وقته وهذا فوق الحد](https://arabroot.io/content/images/2026/10/on-call-stress-01-sre-numbers-1.webp)

الأرقام من فصل Being On-Call في كتاب SRE، وفصل On-Call في كتاب SRE Workbook

- **نصيب المناوبة من الوقت:** يضع الكتاب حداً بأن يقضي مهندس SRE نصف وقته على الأقل في أعمال هندسية، ومن النصف الباقي لا يزيد وقت المناوبة على 25%. والسبب أن الفريق الذي يقضي كل وقته في إطفاء الحرائق لا يجد وقتاً لإصلاح أسبابها، فتزداد الحرائق.
- **عدد الحوادث في النوبة:** الحد الأقصى حادثتان في كل نوبة Shift مدتها 12 ساعة، لأن الكتاب يقدر أن الحادثة الواحدة تأخذ نحو 6 ساعات إذا حسبت التشخيص والإصلاح وكتابة تقرير ما بعد الحادثة Postmortem والمتابعة. ويذكر أن القيمة المتوقعة الوسيطة لعدد التنبيهات في اليوم يجب أن تكون صفراً.
- **حجم الفريق:** أقل عدد للمناوبة من موقع واحد ثمانية مهندسين، على أساس نوبات أسبوعية فيها مناوب أساسي Primary ومناوب ثان Secondary، وإذا كان الفريق موزعاً على موقعين فستة في كل موقع. ويضيف كتاب [SRE Workbook](https://sre.google/workbook/on-call/?ref=arabroot.io) أن تترك شخصاً إضافياً حتى يستطيع أحدهم أن يأخذ إجازة طويلة دون أن ينهار الجدول.
- **وقت الاستجابة:** القيم المعتادة 5 دقائق للخدمات التي يتعامل معها المستخدم مباشرة، و30 دقيقة للأنظمة الأقل حساسية للوقت، وبعض المشكلات، مثل فشل النسخ الاحتياطي Backup لخدمة لم تطلق بعد، تنتظر وقت العمل.

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

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

## إرهاق التنبيهات Alert Fatigue

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

والقاعدة في كتاب SRE وفي فصل [Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/?ref=arabroot.io) أن كل تنبيه يوقظ إنساناً يجب أن يحتاج عملاً فورياً من إنسان، وأن الهدف تنبيه واحد لكل حادثة. وإذا لم يكن التنبيه كذلك، فإما أن يصبح تذكرة Ticket يراها الفريق في وقت العمل، أو أن يؤتمت حله، أو أن يحذف. والشكل التالي يلخص الأسئلة التي تحدد مكان كل تنبيه:

![شجرة قرار تبدأ من تنبيه جديد. السؤال الأول هل يتضرر المستخدمون الآن أو خلال ساعات، فإن كان لا يصبح تذكرة لوقت العمل أو يحذف إن لم يقرأه أحد. وإن كان نعم فالسؤال الثاني هل يحتاج قراراً أو عملاً من إنسان، فإن كان لا يؤتمت بإعادة تشغيل أو توسيع تلقائي. وإن كان نعم فالسؤال الثالث هل له كتيب تشغيل واضح، فإن كان لا يكتب الكتيب قبل تفعيل التنبيه ويجرب أسبوعاً دون إيقاظ أحد، وإن كان نعم يصبح تنبيهاً يوقظ المناوب ويسجل ويراجع كل أسبوع. وبجانبها أهداف كتاب SRE](https://arabroot.io/content/images/2026/10/on-call-stress-02-page-tree.webp)

أغلب تنبيهات الليل تنتهي عند السؤال الأول أو الثاني إذا سألتهما بصدق

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

ولمن يريد التفاصيل التقنية لبناء التنبيهات من البداية، فمقال [مفاهيم المراقبة Observability](https://arabroot.io/articles/%D9%85%D9%81%D8%A7%D9%87%D9%8A%D9%85-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-observability-%D9%85%D9%86-%D8%A7%D9%84%D8%A7%D8%B4%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%AA%D9%86%D8%A8%D9%8A%D9%87/) يشرح الطريق من الإشارة إلى التنبيه، أما هنا فالمهم أن تعرف أن تقليل التنبيهات هو أقوى ما تستطيع فعله لتخفيف ضغط المناوبة، وأقوى من أي تعويض.

## ثلاث حالات توضيحية Case Studies

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

### الحالة الأولى: فريق صغير ومناوبة على مدار الساعة Small Team 24/7

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

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

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

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

**عبارات تقولها أو تكتبها:**

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

> «نحن ثلاثة، وهذا يعني أن كل واحد منا مناوب ثلث وقته. لا أطلب أن نلغي المناوبة، وإنما أن نقلل ما يوقظنا ونضيف مناوباً ثانياً من فريق المنصة Platform Team إذا أمكن.»

> «من عمل بعد منتصف الليل في حادثة، هل نتفق أنه يبدأ يومه التالي بعد الظهر؟ وأريد أن تكون هذه القاعدة مكتوبة حتى لا يحرج أحد في طلبها.»

والأرقام في هذه العبارات توضيحية، والمهم أن تأتي أرقامك أنت من أداة التنبيهات وليس من الذاكرة.

**كيف توثق:** سجل بسيط لكل نوبة يكتبه المناوب في آخرها كرسالة تسليم Handoff، كما يوصي كتاب SRE Workbook: ما التنبيهات التي وصلت، وماذا فعل في كل منها، وكم ساعة عمل خارج الدوام، وما الذي يجب أن يعرفه المناوب التالي. وهذا السجل يفيد مرتين: يعطي المناوب التالي صورة واضحة، ويعطي الفريق بعد شهر أرقاماً حقيقية لأي نقاش.

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

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

### الحالة الثانية: المهندس الذي لا يستغني عنه أحد Hero On-call

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

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

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

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

**عبارات يقولها هو:**

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

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

**وعبارة يقولها المدير:**

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

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

**متى تصعد ولمن:** إذا طلب نقل المعرفة ولم يخصص له وقت، فهذا خطر استمرارية أعمال Business Continuity يستحق أن يصل إلى مدير التقنية، لأن خدمة مالية تعتمد على شخص واحد خطر على الشركة كلها.

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

### الحالة الثالثة: مهندس جديد يخاف من أول مناوبة First On-call Shift

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

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

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

**ما الذي ينجح:** أن يدخل المناوبة بالتدريج، كما يصف كتاب SRE Workbook في مثال فريق جديد في Google: شهران تقريباً من المراقبة Shadowing مع مناوب أساسي، يرى فيها كيف يتعامل مع التنبيهات دون أن يتحمل المسؤولية، ثم يصبح مناوباً أساسياً مع مناوب ثان ذي خبرة يرد عليه في أي وقت. وقبل ذلك جلسات تدريب على حوادث سابقة، وتسميها Google عجلة سوء الحظ Wheel of Misfortune، حيث يعرض أحد أعضاء الفريق حادثة قديمة ويحاول المهندس الجديد تشخيصها خطوة بخطوة. والمهم أن يعرف المهندس الجديد أن الاتصال بالمناوب الثاني جزء من الإجراء وليس فشلاً.

**عبارات يقولها المهندس:**

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

**وعبارات يقولها قائد الفريق:**

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

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

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

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

## تصميم جدول المناوبة Rotation Design

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

![مقارنة بين جدولين. على اليمين قبل: ثلاثة مهندسين كل واحد أسبوع كامل على مدار الساعة دون مناوب ثان، ومن يوقظ في الثالثة يعمل في التاسعة كالمعتاد والتعويض غير مكتوب، والنتيجة إرهاق متراكم وتنبيهات تتجاهل. وعلى اليسار بعد: النهار مناوب أساسي، والليل تنبيهات حرجة فقط، ومناوب ثان يرد إذا لم يرد الأساسي خلال 15 دقيقة، والتنبيهات غير الحرجة تنتظر الصباح كتذاكر، ومن عمل ليلاً يبدأ يومه متأخراً، والتعويض مكتوب، وتبديل النوبات مسموح بسياسة واضحة، ومع نمو الفريق مناوبة تتبع الشمس](https://arabroot.io/content/images/2026/10/on-call-stress-03-rotations.webp)

نفس الفريق تقريباً، والفرق في طول النوبة وما يوقظ الناس في الليل

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

وعندما يكبر الفريق ويصبح موزعاً على مناطق زمنية مختلفة، يمكن الانتقال إلى المناوبة التي تتبع الشمس Follow the Sun، حيث يغطي كل موقع ساعات نهاره فقط، فلا يستيقظ أحد في الليل. ويذكر كتاب SRE أن لهذا الترتيب تكلفة في التنسيق بين المواقع، ولكنه أفضل للناس عندما يكون ممكناً.

## مسار التصعيد أثناء الحادثة Escalation Path

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

![أربع مراحل من اليمين: المناوب الأساسي يقيم ويبدأ التخفيف، وبعد 15 دقيقة المناوب الثاني إذا لم يرد الأساسي أو طلب المساعدة، وبعد 30 دقيقة قائد الحادثة عند وجود عميل متضرر أو أكثر من فريق وهو ينسق ويكتب التحديثات، ثم صاحب الخدمة الخبير يستدعى بالاسم عند الحاجة وليس كل ليلة تلقائياً. وفي الأسفل عبارة طلب المساعدة جزء من الإجراء وليس اعترافاً بالفشل إذا لم تتقدم خلال 30 دقيقة صعد](https://arabroot.io/content/images/2026/10/on-call-stress-04-escalation.webp)

التصعيد بوقت محدد يرفع عن المناوب قرار «هل أزعج أحداً؟»

والأوقات في الشكل مثال، وكل فريق يحددها حسب أهمية خدمته، ولكن المبدأ أن يكون التصعيد قاعدة مكتوبة بوقت، وليس قراراً يعتمد على شجاعة المناوب. فإذا كانت القاعدة «إذا لم تتقدم خلال 30 دقيقة اتصل بالمناوب الثاني»، فالمهندس الجديد يتصل دون أن يشعر أنه أزعج أحداً، والمهندس المتعب لا يبقى ساعتين يحاول وحده بسبب كبريائه. وقائد الحادثة Incident Commander دور تنسيقي، يتولى التواصل مع العملاء والإدارة وكتابة التحديثات، حتى يتفرغ من يصلح المشكلة للإصلاح، وتفاصيل هذا الدور في مقال [خطة الاستجابة للحوادث Incident Response](https://arabroot.io/articles/%D8%AE%D8%B7%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%84%D9%84%D8%AD%D9%88%D8%A7%D8%AF%D8%AB-incident-response-%D9%88%D9%83%D8%AA%D9%8A%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%B4%D8%BA%D9%8A%D9%84/).

## التعويض والراحة في نظام العمل السعودي Compensation and Rest

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

وفي المملكة، لا يذكر [نظام العمل](https://laws.boe.gov.sa/BoeLaws/Laws/LawDetails/08381293-6388-48e2-8ad2-a9a700f2aa94/1?ref=arabroot.io) المناوبة بهذا الاسم، ولكن فيه مواد عن ساعات العمل والراحة والعمل الإضافي Overtime تهم كل من يحمل هاتف المناوبة، ومن المفيد أن تعرفها قبل أن تتفاوض:

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

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

## كيف تطلب التغيير من مديرك؟ Asking for Change

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

![مقارنة بين محادثتين. على اليمين قبل: المهندس يقول المناوبة تقتلنا ولم أنم جيداً منذ شهر ولن أستمر هكذا، والمدير يرد كل الشركات فيها مناوبة وهي جزء من الوظيفة، مع ملاحظة أن المدير يسمع تهديداً فيدافع عن المبدأ. وعلى اليسار بعد: المهندس يقول في آخر أربعة أسابيع وصلنا 61 تنبيهاً ليلياً منها 9 فقط احتاجت عملاً وأقترح أسبوعين لتنظيف التنبيهات ومناوباً ثانياً وكتابة طريقة التعويض، والمدير يرد موافق على التنظيف هذا السبرنت والتعويض أرفعه للموارد البشرية](https://arabroot.io/content/images/2026/10/on-call-stress-05-ask-manager-1.webp)

الأرقام في المثال توضيحية، والذي يصنع الفرق هو شكل الطلب

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

وبعض العبارات المفيدة في هذا الحديث:

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

## بعد الليلة الصعبة Recovery After an Incident

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

والثالث هو مراجعة ما بعد الحادثة، ويجب أن تكون دون لوم Blameless، فالهدف فهم لماذا سمح النظام بالخطأ وليس من ارتكبه. وكتاب SRE في فصل [Postmortem Culture](https://sre.google/sre-book/postmortem-culture/?ref=arabroot.io) يشرح هذا المبدأ بالتفصيل، وله مقال مستقل في هذه السلسلة عن إدارة اجتماع ما بعد الحادثة دون لوم، ومقال آخر في قسم المواقف الصعبة عما تفعله إذا لامك الفريق على عطل لم تسببه. والمهم هنا أن المناوب الذي يخاف من اللوم بعد كل حادثة يحمل ضغطاً مضاعفاً في كل نوبة، فهو لا يفكر فقط في إصلاح المشكلة، وإنما في كيف سيبدو في الاجتماع القادم.

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

## مراجعة صحة المناوبة On-call Health Review

الأداة العملية في هذا المقال مراجعة شهرية قصيرة لصحة المناوبة، يجلس فيها الفريق نصف ساعة، ويملأ الأرقام من أداة التنبيهات وجدول المناوبة، ثم يراجع التنبيهات والناس، ويخرج بقرارات لها مسؤول وموعد. والنسخة الكاملة في الملف `lab/oncall-health-review.md`:

```markdown
# مراجعة صحة المناوبة الشهرية On-call Health Review

الفريق: ...............   الشهر: ..../....   من حضر: ...............

## 1. الأرقام Numbers (من أداة التنبيهات وجدول المناوبة)
| المقياس | هذا الشهر | الشهر الماضي | الحد المتفق عليه |
|---|---|---|---|
| عدد التنبيهات التي أيقظت أحداً Pages | | | |
| منها خارج وقت العمل | | | |
| منها احتاج عملاً فعلياً | | | |
| أكثر نوبة فيها حوادث (عدد الحوادث) | | | 2 لكل 12 ساعة |
| نسبة وقت المناوبة لكل مهندس | | | 25% أو أقل |
| عدد المهندسين في الجدول | | | |
| مرات التصعيد للمناوب الثاني | | | |
| ساعات العمل خارج الدوام بسبب المناوبة | | | |

## 2. التنبيهات Alerts
- [ ] راجعنا أكثر خمسة تنبيهات تكراراً، ولكل واحد قرار: يبقى / يعدل / يصبح تذكرة / يحذف / يؤتمت
- [ ] كل تنبيه يوقظ المناوب له كتيب تشغيل Runbook محدث
- [ ] لا يوجد تنبيه أغلق بسبب «غير معروف» دون تذكرة لمتابعته
- [ ] التنبيهات الجديدة جربت أسبوعاً دون أن توقظ أحداً قبل تفعيلها

## 3. الناس People
- [ ] سألنا كل من كان مناوباً: كيف كان النوم؟ هل شعرت أنك وحدك؟ (إجابة مختصرة، دون ضغط)
- [ ] من عمل ليلاً أخذ وقت الراحة أو التعويض المتفق عليه
- [ ] لا يوجد شخص يستدعى خارج نوبته بشكل متكرر لأنه الوحيد الذي يعرف خدمة معينة
- [ ] المهندس الجديد مر بالمراقبة Shadowing قبل أن يكون مناوباً أساسياً
- [ ] تبديل النوبات تم حسب السياسة، ولم يرفض طلب لظرف عائلي أو صحي

## 4. القرارات Decisions
| المشكلة | الإجراء | المسؤول | الموعد |
|---|---|---|---|
| | | | |
| | | | |

## 5. متى نصعد للإدارة Escalate
- إذا تجاوزت الحوادث الحد في أكثر من ثلث النوبات خلال الشهر
- إذا كانت نسبة المناوبة لأي مهندس فوق 25% لأن الفريق صغير
- إذا لم يخصص وقت لإصلاح أسباب التنبيهات رغم طلبه مرتين
- إذا لم تكن طريقة التعويض مكتوبة ومعروفة لكل من في الجدول
```

وفي هذا النموذج لاحظ التالي:

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

## أخطاء شائعة Common Mistakes

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

## قائمة تحقق Checklist

- هل تعرف نسبة وقت المناوبة لكل مهندس في فريقك، وهل هي قريبة من 25% أو أقل؟
- هل كل تنبيه يوقظ أحداً يحتاج عملاً فورياً من إنسان، وله كتيب تشغيل؟
- هل يوجد مناوب ثان، ومسار تصعيد مكتوب بأوقات محددة؟
- هل النوبات أقصر من 24 ساعة متصلة، والتنبيهات غير الحرجة تنتظر الصباح؟
- هل الراحة بعد الحادثة الليلية قاعدة مكتوبة؟
- هل طريقة التعويض مكتوبة في سياسة الشركة أو العقد، ومعروفة لكل من في الجدول؟
- هل يوجد شخص يستدعى خارج نوبته باستمرار، وهل لديكم خطة لنقل معرفته؟
- هل يمر المهندس الجديد بالمراقبة والتدريب قبل أن يكون أساسياً؟
- هل يراجع الفريق صحة المناوبة كل شهر بالأرقام؟

ولمن يريد الصورة الأوسع لدور SRE وعلاقته بفرق التطوير، فمقال [الفرق بين DevOps وSRE وPlatform Engineering](https://arabroot.io/articles/%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86-devops-%D9%88-sre-%D9%88-platform-engineering/) يشرحها.

[![](https://arabroot.io/content/images/2026/10/burnout-developers-cover-cover.webp)دليلالاحتراق الوظيفي Burnout عند المبرمجين: العلامات والأسبابما تقوله منظمة الصحة العالمية عن الاحتراق الوظيفي، ومن أين يأتي في الفرق التقنية، وما يفعله المهندس لنفسه وقائد الفريق لفريقه.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D8%B1%D8%A7%D9%82-%D8%A7%D9%84%D9%88%D8%B8%D9%8A%D9%81%D9%8A-burnout-%D8%B9%D9%86%D8%AF-%D8%A7%D9%84%D9%85%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/blamed-for-incident-cover-cover.webp)دليلاللوم بعد العطل Blame: حين يلومك الفريق على ما لم تسببهماذا تقول في الساعة الأولى بعد عطل نسب إليك، وكيف توثق الحقائق بخط زمني، ومتى تصعد اللوم المتكرر ومتى تغادر.](https://arabroot.io/articles/%D8%AD%D9%8A%D9%86-%D9%8A%D9%84%D9%88%D9%85%D9%83-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%B9%D9%84%D9%89-%D8%B9%D8%B7%D9%84-%D9%84%D9%85-%D8%AA%D8%B3%D8%A8%D8%A8%D9%87/)[![](https://arabroot.io/content/images/2026/10/saying-no-cover-cover.webp)دليلكيف تقول لا Saying No للمهام فوق طاقتك والمواعيد المستحيلةكيف ترد على عمل لا يتسع له وقتك بخيارات واضحة يختار منها من يملك القرار، ومتى يكون الجواب الصحيح نعم بشروط.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%88%D9%84-%D9%84%D8%A7-%D8%A8%D8%A7%D8%AD%D8%AA%D8%B1%D8%A7%D9%81%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D9%87%D8%A7%D9%85-%D9%88%D8%A7%D9%84%D9%85%D9%88%D8%A7%D8%B9%D9%8A%D8%AF-%D8%A7%D9%84%D9%85%D8%B3%D8%AA%D8%AD%D9%8A%D9%84%D8%A9/)[![](https://arabroot.io/content/images/2026/10/impostor-syndrome-cover-cover.webp)دليلمتلازمة المحتال Impostor Syndrome: أنواعها عند المهندسينلماذا يشعر مهندسون ناجحون بأنهم خدعوا من حولهم، وما تقوله الأبحاث عن هذا الشعور، وكيف تفرق بينه وبين فجوة حقيقية في المهارة.](https://arabroot.io/articles/%D9%85%D8%AA%D9%84%D8%A7%D8%B2%D9%85%D8%A9-%D8%A7%D9%84%D9%85%D8%AD%D8%AA%D8%A7%D9%84-impostor-syndrome-%D8%B9%D9%86%D8%AF-%D8%A7%D9%84%D9%85%D9%87%D9%86%D8%AF%D8%B3%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/deep-work-focus-cover-cover.webp)دليلالتركيز العميق Deep Work: لماذا يحتاج المبرمج ساعات هادئة؟ماذا تقول الدراسات عن تكلفة المقاطعة على المبرمج، وكيف يحمي الفريق وقت التركيز دون أن يتأخر الرد على أحد.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B1%D9%83%D9%8A%D8%B2-%D8%A7%D9%84%D8%B9%D9%85%D9%8A%D9%82-deep-work-%D9%84%D9%85%D8%A7%D8%B0%D8%A7-%D9%8A%D8%AD%D8%AA%D8%A7%D8%AC-%D8%A7%D9%84%D9%85%D8%A8%D8%B1%D9%85%D8%AC-%D8%B3%D8%A7%D8%B9%D8%A7%D8%AA-%D9%87%D8%A7%D8%AF%D8%A6%D8%A9/)

## الخلاصة

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

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

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

- أكتوبر 2026: كتابة المقال، ومراجعة فصول المناوبة والمراقبة وثقافة ما بعد الحادثة في كتابي Google SRE وSRE Workbook، ومواد ساعات العمل والراحة والعمل الإضافي في نظام العمل من موقع هيئة الخبراء بتاريخ 31 أكتوبر 2026.