SLA, SLO жана KPI ишенимдүүлүк

1) Терминдер жана айырмачылыктар

SLI (Service Level Indicator) - өлчөнүүчү сапат көрсөткүчү (мисалы, ийгиликтүү суроо-талаптардын үлүшү, p95 жашыруун).
SLO (Service Level Objective) - убакыт терезеси үчүн SLI максаттуу мааниси (мисалы, "ийгилик ≥ 99. 28 күндүн ичинде 9%").
Бюджеттин катасы (Error Budget) - SLO аткарбагандыгынын жол берилген үлүшү: '1 − SLO'.
SLA (Service Level Agreement) - айыптар/кредиттер менен келишимдик милдеттенмелер (тышкы).
KPI ишенимдүүлүгү - жараянынын иш көрсөткүчтөрү (MTTD/MTTA/MTTR/MTBF,% Automatic Mitigate, Alert каптоо ж.б.).

2) SLI тандоо үчүн кантип (Golden Signals негизинде)

1. Latency - негизги EndPoint үчүн p95/p99.
2. Traffic - RPS/RPM/билдирүүлөр агымы.
3. Errors - 5хх/бизнес каталарынын үлүшү (мисалы, төлөм "PSP күнөөсү менен decline" алынып салынсын).
4. Сатурация - ресурстарды каныктыруу (CPU/RAM/IO/lag).

• Колдонуучунун тажрыйбасы менен байланышат (user-perceived).
• Техникалык жактан жеткиликтүү жана туруктуу өлчөө.
• Биз көзөмөлдөйбүз (жакшыртуу үчүн мүмкүн болгон иш-аракеттер).
• Жыйымдын төмөн наркы.

3) Формулалар жана мисалдар

3. 1 Жеткиликтүүлүк (availability)

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) Туура эмес бюджет жана burn-rate

Бюджет катасы - инновациялар үчүн "күйүүчү май танкы" (релиздер, эксперименттер).

• тез канал (1 сааттан ~ детал),
• жай канал (~ тенденциясы 6-12 саат/24 саат).

• Эгерде burn-rate> 14. 1 саатта 4 - SEV-1 (күнүмдүк бюджетти 100 ~ жейбиз).
• Эгерде burn-rate> 6 саат 6 - SEV-2 (тез деградация).

5) SLO боюнча Алертинг (multi-window, multi-burn)

Каталардын көрсөткүчү: 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-шлюз/Edge

SLI-Errors: 5xx жооп үлүшү <0. 1% (28d).
SLI-Latency: p95 ≤ 250 мс (күн).
SLO: Availability ≥ 99. 95% (чейрек).

6. 2 Төлөмдөр

SLI-Success: ийгиликтүү төлөмдөр (кардарлардын баш кошпогондо) ≥ 99. 8% (28d).
SLI-Latency: авторизация ≤ 2 секунд үчүн 99% (күн).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6. 3 Маалымат базалары (PostgreSQL)

SLI-Lag: репликациялык лаг p95 ≤ 1 сек (күн).
SLI-Errors: суроо каталардын үлүшү ≤ 0. 05% (28d).
SLO: кластердин жеткиликтүүлүгү ≥ 99. 95%.

6. 4 кезек/агымы (Kafka)

SLI-Lag: керектөө артта p95 ≤ N билдирүүлөр (саат).
SLI-Туруктуулук: ≥ 99 жазуу ырастоо. 99% (28d).
SLO: жеткиликтүү брокерлер ≥ 99. 9%.

7) KPI ишенимдүүлүк жараяны

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

Автоматтык митигация инциденттеринин%

SLO жабуу/жогорку трафик жолдору (максаттуу ≥ 95%)

Канарейка этабы менен релиздердин үлүшү

Туура эмес бюджетти команда/фич боюнча керектөө

8) SLO реалдуу коюп кантип

1. Учурдагы негизги ишенимдүүлүгүн өлчөө (3-4 жума).
2. "сезимтал" колдонуучу жолдорун аныктоо (логин, депозиттик, оюн).
3. Ар бир девиациянын наркын (убакыт, акча, репутация) эске алыңыз.
4. амбициялуу, бирок жетишүүгө мүмкүн болгон максатты тандаңыз (базага карата 10-30% жакшыртуу).
5. чейрек сайын карап чыгуу.

• Бир эле учурда "беш тогуз" негизсиз.
• Колдонуучуга көрүнбөгөн метриктер боюнча SLO (мисалы, UX менен байланышы жок CPU).
• Өтө көп SLO → Focus чачуу.

9) SLO жана бюджеттер боюнча отчеттуулук

