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

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

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

SLO (هدف سطح خدمات) - هدف SLI ارزش در هر پنجره زمان (به عنوان مثال، "موفقیت ≥ 99. 9% در 28 روز)

Error Budget - نرخ شکست SLO مجاز «1 − SLO» است.
SLA (توافقنامه سطح خدمات) - تعهدات قراردادی با جریمه/اعتبار (خارجی).
KPI های قابلیت اطمینان - معیارهای فرآیند عملیاتی (MTTD/MTTA/MTTR/MTBF، کاهش خودکار٪، پوشش هشدار و غیره).

2) نحوه انتخاب SLI (بر اساس سیگنال های طلایی)

1. تاخیر - p95/p99 برای نقاط پایانی کلیدی.
2. ترافیک - جریان RPS/RPM/پیام.
3. خطاها - سهم خطاهای 5xx/کسب و کار (به عنوان مثال، حذف پرداخت "کاهش به دلیل خطای PSP).
4. اشباع - اشباع منابع (CPU/RAM/IO/تاخیر).

• ارتباط با تجربه درک شده توسط کاربر.
• از لحاظ فنی در دسترس و پایدار در اندازه گیری.
• ما کنترل می کنیم (اقدامات برای بهبود امکان پذیر است).
• هزینه جمع آوری کم

3) فرمول ها و مثال ها

3. 1 در دسترس بودن

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

به عنوان مثال: SLO 99. 9% در 30 روز → بودجه خطا = 0. 1٪، که معادل 43 دقیقه 12 ثانیه عدم دسترسی است.

3. 2 تاخیر

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 پرداخت (سطح کسب و کار)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) بودجه ناقص و نرخ سوختن

خطای بودجه - «مخزن سوخت» شما برای نوآوری (انتشار، آزمایش).

• کانال سریع (تشخیص در ~ 1 ساعت)،
• کانال آهسته (روند بیش از ~ 6-12 ساعت/24 ساعت).

• اگر سوختگی> 14. 4 در 1 ساعت - SEV-1 (ما بودجه روزانه را در ~ 100 دقیقه می خوریم).
• اگر میزان سوختگی> 6 در 6 ساعت - SEV-2 (تخریب سریع).

5) هشدار توسط SLO (چند پنجره، چند سوختگی)

شاخص خطا: نسبت نقض 5xx یا تأخیر.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) نمونه SLI/SLO توسط دامنه

6. 1 API دروازه/لبه

SLI-خطاها: نرخ پاسخ 5xx <0. 1% (28)

SLI-Latency: p95 ≤ 250 میلی ثانیه (روز).

SLO: در دسترس بودن ≥ 99. 95% (یک چهارم)

6. 2 پرداخت ها

SLI-Success: پرداخت برای موفقیت (به استثنای شکست مشتری) ≥ 99. 8% (28)

SLI-Latency: مجوز ≤ 2 ثانیه برای 99٪ (روز).
SLO: زمان به کیف پول p95 ≤ 3 мин (24 ساعت).

6. 3 پایگاه داده (PostgreSQL)

SLI-Lag: تکرار تاخیر p95 ≤ 1 ثانیه (روز).

SLI-خطاها: میزان خطای پرس و جو ≤ 0. 05% (28)

دسترسی به SLO Cluster ≥ 99. 95%.

6. 4 صف/جریان (کافکا)

SLI-Lag: تاخیر مصرف کننده پیام های p95 ≤ N (ساعت).

SLI-Durability - ورودی 99 ≥ تأیید کنید. 99% (28)

SLO: در دسترس بودن کارگزاران ≥ 99. 9%.

7) KPI فرآیند قابلیت اطمینان

MTTD (میانگین زمان برای تشخیص)

MTTA [...] برای تایید)

MTTR [...] برای بازگرداندن)

MTBF [...] بین شکست ها)

درصد حوادث با کاهش خودکار

پوشش SLO/هشدار از مسیرهای ترافیکی بالا (≥ هدف 95٪)

سهم آزادی با مرحله قناری

مصرف بودجه اشتباه توسط تیم/ویژگی

8) نحوه قرار دادن SLO واقع بینانه

1. اندازه گیری قابلیت اطمینان پایه فعلی (3-4 هفته).
2. تعریف مسیرهای کاربر «حساس» (ورود، سپرده، بازی).
3. هزینه هر انحراف (زمان، پول، شهرت) را در نظر بگیرید.
4. یک هدف بلند پروازانه اما قابل دستیابی (10-30٪ بهبود در پایه) را انتخاب کنید.

5. بررسی سه ماهه

• بلافاصله «پنج نه» بدون توجیه.
• SLO با معیارهایی که برای کاربر قابل مشاهده نیست (به عنوان مثال، CPU بدون ارتباط با UX).
• SLO بیش از حد → اسپری تمرکز.

