Операциялар және басқару → Метрикалық аудит және SLA

Метриктер мен SLA аудиті

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

Егер параметрлер дұрыс болмаса, шешімдер дұрыс болмайды, SLA «қағазда» бұзылады немесе керісінше проблемаларды жасырады. Метриктер мен SLA аудиті пайдаланушылар мен серіктестер алдындағы уәделердің салыстырмалылығына, дұрыстығына және заңды қорғалуына кепілдік береді.

• Бірыңғай «шындық көзін» (SSOT) және ойнатылатын есептерді қамтамасыз ету.
• Дашбордтар/есептер/биллинг арасындағы айырмашылықтарды азайту.
• SLA бағдарламасын орындалатын және тексерілетін ету (evidence-based).
• Өлшемдердегі тозуларды анықтау сервистердегі сияқты ерте.

2) Жауапкершіліктің базалық ұғымдары мен шектері

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

3) Метриктердің таксономиясы (қабаттары)

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

Ереже: әрбір метрикада иесінің қабаты және формуласы болуы тиіс.

4) Деректер көздері және «ақиқат»

Онлайн телееметрия: Prometheus/OTel, логи (ELK/ClickHouse), трассировка.
Оқиғалар және бухгалтерия: Kafka/Outbox, DWH/күні-наурыз (BigQuery/ClickHouse).
Қол артефактілері: постмортемдер, тикеттер, инциденттер тізілімі.
Сыртқы тізілімдер: провайдерлердің есептері (PSP/KYC/студиялар), биллинг.

Жанжалды шешу: «онлайн vs DWH» айырмашылықтары кезінде басымдық регламенті қолданылады (мысалы, SLA үшін - көздік трассалануы бар DWH агрегаттары).

5) Метрикалық аудит процесі (басқару контуры)

1. Түгендеу: метриктер/SLO/SLA каталогы (атауы, иесі, қабаты, формуласы, көзі, есептеу жиілігі).
2. Формулаларды верификациялау: SQL/өнеркәсіптік сұрауларды анықтаумен салыстыру (есептеулердің unit-тестілері).
3. Оқиғалар/логтар жолдарын іріктеу және қолмен салыстыру.
4. Контурларды салыстыру: онлайн-дашбордтар мен DWH-есептерді салыстыру.
5. Өзгерістерді бақылау: схемалар/логикалар релизі кезінде формулаларды тексеру.
6. SLA аудиті: құрастырмалар мен ерекшеліктердің дұрыстығын тексеру (planned maintenance, форс-мажор).
7. Есеп және жақсартулар: анықталған мерзімдік айырмашылықтар мен фикстердің тізімі.

6) Анықтамалар мен формулалар (үлгілер)

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

• SSOT-та терезенің (rolling 5m/1h) және агрегацияның (HDR/TDigest) бірыңғай анықтамасы тіркеледі.

• 'SLO _ availability _ month = (жұмыс уақыты _ рұқсат етілген _ ерекшеліктер )/жалпы _ уақыт'

• `SLA_month = 99. жоспарлы терезелерді (T-48 хабарлама), транзиттік операторлардың дәлелденетін аварияларды (құжаттар) қоспағанда, UTC терезесі бойынша аптайманың 90% -ы. '

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) Есептеулердің жаңғыртылуын тексеру

Формулаларды нұсқалау: SQL/PromQL/док-ерекшеліктері бар Git-репозиторий.
Өлшемдердің юнит-тесттері: synthetic деректерге (edge-кейстер: рұқсатнамалар, дублдер, күндер шекаралары).
Data lineage: Дашбордтан бастапқы кестелер мен оқиғаларға.
Snapshot: қайта есептеулер салыстырмалы болуы үшін деректерді кесуге қатыру.

10) Бақылау іріктемелері (sampling)

Күн сайын: негізгі ағындар бойынша 10-20 оқиға (депозит/ставка/АКҚ) - DWH трассасын қолмен салыстыру.
Апта сайын: агрегаттар бойынша «онлайн vs DWH» салыстыру үшін 1% сэмпл.
Ай сайын: 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) Дашбордтар мен хабарландырулардың аудиті

Метриканың бірыңғай сөздігі: глоссарий тікелей дашбордта.
Релиздер/оқиғалар аңдатпалары: ауытқу себебін көру үшін.
Релизге дейін/кейін салыстыру: автоматты регрессия тақтасы.
Дули/айырмашылықтар: «екі түрлі p99» - формулаларды/терезелерді түзету.
Панельдердің қолжетімділігі: құқықтар, резерв, сілтемелерді/нұсқаларды бақылау.

12) Метрикадағы өзгерістерді басқару

RFC процесі: формуланы/терезені/көзді өзгерту - SLA/есептерге әсерін бағалаумен RFC арқылы.
«expand → migrate → contract» көші-қоны: екі нұсқасын да уақытша жүргіземіз, салыстырамыз, содан кейін ескісін өшіреміз.
Коммуникация: «жаңа әдістеме бойынша» мәндердің ауысуы туралы өнім/бизнеске алдын ала хабарлау.

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

Сұраныс шыңдары: метриктер жарылыс жүктемелерін көтеруге тиіс (агрегациялар «жабыспайды»).
Провайдерлер: SLA ОЛА вендорларына байланысты → олардың есептерін, инциденттердің мәртебесін және квоталарын сақтау.
Құны: 'cost _ per _ 1k _ calls' және «табыс құны» - міндетті панельдер.
Антифрод/тәуекел: кідірістерге және метриктердің «жалған іске қосылуына» сезімталдығы.

14) Аудит дашбордтары (ең аз жиынтық)

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

15) Аудит (операциялық) чек-парағы

• Иелері мен формулалары бар метриктер/SLO/SLA каталогы өзекті.
• SSOT әрбір есеп/тақтаға арналған.
• Формула юнит-тестілері жасыл, есептеулердің пайплайндары құжатталған.
• Деректер сапасына алерттар белсенді (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

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

19) Рөлдер мен жауапкершілік

Метрика/сервис иесі: формула, дереккөз, дашборд, алерта.
Observability/SRE: SSOT/платформа, формула тестілері, деректер сапасының алерттары.
Data/BI: DWH, есептердің қайталануы, lineage.
Заңгерлер/әріптес-менеджерлер: SLA-келісімдер және ерекшеліктер.
Инцидент менеджері: атрибуция және инциденттерді SLA-мен байланыстыру.

20) Жылдам бастау (30 күн)

1-апта: метриканы/SLO/SLA және иелерін түгендеу; SSOT тағайындау.
Апта 2: деректер сапасы мен «Online vs DWH» панелін қосу.
3-апта: бақылау іріктемелерін жүргізу, p95/p99 терезесін тегістеу.
4-апта: формулалар үшін RFC-процесін ресімдеу, қосымшалары бар ай сайынғы SLA-есепті дайындау.

21) FAQ

Q: SLA үшін SSOT қалай есептеледі?
А: Қайта өндірілетін есептеулері (DWH) және толық lineage бар сақтау орны; онлайн-панельдер - жедел бақылау үшін, заңды актілер үшін емес.

Q: «екі p99» қалай күресуге болады?
A: Терезені/агрегаттау әдісін метрика каталогына бекіту, панельдерді көшіру, дрейфке алерт қосу.

Q: Жоспарлы жұмыстарды қалай ескеру керек?
А: Алып тастаулар күнтізбесін жүргізу және оларды шарт ережелері бойынша SLA-дан автоматты түрде алып тастау; растайтын артефактілерді сақтауға міндетті.