GH GambleHub

عملیات و → معیارهای حسابرسی مدیریت و SLAs

معیارهای حسابرسی و SLAs

1) چرا شما به آن نیاز دارید

اگر معیارها اشتباه باشند - تصمیمات اشتباه خواهند بود، SLA ها «روی کاغذ» نقض می شوند یا برعکس برای پنهان کردن مشکلات. معیارهای حسابرسی و SLA ها تضمین می کنند که وعده های کاربران و شرکا قابل مقایسه، قابل اعتماد و قانونی امن هستند.

اهداف:
  • ارائه یک «منبع حقیقت» (SSOT) و محاسبات قابل تجدید.
  • کاهش اختلاف بین داشبورد/گزارش/صورتحساب.
  • SLA ها را مبتنی بر شواهد بسازید.
  • تشخیص تخریب در اندازه گیری در اوایل به عنوان در خدمات.

2) مفاهیم اساسی و مرزهای مسئولیت

متریک: مقدار اندازه گیری (RPS، P95، CR، GGR، میزان موفقیت).
KPI/OKR: اهدافی که معیارها به آنها مرتبط هستند.
SLO: کیفیت هدف خدمات (به عنوان مثال، "p99 ≤ 400 ms 99. 9٪ از زمان").
SLA: وعده خارجی ؛ از لحاظ قانونی قابل توجه، بر اساس SLO.
OLA: توافق داخلی بین تیم ها/فروشندگان، از SLA پشتیبانی می کند.
SSOT: سیستم/ذخیره سازی که داده ها به عنوان مرجع برای گزارش دهی در نظر گرفته می شوند.

3) طبقه بندی معیارها (لایه ها)

1. زیرساخت: CPU/حافظه/IO/خالص، غلاف/گره، HPA/VPA.
2. بستر های نرم افزاری: صف/جریان (تاخیر، توان)، DB/کش ها (اتصالات، ضربه)، API (p95/p99، 5xx).
3. جریان های تجاری: سپرده ها/برداشت ها، شرط ها، راه اندازی بازی، مجوزها، KYC.
4. محصول/بازاریابی: تبدیل، ARPPU/LTV، کمپین ها.
5. کیفیت فرآیندها: MTTA/MTTR، تغییر نرخ شکست، پوشش لیست چک.

قانون: هر متریک باید یک لایه، مالک و فرمول داشته باشد.

4) منابع داده و «درست»

تله متری آنلاین: Prometheus/OTel، سیاهههای مربوط (ELK/ClickHouse)، آثار.
رویدادها و حسابداری: Kafka/Outbox، DWH/Data Marts (BigQuery/ClickHouse).
مصنوعات دستی: پس از مرگ، بلیط، ثبت حوادث.
ثبت های خارجی: گزارش های ارائه دهنده (PSP/KYC/استودیو)، صورتحساب.

حل تعارض: در صورت اختلاف «آنلاین در مقابل DWH»، مقررات اولویت اعمال می شود (به عنوان مثال، برای SLA - جمع از DWH با ردیابی منبع).

5) فرآیند حسابرسی معیارها (حلقه کنترل)

1. موجودی: کاتالوگ متریک/SLO/SLA (نام، مالک، لایه، فرمول، منبع، فرکانس محاسبه).
2. تأیید فرمول: تطبیق پرس و جو SQL/promo با تعریف (تست واحد محاسبات).
3. نمونه برداری و بازنگری: نمونه برداری خطوط رویداد/ورود به سیستم و آشتی دستی.
4. نقشه برداری کانتور: مقایسه داشبورد آنلاین و گزارش DWH.
5. کنترل تغییر: بررسی فرمول برای انتشار طرح/منطق.
6. حسابرسی SLA: تأیید صحت مجامع و استثنائات (نگهداری برنامه ریزی شده، فورس ماژور).
7. گزارش و بهبود: لیستی از اختلافات شناسایی شده و رفع با مهلت.

6) تعاریف و فرمول ها (نمونه ها)