9) گزارش SLO و بودجه

• تکمیل در هر SLO: واقعی در مقابل هدف، روند، اعتماد به نفس.
• خلاصه ای از مصرف خطا: چقدر بودجه «سوخته» از چه کسی (انتشار/حادثه).
• پنج علت اصلی تخریب، برنامه CAPA و وضعیت کار.
• تاثیر کسب و کار: تبدیل، ND، نگهداری، LTV.

10) ارتباط با سیاست انتشار

بودجه خطا <50% → نسخه های رایگان.
50-80% → «حالت محتاطانه»: تنها محاسبات کم خطر/قناری.

11) SLA (قراردادی) - قالب مورد

تعهد دسترسی: به عنوان مثال، 99. 9 درصد در ماه

Force Majeure: DDoS فراتر از کنترل معقول، ارائه دهندگان شخص ثالث.
پنجره اندازه گیری و منطقه مسئولیت: منابع معیارها، روش محاسبه.
اعتبار/جریمه: جدول سطوح (به عنوان مثال، عدم دسترسی 60-120 دقیقه → اعتبار X٪).
روش های تشدید و اطلاع رسانی: مهلت ها، کانال ها.
داده ها و حریم خصوصی: ماسک، ذخیره سازی، نگهداری قانونی.
طرح پیشگیری از تکرار (CAPA) در صورت نقض.

SLA خارجی باید به SLI های خاص و قابل اثبات و روش محاسبه اشاره کند.

12) ابزار اندازه گیری

معیارهای منفعل: Prometheus/Mimir/Thanos، صادر کنندگان.
سیاهههای مربوط: Loki/ELK برای شمارش موفقیت/خطا در سطح کسب و کار.
مصنوعی: نمونه های فعال (ورود/سپرده/بازی) توسط cron.
ردیابی: Tempo/Jaeger برای تنگناهای p99.
پرداخت/امور مالی: منابع حقیقت زمین برای SLI پرداخت.

13) نمونه پرس و جو (قالب)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

کلید> فیلتر کردن برای حذف «کاهش توسط مشتری».

14) FinOps و قابلیت اطمینان

هزینه هر 9: هزینه اضافه کردن 9 به صورت نمایی در حال افزایش است.
منحنی سود: بهینه که در آن افزایش درآمد/کاهش در زیان ≥ هزینه اضافی «9».
نمونه کارها SLO: سطوح مختلف برای مسیرهای مختلف (پرداخت بحرانی «گران تر» است، گزارش «ارزان تر» است).

15) SLO/کیفیت هشدار - چک لیست

• SLI با UX و معیارهای تجاری ارتباط دارد.
• پنجره و تجمع سازگار هستند (نورد 28d/سه ماهه).
• هشدار چند پنجره، بدون flapping، مسیریابی مبتنی بر نقش.
• مستندات: مالک، فرمول، منابع، runbook.
• SLO پانل نسخه ی نمایشی با بودجه اشتباه و شاخص های سوختگی.
• به طور منظم اهداف را بررسی کنید (سه ماهه).
• تست های مصنوعی در سناریوهای کلیدی.

16) برنامه پیاده سازی (4 تکرار)

1. هفته 1: موجودی مسیرهای کاربر، پیش نویس SLI، داشبورد اساسی.
2. هفته 2: رسمی SLO، بودجه بندی، هشدار (سریع/آهسته رایت).
3. هفته 3: ادغام با فرآیند حادثه/انتشار، قوانین یخ.

4. هفته 4 +: SLA های قراردادی، بررسی های سه ماهه، «هزینه هر 9» مدل Finops

17) مینی سوالات متداول

آیا برای هر سرویس باید یک SLO داشته باشم ؟

بهتر 2-3 آنهایی که کلیدی (موفقیت + تاخیر) به جای ده ها تن از آنهایی که ثانویه.

اگر بودجه تمام شود چه میشود ؟

انتشار انجماد، تمرکز بر تثبیت و CAPA، از بین بردن ویژگی های تجربی.

چگونه از درگیری بین سرعت انتشار و قابلیت اطمینان جلوگیری کنیم ؟

انتشار برنامه «در بودجه»، اجرای محاسبات قناری و پرچم های ویژگی.

نتیجه گیری

قابلیت اطمینان توسط مجموعه ای از معیارهای متفاوت کنترل نمی شود، بلکه توسط سیستم کنترل می شود: SLI → SLO → خطای بودجه → سوزاندن هشدار → فرآیند حادثه → CAPA → SLA. استاندارد تعاریف، منابع داده ها و گزارش، اهداف پیوند به تجربه کاربر و اقتصاد، و به طور منظم بررسی nines بر اساس ROI در دنیای واقعی.