KPI инфрақұрылым және аптайм

Бұл не үшін қажет

Инфрақұрылым KPI тұрақтылық туралы «сезімді» өлшенетін мақсаттарға айналдырады, тәуекелді және жұмыс фокусын басқарады. Дұрыс метриктер техникалық SLI-ді бизнес-нәтижелермен (конверсия, Time-to-Wallet, LTV) байланыстырады және дамуды, жүктемені және инновациялардың үлесін vs сенімділікті жоспарлауға мүмкіндік береді.

Негізгі ұғымдар: SLI, SLO, SLA және қателер бюджеті

SLI (Service Level Indicator) - өлшенетін сапа көрсеткіші: сәтті сұраныстардың үлесі, p95 latency, бір интервал үшін аптайм.
SLO (Service Level Objective) - SLI бойынша мақсат (мысалы, "табыс ≥ 99. 30 күнде 9%").
SLA (Agreement) - тұрақсыздық айыбы/кредиттері бар сыртқы уәде. Әрқашан SLO туындысы, бірақ оған тең емес.
Қателер бюджеті = '1 − SLO'. Бұл өлшеу терезесі үшін «сәтсіздіктің» барынша рұқсат етілген үлесі. Тәуекелді релиздер мен эксперименттер туралы шешім қабылдау үшін пайдаланылады.

Мысал:

SLO қол жетімділігі 99. 30 күнде 95% → бюджет қателері 0. 05% ≈ 21. күнтізбелік айда 6 минут «сәтсіздік».

Төрт «алтын» сигнал және қосымша

1. Жасырындылық (p50/p90/p95/p99, tail орташадан маңызды).
2. Қателер (5xx/timeout/бизнес қателері).
3. Трафик/өткізу (RPS/QPS, MBps).
4. Қанықтыру (CPU/RAM/IO/FD/қосылу/GC/квота).
Қосымша: суық старт, кезек/беклог, деплой уақыты, SLO-комплаенс.

Әртүрлі қызмет түрлеріне арналған SLI моделі

HTTP/API

Қол жетімділік: '(сәтті 2xx/3xx − логикалық қателер )/( барлық сұраулар)'

Жасырындылығы: сәтті сұрау үшін 'p95'; «ыстық» маршруттар бойынша мақсат.
Сапасы: 'audience/scope' дұрыс сұрау үлесі (authZ қателерінсіз).

Кезек/асинхрон

Хабарды өңдеу уақыты: p95 end-to-end ≤ N сек.
Backlog: медиана <X, p99 құйрығы <Y.
Жеткізу қатесі: ≤ Z ppm.

ДБ/кэш

Операцияның жасырындылығы: p95 get/put/commit.
Қанықтыру: connection pool usage, hit-ratio кэш.
Қателер: timeouts, deadlocks, eviction storms.

CDN/статик

Hit Ratio: нысаналы деңгейді ≥; деградация → origin жүктемесінің өсуі.
POP қолжетімділігі: Anycast-орналастыру, істен шығулар көршілермен өтеледі.

Төлемдер (бизнес-SLI)

Time-to-Wallet p95, депозиттің табыстылығы/%, PSP бас тартуларының rate.

Қолжетімділік және «аптайма» есебі

Сервистің қолжетімділігі = 'сәтті сұраулар/барлық сұраулар' («аптайм минуттары» емес, дұрыс).
Инфрақұрылымдық тораптар үшін балама: 'жасыл "күйіндегі уақыт/терезе уақыты'.
Күнтізбелік терезе: 28-31 күн, жылжымалы терезе: соңғы 30/90 күн.
Жұмыс сағаттары/сындарлы терезелер: backoffice үшін кесте бойынша аптайм болып есептелуі мүмкін (мысалы, жергілікті уақыт бойынша 08: 00-22: 00).

Тәуелділік композициясы (жеңілдетілген): Егер А сервисі B және C тәуелді болса, тәуелсіз істен шығу кезінде:

'Availability (A) ≈ Av (B) × Av (C) × Av (A' B, C) '- шекараларда SLO салу маңызды.

SLO-жиынтық үлгісі (үлгі)