میزان موفقیت (API):
  • 'success = requests - (5xx + timeouts + circuit_open)'
  • 'success _ rate = موفقیت/درخواستها'
تاخیر p95/p99:
  • SSOT یک تعریف واحد از پنجره (نورد 5m/1h) و تجمع (HDR/TDigest) را ثبت می کند.
SLO (مثال):
  • 'SLO _ availability _ month = (uptime - allowable _ exceptions )/total _ time'
SLA (به عنوان مثال برای ارائه دهنده):
  • SLA _ month = 99. 90٪ آپ تایم توسط پنجره UTC، به استثنای پنجره های برنامه ریزی شده (اطلاع رسانی T-48)، حوادث قابل اثبات در اپراتورهای حمل و نقل (اسناد)

7) کیفیت داده: چک و هشدار

بررسی کیفیت:
  • Полнота (کامل بودن): 'received _ events/ expected_events ≥ 0. 99`.
  • به موقع: تاخیر بار ≤ N دقیقه.
  • منحصر به فرد: بدون کلید های تکراری (idempotency-key).
  • قوام-مقادیر/ارز/شخصیت.
  • خطی بودن - شمارنده ها «به عقب رانده نمی شوند».
هشدارها در مورد کیفیت اندازه گیری (ایده ها):

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. Attribution: خرابی های خود، ارائه دهنده، حمل و نقل، DDoS، تعمیر و نگهداری روزمره.
5. محیط SLA: تجربه کاربر (E2E) در مقابل یک API خاص.
6. گزارش: گزارش ماهانه/سه ماهه: واقعی، انحراف، جبران (در صورت وجود)، اقدامات اصلاحی.

9) بررسی تکرارپذیری محاسبه

نسخه بندی فرمول: مخزن Git با مشخصات SQL/PromQL/dock.
تست واحد معیارها: بر روی داده های مصنوعی (موارد لبه: شکاف، تکراری، مرزهای تاریخ).
Data lineage: از داشبورد به جداول و رویدادهای منبع.
Snapshots: انجماد داده ها برای قطع به طوری که دوباره محاسبات قابل مقایسه است.

10) نمونه برداری

روزانه: رویدادهای 10-20 توسط جریان های کلیدی (سپرده/نرخ/CCL) - تأیید دستی ردیابی ↔ DWH.
هفتگی: 1٪ نمونه برای مقایسه «آنلاین در مقابل DWH» در سراسر aggregates.
ماهانه: مجموعه ای از حوادث با اثر 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) حسابرسی داشبورد و هشدارها

Unified dictionary of metrics: واژه نامه درست در داشبورد.
حاشیه نویسی از انتشار/حوادث: برای دیدن علت انحراف.
مقایسه قبل/بعد از انتشار: پانل های رگرسیون خودکار.
تکراری/اختلاف: شناسایی «دو p99s مختلف» - ویرایش فرمول/ویندوز.
در دسترس بودن پنل: حقوق، رزرو، کنترل لینک/نسخه.

12) مدیریت تغییر متریک

فرآیند RFC - تغییر فرمول/پنجره/منبع - از طریق RFC با SLA/گزارش ارزیابی تاثیر

Migration «expand → migrate → contract»: هر دو نسخه را به طور موقت نگه دارید، مقایسه کنید، سپس نسخه قدیمی را خاموش کنید.
ارتباطات: اطلاع محصول/کسب و کار در پیش از تغییرات در ارزش «با توجه به روش جدید».

13) مشخصات iGaming/fintech

اوج تقاضا: معیارها باید در برابر بارهای انفجاری مقاومت کنند (تجمع ها «نمی چسبند»).
ارائه دهندگان: SLA بستگی به فروشندگان OLA دارد که گزارش ها، وضعیت حوادث و سهمیه های خود را ذخیره می کنند.
هزینه: 'cost _ per _ 1k _ calls' و 'cost of success' پانل های اجباری هستند.
Antifraud/risk: حساسیت به تاخیر و «مثبت کاذب» معیارها.

14) داشبورد حسابرسی (حداقل مجموعه)

