Операциялар жана башкаруу → Инциденттердин алдын алуу

Инциденттердин алдын алуу

1) Эмне үчүн керек

Окуяга эң жакшы реакция - анын жоктугу. iGaming/fintech үчүн ар бир тыныгуу мүнөтү - жоголгон коюмдар/депозиттер, провайдерлердин айыптары, репутациялык тобокелдиктер. Системалуу алдын алуу Өзгөрүү Failure Rate азайтат, SLO турукташтырат жана өрт өчүрүү эмес, өнүктүрүү үчүн команда убакыт бошотулат.

• Критикалык жолдордо инциденттердин ыктымалдыгын азайтуу (депозит, коюм, оюнду баштоо, чыгаруу).
• SLO жана капчыкка сокку чейин деградация кармап.
• Ажырым радиусун чектөө (blast radius) жана калыбына келтирүүнү тездетүү.

2) Алдын алуунун негизги принциптери

1. SLO-first жана error budget: өзгөрүүлөр SLO талкалап жана бюджетти өрттөп коркунучу бар болсо, бошотулган эмес.
2. Defence in depth: коргоо катмарлары - маалымат схемалары жана конфигурациялардан тармактык саясаттарга жана физикалык тармактарга чейин.
3. Design for failure: брейкерлер, таймауттар, джиттер менен ретрайлер, демпотенттүүлүк, деградациялар.
4. Small & reversible changes: кичинекей инкременттер + тез артка (feature flags/канарейка).
5. Observability by design: метрика/Логи/ар бир маанилүү кадам жана байланыш үчүн соода.

3) Тобокелдиктердин жана критикалык жолдордун картасы

"Оору картасын" домендер боюнча түзүңүз: Payments, Bets, Games, KYC, Promotions, Jackpots, Content.

• Бизнес-метрика (конверсия, GGR, орточо чек).
• Техникалык SLO (latency p95/p99, uptime, success rate).
• Көз карандылык (ички/тышкы), лимиттер/квоталар.
• "Коопсуз режим" жүрүм-туруму (өчүрүп/жөнөкөйлөтүү).
• Runbook ээси.

4) Guardrails (коргоочу тоскоолдуктар)

Таймауттар жана брейкерлер: чакыруучу сервисте ички суммадан кыска таймаут; брейкер каталар/жашыруун көбөйгөндө ачылат.
Bulkhead-обочолонуу: өзүнчө бассейндер байланыштар/workers боюнча downstream.
Rate limit & backpressure: кар көчкү жана retrai бороон коргоо.
Ficheflagy деградация: "минималдуу режими" - жонокой жооптор, кэш-реплалар, оор сүрөттөрдү өчүрүү.
Multi-сатуучу жана Failover: PSP/KYC, жолдорду которуу.
Конфигурацияларды валидациялоо: схемалар/линерлер/эрежелер коопсуз өзгөрүүлөр жана лимиттер үчүн.

5) Өзгөрүүлөрдү башкаруу (Change Management)

Pre-release gates: тесттер, коопсуздук, CDC (consumer-driven contracts), шайкештиги схемалар.
Канар релиз + автогейттер: 1% → 10% → 100%; p99/error rate/күйүүчү бюджеттин өсүшү менен auto-stop.
Feature flags: deplois жок жүрүм-турумдун заматта артка/которуу.
Release calendar: спорт/турнирлер жана maintenance провайдерлер жогорку терезелер качуу.
Post-deploy текшерүүлөр: Auto Smoke, "чейин/кийин" босоголор менен салыштыруу.

6) алдын алуу чарасы катары сыноо

Unit/contract/integration: OpenAPI/AsyncAPI келишимдери, CDC каршы провайдер/мок.
Load & стресс: прайм-тайм үчүн трафик профилдери; connections/IOPS/квота чектери боюнча тесттер.
Soak/long-haul: ресурстардын агып чыгышы, саат/күндүн горизонтунда кечигүүлөрдүн өсүшү.
Chaos/оюн-күндөр: брокердин кулашы/PSP/KYC, аймактын ажырымы, "жай провайдер".
Disaster Recovery Drills: үзгүлтүксүз окутуу аймактарды которуу жана DD калыбына келтирүү.

7) Бузулууларды эрте аныктоо

Capacity-alerts: headroom, лагдар кезек, DD коннектилер, eviction кэш.
SLO-burn-rate: коркунучтуу ылдамдык "өрттөп" бюджеттин сигнал.
Adaptive босоголор: сезондук/күнүмдүк шаблондор жалган азайтуу үчүн.
Курамдык алерталар: "lag ↑ + HPA at max + open circuit" ⇒ жогорку тобокелдик.
Vendor ден соолук: ар бир провайдер үчүн квота/тайм/ката + чалуулардын баасы.

8) Тышкы провайдерлер менен иштөө

