Операциялар жана башкаруу → Метрика жана SLA аудит

Метрика жана SLA аудит

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

Эгерде көрсөткүчтөр туура эмес болсо, чечимдер туура эмес болот, SLA "кагазда" бузулат же тескерисинче көйгөйлөрдү жашырат. Метриканын жана SLA аудити колдонуучуларга жана өнөктөштөргө убадалардын салыштырууга жөндөмдүүлүгүн жана юридикалык жактан корголушун кепилдейт.

• Бирдиктүү "чындык булагын" (SSOT) жана кайталануучу эсептөөлөрдү камсыз кылуу.
• Дашборддор/отчеттор/биллинг ортосундагы айырмачылыктарды азайтуу.
• SLAны мүмкүн жана текшерилүүчү кылуу (evidence-based).
• Өлчөөлөрдөгү деградацияларды аныктоо кызматтардагыдай эле эрте.

2) Жоопкерчиликтин негизги түшүнүктөрү жана чектери

Metric (Метрика): өлчөнүүчү көлөмү (RPS, p95, CR, GGR, Success баасы).
KPI/OKR: метриктер байланышкан максаттар.
SLO: кызматтын максаттуу сапаты (мисалы, "p99 ≤ 400 мс 99. 9% убакыт").
SLA: тышкы убада; юридикалык жактан маанилүү, SLO негизинде.
OLA: командалар/сатуучулар ортосундагы ички келишим, SLA колдойт.
SSOT: маалыматтар отчеттор үчүн эталон болуп эсептелет системасы/сактоо.

3) Метриктердин таксономиясы

1. Инфраструктура: CPU/Memory/IO/Net, Pod/түйүндөр, HPA/VPA.
2. Платформа: кезек/агымдар (lag, throughput), BD/кэш (коннектилер, хит), API (p95/p99, 5xx).
3. Бизнес агымдары: депозиттер/корутундулар, коюмдар, оюндарды баштоо, авторизация, KYC.
4. Продукт/маркетинг: конверсиялар, ARPPU/LTV, кампаниялар.
5. жараяндардын сапаты: MTTA/MTTR, өзгөрүү Failure Rate, чек барактарын жабуу.

Эреже: ар бир метриканын катмары, ээси жана формуласы болушу керек.

4) Маалымат булактары жана "чындык"

Телекөрсөтүү онлайн: Prometheus/OTel, Логи (ELK/ClickHouse), Tracking.
Окуялар жана бухгалтерия: Kafka/Outbox, DWH/Date-март (BigQuery/ClickHouse).
Кол экспонаттары: постмортемдер, билеттер, инциденттердин реестрлери.
Тышкы реестрлер: провайдерлердин отчеттору (PSP/KYC/студиялар), биллинг.

Чыр-чатакты чечүү: "онлайн vs DWH" айырмачылыктары болгон учурда артыкчылыктуу регламент колдонулат (мисалы, SLA үчүн - DWHден булакты издөө менен агрегаттар).

5) Метрика текшерүү жараяны (башкаруу контур)

1. Инвентаризация: метрика/SLO/SLA каталогу (аты, ээси, катмар, формула, булак, эсептөө жыштыгы).
2. Формулаларды текшерүү: SQL/пром-суроо-талаптарды аныктама менен салыштыруу (эсептөөлөрдүн бирдик-тесттери).
3. Самплирлөө жана кайра текшерүү: окуялардын/логдордун жолдорун тандоо жана кол менен текшерүү.
4. Контурларды салыштыруу: онлайн дашбордддорду жана DWH отчетторун салыштыруу.
5. Өзгөрүүлөрдү көзөмөлдөө: схемаларды/логиканы чыгарууда формулаларды ревю.
6. SLA аудити: монтаждардын жана өзгөчөлүктөрдүн тууралыгын текшерүү (planned maintenance, форс-мажор).
7. Отчет жана өркүндөтүү: аныкталган айырмачылыктардын жана мөөнөттөр менен фикстердин тизмеси.

6) Аныктамалар жана формулалар (үлгүлөр)

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

• SSOT бир терезе аныктамасын (5m/1h rolling) жана бириктирүү (HDR/TDigest) жазылган.

