عملیات و → مدیریت پیشگیری از حادثه

پیشگیری از حادثه

1) چرا شما به آن نیاز دارید

بهترین واکنش به یک حادثه نداشتن آن است. برای iGaming/fintech، هر دقیقه از خرابی شرط/سپرده، جریمه از ارائه دهندگان، خطرات شهرت از دست رفته است. پیشگیری سیستمیک نرخ شکست تغییر را کاهش می دهد، SLO ها را تثبیت می کند و زمان فرمان را برای توسعه به جای خاموش کردن آتش سوزی آزاد می کند.

• به حداقل رساندن احتمال حوادث در مسیرهای بحرانی (سپرده، شرط، راه اندازی بازی، خروج).
• قبل از ضربه زدن به SLO و کیف پول، تخریب را از بین ببرید.
• محدود کردن شعاع شکست (شعاع انفجار) و سرعت بخشیدن به بازیابی.

2) اصول اساسی پیشگیری

1. SLO-اول و بودجه خطا: تغییرات منتشر نمی شوند اگر آنها در معرض خطر از بین بردن SLO و سوزاندن بودجه.
2. دفاع در عمق: لایه های حفاظت - از طرح های داده ها و پیکربندی ها به سیاست های شبکه و phicheflags.
3. طراحی برای شکست: قطع کننده ها، وقفه ها، عقب نشینی های jitter، بی نظمی، تخریب.
4. تغییرات کوچک و برگشتپذیر: افزایشهای کوچک + برگشت سریع (پرچمهای ویژگی/قناری).
5. قابلیت مشاهده توسط طراحی: معیارها/سیاهههای مربوط/آثار برای هر مرحله مهم و لینک.

3) نقشه مسیر ریسک و بحرانی

«نقشه درد» را با دامنه ها ایجاد کنید: پرداخت ها، شرط ها، بازی ها، KYC، تبلیغات، جکپات ها، محتوا.

• معیارهای کسب و کار (تبدیل، GGR، بررسی متوسط).
• SLO فنی (زمان تاخیر p95/p99، آپ تایم، میزان موفقیت).
• وابستگی ها (داخلی/خارجی)، محدودیت ها/سهمیه ها.
• رفتار «حالت امن» (که ما غیر فعال/ساده).
• صاحب کتاب.

4) گارد محافظ (موانع محافظ)

وقفه ها و قطع کننده ها: سرویس تماس دارای یک وقفه کوتاه تر از مجموع داخلی است ؛ breaker هنگامی که خطاها/تأخیر افزایش می یابد باز می شود.
جداسازی بدنه: استخرهای جداگانه اتصالات/کارگران برای جریان های پایین.
محدودیت نرخ و فشار پشتی: حفاظت در برابر بهمن و طوفان مجدد.
ficheflags تخریب: «حالت حداقل» - پاسخ آسان, کش تکرار, غیر فعال کردن ویژگی های سنگین.
چند فروشنده و feilover: PSP جایگزین/KYC، تغییر مسیر.
اعتبار سنجی configs: طرح ها/خطوط/سیاست ها برای تغییر ایمن ویژگی ها و محدودیت ها.

5) مدیریت تغییر

گیت های قبل از انتشار: تست، ایمنی، CDC (قراردادهای مبتنی بر مصرف کننده)، سازگاری طرح.
انتشار قناری + autogates: 1٪ → 10٪ → 100٪ ؛ توقف خودکار در p99/نرخ خطا/رشد بودجه احتراق.
پرچم های ویژگی: رفتار رول عقب/سوئیچ فوری بدون استقرار.
انتشار تقویم: جلوگیری از اوج ورزش/پنجره مسابقات و تعمیر و نگهداری در ارائه دهندگان.
چک های پس از استقرار: همگام سازی خودکار، مقایسه معیارهای قبل/بعد با آستانه.

6) آزمایش به عنوان یک اقدام پیشگیرانه