معیارهای سلامت: کامل/بهنگام بودن/تکراری، مصرف تاخیر، ошибки ETL.
SLO/SLA شواهد: SLO محاسبه شده، SLA واقعی، استثنائات، اشاره به حوادث/اعمال.
مقایسه آنلاین در مقابل DWH: نرخ p95/p99/Success، انحرافات و روندها.
SLA فروشنده: uptime/quota/timeouts/cost by provider.
تأثیر انتشار: رگرسیون معیارها پس از محاسبات/درج ویژگی ها.

15) چک لیست حسابرسی (عملیاتی)

  • فهرست metrics/SLO/SLA با صاحبان و فرمول ها به روز است.
  • SSOT برای هر گزارش/پانل تعریف شده است.
  • تست واحد فرمول سبز هستند، محاسبه خطوط لوله مستند شده است.
  • هشدارهای کیفیت داده فعال هستند (کامل بودن/جدول زمانی/تکراری).
  • «آنلاین در مقابل DWH» اختلاف ≤ آستانه قابل قبول (به عنوان مثال ≤2٪).
  • استثنائات SLA توافق مستند و متصل به گزارش.
  • نمونه های کنترل گرفته شد و گواهینامه ها تهیه شد.
  • تمام تغییرات فرمول RFC و مهاجرت گذشت.

16) نمونه ها (قطعات)

PromQL - مقایسه قبل/بعد از انتشار p99:

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})
SQL - کنترل کامل رویداد:
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;
قانون Alertmanager - واگرایی کانتور:

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.
گزارش در اکسل محلی به عنوان «درست» (غیر قابل تکرار).
مخلوط کردن مناطق زمانی و تقویم در محاسبات SLA.
استثنائات SLA مستند نشده است.
هیچ هشداری در مورد کیفیت اندازه گیری وجود ندارد.

18) KPI بلوغ اندازه گیری

نرخ رانش Online↔DWH (هدف ≤2٪).
آپتایم سلامت متریک.

فرمول زمان برای اصلاح

نرخ اختلاف SLA.
پوشش SLO/SLA (نسبت مسیرهای بحرانی با SLO/SLA به طور رسمی شرح داده شده).

19) نقش ها و مسئولیت ها

صاحب متریک/خدمات: فرمول، منبع، داشبورد، هشدارها.
قابلیت مشاهده/SRE: SSOT/پلت فرم، آزمون فرمول، هشدار کیفیت داده ها.
داده/BI: DWH، گزارش تکرارپذیری، اصل و نسب.
وکلا/مدیران شریک: موافقت نامه های SLA و استثنائات.
مدیر حادثه: تخصیص و ارتباط حوادث SLA.

20) شروع سریع (30 روز)

هفته 1: معیارهای موجودی/SLO/SLA و صاحبان ؛ یک SSOT را اختصاص دهید.
هفته 2: شامل هشدار کیفیت داده ها و پانل «آنلاین در مقابل DWH».
هفته 3: نمونه های کنترل را انجام دهید، پنجره p95/p99 را تراز کنید.
هفته 4: فرآیند RFC را برای فرمول ها رسمی کنید، یک گزارش SLA ماهانه با پیوست ها تهیه کنید.

21) سوالات متداول

س: SSOT برای SLA چیست ؟

A: ذخیره سازی با محاسبات تجدید پذیر (DWH) و اصل و نسب کامل ؛ پانل های آنلاین - برای کنترل عملیاتی، نه برای اعمال قانونی.

س: چگونه با «دو p99s» برخورد کنیم ؟

A: رفع روش پنجره/تجمع در فهرست معیارها، مهاجرت پانل ها، اضافه کردن هشدار به رانش.

س: چگونه می توان کارهای برنامه ریزی شده را در نظر گرفت ؟

A: تقویم استثنائات را حفظ کنید و به طور خودکار آنها را از SLA بر اساس قوانین قرارداد کسر کنید ؛ مصنوعات تأیید شده را ذخیره کنید.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

Telegram
@Gamble_GC
شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.