API Gateway: қол жетімділік ≥ 99. 95 %/30д; p95 latency ≤ 120 мс; 0 ≤ қатесі. 2%.
Checkout/Payments: депозиттің табысы ≥ 98. 5 %/30д; Time-to-Wallet p95 ≤ 90 с; PSP-timeouts ≤ 0. 3%.
Дерекқор: p95 read ≤ 10 мс; p95 write ≤ 25 мс; replica lag p95 ≤ 150 мс.
Кэш: hit ratio ≥ 85%; eviction storms = 0/30д.
Төлемдер: p95 өңдеу ≤ 5 мин; фрод-фолс-позитивтер ≤ 0. 3%.

Қателер бюджеті және өзгерістерді басқару

Егер қателер бюджеті терезенің ортасынан 50% + ерте таусылса - фич/релиздерді «мұздату» енгізіледі, тұрақтандыруға назар аударылады.
Егер бюджет баяу жұмсалатын болса, эксперименттерді/канареяларды тездетуге болады.
Бюджетті тұтынуды нақты релиздермен/инциденттермен 'release _ id' арқылы байланыстырыңыз.

Алертинг: «түнде қоңырау шалудың» қажеті жоқ

Алерталар тек SLO-деградация және өмірлік маңызды симптомдар бойынша, әр метрика бойынша емес.
Multi-window, multi-burn rate: қысқа терезе (5-15 мин) + ұзын (1-6 сағ).
Мысал: «Burn rate 14 × 5 минутта және 6 × 1 сағатта» → on-call.
P1 емес сигналдар үшін тыныш сағаттар; жауапкершілік бойынша бағыттау (ownership).

Дашбордтар және визуализация практикасы

SLO-панель: сервистер бойынша комплаенс, қалған бюджет, тәуелділік карталары.
Latency панелі: p50/p90/p95/p99, маршруттар/тенанттар/елдер/ASN бойынша ыдырау.
Error панелі: кодтар/себептер, релиздермен/фичфлагтармен корреляция.
Capacity панелі: CPU/RAM/IO/нетворк/FD/коннектілер, трендтер және болжамдар кесіндісі.
Бизнес-панель: конверсия, Time-to-Wallet, депозиттер/қорытындылар, қорғау әсері (WAF/антибот).

Оқиғалар, MTTR және постмортемалар

KPI реакциясы:

MTTD (анықтау), MTTA (аккепт), MTTR/MTTC (қалпына келтіру/тежеу), мерзімінде RCA-сыз оқыс оқиғалардың%.
Плейбуктер: кім эскалацияланады, фичфлагтарды/блоктарды қалай қосу керек, релизді қалай сырғыту керек, бизнеспен байланыс.
Постмортем (blameless): фактілер, уақыт сызығы, бастапқы себептер (тех/процестер), әрекеттер: шұғыл/ұзақ мерзімді, регрессия тестілері, SLO-ға әсері.

Өнімділік, қанығу және тозу

Headroom: ресурстардың мақсатты қоры (мысалы, CPU <70% p95, RAM <75% p95).
Hot paths: маңызды бағыттарды профильдеу; 'p99' орташадан гөрі маңызды.
Degradation modes: кэш-тек, read-only, маңызды емес сұрауларды drop-тегістеу, «ставкаларды шектеу «/квота.

Есептеу формулалары мен мысалдары

1) Сұрау салу бойынша қолжетімділік


availability = (total_requests - error_requests) / total_requests

мұнда 'error _ requests' = 5xx + timeouts + бизнес қателері (теңшеледі).

2) Қателер бюджеті (минут)


error_budget_minutes = window_minutes (1 - SLO)

Мысал: 30 күн (43 200 мин), SLO 99. 95% → 21. 6 мин.

3) Burn rate


burn_rate = observed_error_ratio / (1 - SLO)

Егер SLO 99. 9% (бюджет 0. 1%), ал қате 1% → burn_rate = 10 ×.

4) Құрамдас қолжетімділік


A_total ≈ A_gw × A_auth × A_db × A_psp

Кішігірім құлдыраулар жалпы A.

Өлшеу және алып тастау саясаты

Жоспардан тыс терезелер (инциденттер) есепке алынады.
Қызмет көрсетудің жоспарлы терезелері - егер SLA осылай жазылса ғана ескеріледі; SLO үшін көбінесе шегерілмейді (немесе 'planned _ downtime' деп жеке белгіленеді).
Синтетика vs нақты пайдаланушылар: екі арнаның болуы пайдалы (RUM + синтетикалық тексерулер).

Артефактілердің мысалдары

KQL/PromQL (идеялар)