واحد/قرارداد/ادغام: قراردادهای OpenAPI/AsyncAPI، CDC در مقابل ارائه دهنده/moka.
بار و استرس: پروفایل های ترافیک برای زمان نخست ؛ تست برای محدودیت اتصال/IOPS/سهمیه.
خیس/مسافت طولانی: نشت منابع، افزایش تاخیر در افق ساعت/روز.
هرج و مرج/بازی روز: افت کارگزار/PSP/KYC، شکاف منطقه، «ارائه دهنده آهسته».
تمرین بازیابی فاجعه: آموزش منظم برای تعویض مناطق و بازگرداندن پایگاه های داده.

7) تشخیص زود هنگام تخریب

ظرفیت هشدار: headroom، تاخیر صف، اتصالات پایگاه داده، اخراج در انبارها.
SLO-burn-rate: سیگنال با نرخ خطرناک «سوزاندن» بودجه.
آستانه تطبیقی: فصلی/الگوهای روزانه برای کاهش کاذب.
هشدار کامپوزیت: «تاخیر ↑ + HPA در حداکثر + مدار باز» ⇒ خطر بالا.
سلامت فروشنده: سهمیه/زمان بندی/خطا برای هر ارائه دهنده + هزینه تماس.

8) همکاری با ارائه دهندگان خارجی

OLA/SLA ↔ SLO: پیوند موافقت نامه ها به اهداف ما.
Playbooks of the feilover: مسیرهای PSP-X ⇆ PSP-Y, حافظه پنهان رمز, حالت سپرده فضل.
سندباکس ها و قراردادها: تست جریان قبل از هر تغییر عمده.
پنجره های ارائه دهنده: حاشیه نویسی در داشبورد و قوانین سرکوب خودکار.

9) داده ها، پیکربندی ها و اسرار

سیاست های تغییر: کد بررسی دو جفت چشم، اعتبار سنجی طرح/JSON/YAML.
اسرار: مدیر KMS/اسرار، چرخش، جدایی از محیط زیست/نقش.
پرچم/محدودیت: تغییر از طریق API با ممیزی و بازگشت فوری.
Migrations: «دو مرحله ای» (expand → migration → contract), total backward compatibility.

10) آموزش و آمادگی تیم

آموزش در تماس: شبیه سازی حادثه، وظیفه سایه، runbook متمرکز "و.
فرمت های ارتباطی یکپارچه: قالب های وضعیت/تحویل/حادثه به روز رسانی.
فرهنگ ایمن: پس از مرگ بدون سرزنش، دلایل مکانیکی و اقدام پیشگیرانه.

11) داشبورد پیشگیری (حداقل)

ریسک و آمادگی: SLO/بودجه، headroom توسط لایه، «اتصالات آسیب پذیر بالا».
تغییر ایمنی: درصد قناری ها، ضربات، هشدارها «پس از انتشار»، CTR autogates.
پانل فروشنده: p95/خطا/سهمیه/هزینه برای هر ارائه دهنده، زمان پاسخ پشتیبانی فروشنده.
هرج و مرج/DR آمادگی: فرکانس ورزش، زمان تعویض منطقه، موفقیت بازیابی.
پیکربندی/SecOps: تغییرات پرچم/محدود/مخفی، ناهنجاری ها.

12) نمونه هایی از هشدارهای پیشگیرانه

ALERT SLOBurnRateHigh
IF slo_error_budget_burnrate{name="payments_api"} > 4 FOR 10m
LABELS {severity="critical", team="payments"}

ALERT PostDeployRegression
IF (api_p99_ms{service="bets"} > baseline_1d 1. 3) AND (release_window="canary")
FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderQuotaNearLimit
IF usage_quota_ratio{provider="psp_x"} > 0. 9 FOR 5m
LABELS {severity="warning", team="integrations"}

ALERT QueueLagAtRisk
IF (kafka_consumer_lag{topic="ledger"} > 5e6 AND rate(kafka_consumer_lag[5m]) > 5e4)
AND (hpa_desired == hpa_max)
FOR 10m
LABELS {severity="critical", team="streaming"}

