Claude Code لتحقيقات الأداء: سير عمل مقاس

لماذا يفشل عمل الأداء بدون قياس

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

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

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

عامل الأداء كأنّه تجربة، لا مناظرة. الحلقة بسيطة وقابلة للتكرار:

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

العديد من النجاحات متواضعة: تقليم 8% من p95، تقليل ذروة الذاكرة بـ50 ميغابايت، أو حذف استعلام قاعدة بيانات واحد. تلك المكاسب مهمة، لكن فقط إذا كانت مقاسة، مؤكدة وقابلة للتكرار.

سير العمل: قس، افترض، غيّر، أعد القياس

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

تتبع واضح:

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

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

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

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

اختر المقياس وحدد خط أساس

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

كن محددًا حول السيناريو. "API بطيء" غامض جدًا. "POST /checkout بعربة نموذجية من 3 عناصر" قابل للقياس. حافظ على ثبات المدخلات حتى تكون الأرقام ذات معنى.

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

بالنسبة للزمن، اعتمد على النسب المئوية وليس المتوسط فقط. p50 يظهر التجربة النموذجية، بينما p95 وp99 يكشفان ذيل الألم الذي يشتكي منه المستخدمون. تغيير يحسّن p50 لكنه يُسوء p99 قد يشعر المستخدم بأنه أبطأ.

قرّر مسبقًا ماذا يعني "مهم" حتى لا تحتفل بضوضاء:

• زمن الاستجابة: تحسّن بنسبة لا تقل عن 10% في p95 (أو عتبة ثابتة مثل 50 ملِّي ثانية)
• الإنتاجية: زيادة لا تقل عن 5% في الطلبات في الثانية مع نفس معدل الخطأ
• CPU أو الذاكرة: انخفاض كافٍ لتجنّب التوسيع أو الأعطال
• التكلفة: انخفاض قابل للقياس لكل تشغيل أو لكل 1,000 طلب

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

جمع الأدلة بالبروفايل ومقاييس بسيطة

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

عادةً ما تأتي الأدلة الجيدة من مزيج مصادر:

• سجلات التطبيق (زمن الطلب، معدل الأخطاء، أبطأ نقاط النهاية)
• تتبّعات APM (أين يذهب الوقت عبر الخدمات)
• مخرجات بروفايلر أو رسوم شعلة (الدوال الساخنة ومسارات الاستدعاء)
• إحصاءات قاعدة البيانات (الاستعلامات البطيئة، انتظار الأقفال، معدل إصابة الكاش)
• مقاييس البنية التحتية (CPU، الذاكرة، الشبكة، إعادة تشغيل الحاويات)

استخدم مقاييس بسيطة عندما يكون السؤال "هل هو أبطأ وبأي قدر؟" استخدم البروفايل عندما يكون السؤال "أين يذهب الوقت؟" إذا تضاعف p95 بعد نشر، ابدأ بالتوقيتات والسجلات لتأكيد الانحدار وتحديد النطاق. إذا أظهرت التوقيتات أن معظم التأخير داخل شيفرة التطبيق (وليس DB)، فإن بروفايلر CPU أو رسم شعلة يمكن أن يوجّهك إلى الدالة المحددة التي نمت.

حافظ على قياسات آمنة. اجمع ما تحتاجه لتصحيح الأداء، لا محتوى المستخدم. فضّل التجميعات (الزمن، العدّادات، الأحجام) على الحمولة الخام، واحجب المعرفات افتراضيًا.

الضوضاء حقيقية، لذلك خذ عينات متعددة ولاحظ القيم الشاذة. نفّذ نفس الطلب 10 إلى 30 مرة، وسجّل الوسيط وp95 بدلاً من تشغيل واحد "الأفضل".

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

تحويل الأدلة إلى افتراض واضح

