> ## 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. # استكشاف الأخطاء وتحليل الأداء للمبتدئين: من العرض إلى السبب - URL: https://arabroot.io/articles/استكشاف-الاخطاء-وتحليل-الاداء-للمبتدئين/ - Published: 2026-10-05T18:00:00.000Z - Updated: 2026-10-09T09:42:43.000Z - Description: عندما يبطئ الموقع أو يعطي 502، هذه طريقة منظمة توصلك من العرض إلى السبب قبل أن تخمن أو تشتري سيرفراً أكبر. - Author: فريق عرب رووت - Tags: الأدلة التقنية, DevOps والتشغيل, DevOps وCI/CD, لينكس والسيرفرات, الاستضافة الذاتية يصلك في صباح يوم عمل عادي سطر واحد من زميل في فريق المبيعات: «الموقع بطيء جداً»، وبعد دقائق تصل رسالة ثانية من عميل يقول إن صفحة الدفع تعطيه خطأ، وفي نفس الوقت يقترح أحد الزملاء في مجموعة الفريق أن نرفع السيرفر إلى حجم أكبر، ويقترح آخر أن نعيد تشغيل كل شيء، ويقترح ثالث أن نضيف Redis. وكل هذه الاقتراحات قد تكون صحيحة وقد تكون خاطئة تماماً، والمشكلة أن أحداً لم يقس شيئاً بعد، ولا يعرف أحد ما الذي تغير منذ أمس. وقد ذكرنا في قسم [قس قبل أن تغير](https://arabroot.io/articles/%D9%85%D8%AF%D8%AE%D9%84-%D8%A7%D9%84%D9%89-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D9%85%D9%86-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-%D9%88%D8%A7%D8%AD%D8%AF-%D8%A7%D9%84%D9%89-%D9%85%D9%84%D8%A7%D9%8A%D9%8A%D9%86/#measure-first) من مقال تصميم الأنظمة أن أكثر خطأ يتكرر عندما يبطئ الموقع هو أن يقرر الفريق الحل قبل أن يعرف السبب، وهذا الدليل هو الجواب العملي على سؤال «كيف أعرف السبب؟». واستكشاف الأخطاء Troubleshooting وتحليل الأداء Performance Analysis ليسا موهبة يولد بها بعض المهندسين، وإنما طريقة منظمة تتعلمها: تحدد العرض بدقة، وتسأل ما الذي تغير، وتضع فرضية واحدة، وتقيسها بقياس واحد، وتغير شيئاً واحداً، وتكتب كل ذلك. وهذا الدليل هو المقال الرئيسي في هذا الموضوع، فهو يملك الطريقة ودليل الحالات الشائعة، ومعه مقالان يتعمقان في التفاصيل: - استكشاف الأخطاء وتحليل الأداء للمبتدئين: الطريقة والحالات الشائعة (هذا المقال). - [تحليل أداء سيرفر Linux في 60 ثانية](https://arabroot.io/articles/%D8%AA%D8%AD%D9%84%D9%8A%D9%84-%D8%A7%D8%AF%D8%A7%D8%A1-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-linux-%D9%81%D9%8A-60-%D8%AB%D8%A7%D9%86%D9%8A%D8%A9/): أدوات المعالج والذاكرة والقرص والشبكة واحدة واحدة، مثل `vmstat` و`iostat` و`pidstat` و`ss`. - [تتبع الطلب البطيء من المتصفح إلى قاعدة البيانات](https://arabroot.io/articles/%D8%AA%D8%AA%D8%A8%D8%B9-%D8%A7%D9%84%D8%B7%D9%84%D8%A8-%D8%A7%D9%84%D8%A8%D8%B7%D9%8A%D8%A1-%D9%85%D9%86-%D8%A7%D9%84%D9%85%D8%AA%D8%B5%D9%81%D8%AD-%D8%A7%D9%84%D9%89-%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA/): توقيت الطلب الواحد بـ `curl` وأدوات المتصفح وسجلات Nginx، وأخطاء 502 و504، والتحليل Profiling. وسوف نناقش في هذا المقال ما يلي: - لماذا يفشل التخمين، ولماذا لا يحل السيرفر الأكبر مشكلة لا تعرف سببها. - طريقة التحقيق خطوة بخطوة: وصف العرض، وسؤال «ما الذي تغير؟»، والخط الزمني، والفرضية والقياس، والملاحظات، ومتى تتراجع أولاً ثم تبحث عن السبب. - ثلاث قوائم تحقق من مصادرها الأصلية: طريقة USE وطريقة RED والإشارات الذهبية الأربع، ولماذا تقيس النسب المئوية Percentiles وليس المتوسط. - خريطة الطبقات التي يمر بها الطلب، وأين يعيش كل عرض، وأول أداة تفتحها له. - تجربة عملية كاملة: بطء بعد نشر إصدار جديد، نحققه بالطريقة نفسها من العرض إلى السبب ثم التراجع. - دليل الحالات الشائعة: البطء على الجميع أو على بعضهم، و502 و504، والمعالج والذاكرة والقرص، والاتصالات بقاعدة البيانات، وDNS والشهادات، والبطء بعد النشر، والأخطاء المتقطعة، والمهام المجدولة. - حوادث حقيقية نشرتها شركات معروفة عن نفسها، ونموذج ملاحظات للحادثة تنسخه، والأخطاء الشائعة. ## الخلاصة في دقيقة واحدة إذا لم يكن لديك وقت إلا لهذا القسم، فهذه القواعد التي سوف نشرحها في بقية الدليل: - اكتب العرض في جملة دقيقة قبل أي شيء: من يتأثر، وما الذي يحدث بالضبط، ومنذ متى، وكيف قسته. - اسأل «ما الذي تغير؟» قبل أن تسأل «ما الخطأ؟»، والسبب أن أغلب الأعطال تأتي بعد تغيير: نشر إصدار، أو تعديل إعداد، أو تحديث حزمة، أو زيادة في الزيارات، أو شهادة انتهت. - إذا كان العملاء متأثرين الآن وهناك تغيير حديث، فتراجع عنه أولاً ثم ابحث عن السبب بهدوء، فإيقاف الضرر Mitigation يسبق معرفة السبب الجذري Root Cause. - فرضية واحدة، ثم قياس واحد يثبتها أو ينفيها، ثم تغيير واحد، ثم قياس جديد، ولا تغير ثلاثة أشياء معاً لأنك لن تعرف أيها أصلح المشكلة. - استخدم قائمة USE لكل مورد في السيرفر، وقائمة RED لكل خدمة، وانظر إلى p95 وp99 وليس إلى المتوسط وحده. - اتبع الطلب طبقة طبقة من المتصفح إلى القرص، وابدأ بالطبقة التي تقول الأرقام إنها تأخذ الوقت، وليس بالطبقة التي تعرفها أكثر. - اكتب ملاحظاتك بالوقت أثناء التحقيق، فهي التي تمنعك من تكرار نفس التجربة، وهي التي يبنى عليها تقرير ما بعد الحادثة. ## لماذا يفشل التخمين؟ لنأخذ المثال الأشهر: صفحة الطلبات في متجرك صارت تأخذ ثلاث ثوان بعد أن كانت تأخذ نصف ثانية. والحل الذي يخطر للجميع أولاً هو أن نرفع السيرفر من 4 أنوية إلى 8 أنوية، لأن السيرفر «يبدو مضغوطاً». وقد ينجح هذا الحل يوماً أو يومين، ثم يعود البطء كما كان، والسبب أن المشكلة الحقيقية استعلام بلا فهرس Index يقرأ الجدول كله في كل طلب، والجدول يكبر كل يوم، فكلما زادت الطلبات زادت القراءة الكاملة، ولا يوجد سيرفر كبير بما يكفي لعمل يتضاعف مع كل صف جديد. والفهرس الصحيح كان سيجعل نفس الاستعلام يأخذ جزءاً من المللي ثانية على السيرفر الصغير نفسه، كما سوف نرى بالأرقام في التجربة العملية بعد قليل. والحل الثاني الذي يخطر للبعض هو إعادة التشغيل، وهي تخفي العرض فعلاً لبعض الوقت، لأنها تفرغ الذاكرة وتغلق الاتصالات المعلقة، ولكنها تمسح معها الدليل الذي كنت تحتاجه لتعرف السبب: العمليات التي كانت تستهلك المعالج، والاتصالات المفتوحة، وحالة الذاكرة. لذلك إذا اضطررت لإعادة التشغيل لتعيد الخدمة للعملاء، فخذ قبلها دقيقة واحدة تحفظ فيها ما تستطيع، مثل مخرج `top` و`docker stats` وآخر سطور السجلات. والطريقة الصحيحة أن تعامل المشكلة كما يعامل الطبيب المريض: لا يصف الدواء قبل أن يسمع الأعراض ويقيس الحرارة ويسأل ما الذي تغير في الأيام الأخيرة. وهذا بالضبط ما يسميه فصل [Effective Troubleshooting](https://sre.google/sre-book/effective-troubleshooting/?ref=arabroot.io) في كتاب Google عن هندسة موثوقية المواقع Site Reliability Engineering بالطريقة الافتراضية الاستنتاجية Hypothetico-Deductive Method: تجمع ملاحظات عن النظام، وتضع فرضية عن السبب، ثم تختبرها، وتكرر حتى تصل. 📌 في 28 أكتوبر 2021 توقفت منصة الألعاب Roblox [73 ساعة](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021?ref=arabroot.io)، وكان السبب في نظام Consul الذي تعتمد عليه مئات الخدمات الداخلية. ويشرح تقرير الشركة أن الفريق جرب عدة فرضيات قبل أن يصل إلى السبب، منها أن العتاد معطل ومنها أن الحمل زاد، فاستبدل كل سيرفرات Consul بأجهزة أقوى فيها 128 نواة، أي ضعف الأنوية، وبقيت الكتابة بطيئة كما هي. والسبب الحقيقي كان ميزة جديدة في Consul اسمها Streaming فعلها الفريق قبل الحادثة بيوم واحد، مع مشكلة أداء في مكتبة التخزين BoltDB، وزاد الأمر صعوبة أن أنظمة المراقبة نفسها كانت تعتمد على Consul، فغابت البيانات عندما احتاجوها. والدرس أن السيرفر الأكبر لا يحل مشكلة لا تعرف سببها، وأن سؤال «ما الذي تغير أمس؟» يجب أن يكون من أول الأسئلة، وأن المراقبة يجب ألا تعتمد على النظام الذي تراقبه. ## طريقة التحقيق خطوة بخطوة الطريقة التي نستخدمها في كل حالة في هذا الدليل حلقة من ست خطوات، تعيدها حتى تصل إلى السبب، وفي وسطها ملف ملاحظات تكتب فيه كل خطوة بوقتها، والصورة التالية تبين هذه الحلقة: ![حلقة من ست خطوات مرقمة حول دفتر ملاحظات في الوسط: 1 العرض Symptom بوصف دقيق لمن يتأثر وماذا يحدث ومنذ متى وكيف قيس، 2 ما الذي تغير What changed من نشر وإعداد وزيارات وشهادات وخدمات خارجية، 3 الفرضية Hypothesis، 4 قياس واحد One measurement يثبتها أو ينفيها، 5 تغيير واحد One change، 6 التحقق Verify بنفس القياس الأول، ثم سهم يعود إلى الخطوة 3 إذا لم تحل المشكلة، وفي الوسط ملف incident notes فيه أسطر بالوقت](https://arabroot.io/content/images/2026/10/troubleshooting-guide-01-investigation-loop.webp) فرضية واحدة وقياس واحد وتغيير واحد في كل دورة، وكل خطوة تكتب بوقتها ### الخطوة الأولى: صف العرض بدقة جملة «الموقع بطيء» لا تكفي لتبدأ، لأنها قد تعني صفحة واحدة بطيئة لعميل واحد على شبكة جواله، وقد تعني أن كل الصفحات تعطي 502 لكل العملاء. لذلك حول البلاغ إلى وصف دقيق يجيب عن أربعة أسئلة، وهي قريبة مما يطلبه فصل Google في تقرير المشكلة Problem Report، أي السلوك المتوقع والسلوك الفعلي وطريقة إعادة المشكلة: - **من يتأثر؟** كل المستخدمين، أم مستخدمو دولة معينة، أم من يستخدم تطبيق الجوال فقط، أم المستخدمون المسجلون دون الزوار؟ - **ماذا يحدث بالضبط؟** بطء أم خطأ؟ وإذا كان خطأ فما رمزه بالضبط، 500 أم 502 أم 504، أم رسالة شهادة في المتصفح؟ وأي صفحة أو أي نقطة API؟ - **منذ متى؟** بدأ فجأة في ساعة محددة، أم يزيد تدريجياً منذ أسابيع، أم يتكرر في نفس الساعة كل يوم؟ - **كيف قسته؟** من لوحة المراقبة، أم من سجلات ال Reverse Proxy، أم من متصفح شخص واحد؟ وما الرقم قبل المشكلة وما الرقم الآن؟ والفرق كبير بين البلاغين التاليين: «الموقع بطيء»، و«منذ الساعة 10:40 صار زمن p95 لصفحة `/orders` حوالي 900 مللي ثانية بعد أن كان 60، لكل المستخدمين، والصفحة الرئيسية طبيعية، بحسب سجل Nginx». فالبلاغ الثاني يخبرك أين تبحث، ويعطيك رقماً تقارن به بعد كل تغيير لتعرف هل نجح. ### الخطوة الثانية: ما الذي تغير؟ يقول فصل المقدمة في [كتاب Google SRE](https://sre.google/sre-book/introduction/?ref=arabroot.io) إن قرابة 70% من الأعطال التي رآها الفريق سببها تغيير في نظام يعمل، لذلك فأسرع طريق إلى السبب في الغالب أن تسأل ما الذي تغير قريباً من وقت بداية العرض، وابحث في هذه القائمة: - **النشر Deployment:** إصدار جديد من التطبيق، أو Docker Image جديدة، أو ترحيل Migration في قاعدة البيانات. - **الإعداد Configuration:** تعديل في Nginx أو في متغيرات البيئة أو في حدود الذاكرة، أو قاعدة جديدة في جدار الحماية Firewall. - **النظام والحزم:** تحديث تلقائي لحزمة، أو إعادة تشغيل السيرفر، أو إصدار جديد من Docker. - **الزيارات Traffic:** حملة تسويقية، أو بداية الدوام بعد إجازة، أو زاحف Crawler جديد، أو هجوم. - **الوقت:** شهادة انتهت، أو نطاق انتهى تسجيله، أو مهمة مجدولة Cron Job تعمل في هذه الساعة، أو جدول وصل حجماً معيناً. - **الخدمات الخارجية Dependencies:** مزود الدفع، أو خدمة البريد، أو مزود DNS، أو ال CDN، أو مزود السيرفر نفسه. والأوامر التالية تجيب عن جزء كبير من هذا السؤال على سيرفر Linux يعمل عليه Docker: ```bash # what restarted or was redeployed recently? (look at STATUS and CREATED) docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.CreatedAt}}' # when did the server itself start? uptime -s # packages installed or upgraded recently (Ubuntu / Debian) tail -n 30 /var/log/apt/history.log # warnings and errors from the system in the last two hours journalctl --since "2 hours ago" -p warning --no-pager | tail -n 50 # what did the team change in the code and the configuration? git log --since="2 days ago" --oneline ``` في الأوامر أعلاه لاحظ التالي: - عمود `Status` في `docker ps` يقول منذ متى يعمل كل Container، فإذا وجدت Container عمره 20 دقيقة والمشكلة بدأت قبل 20 دقيقة فهذا أول خيط. - السجل `/var/log/apt/history.log` يكتب فيه apt كل عملية تثبيت وتحديث بتاريخها، ومنها التحديثات التلقائية Unattended Upgrades. - آخر أمر يفترض أن الإعداد نفسه في Git، وإذا لم يكن كذلك فهذه أول حادثة تقنعك بأن تضعه فيه. ### الخطوة الثالثة: ارسم خطاً زمنياً ضع في ملف الملاحظات خطاً زمنياً بسيطاً من سطر لكل حدث: متى بدأ العرض بحسب المراقبة، ومتى وصل أول بلاغ، ومتى نشر آخر إصدار، ومتى عمل آخر Cron Job، ومتى بدأت أنت التحقيق. والخط الزمني يكشف علاقات لا تراها وأنت تنظر إلى لوحة واحدة، مثل أن البطء بدأ بعد النشر بدقيقتين، أو أنه يبدأ كل ليلة في الثانية بعد منتصف الليل. ولاحظ أن كل الأوقات يجب أن تكون بمنطقة زمنية واحدة، والأفضل UTC، والسبب أن السجلات من أنظمة مختلفة قد تكتب بمناطق زمنية مختلفة، وقد شرحنا ذلك في مقال [التاريخ والوقت](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%A7%D8%B1%D9%8A%D8%AE-%D9%88%D8%A7%D9%84%D9%88%D9%82%D8%AA-utc-%D9%88%D8%A7%D9%84%D9%85%D9%86%D8%A7%D8%B7%D9%82-%D8%A7%D9%84%D8%B2%D9%85%D9%86%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%AA%D9%82%D9%88%D9%8A%D9%85-%D8%A7%D9%84%D9%87%D8%AC%D8%B1%D9%8A/). ### الخطوة الرابعة: فرضية واحدة، وقياس واحد، وتغيير واحد بعد أن عرفت العرض وما تغير، ضع فرضية محددة يمكن اختبارها، مثل «الاستعلام الجديد في صفحة الطلبات لا يستخدم الفهرس»، وليس «قاعدة البيانات فيها مشكلة». ثم اختر قياساً واحداً يثبتها أو ينفيها، مثل ترتيب الاستعلامات بالوقت في `pg_stat_statements`، وبعده نفذ تغييراً واحداً فقط، ثم أعد نفس القياس الذي بدأت به في الخطوة الأولى. وقد يتساءل البعض: لماذا لا أغير ثلاثة أشياء معاً لأوفر الوقت والعملاء ينتظرون؟ والإجابة أنك إذا غيرت حجم الذاكرة وإعداد ال Pool وأعدت تشغيل قاعدة البيانات في نفس الوقت ثم تحسن الموقع، فلن تعرف أي التغييرات أصلحه، وقد يكون أحدها أضر بشيء آخر سوف يظهر غداً، وستبقى بقية التغييرات في الإنتاج Production دون سبب يعرفه أحد. والاستثناء الوحيد هو التراجع عن تغيير معروف لإيقاف الضرر، كما سوف نرى بعد قليل. وانتبه في هذه الخطوة إلى خطأين يحذر منهما فصل Google نفسه: الخلط بين الارتباط Correlation والسببية Causation، فكون رسالة خطأ تظهر بكثرة الآن لا يعني أنها السبب، فقد تكون موجودة منذ أشهر بنفس العدد، وأن تبدأ بالفرضيات النادرة قبل الشائعة، فخطأ في نواة Linux ممكن، ولكن استعلاماً بلا فهرس أو قرصاً ممتلئاً أكثر احتمالاً بكثير. ### الخطوة الخامسة: اكتب كل شيء بوقته اكتب أثناء التحقيق، وليس بعده، كل ما رأيته وكل ما جربته ونتيجته بالوقت، في ملف نصي أو في قناة الحادثة في نظام المحادثة لديكم. والسبب أنك بعد ساعة من الضغط لن تتذكر هل جربت إعادة تشغيل ال Container قبل تعديل الإعداد أم بعده، وأن زميلك الذي ينضم في منتصف الحادثة يقرأ الملف بدل أن يسألك عشرة أسئلة، وأن هذه الملاحظات هي المادة التي يبنى منها تقرير ما بعد الحادثة Postmortem. وتجد نموذجاً جاهزاً تنسخه في قسم [نموذج ملاحظات الحادثة](#runbook) في آخر هذا الدليل. ### متى توقف الضرر أولاً ثم تبحث عن السبب؟ هناك قاعدة يكررها فصل Google بتشبيه من الطيران: الطيار المبتدئ يتعلم أن أول مسؤولياته في الطوارئ أن يبقي الطائرة في الجو، واستكشاف العطل يأتي بعد ذلك. وفي عملنا تعني هذه القاعدة أنه إذا كان العملاء متأثرين الآن، وكان لديك إجراء معروف يعيد الخدمة، فنفذه أولاً ثم ابحث عن السبب. ومن هذه الإجراءات: - **التراجع Rollback:** إعادة الإصدار السابق من التطبيق أو الإعداد السابق، وهو الأهم والأكثر استخداماً، لذلك يجب أن يكون التراجع أمراً واحداً مجرباً، وليس عملية تخترعها أثناء الحادثة. - **إيقاف الميزة Feature Flag:** إطفاء الميزة الجديدة دون نشر جديد، إذا كان تطبيقك يدعم ذلك. - **زيادة السعة مؤقتاً:** نسخة إضافية من التطبيق، أو سيرفر أكبر، وهنا يصبح السيرفر الأكبر مقبولاً، لأنه إجراء مؤقت لكسب الوقت وليس الحل. - **تحويل الحركة Failover:** إلى نسخة أو منطقة سليمة إذا كانت موجودة. - **تخفيف الحمل Load Shedding:** إيقاف المهام غير الضرورية مؤقتاً، مثل تقرير ثقيل أو مزامنة خلفية. ولاحظ أن الإجراء المؤقت لا ينهي الحادثة، وإنما ينقلها من «العملاء متأثرون» إلى «لدينا وقت لنفهم»، وبعده يجب أن تصل إلى السبب الجذري وتصلحه إصلاحاً دائماً، وإلا فسوف تعود المشكلة في النشر التالي. والصورة التالية تبين هذا الترتيب على حادثة حقيقية: ![خط زمني بمراحل: الاكتشاف Detect ثم الفرز Triage ثم إيقاف الضرر Mitigate بالتراجع أو إيقاف الميزة أو زيادة السعة ثم عودة الخدمة Restored، وبعدها التحقيق في السبب Root cause ثم الإصلاح الدائم Fix ثم التقرير Postmortem، وشريط أحمر فوق الجزء الأول مكتوب عليه أن المستخدمين متأثرون حتى عودة الخدمة، وشريط أزرق تحت الجزء الثاني مكتوب عليه أن التحقيق بلا ضغط، وأسفله أوقات حادثة Cloudflare في 2 يوليو 2019 بتوقيت UTC: النشر 13:42، والتنبيه 13:45، والإيقاف العالمي للجدار 14:07، وعودة الحركة 14:09، وعودة الجدار بعد إصلاح القاعدة 14:52](https://arabroot.io/content/images/2026/10/troubleshooting-guide-05-mitigate-timeline.webp) إيقاف الضرر يعيد الخدمة للعملاء، ومعرفة السبب تأتي بعده دون ضغط 📌 في 2 يوليو 2019 الساعة 13:42 بتوقيت UTC نشرت Cloudflare قاعدة جديدة في جدار حماية تطبيقات الويب WAF على كل سيرفراتها في العالم دفعة واحدة، وكانت القاعدة تحتوي على تعبير نمطي Regular Expression يتراجع تراجعاً كارثياً Catastrophic Backtracking، فارتفع استهلاك المعالج في السيرفرات التي تخدم HTTP إلى قرابة 100% وصار الزوار يرون 502\. ويشرح [تقرير الشركة](https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/?ref=arabroot.io) أن الفريق لم يبدأ بإصلاح التعبير النمطي، وإنما أوقف ال WAF كله في العالم الساعة 14:07، فعادت الحركة الساعة 14:09، ثم أصلح القاعدة وأعاد تشغيل ال WAF الساعة 14:52\. ومن الإجراءات التي التزمت بها الشركة بعدها أن تنشر القواعد على مراحل Staged Rollouts كما تنشر بقية البرامج، وأن تعيد حماية كانت تمنع القاعدة من استهلاك المعالج بشكل زائد. والدرس أن التراجع عن التغيير الأخير أسرع طريق لإعادة الخدمة، وأن النشر على مراحل يجعل الخطأ يصيب جزءاً صغيراً قبل أن يصيب الجميع. ## ثلاث قوائم تحقق تبدأ بها عندما لا تعرف من أين تبدأ، فالقائمة المكتوبة أفضل من الذاكرة، والسبب أن الذاكرة تقودك إلى ما تعرفه وما حدث في المرة السابقة، بينما القائمة تجبرك أن تنظر إلى كل شيء ولو نظرة سريعة. وهناك ثلاث قوائم معروفة كتبها أصحابها من خبرة طويلة، والصورة التالية تجمعها: ![ثلاث لوحات: في اليمين طريقة USE من Brendan Gregg لكل مورد في السيرفر مع رسوم للمعالج والذاكرة والقرص والشبكة، وتحتها Utilization أي نسبة الوقت المشغول، وSaturation أي العمل المنتظر في الطابور، وErrors أي عدد الأخطاء، وفي الوسط طريقة RED من Tom Wilkie لكل خدمة مع رسم للتطبيق وقاعدة البيانات، وتحتها Rate أي الطلبات في الثانية، وErrors أي الطلبات الفاشلة، وDuration أي زمن الطلبات بالنسب المئوية، وفي اليسار الإشارات الذهبية الأربع من كتاب Google SRE وهي Latency وTraffic وErrors وSaturation، مع ملاحظة أن USE تسأل عن السيرفر وRED تسأل عن ما يراه المستخدم](https://arabroot.io/content/images/2026/10/troubleshooting-guide-02-signals.webp) USE تنظر إلى الموارد من داخل السيرفر، وRED والإشارات الذهبية تنظر إلى الخدمة كما يراها المستخدم ### طريقة USE للموارد وضع Brendan Gregg [طريقة USE](https://www.brendangregg.com/usemethod.html?ref=arabroot.io) في جملة واحدة: لكل مورد، افحص الاستخدام والتشبع والأخطاء. والمورد Resource هو كل جزء في السيرفر له سعة محدودة: المعالج، والذاكرة، والقرص، وواجهة الشبكة، وحتى الحدود البرمجية مثل عدد الملفات المفتوحة. وتعريفاته الثلاثة كما يلي: - **الاستخدام Utilization:** متوسط الوقت الذي كان فيه المورد مشغولاً، مثل معالج مشغول 90% من الوقت. - **التشبع Saturation:** العمل الإضافي الذي لا يستطيع المورد أن يخدمه فينتظر في طابور، مثل عمليات تنتظر دورها على المعالج، أو طلبات قراءة تنتظر القرص، أو ذاكرة تنقل إلى Swap. - **الأخطاء Errors:** عدد أحداث الخطأ، مثل أخطاء القرص في سجل النواة، أو حزم الشبكة المرفوضة. وقوة هذه الطريقة أنها تمر على كل مورد بالترتيب، فلا تترك القرص لأنك مقتنع أن المشكلة في المعالج. والأدوات التي تقرأ بها هذه الأرقام على Linux، مثل `vmstat` و`mpstat` و`iostat` و`free` و`sar`، وكيف تقرأ متوسط الحمل Load Average ووقت السرقة Steal Time، هي موضوع مقال [تحليل أداء سيرفر Linux في 60 ثانية](https://arabroot.io/articles/%D8%AA%D8%AD%D9%84%D9%8A%D9%84-%D8%A7%D8%AF%D8%A7%D8%A1-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-linux-%D9%81%D9%8A-60-%D8%AB%D8%A7%D9%86%D9%8A%D8%A9/)، فلن نكررها هنا. ### طريقة RED للخدمات طريقة USE ممتازة للسيرفر، ولكنها لا تخبرك مباشرة بما يشعر به المستخدم، لذلك وضع Tom Wilkie [طريقة RED](https://grafana.com/blog/the-red-method-how-to-instrument-your-services/?ref=arabroot.io) للخدمات التي تستقبل طلبات، وقال في شرحها إن USE تناسب العتاد والشبكة والأقراص ولا تناسب الخدمات. ولكل خدمة، مثل التطبيق أو ال API أو قاعدة البيانات، تقيس ثلاثة أرقام: - **المعدل Rate:** عدد الطلبات في الثانية. - **الأخطاء Errors:** عدد الطلبات التي تفشل منها. - **المدة Duration:** الزمن الذي تأخذه هذه الطلبات، ويقاس بالنسب المئوية كما سوف نرى. وإذا لم تكن لديك لوحة مراقبة بعد، فسجل ال Reverse Proxy فيه هذه الأرقام الثلاثة لكل طلب: الوقت ورمز الرد وزمن الطلب، وكيف تضيف زمن الطلب وزمن التطبيق إلى سجل Nginx وتقرؤهما هو موضوع مقال [تتبع الطلب البطيء](https://arabroot.io/articles/%D8%AA%D8%AA%D8%A8%D8%B9-%D8%A7%D9%84%D8%B7%D9%84%D8%A8-%D8%A7%D9%84%D8%A8%D8%B7%D9%8A%D8%A1-%D9%85%D9%86-%D8%A7%D9%84%D9%85%D8%AA%D8%B5%D9%81%D8%AD-%D8%A7%D9%84%D9%89-%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA/#nginx-log). ### الإشارات الذهبية الأربع وفي الفصل السادس من كتاب Google SRE، وعنوانه [Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/?ref=arabroot.io)، أربع إشارات يقول الفصل إنك إذا لم تستطع أن تقيس إلا أربعة أشياء في نظام يخدم المستخدمين فقس هذه الأربعة: - **زمن الاستجابة Latency:** الزمن الذي يأخذه الطلب، مع ملاحظة مهمة في الفصل نفسه، وهي أن تفصل زمن الطلبات الناجحة عن زمن الطلبات الفاشلة، فالرد السريع بخطأ 500 يجعل المتوسط يبدو جميلاً وهو في الحقيقة فشل. - **الحركة Traffic:** حجم الطلب على النظام، مثل الطلبات في الثانية. - **الأخطاء Errors:** نسبة الطلبات التي تفشل، سواءً فشلت صراحة مثل 500، أو ضمنياً مثل رد 200 بمحتوى خاطئ. - **التشبع Saturation:** مدى امتلاء الخدمة، مع التركيز على المورد الأكثر ضيقاً فيها. ولاحظ أن الطرق الثلاث متقاربة، وأنها تكمل بعضها: RED والإشارات الذهبية تقولان لك إن الخدمة مريضة وأين يشعر المستخدم بذلك، وUSE تقول لك أي مورد داخل السيرفر هو السبب. ### لماذا p95 وp99 وليس المتوسط؟ المتوسط Average رقم مريح ولكنه يكذب في الأداء، والسبب أن الطلبات البطيئة قليلة العدد ولكنها هي التي يشعر بها العملاء ويشتكون منها. ويضرب فصل Google مثالاً على ذلك: خدمة متوسط زمنها 100 مللي ثانية مع 1000 طلب في الثانية قد يكون 1% من طلباتها يأخذ 5 ثوان. والنسبة المئوية Percentile تحل هذه المشكلة: p50 هو الزمن الذي تنتهي قبله نصف الطلبات، وp95 هو الزمن الذي تنتهي قبله 95% منها، فالطلبات الخمسة في المئة الباقية أبطأ منه، وp99 هو الزمن الذي يتجاوزه طلب واحد من كل مئة. والصورة التالية تبين الأرقام الحقيقية من التجربة العملية في هذا الدليل بعد نشر الإصدار البطيء ومع عميل واحد: المتوسط 123.7 مللي ثانية، وهو رقم قد يبدو مقبولاً في تقرير أسبوعي، ولكن طلباً من كل عشرين أخذ أكثر من 214 مللي ثانية، وطلباً من كل مئة أخذ أكثر من 284، وأبطأ طلب أخذ 440 مللي ثانية، أي أكثر من ثلاثة أضعاف المتوسط. ومع ثمانية عملاء في نفس الوقت صار المتوسط حوالي 300 مللي ثانية وp99 بين 750 و930 مللي ثانية، كما سوف ترى في التجربة: ![رسم أشرطة أفقية لزمن 200 طلب بعد نشر الإصدار v2 في التجربة العملية: المتوسط avg 123.7 مللي ثانية، وp50 هو 114.9، وp95 هو 214.2، وp99 هو 284.4، وأطول طلب max هو 439.9 مللي ثانية، ولكل شريط سطر يشرحه، وتحتها مقارنة بالإصدار v1 قبل النشر: المتوسط 5.4 وp95 هو 7.1 مللي ثانية](https://arabroot.io/content/images/2026/10/troubleshooting-guide-06-percentiles.webp) المتوسط يقول 124 مللي ثانية، وأبطأ الطلبات انتظرت أكثر من ثلاثة أضعافه لذلك اجعل لوحاتك وتنبيهاتك على p95 وp99 لأهم الصفحات، وقارن دائماً بنفس الرقم قبل المشكلة. وكيف تحول هذه الأرقام إلى أهداف تتفق عليها مع فريقك، مثل مستوى الخدمة المستهدف SLO وميزانية الأخطاء Error Budget، فهي مواضيع مخطط لها في قسم [الأداء والموثوقية SRE](https://arabroot.io/start/#stage-sre) في خارطة الطريق. ## أين يمكن أن يبطئ الطلب أو يفشل؟ عندما يفتح العميل صفحة في متجرك، يمر طلبه بعدة طبقات قبل أن يعود إليه الرد، وكل طبقة منها يمكن أن تبطئ أو تفشل، ولكل طبقة أعراض تشبهها وأدوات تقيسها. والصورة التالية تبين الطبقات بالترتيب، وتحت كل طبقة الأعراض التي تعيش فيها في الغالب: ![مسار طلب من اليمين إلى اليسار عبر ثماني طبقات مرقمة مرسومة: 1 المتصفح Browser مع ملفات JavaScript ثقيلة وشبكة العميل، 2 DNS مع NXDOMAIN وسجل قديم بعد التغيير ونطاق منتهي، 3 CDN مع نسخة قديمة وخطأ من الحافة وبطء في منطقة واحدة، 4 Reverse Proxy مع 502 و504 و499 وشهادة منتهية، 5 التطبيق App مع 500 ومعالج 100% وذاكرة تنفد وتسرب، 6 مجمع الاتصالات Pool مع انتظار اتصال وtoo many clients، 7 قاعدة البيانات Database مع استعلام بطيء وأقفال Locks وانتفاخ، 8 القرص والشبكة Disk and network مع قرص ممتلئ وinodes وiowait وفقدان حزم، وتحت المسار سهم يقول ابدأ بالطبقة التي تقول الأرقام إنها تأخذ الوقت](https://arabroot.io/content/images/2026/10/troubleshooting-guide-03-request-layers.webp) كل عرض يعيش في طبقة، والقياس هو الذي يخبرك أي طبقة تبدأ بها والقاعدة في استخدام هذه الخريطة أن تقسم المسار إلى نصفين بالقياس، كما يفعل من يبحث عن كلمة في قاموس، وهي طريقة فرق تسد Divide and Conquer التي يذكرها فصل Google أيضاً. فإذا قال سجل Nginx إن التطبيق رد في 20 مللي ثانية والعميل انتظر 4 ثوان، فالمشكلة قبل ال Reverse Proxy، في الشبكة أو ال CDN أو المتصفح، ولا داعي لأن تفتح قاعدة البيانات أصلاً. وإذا قال إن التطبيق نفسه أخذ 4 ثوان، فانتقل إلى داخل التطبيق ثم إلى قاعدة البيانات. والجدول التالي يجمع الأعراض الشائعة مع أول مكان تنظر فيه وأول أداة تفتحها، وكل سطر منه حالة مشروحة في [دليل الحالات](#playbook) بعد التجربة العملية: | العرض | أول مكان تنظر فيه | أول أداة | | ------------------------------------------ | --------------------------------------------------------- | ------------------------------------------- | | كل الصفحات بطيئة لكل المستخدمين | زمن الطلب في سجل ال Reverse Proxy، ثم موارد السيرفر | curl -w وسجل Nginx، ثم uptime وdocker stats | | بطء أو خطأ عند بعض المستخدمين فقط | ما يشترك فيه المتأثرون: منطقة، أو مزود، أو جهاز، أو متصفح | dig من أكثر من خادم DNS، وترويسات ال CDN | | 502 أو 504 | سجل الأخطاء في ال Reverse Proxy، ثم حالة التطبيق خلفه | docker logs وسجل أخطاء Nginx | | المعالج عند 100% | أي عملية أو Container يستهلكه | top وdocker stats | | عمليات تموت فجأة أو Container يعيد التشغيل | سجل النواة | dmesg أو journalctl -k | | أخطاء كتابة أو No space left on device | المساحة وعدد الملفات | df -h وdf -i وdocker system df | | too many clients أو too many connections | الاتصالات المفتوحة في قاعدة البيانات | pg\_stat\_activity | | الاسم لا يحل أو التغيير لم يصل | ما يرد به خادم DNS الرسمي للنطاق مقارنة بالخوادم العامة | dig | | تحذير شهادة في المتصفح | تاريخ انتهاء الشهادة وسلسلتها | openssl s\_client | | بدأ كل شيء بعد النشر | الفرق بين الإصدارين، وقرار التراجع | سجل النشر وgit log | | بطء في نفس الساعة كل يوم | المهام المجدولة والنسخ الاحتياطي | crontab -l وsystemctl list-timers | والصورة التالية تبين نفس الخريطة بشكل يسهل أن تحفظه أو تعلقه بجانب شاشتك: ![خريطة من عمودين: في اليمين بطاقات الأعراض Slow for everyone وSlow or failing for some users و502 or 504 وCPU at 100% وProcess killed, container restarts وNo space left on device وtoo many clients وName does not resolve وCertificate warning وStarted right after a deploy وSame hour every day، ومن كل بطاقة سهم إلى بطاقة سوداء في اليسار فيها أول أمر يشغله المهندس مثل curl -w وسجل Nginx وdocker stats وdig مع خادمين عامين وترويسات CDN وسجل أخطاء ال Proxy وdocker logs وtop وdmesg -T وjournalctl -k وdf -h وdf -i وdocker system df وpg_stat_activity وdig +trace وwhois وopenssl s_client وسجل النشر والتراجع وcrontab -l وsystemctl list-timers، وفي الأسفل ملاحظة أن الأداة الأولى تؤكد الطبقة والمقال المتخصص يعطي الحل](https://arabroot.io/content/images/2026/10/troubleshooting-guide-04-symptom-map.webp) الأداة الأولى تؤكد لك الطبقة، ثم تنتقل إلى المقال الذي يتعمق فيها ## تجربة عملية: بطء بعد النشر نحققه بالطريقة كاملة الآن سوف نطبق الطريقة على حالة كاملة على جهازك: تطبيق صغير بلغة Python يقرأ آخر طلبات العميل من جدول فيه مليونا طلب في PostgreSQL، ونشغل منه الإصدار v1 ونقيسه، ثم ننشر الإصدار v2 الذي فيه تعديل صغير في الاستعلام يبدو بريئاً، ونرى البطء، ثم نحققه خطوة بخطوة كما في الطريقة، ونتراجع، ونقيس من جديد. والتجربة كلها في Containers تبدأ أسماؤها بـ `lab-trbl-`، والمنفذ الوحيد المنشور هو `18880` على `127.0.0.1` فقط. وإذا لم يكن Docker مثبتاً لديك فقد شرحنا تثبيته في دليل [تثبيت Docker على Ubuntu](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-docker-%D8%B9%D9%84%D9%89-ubuntu/). ### ملفات التجربة أنشئ مجلداً باسم `lab-trbl` وضع فيه الملفات التالية، وأولها التطبيق في ملف `app.py`: ```python import json, os from http.server import ThreadingHTTPServer, BaseHTTPRequestHandler from urllib.parse import urlparse, parse_qs import psycopg_pool VERSION = os.environ.get("APP_VERSION", "v1") db = psycopg_pool.ConnectionPool(os.environ["DATABASE_URL"], min_size=2, max_size=10) QUERIES = { # v1: the column is compared as a number, so the index on customer_id is used "v1": "SELECT id, total, created_at FROM orders WHERE customer_id = %s ORDER BY id DESC LIMIT 5", # v2: a "small" refactor compares the column as text, so the index cannot be used "v2": "SELECT id, total, created_at FROM orders WHERE customer_id::text = %s ORDER BY id DESC LIMIT 5", } class Handler(BaseHTTPRequestHandler): def do_GET(self): url = urlparse(self.path) if url.path == "/health": return self.reply(200, {"status": "ok", "version": VERSION}) if url.path == "/orders": customer = parse_qs(url.query).get("customer", ["1"])[0] with db.connection() as conn: rows = conn.execute(QUERIES[VERSION], (customer,)).fetchall() return self.reply(200, {"version": VERSION, "orders": [r[0] for r in rows]}) self.reply(404, {"error": "not found"}) def reply(self, code, body): data = json.dumps(body).encode() self.send_response(code) self.send_header("Content-Type", "application/json") self.send_header("Content-Length", str(len(data))) self.end_headers() self.wfile.write(data) def log_message(self, fmt, *args): pass ThreadingHTTPServer(("0.0.0.0", 8000), Handler).serve_forever() ``` في الكود أعلاه لاحظ التالي: - الإصداران في ملف واحد، والمتغير `APP_VERSION` يختار بينهما، حتى يكون «النشر» و«التراجع» في التجربة أمراً واحداً، كما يجب أن يكونا في الإنتاج. - الفرق الوحيد بين الإصدارين هو `customer_id::text` في v2، وهو تعديل يحدث فعلاً في الحياة الحقيقية عندما تمرر طبقة في الكود رقم العميل نصاً فيحول أحد الزملاء العمود إلى نص ليتطابق النوعان. والنتيجة أن PostgreSQL لا يستطيع استخدام الفهرس على `customer_id`، لأن الفهرس مبني على قيم العمود نفسه وليس على نتيجة تحويلها إلى نص. - الاتصال بقاعدة البيانات عبر مجمع اتصالات Connection Pool بحد أقصى 10 اتصالات، وشرحنا فكرته في مقال [تجميع الاتصالات](https://arabroot.io/articles/%D8%AA%D8%AC%D9%85%D9%8A%D8%B9-%D8%A7%D9%84%D8%A7%D8%AA%D8%B5%D8%A7%D9%84%D8%A7%D8%AA-connection-pooling-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/). ثم ملف `Dockerfile`: ```dockerfile FROM python:3.13-slim RUN pip install --no-cache-dir "psycopg[binary,pool]==3.*" WORKDIR /app COPY app.py . CMD ["python", "app.py"] ``` ثم ملف `init.sql` الذي ينشئ الجدول بمليوني طلب لمئة ألف عميل، مع فهرس على رقم العميل، ويفعل الإضافة `pg_stat_statements` التي تجمع إحصاءات كل استعلام: ```sql CREATE EXTENSION pg_stat_statements; CREATE TABLE orders ( id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, customer_id bigint NOT NULL, total numeric(10,2) NOT NULL, created_at timestamptz NOT NULL DEFAULT now() ); INSERT INTO orders (customer_id, total, created_at) SELECT (random() * 100000)::bigint, (random() * 500)::numeric(10,2), now() - random() * interval '365 days' FROM generate_series(1, 2000000); CREATE INDEX orders_customer_id_idx ON orders (customer_id); ANALYZE orders; ``` وأخيراً سكربت القياس `measure.sh`، وهو الذي يحول «الموقع بطيء» إلى رقم: يرسل 200 طلب لعملاء مختلفين، ويحسب المتوسط والنسب المئوية: ```bash #!/bin/sh # measure.sh