מבצעים ו ־ Group Administration Metrics ו ־ SLAName

ביקורת מטריות ו SLAs

1) למה אתה צריך את זה

אם המדדים שגויים - החלטות שגויות, יופרו ”על הנייר” או להפך כדי להסתיר בעיות. ביקורת מדדים ו-SLAs מבטיחה כי הבטחות למשתמשים ושותפים ניתנות להשוואה, אמינות וחוקית.

• לספק ”מקור אמת” יחיד (SSOT) וחישובים רבעוניים.
• הפחתת אי התאמות בין לוחות מחוונים/דוחות/חיובים.
• הפוך SLAs מבוסס ראיות.
• איתור השפלה במדידות מוקדם כמו בשירותים.

2) מושגים בסיסיים וגבולות אחריות

מטרי: כמות נמדדת (RPS, p95, CR, GGR, Success Rate).
KPI/OKR: מטרות שאליהן מדדים קשורים.
SLO: איכות המטרה של השירות (לדוגמה, p99 בלום 400 ms 99. 9% מהזמן").
SLA: הבטחה חיצונית; משמעותי מבחינה משפטית, מבוסס על SLO.
הסכם פנימי בין צוותים/ספקים, תומך ב-SLA.
SSOT: מערכת/אחסון שהנתונים שלה נחשבים כהתייחסות לדיווח.

3) טקסונומיה של מדדים (שכבות)

1. תשתית: CPU/Memory/IO/Net, תרמילים/צמתים, HPA/VPA.
2. פלטפורמה: תורים/זרמים (lag, breadput), DB/caches (חיבורים, להיט), API (p95/p99, 5xx).
3. זורמים עסקים: הפקדות/משיכות, הימורים, השקות משחק, הרשאות, KYC.
4. מוצר/שיווק: המרות, ARPU/LTV, קמפיינים.
5. איכות תהליכים: MTTA/MTR, שינוי שיעור כישלון, סיקור רשימה.

חוק: לכל מטרי חייבת להיות שכבה, בעלים ונוסחה.

4) מקורות נתונים ו ”אמת” ‏

טלמטריה מקוונת: Prometheus/Otel, יומנים (ELK/ClickHouse), עקבות.
אירועים וחשבונאות: Kafka/Outbox, DWH/Data marts (BigQuery/ClickHouse).
חפצים ידניים: לאחר המוות, כרטיסים, רשומות אירוע.
רישומים חיצוניים: דיווחים מספקים (PSP/KYC/studios), חיוב.

יישוב סכסוכים: במקרה של אי התאמות ”Online vs. DWH”, תקנות העדיפות תקפות (לדוגמה, עבור SLA - צבירים מ-DWH עם איתור מקור).

5) תהליך ביקורת חשבונות (לולאת בקרה)

1. מלאי: קטלוג מטריצות/SLO/SLA (שם, בעלים, שכבה, נוסחה, מקור, תדר חישוב).
2. אימות פורמולה: פיוס שאילתות SQL/promo עם ההגדרה (בדיקות יחידה של חישובים).
3. דגימה ובדיקה מחודשת: דגימה של אירועים/קווי רישום ופיוס ידני.
4. מיפוי מתאם: השוואה של לוחות מחוונים מקוונים ודיווחי DWH.
5. שינוי בקרה: סקירת נוסחה לסכימה/היגיון משחררת.
6. ביקורת: אימות התקינות של אסיפות וחריגות (תחזוקה מתוכננת, כוח עליון).
7. דו "ח ושיפורים: רשימה של אי התאמות מזוהות ותיקונים עם מועדים.

6) הגדרות ונוסחאות (דוגמאות)

• הצלחה = בקשות - (5xx + פסק זמן + circuit_open) "
• success _ rate = הצלחה/דרישה &poss

• SSOT מקליט הגדרה אחת של חלון (מגלגל 5m/1h) וצבירה (HDR/TDiingt).

• 'SLO _ זמינות _ חודש = (optime - allowable _ expections )/time _ &fospos

• 'SLA _ חודש = 99. 90% העלאה בזמן על ידי חלון UTC, לא כולל חלונות מתוכננים (הודעה T-48), תאונות אפשריות במפעילי מעבר (מסמכים) "

7) איכות נתונים: בדיקות והתראות

• 'קיבל _ events/ expected_events wime 0. 99`.
• זמן: Top Lag Lough 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: Methodology

1. לאסוף לוח שנה של יוצאים מן הכלל: חלונות מתוכננים, השפלה מוסכמת, פעולות של ספקים.
2. חישוב הזמן: לפי אזור זמן אחד, המבוסס על SSOT.
3. פיוס עם תקריות: ציר זמן, כרטיסים, לאחר המוות.
4. ייחוס: כשלים משלו, ספק, מעבר, DDOS, תחזוקה שגרתית.
5. היקף SLA: חוויית משתמש (E2E) נגד API מסוים אחד.
6. דיווח: דו "ח חודשי/רבעוני: בפועל, סטיות, פיצויים (אם ישים), אמצעים מתקנים.

9) בדיקת רבייה חישובית

