نظارت SLA و SLO

1) شرایط و نقش ها

SLA (توافقنامه سطح خدمات) - تعهد قراردادی خارجی به مشتری (مقررات مجازات، اعتبارات).
SLO (هدف سطح خدمات) - هدف سطح خدمات داخلی است که از اجرای SLA پشتیبانی می کند.
SLI (شاخص سطح خدمات) - شاخص اندازه گیری، که بر اساس آن SLO/SLA ارزیابی می شوند.
بودجه خطا - درصد مجاز «عدم دسترسی/خطا» برای دوره: «بودجه = 1 − SLO».
محدوده: اندازه گیری شده توسط چشم کاربر (پایان به پایان). در میکروسرویس ها، هم در سطح کامپوننت و هم در سطح مسیر پایان به پایان.

2) انتخاب SLI: دقیقا چه چیزی را اندازه گیری کنید

معیار ارتباط با تجربه کاربر و ارزش کسب و کار است.

• در دسترس بودن: درصد درخواست های موفق 'SLI = موفق/همه'.
• تأخیر: نسبت درخواستها سریعتر از آستانه T 'SLI = P (تأخیر ≤ T) است.
• کیفیت: نسبت پاسخ صحیح (بدون 5xx/functes. اشتباهات)
• داده ها تا به امروز - تاخیر تکرار/ETL ≤ X دقیقه.
• عملکرد فرآیند کسب و کار: سهم پرداخت های موفق/ثبت نام.

ضد الگوها: فقط ۲۰۰ را به عنوان «موفقیت» در نظر بگیرید و اشتباهات تجاری را نادیده بگیرید. اندازه گیری در شبکه تست به جای شبکه کاربر.

3) فرمول ها و پنجره های مشاهده

• 'در دسترس بودن = (OK_requests/ All_requests) × 100٪'.

• «P95 ≤ T» → بهتر است به عنوان یک سهم فرموله: «SLI =٪ از درخواست ≤ T».
• به عنوان مثال: «99٪ از نمایش داده شد جستجو ≤ 300 میلی ثانیه در 28 روز».
• پنجره کشویی: 28 یا 30 روز (تعادل حساسیت و ثبات). برای حوادث - پنجره های اضافی: 1 ساعت، 6 ساعت، 24 ساعت.

4) خطا بودجه و کنترل نرخ تغییر

محاسبه: در 'SLO = 99. 9% 'بودجه =' 0. 1٪ "خطاها/عدم دسترسی در هر دوره.

• بودجه> 50٪: انتشار و برنامه ریزی آزمایش.
• بودجه 10-50٪: فقط انتشار کم خطر، تشدید قناری ها.
• بودجه <10٪: انجماد انتشار، علت ریشه، بهبود قابلیت اطمینان.
• ارتباط با نسخه های مترقی: canary/ویژگی های پرچم «خوردن» بودجه در دوز، با بازگشت خودکار تحت تخریب.

5) هشدار به سیاستمداران: از آستانه تا میزان سوختگی

چرا «daupal SLO - افزایش هشدار»: خیلی دیر است. نیاز به فعالیت

• 'BR = (خطای مشاهده شده در یک پنجره کوتاه/خطای مجاز در این پنجره)'.
• if 'BR> 1' - بودجه سریعتر از حد معمول مصرف می شود.

• هشدار سریع (سر و صدا حساس است، حوادث را جذب می کند): پنجره 5-10 دقیقه، آستانه BR 14-20 ×.
• هشدار آهسته (تخریب خزنده): پنجره 1-6 ساعت، آستانه BR 2-4 ×.
• ترکیب شرایط: سریع یا آهسته کار - صفحه بندی در تماس.
• سطوح: پیجر برای SLO های کاربر، بلیط/اطلاعیه ها برای تخریب خاکستری SLI های داخلی.

6) قابلیت مشاهده و منابع حقیقت

Logs - تشخیص علل.
معیارها - SLI های عددی (موفقیت/خطا، درصد تاخیر، کسری، شمارنده).
مسیرهای پیاده روی - از طریق مسیرها، محلی سازی بخش های «داغ».
Synthetics - نمونه های فعال از حاشیه (منطقه آگاه).
رویدادهای واقعی - RUM/مشتری تله متری، معیارهای کسب و کار (تبدیل، پرداخت موفق).

الزامات: یک تصویر واحد در داشبورد انتشار و حوادث، حاشیه نویسی «نسخه/canary/flag».

7) طراحی SLO: قالب گام به گام

1. مسیر بحرانی را توصیف کنید (به عنوان مثال، «واریز با کارت»).
2. SLI را تعریف کنید: موفقیت/خطا، آستانه تأخیر، کامل بودن.
3. موافق SLO: هدف 28 روزه + استثنا (پنجره های برنامه ریزی شده).
4. لینک به SLA: تعهد قانونی ≦ SLO واقعی.
5. یک صاحب سرویس، RACI و کانال هشدار را اختصاص دهید.
6. سیاست های هشدار (BR دو پنجره) و بازگشت خودکار را تعریف کنید.
7. پیاده سازی گزارش دهی: بررسی بودجه هفتگی، بررسی پس از حادثه.
8. مرور سه ماهه SLO (تغییر بار/معماری).

8) نمونه های SLO (قالب ها)

