תגובת התראה וכישלון

(סעיף: טכנולוגיה ותשתיות)

תקציר

התראה חזקה היא אות להפרה של ערך המשתמש, ולא רק "מטרי אדום. עבור iGaming, שערי SLO (latency, זמינות, המרת תשלומים, Time-to-Wallet), כללים רבי-צריבה, ברורים בכוננות, הסלמה, צ 'טופ ותפקידי ריצה חשובים. המטרה היא לראות במהירות את הסטייה, להודיע למי שיכול לתקן, ולתקן את הידע כדי להגיב אפילו מהר יותר וזול יותר בפעם הבאה.

1) היסודות: ממטרים לפעולה

SLI # SLO # התראה - איכות נמדדת * רמת מטרה = ”תקציב הוא בתנאי”.
חומרה (SEV): - קריטית (הכנסות/GGR בסיכון), - רצינית, - מתונה, מינורית.
Impact/Orgency: מי סובל (כל/אזור/דייר/ערוץ) וכמה דחוף (TTW drught, p99 drught, serror-drage drage).
פעילות: עבור כל אזעקה - פעולה ספציפית (runbook + בעלים).

2) טקסונומיה אותות

SLO: p95/p99 latency API, שגיאה-rate, רוויה (CPU/IO/GPU), תור lag.
BUSSLO: המרת תשלום (Time-to-Wallet), הצלחה בהימורים, השקת משחקים.
נתיבי תשלום: מדדים ספציפיים PSP (קוצי זמן/ירידה).
קדמי/נייד: RUM metrics (LCP/INP), crash-rate, תרחיש סינתטי (login/deposition/rate/plut).

3) מדיניות התראה: SLO וקצב צריבה

דוגמאות SLI/SLO

תשלומים-api זמינות 99. 9 %/30d p95 '/הפקדה 'nother 250 ms/30d

המרה של 'תשלומים _ ניסיון * הצלחה קו בסיס 0. 3 %/24h

TW p95 3min/24h

multi-window/multi-burn (שם: PromQL)

צריבה מהירה: הפרת SLO 5-10 x מהר יותר מהרגיל (עמוד התראה בעוד 5-15 דקות).
צריבה איטית: שחיקת תקציב איטית (ניתוח כרטיס + 1-3 שעות).

yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }

4) הפחתת רעש ואיכות אות

מקור האמת הנכון: לשנות באמצעות צבירה (כללי הקלטה), ולא באמצעות ביטויים ”גולמיים” כבדים.
שכפול - קבוצות מתריעות על ידי 'שירות/אזור/חומרה'.
היררכיה: התראה ראשונה לעסקים/SLI, מדדים טכניים תחתונים כאבחון.
דיכוי: במהלך תכנון תחזוקה/שחרור (annotation), במהלך תקריות במעלה הזרם.
קרדינליות: אל תשתמש ב- "user _ id/session _ id' בתוויות התראה.
התראות מבחן: ”אימון” רגיל מפעיל (בדיקת ערוצים, תפקידים, הפעלת קישורים).

5) ניתוב הזעקה והסלמה

yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack

receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"

inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]

רעיון: SEV = page # Pgare Duty/SMS; השאר הוא רפוי/כרטיס. עיכוב מדכא את ”ההייפ” של רמות נמוכות יותר עם SEV פעיל למעלה.

6) Grafana Alerting (כשכבה נוספת)

כללי התראה מרכזית על לוחות מחוונים (Prometheus/Loki/Cloud).
נקודות מגע: Pgrag Duty/Slack/Dוא "ל, מדיניות הודעה לתיקייה.
שתיקה: עבודות מתוכננות, נדידה, שחרור.
תמונות עם צילום מסך אוטומטי של הפאנל בכרטיס.

7) תהליכים תורניים וחיים

סיבוב: קו 1 (SRE/platform), קו 2 (בעל שירות), קו 3 (DB/תשלומים/Sec).
תגובות SLA: הכרה ב-5 דקות (SE1), אבחון 15 דקות, תקשורת כל 15-30 דקות.
ערוצי החובה: ”# תקרית-חדר מלחמה”, ”# סטטוס-עדכונים” (עובדות בלבד).
ספרי ריצה: קישור בכל התראה + פקודות מהירות של ChatOps ('/rollback ', '/freze', '/scale ').
אזעקות אימון: חודש (בדיקת אנשים, ערוצים, רצים רלוונטיים).

8) אירועים: מחזור חיים

