طرق Brendan Gregg لأداء النظام: التحقيق في الكمون والبروفايلينغ

لماذا تقلل منهجية Brendan Gregg من التخمين

يُعد Brendan Gregg من أكثر الأصوات تأثيراً في مجال أداء الأنظمة، خصوصاً في عالم لينكس. كتب كتباً مستخدمة على نطاق واسع، بنى أدوات عملية، والأهم من ذلك — شارك طرقاً واضحة للتحقيق في مشاكل الإنتاج الحقيقية. تعتمد الفرق على طريقته لأنها تعمل تحت الضغط: عندما يرتفع الكمون والجميع يريد إجابات، تحتاج إلى طريقة للتحول من "ربما السبب X" إلى "بالتأكيد Y" بأدلة قليلة وخطوات محددة.

ماذا يعني فعلاً "منهجية الأداء"

منهجية الأداء ليست أداة واحدة ذكية أو أمر مميز. إنها طريقة قابلة للتكرار للتحقيق: قائمة تحقّق لما تنظر إليه أولاً، كيفية تفسير ما تراه، وكيف تقرر الخطوة التالية.

تلك القابلية للتكرار هي ما يقلل التخمين. بدلاً من الاعتماد على صاحب الحدس الأكبر (أو الصوت الأعلى)، تتبع عملية متسقة تقوم على:

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

وضع الفشل الشائع: الإصلاح قبل القياس

تفشل العديد من تحقيقات الكمون خلال الدقائق الخمس الأولى. يقفز الناس مباشرة إلى الإصلاحات: "أضف CPU"، "أعد تشغيل الخدمة"، "زيد الكاش"، "اضبط GC"، "لا بد أن المشكلة في الشبكة". أحياناً تساعد تلك الإجراءات — وغالباً ما تُخفِي الإشارة، تهدر الوقت، أو تدخل مخاطر جديدة.

تدفعك طرق Gregg إلى تأجيل "الحلول" حتى تستطيع الإجابة على أسئلة أبسط: ما المشبع؟ ما الذي يخطئ؟ ما الذي أصبح أبطأ — الإنتاجية، الطوابير، أم العمليات الفردية؟

ماذا يساعدك هذا الدليل على فعله

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

أساسيات الكمون: ماذا تقيس قبل أن تضبط

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

الإنتاجية والكمون والأخطاء تتحرك معاً

تتصل هذه الإشارات الثلاثة ببعضها:

• الإنتاجية (طلبات/ثانية) المرتفعة قد تزيد الطوابير، ما يزيد الكمون.
• الأخطاء قد تخفض الكمون الظاهر (فشل سريع) أو ترفعه (إعادة المحاولة والمهلات).
• تقييد الإنتاجية (حدود معدل، ضغط عكسي) قد يحسن الكمون الذِيلِي بينما يجعل نجاح الطلبات أقل.

قبل الضبط، اجمع الثلاثة لنفس نافذة الزمن. وإلا فقد "تحل" الكمون عن طريق إسقاط العمل أو الفشل بشكل أسرع.

لا تثق في المتوسطات: المئينات وكمون الذيل

المتوسط يخفي الذروات التي يتذكرها المستخدمون. خدمة بمعدل متوسط 50 ملليثانية قد تعاني من توقفات متكررة تصل إلى ثانيتين.

تتبع المئينات:

• p50: تجربة المستخدم النموذجية
• p95/p99: كمون الذيل (حيث يكمن معظم ألم الحوادث)

راقب أيضاً شكل الكمون: p50 ثابت مع ارتفاع p99 غالباً ما يشير إلى توقفات متقطعة (مثل تداخل الأقفال، هزات I/O، أو توقفات جمع القمامة) بدل تباطؤ عام.

ميزانيات الكمون: أين يُسمح للوقت أن يذهب

ميزانية الكمون نموذج محاسبي بسيط: "إذا يجب أن ينتهي الطلب في 300 ملليثانية، كيف يُسمح باستخدام الوقت؟" قسمه إلى دلاء مثل:

