بیشتر تیمها یک عدد آپتایم روی اسلاید دارند که هیچکس دقیقاً نمیداند چطور محاسبه میشود. SLO دقیقاً برای حل همین ابهام است.
سه اصطلاح، به زبان ساده
- SLI (شاخص): چیزی که اندازه میگیرید. مثلاً «نسبت درخواستهایی که در کمتر از ۳۰۰ میلیثانیه پاسخ گرفتند».
- SLO (هدف): مقداری که برای آن شاخص میخواهید. مثلاً «۹۹٪ در هر ۳۰ روز».
- SLA (توافق): تعهد قراردادی، معمولاً با جریمه. همیشه سستگیرانهتر از SLO داخلی.
نکته کلیدی: SLO باید از SLA سختگیرانهتر باشد. اگر به مشتری ۹۹٫۵ قول دادهاید، هدف داخلیتان باید ۹۹٫۹ باشد تا فضای واکنش داشته باشید.
اولین SLO خود را انتخاب کنید
با یک چیز شروع کنید: مسیری که اگر خراب شود، مشتری فوراً میفهمد. معمولاً ورود به سیستم، صفحه اصلی محصول، یا مسیر پرداخت.
برای همان مسیر، دو شاخص کافی است:
دسترسپذیری = درخواستهای غیر-5xx / کل درخواستها
تأخیر = درخواستهای زیر 300ms / کل درخواستهابودجه خطا؛ بخش واقعاً مفید
اگر SLO شما ۹۹٫۹٪ در ۳۰ روز است، یعنی اجازه دارید حدود ۴۳ دقیقه در ماه خارج از هدف باشید. این ۴۳ دقیقه «بودجه خطا» شماست.
این عدد یک ابزار تصمیمگیری است، نه یک معیار سرزنش:
- بودجه دستنخورده مانده؟ میتوانید ریسک بیشتری بردارید — استقرار سریعتر، تغییرات بزرگتر.
- بودجه تمام شده؟ تغییرات غیرضروری متوقف میشود تا پایداری برگردد.
بودجه خطا، بحث «سرعت یا پایداری» را از یک مشاجره سلیقهای به یک تصمیم دادهمحور تبدیل میکند.
اشتباهات رایج
هدف ۱۰۰٪ گذاشتن. غیرممکن و پرهزینه است. هر نُهِ اضافه، هزینه را چند برابر میکند و بعد از حدی، کاربر تفاوت را حس نمیکند.
اندازهگیری از داخل. اگر شاخص را از داخل کلاستر میسنجید، قطعی DNS یا CDN را نمیبینید — دقیقاً همان چیزی که کاربر میبیند.
SLO برای هر سرویس. با یکی شروع کنید. ده SLO که کسی نگاهشان نمیکند، از یک SLO که هفتگی بررسی میشود بدتر است.
بعد از تعیین
یک داشبورد بسازید که مصرف بودجه خطا را نشان دهد، و هشدار را روی نرخ مصرف بگذارید، نه روی خود قطعی. اگر بودجه یک ماه در دو ساعت دارد تمام میشود، باید همان دو ساعت بدانید — نه آخر ماه.