KPI infrastruktur və aptaym

Niyə lazımdır

KPI infrastrukturları sabitlik hisslərini ölçülə bilən hədəflərə çevirir, risk və iş fokusunu idarə edir. Düzgün metriklər texniki SLI-ni iş nəticələri ilə əlaqələndirir (konvertasiya, Zaman-to-Wallet, LTV) və inkişaf, yük və inovasiya payı vs etibarlılığı planlaşdırmağa imkan verir.

Əsas anlayışlar: SLI, SLO, SLA və büdcə səhvləri

SLI (Service Level Indicator) - ölçülə bilən keyfiyyət göstəricisi: uğurlu sorğuların payı, p95 latency, interval başına aptaym.
SLO (Service Level Objective) - SLI hədəfi (məsələn, "uğur ≥ 99. 9% 30 gün").
SLA (Agreement) - cərimələr/kreditlər ilə xarici vəd. Həmişə SLO törəməsidir, lakin ona bərabər deyil.
Səhv büdcəsi = '1 − SLO'. Bu, ölçmə pəncərəsi üçün «uğursuzluğun» icazə verilən maksimum payıdır. Riskli buraxılışlar və təcrübələr haqqında qərar vermək üçün istifadə olunur.

• SLO mövcudluğu 99. 95% 30 gün → büdcə səhvləri 0. 05% ≈ 21. Təqvim ayında 6 dəqiqə «uğursuzluq».

Dörd «qızıl» siqnal və əlavə

1. Gecikmə (p50/p90/p95/p99, tail ortalamadan daha vacibdir).
2. Səhvlər (5xx/timeout/biznes səhvləri).
3. Trafik/keçid (RPS/QPS, MBps).
4. Doyma (CPU/RAM/IO/FD/qoşulma/GC/kvota).
Əlavə: soyuq başlanğıc, növbələr/bekloq, deploi vaxtı, SLO-komplayens.

Müxtəlif xidmət növləri üçün SLI modeli

HTTP/API

Əlçatanlıq: '(uğurlu 2xx/3xx − məntiqi səhvlər )/( bütün sorğular)'

Gecikmə: uğurlu sorğular üçün 'p95'; «isti» marşrutlar üzrə hədəf.
Keyfiyyət: «audience/scope» düzgün olan sorğuların payı (authZ səhvləri olmadan).

Növbələr/Asinxron

Post emal vaxtı: p95 end-to-end ≤ N san.
Backlog: mediana <X, quyruq p99 <Y.
Çatdırılma səhvi: ≤ Z ppm.

BD/Cache

Əməliyyatların gizliliyi: p95 get/put/commit.
Doygunluq: connection pool usage, hit-ratio cache.
Səhvlər: timeouts, deadlocks, eviction storms.

CDN/statik

Hit Ratio: hədəf səviyyəsinin ≥; deqradasiya → origin yük artım.
POP mövcudluğu: Anycast-düzəliş, uğursuzluqlar qonşular tərəfindən kompensasiya olunur.

Ödənişlər (biznes-SLI)

Time-to-Wallet p95, depozit/çıxarış% müvəffəqiyyəti, PSP rate uğursuzluqları.

Əlçatanlığın hesablanması və «aptaym»

Xidmətin mövcudluğu = 'uğurlu sorğular/bütün sorğular' (tercihen «aptime dəqiqələri» deyil).
Infrastruktur qovşaqları üçün alternativ: 'yaşıl vaxt/pəncərə vaxtı'.
Təqvim pəncərəsi: 28-31 gün, sürüşmə pəncərəsi: son 30/90 gün.
İş saatları/kritik pəncərələr: backoffice üçün cədvəl üzrə aptime hesab edilə bilər (məsələn, yerli vaxtla 08: 00-22: 00).

• 'Availability (A) ≈ Av (B) × Av (C) × Av (A' B, C) '- sərhədlərdə SLO qoymaq vacibdir.

SLO dəsti nümunəsi (nümunə)

API Gateway: 99 ≥. 95 %/30d; p95 latency ≤ 120 ms; səhv ≤ 0. 2%.
Checkout/Payments: depozitin müvəffəqiyyəti ≥ 98. 5 %/30d; Time-to-Wallet p95 ≤ 90 с; PSP-timeouts ≤ 0. 3%.
Verilənlər bazası: p95 read ≤ 10ms; p95 write ≤ 25 ms; replica lag p95 ≤ 150 мс.
Cache: hit ratio ≥ 85%; eviction storms = 0/30д.
Ödənişlər: p95 emal ≤ 5 dəq; frod fols pozitivləri ≤ 0. 3%.