• الوقت في خدمتك (الحوسبة + الانتظار)
• الوقت في الخدمات اللاحقة
• الوقت في قواعد البيانات/الكاش
• العبور الشبكي وTLS
• الوقت المستغرق في الطابور (خيوط، تجمعات اتصالات، موازنات تحميل)

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

ابدأ بسؤال ونطاق واضحين

يتعثر عمل الكمون عندما يوصف "النظام بطيء". تبدأ طرق Gregg أبكر: حوّل المشكلة إلى سؤال محدد وقابل للاختبار.

عرّف ماذا يعني "بطيء" (ولمن)

اكتب جملتين قبل أن تلمس أي أدوات:

• ما الذي بطيء؟ (تحميل صفحة، نقطة نهاية API، وظيفة دفعة، تسجيل دخول، إنهاء طلب، استعلام SQL محدد)
• أين يُلاحَظ البطء؟ (متصفح العميل، تطبيق الجوال، منطقة معينة، بود واحد، مضيف واحد، خدمة داخلية)

يمنعك هذا من تحسين الطبقة الخطأ — مثل CPU المضيف — حين يكون الألم معزولاً لنقطة نهاية أو تبعية واحدة.

اختر نافذة زمنية ونطاق

اختر نافذة تطابق الشكوى وتتضمن فترة مقارنة "جيدة" إن أمكن.

حدّد نطاق تحقيقك صراحةً:

• مضيف مقابل خدمة مقابل نقطة نهاية: "عقدة Kubernetes واحدة" مختلفة عن "مسار API واحد".
• أي شريحة من الحركة: منطقة، مستوى عميل، الطلبات التي ترجع أخطاء فقط، أو كل الطلبات.
• ما الإشارة التي دفعت التقرير: p95 الكمون، مهلات، عمق الطابور، أو توقيتات المستخدم.

الدقة هنا تجعل الخطوات التالية (USE، RED، البروفايلينغ) أسرع لأنك ستعرف أي البيانات ينبغي أن تتغير إذا كانت فرضيتك صحيحة.

عامل التغييرات الأخيرة كفرضيات، لا كأجوبة

دون عمليات النشر، تغييرات التهيئة، تحولات الحركة، وأحداث البُنية التحتية — لكن لا تفترض السببية. كتبها كـ "إذا X، فنحن نتوقع Y" حتى تؤكد أو ترفض بسرعة.

احتفظ بسجل تحقيق خفيف

سجل صغير يمنع العمل المكرر بين الزملاء ويسهّل التسليم.

Time | Question | Scope | Data checked | Result | Next step

حتى خمس سطور كهذه يمكن أن تحول حادثاً متوتّراً إلى عملية قابلة للتكرار.

طريقة USE: جرد سريع للاختناق في الموارد

طريقة USE (الاستفادة، التشبع، الأخطاء) هي قائمة فحص سريعة لGregg لمسح "الأربعة الكبار" — CPU، الذاكرة، القرص (التخزين)، والشبكة — لتضييق المشكلة بدلاً من التخمين.

ما هي: قائمة per-resource

بدلاً من التحديق في عشرات اللوحات، اطرح نفس الأسئلة الثلاثة لكل مورد:

• الاستفادة: ما مدى انشغاله الآن؟
• التشبع: هل يتكدس العمل (طوابير، وقت انتظار)، حتى لو لم تصل الاستفادة إلى الحد؟
• الأخطاء: هل يفشل أو يعيد المحاولة بطريقة تخلق تأخيراً؟

تطبيق هذا باستمرار يصبح جرداً سريعاً لمكان وجود "الضغط".

كيفية تطبيقها عملياً

لـ CPU، الاستفادة هي نسبة انشغال CPU، التشبع يظهر كضغط صف التشغيل أو خيوط تنتظر للتشغيل، والأخطاء قد تشمل تحديد السرعة (throttling) في الحاويات أو مقاطعات سيئة.

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

لـ القرص، الاستفادة هي زمن انشغال الجهاز، التشبع هو عمق الطابور وزمن انتظار القراءة/الكتابة، والأخطاء هي أخطاء I/O أو مهلات.

