شاخص‌های سطح سرویس: چهار سیگنال طلایی

تاریخچه، مفهوم و تمثیل

تاریخچه مانیتورینگ

در گذشته، رویکرد رایج در مهندسی نرم‌افزار مانیتور کردن تمامی اجزای یک سرور بود. مواردی مانند دمای دستگاه، سرعت چرخش فن‌ها و میزان دقیق مصرف پردازنده (CPU) و حافظه (RAM) به صورت مداوم بررسی می‌شدند. نتیجه این رویکرد، تولید هزاران هشدار بی‌ارزش بود. به عنوان مثال، ممکن بود در نیمه‌شب زنگ هشدار به دلیل رسیدن موقت پردازنده به ۱۰۰٪ به صدا درآید، در حالی که کاربران هیچ مشکلی در کار با سایت یا سرویس مربوطه تجربه نمی‌کردند. با تکامل مهندسی قابلیت اطمینان سایت (SRE)، این نتیجه حاصل شد که به جای اندازه‌گیری تمامی پارامترهای سخت‌افزاری، سیستم باید از دیدِ کاربر نهایی بررسی و مانیتور شود.

تمثیل پزشکی

برای درک بهتر، می‌توان سیستم مانیتورینگ را با معاینه بیمار در اورژانس مقایسه کرد. پزشک برای بررسی وضعیت عمومی بیمار، تمام سلول‌های بدن او را آزمایش نمی‌کند، بلکه تنها چهار «علامت حیاتی» را بررسی می‌نماید: ضربان قلب، فشار خون، دمای بدن و سرعت تنفس. چنانچه این چهار مورد در وضعیت عادی باشند، بیمار به احتمال بسیار زیاد سالم است. در دنیای SRE نیز دقیقاً چهار علامت حیاتی برای نرم‌افزارها تعریف شده است که به آن‌ها «چهار سیگنال طلایی» گفته می‌شود.

مفهوم تخصصی (Technical Concept)

شاخص SLI یا Service Level Indicator (شاخص سطح سرویس)، به معنای یک اندازه‌گیری دقیق و عددی از کیفیت عملکرد سیستمی است که به کاربر ارائه می‌شود. در واقع SLI به عنوان دماسنج سیستم عمل می‌کند.

بر اساس استانداردهای SRE، چهار سیگنال طلایی (The Four Golden Signals) عبارتند از:

• تاخیر (Latency): مدت زمانی که طول می‌کشد تا سیستم به یک درخواست پاسخ دهد. این شاخص نشان‌دهنده سرعت پاسخگویی سیستم است.
• ترافیک (Traffic): مقدار تقاضا یا تعداد کاربرانی که در یک لحظه مشخص در حال استفاده از سیستم هستند.
• خطاها (Errors): درصدی از کل درخواست‌های کاربران که با خطا مواجه شده یا با شکست روبرو شده‌اند.
• اشباع (Saturation): میزان مصرف ظرفیت و توان سیستم (مانند حافظه، پردازنده یا پهنای باند) که نشان می‌دهد سیستم تا چه حد تحت فشار است.

کارگاه عملی و پیاده‌سازی

فرض کنید یک سیستم مانیتورینگ برای بررسی لحظه‌به‌لحظه سرویس ورود به سایت (login-api) راه‌اندازی شده است. خروجی این داشبورد اطلاعات را در قالب JSON ارائه می‌دهد. چهار سیگنال طلایی در این خروجی به شکل زیر نمایان می‌شوند:

{
  "service": "login-api",
  "four_golden_signals": {
    "latency_ms": 120,
    "traffic_rps": 5000,
    "error_rate_percent": 0.5,
    "saturation_percent": 75
  }
}

تحلیل این داده‌ها بسیار ساده و کارآمد است. مقادیر بالا نشان می‌دهند که سرویس دارای زمان پاسخگویی ۱۲۰ میلی‌ثانیه (بسیار سریع)، ترافیک ۵۰۰۰ درخواست بر ثانیه، نرخ خطای بسیار ناچیز ۰.۵ درصد و اشباع ۷۵ درصدی است. یک مهندس SRE با بررسی همین چهار فیلد نتیجه می‌گیرد که با وجود ترافیک بالا، سیستم کاملاً سالم بوده و در حال سرویس‌دهی مطلوب است.

اشتباهات رایج در دنیای واقعی (Anti-Patterns)

یک اشتباه بسیار مهلک در میان تیم‌های عملیاتی تازه‌کار، تنظیم سیستمِ هشدار (Alerting) صرفاً بر اساس شاخص اشباع (Saturation) است. به عنوان مثال، تعریف قانونی که در صورت رسیدن CPU سرور به ۹۰٪، هشداری برای مهندس شیفت ارسال شود.

در رویکردهای مدرن SRE، قانون بر این است که هشدارها صرفاً باید برای علائم بیماری (Symptoms) ارسال شوند، نه برای علت‌ها (Causes). اگر پردازنده سرور روی ۹۹٪ قرار دارد (اشباع بالا)، اما زمان پاسخگویی بسیار پایین (تاخیر کم) و نرخ خطا صفر است، این به معنای استفاده بهینه و حداکثری از منابع زیرساخت است و سیستم هیچ مشکلی برای کاربران ایجاد نکرده است. در چنین شرایطی، نیازی به ارسال هشدار بحرانی نخواهد بود.

بررسی سناریوی کاربردی: روزهای پر ترافیک

سناریو: در جریان رویدادهای پرفشاری مانند جمعه سیاه (Black Friday)، مانیتورینگ یک فروشگاه اینترنتی نشان می‌دهد که شاخص ترافیک (Traffic) سیستم ۱۰ برابر شده است. همزمان، شاخص اشباع پایگاه داده (Saturation) به ۹۵٪ رسیده است. در این حالت، ممکن است پیشنهاد شود که سایت به منظور جلوگیری از خرابی سرور موقتاً از دسترس خارج شود.

تحلیل وضعیت: برای تصمیم‌گیری صحیح، باید به سایر سیگنال‌ها مراجعه کرد:

• شاخص Latency: ۶۰ میلی‌ثانیه (فوق‌العاده سریع)
• شاخص Errors: ۰.۰۱٪ (تقریباً نزدیک به صفر)

نتیجه‌گیری: با تکیه بر اصول «چهار سیگنال طلایی»، مشخص می‌شود که مشتریان در حال تجربه هیچ‌گونه کندی یا خطایی نیستند. بالا بودن اشباع به تنهایی به معنای قطعی سیستم نیست، بلکه صرفاً نشان‌دهنده لود بالای کاری است که سیستم در حال حاضر به خوبی از پس آن برآمده است. اقدام صحیح در این شرایط، ادامه سرویس‌دهی و مانیتور کردن روند تغییرات است و خاموش کردن سایت تصمیمی کاملاً اشتباه خواهد بود.