Səhv büdcəsi və dəyişikliklərin idarə edilməsi

Əgər səhv büdcəsi pəncərənin ortasından + 50% əvvəl tükənirsə - «dondurma» fich/relizlər tətbiq olunur, sabitləşməyə diqqət yetirilir.
Büdcə yavaş xərclənirsə, təcrübələri/kanaryaları sürətləndirə bilərsiniz.
Büdcə istehlakını 'release _ id' vasitəsilə xüsusi buraxılışlar/hadisələrlə əlaqələndirin.

Alerting: «gecə zəng» boş yerə necə

Alertlər yalnız SLO deqradasiyası və həyati əlamətlər üçün, hər metrik üçün deyil.
Multi-window, multi-burn rate: qısa pəncərə (5-15 dəqiqə) + uzun (1-6 saat).
Nümunə: «Burn rate 14 × 5 dəqiqə və 6 × 1 saat» → on-call səhifə.
Qeyri-P1 siqnalları üçün sakit saat; məsuliyyət marşrutu (ownership).

Dashboard və vizualizasiya təcrübələri

SLO paneli: xidmətlərə uyğunluq, qalan büdcə, asılılıq kartları.
Latency paneli: p50/p90/p95/p99, marşrutlar/tenantlar/ölkələr/ASN üzrə parçalanma.
Error paneli: kodlar/səbəblər, relizlər/fitflags ilə korrelyasiya.
Capacity paneli: CPU/RAM/IO/network/FD/konnektlər, trendlər və proqnozlar.
Biznes paneli: konvertasiya, Time-to-Wallet, depozitlər/nəticələr, qorunma təsiri (WAF/antibot).

Hadisələr, MTTR və postmortemlər

• MTTD (aşkarlama), MTTA (akkept), MTTR/MTTC (bərpa/saxlama), RCA olmadan hadisələrin% vaxtında.
• Playbook: kim eskalasiya edir, fichflags/blokları necə açmaq, sərbəst buraxmaq üçün necə, biznes ilə ünsiyyət.
• Postmortem (blameless): faktlar, zaman xətti, əsas səbəblər (tex/proseslər), hərəkətlər: dərhal/uzunmüddətli, reqressiya testləri, SLO-ya təsir.

Performans, doyma və deqradasiya

Headroom: hədəf resurs (məsələn, CPU <70% p95, RAM <75% p95).
Hot paths: kritik marşrutların profilləşdirilməsi; 'p99' ortalamadan daha vacibdir.
Degradation modes: cache yalnız, read-only, drop-taşlama əhəmiyyətsiz sorğular, «limitli bahis «/kvota.

Formullar və hesablama nümunələri

1) Tələblər üzrə mövcudluq

availability = (total_requests - error_requests) / total_requests

harada 'error _ requests' = 5xx + timeouts + biznes səhvləri (xüsusi).

2) Səhv büdcəsi (dəqiqə)

error_budget_minutes = window_minutes (1 - SLO)

Nümunə: 30 gün (43 200 dəq), SLO 99. 95% → 21. 6 dəq.

3) Burn rate

burn_rate = observed_error_ratio / (1 - SLO)

Əgər SLO 99. 9% (büdcə 0. 1%), səhv isə 1% → burn_rate = 10 ×.

4) Kompozit mövcudluq

A_total ≈ A_gw × A_auth × A_db × A_psp

Kiçik enişlər multiplikativ ümumi A. vurur

Ölçmə və istisnalar siyasəti

Planlaşdırılmamış pəncərələr (hadisələr) - nəzərə alınır.
Planlaşdırılmış xidmət pəncərələri - yalnız SLA belə yazılıbsa; SLO üçün çox vaxt çıxılmır (və ya ayrıca 'planned _ downtime' kimi qeyd olunur).
Sintetik vs real istifadəçilər: hər iki kanalın olması faydalıdır (RUM + sintetik yoxlamalar).

Artefaktların nümunələri