لـ الشبكة، الاستفادة هي الإنتاجية، التشبع هو السقوط/الطوابير/الكمون، والأخطاء هي إعادة الإرسال، إعادة التعيين، أو فقد الحزم.

الإشارات الأكثر فائدة خلال حوادث الكمون

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

USE يكمل مقاييس الخدمة (لا يستبدلها)

مقاييس مستوى الخدمة (مثل زمن الطلب ومعدل الأخطاء) تخبرك التأثير. USE يخبرك أين تنظر بعد ذلك بتحديد المورد المتعرض للضغط.

حلقة عملية:

1. أكد تأثير المستخدم (المدة/الأخطاء)
2. نفّذ جرد USE
3. توغّل في المورد المشبوه بأدوات أعمق (بروفايل، تتبعات، إحصاءات نواة)

طريقة RED: إشارات خدمة تركزك على التأثير

طريقة RED تُبقيك مترسخاً بتجربة المستخدم قبل الغوص في رسوم المضيف.

• Rate: عدد الطلبات في الثانية التي تتعامل معها الخدمة أو نقطة النهاية
• Errors: عدد الطلبات الفاشلة (وماذا يعني "فشل" لتطبيقك)
• Duration: مدة الطلبات الناجحة (تتبّع كمئين، لا متوسطات)

لماذا RED يساعدك في ترتيب الأولويات

تمنعك RED من مطاردة مقاييس نظام "مثيرة" لا تؤثر على المستخدمين. تُجبر حلقة أقصر: أي نقطة نهاية بطيئة، لأي مستخدمين، ومنذ متى؟ إذا ارتفعت Duration على مسار واحد بينما CPU الكلي ثابت، فهناك نقطة بداية أوضح.

عادةً ما تكون عادة مفيدة: حافظ على RED مُقسَّمة حسب الخدمة وأهم النقاط النهائية (أو طرق RPC الأساسية). يجعل هذا التفرقة بين تدهور شامل وانتكاسة محلية أسهل.

مطابقة أعراض RED مع فحوص USE

RED يخبرك أين الألم. USE يساعدك على اختبار أي مورد مسؤول.

أمثلة:

• Duration مرتفعة + Rate ثابت → افحص التشبع/الطوابير: صف التشغيل CPU، كمون التخزين، تجمعات اتصالات DB.
• Errors مرتفعة + Duration مرتفعة → افحص المهلات وإعادة المحاولات: تبعيات محملة، تجمعات خيوط، سقوط الشبكة.
• Rate مرتفع + Duration مرتفع → افحص حدود السعة: استهلاك CPU، سلوك موازن التحميل، تأخيرات autoscaling.

لوحة "ما تغير؟" الحدّ الأدنى

حافظ على تخطيط مركز:

1. نظرة RED: Rate، Errors، و p50/p95/p99 Duration للخدمة.
2. أهم النقاط النهائية: نفس إشارات RED لكل نقطة، مرتبة حسب الحركة أو أسوأ p95.
3. التبعيات: لوحات على نمط RED للتبعيات الرئيسية (DB، الكاش، APIs خارجية).
4. صف ارتباط واحد: مجموعة صغيرة من مقاييس النظام (CPU، ضغط الذاكرة، كمون I/O للقرص، إعادة إرسال الشبكة) لتسريع القفزة من عرض الخدمة إلى اختبار السبب الجذري.

إذا أردت سير حادث متسق، اقترن هذا الجزء مع جرد USE في /blog/use-method-overview حتى تتحرك من "المستخدمون يشعرون بالأمر" إلى "هذا المورد هو القيد" مع ضوضاء أقل.

الأولويات: اختر السؤال الأفضل التالي

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

قاعدة 80/20 للاختناقات

معظم مشاكل الكمون يهيمن عليها تكلفة واحدة (أو زوج صغير): قفل ساخن، تبعية بطيئة، قرص مثقل، نمط توقف GC. تعني الأولويات البحث عن تلك التكلفة المسيطرة أولاً، لأن تقليم 5% من خمسة أماكن نادراً ما يحرك الكمون المرئي للمستخدم.

