بودجه خطا و مدیریت SLO

1) چرا SLO و بودجه خطا

SLO (هدف سطح خدمات) - سطح کیفیت هدف درک شده توسط کاربر ؛ SLI - اندازه گیری متریک ؛ بودجه خطا - تحمل برای انحراف در هر پنجره (معمولا 30/90 روز).
بودجه خطا قابلیت اطمینان را از یک «انتزاع» به یک منبع مدیریت شده تبدیل می کند: زمانی که بودجه به سرعت از بین می رود، ما ویژگی ها و chinim را متوقف می کنیم ؛ هنگامی که بودجه سالم است - شما می توانید سرعت انتشار را افزایش دهید.

2) SLI انتخاب کنید: چه چیزی به عنوان «خوب» شمارش می شود

معیار: «موفقیت از نقطه نظر کاربر».

2. 1 SLI های کلاسیک

در دسترس بودن درصد درخواست های موفق (به استثنای آنهایی که توسط مشتری لغو شده است).
'success = http_status ∈ {2xx, 3xx, 404} و بدون وقفه' (404 را می توان موفقیت API خواندن در نظر گرفت اگر انتظار می رود معنایی باشد).
تأخیر: نسبت درخواستها سریعتر از آستانه است (به عنوان مثال، p95 ≤ 300 ms).
'good _ latency = duration_ms ≤ 300'.
تازگی/پایداری: «دادههایی که قدیمیتر از X دقیقه نیستند» (کش، دایرکتوریها، ضرایب).
کیفیت: صحت نتیجه (اعتبار سنج های کسب و کار/invariants backend).

2. ۲ مرزها و بخشها

SLI باید با برش های مهم شمارش شود: «مسیر»، «مستاجر/نام تجاری»، «منطقه/صلاحیت»، «ارائه دهنده پرداخت». بنابراین شما نمی خواهد «لکه دار کردن» شکست یک دسته مهم در سراسر سیستم.

3) فرمول ها و بودجه

3. 1 درخواست مبتنی بر (ترجیح برای API)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 مبتنی بر زمان (برای خدمات پس زمینه/جریان)

SLO_uptime = good_minutes / total_minutes

3. 3 مثال از اهداف

API عمومی: 99. 9% در دسترس بودن در 30 روز → بودجه = 0. 1%.
خودکار پرداخت بحرانی: 99. 95%; کاتالوگ/جستجو: 99 5%.
تاخیر: p95 ≤ 300 ms در «/v1/پرداخت »، p99 ≤ 800 ms.

4) ابزار SLI

4. 1 اصول

Logs/trails → RED (نرخ/خطا/مدت زمان) متریک با سطل صریح.
اطمینان حاصل کنید که 'tenant'، 'region'، 'route _ class' (بدون PII) را قرار دهید.
دو معیار را بشمارید: «موفقیت» و «کل»، و برای تاخیر، «سریع» و «کل».

4. 2 مثال پرومتئوس (نرخ در هر 5M)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) هشدارها با میزان سوختگی (چند پنجره، چند سوختگی)

5. ایده های 1

ما نگاه می کنیم که بودجه نسبت به هدف چقدر سریع می سوزد. اگر سرعت در یک پنجره کوتاه و بلند بالا باشد، سیگنال می دهیم.

5. 2 پروفیل آستانه (برای SLO 99. 9%)

پیجینگ: میزان سوختگی 14 ≥. 4 × (10٪ از بودجه برای 1 ساعت و 5٪ برای 6 ساعت).
بلیط: میزان سوختگی ≥ 6 × (2٪ در 6 ساعت و 1٪ در 24 ساعت).

5. 3 قواعد مثال (پرومتئوس، شبه)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

به طور مشابه برای 6 ساعت/24 ساعت برای بلیط.

6) دفتر بودجه: فرآیندها

6. 1 دروازه های آزاد

اگر تعادل بودجه <25٪ باشد و روند منفی باشد - «کد توقف» در ویژگی ها، اولویت SRE/ثبات است.
نسخه های قناری باید یک SLO جداگانه ('deployment. environment = "canary" ").

6. ۲ اولویت دادن به بکلاگ

توزیع ظرفیت فرماندهی نسبت به نرخ احتراق و تاثیر درآمد.
توجیه بدهی فنی با معیارها: «رفع X میزان سوختگی را با Y٪ کاهش می دهد».

6. 3 پس از حادثه

هر حادثه - RCA و «تعمیر که نمی تواند به عقب برگردد» (قابل اجرا)، کنترل «به SLO بازگشته است».

7) SLO به عنوان کد

