تنبيه وفشل الاستجابة

(القسم: التكنولوجيا والهياكل الأساسية)

موجز موجز

التنبيه القوي هو إشارة إلى انتهاك قيمة المستخدم، وليس مجرد "مقياس أحمر. "بالنسبة إلى iGaming، فإن بوابات SLO (زمن الوصول، والتوافر، وتحويل الدفع، و Time-to-Wallet)، وقواعد الحرق المتعددة، والوضوح عند الطلب، والتصعيد، وأدوار ChatOps والكتيبات الجاهزة مهمة. الهدف هو رؤية الانحراف بسرعة، وإبلاغ أولئك الذين يمكنهم التصحيح، وإصلاح المعرفة من أجل الرد بشكل أسرع وأرخص في المرة القادمة.

1) الأساسيات: من المقاييس إلى العمل

SLI → SLO → Alert - الجودة المقاسة → المستوى المستهدف → «الميزانية في حالة».
الشدة (SEV): SEV1 - حرجة (الإيرادات/GGR في خطر)، SEV2 - خطيرة، SEV3 - معتدلة، SEV4 - طفيفة.
الأثر/الإلحاح: من يعاني (الكل/المنطقة/المستأجر/القناة) ومدى الإلحاح (TTW↑، p99↑، الخطأ - rate↑).
إمكانية العمل: لكل إنذار - إجراء محدد (دفتر التشغيل + المالك).

2) تصنيف الإشارة

ТехSLO: p95/p99 latency API، معدل الخطأ، التشبع (CPU/IO/GPU)، تأخر الطابور.
BusinessSLO: تحويل الدفع (attempt→success)، Time-to-Wallet (TTW)، نجاح المراهنة، إطلاق اللعبة.
طرق الدفع: مقاييس خاصة بـ PSP (مهلة/ارتفاع في الانخفاض).
الأمامي/المحمول: مقاييس RUM (LCP/INP)، معدل الانهيار، السيناريو التركيبي (تسجيل الدخول/الإيداع/السعر/الناتج).

3) سياسة التنبيه: SLO ومعدل الحرق

أمثلة SLI/SLO

توافر المدفوعات ≥ 99. 9 ٪/30d p95 '/deposit '≤ 250 ms/30d

تحويل 'payments_attempt→success ≥ خط الأساس − 0. 3 ٪/24 ساعة

TTW p95 ≤ 3 دقائق/24 ساعة

متعدد النوافذ/متعدد الحروق (идея PromQL)

حرق سريع: انتهاك SLO 5-10 × أسرع من المعتاد (صفحة تنبيه في 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) تقليل الضوضاء وجودة الإشارات

المصدر الصحيح للحقيقة: التغيير بالتجمعات (قواعد التسجيل)، وليس بالتعبيرات «الخام» الثقيلة.
Deduplication - Alertmanager groups by 'service/region/severity'.
التسلسل الهرمي: التنبيه الأول للأعمال/SLI، أدناه - المقاييس التقنية كتشخيص.
القمع: أثناء عمليات الصيانة/الإصدار المخطط لها (التعليق)، أثناء حوادث المنبع.
Cardinality: لا تستخدم «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 = الصفحة → PagerDuty/SMS; الباقي هو Slack/Ticket. يثبط التثبيط «الضجيج» للمستويات المنخفضة مع SEV النشط أعلاه.

6) تنبيه جرافانا (كطبقة إضافية)

قواعد التنبيه المركزية على لوحات القيادة (Prometheus/Loki/Cloud).
نقاط الاتصال: PagerDuty/Slack/Email، سياسات الإخطار لكل مجلد.
الصمت: الأعمال المخطط لها والهجرات والإطلاقات.
لقطات مع لقطة شاشة تلقائية للوحة في التذكرة.

7) العمليات أثناء الطلب والعمليات الحية

التناوب: الخط الأول (SRE/platform)، الخط الثاني (مالك الخدمة)، الثالث (DB/Payments/Sec).
ردود فعل SLA: التعرف ≤ 5 دقائق (SEV1)، التشخيص ≤ 15 دقيقة، التواصل كل 15-30 دقيقة.
قنوات الواجب: "# incident-warroom'،" # تحديثات الحالة "(حقائق فقط).
دفاتر التشغيل: رابط في كل تنبيه + أوامر ChatOps السريعة («/rellack »و «/freeze» و «/scale »).
إنذارات التدريب: شهرية (التحقق من الأشخاص، القنوات، أهمية ruabook).

8) الحوادث: دورة الحياة

