Əməliyyatlar və İdarəetmə → Metrik audit və SLA

Metrik və SLA auditi

1) Niyə lazımdır

Metriklər səhv olarsa, qərarlar səhv olacaq, SLA «kağız üzərində» pozulacaq və ya əksinə problemləri gizlədir. Metrik və SLA auditi istifadəçilər və tərəfdaşlar qarşısında vədlərin müqayisəli, etibarlı və qanuni qorunmasını təmin edir.

• Vahid «həqiqət mənbəyi» (SSOT) və təkrar hesablamalar təmin edin.
• Dashboard/hesabatlar/billing arasındakı fərqləri azaltın.
• SLA-nı mümkün və yoxlanıla bilən etmək (evidence-based).
• Ölçülərdə deqradasiyanı müəyyən etmək xidmətlərdə olduğu kimi tezdir.

2) Məsuliyyətin əsas anlayışları və sərhədləri

Metrik (metrika): ölçülən kəmiyyət (RPS, p95, CR, GGR, Success Rate).
KPI/OKR: Metriklərin bağlı olduğu hədəflər.
SLO: məqsədli xidmət keyfiyyəti (məsələn, "p99 ≤ 400 ms 99. 9% vaxt").
SLA: xarici vəd; hüquqi əhəmiyyətli, SLO əsaslanır.
OLA: komandalar/satıcılar arasında daxili müqavilə, SLA dəstəkləyir.
SSOT: məlumatları hesabatlar üçün istinad hesab olunan sistem/saxlama.

3) Metriklərin taksonomiyası (laylar)

1. Infrastruktur: CPU/Memory/IO/Net, pod/node, HPA/VPA.
2. Platforma: növbələr/axınlar (lag, throughput), BD/caches (konnektlər, hit), API (p95/p99, 5xx).
3. Biznes axınları: depozitlər/çıxışlar, dərəcələr, oyunların başlaması, avtorizasiya, KYC.
4. Məhsul/marketinq: dönüşüm, ARPPU/LTV, kampaniyalar.
5. Proseslərin keyfiyyəti: MTTA/MTTR, Change Failure Rate, çek vərəqlərini əhatə edir.

Qayda: Hər metrika bir təbəqə, sahibi və düsturu olmalıdır.

4) Məlumat mənbələri və «həqiqət»

Onlayn teleemetriya: Prometheus/OTel, loqlar (ELK/ClickHouse), izlər.
Hadisələr və mühasibat: Kafka/Outbox, DWH/Date-mart (BigQuery/ClickHouse).
Əl əsərləri: postmortemlər, biletlər, insidentlərin reyestrləri.
Xarici reyestrlər: provayderlərin hesabatları (PSP/KYC/studiyalar), billing.

Münaqişənin həlli: «onlayn vs DWH» uyğunsuzluqları zamanı prioritet tənzimləmə qüvvədədir (məsələn, SLA üçün - mənbə izləmə qabiliyyətinə malik DWH-dən olan aqreqatlar).

5) Metrik audit prosesi (idarəetmə konturu)

1. Inventarizasiya: metrik kataloq/SLO/SLA (adı, sahibi, təbəqə, formula, mənbə, hesablama tezliyi).
2. Formulların yoxlanılması: SQL/promosyon sorğularının tərifi ilə yoxlanılması (vahid hesablama testləri).
3. Sampling və yenidən yoxlama: hadisə/log sətir nümunələri və əl ilə yoxlama.
4. Konturların müqayisəsi: onlayn dashboard və DWH hesabatlarının müqayisəsi.
5. Dəyişikliklərə nəzarət: sxemlərin/məntiqin buraxılması zamanı formulların review.
6. SLA auditi: montaj və istisnaların düzgünlüyünün yoxlanılması (planned maintenance, fors-major).
7. Hesabat və təkmilləşdirmələr: aşkar edilmiş uyğunsuzluqların və müddətli fikslərin siyahısı.

6) Təriflər və düsturlar (nümunələr)

• `success = requests - (5xx + timeouts + circuit_open)`
• `success_rate = success / requests`

• SSOT vahid pəncərə (5m/1h rolling) və aqreqasiya (HDR/TDigest) müəyyən edir.