• 'SLO _ availability _ month = (_ иштөө убактысы - алгылыктуу _ өзгөчөлүктөр )/жалпы _ убакыт'

• `SLA_month = 99. 90% UTC терезеси боюнча аптайм, пландуу терезелерди кошпогондо (T-48 билдирүү), транзиттик операторлордо далилденген кырсыктар (документтер). '

7) Маалымат сапаты: текшерүүлөр жана тобокелдиктер

• Полнота (completeness): `received_events / expected_events ≥ 0. 99`.
• Өз убагында (timeliness): жүктөө артта ≤ N мүнөт.
• Уникалдуулук (uniqueness): ачкычтар боюнча дубль жок (idempotency-key).
• Ырааттуулук (consistency): суммалар/валюта/белгилер.
• Сызыктуулук (monotonicity): эсептегичтер "тоголонуп" эмес.

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 аудит: ыкмасы

1. Эсептен чыгаруу календарын чогултуу: пландаштырылган терезелер, макулдашылган деградациялар, сатуучулардын актылары.
2. Аптаймды эсептөө: бирдиктүү убакыт зонасы боюнча, SSOT таянуу менен.
3. Инциденттер менен салыштыруу: таймлайн, билеттер, постмортемалар.
4. Атрибуция: өздүк мүчүлүштүктөр, провайдер, транзит, DDoS, регламенттик иштер.
5. SLA периметри: колдонуучу тажрыйбасы (E2E) vs бир конкреттүү API.
6. Отчеттуулук: ай/чейрек боюнча отчет: факт, четтөөлөр, компенсациялар (эгер колдонулса), түзөтүү чаралары.

9) Эсептешүүлөрдүн кайталанышын текшерүү

Formula Version: SQL/PromQL/док-өзгөчөлүктөрү менен Git-репозиторий.
Бирдиктик тесттер метриктер: synthetic маалыматтар боюнча (edge-учурларда: өткөрмөлөр, эки, даталар чектери).
Data lineage: баштапкы таблицалар жана окуялар үчүн кайра dashboard.
Snapshots: алдын-ала эсептөөлөр салыштырууга болот өчүрүү боюнча маалыматтарды тоңдуруп.

10) контролдук үлгүлөрү (sampling)

Күн сайын: 10-20 негизги агымдар боюнча иш-чаралар (депозиттик/коюм/CUS) - кол менен тактоо DWH.
Жумалык: 1% агрегаттар боюнча "онлайн vs DWH" салыштыруу үчүн sampl.
Ай сайын: SLA таасири менен окуялар топтому - деталдуу калыбына келтирүү.

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) Дашборддордун жана эскертүүлөрдүн аудити

Метриканын бирдиктүү сөздүгү: глоссарий түз эле дашборддо.
Релиздердин/иш-чаралардын аннотациялары: четтөөлөрдүн себебин көрүү.
Салыштыруу "чыгаруу алдында/кийин": автоматтык регрессия панелдер.
Doubley/айырмачылыктар: аныктоо "эки башка p99" - түзөтүүлөр/терезелер.
Panel жеткиликтүүлүгү: укуктар, камдык, шилтемелерди/версияларды көзөмөлдөө.

12) Метрикадагы өзгөрүүлөрдү башкаруу

RFC жараяны: формула/терезе/булак өзгөртүү - SLA/отчетторго таасир баа берүү менен RFC аркылуу.
көчүрүү "expand → migrate → contract": убактылуу эки нускасын алып, салыштырып, андан кийин эски өчүрүп.
Коммуникация: "жаңы ыкма боюнча" маанилердин жылышы жөнүндө продукт/бизнеске алдын ала кабарлоо.

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

Суроо-талаптын чокулары: метриктер жарылуучу жүктөргө туруштук бериши керек (агрегациялар "жабышпайт").
Провайдерлер: SLA OLA сатуучуларга көз каранды → алардын отчетторун, инциденттердин статусун жана квоталарды сактоо.
Баасы: 'cost _ per _ 1k _ calls' жана "ийгиликтин баасы" - милдеттүү панелдер.
Антифрод/тобокелдик: кечигүүлөргө жана метриктердин "жалган иштешине" сезгичтик.

14) Dashbord аудит (минималдуу топтому)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence: эсептелген SLO, иш жүзүндө SLA, өзгөчөлүктөр, окуяларга/актыларга шилтемелер.
Online vs DWH Compare: p95/p99/Success Rate, четтөөлөр жана тенденциялар.
Vendor SLA: uptime/квота/тайм-аутс/провайдерлер боюнча наркы.
Release Impact: чегерүү/FICH киргизүү кийин метрикалык регрессия.

15) Аудит тизмеси (операциялык)

• Ээлери жана формулалары менен метрика/SLO/SLA каталогу актуалдуу болуп саналат.
• SSOT ар бир отчет/панел үчүн аныкталган.
• Unit-тесттер формулалары жашыл, эсептөөлөрдүн пайплайндары документтештирилген.
• маалыматтардын сапаты боюнча Алерт активдүү (completeness/timeliness/duplicates).
• "Online vs DWH" ≤ жол берилген босого айырмачылыктар (мисалы, ≤ 2%).
• SLAнын макулдашылган өзгөчөлүктөрү документтештирилген жана отчетко тиркелет.
• Контролдук тандоолор жүргүзүлүп, актылар таризделди.
• Бардык формула өзгөртүүлөр RFC жана көчүрүү өттү.

16) Мисалдар (фрагменттер)

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) Анти-үлгүлөрү

Эки түрдүү формулалар "бир" ар кандай панелдер боюнча метрика.
Миграциясыз жана билдирүүсүз метриканы өзгөртүү - OKR/SLAга "секирүү".
Жергиликтүү Excel отчеттор "чындык" катары (калыбына келтирүү мүмкүн эмес).
SLA эсептөөлөрүндө убакыт алкактары менен календарларды аралаштыруу.
SLA өзгөчөлүктөрү документтештирилбейт.
өлчөө сапатына эч кандай коркунуч жок.

18) KPI жетилген өлчөө

Drift Rate Online ≤ DWH (максаты 2%).
Metrics Health Uptime (ingest/ETL деградациясы жок убакыт).
Time-to-Fix Formula (формуладагы катаны жоюу убактысы).
SLA Dispute Rate (өнөктөштөр менен талаш учурларда жыштыгы).
Coverage SLO/SLA (SLO/SLA расмий сүрөттөлгөн менен маанилүү жолдордун үлүшү).

19) Ролдору жана жоопкерчилиги

Метриканын/кызматтын ээси: формула, булак, дашборд, алерта.
Observability/SRE: SSOT/платформа, Formula тесттер, маалымат сапатынын алерттери.
Data/BI: DWH, отчетторду ойнотуу, сызык.
Юристтер/өнөктөш менеджерлер: SLA келишимдер жана өзгөчөлүктөр.
Инцидент менеджери: SLA менен инциденттердин атрибутикасы жана байланышы.

20) Тез баштоо (30 күн)

Апта 1: Метрика/SLO/SLA жана ээлеринин инвентаризациясы; SSOT дайындоо.
Апта 2: маалымат сапаты жана панелдин Алерт "Online vs DWH".
Апта 3: текшерүү үлгүлөрүн өткөрүү, p95/p99 терезесин тегиздөө.
Апта 4: формулалар үчүн RFC жараянын тариздөө, тиркемелер менен ай сайын SLA отчетун даярдоо.

21) FAQ

Q: SLA үчүн SSOT деген эмне?
A: Replay эсептөөлөр менен сактоо (DWH) жана толук сызык; онлайн панелдер - юридикалык актылар үчүн эмес, ыкчам көзөмөл үчүн.

Q: "эки p99" менен кантип күрөшүү керек?
A: Терезени/агрегация ыкмасын метрика каталогуна бекитүү, панелдерди көчүрүү, дрейфке алерт кошуу.

Q: пландаштырылган иш кантип эске алуу керек?
A: Чыгарылыштар календарын жүргүзүү жана келишим эрежелери боюнча аларды SLAдан автоматтык түрдө алып салуу; тастыктоочу артефакттарды сактоого.