1. الكشف (التنبيه/التقرير/المواد التركيبية) → الاعتراف عند الطلب.
2. الفرز: تحديد SEV/متأثر/فرضية، غرفة حرب مفتوحة.
3. التثبيت: اللفات/التراجع/التحجيم/phicheflags.
4. الاتصالات: نموذج الحالة (انظر أدناه)، ETA/الخطوات التالية.
5. خاتمة: تأكيد استرداد المدار الثابت بالنسبة للأرض.
6. مراجعة ما بعد الحادث (RCA): بعد 24-72 ساعة، لا توجد رسوم أو عناصر عمل.

• ما هو المعطل/المتأثر (المنطقة/المستأجر/القناة)
• عندما بدأت/SEV
• التدابير المؤقتة (التخفيف)
• تحديث الحالة التالي في دقائق N
• الاتصال (مدير الحوادث)

9) تفاصيل iGaming: مناطق وتنبيهات «الألم»

المدفوعات/TTW: حصة من مهلات PSP، زيادة في فشل الكود، TTW p95> 3 م.
قمم البطولة: p99 API/وقت بدء اللعبة/تأخر الانتظار ؛ تعزيز الحدود/النطاق التلقائي.
استنتاجات الأموال: جيش تحرير السودان للتحقق اليدوي/الضوابط اليدوية، الحدود حسب البلد.
مقدمو الألعاب: التوفر حسب الاستوديو، وقت بدء الجلسة، انخفاض الإطلاق.
RG/الامتثال: دفعات من الجلسات الطويلة/» dogon»، تتجاوز العتبات - ليست صفحة، ولكن تذكرة + إشعار لفريق RG.

10) أمثلة القاعدة (اختياري)

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.

اختصارات الأمر: «/بدء الحادث »، «/تحديث الحالة»، «/الاتصال <المالك> »، «/grafana »

تشدد الروبوتات السياق: أحدث تذاكر، رسم بياني للتبعية، نماذج، تذاكر مرتبطة.

12) العمل بعد الحادث (RCA)

حقائق: الجدول الزمني، ما الذي رأى/جرب، ما الذي نجح.
السبب الجذري: أسباب فنية وتنظيمية.
الاكتشافات والدفاعات: أي الإشارات ساعدت/فشلت.
بنود العمل: مهام محددة (SLO/alerts/codes/limits/tests/runabook).
التواريخ المستحقة والمالكون: الشروط والمسؤوليات ؛ في غضون 2-4 أسابيع.

13) قائمة التنفيذ المرجعية

1. حدد SLI/SLO للتدفقات الرئيسية (API/Payments/Games/TTW).
2. قم بإعداد قواعد التسجيل والتنبيهات متعددة الحروق + توجيه Alertmanager.
3. أدخل عند الطلب مع التناوب ورد الفعل SLO والتصعيد.
4. ربط التنبيهات بكتب التشغيل وأوامر ChatOps.
5. ضبط قمع/هدوء النوافذ، إصدار/عمل شروح.
6. اجعل إنذارات التعلم وسيناريوهات يوم اللعبة (انخفاض PSP، ارتفاع p99، ارتفاع تأخر الانتظار).
7. قياس جودة التنبيه: MTTA/MTTR،% صاخب/خاطئ، تغطية SLO.
8. التقييمات التعاونية الإقليمية المنتظمة وتنقيح العتبات/العمليات.
9. أدخل حالة اتصال الأعمال/الدعم (النماذج).
10. قم بتوثيق كل شيء كرمز: القواعد والطرق وروابط الرونابوك.

14) الأنماط المضادة

التنبيه من خلال تنبيه «كل مقياس →»، تجاهل.
لا SLO → ليس من الواضح ما هو «الطبيعي» وما هو «المشتعل».
لا يوجد قمع/تثبيط → تكرار الانهيار الجليدي.
صفحة في الليل للأحداث البسيطة (SEV لا يمكن مقارنتها بـ Impact).
تنبيهات بدون دفتر تشغيل/مالك.
إجراءات «يدوية» بدون ChatOps/مراجعة حسابات.
لا توجد بنود RCA/Action → تكرار الحوادث.

موجز

التنبيه والاستجابة عملية وليست مجموعة من القواعد. اربط SLO بتنبيهات متعددة الحروق، وقم ببناء تصعيد واضح عند الطلب، وأضف ChatOps والرونابوك المباشر، وأجري بانتظام RCAs وجلسات تدريبية. عندها ستكون الحوادث أقل تكرارًا وأقصر وأرخص، وستكون الإصدارات أكثر قابلية للتنبؤ حتى في الساعات الحارة من iGaming.