• دسترسی: ≥ 99 95٪ (28d، به استثنای پنجره های اعلام شده ≤ 30 دقیقه در ماه).
• تاخیر: «≥ 99٪» پاسخ «≤ 400 میلی ثانیه».
• موفقیت عملیات کسب و کار: "≥ 98. مجوزهای موفق 5٪ (فیلترهای تقلب در نظر گرفته می شوند).

• تاخیر: «≥ 99٪» درخواست «≤ 300 میلی ثانیه».
• ارتباط حافظه پنهان: ≤ 5 دقیقه تاخیر 99٪ از زمان.

• تحویل: "≥ 99. 9٪ برای '≤ 60 s' (پایان به پایان، با retras).
• از دست دادن: ≤ 0. پیام های 01٪ (idemotency/deduplication فعال).

9) چند منطقه و چند مستاجر

SLO «توسط کوهورت»: کشور، ارائه دهنده پرداخت، بخش VIP، دستگاه.
SLO های محلی در لبه: معیارها از نزدیکترین نقاط به کاربر (edge/PoP).
جمع آوری: Total SLO نباید شکست ها را در گروه های مهم پنهان کند.
ارائه دهندگان سوئیچینگ: مسیرهای جایگزین اتوماتیک در سطح دروازه SLO.

10) داشبورد و گزارش

داشبورد انتشار: نسخه، canary (٪ ترافیک)، SLI (موفقیت/تاخیر)، BR، حاشیه نویسی پرچم.
داشبورد عملیاتی: کاهش بودجه روزانه، حوادث بالا، MTTR، گروه های مشکل.
گزارش های هفتگی: تعادل بودجه، روند BR، بدهی فنی (تنگناها)، طرح بهبود.

11) فرآیندها: حوادث، RCA ها و بهبود

مدیریت حادثه: هشدار → ارزیابی BR → مقیاس قناری/پرچم → عقبگرد/ثابت.
RCA (علت ریشه ای): حقایق/جدول زمانی/فرضیه ها/اصلاحات/بررسی اثر توسط SLI.
درس های آموخته شده: غیر مجازات پس از مرگ، موارد اقدام اجباری با صاحبان و مهلت.
بسته شدن حلقه: تغییرات در تست ها، پرچم های ویژگی، محدودیت ها، کش ها، بازپرداخت ها، سهمیه ها.

12) انطباق و حسابرسی

SLO/SLI به عنوان مصنوعات کنترل (سیاست به عنوان کد، سیاهههای مربوط تغییر ناپذیر).
پیوند به الزامات (به عنوان مثال، در دسترس بودن معاملات پرداخت).
شواهد: دقیقه هشدار، گزارش بودجه، انتشار/رولبک سیاهههای مربوط.

13) اشتباهات مکرر و چگونگی اجتناب از آنها

“99. 99٪ یا مرگ": اهداف غیر قابل دستیابی → هشدار ثابت سر و صدا. SLO های واقعی را انتخاب کنید.
میانگین های جهانی پنهان کردن افت های محلی → معرفی گروه ها.
معیارهای e2e: SLO بالا در طول تخریب واقعی در مشتری → اضافه کردن RUM/synthetics.
هشدارها در یک آستانه → تغییر به نرخ سوزاندن دو پنجره.
هیچ پیوندی به تغییرات وجود ندارد → نسخه ها حاشیه نویسی نشده اند، هیچ بازگشت خودکار وجود ندارد.

14) چک لیست مینی پیاده سازی

• مسیرهای بحرانی و SLI/SLO آنها شرح داده شده است.
• پنجره نظارت و محرومیت تنظیم شده است.
• هشدارهای BR دو پنجره (سریع و آهسته) پیکربندی شده اند.
• داشبورد نسخه ها و عملیات با حاشیه نویسی نسخه ها/پرچم ها.
• سیاست بودجه خطا بر انتشارات تاثیر می گذارد.
• بررسی منظم بودجه و RCA های پس از حادثه.
• صاحبان اسناد و مدارک.

15) مثال محاسبه (جزئیات)

در دسترس بودن API SLO: 99. 9% در 28 روز → بودجه = 0. 1%.
برای 7 روز انباشته 0. 06٪ از اشتباهات → استفاده 60٪ از بودجه هفتگی.
در یک پنجره کوتاه 15 دقیقه ای، 2 درصد از خطاها مشاهده می شود. معتبر در این پنجره '0 است. 1٪ × (15 دقیقه/40320 دقیقه) ≈ 0. 000037%`.
Burn Rate ≫ 1 (ده ها ×) → یک پیجر سریع ایجاد می شود، قناری به 1٪ باز می گردد، پرچم ویژگی های کاهش پرداخت UX روشن می شود، RCA شروع می شود.

16) خط پایین

نظارت SLA/SLO نه تنها اعداد در گزارش است، بلکه مکانیزمی برای مدیریت ریسک تغییرات و کیفیت خدمات است. SLI های صحیح، SLO های واقع گرایانه، مدیریت بودجه خطا، هشدارهای نرخ سوختن دو پنجره و قابلیت مشاهده e2e معیارها را به راه حل های کاری تبدیل می کنند: ارزش انتشار سریعتر و تجربه کاربر را قابل پیش بینی نگه دارید.