هشدار و پاسخ به شکست

(بخش: تکنولوژی و زیرساخت)

خلاصه ای کوتاه

هشدار قوی یک سیگنال نقض ارزش کاربر است و نه فقط یک «متریک قرمز». برای iGaming، دروازه های SLO (تاخیر، در دسترس بودن، تبدیل پرداخت، زمان به کیف پول)، قوانین چند رایت، روشن در تماس، تشدید، ChatOps و نقش های runbooks مهم هستند. هدف این است که به سرعت انحراف را ببینید، اطلاع کسانی که می توانند تصحیح، و رفع دانش به منظور واکنش نشان می دهند و حتی سریع تر و ارزان تر دفعه بعد.

1) مبانی: از معیارها تا عمل

SLI → SLO → Alert - کیفیت اندازه گیری شده → سطح هدف → «بودجه» است.
شدت (SEV): SEV1 - بحرانی (درآمد/GGR در معرض خطر)، SEV2 - جدی، SEV3 - متوسط، SEV4 - جزئی.
تأثیر/فوریت: چه کسی رنج می برد (همه/منطقه/مستاجر/کانال) و چقدر فوری (TTW↑، p99↑، خطا - rate↑).
قابلیت اجرا: برای هر زنگ - یک اقدام خاص (runbook + مالک).

2) طبقه بندی سیگنال

ТехSLO: API تاخیر p95/p99، نرخ خطا، اشباع (CPU/IO/GPU)، تاخیر صف.
BusinessSLO: تبدیل پرداخت (تلاش → موفقیت), زمان به کیف پول (TTW), موفقیت شرط بندی, راه اندازی بازی.
مسیرهای پرداخت: معیارهای خاص PSP (خوشه زمان/کاهش).
جلو/تلفن همراه: معیارهای RUM (LCP/INP)، نرخ سقوط، سناریو synthetics (ورود/سپرده/نرخ/خروجی).

3) سیاست هشدار: SLO و نرخ سوختن

نمونه های SLI/SLO

در دسترس بودن پرداخت api ≥ 99. 9 ٪/30d p95 '/سپرده '≤ 250 میلی ثانیه/30d

تبدیل "payments _ attempt → success ≥ baseline − 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) کاهش نویز و کیفیت سیگنال

منبع صحیح حقیقت: تغییر با aggregates (قوانین ضبط)، و نه عبارات سنگین «خام».
Deduplication - گروه های Alertmanager بر اساس «سرویس/منطقه/شدت».
سلسله مراتب: اولین هشدار به کسب و کار/SLI، در زیر - معیارهای فنی به عنوان تشخیص.
سرکوب: در طول نگهداری/انتشار برنامه ریزی شده (حاشیه نویسی)، در حوادث بالادست.
Cardinality: از user _ id/session _ id در برچسب های هشدار استفاده نکنید.
هشدار تست: به طور منظم «آموزش» باعث (چک کردن کانال ها، نقش ها، لینک های runabook).

5) مسیریابی و تشدید Alertmanager

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 ؛ بقیه بلیط/بلیط است. مهار سرکوب «اعتیاد به مواد مخدره» از سطوح پایین تر با SEV فعال بالا.

6) هشدار گرافانا (به عنوان لایه اضافی)

قوانین هشدار متمرکز در داشبورد (Prometheus/Loki/Cloud).
نقاط تماس: PagerDuty/Slack/ایمیل، سیاست های اطلاع رسانی در هر پوشه.
سکوت: کارهای برنامه ریزی شده، مهاجرت، انتشار.
عکس های فوری با یک تصویر خودکار از پانل در بلیط.

7) در تماس و فرآیندهای زنده

چرخش: خط اول (SRE/پلت فرم)، خط دوم (صاحب سرویس)، سوم (DB/Payments/Sec).
واکنش SLA: تشخیص ≤ 5 دقیقه (SEV1)، تشخیص ≤ 15 دقیقه، ارتباط هر 15-30 دقیقه.
کانال های وظیفه: «# incident-warroom»، «# status-updates» (فقط حقایق).
Runbooks: لینک در هر هشدار + دستورات سریع ChatOps ('/rollback '، '/freeze'، '/scale ').
هشدارهای آموزشی: ماهانه (چک کردن افراد، کانال ها، ارتباط runabook).

8) حوادث: چرخه زندگی