7. 1 نمونه آشکار SLO (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 تولید قانون

از ژنراتورها (slo-generator، pyrra، sloth) استفاده کنید تا به طور خودکار قوانین، داشبورد ها و گزارش ها را ایجاد کنید.

8) تخریب و حفاظت SLO

Load shedder: پاسخ سریع بدون وابستگی «گران» در اوج.
Cache & stale: 'stale-while-revalidate' для خواندن.

محدودیت های نرخ/همزمانی: از backends محافظت می کند ؛ مسیرهای مهم - اولویت

Circuit/Timeout: وقفه های سریع و شاخه های «برگشت».
پرچم های ویژگی: غیرفعال کردن ویژگی های سنگین با یک دکمه.

9) قابلیت مشاهده برای SLO

داشبورد: SLO واقعی در مقابل هدف، تعادل بودجه، نرخ سوختن، سهم مسیرها/ارائه دهندگان.
همبستگی: از «سوراخ» SLO → به نمونه → یک ردیابی خاص → سیاهههای مربوط/پروفایل.
گزارش ها: روند هفتگی، مصرف بودجه، دلایل اصلی تخریب.

10) ضد گلوله

یک SLO «جهانی» برای کل مشکلات ماسک. بخش بندی.
«99. 99٪ در همه چیز" به استثنای هزینه و واقعیت. اهداف را از تجربه کاربر انتخاب کنید.
هشدار CPU/heap به جای نرخ سوختن/SLO.
نادیده گرفتن تغییر مسیرهای 4xx/long که UX را خراب می کند.
پنجره مات (نورد در مقابل تقویم) - مقایسه «سیب با پرتقال».

11) ویژگی های iGaming/امور مالی

مسیرهای پول (سپرده/برداشت): SLO های فردی بالاتر از سطح کلی (به عنوان مثال،. 99. 95٪ در دسترس بودن ؛ p95 ≤ 250 میلی ثانیه)

ارائه دهندگان PSP/KYC: SLO برای هر ارائه دهنده + هشدار برای سهم خود را به رایت ؛ سوئیچینگ مسیر اتوماتیک (مسیریابی هوشمند).
حوزه های قضایی/مستاجران: SLO ها و بودجه ها توسط «منطقه/صلاحیت/نام تجاری» به طوری که یک مشکل محلی متریک جهانی را «سیل» نمی کند.
بازی مسئول: SLO برای دوره استفاده از محدودیت/خود حذفی (انطباق فرمول).

حسابرسی/نظارتی: نگه داشتن SLO و گزارش حادثه ؛ شفافیت در بازرسی های داخلی

12) تولید لیست آمادگی

• SLI ها (در دسترس بودن/تاخیر/کیفیت/طراوت) و بخش (مسیر/مستاجر/منطقه) تعریف شده است.
• اهداف (SLOs) واقع بینانه هستند، هماهنگ با کسب و کار ؛ پنجره های نورد 30/90 روز وجود دارد.
• هشدارها با میزان سوختگی با چند پنجره (صفحه بندی/بلیط).
• SLO به عنوان کد (قانون/ژنراتور داشبورد) ؛ گزارش های بودجه
• دروازه های آزادی به بقیه بودجه گره خورده است ؛ بخش های قناری
• مکانیسم های تخریب (shedder، cache stale، circuit، limits) اجرا و آزمایش می شوند.
• همبستگی معیارها ↔ مسیرها، کتابهای روشن.
• مسیرهای مالی/اداری - SLO/هشدار جداگانه ؛ PSP/KYC تقسیم می شوند.
• حادثه به طور منظم یکپارچهسازی با سیستمعامل و سرمایه گذاری قابلیت اطمینان مبتنی بر سوختگی.

13) TL ؛ دکتر متخصص

SLI ها را با ارزش کاربر تعریف کنید، SLO های واقع گرایانه را تنظیم کنید و از طریق Error Budget و میزان رایت با چند پنجره مدیریت کنید. SLO-as-code را فعال کنید، دروازه ها و تخریب را به صورت برنامه ریزی شده آزاد کنید. بخش بر اساس مسیر/مستاجر/منطقه ؛ برای مسیرهای مالی اهداف سخت تر و هشدارهای جداگانه را حفظ کنید.