נוסחה: מאגר Git עם מפרט SQL/PromQL/dock.
בדיקות יחידה של מדדים: על נתונים סינתטיים (מקרי קצה: פערים, שכפולים, גבולות תאריך).
שושלת נתונים: מלוח מחוונים חזרה לטבלאות מקור ואירועים.
תצלומים: מקפיאים נתונים לחיתוך כך שהחישובים מחדש ניתנים להשוואה.

10) דגימה

יום: 10-20 אירועים על ידי זרימות מפתח (הפקדה/קצב/CCL) - אימות ידני של איתור ↔ DWH.
שבוע: 1% מדגם להשוואת ”מקוון נגד DWH” על פני אגרגטים.
סט אירועים עם אפקט 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) ביקורת של לוחות מחוונים והתראות

מילון מאוחד של מדדים: גלוסרי ממש על לוח המחוונים.
אנוטציות של שחרור/אירועים: כדי לראות את הסיבה לסטיות.
השוואה טרום שחרור: לוחות רגרסיה אוטומטיים.
כפילויות/אי ־ התאמות: זיהוי ”שתי p99s שונות” - נוסחאות עריכה/חלונות.
זמינות פנל: זכויות, רזרבה, קישור/בקרת גירסה.

12) ניהול שינויים מטריים

תהליך RFC - שינוי פורמולה/חלון/מקור - באמצעות RFC עם הערכת השפעה SLA/Reporting

הגירה ”התרחבה * חוזה נודד”: באופן זמני לשמור על שתי הגרסאות, להשוות, ואז לכבות את הישן.

תקשורת: הודע למוצר/עסק מראש על משמרות בערכים ”לפי השיטה החדשה”. ‏

13) פרטים iGaming/fintech

פסגות הביקוש: מדדים חייבים לעמוד בעומסי חומר נפץ (צבירה לא ”מקל”).
ספקים: SLA תלויה בספקים של OLA.
עלות: "עלות _ per _ 1k _ calls' ו" עלות ההצלחה "הם לוחות חובה.
אנטיפראוד/סיכון: רגישות לעיכובים ו ”חיובי כוזב” של מדדים.

14) לוחות מחוונים (סט מינימלי)

בריאות מטרית: שלמות/עיתוי/שכפולים, בלע-לג, לשעבר ETL.
ראיות SLO/SLA: SLO מחושב, SLA בפועל, חריגים, אזכורים לתקריות/מעשים.
מקוון נגד DWH השוואה: קצב p95/p99/Success, סטיות ומגמות.
ספק SLA: uptime/מכסות/timeouts/עלות על ידי ספק.
שחרור פגיעה: רגרסיה של מדדים לאחר חישובים/הכללה של תכונות.

15) בדיקת ביקורת (מבצעי)

[ ] ספריית המדדים/SLO/SLA עם בעלים ונוסחאות מעודכנות.

[ ] SSOT מוגדרת עבור כל דו "ח/פאנל.

[ מבחני היחידה ] של נוסחאות ירוקות, מתועדים צינורות חישוב.

[ ] התראות איכות נתונים פעילות (שלמות/ציר זמן/שכפולים).

[ ] ”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.
דיווחים באקסל המקומי כ ”אמת” (לא רבייה).
ערבוב אזורי זמן ולוחות שנה בחישובי SLA.
חריגות SLA אינן מתועדות.
אין התראות על איכות המדידות.

18) מדידת בגרות KPI

סחיפה קצב Online↔DWH (יעד סימון 2%).
מדדים לבריאות בזמן.
זמן לתקן פורמולה.
שיעור מחלוקת SLA.
סיקור SLO/SLA (פרופורציה של נתיבים קריטיים עם תיאור רשמי של SLO/SLA).

19) תפקידים ואחריות

בעלים של השירות המטרי: נוסחה, מקור, לוח מחוונים, התראות.
יכולת תצפית/SRE: SSOT/פלטפורמה, מבחני נוסחה, התראות איכות נתונים.
Data/BI: DWH, דיווח על רבייה, שושלת.

• ייחוס וקישור תקריות SLA.

20) התחלה מהירה (30 ימים)

שבוע 1: מלאי מטריצות/SLO/SLA ובעלים; להקצות SSOT.
שבוע 2: כללו התראות על איכות המידע ופאנל ”Online vs. DWH”.
שבוע 3: דגימות בקרת התנהגות, יישור חלון p95/p99.
שבוע 4: לארגן את תהליך RFC לנוסחאות, להכין דו "ח SLA חודשי עם קבצים מצורפים.

21) FAQ

Q: מהו SSOT עבור SLA?
א. אחסון עם חישובים רבעוניים (DWH) ושושלת מלאה; לוחות מקוונים לבקרה מבצעית, לא למעשים משפטיים.

קיו: איך להתמודד עם ”שני פי-99”?
א. תקן את שיטת החלון/הצבירה בספריית המדדים, תוסיף התראה להיסחף.

קיו: כיצד לשקול עבודות מתוכננות? ‏

א ': לשמור על לוח שנה של חריגים ולנכות אותם אוטומטית מה-SLA לפי כללי החוזה; חפצים המאשרים את החנות.