• Ар бир SLO боюнча аткаруу: факт vs максат, тенденциялар, confidence.
• ката керектөө кыскача: канча бюджет "өрттөп", ким (релиз/окуя).
• Деградациянын эң мыкты беш себеби, CAPA планы жана милдеттердин статусу.
• Бизнеске таасири: конверсия, ND, сактоо, LTV.

10) релиз саясаты менен байланыш

Бюджет каталар <50% → эркин релиздер.
50-80% → "этияттык режими": бир гана төмөн-тобокелдик/канарейка эсептөөлөр.

11) SLA (келишимдик) - пункт үлгүлөрү

Жеткиликтүүлүк милдеттенмеси: мисалы, 99. 9 %/ай.
Өзгөчөлүктөр (Force Majeure): DDoS акылга сыярлык көзөмөлдөн тышкары, үчүнчү жактардын провайдерлери.
Өлчөө терезеси жана жоопкерчилик зонасы: метриканын булактары, эсептөө ыкмасы.
Кредиттер/айыптар: деңгээлдер таблицасы (мисалы, жеткиликсиздик 60-120 мин → кредит X%).
Эскалациялоо жана кабарлоо жол-жоболору: мөөнөттөр, каналдар.
Маалыматтар жана купуялык: жашыруу, сактоо, Юридикалык Hold.
Бузуу болгон учурда кайталоону алдын алуу боюнча иш планы (CAPA).

12) Өлчөө аспаптары

Пассивдүү метриктер: Prometheus/Mimir/Thanos, экспорттоочулар.
Logs: Loki/ELK бизнес деъгээлинде ийгиликтерди/каталарды эсептөө үчүн.
Синтетика: cron боюнча активдүү үлгүлөр (логин/депозит/оюн).
Tracking: Tempo/Jaeger үчүн "тар" p99.
Төлөм/каржы: булактары ground truth үчүн төлөм 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 жана ишенимдүүлүк

Cost per 9: "тогуз" кошуу наркы экспоненциалдуу өсүп жатат.
Пайданын ийри сызыгы: кирешенин өсүшү/жоготуулардын азайышы ≥ кошумча "9" наркы болгон жерде оптимум.
SLO портфели: ар кандай жолдор үчүн ар кандай деңгээлдер (критикалык төлөмдөр "кымбатыраак", отчеттуулук "арзан").

15) Сапаты SLO/Алерт - чек тизмеси

• SLI UX жана бизнес-метриктер менен байланыштуу.
• Терезе жана бириктирүү макулдашылган (rolling 28d/чейрек).
• Alerty multi-window, Fapping жок, ролдорду багыттоо менен.
• Документтер: ээси, формула, булактары, runbook.
• Туура эмес бюджет жана бурн индикаторлору менен SLO демо панели.
• Максаттарды үзгүлтүксүз кайра карап чыгуу (чейрек сайын).
• Негизги сценарийлер боюнча синтетикалык тесттер.

16) Ишке ашыруу планы (4 итерация)

1. Апта 1: Колдонуучу жолдорун, SLI долбоорлорун, базалык дашборддорду инвентаризациялоо.
2. Апта 2: SLO, бюджеттерди эсептөө, алерталар (fast/slow burn).
3. Жума 3: окуялар/релиздер менен бириктирүү, freeze эрежелери.
4. Жума 4 +: келишимдик SLA, чейректик ревю, finops-модель "cost per 9".

17) Mini-FAQ

Мен кызмат бир SLO болушу керекпи?
Жакшы 2-3 негизги (ийгилик + жашыруун) ордуна ондогон экинчи даражадагы.

Бюджет түгөнүп калса эмне кылуу керек?
Релиздерди тоңдуруу, турукташтыруу жана CAPAга басым жасоо, эксперименталдык көрүнүштөрдү алып салуу.

Релиздердин ылдамдыгы менен ишенимдүүлүктүн ортосундагы чыр-чатакты кантип болтурбоо керек?
"Бюджет боюнча" релиздерди пландаштырып, канареалык эсептөөлөрдү жана feature-flags киргизиңиз.

Жыйынтык

Ишенимдүүлүк чачыранды метриктердин жыйындысы менен эмес, система менен башкарылат: SLI → SLO → бюджет катасы → burn-alerting → окуя процесси → CAPA → SLA. Аныктамаларды, маалымат булактарын жана отчеттуулукту стандартташтырып, максаттарды колдонуучунун тажрыйбасына жана экономикасына байланыштырып, чыныгы ROIге жараша "тогуздун" деңгээлин үзгүлтүксүз карап чыгыңыз.