اختبار عملي: "ما الذي قد يفسر معظم التغير في الكمون الذي نراه؟" إذا كانت فرضية لا تفسّر سوى جزء ضئيل، فهي أولوية أدنى.

من الأعلى إلى الأسفل مقابل من الأسفل إلى الأعلى: أين تبدأ

استخدم من الأعلى إلى الأسفل عند الإجابة على "هل المستخدمون متأثرون؟" ابدأ من النقاط النهائية (إشارات على نمط RED): الكمون، الإنتاجية، الأخطاء. هذا يساعدك على تجنّب تحسين شيء ليس في المسار الحرج.

استخدم من الأسفل إلى الأعلى عندما يكون المضيف مريضاً بوضوح (أعراض USE): تشبع CPU، ضغط ذاكرة، انتظار I/O. إذا كانت العقدة محمّلة، ستضيع وقتك في مراقبة مئينات النقاط النهائية دون فهم القيد.

شجرة قرار بسيطة تمنع التشتت

عندما يرن تنبيه، اختر فرعاً وابقَ عليه حتى تؤكده أو تنفيه:

• قفزة الكمون + قفزة الأخطاء → "هل هذا حدث تبعية أم سعة؟" (مهلات، استنفاد تجمعات اتصالات)
• قفزة الكمون + قفزة CPU → "هل CPU يعمل بعمل مفيد أم متوقف؟" (وقت على-CPU مقابل خارج-CPU)
• قفزة الكمون + انتظار I/O مرتفع → "أي جهاز أو نظام ملفات يتكدس؟"
• قفزة الكمون دون قفزات بالمورد → "أين يُنفق الوقت في الانتظار؟" (أقفال، المجدول، الشبكة، استدعاءات بعيدة)

تجنّب حمولة المقاييس، ابق منظماً

حدّد لنفسك مجموعة صغيرة من الإشارات الابتدائية، ثم توغّل فقط عندما يتحرك شيء. إذا احتجت قائمة تحقق للحفاظ على التركيز، اربط خطواتك بدليل تشغيل مثل /blog/performance-incident-workflow حتى يكون لكل مقياس هدف محدد: الإجابة على سؤال معين.

البروفايلينغ في الإنتاج دون إيقاف النظام

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

ما الذي يجيب عنه البروفايلينغ فعلاً

البروفايلينغ أداة "ميزانية وقت". بدلاً من مناقشة النظريات ("هي قاعدة البيانات" مقابل "هو GC"), تحصل على دلائل مثل "45% من عينات CPU في تحليل JSON" أو "معظم الطلبات محجوزة على mutex". هذا يضيق الخطوة التالية إلى إصلاح أو اثنين محددين.

الأنواع الشائعة التي يمكنك استخدامها في الإنتاج

• بروفايل CPU: يوضح الكود الذي يُنفَّذ على-CPU.
• بروفايل خارج-CPU (wait): يظهر أين تقضي الخيوط وقت الانتظار (انتظار I/O، تأخير المجدول، sleep، الشبكة، القرص).
• بروفايل الأقفال: يظهر التداخل — الوقت المفقود في الانتظار على الأقفال، mutexes، وقفل القراءة/الكتابة.

كل واحد يجيب عن سؤال مختلف. الكمون العالي مع CPU منخفض غالباً ما يشير إلى وقت خارج-CPU أو وقت قفل بدلًا من نقاط ساخنة CPU.

دائم التشغيل مقابل عند الطلب

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

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

السلامة: العبء، العيّنة، والنوافذ القصيرة

بروفايل آمن للإنتاج يعني التحكم بالتكلفة. فضّل العينة (sampling) بدل تتبّع كل حدث، اجعل نوافذ الالتقاط قصيرة (مثلاً 10–30 ثانية)، وقيّم العبء أولاً في كاناري. إن لم تكن متأكداً، ابدأ بعينات منخفضة التردد وزدها فقط إذا كان الإشارة متوسطة الضوضاء.

