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,% автоматты митигейттер, алерттермен жабу және т.б.).

2) SLI қалай таңдауға болады (Golden Signals базасында)

1. Latency - негізгі эндпоинттер үшін p95/p99.
2. Traffic - RPS/RPM/хабар ағыны.
3. Errors - 5хх/бизнес қателер үлесі (мысалы, «PSP кінәсі бойынша decline» төлем үлесі алынып тасталсын).
4. Saturation - ресурстарды қанықтыру (CPU/RAM/IO/lag).

• Пайдаланушы тәжірибесімен байланыстырады (user-perceived).
• Техникалық жағынан қолжетімді және өлшеуде тұрақты.
• Бақылаймыз (жақсарту үшін әрекеттер болуы мүмкін).
• Алымның төмен құны.

3) Формулалар мен мысалдар

3. 1 Қол жетімділік (availability)

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

Мысалы: SLO 99. 30 күнде 9% → қателер бюджеті = 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-Durability: жазбаны растау ≥ 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 → фокусты шашу.

9) SLO және бюджеттер бойынша есептілік

• Әрбір SLO бойынша орындау: факт vs мақсат, трендтер, confidence.
• Қателерді тұтыну жиынтығы: қанша бюджетті «өртеген», кем (релиз/инцидент).
• Тозудың бес себебі, CAPA-жоспар және міндеттердің мәртебесі.
• Бизнеске әсері: конверсия, ND, ұстап қалу, LTV.

10) Релиздік саясатпен байланыс

Қателер бюджеті <50% → бос релиздер.
50-80% → «сақтық режимі»: тек low-risk/канареялық есептеулер.

11) SLA (шарттық) - тармақтардың үлгілері

Қолжетімділік міндеттемесі: мысалы, 99. 9 %/ай.
Ерекшеліктер (Force Majeure): DDoS ақылға қонымды бақылаудан тыс, үшінші тараптың провайдерлері.
Өлшеу терезесі және жауапкершілік аймағы: метрика көздері, есептеу әдісі.
Кредиттер/айыппұлдар: деңгейлер кестесі (мысалы, қолжетімсіздік 60-120 мин → кредит X%).
Эскалация және хабарламалар рәсімдері: мерзімдері, арналары.
Деректер және құпиялылық: бүркемелеу, сақтау, Legal Hold.
Бұзушылық жағдайында қайталануды болдырмау жөніндегі жұмыстар жоспары (CAPA).

12) Өлшеу құралдары

Пассивті метриктер: Prometheus/Mimir/Thanos, экспорттаушылар.
Логи: Бизнес деңгейіндегі жетістіктерді/қателерді есептеу үшін Loki/ELK.
Синтетика: cron бойынша белсенді сынамалар (логин/депозит/ойын).
Трассировка: p99 «тар орындар» үшін Tempo/Jaeger.
Төлем/қаржы: SLI төлеміне арналған ground truth көздері.

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) ФинОпс және сенімділік

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

15) SLO/алерт сапасы - чек парағы

• SLI UX және бизнес-метрикалармен байланысты.
• Терезе мен біріктіру келісілген (rolling 28d/тоқсан).
• Көп терезе алерті, флаппингсіз, рөлдік маршрутизациясы бар.
• Құжаттама: иесі, формуласы, көздері, runbook.
• Қате бюджеті және burn индикаторлары бар SLO демо-панелі.
• Мақсаттарды тұрақты қайта қарау (тоқсан сайын).
• Негізгі сценарийлер бойынша синтетика тестілері.

16) Енгізу жоспары (4 итерация)

1. 1-апта: пайдаланушы жолдарын түгендеу, SLI жобалары, базалық дашбордтар.
2. 2-апта: SLO-ны ресімдеу, бюджеттерді есептеу, алерта (fast/slow burn).
3. 3-апта: оқиғалар/релиздер процесімен интеграция, freeze-ережелер.
4. 4 + аптасы: шартты SLA, тоқсандық ревю, «cost per 9» финопс-моделі.

17) Шағын FAQ

Сервисте бір SLO болу керек пе?
Ондаған екінші дәрежелі емес, 2-3 кілттен жақсы (табыс + жасырындылық).

Егер бюджет таусылса не істеу керек?
Релиздерді мұздату, тұрақтандыруға және CAPA-ға назар аудару, эксперименттік фичтерді алу.

Релиздер жылдамдығы мен сенімділік арасындағы қайшылықты қалай болдырмауға болады?
«Бюджет бойынша» релиздерді жоспарлаңыз, канареялық есептер мен feature-flags енгізіңіз.

Жиынтық

Сенімділік шашыраңқы метриктер жиынтығымен емес, жүйемен басқарылады: SLI → SLO → бюджет қатесі → burn-alerting → инциденттер процесі → CAPA → SLA. Анықтамаларды, деректер көздерін және есептілікті стандарттаңыз, мақсаттарды пайдаланушы тәжірибесі мен экономикаға байланыстыңыз және нақты ROI-ге байланысты «тоғыз» деңгейін үнемі қайта қараңыз.