KPI инфраструктурасы жана аптайм

Эмне үчүн керек

Инфраструктуралык KPI туруктуулук жөнүндөгү "сезимдерди" өлчөнүүчү максаттарга айландырат, тобокелчиликти жана иштин фокусун башкарат. Туура метриктер техникалык SLI бизнес натыйжалары менен байланыштырат (конверсия, убакыт коштомо, LTV) жана өнүгүүнү, жүктү жана инновациялардын үлүшүн ишенимдүүлүккө каршы пландаштырууга мүмкүндүк берет.

Негизги түшүнүктөр: SLI, SLO, SLA жана бюджет каталар

SLI (Service Level Indicator) - өлчөнүүчү сапат көрсөткүчү: ийгиликтүү суроо-талаптардын үлүшү, p95 latency, интервал сайын аптайм.
SLO (Service Level Objective) - SLI максаты (мисалы, "ийгилик ≥ 99. 9% 30 күн").
SLA (Agreement) - айып/насыялар менен тышкы убада. Ар дайым SLO туунду, бирок ага барабар эмес.
Жаңылыштык бюджети = '1 − SLO'. Бул өлчөө терезеси үчүн "ийгиликсиздиктин" максималдуу жол берилген үлүшү. Ал кооптуу релиздер жана эксперименттер жөнүндө чечим кабыл алуу үчүн колдонулат.

• SLO жеткиликтүүлүгү 99. 95% 30 күн → бюджет каталар 0. 05% ≈ 21. календардык айда "ийгиликсиз" 6 мүнөт.

Төрт "алтын" сигнал жана кошумча

1. Латентность (p50/p90/p95/p99, tail ортоңку караганда маанилүү).
2. Каталар (5xx/убакыт/бизнес каталар).
3. Traffic/өткөрүү (RPS/QPS, MBps).
4. Каныккандык (CPU/RAM/IO/FD/туташуу/GC/квота).
Кошумча: муздак баштоо, кезек/беклог, деплой убактысы, SLO-комплаенс.

ар кандай кызмат түрлөрү үчүн SLI модели

HTTP/API

Жеткиликтүүлүк: '(ийгиликтүү 2xx/3xx − логикалык каталар )/( бардык суроолор)'

Жашыруун: 'p95' ийгиликтүү суроо үчүн; "ысык" каттамдар боюнча максаттуу.
Сапаты: менен суроо үлүшү 'audience/scope' туура (authZ каталар жок).

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

Post иштетүү убактысы: p95 end-to-end ≤ N сек.
Backlog: mediana <X, куйрук p99 <Y.
жеткирүү ката: ≤ Z ppm.

BD/кэш

Операциялардын латенттүүлүгү: p95 get/put/commit.
Каныккандык: connection pool usage, hit-ratio кэш.
Каталар: timeouts, deadlocks, eviction storms.

CDN/Static

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

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

Time-to-Wallet p95, депозиттик/депозиттик ийгилиги%, PSP ката.

Жеткиликтүүлүктү жана "аптайманы" эсептөө

Кызматтын жеткиликтүүлүгү = 'ийгиликтүү суроо-талаптар/бардык суроо-талаптар' (жакшыраак эмес, "аптайм мүнөт").
Инфраструктуралык түйүндөр үчүн альтернатива: 'жашыл "абалдагы убакыт/терезе убактысы'.
календардык терезе: 28-31 күн, жылма терезе: акыркы 30/90 күн.
Жумуш сааттары/маанилүү терезелер: backoffice үчүн график боюнча аптайм деп эсептелиши мүмкүн (мисалы, 08: 00-22: 00 жергиликтүү убакыт).

• 'Availability (A) ≈ Av (B) × Av (C) × Av (A' B, C) '- чек арага SLO салуу маанилүү.

SLO-топтомун мисал (үлгү)

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

Бюджет каталар жана өзгөрүүлөрдү башкаруу

Эгерде каталардын бюджети терезенин ортосуна чейин 50% түгөнүп калса - "тоңдуруу" фич/релиздер киргизилет, турукташтырууга басым жасалат.
Эгерде бюджет жай сарпталса, анда эксперименттерди/канареяларды тездетүүгө болот.
Бюджеттин керектөөсүн конкреттүү релиздер/окуялар менен 'release _ id' аркылуу байланыштырыңыз.