1. تشخیص (هشدار/گزارش/synthetics) → تایید در تماس.
2. Triage: تعیین SEV/تحت تاثیر/فرضیه، اتاق جنگ باز است.
3. تثبیت: رول/بازگشت/پوسته پوسته شدن/phicheflags.
4. ارتباطات: قالب وضعیت (پایین را ببینید)، ETA/مراحل بعدی.
5. بسته شدن: تأیید بازیابی SLO.
6. بررسی پس از حادثه (RCA): پس از 24-72 ساعت، بدون اتهام، موارد اقدام.

• چه چیزی شکسته/آسیب دیده (منطقه/مستاجر/کانال)
• هنگامی که شروع/SEV
• اقدامات موقت (کاهش)
• به روز رسانی وضعیت بعدی در N دقیقه
• تماس (مدیر حوادث)

9) مشخصات iGaming: مناطق «درد» و هشدار

پرداخت/TTW: سهم زمان PSP، افزایش خرابی کد، TTW p95> 3m.
قله مسابقات: p99 API/بازی شروع زمان/تاخیر صف ؛ ارتقاء محدودیت ها/مقیاس خودکار.
نتیجه گیری از بودجه: SLA از backhoe/چک دستی، محدودیت های کشور.
ارائه دهندگان بازی: در دسترس بودن توسط استودیو، زمان شروع جلسه، قطره راه اندازی.
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) ChatOps و اتوماسیون

هشدار خودکار ارسال با دکمه های عمل: توقف canary، Rollback، Scale + N.

اختصارات فرمان: '/incident start ', '/status update', '/call ', '/grafana '

رباتها زمینه را محکم می کنند: آخرین deploi، نمودار وابستگی، نمونه ها، بلیط های مرتبط.

12) کار پس از حادثه (RCA)

Factbox: جدول زمانی، چه چیزی را دید/سعی کرد، چه کار کرد.

علت ریشه ای: دلایل فنی و سازمانی

شناسایی و دفاع: که سیگنال کمک کرد/شکست خورد.
موارد اقدام: وظایف خاص (SLO/هشدار/کد/محدودیت/تست/runabook).
تاریخ و صاحبان: شرایط و مسئولیت ها ؛ جلسه پیگیری در 2-4 هفته.

13) چک لیست پیاده سازی

1. SLI/SLO را برای جریانهای کلیدی (API/Payments/Games/TTW) تعریف کنید.
2. تنظیم قوانین ضبط و هشدار چند رایت + مسیریابی Alertmanager.
3. تماس با چرخش، SLO واکنش و افزایش سرعت را وارد کنید.
4. هشدار لینک به runbooks و دستورات ChatOps.
5. پیکربندی پنجره های سرکوب/آرام، حاشیه نویسی انتشار/کار.
6. ایجاد آلارم های یادگیری و سناریوهای روز بازی (افت PSP، افزایش P99، افزایش تاخیر صف).
7. اندازه گیری کیفیت هشدار: MTTA/MTTR،٪ پر سر و صدا/نادرست، پوشش توسط SLO.
8. RCA های منظم و تجدید نظر در آستانه/فرایندها.
9. وضعیت ارتباطات تجاری/پشتیبانی (قالب ها) را وارد کنید.
10. همه چیز را به عنوان کد مستند کنید: قوانین، مسیرها، لینک های runabook.

14) ضد الگوهای

هشدار توسط «هر متریک →» هشدار fetig، نادیده گرفتن.
روشن نیست که چه چیزی «طبیعی» است و چه چیزی «در آتش است».
بدون سرکوب/مهار → تکراری بهمن.
صفحه در شب برای رویدادهای جزئی (SEV قابل مقایسه با Impact نیست).
هشدار بدون runbook/مالک.
اقدامات «دستی» بدون ChatOps/حسابرسی.
بدون RCA/موارد اقدام → تکرار حوادث.

خلاصه

هشدار و پاسخ یک فرآیند است، نه مجموعه ای از قوانین. لینک SLO با هشدار چند رایت، ساخت یک تشدید روشن در تماس، اضافه کردن ChatOps و runabook زندگی می کنند، به طور منظم انجام RCA ها و جلسات آموزشی. سپس حوادث کمتر مکرر، کوتاه تر و ارزان تر خواهد بود و نسخه ها حتی در ساعات گرم iGaming قابل پیش بینی تر خواهند بود.