KQL/PromQL (fikirlər)

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 (ödənişlər üzrə biznes 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;

Asılılıq və kaskadların idarə edilməsi

Komandalar arasında SLO müqavilələri: gateway, auth, wallet, PSP.
Degradation policies: asılılıq düşdükdə xidmət «sadələşdirilmiş rejimi» keçir.
Feature flags: kritik olmayan funksiyaların bağlanması, latency quyruqlarını azaltmaq üçün «boz reliz».

Capacity Planning və proqnozlar

Schomes. RPS/MBps trendlər və hadisələr (turnirlər, matçlar, promosyonlar) üzrə proqnoz.
«Qızıl yollar» üzrə yükləmə testləri, PSP/ödənişlər üçün fərdi testlər.
Zirvə ehtiyatı: hədəf əmsalı 1. 3×–2. Gözlənilən yükdən 0 ×.

SLO/KPI tətbiq çek siyahısı

1. Kritik istifadəçi yollarını müəyyənləşdirin və «müştərinin nöqteyi-nəzərindən» SLI haqqında razılaşın.
2. SLO hədəfləri və pəncərə seçin (30/90 gün); səhv büdcəsini hesablayın.
3. Metriklərin toplanmasını şlyuzlara/xidmətlərə inteqrasiya edin, kodları/səbəbləri normallaşdırın.
4. burn-rate alert (qısa + uzun pəncərə), marşrutlaşdırma və on-call.
5. SLO uyğunluğunu vizuallaşdırın, relizlər/fitflags ilə əlaqələndirin.
6. «Büdcə dəyişikliyə qarşı» siyasətini və dondurma prosesini başlatın.
7. Retrospektivlər və hər bir həddindən artıq RCA, regressiya testləri.
8. Büdcənin faktiki istifadəsi və biznes məqsədləri üzrə SLO-ların rüblük reviziyası.

Tipik səhvlər

Tətbiq səhvlərinə məhəl qoymadan «ping uptime» ölçün.
SLO «ehtiyatda» sərgilənir (99. 999%), lakin əlçatmazdır və heç nə həll etmir.
Xüsusi simptomlar əvəzinə aşağı səviyyəli metriklərə görə alertlər.
Asılılıq xəritəsi yoxdur → harada yandığı bəlli deyil.
SLO-nun buraxılışlarla əlaqəsi yoxdur → büdcəni kimin «yediyi» bəlli deyil.
Ignor quyruqları p99 → yaxşı orta, lakin pis UX VIP istifadəçilər.

iGaming/Fintech üçün xüsusiyyətlər

Cədvəl üzrə zirvələr: matçlar/tədbirlər/promosyonlar - əvvəlcədən capacity artırmaq, cache/CDN qızdırmaq, xüsusi limit profillərini daxil etmək.
Biznes SLI: Vaxt-to-Wallet, depozit/çıxarış müvəffəqiyyəti, «ödəmə sürəti» p95; daşbordların kökündə.
PSP/partnyorlar: fərdi SLO/dashboard provayderləri, avtomatik marşrut keçid.
Antibot/antifrod: büdcə səhvlərini yeməməlidir - «qanuni blokları» «texniki səhvlərdən» ayırın.
Tənzimləyici: jurnalların saxlanması, SLO/SLA hesabatlarının təkrarlanabilirliyi, insident hesabatları.

FAQ

SLO-dan planlaşdırılan işləri çıxmaq lazımdırmı?
Adətən yox: SLO istifadəçi təcrübəsini əks etdirir. SLA üçün istisnaları qeyd edə bilərsiniz.

Niyə orta deyil, p95?
Orta quyruqları maskalayır; UX quyruqları müəyyən (p95/p99).

Bütün məhsul üçün bir SLO ola bilərmi?
SLO ağacına ehtiyacınız var: məhsulda yığılmış və kritik yollarda/komponentlərdə törəmə.

Yekun

Güclü KPI infrastruktur sistemi xüsusi SLI, real SLO, dəyişiklik idarəetmə qolu kimi səhv büdcəsi, ağıllı alertinq və hadisə intizamı və RCA-dır. Texniki göstəriciləri iş metrləri ilə əlaqələndirin, kolleksiyanı və vizualizasiyanı avtomatlaşdırın - və infrastruktur proqnozlaşdırıla bilər və aptaym hətta pik ssenarilərdə də idarə olunur.