ابدأ بعَرَض يمكنك تسميته: "p95 ارتفع من 220 ملِّي ثانية إلى 900 ملِّي ثانية أثناء ذروة الحركة"، "CPU يصل إلى 95% على نواتين"، أو "الذاكرة تنمو 200 ميغابايت في الساعة." الأعراض الغامضة مثل "يبدو بطيئًا" تقود إلى تغييرات عشوائية.

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

الافتراض الجيد جملة واحدة، قابل للاختبار، ومرتبط بتنبؤ. أنت تطلب مساعدة لاختبار فكرة، لا تطلب من أداة جعل كل شيء أسرع بطريقة سحرية.

قالب افتراض بسيط

استخدم هذا الشكل:

• بسبب (الدليل)، فإن (المشتبه به) يسبب (العَرَض).
• إذا غيّرنا (السلوك المحدد)، فإن (المقياس) يجب أن يتحسّن بـ(الكم التقريبي).
• سنعرف أنه نجح إذا (نتيجة إعادة القياس).

مثال: "لأن البروفايل يظهر 38% من CPU في SerializeResponse، إن تخصيص مخزن جديد لكل طلب يسبب ارتفاعات CPU. إذا أعدنا استخدام المخزن، يجب أن ينخفض p95 بحوالي 10–20% وCPU ينخفض بـ15% تحت نفس الحمل."

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

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

كيف تستخدم Claude Code دون الانجراف نحو التخمين

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

قدّمه بمُدخلات حقيقية، لا وصف غامض. ألصق أدلة صغيرة ومركزة: ملخّص بروفايل، بعض أسطر السجل حول الطلب البطيء، خطة استعلام، ومسار الشيفرة المحدد. أدرج أرقام "قبل" (p95، وقت CPU، وقت DB) حتى يعرف خط أساسك.

اطلب منه تفسير ما تشير إليه البيانات وما لا تدعمه. ثم اجبره على طرح تفسيرات متنافسة. مطالبة مفيدة تنتهي بـ: "اعطني 2–3 افتراضات، ولكلٍ منها أخبرني ما الذي يدحضها." هذا يمنع التمسّك بالقصة الأولى المعقولة.

قبل تغيير أي شيء، اطلب أصغر تجربة يمكنها تأكيد الافتراض القيادي. اجعلها سريعة وقابلة للعكس: أضف مؤقتًا واحدًا حول دالة، فعل علم بروفايلر واحد، أو شغّل استعلام DB مع EXPLAIN.

إذا أردت هيكلًا صارمًا للمخرجات، اطلب:

• ما تشير إليه الأدلة (ومستوى الثقة)
• 2-3 افتراضات مع اختبار نفي لكلٍ منها
• أصغر تغيير شيفرة أو إعداد لاختبار الأول
• بالضبط أي مقياس تعيد قياسه والاتجاه المتوقع

إن لم يستطع تسمية مقياس محدد، موقع، ونتيجة متوقعة، فأنت تعود للتخمين.

اجعل التغييرات صغيرة وقابلة للعكس

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

غيّر شيئًا واحدًا في كل مرة. إن عدّلت استعلامًا وأضافت كاشًا وأعدت كتابة حلقة في نفس الالتزام، فلن تعرف ما الذي أفاد (أو أضر). التغييرات ذات المتغير الواحد تجعل القياس التالي ذو معنى.

قبل لمس الشيفرة، اكتب ما تتوقعه بالأرقام. مثال: "p95 يجب أن ينخفض من 420 ملِّي ثانية إلى أقل من 300 ملِّي ثانية، ووقت DB يجب أن يقل بحوالي 100 ملِّي ثانية." إن لم يصقّل النتيجة، تتعلّم سريعًا أن الافتراض كان ضعيفًا أو غير كامل.

اجعل التغييرات قابلة للعكس:

