Error Budgets жана SLO башкаруу

1) Эмне үчүн SLO жана бюджет каталар

SLO (Service Level Objective) - колдонуучу тарабынан кабыл алынган сапаттын максаттуу деңгээли; SLI - өлчөнүүчү метрика; Error Budget - терезеден четтөөлөрдү кабыл алуу (адатта 30/90 күн).
Каталардын бюджети ишенимдүүлүктү "абстракциядан" башкарылуучу ресурска айландырат: бюджет тез күйүп кеткенде - фичтерди жана чинимди тоңдуруп; бюджети дени сак болгондо - чыгарылышын тездетүүгө болот.

2) SLI тандоо: "жакшы" деп эсептелет

Критерий: "колдонуучунун көз карашы боюнча ийгиликтүү".

2. 1 Classic SLI

Availability: ийгиликтүү суроо үлүшү (кардар жокко чыгарылгандарды эске албаганда).
'success = http_status ∈ {2xx, 3xx, 404} жана тайм жок' (404 күтүлгөн семантика болсо, окуу API үчүн ийгилик катары каралышы мүмкүн).
Latency: суроо-талаптардын үлүшү босогодон тезирээк (мисалы, p95 ≤ 300 ms).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness: "Маалыматтар X мүнөттөн ашпайт" (кэш, каталогдор, коэффициенттер).
Quality: натыйжанын тууралыгы (бизнес-валидаторлордон/бэкенд-инварианттардан өтүү).

2. 2 Чек аралар жана сегменттер

SLI маанилүү тилкелери боюнча каралышы керек: 'route', 'tenant/brand', 'region/jurisdiction', 'payment _ provider'. Ошентип, сиз бүтүндөй система боюнча бир маанилүү туткасынын бузулушун "булгабайт".

3) Формулалар жана бюджет

3. 1 Request-based (жакшы API үчүн)

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

3. 2 Time-based (фон кызматтары/стриминг үчүн)

SLO_uptime = good_minutes / total_minutes

3. 3 Максаттардын мисалы

жалпы API: 99. 9% 30 күндүн ичинде жеткиликтүү → бюджет = 0. 1%.
Критикалык төлөм туткалары: 99. 95%; каталогдор/издөө: 99. 5%.
Латенттүүлүк: p95 ≤ 300 мс '/v1/payments ', p99 ≤ 800 мс.

4) аспаптык SLI

4. 1 принциптер

Логи/соода → ачык buckets менен RED (Rate/Errors/Duration) метрика.
Сөзсүз 'tenant', 'region', 'route _ class' (PII жок).
Эки метриканы караңыз: "ийгилик" жана "бардыгы", ал эми latency үчүн - "тез" жана "бардыгы".

4. 2 Мисал Prometheus (5m үчүн rate)

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) Alerty боюнча burn rate (multi-window, multi-burn)

5. 1 Идея

Бюджет максатка карата канчалык тез күйүп жатканын карап көрөлү. Эгерде ылдамдык кыска жана узун терезеде жогору болсо - сигнал беребиз.

5. 2 босого Profils (SLO 99 үчүн. 9%)

Пейжинг: burn rate ≥ 14. 4 × (1 саат үчүн бюджеттин 10% жана 6 саат үчүн 5%).
Билет: burn rate ≥ 6 × (6 саат үчүн 2% жана 24 саат үчүн 1%).

5. 3 эрежелери мисал (Prometheus, psevdo)

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"

Окшош 6h/24h үчүн билет.

6) Бюджет башкармалыгы: процесстер

6. 1 Релиз Гейтс

Эгерде бюджеттин калдыгы <25% болсо жана тенденция терс болсо - фичтерге "код-тоңдуруу", приоритет SRE/туруктуулук.
Канар релиздери өзүнчө SLO кесилиши керек ('deployment. environment="canary"`).

6. 2 Беклог артыкчылыктуу

Команданын сыйымдуулугун күйүү ылдамдыгына жана кирешенин таасирине пропорционалдуу бөлүштүрүңүз.
Техникалык карызды метриктер менен негиздеңиз: "X fix burn rate Y% га төмөндөтөт".

6. 3 Пост-окуя

Ар бир окуя - RCA жана "кайра мүмкүн эмес fix" (actionable), көзөмөл "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` для read.
Rate/Concurrency limits: backends коргойт; маанилүү каттамдар - артыкчылык.
Circuit/Timeout: тез убакыт жана "fallback" бутактары.
Feature flags: оор баскычы бир баскычын өчүрүү.

9) SLO үчүн байкоо

Dashbord: SLO actual vs максат, бюджеттин калдыгы, burn rate, маршруттар/провайдерлер боюнча салым.
Корреляция: "тешиктен" SLO → exemplar → конкреттүү trace → логи/профилдер.
Отчеттор: жума сайын - тенденциялар, бюджетти керектөө, деградациянын негизги себептери.

10) Антипаттерндер

Бир "глобалдык" SLO үчүн бардык → көйгөйлөрдү жашырат. сегментти.
«99. 99% баарына" наркын жана чындыгын эске албаганда. Колдонуучунун тажрыйбасынан максаттарды тандоо.
CPU/heap ордуна burn rate/SLO боюнча Alerts.
UX бузат 4xx/узун редакторлорду четке кагуу.
Тунук эмес терезе (rolling vs календардык) - салыштыруу "апельсин менен алма".

11) iGaming/Каржы өзгөчөлүктөрү

Акча жолдору (депозиттер/корутундулар): жеке SLO жалпы деңгээлден жогору (мисалы, 99. 95% жеткиликтүүлүгү; p95 ≤ 250 мс).
PSP/KYC провайдерлери: ар бир провайдер үчүн SLO + алардын burn салымы үчүн алерт; маршруттарын автоматтык которуу (smart routing).
Юрисдикциялар/тенанттар: SLO жана бюджеттер 'region/jurisdiction/brand' жергиликтүү көйгөй глобалдык метриканы "каптап" кетпеши үчүн.
Жооптуу оюн: SLO лимиттерди колдонуу/өзүн-өзү жоюу учурунда (compliance-formula).
Аудит/жөнгө салуучу: SLO жана инциденттердин отчетторун сактаңыз; ички аудиттер үчүн ачык-айкындуулук.

12) Prod-даярдык чек тизмеси

• Аныкталган SLIs (availability/latency/quality/freshness) жана сегменттер (route/tenant/region).
• Максаттар (SLO) реалдуу, бизнес менен макулдашылган; бар rolling терезелер 30/90 күн.
• Көп терезелер менен burn rate боюнча алерталар (пейджинг/тикет).
• код катары SLO (эрежелер/dashboard генератор); бюджет боюнча отчеттор.
• Релиздик гейтс бюджеттин калдыгына байланган; Канар кесилиши.
• Деградациянын механизмдери (shedder, cache stale, circuit, лимиттер) ишке ашырылган жана сыналган.
• Корреляция метрика трейдер (exemplars), так runbooks.
• Каржылык/юрисдикция жолдору - өзүнчө SLO/алерталар; PSP/KYC бириктирилген.
• Үзгүлтүксүз retro окуялар жана burn негизделген ишенимдүүлүк салымдар.

13) TL; DR

колдонуучу баалуулугу боюнча SLI аныктоо, реалдуу SLO коюп, көп терезелер менен Error Budget жана бурн rate аркылуу башкаруу. SLO-кодду, релиздерди жана план боюнча деградацияны күйгүзүңүз. Маршруттар/тенанттар/региондор боюнча сегменттештирүү; жолдору үчүн катуу максаттарды жана өзүнчө алерттерди сактаңыз.