OLA/SLA, SLO: Биздин максаттарга макулдашууларды байлап.
Playbooks Failover: PSP-X PSP-Y жолдору, кэш-токендер, grace-депозиттик режимдери.
Sandboxes жана келишимдер: ар бир негизги өзгөрүү алдында сыноо Flow.
Терезелер провайдерлер: dashboard аннотациялар жана автоматтык suppress эрежелери.

9) Маалыматтар, чыр-чатактар жана сырлар

Өзгөртүү саясаты: code-review эки жуп көз, валидация схемалары/JSON/YAML.
Secrets: KMS/Secrets Manager, айлануу, айлана-чөйрө/ролдорду бөлүштүрүү.
Желектер/лимиттер: аудит жана дароо артка кайтаруу менен API аркылуу өзгөртүү.
Миграциялар: "эки кадамдуу" (expand → migrate → contract), жалпы тескери шайкештик.

10) Окутуу жана команда даярдыгы

On-call тренингдер: инциденттердин симуляциялары, Shadow-милдети, борборлоштурулган runbook 'ы.
Коммуникациянын бирдиктүү форматтары: статустардын/хендоверлердин/инцидент-жаңылоонун шаблондору.
Коопсуз маданият: айыпсыз постмортем, механикалык себептер жана алдын алуу аракеттери.

11) Dashbord алдын алуу (минималдуу)

Risk & Readiness: SLO/бюджет, катмарлары боюнча headroom, "жогорку аялуу байланыштар".
Change Safety: канарейка пайызы, артка чегинүү, алерта "чыккандан кийин", CTR автогейт.
Vendor Panel: p95/error/квота/ар бир провайдер үчүн наркы, сатуучу саппорттун жооп убактысы.
Chaos/DR Readiness: көнүгүүлөрдүн жыштыгы, аймакты которуу убактысы, калыбына келтирүү ийгилиги.
Config/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) Алдын алуу тизмеси (күн сайын/чокусуна чейин)

• Учурдагы чокуларынын календары (дан, турнир, кампаниялар, терезелер).
• API/DD/кэш/кезек боюнча Headroom, HPA/VPA даяр, кэш жылытуу.
• Провайдерлердин абалы (квоталар, лимиттер, 24h үчүн деградациялар), Feylover орнотулган.
• Канар гейттери камтылган, кайтаруу фичефлагдары ээлерине жеткиликтүү.
• SLO/Capacity Alerts активдүү, suppression пландаштырылган иш жазылган.
• Runbook 'жана жаңыланган, on-call тастыкталган, эскалация каналдары иштеп жатат.

14) Анти-үлгүлөрү (эмне качуу)

Канарейка жана желектери жок "Чоң түнкү релиздер".
Бардык downstream жалпы көлмөлөр агымы (head-of-line blocking).
Демпотенттик эмес операцияларга жана тар жерлердин таймауттарына ретрациялар.
Алерттерде гистерезистин жоктугу → босогодо кесүү.
байкоо жана убакыт башкаруу жок сатуучу SDK сокур ишеним.
Стейдж/сандбокс жана CDC жок "Прод жасайбыз".

15) KPI алдын алуу

Change Failure Rate (максат ≤ 10-15% же максаттуу).
Pre-Incident Detect Rate: деградация стадиясында алдын инциденттердин үлүшү.
Mean Time Between Incidents (MTBI) и MTTR.
Coverage коргоо: желектер/брейкер/убакыт/канарейка менен маанилүү жолдордун%.
Chaos/DR cadence: көнүгүүлөрдүн жыштыгы жана ийгилиги.
Vendor readiness: резервдик провайдерге өтүүнүн орточо убактысы.

16) Тез баштоо (30 күн)

Апта 1: маанилүү жолдордун картасы, SLO жана ээлери; SLO-burn-alerts жана capacity-alerts кирет.
Апта 2: Канарейка гейтс + фичефлагдар; негизги chaos-жагдайлар (провайдер/кезек).
Апта 3: "Change Safety" жана "Vendor Panel" дашборддору, фейловер плейбуктар.
Жума 4: DR-машыгуу (жарым-жартылай), retrospective жана hardening 'a чейрек планы.

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) FAQ

Q: ресурстар аз болсо, биринчи кезекте эмне киргизүү керек?
A: SLO-burn-критикалык жолдор боюнча алерттер, канареялык гейтс жана ficheflags кайра; андан кийин - тобокелдик картасы жана провайдерлердин фейловери.

Q: алдын алуу "иштейт" кантип түшүнүүгө болот?
A: Change Failure Rate төмөндөйт, алдын алган окуялардын үлүшү өсөт, MTTR жана алерт ызы-чуусу төмөндөйт, "түнкү" пейджерлердин саны азаят.

Q: үзгүлтүксүз chaos-машыгуу керек?
A: Ооба. Эч кандай машыгуу Feylover жана DR дээрлик дайыма узак жана кагаз бетинде көрүнгөндөн азаптуу.