• فضّل تفريق صغير يمكن التراجع عنه بسهولة.
• ضع التغيير خلف علم بسيط حتى يمكنك إيقافه بسرعة.
• تجنّب refactors العابرة التي تغيّر الأسماء، التنسيق والمنطق معًا.
• قصر النطاق: نقطة نهاية واحدة، مسار ساخن واحد، استدعاء مكلف واحد.
• أضف ملاحظة قصيرة في رسالة الالتزام مع مقاييس قبل/بعد المتوقعة.

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

أضف توقيتًا خفيفًا حول عنق الزجاجة المشتبه بها حتى ترى ما تغيّر. طابع زمني واحد قبل وبعد استدعاء (مسجّلًا أو كمقياس) يمكن أن يؤكد أن التغيير استهدف الجزء البطيء أم أن الوقت انتقل لمكان آخر.

أعد القياس وقرّر الخطوة التالية

بعد التغيير، أعِد تشغيل نفس السيناريو المستخدم لخط الأساس: نفس المدخلات، البيئة، وشكل الحمل. إن كان الاختبار يعتمد على الكاش أو الإحماء، اجعل ذلك صريحًا (مثال: "التشغيل الأول بارد، الخمس التالية دافئة"). وإلّا ستجد تحسينات محض حظ.

قارن النتائج بنفس المقياس ونفس النسب المئوية. المتوسطات قد تخفي الألم، لذا راقب p95 وp99 بالإضافة إلى الإنتاجية ووقت CPU. شغّل تكرارات كافية لترى استقرار الأرقام.

قبل الاحتفال، تحقّق من الانحدارات التي لا تظهر في رقم واحد:

• الصواب: هل الإجابات لا تزال متوقعة؟
• معدل الأخطاء: المهلات، 5xx، إعادة المحاولات
• الذاكرة: ذروة أعلى أو نمو ثابت عبر التشغيلات
• ذيل الاستجابة: هل p99 أسوأ رغم تحسّن p50؟
• تكلفة الموارد: هل CPU أو DB ارتفعا

ثم قرّر بناءً على الأدلة، لا الأمل. إن كان التحسّن حقيقيًا ولم تُدخل انحدارات، ابقَ على التغيير. إن كانت النتائج مختلطة أو ضوضائية، ارجع التغيير وكون افتراضًا جديدًا، أو قلّص النطاق أكثر.

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

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

الأخطاء الشائعة التي تضيّع الوقت

عمل الأداء ينحرف عادة عندما تفقد الصلة بين ما قستَه وما غيّرتَه. حافظ على سلسلة أدلة نظيفة حتى تستطيع القول بثقة ما الذي جعل الأمور أفضل أو أسوأ.

المخالفون المتكرّرون:

• إصلاح الهدف الخطأ: تحتفل بمتوسط أسرع (p50)، لكن ذيل الاستجابة (p95 أو p99) لا يزال سيئًا.
• تغيير عدة أشياء دفعة واحدة: refactors، كاش، وتعديلات الاستعلام في التزام واحد يعني أنك لا تستطيع معرفة ما الذي أفاد.
• الإيمان بتشغيل ضوضائي واحد: معيار محلي يتأرجح 20% بين التشغيلات ليس دليلًا.
• اعتبار بروفايل واحد كحقيقة مطلقة: قد يشير رسم الشعلة إلى تحليل JSON، لكن الطلبات تتكدس بسبب تباطؤ DB.
• مقارنة التفاح بالبرتقال: مجموعات بيانات مختلفة، أعلام ميزات، عتاد مختلف، أو مستويات تزامن مختلفة ثم استنتاج نتائج.

مثال صغير: تبدو نقطة نهاية بطيئة، فتحسّن المُسلسل لأنه ساخن في بروفايل. ثم تعيد الاختبار بمجموعة بيانات أصغر فيبدو أسرع. في الإنتاج، p99 يتفاقم لأن DB لا تزال عنق الزجاجة وزيادة الحمولة الناتجة عن التغيير زادت حجم الحمولة.