Alerting: кантип "түн чалуу" бекер

Alerta гана SLO-деградация жана маанилүү белгилери, жана ар бир метрика үчүн эмес.
Multi-window, multi-burn rate: кыска терезе (5-15 мин) + узун (1-6 саат).
Мисалы: "Burn rate 14 × 5 мүнөт жана 6 × 1 саат" → on-call бет.
P1 эмес сигналдар үчүн тынч саат; жоопкерчилик багыттоо (ownership).

Dashboard жана визуализация практикасы

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

Окуялар, MTTR жана postmortems

• MTTD (аныктоо), MTTA (accept), MTTR/MTTC (калыбына келтирүү/токтотуу),% RCA жок окуялар убагында.
• Playbook: ким эскалацияланат, кантип fichflags/блокторду күйгүзүү, кантип бошотуу, бизнес менен байланыш.
• Постмортем (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 (идеялар)

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

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

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 жана болжолдоолор

Schomes. тенденциялар жана окуялар боюнча RPS/MBps божомолу (турнирлер, матчтар, акциялар).
"Алтын жолдор" боюнча Load тестирлөө, PSP/төлөмдөр үчүн өзүнчө тесттер.
Туу чокусундагы запас: максаттуу коэффициент 1. 3×–2. 0 × күтүлгөн жүк.

SLO/KPI киргизүү чек тизмеси

1. Маанилүү колдонуучу жолдорун аныктоо жана "кардардын көз карашы боюнча" SLI жөнүндө макулдашуу.
2. SLO максаттарды жана терезени тандоо (30/90 күн); бюджетин эсептеп чыгуу.
3. Метриктердин жыйноосун шлюздарга/кызматтарга киргизүү, коддорду/себептерди нормалдаштыруу.
4. burn-rate алерта (кыска + узун терезе), багыттоо жана on-call.
5. SLO-комплаенс Visualize, Releases/Fichflags менен байланышкан.
6. "Бюджетти өзгөртүүгө каршы" саясатын жана тоңдуруу процессин баштоо.
7. Retrospectives жана ар бир ашыкча RCA, регрессия тесттер.
8. Бюджетти иш жүзүндө пайдалануу жана бизнес максаттары боюнча СЛОну квартал сайын ревизиялоо.

Типтүү каталар

Тиркемелердин каталарына көңүл бурбай, "пинг боюнча аптайм" өлчөйт.
SLO "запастагы" (99. 999%), бирок жеткиликсиз жана эч нерсени чечпейт.
Төмөнкү деңгээлдеги метриктер боюнча алерталар колдонуучунун симптомдорунун ордуна.
Көз карандылык картасы жок → кайда күйүп жатканы белгисиз.
СЛОнун чыгарылышы менен байланышы жок → бюджетти ким "жегени" белгисиз.
Ignor куйруктары p99 → жакшы орто, бирок жаман UX VIP колдонуучулар.

iGaming/Fintech үчүн өзгөчөлүктөрү

График боюнча чокулар: матчтар/иш-чаралар/акциялар - алдын ала capacity жогорулатуу, кэш/CDN жылытуу, атайын лимит профилдерин киргизүү.
Бизнес-SLI: Time-to-Wallet, депозиттин/чыгаруунун ийгилиги, "төлөм ылдамдыгы" p95; дашборддордун тамырында.
PSP/өнөктөштөр: жеке SLO/dashboard жөнөтүүчүлөр, автоматтык которуу жолдору.
Antibot/антифрод: каталар бюджетти жебеши керек - "мыйзамдуу блокторду" "техникалык каталардан" бөлүңүз.
Жөнгө салуучу: журналдарды сактоо, SLO/SLA эсептөөлөрүн кайталоо, инциденттер боюнча отчеттор.

FAQ

СЛОдон пландуу иштерди алып салуу керекпи?
Адатта жок: SLO колдонуучунун тажрыйбасын чагылдырат. SLA үчүн өзгөчөлүктөр каралышы мүмкүн.

Эмне үчүн p95 эмес, орточо?
Орто куйруктарын жашыруу; UX куйруктарын аныктоо (p95/p99).

Бүт продукт үчүн бир SLO болушу мүмкүнбү?
SLO жыгач керек: продукт боюнча агрегаттык жана маанилүү жолдор/компоненттер боюнча туунду.

Жыйынтык

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