مخططات اللهب: كيفية قراءتها وتجنب الاستنتاجات الخاطئة

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

ماذا يظهر مخطط اللهب (وماذا لا يظهر)

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

لا تُظهر مباشرة الانتظار على القرص أو الشبكة أو تأخيرات المجدول، أو وقت الحجز على mutex (هذا وقت خارج-CPU ويحتاج بروفايل مختلف). كما أنها لا تثبت السببية لزمن استجابة المستخدم ما لم تربطها بسؤال محدد.

قراءة العرض وعمق المكدس

• العرض: عدد مرات ظهور ذلك الإطار في العينات. العرض الأكبر عادةً يعني "وقت CPU أكثر"، لكن فقط ضمن نافذة الزمن المختارة.
• عمق المكدس: عمق الاستدعاء. المكدسات العميقة ليست سيئة بذاتها؛ المهم أي المسارات تهيمن وهل تتطابق مع العمل الذي تهتم به.

أفخاخ شائعة لتجنبها

الصندوق الأعرض مغرّ للوم، لكن اسأل: هل هذه نقطة ساخنة يمكنك تغييرها، أم مجرد "وقت في malloc، GC، أو التسجيل" لأن المشكلة الحقيقية تكون في مصدر أعلى؟ راقب أيضاً السياق المفقود (JIT، inline، الرموز) الذي قد يجعل صندوقاً يبدو كالمذنب بينما هو مجرد رسول.

اقترن مخططات اللهب بسؤال محدد

عامل مخطط اللهب كإجابة لسؤال محدود: أي نقطة نهاية، أي نافذة زمنية، أي خوادم، وما الذي تغير. قارن مخططات "قبل مقابل بعد" (أو "صحي مقابل متدهور") لنفس مسار الطلب لتجنب ضوضاء البروفايل.

الوقت خارج-CPU: مصدر الكمون المخفي

عند قفز الكمون، تنظر العديد من الفرق إلى نسبة CPU أولاً. هذا مفهوم — لكنه غالباً ما يوجهك في الاتجاه الخاطئ. يمكن أن تكون الخدمة "تستخدم 20% CPU فقط" وما تزال بطيئة لأن خيوطها تمضي معظم وقتها غير قيد التشغيل.

لماذا يخدعك %CPU وحدها

%CPU يجيب على "كم المعالج مشغول؟" لكنه لا يجيب على "أين ذهب وقت طلبي؟" قد تتعطل الطلبات بينما الخيوط تنتظر أو تُوقَف أو تُركَن من قبل المجدول.

فكرة أساسية: وقت الحائط لطلب يشمل العمل على-CPU ووقت الانتظار خارج-CPU.

المسببات الشائعة لوقت خارج-CPU

وقت خارج-CPU يختبئ عادة وراء التبعيات والتداخل:

• I/O على القرص: قراءات/كتابات متزامنة، fsyncs، تخزين بطيء، فقدان صفحة الكاش.
• انتظار الشبكة: بحث DNS، إعادة إرسال TCP، خدمات بعيدة مثقلة.
• تداخل الأقفال: خيوط محجوزة على الأقفال، reader/writer locks، تداخل المُخصِّص.
• الطوابير: الانتظار في تجمعات الخيوط، تجمعات الاتصالات، أو قوائم العمل الداخلية.

أعراض تستحق المراقبة

بعض الإشارات غالباً ما ترتبط باختناقات خارج-CPU:

• ارتفاع وقت الطابور (طلبات تنتظر قبل أن تبدأ التنفيذ)
• زيادة الخيوط القابلة للتشغيل (منافسة أكبر على وقت CPU)
• ارتفاع انتظار I/O وزيادة أوقات القرص/الشبكة

تخبرك هذه الأعراض "ننتظر"، لكنها لا تخبرك على ماذا ننتظر.

كيف يُظهر بروفايل خارج-CPU "أين ذهب الوقت"

