عملیات و → معیارهای حسابرسی مدیریت و 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 = موفقیت/درخواستها'
- SSOT یک تعریف واحد از پنجره (نورد 5m/1h) و تجمع (HDR/TDigest) را ثبت می کند.
- 'SLO _ availability _ month = (uptime - allowable _ exceptions )/total _ time'
- 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 بر اساس قوانین قرارداد کسر کنید ؛ مصنوعات تأیید شده را ذخیره کنید.