الخادم سليم والمستخدم ينتظر: لماذا يخفي المتوسط حقيقة السرعة؟
تأخير ذيل التوزيع والصفوف وزمن المستخدم الحقيقي: ما الذي نقيسه بجانب المتوسط، وكيف نتجنب شراء سعة للمشكلة الخطأ؟
المصدر المفاهيمي: فصل المراقبة في Google SRE Workbook. يشرح حدود المتوسط وقيمة توزيع التأخير. المثال وخطة الفحص مقترحان مستقلان، لا تشخيص لهذا الموقع أو اختبار منتج.
يشكو المستخدم من البطء بينما اللوحة طبيعية. ليس بالضرورة أن أحدهما مخطئ؛ قد تكون الطلبات السريعة كثيرة، والمستخدم وصل إلى مسار نادر بطيء أخفاه المتوسط.
من رقم إلى توزيع
يفيد المتوسط لبعض الاتجاهات، لكنه لا يصف شكل التجربة. أفحص معه المئينات وعدد الطلبات والأخطاء. يشير p95 إلى حد يشمل معظم القياسات، لا وعد لكل شخص ولا أسوأ حالة يقينية.
| المؤشر | فائدته | ما لا يثبته |
|---|---|---|
| الوسيط | التجربة المعتادة للمجموعة | سلامة المسارات النادرة |
| p95 | الجزء الأبطأ من التوزيع | غياب طلبات أشد بطئًا |
| الأخطاء والانصراف | العمل غير المكتمل | السبب الجذري بلا فحص |
| انتظار الصف | فصل الانتظار عن التنفيذ | أن زيادة CPU هي الحل حتمًا |
مجتمع القياس مهم. حذف الطلبات الفاشلة أو المنتهية المهلة قد يجعل الخدمة تبدو أسرع رغم تدهورها. والمئين المرتفع قد يكون متقلبًا في العينة الصغيرة.
الصف ليس استهلاك المعالج
افتراضيًا، ينتظر التطبيق اتصال قاعدة بيانات متاحًا. قد يبقى CPU منخفضًا والمستخدم معطلًا. قد يكون الصف في الوكيل أو تجمع الاتصالات أو عامل خلفي أو خدمة خارجية. تكبير الخادم لا يزيله بالضرورة.
وتمديد المهلة ليس علاجًا عامًا؛ قد يسمح بصف أطول فقط. ينبغي تصميم معدل الدخول وسعة الإنجاز وقرار الازدحام معًا.
تتبع الطلب من منظور المستخدم
- اختر مسارًا مهمًا كالبحث أو فتح تقرير.
- سجّل الزمن الكلي للمستخدم منفصلًا عن زمن التطبيق.
- اربط انتظار الاعتماديات وتنفيذها بمعرّف الطلب.
- قارن تغييرًا محدودًا بحمل مشابه، مع الأخطاء والجودة.
يمثل Trace في OpenTelemetry بداية مفيدة. لكن الأداة لا تمثل كل الطلبات؛ أخذ العينات ومراحل بلا قياس يخلقان نقاطًا عمياء. ولا تُخزّن معلومات حساسة بلا ضرورة داخل الأحداث.
لا تحسب متوسط المئينات
متوسط مئينات الخوادم ليس عمومًا مئين كل الطلبات. يجب أن يناسب التجميع البيانات والأداة. اعرف الطلبات والفترة والاستبعادات التي صنعت الرسم.
وافصل المسارات المهمة إداريًا. خلط صفحة عامة خفيفة بتقرير ثقيل قد يعطي رقمًا غير مناسب لاتخاذ قرار لأي منهما.
أسئلة عملية
هل كل بطء يحتاج RAM أو CPU أكثر؟
لا. تفيد الموارد عند معرفة القيد. قد يكون ضبط الاتصالات أو الاستعلام أو إزالة التكرار أهم؛ قِس النتيجة.
هل يكفي اختبار من حاسوب واحد؟
يفيد لفحص مسار، لكنه لا يثبت تجربة مختلف الأجهزة والشبكات. اجمع الاختبار الخارجي وبيانات المستخدم ومراقبة الخادم.
متى ينتهي التشخيص؟
حين يتحسن المسار نفسه بمعيار مسبق وظروف قابلة للمقارنة، دون نقل الخطأ أو تراجع الجودة إلى مكان آخر. اللون الأخضر لا يكفي.
قراءة مرتبطة: الخادم الحي والخدمة السليمة.
مراجعة المصادر: 2 نوفمبر 2026. السيناريو والخطوات تحليل تأليفي، لا وعد بتحسن ثابت أو تزكية أداة.
تابع القراءة
جميع المنشورات →
حساب الخدمة بلا مالك: مسار وصول صغير يسهل نسيانه
بطاقة لكل حساب خدمة: الغرض والمالك والأذونات ومرجع آمن للاعتماد وموعد المراجعة، دون وضع كلمة المرور في مستند عام.
الخدمة غير جاهزة أم عالقة؟ فحص واحد لا يكفي لكل القرارات
افصل جاهزية الترافيك عن حياة التطبيق، كي لا يتحول انقطاع اعتماد مؤقت إلى حلقة إعادة تشغيل.
افحص 502 عبر ثلاثة حدود قبل إعادة تشغيل كل شيء
مسار قصير لفصل المستخدم والوكيل والتطبيق، مع ربط الوقت ومعرّف الطلب وتجنب الاستنتاج المتسرع.