ينسب بروفايل خارج-CPU الوقت إلى سبب عدم تشغيلنا: الحجز في نداءات النظام، الانتظار على أقفال، النوم، أو النزع من المجدول. ذلك قوي لعمل الكمون لأنه يحول التباطؤ الغامض إلى فئات قابلة للعمل: "محجوز على mutex X"، "ينتظر read() من القرص"، أو "معلق في connect() لتبعٍ بعيد". بمجرد أن تسمي الانتظار، يمكنك قياسه، تأكيده، وإصلاحه.

أكد الاختناق بالأدلة، لا بالحدس

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

الاختناق، النقطة الساخنة، والضوضاء

الاختناق هو المورد أو المكوّن الذي حالياً يحد الإنتاجية أو يزيد الكمون. إذا خففته، سيرى المستخدمون تحسناً.

النقطة الساخنة هي حيث يُنفق الوقت (مثلاً دالة تظهر كثيراً في بروفايل). النقاط الساخنة قد تكون اختناقات حقيقية — أو مجرد عمل مشغول لا يؤثر على المسار البطيء.

الضوضاء هو كل ما يبدو مهمّاً لكنه ليس كذلك: وظائف خلفية، ذروات لمرة واحدة، آثار العينة، تأثيرات الكاش، أو "المتكلمون الكبار" الذين لا يرتبطون بالمشكلة المرئية للمستخدم.

إثبات ذلك بالمقارنات والتغيير المتحكم به

ابدأ بالتقاط لقطة "قبل" نظيفة: العَرَض المواجه للمستخدم (الكمون أو معدل الأخطاء) والإشارات المرشحة (تشبع CPU، عمق الطابور، I/O للقرص، تداخل الأقفال، إلخ). ثم طبق تغييراً متحكَّماً يجب أن يؤثر فقط على السبب المشتبه فيه.

أمثلة لاختبارات سببية:

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

الارتباط تلميح، وليس حكم. إذا "CPU يرتفع عندما يرتفع الكمون"، فأكد بتغيير توفر CPU أو تقليل العمل على CPU وملاحظة إن تبع الكمون التغيير.

وثق ما أثبتته

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

ابنِ سير عمل قابل للتكرار لحوادث الأداء

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

حلقة الحادث: كشف → تصنيف → قياس → إصلاح

كشف: إنذار على الكمون المرئي للمستخدم ومعدل الأخطاء، لا فقط CPU. أنبِه عند عبور p95/p99 عتبة لفترة مستمرة.

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

قياس: اجمع أدلة تضيق الاختناق. فضّل الالتقاطات محدودة الزمن (مثلاً 60–180 ثانية) حتى تتمكن من المقارنة "السيء" مقابل "الجيد".

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

قوِّم مجموعة رسوم قياسية صغيرة

حافظ على لوحة مشتركة يستخدمها الجميع أثناء الحوادث. اجعلها مملة ومتسقة:

• الكمون: p50 / p95 / p99 (لكل نقطة نهاية حرجة)
• إشارات RED: Rate, Errors, Duration (عرض الخدمة أولاً)
• بعض مقاييس USE: الاستفادة، التشبع، الأخطاء لـ CPU، القرص، والشبكة

الهدف ليس رسم كل شيء؛ الهدف تقصير زمن الوصول إلى أول حقيقة.

حدّد "الإشارات الذهبية" لكل نقطة نهاية حرجة

قم بقياس النقاط النهائية الأكثر أهمية (checkout، تسجيل الدخول، البحث)، لا كل نقطة. لكل منها اتفق على: p95 المتوقع، أقصى معدل خطأ، والتبعية الرئيسية (DB، الكاش، طرف ثالث).

قرّر ماذا تلتقط أثناء الحوادث

قبل الخروج للتعطل التالي، اتفق على مجموعة التقاط:

• بروفايل (CPU وخارج-CPU)، ومخططات اللهب
• تتبعات للنقاط البطيئة
• سجلات للأخطاء/المهلات (مأخوذة عينات)

وثّقها في دليل تشغيل قصير (مثلاً /runbooks/latency)، بما في ذلك من يمكنه تشغيل الالتقاطات وأين تُخزن الآثار.

