SLO/SLA و معیارها

SLO/SLA و معیارهای

1) شرایط و سلسله مراتب

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

SLO (هدف سطح خدمات) - مقدار SLI هدف در فاصله مشاهده (28/30/90 روز). مثال: "99. 9٪ از درخواست/پایان پرداخت ≤ 400 ms"

بودجه خطا - 1 − SLO. در SLO 99 9% بودجه خطا = 0. 1٪ از زمان/درخواست

SLA (توافقنامه) - سطح خدمات قانونی قابل توجه: شامل SLO، اندازه گیری، استثنائات، جبران خسارت/جریمه است.

2) اصول طراحی

علائم> معیارهای داخلی. SLI ها باید تجربه واقعی کاربر را منعکس کنند.
تعداد کمی از SLI های کلیدی. برای خدمات - 2-5 اصلی: موفقیت، تاخیر، توان/طراوت، صحت.
پوشش مسیرهای بحرانی هر سناریوی کسب و کار (پرداخت، ورود، webhook، دانلود ETL) مجموعه SLI/SLO خود را دارد.
معنای دقیق «موفقیت». نه «کد 200»، بلکه «کاربر پاسخی را به موقع دریافت کرد و نتیجه معتبر است».
جدا کردن SLO های داخلی و خارجی داخلی - سخت تر ؛ SLA خارجی ≤ 1-2 نه پایین تر است.

3) کاتالوگ SLI (مرجع)

3. 1 API/خدمات آنلاین

موفقیت: "SLI _ success = 1 − (5xx + timeout + business_error )/ all_requests'

تاخیر: p95/p99 'http _ server _ duration _ seconds' توسط مسیر/روش/مستاجر

پهنای باند: «RPS »/محدودیت/سهمیه

درستی: نسبت پاسخهای معتبر (امضاها، طرحها، ناورداها)

3. 2 وب سایت/تحویل ناهمزمان

تحویل: نسبت وقایع تایید شده در ثانیه T و ≤ N retrays

مشتریان: درصد مشترکین بدون تاخیر طولانی (به ازای هر مستاجر)

3. 3 داده/ETL/DWH

تازگی: حالا − last_successful_ingest_ts'

کامل بودن: 'خورده _ ردیف/ expected_rows'

صحت: نسبت پرونده هایی که بررسی های کیفی را انجام داده اند

خطوط لوله: سهم مشاغل تکمیل شده قبل از مهلت

3. 4 SDK های موبایل/مشتری

موفقیت مشتری: نسبت جلسات بدون اشتباهات مرگبار

تأخیر رفت و برگشت: p95 از درخواست تا رندر

بازدیدهای حافظه پنهان: درصد خدمت از حافظه پنهان (به عنوان نشانه ای از عملکرد)

4) فرمول ها و نمونه هایی از اهداف

• 'SLI _ req _ avail = 1 − (failed_requests/ total_requests)'
• 'SLO _ req _ avail = 99. 95% برای 30 روز → بودجه خطا = 0. 05% درخواست ها

• 'uptime = (obs_window − خرابی )/ obs_window'

• 'SLO _ latency = p95 (مسیر = «/پرداخت ») ≤ 400 میلی ثانیه' در برش 7 روز، به استثنای کش گرم یو پی اس (1٪)

• 'SLO _ freshness (مجموعه داده = «سفارشات») ≤ 10 min' p99 در 24 ساعت.

5) بودجه خطا و مدیریت تغییر

بودجه (B): «B = 1 − SLO».
Burn - نسبت خطاهای واقعی به خطاهای مجاز.

• Overspend (burn> 1) → ویژگی یخ، تمرکز بر قابلیت اطمینان.
• در نرخ سوختن> X در پنجره کوتاه - حادثه و کلاه. اقدامات.
• برنامه ریزی: سهم sprint از قابلیت اطمینان با سوختگی در دوره گذشته ارتباط دارد.

6) هشدار: میزان سوختگی و قوانین چند پنجره

ایده: ما گرفتن نشت سریع و رانش آهسته.

• بحرانی: «2٪ بودجه در 1 ساعت» (آتش سریع).
• هشدار: «5٪ بودجه در 6 ساعت» (تخریب خزنده).

• پنجره کوتاه (دقیقه ساعت) برای حوادث سریع.
• پنجره طولانی (6-24 ساعت) برای روند.
• تاخیر: هشدار توسط p99> آستانه ≥5 دقیقه، با سرکوب flapping و ارتباط با موارد ردیابی.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) چند مستاجر و تقسیم بندی

SLI/SLO با توجه به مستاجران/برنامه ها/مناطق شمارش می شود، در غیر این صورت میانه «شکست» را پوشش می دهد.
حداقل تعداد رویدادها برای معنی داری آماری (گارد ریل).
SLA می تواند در تعرفه ها متفاوت باشد (به عنوان مثال، "Pro 99. 9٪، رایگان 99. 5%»).

8) ارتباط با قابلیت مشاهده و ردیابی

معیارهای SLI - از هیستوگرام/شمارنده با نمونه → انتقال به مسیرهای «بد».
گزارش ها منبع دلایل هستند: زمان بندی، کدهای خطای کسب و کار، محدودیت ها.
برای داده ها - پیوند با اصل و نسب: «کدام کار متریک طراوت را به تأخیر انداخت».

9) قراردادها و SLA ها