13) چک لیست پیشگیری (روزانه/قبل از قله)

• تقویم اوج به روز (مسابقات، مسابقات، کمپین ها، پنجره های ارائه دهنده).
• Headroom توسط API/DB/کش/صف، آمادگی HPA/VPA، کش گرم کردن.
• دولت از ارائه دهندگان (سهمیه, محدودیت, تخریب در 24 ساعت), feiler پیکربندی.
• دروازه های قناری فعال هستند، پرچم های رول بک برای صاحبان در دسترس هستند.
• هشدار SLO/ظرفیت فعال هستند، سرکوب برای کار برنامه ریزی شده تجویز می شود.
• Runbook "و به روز شده، در تماس تایید شده، کانال های تشدید کار می کند.

14) ضد الگوهای (آنچه برای جلوگیری از)

«Big Night Releases» بدون قناری یا پرچم

مشترک سر از خط مسدود کردن استخر.
Retrays برای عملیات غیر idempotent و برای زمانبندی تنگنا.
عدم وجود هیسترزیس در هشدار → اره در امتداد آستانه.
ایمان کور به SDK فروشنده بدون مشاهده و مدیریت زمان.
«Let's Do the Prod» بدون صحنه/سندباکس و CDC.

15) KPI های پیشگیری

نرخ شکست را تغییر دهید (≤ هدف 10-15٪ یا هدف شما).
نرخ تشخیص قبل از حادثه: درصد حوادث جلوگیری شده در مرحله تخریب.

میانگین زمان بین حوادث (MTTI) и MTTR

حفاظت پوشش:٪ مسیرهای بحرانی با پرچم/breakers/timeouts/canary.

Chaos/DR cadence: فرکانس و موفقیت تمرینات

آمادگی فروشنده: متوسط زمان تعویض به ارائه دهنده پشتیبان.

16) شروع سریع (30 روز)

هفته 1: نقشه مسیر بحرانی، SLO ها و صاحبان ؛ شامل هشدار سوزاندن SLO و هشدار ظرفیت.
هفته 2: گیتس قناری + Phicheflags ؛ اسکریپت های هرج و مرج پایه (ارائه دهنده/صف).
هفته 3: داشبورد «تغییر ایمنی» و «پنل فروشنده»، playbooks feilover.
هفته 4: ورزش DR (جزئی)، برنامه گذشته نگر و سخت برای سه ماهه.

17) قالب (قطعات)

canary_policy:
guardrails:
- metric: api_p99_ms threshold: 1. 3 baseline_1d window: 10m action: pause_and_rollback
- metric: error_rate threshold: 2 baseline_1d window: 5m action: pause max_step: 10%
step_interval: 15m required_annotations: [release_notes, feature_flags, runbook_link]

safe_mode:
payments:
- freeze_heavy_providers
- enable_cached_token_flow
- route_to_psp_y_if(psp_x_error_rate > 5%)
games:
- limit_broadcasts
- reduce_lobby_heavy_widgets bets:
- raise_risk_score_threshold
- cache_odds_snapshot

18) سوالات متداول

س: اگر منابع کم است، ابتدا چه باید کرد ؟

A: هشدار سوزاندن SLO در مسیرهای بحرانی، دروازه های قناری و عقب نشینی phicheflags ؛ سپس - یک نقشه ریسک و یک ارائه دهنده جعلی.

س: چگونه می دانید که پیشگیری «کار می کند» ؟

A: نرخ شکست تغییر در حال کاهش است، نسبت حوادث جلوگیری شده افزایش می یابد، MTTR و سر و صدای هشدار کاهش می یابد، تعداد صفحات «شب» کاهش می یابد.

س: آیا ما نیاز به تمرینات منظم هرج و مرج داریم ؟

پاسخ: بله. بدون آموزش، یک feuillower و DR تقریبا همیشه طولانی تر و دردناک تر از آنها بر روی کاغذ به نظر می رسد.