تفاوت SLA، SLO و SLI: هدف‌های پایداری سرویس با مثال.

جمله‌ی «ما ۹۹٫۹ درصد آپتایم تضمین می‌کنیم» سه ایده‌ی متفاوت رو پشت خودش قایم کرده: چی رو اندازه می‌گیرید، به چی هدف دارید، و چی رو تعهد می‌دید. مهندسی پایداری سایت (SRE) برای هر کدوم اسم جدا گذاشته (SLI، SLO و SLA) و جدا نگه داشتنشون تصمیم‌گیری درباره‌ی پایداری رو خیلی راحت‌تر می‌کنه.

نکته‌های کلیدی

• SLI یه اندازه‌گیریه، SLO هدف داخلی برای اونه، و SLA تعهدی به مشتری که پیامد داره.
• SLA رو شل‌تر از SLO بذارید تا قبل از اینکه به کسی بدهکار بشید، متوجه مشکل بشید.
• بودجه‌ی خطا (۱۰۰ درصد منهای SLO) می‌گه این ماه هنوز چقدر جای ریسک دارید.
• از سمت کاربر اندازه بگیرید (مانیتورینگ بیرونی)، نه فقط از داخل سرورها.

SLI: چیزی که اندازه می‌گیرید

شاخص سطح خدمات عددیه که تجربه‌ی کاربر از سرویس رو نشون می‌ده؛ معمولاً نسبت رویدادهای خوب به کل رویدادها:

• درصد چک‌های HTTP که موفق بودن.
• درصد درخواست‌های API که زیر ۵۰۰ میلی‌ثانیه جواب گرفتن.
• درصد کارهای زمان‌بندی‌شده که سر وقت تموم شدن.

SLI خوب جایی اندازه گرفته می‌شه که کاربرها هستن. یه مانیتور آپتایم که از چند شهر چک می‌کنه، SLI مستقیم دسترس‌پذیریه؛ مصرف CPU اصلاً SLI نیست، چون کاربر CPU رو حس نمی‌کنه، خطا و کندی رو حس می‌کنه.

SLO: چیزی که هدفشه

هدف سطح خدمات یه هدف برای یه SLI در یه بازه‌ی زمانیه:

SLOها داخلی‌ان. برای هدایت تصمیم‌های فنی وجود دارن، پس اون‌ها رو جایی بذارید که کاربرها متوجه می‌شن و براشون مهمه، نه روی ۱۰۰ درصد.

SLA: چیزی که تعهد می‌دید

توافق‌نامه‌ی سطح خدمات یه قرارداده. یه هدف، روش اندازه‌گیریش، استثناها (معمولاً تعمیرات اعلام‌شده) و اتفاقی که در صورت رعایت نشدن می‌افته (معمولاً اعتبار یا تخفیف سرویس) رو مشخص می‌کنه.

چون SLA پیامد داره، اون رو شل‌تر از SLO بذارید. اگه SLO شما ۹۹٫۹۵ درصد و SLA شما ۹۹٫۹ درصد باشه، یه ماه بد اول هدف داخلی رو می‌سوزونه و قبل از اینکه بدهکار بشید وقت واکنش دارید.

بودجه‌ی خطا

بودجه‌ی خطا مقدار ناپایداری‌ایه که SLO اجازه می‌ده:

تیم‌ها از این بودجه برای تصمیم‌گیری استفاده می‌کنن:

• بودجه مونده؟ قابلیت منتشر کنید، آزمایش کنید، migrationهای پرریسک انجام بدید.
• بودجه نزدیک تمومه؟ سرعت انتشار رو کم کنید و وقت رو صرف پایداری کنید.

می‌تونید با محاسبه‌گر آپتایم ببینید هر هدف در عمل چه معنایی داره.

انتخاب هدف‌های واقع‌بینانه

• از سابقه شروع کنید. اگه فصل قبل ۹۹٫۷ درصد اندازه گرفتید، قول ۹۹٫۹۹ درصد برای ماه بعد خیال‌پردازیه.
• وابستگی‌ها رو بشمرید. سرویسی که به سه جزء هر کدوم با ۹۹٫۹ درصد متکیه، نمی‌تونه بیشتر از حدود ۹۹٫۷ درصد در دسترس باشه، مگر اینکه افزونگی داشته باشید.
• هر «نه»ی اضافه گرون‌تره. رفتن از ۹۹٫۹ به ۹۹٫۹۹ درصد یعنی تشخیص و رفع مشکل در چند دقیقه، شبانه‌روزی.

اندازه‌گیری صادقانه

SLI شما فقط به اندازه‌ی داده‌اش خوبه:

1. از بیرون اندازه بگیرید؛ چک‌های بیرونی مشکل‌های DNS، شبکه و گواهی رو می‌بینن که متریک‌های داخلی نمی‌بینن.
2. به اندازه‌ی کافی مکرر چک کنید؛ فاصله‌ی ۵ دقیقه‌ای نمی‌تونه بودجه‌ی ماهانه‌ی ۴ دقیقه‌ای رو اندازه بگیره.
3. خرابی رو از بیشتر از یه لوکیشن تأیید کنید تا یه مسیر شبکه‌ی خراب بودجه‌تون رو نسوزونه.

پرسش‌های پرتکرار

• تیم‌های کوچیک هم SLO لازم دارن؟

  +

  یه SLO ساده کمک می‌کنه: «فروشگاه ۹۹٫۹ درصد وقت‌ها در دسترسه». بحث‌های مبهم درباره‌ی پایداری رو به عددی تبدیل می‌کنه که هر ماه می‌شه چکش کرد.

• آپتایم ۱۰۰ درصد SLO خوبیه؟

  +

  نه. هیچ جایی برای تغییر نمی‌ذاره و در عمل غیرممکنه. سطحی رو انتخاب کنید که کاربرها دیگه مشکل رو حس نمی‌کنن.

• عدد SLA از کجا اندازه گرفته می‌شه؟

  +

  از هر منبعی که قرارداد مشخص کرده؛ معمولاً مانیتورینگ خود ارائه‌دهنده. داشتن یه مانیتورینگ بیرونی مستقل کمک می‌کنه اون عدد رو راستی‌آزمایی کنید.