• SLI/روش اندازه گیری/تعاریف پنجره.
• استثنا (کار برنامه ریزی شده، فورس ماژور).
• روش حادثه و ارتباطات (صفحه وضعیت، RFO/RCA).
• اعتبار خدمات و درخواست سفارش.
• صلاحیت، مدت اعتبار، شرایط تجدید نظر.

• هرگز به طور عمومی قول ندهید که SLO ها سخت تر از معماری و شیوه های عملیاتی اجازه می دهند.
• SLO های داخلی جداگانه و SLA های خارجی.

10) هزینه و اولویت بندی

قیمت نه ها به صورت خطی رشد نمی کند. «99. 9% → 99. 99٪" = کلاس معماری مختلف (N + 1، چند منطقه، دارایی به دارایی).
SLO ها را در ارزشمندترین اقدامات کاربر قرار دهید.
کنترل هزینه تله متری - downsampling، سهمیه، ماکت، و ذخیره سازی توسط کلاس.

11) روش ها و گزارش

گزارش های هفتگی: اجرای SLO توسط سرویس/مستاجر، هزینه های بودجه، دلایل بالا، برنامه های بهبود.
RCA پس از حادثه: ما با بخش هایی از بودجه مرتبط هستیم ؛ ما وظایف را برای از بین بردن علل ریشه ای تنظیم می کنیم.
Fichfriz: معیارهای ورود/خروج.

12) قالب ها (برای شروع سریع)

12. 1 کارت SLO (به عنوان مثال)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 جدول بلوغ SLO

13) نمونه هایی از قوانین (قطعات)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO برای داده ها و ML (ویژگی ها)

SLO داده های پایان به پایان: طراوت P99، کامل بودن P99، زمان «پردازش مجدد» پس از تصادف.

قراردادهای داده: طرح های مورد انتظار، حجم، مهلت ؛ نقض اطلاعات → حادثه

ML: SLO برای تأخیر استنتاج، SLA برای در دسترس بودن ویژگی های stor، نظارت بر رانش (کیفیت مدل یک موضوع جداگانه در خارج از SLA است).

15) ادغام با امنیت و حریم خصوصی

SLI سیاهههای مربوط بدون PII/اسرار ؛ نشانه گذاری/ماسک کردن.
تغییرات در SLO/SLA ها را بررسی کنید و نشریات را در سیاهههای مربوط غیر قابل تغییر گزارش دهید.
برای مسیرهای نظارتی (پرداخت/PII) - SLO های جداگانه و دقیق تر.

16) چک لیست

قبل از شروع خدمات/ویژگی ها

• SLI های موفقیت/تاخیر/بازدهی/طراوت تعریف شده است.
• SLO و پنجره تعریف شده است ؛ بودجه خطا محاسبه می شود.
• تنظیم هشدار سوختگی نرخ (کوتاه + بلند).
• داشبورد RED + نمونه → مسیرها ؛ حادثه رانيبوک.
• بخش چند اجاره نامه و آستانه اهمیت.
• Fichfreeze و روش گزارش.

عملیات

• گزارش هفتگی SLO/burn، برنامه های سخت شدن.
• ارزیابی مجدد SLO زمانی که معماری/بار تغییر می کند.
• دوره «حوادث مته» و به روز رسانی runibook.
• نظارت بر هزینه تله متری و شمارش SLI.

17) Runbook'и

Runbook: رشد سریع p99/پرداخت

1. Alert p99> threshold → داشبورد را باز کنید → از طریق نمونه برای ردیابی بروید.
2. دامنه CLIENT/SERVER باریک را پیدا کنید، مناطق/نسخه ها را مقایسه کنید.
3. تخریب را فعال کنید (کش/حد/برگشت)، دستور وابستگی را اطلاع دهید.
4. پس از تثبیت - RCA، وظایف بهینه سازی، به روز رسانی اندازه گیری SLO.

Runbook: هزینه بودجه> 50٪ برای هفته

1. ویژگی های یخ زده، اولویت قابلیت اطمینان را افزایش دهید.
2. خوشه بندی خطاها: توسط مسیرها/مستاجران/وابستگی ها.
3. اصلاح → تایید بهبود روند.
4. تنظیم گذشته و هشدار/آستانه.

18) سوالات متداول

س: چه تعداد SLO نیاز دارید ؟

A: حداقل در سناریوهای بحرانی کاربر: موفقیت + تاخیر. هر چیز دیگری خارج از ضرورت است.

س: کدام بهتر است - در دسترس بودن با زمان یا درخواست ؟

A: بر اساس تقاضا - متریک کاربر بیشتر. زمان مناسب برای اجزای شبکه/infra است.

س: چرا p95، متوسط نیست ؟

A: وسط دم را پنهان می کند ؛ کاربر احساس p95/p99.

س: چگونه بیش از حد "پیچ ها را محکم نکنیم ؟

A: با اهداف واقع بینانه (داده های تاریخی) شروع کنید، سپس به عنوان بالغ شوید.

• «قابلیت مشاهده: سیاهههای مربوط، معیارها، ردیابی»
• «آثار توزیع شده»
• «گزارش های حسابرسی و تغییر ناپذیر»
• «Webhook گارانتی تحویل»
• «در حمل و نقل/در حالت استراحت رمزگذاری»
• «منبع داده (اصل و نسب)»