• 'SLO _ availability _ month = (iş vaxtı - icazə verilən _ istisnalar )/ümumi _ vaxt'

• `SLA_month = 99. Planlı pəncərələr (90% bildiriş), tranzit operatorlarında sübuta yetirilən qəzalar (sənədlər) istisna olmaqla, UTC pəncərəsi ilə aptaym T-48. '

7) Məlumat keyfiyyəti: yoxlamalar və risklər

• Полнота (completeness): `received_events / expected_events ≥ 0. 99`.
• Vaxtında (timeliness): yükləmə gecikməsi ≤ N dəqiqə.
• Uniqueness: düymələr olmadan (idempotency-key).
• Uyğunluq (consistency): məbləğlər/valyuta/işarələr.
• Lineer (monotonicity): sayğaclar «yuvarlanmır».

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) SLA/OLA auditi: metodika

1. İstisna təqvimini toplayın: planlaşdırılmış pəncərələr, razılaşdırılmış deqradasiyalar, satıcıların aktları.
2. Aptaym hesablanması: SSOT-a əsaslanan vahid vaxt zonası üzrə.
3. Hadisələrlə müqayisə: time line, biletlər, postmortemlər.
4. Atributlar: öz nasazlıqlar, provayder, tranzit, DDoS, tənzimləmə işləri.
5. SLA perimetri: istifadəçi təcrübəsi (E2E) vs bir xüsusi API.
6. Hesabat: ay/rüb üzrə hesabat: fakt, sapmalar, kompensasiyalar (mümkünsə), düzəliş tədbirləri.

9) Hesablamaların təkrarlanabilirliyinin yoxlanılması

Formulların versiyalaşdırılması: SQL/PromQL/Dock Specifications ilə Git-Repository.
Vahid metrik testlər: synthetic data (edge-cases: pass, dubley, tarix sərhədləri).
Data lineage: dashboard geri orijinal cədvəllər və hadisələr.
Snapshot: yenidən hesablamaları müqayisə etmək üçün kəsmə məlumatlarını dondurun.

10) Nəzarət nümunələri (sampling)

Gündəlik: Əsas axınlar üzrə 10-20 hadisə (depozit/bahis/KUS) - DWH izinin əl ilə yoxlanılması.
Həftəlik: 1% yığımlar üzrə «online vs DWH» müqayisə üçün sampl.
Aylıq: SLA effekti hadisələrinin dəsti - ətraflı yenidənqurma.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Daşbordların və xəbərdarlıqların auditi

Vahid metrik lüğət: lüğət birbaşa daşbordda.
Relizlərin/tədbirlərin şərhləri: sapmaların səbəbini görmək.
«Buraxılışdan əvvəl/sonra» müqayisə: avtomatik reqressiya panelləri.
Dubli/uyğunsuzluqlar: «iki fərqli p99» - düsturların/pəncərələrin düzəldilməsi.
Panellərin mövcudluğu: hüquqlar, ehtiyat, link/versiya nəzarəti.

12) Metrik dəyişikliklərin idarə edilməsi

RFC prosesi: formula/pəncərə/mənbə dəyişikliyi - SLA/hesabatlara təsir qiymətləndirilməsi ilə RFC vasitəsilə.
«expand → migrate → contract» miqrasiyası: müvəqqəti olaraq hər iki versiyanı aparırıq, müqayisə edirik, sonra köhnəsini söndürürük.
Rabitə: məhsul/biznesi «yeni metodologiyaya uyğun» qiymətlərin dəyişməsi barədə əvvəlcədən xəbərdar edin.

13) iGaming/Fintech xüsusiyyətləri

Tələbin zirvələri: metrlər partlayıcı yüklərə dözməlidir (aqreqasiyalar «yapışmır»).
Provayderlər: SLA OLA satıcılarından asılıdır → onların hesabatlarını, hadisə statuslarını və kvotalarını saxlayın.
Qiymət: 'cost _ per _ 1k _ calls' və «uğur dəyəri» - məcburi panellər.
Antifrod/risk: gecikmələrə və metriklərin «yanlış işləməsinə» həssaslıq.

14) Dashboard audit (minimum dəsti)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence: hesablanmış SLO, faktiki SLA, istisnalar, hadisələrə/aktlara istinadlar.
Online vs DWH Compare: p95/p99/Success Rate, sapmalar və trendlər.
Vendor SLA: uptime/kvotalar/time-auts/provayderlər baxımından dəyəri.
Release Impact: reqressiya metrik/fich daxil sonra.

15) Audit yoxlama siyahısı (əməliyyat)

• Sahibləri və düsturları olan metrik/SLO/SLA kataloqu aktualdır.
• SSOT hər hesabat/panel üçün müəyyən edilmişdir.
• Vahid düstur testləri yaşıl, hesablamalar paylayıcıları sənədləşdirilmişdir.
• Məlumatların keyfiyyətinə görə risklər aktivdir (completeness/timeliness/duplicates).
• «Online vs DWH» ≤ icazə həddi uyğunsuzluqları (məsələn, ≤ 2%).
• Razılaşdırılmış SLA istisnaları sənədləşdirilmiş və hesabata əlavə edilmişdir.
• Nəzarət nümunələri aparılıb və aktlar tərtib edilib.
• Bütün düstur dəyişiklikləri RFC və miqrasiya keçdi.

16) Nümunələr (fraqmentlər)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) Anti-nümunələr

Müxtəlif panellərdə «bir» metrikanın iki fərqli düsturu.
Miqrasiyasız metrikanın dəyişdirilməsi - OKR/SLA-da «sıçrayışlar».
Yerli Excel hesabatları «həqiqət» kimi (bərpa olunmur).
SLA hesablamalarında saat zonaları və təqvimlərin qarışdırılması.
SLA istisnaları sənədləşdirilmir.
Ölçmə keyfiyyətinə dair heç bir alert yoxdur.

18) KPI yetkinlik ölçü

DWH Online Drift Rate (hədəf ≤ 2%).
Metrics Health Uptime (ingest/ETL deqradasiyasız vaxt).
Time-to-Fix Formula (formula səhvinin aradan qaldırılması vaxtı).
SLA Dispute Rate (tərəfdaşlarla mübahisəli halların tezliyi).
Coverage SLO/SLA (rəsmi olaraq təsvir edilmiş SLO/SLA ilə kritik yolların payı).

19) Rollar və məsuliyyət

Metrika/xidmət sahibi: formula, mənbə, daşbord, alertlər.
Observability/SRE: SSOT/platforma, düstur testləri, məlumatların keyfiyyəti.
Data/BI: DWH, hesabatların təkrarlanabilirliyi, lineage.
Hüquqşünaslar/tərəfdaş menecerlər: SLA razılaşmaları və istisnaları.
Hadisə meneceri: SLA ilə hadisələrin atributu və birləşməsi.

20) Sürətli başlanğıc (30 gün)

Həftə 1: metrik/SLO/SLA və sahiblərinin inventarlaşdırılması; SSOT təyin edin.
Həftə 2: Məlumat keyfiyyəti və «Online vs DWH» panelini aktivləşdirin.
Həftə 3: nəzarət nümunələri keçirmək, p95/p99 pəncərəsini bərabərləşdirmək.
Həftə 4: Formulalar üçün RFC prosesini rəsmiləşdirin, tətbiqlərlə aylıq SLA hesabatını hazırlayın.

21) FAQ

Q: SLA üçün SSOT saymaq nədir?
A: Reproduktiv hesablamalar (DWH) və tam lineage ilə saxlama; onlayn panellər - hüquqi aktlar üçün deyil, operativ nəzarət üçün.

Q: «iki p99» ilə necə mübarizə aparmaq olar?
A: Metrik kataloqunda pəncərə/aqreqasiya üsulunu düzəltmək, panelləri miqrasiya etmək, sürüklənməyə alert əlavə etmək.

Q: Planlaşdırılan işləri necə nəzərə almaq olar?
A: istisnalar təqvimi aparın və müqavilənin qaydalarına əsasən onları avtomatik olaraq SLA-dan çıxarın; təsdiq edən artefaktları saxlamaq.