5 минут ішінде SLI (5xx + timeouts) қатесі:

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

p95 latency по route:

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

Burn rate 5m/1h:

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (төлемдер бойынша бизнес-SLI)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Тәуелділіктер мен каскадтарды басқару

Командалар арасындағы SLO келісімшарттары: gateway, auth, wallet, PSP.
Degradation policies: тәуелділік төмендеген кезде сервис «оңайлатылған режимге» ауысады.
Feature flags: критикалық емес функцияларды ажырату, latency қалдықтарын төмендету үшін «сұр шығарылым».

Capacity Planning және болжамдар

Щомес. трендтер мен оқиғалар бойынша RPS/MBps болжамы (турнирлер, матчтар, акциялар).
«Алтын жолдар» бойынша load testing, PSP/төлемдер үшін жеке тесттер.
Шыңдағы қор: нысаналы коэффициент 1. 3×–2. 0 × күтілетін жүктемеден.

SLO/KPI енгізу парағы

1. Қатер шегіндегі пайдаланушы жолдарын анықтау және «клиент тұрғысынан» SLI туралы келісу.
2. SLO мақсаттарын және терезені таңдау (30/90 күн); қателер бюджетін есептеу.
3. Метриктер жинағын шлюздерге/сервистерге кіріктіру, кодтарды/себептерді қалыпқа келтіру.
4. burn-rate (қысқа + ұзын терезе), бағыттау және on-call күйін келтіру.
5. SLO-комплаенсті визуализациялау, релиздермен/фичфлагтармен байланыстыру.
6. «Бюджет өзгерістерге қарсы» саясатын және қатыру процесін бастау.
7. Әрбір арту бойынша ретроспективалар мен RCA, регрессия тестілері.
8. Тоқсан сайын SLO-ны бюджеттің іс жүзінде пайдаланылуы және бизнес-мақсаттар бойынша тексеру.

Типтік қателер

Қосымшалардың қателерін елемей, «пинг бойынша аптайм» өлшейді.
SLO «қор бойынша» қойылған (99. 999%), бірақ қол жеткізілмейді және ештеңені шешпейді.
Пайдаланушы симптомдарының орнына төмен деңгейлі метриктер бойынша аллергиялар.
Тәуелділік картасы жоқ → қайда жанатыны түсініксіз.
SLO-ның шығарылымдармен байланысы жоқ → бюджетті кім «жегені» белгісіз.
p99 → жақсы орташа, бірақ нашар UX VIP пайдаланушылар.

iGaming/финтех ерекшелігі

Кесте бойынша шыңдар: матчтар/ивенттер/акциялар - capacity алдын ала арттыру, кэш/CDN жылыту, лимиттердің ерекше профильдерін қосу.
Бизнес-SLI: Time-to-Wallet, депозит/шығарудың табыстылығы, «төлем жылдамдығы» p95; дашбордтардың түбінде.
PSP/серіктестер: провайдерлер бойынша жеке SLO/дашбордтар, маршруттарды автоматты түрде ауыстырып қосу.
Антибот/антифрод: бюджет қателіктерді жемеуі тиіс - «заңды блоктарды» «техникалық қателерден» бөліңіз.
Реттеуіш: журналдарды сақтау, SLO/SLA есептеулерінің жаңғыртылуы, инциденттер бойынша есептер.

FAQ

SLO-дан жоспарлы жұмыстарды шегеру керек пе?
Әдетте жоқ: SLO пайдаланушының тәжірибесін көрсетеді. SLA үшін ерекшеліктерді ескертуге болады.

Неге орташа емес, p95?
Орташа құйрықтарын бүркемелейді; UX қалдықтарды анықтайды (p95/p99).

Бүкіл өнімге бір SLO бола ма?
SLO ағашы қажет: өнім бойынша агрегаттық және күрделі жолдар/компоненттер бойынша еншілес.

Жиынтығы

Күшті инфрақұрылым KPI жүйесі - бұл пайдаланушы SLI, шынайы SLO, өзгерістерді басқару тетігі ретінде қателер бюджеті, ақылды алертинг және инцидент тәртібі және RCA. Техникалық көрсеткіштерді бизнес-метрикалармен байланыстырып, жинау мен визуализацияны автоматтандырыңыз - инфрақұрылым болжамды болады, ал аппайм тіпті ең жоғары сценарийлерде де бақыланады.