Error Budgets және SLO басқару

1) Неліктен SLO және бюджет қателері

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

2) SLI таңдау: «жақсы» деп не санау керек

Критерий: «пайдаланушы тұрғысынан табысты».

2. 1 Классикалық SLI

Availability: сәтті сұраулардың үлесі (клиенттің күшін жойғандарын қоспағанда).
'success = http_status ∈ {2xx, 3xx, 404} және таймаусыз' (404, егер бұл күтілетін семантика болса, read API үшін табысты болып саналады).
Latency: сұрау салулардың үлесі табалдырықтан жылдам (мысалы, p95 ≤ 300 мс).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness: «Х минуттан аспайтын деректер» (кэш, каталогтар, коэффициенттер).
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. 30 күн ішіндегі қолжетімділіктің 9% → бюджет = 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) Burn rate (multi-window, multi-burn) бойынша алерттар

5. 1 Идея

Бюджеттің мақсатқа қатысты қаншалықты тез жанып жатқанын қараймыз. Егер жылдамдық қысқа және ұзын терезеде жоғары болса - белгі береміз.

5. 2 Шекті профильдер (SLO үшін 99. 9%)

Пейджинг: burn rate ≥ 14. 4 × (1 сағат үшін бюджеттің 10% -ы және 6 сағат үшін 5% -ы).
Тегі: burn rate ≥ 6 × (6 сағат ішінде 2% және 24 сағат ішінде 1%).

5. 3 Ереже үлгісі (Prometheus, жалған)

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. 2 Беклогтың басымдығы

Команда сыйымдылығын жану жылдамдығына және түсімге әсеріне пропорционалды бөліңіз.
Техникалық борышты метрикалармен негіздеңіз: «X фикс burn rate-ды Y% -ға төмендетеді».

6. 3 Оқыс оқиғадан кейінгі

Әрбір оқиға - RCA және «кері қарай алмайтын фикс» (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: бэкендерді қорғайды; маңызды бағыттар - басымдық.
Circuit/Timeout: жылдам таймауттар және «fallback» тармақтары.
Feature flags: бір батырмамен ауыр сызықтарды ажырату.

9) SLO үшін бақылау

Дашбордтар: SLO actual vs target, бюджет қалдығы, burn rate, маршруттар/провайдерлер бойынша салым.
Корреляция: «тесіктен» SLO → exemplar → нақты trace → логи/профайлдар.
Есептер: апта сайын - трендтер, бюджетті тұтыну, тозудың топ-себептері.

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

Барлық → үшін бір «жаһандық» SLO проблемаларды бүркемелейді. Сегменттеу.
«99. 99% барлық" құн мен нақтылықты есептемегенде. Пайдаланушы тәжірибесінен мақсаттарды таңдаңыз.
burn rate/SLO орнына CPU/heap бойынша алерттар.
UX-ті бұзатын 4хх/ұзын редакторларды елемеу.
Мөлдір емес терезе (rolling vs күнтізбелік) - «алмаларды апельсиндермен» салыстыру.

11) iGaming/Қаржы ерекшелігі

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

12) Prod-дайындық чек-парағы

• SLIs (availability/latency/quality/freshness) және сегменттер (route/tenant/region) анықталды.
• Мақсаттар (SLO) шынайы, бизнеспен келісілген; rolling терезе бар 30/90 күн.
• Көп терезелі burn rate бойынша алерттар (пейджинг/тикет).
• SLO код ретінде (ережелер/дашбордтар генераторы); бюджет бойынша есептер.
• Релиздік гейттер бюджет қалдығына байланған; канареялық кесінділер.
• Тозу тетіктері (shedder, cache stale, circuit, лимиттер) іске асырылды және сынақтан өткізілді.
• Метрикалық Trace (exemplars) корреляциясы, нақты runbooks.
• Қаржылық/юрисдикциялық жолдар - жеке SLO/алерталар; PSP/KYC ірілендірілген.
• Инциденттер бойынша тұрақты ретро және burn негізделген сенімділікке инвестициялар.

13) TL; DR

Пайдаланушылық құндылығы бойынша SLI-ді анықтаңыз, шынайы SLO-ларды орнатыңыз және басқаруды Error Budget және burn rate арқылы көп терезелермен жүргізіңіз. SLO-кодты, релиздік гейттерді және жоспар бойынша тозуды қосыңыз. Маршруттар/тенанттар/өңірлер бойынша сегменттеңіз; ақша жолдары үшін әлдеқайда қатаң мақсаттар мен жекелеген алаңдарды ұстаңыз.