أين يندرج Koder.ai في سير عمل على طريقة Gregg

منهجية Gregg تدور حول التغيير المتحكم والتحقق السريع. إذا كان فريقك يبني خدمات باستخدام Koder.ai (منصة محادثة لتوليد وتكرار تطبيقات الويب، الباكند، والجوال)، فاثنان من الميزات تتماشى مع هذا العقل:

• وضع التخطيط يساعدك على تحويل "ربما السبب X" إلى فرضية صريحة ومجموعة تغييرات صغيرة قابلة للاختبار قبل لمس الإنتاج.
• اللقطات والتراجع تدعم تجارب آمنة لمتغير واحد: طبق تغييراً واحداً، أعد قياس إشارات RED/USE، وارجع سريعاً إذا قالت الأدلة "لا".

حتى لو لم تكن تولّد كوداً جديداً أثناء حادث، تلك العادات — فروق صغيرة، نتائج قابلة للقياس، وقابلية التراجع السريعة — هي نفس العادات التي يروّج لها Gregg.

مسار عملي: من قفزة الكمون إلى إصلاح مُثبَت

السيناريو: p99 يقفز أثناء ذروة الحركة

الساعة 10:15 صباحاً ولوحة القيادة تُظهر ارتفاع p99 لواجهة API من ~120ms إلى ~900ms أثناء ذروة الحركة. معدل الأخطاء ثابت، لكن العملاء يشتكون من "بطء" الطلبات.

الخطوة 1 — ابدأ بـ RED لتحديد أثر المستخدم

ابدأ من الخدمة: Rate, Errors, Duration.

تقطّع Duration حسب نقطة النهاية وتجد مساراً واحداً يهيمن على p99: POST /checkout. الإنتاجية ازدادت 2×، الأخطاء طبيعية، لكن Duration يقفز تحديداً عند ارتفاع التزامن. هذا يشير إلى الطوابير أو التداخل، وليس فشل واضح.

تحقق إذا ما كان الكمون هو وقت حسابي أم انتظار: قارن "زمن المعالج" بالتطبيق مقابل زمن الطلب الكلي (أو spans الصاعدة-الهابطة إن توافرت). زمن المعالج منخفض، والزمن الكلي مرتفع — الطلبات تنتظر.

الخطوة 2 — طبق USE على المضيف/المضيفات المشبوهة

جرد الاختناقات المحتملة: الاستفادة، التشبع، الأخطاء للـ CPU، الذاكرة، القرص، والشبكة.

استهلاك CPU ~35% فقط، لكن صف التشغيل (run queue) والتبديلات السياقية ترتفع. ذلك التناقض (CPU منخفض، انتظار مرتفع) إشارة كلاسيكية: الخيوط ليست تحرق CPU — إنها محجوزة.

الخطوة 3 — اختر البروفايل بناءً على الأعراض

• إذا كان CPU عالياً: استخدم بروفايل CPU (مخططات اللهب on-CPU) لمعرفة أين يُنفق الوقت.
• إذا كانت الطلبات تنتظر: استخدم بروفايل خارج-CPU لمعرفة لماذا الخيوط محجوزة (أقفال، I/O، المجدول).

تلتقط بروفايل خارج-CPU خلال الذروة وتجد وقتاً كثيراً في mutex حول كاش تحقق "الترقيات" المشترك.

الخطوة 4 — أصلح ثم تحقق

تستبدل القفل العام بقفل لكل مفتاح (أو مسار قراءة خالٍ من الأقفال)، تنشر، وتراقب عودة p99 إلى القاعدة بينما يبقى Rate مرتفعاً.

قائمة ما بعد الحادث:

• سجّل أعراض RED الضيقة ونقطة النهاية المشتبه فيها.
• احفظ البروفايل ونافذة الزمن.
• أضف تنبيهاً لإشارة التشبع المحددة (مثلاً انتظار القفل / صف التشغيل).
• دوّن "السؤال التالي" إذا تكرر.