1. גילוי (התראה/דיווח/סינתטיקה) = & Know on-call.
2. מיון: לקבוע SEV/מושפע/השערה, חדר מלחמה פתוח.
3. ייצוב: rolls/rollback/scaling/phichflags.
4. תקשורת: תבנית מצב (ראה להלן), זמן הגעה משוער/צעדים הבאים.
5. סגירה: אישור של התאוששות SLO.
6. לאחר 24-72 שעות, אין חיובים, פריטי פעולה.

• מה שבור/מושפע (אזור/דייר/ערוץ)
• כאשר התחיל/SEV
• צעדים זמניים (הקלה)
• עדכון מצב הבא בעוד N דקות
• צור קשר (מנהל תקרית)

9) הפרטים של iGaming: ”אזורי כאב” והתראות

תשלומים/TTW: נתח של פסקי זמן PSP, עלייה בכשלונות קוד, TTW p95> 3.
פסגות טורניר: p99 API/משחק להתחיל זמן/תור lag; קידום גבולות/קנה מידה אוטומטי.
מסקנות של קרנות: SLA של מחפר/בדיקות ידניות, מגבלות על ידי מדינה.
ספקי משחקים: זמינות באולפן, זמן אתחול הפעלה, ירידה בשיגור.
RG/Complication: התפרצויות של מפגשים ארוכים/Dogon, מעבר לסף - לא דף, אלא כרטיס + הודעה לצוות RG.

10) דוגמאות חוק (אופציונלי)

Latency p95 (API)

promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"

תור ראשי ”על”

promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"

המרת תשלום טבול

promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"

11) פטפוטים ואוטומציה

התראות על פרסום אוטומטי עם כפתורי פעולה: עצור קנרית, רולבק, סקאלה + N.

קיצורי פקודה: '/תקרית התחלה ', '/עדכון מצב', '/call <בעלים> ', '/grafana '

Bots להדק את ההקשר: הפריסה האחרונה, גרף תלות, מופת, כרטיסים קשורים.

12) עבודה שלאחר תקרית (RCA)

ציר זמן, מה ראה/ניסה, מה עבד.
סיבה שורשית: סיבות טכניות וארגוניות.
גילוי & הגנות: אילו אותות עזרו/נכשלו.
פריטי פעולה: משימות ספציפיות (SLO/התראות/קודים/הגבלות/בדיקות/ריצות).
תאריכי עבודה & בעלים: תנאים ואחריות; פגישת מעקב בעוד 2-4 שבועות.

13) רשימת מימושים

1. הגדר SLI/SLO עבור זרמי מפתח (API/תשלומים/משחקים/TTW).
2. הגדרת כללי הקלטה והתראות רב צריבה + ניתוב Alertmanager.
3. הזן בכוננות עם סיבוב, תגובה SLO והסלמה.
4. התראות קישור לספרי ריצות ופקודות צ 'טופ.
5. הגדרות דיכוי/חלונות שקטים, שחרור/עבודה אנוטציות.
6. הכן אזעקות למידה ותרחישי יום-משחק (ירידה ב-PSP, עלייה ב-p99, עלייה בתורים).
7. איכות התראת מדידה: MTTA/MTR,% roisy/false, כיסוי על ידי SLO.
8. RCAs רגיל ושינוי של סף/תהליכים.
9. הזן מצב תקשורת עסקית/תמיכה (תבניות).
10. לתעד הכל כקוד: כללים, מסלולים, בריחת קישורים.

14) אנטי דפוסים

התראה על ידי ”כל מטרי” התראה-פטיג, להתעלם.
לא SLO = לא ברור מה ”נורמלי” ומה ”עולה באש”.
אין דיכוי/עכבות * מפולת שלגים כפולה.
עמוד בלילה לאירועים שוליים (SEV אינו דומה לאימפקט).
התראות ללא רישום/בעלים.
פעולות ”ידניות” ללא צ 'טופ/ביקורת.
אין RCA/Action פריטים * תקריות חוזרות.

תקציר

התראה ותגובה זה תהליך, לא מערכת חוקים. Link SLO עם התראות רב-כוויות, לבנות הסלמה בתורנות ברורה, להוסיף שאטופים ולברוח חי, לנהל באופן קבוע RCAs והפעלות אימון. אז תקריות יהיו פחות תכופות, קצרות יותר וזולות יותר, ושחרורים יהיו צפויים יותר אפילו בשעות החמות של ה ־ iGaming.