سرور سالم است، کاربر معطل؛ چرا میانگین سرعت حقیقت را پنهان می‌کند؟
تحلیل تأخیر انتهای توزیع، صف‌ها و زمان پاسخ واقعی کاربر؛ چه چیزهایی را کنار میانگین بسنجیم و چگونه از خرید ظرفیت اشتباه جلوگیری کنیم؟
منبع مفهومی: فصل پایش در Google SRE Workbook. منبع، محدودیت میانگین و ارزش توزیع تأخیر را توضیح می‌دهد. مثال و برنامه بررسی زیر پیشنهاد مستقل این مقاله است؛ توصیف وضعیت واقعی این سایت یا بنچمارک محصول نیست.
کاربر می‌گوید صفحه کند است؛ داشبورد می‌گوید همه‌چیز عادی است. لزوماً یکی اشتباه نمی‌کند. ممکن است داشبورد پاسخ بیشتر درخواست‌های سریع را ببیند، ولی کاربر به همان مسیر کم‌تعداد و کندی رسیده باشد که میانگین آن را پوشانده است.
از یک عدد به یک توزیع برسیم
میانگین برای دیدن برخی روندها مفید است، اما شکل تجربه را نشان نمی‌دهد. من در کنار آن، صدک‌ها، شمار درخواست‌ها و خطا را می‌بینم. p95 مرز تقریبی بخش عمده اندازه‌گیری‌ها را نشان می‌دهد؛ نه تضمین زمان پاسخ همه افراد و نه بدترین حالت قطعی.
| شاخص | چه کمکی می‌کند؟ | چه چیزی را ثابت نمی‌کند؟ |
|---|---|---|
| میانه | تجربه معمول در مجموعه اندازه‌گیری | سلامت مسیرهای کم‌تعداد |
| p95 | دیدن بخش کندتر توزیع | نبود درخواست بسیار دیرتر |
| تعداد خطا و انصراف | کارهایی که کامل نشده‌اند | علت ریشه‌ای بدون بررسی |
| زمان انتظار صف | تفکیک انتظار از اجرا | اینکه افزایش CPU حتماً راه‌حل است |
جمعیت اندازه‌گیری مهم است. اگر زمان‌تمام‌شده‌ها یا درخواست‌های شکست‌خورده را از گزارش حذف کنیم، سرویس ممکن است روی کاغذ سریع‌تر شود، در حالی که تجربه بدتر شده است. برای نمونه کم نیز صدک بالا می‌تواند ناپایدار باشد.
صف، مصرف پردازنده نیست
در یک سناریوی فرضی، برنامه برای اتصال آزاد به پایگاه داده منتظر است. CPU میزبان می‌تواند پایین باشد ولی کاربر همچنان معطل بماند. صف ممکن است در پراکسی، استخر اتصال، پردازشگر پس‌زمینه یا سرویس بیرونی باشد. بزرگ‌کردن سرور بدون شناخت محل انتظار، لزوماً آن را حذف نمی‌کند.
افزایش مهلت پاسخ هم درمان عمومی نیست. ممکن است فقط اجازه دهد صف طولانی‌تر شود. از نظر من باید حجم ورودی، ظرفیت انجام کار و تصمیم هنگام ازدحام کنار هم طراحی شوند.
درخواست را از دید کاربر دنبال کنیم
- یک مسیر مهم مانند جست‌وجو یا بازکردن گزارش انتخاب کنید.
- زمان کل کاربر را از زمان داخل برنامه جدا ثبت کنید.
- با شناسه درخواست، انتظار و اجرای وابستگی‌ها را مرتبط کنید.
- در بار مشابه، یک تغییر محدود را با خطا و کیفیت نتیجه بسنجید.
برای این ارتباط، مفهوم Trace در OpenTelemetry نقطه شروع مفیدی است. اما داشتن ابزار ردیابی به‌تنهایی همه درخواست‌ها را نمایندگی نمی‌کند؛ نمونه‌برداری و مرحله‌های بدون ابزارگذاری می‌توانند نقاط کور بسازند. اطلاعات حساس هم نباید بی‌دلیل داخل رویدادها ذخیره شوند.
از میانگینِ صدک‌ها پرهیز کنیم
میانگین‌گرفتن از صدک چند سرور، عموماً صدک کل درخواست‌ها را نمی‌سازد. روش تجمیع باید با نوع داده و ابزار اندازه‌گیری سازگار باشد. تیم لازم است بداند نمودار از کدام درخواست‌ها، در چه بازه‌ای و با چه حذف‌هایی ساخته شده است.
گزارش مدیریتی هم باید مسیرهای مهم را تفکیک کند. صفحه سبک عمومی و گزارش سنگین، اگر در یک سبد مخلوط شوند، نتیجه‌ای می‌سازند که برای هیچ‌کدام تصمیم مناسبی نمی‌دهد.
پرسش‌های عملی
آیا هر افت سرعت به رم یا CPU بیشتر نیاز دارد؟
خیر. منابع بیشتر وقتی ارزش دارند که منبع محدودکننده شناسایی شده باشد. تنظیم اتصال، اصلاح پرس‌وجو یا حذف کار تکراری ممکن است اثر بیشتری داشته باشد؛ نتیجه باید اندازه‌گیری شود.
آیا تست از یک رایانه کافی است؟
برای بررسی یک مسیر مفید است، اما تجربه شبکه‌ها و دستگاه‌های متفاوت را ثابت نمی‌کند. آزمون بیرونی، داده کاربران و مشاهده سمت سرور را کنار هم ببینید.
پایان عیب‌یابی چه زمانی است؟
وقتی همان مسیر با معیار ازپیش‌تعیین‌شده، در شرایط قابل مقایسه بهتر شده و خطا یا کیفیت به جای دیگری منتقل نشده باشد. «نمودار سبز شد» معیار کافی نیست.
مطالعه مرتبط: تفاوت زنده‌بودن سرور و سلامت خدمت.
بررسی منابع: 2 نوامبر 2026. سناریو و مراحل، تحلیل تألیفی‌اند و وعده بهبود ثابت یا ابزار خاصی نیستند.
برای ادامه مطالعه
همه نوشته‌ها →
حساب سرویس بدون مالک؛ دسترسی کوچکی که فراموش می‌شود
برای هر حساب سرویس یک کارت کوتاه بسازیم: هدف، مالک، مجوز، محل امن اعتبارنامه و موعد بازبینی؛ بدون ثبت رمز در مستند عمومی.
سرویس آماده نیست یا گیر کرده؟ یک Healthcheck برای همه تصمیم‌ها کافی نیست
تفاوت آمادگی دریافت ترافیک و زنده‌بودن برنامه را روشن کنیم تا خطای موقت یک وابستگی، حلقه ری‌استارت نسازد.
خطای 502 را با سه مرز بررسی کنیم؛ نه با ری‌استارت همه‌چیز
یک مسیر کوتاه برای جداکردن مشکل کاربر، پراکسی و برنامه بالادستی؛ همراه با ثبت زمان و شناسه درخواست و پرهیز از نتیجه‌گیری عجولانه.