SLO، SLA و نظارت بر قابلیت اطمینان

(بخش: تکنولوژی و زیرساخت)

خلاصه ای کوتاه

SLO یک هدف کیفیت داخلی است، SLA تعهد خارجی به مشتری است، SLI این است که چگونه کیفیت را اندازه گیری می کنیم. در iGaming، SLI های کلیدی: API و در دسترس بودن پرداخت، تاخیر p95/p99 از مسیرهای بحرانی، زمان به کیف پول (TTW)، تبدیل پرداخت، راه اندازی بازی و معیارهای صف. مدیریت قابلیت اطمینان در اطراف بودجه اشتباهات، هشدار چند رایت، دروازه انتشار روشن و داشبورد بصری با حاشیه نویسی ساخته شده است.

1) شرایط و تفاوت ها

SLI (شاخص سطح خدمات) - شاخص اندازه گیری (به عنوان مثال،. نسبت درخواست های موفق در هر پنجره زمانی).

SLO (هدف سطح خدمات) - ارزش SLI هدف (به عنوان مثال در دسترس بودن 99 9% در 30 روز)

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

قانون: ابتدا SLI/SLO را در داخل تثبیت کنید و سپس SLA را در خارج تعمیر کنید.

2) چارچوب SLI برای iGaming

نرم افزار TexSLO

در دسترس بودن: موفق 2xx/3xx/تمام درخواست ها.
تاخیر: p95/p99 با مسیرهای کلیدی («/سپرده »، «/شرط»، «/بازی/init »).
خطاها: اشتراک 5xx/زمان بندی.
اشباع/صف: پرداخت تاخیر/صف معامله.

SLI کسب و کار

تبدیل پرداخت: «موفقیت/تلاش».
TTW p95: زمان از درخواست برداشت به ثبت نام.
موفقیت شروع بازی: جلسات بازی، راه اندازی اولیه ارائه دهنده.
موفقیت جریان KYC/AML.

3) بودجه خطا: نحوه شمارش

بودجه خطا = 1 − SLO.
مثال: در دسترس بودن 99 SLO. بودجه خطای ⇒ 9 ٪/30d = 0. 1٪ از زمان ≈ 43 دقیقه 12 در یک پنجره 30 روزه.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO بر روی یک پنجره کشویی (30/7/1 روز) شمارش می شود و در داشبورد قابل مشاهده است.

• سریع «احتراق» بودجه → انتشار یخ, ما متوقف قناری, ما در حال کار بر روی ثبات.
• سهام بودجه → اجازه می دهد تغییرات مکرر (کنترل شده).

4) نمونه های SLO برای جریان های کلیدی

• دسترسی ≥ 99 9 ٪/30 دی
• تاخیر p95 '/سپرده '≤ 250 میلی ثانیه/ 30д
• تبدیل پرداخت ≥ پایه − 0. 3 ٪/24 ساعت
• TTW p95 (خروجی) ≤ 3 دقیقه/24 ساعت

• موفقیت بازی ≥ 99. 5 ٪/ 7д p95 بازی init ≤ 600 میلی ثانیه/ 7д

• موفقیت شغلی ≥ 99 ٪/7e، تاخیر <5 دقیقه (پنجره های اوج به طور جداگانه).

5) اندازه گیری: فرمول ها و PromQL (ایده ها)

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6) هشدار سوختگی (چند پنجره)

ایده: ما نرخ فعلی مصرف بودجه را با نرخ مجاز مقایسه می کنیم.

• سوزاندن سریع: 14 × بودجه در 1 ساعت → صفحه در 5-15 دقیقه.
• سوزاندن آهسته: 6 × بودجه در 24 ساعت → بلیط، تجزیه و تحلیل دلیل.

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7) داشبورد «SLO-card» و سیستم عامل

• کارت های خدمات: در دسترس بودن، p95، نرخ خطا، نرخ سوزاندن، تعادل بودجه خطا.
• فیلترها: «env»، «منطقه»، «مستاجر»، «نسخه».
• حاشیه نویسی انتشار: Git SHA، نوع (قناری/آبی سبز)، زمان تغییر.

• مقایسه پایدار در مقابل قناری.
• بخش توسط PSP/ارائه دهندگان بازی.
• برو به نمونه (trace_id) و سیاهههای مربوط.
• تاخیر صف و اشباع (معیارهای USE).

8) فرآیندهای SLO: دروازه، یخ، تشدید

گیتس در CD: ارتقاء قناری تنها در هنگام انجام یک پروکسی SLO (در دسترس بودن، p95، conv) مجاز است.
یخ زدن: با تعادل بودجه سریع یا صفر - توقف انتشار تا بهبودی.
Escalation: ماتریس SEV (پرداخت های SEV1/سپرده ها، بازی های SEV2 SEV3 backhoe).
RCA: تجزیه و تحلیل بدون اتهام، به روز رسانی تست/محدودیت/phicheflags.

9) داده ها/ML-SLO (برای توصیه/LLM)

تاخیر: مدل پاسخ p95 ≤ 300 میلی ثانیه (یا نشانه/ثانیه ≥ N).
پروکسی کیفیت: نسبت پاسخ های معتبر/سمیت کم، سهم مفید است.
تازگی: سن ویژگی ها/داده ها ≤ X ساعت.
هزینه هر رویداد 1k: هزینه در بودجه.
دروازه های SLO در نسخه های مدل (A/B/canary rollout) یکپارچه شده اند.

10) طراحی SLA بر اساس SLO

SLO های محافظه کار را به عنوان پایه ای برای SLA ها انتخاب کنید.
استثنائات (فعالیت های برنامه ریزی شده، ارائه دهندگان وابسته خارجی، روش های حادثه) را تعریف کنید.
جبران خسارت را با سطوح نقض (اعتبار/تخفیف)، گزارش و مکانیسم های تأیید وارد کنید.

11) خطاهای مکرر و ضد الگوهای

SLO وجود ندارد، فقط «uptime 100٪» غیر واقعی است، انگیزه ها را از بین می برد و خطرات را پنهان می کند.
هشدار برای «هر متریک» به جای سوزاندن نرخ - هشدار-خستگی و نادیده گرفتن.
مخلوط کردن PII در معیارها/سیاهههای مربوط به SLO - خطرات انطباق.
Cardinality منفجر می شود: 'user _ id/session _ id' به عنوان برچسب.
فقدان حاشیه نویسی انتشار - دشوار است که تخریب را با تغییر مرتبط کنیم.
بودجه خطای مبهم - تیم متوجه نمی شود که «شما می توانید» ریسک کنید.
SLO به کسب و کار وابسته نیست - معیارهای فنی «سبز» هستند، درآمد «قرمز» است.

12) چک لیست پیاده سازی

1. SLI های اساسی را تأیید کنید (در دسترس بودن، p95/p99، نرخ خطا، TTW، تبدیل).
2. SLO را در پنجره های 30/7/1 تنظیم کنید و بودجه خطا را شمارش کنید.
3. اضافه کردن قوانین ضبط و هشدار سوختگی نرخ (سریع/آهسته).
4. یک نقشه SLO با حاشیه نویسی انتشار و مقایسه canary/stable ایجاد کنید.
5. شامل دروازه ها در CD: بدون SLO-OK - بدون ارتقاء.
6. روش های انجماد و ماتریس SEV تشدید را وارد کنید.
7. SLO ها را به معیارهای تجاری (conv، TTW) و مسیرهای پرداخت پیوند دهید.
8. برای Data/ML، latency/quality/freshness-SLO را تعریف کنید.
9. RCA های منظم و بازنگری SLO/آستانه (سه ماهه).
10. SLA سند تنها پس از SLO تثبیت شده است.

13) نمونه هایی از اهداف «آماده» (به عنوان یک شروع)

API عمومی: در دسترس بودن 99. 9 ٪/30d ؛ p95 ≤ 250 میلی ثانیه/30d ؛ نرخ خطا ≤ 0. 3 ٪/30 دی

پرداخت: تبدیل ≥ پایه − 0. 3 ٪/24 ساعت ؛ TTW p95 ≤ 3 دقیقه/24 ساعت

بازی init: موفقیت ≥ 99. 5 ٪/7d ؛ p95 ≤ 600 میلی ثانیه/7e

مشاغل اداری: موفقیت ≥ 99 ٪/ 7д ؛ ≤ تاخیر 5 دقیقه/7d

LLM/Reco: نشانه/S ≥ N، سمیت viol. ≤ 0. 5 ٪/7d، طراوت ≤ 6 ساعت.

خلاصه

رویکرد SLO/SLA قابلیت اطمینان را از «بهتر از دیروز» به یک رشته قابل اندازه گیری تبدیل می کند: SLI شفاف، بودجه خطای قابل درک، هشدار برای سرعت احتراق، داشبورد قابل درک و دروازه های کیفیت ساخته شده در نسخه ها. این کانتور به پلت فرم iGaming یک p95/p99 قابل پیش بینی، پرداخت پایدار و TTW می دهد که به معنی درآمد بهتر و حوادث کمتر در طول داغترین ساعت ها است.