Операциялар және басқару → Тосын оқиғаларды болдырмау

Инциденттерді болдырмау

1) Бұл не үшін қажет

Оқиғаға ең жақсы реакция - оның жоқтығы. iGaming/финтех үшін тоқтап тұрған әрбір минут - жоғалған мөлшерлемелер/депозиттер, провайдерлерден айыппұлдар, беделді тәуекелдер. Жүйелі алдын алу Change 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).
• Тәуелділіктер (ішкі/сыртқы), лимиттер/квоталар.
• «Safe mode» әрекеті (өшіріліп/жеңілдетіліп жатыр).
• Иесінің Runbook.

4) Guardrails (қорғаныс кедергілері)

Таймауттар мен брейкерлер: шақырушы сервисте ішкі таймаут сомасынан қысқа; брейкер қателер/жасырындылық өскен кезде ашылады.
Bulkhead-оқшаулау: даунстримдерге арналған қосылыстардың/воркерлердің жеке пулдары.
Rate limit & backpressure: көшкіннен және ретрай-дауылдан қорғау.
Деградация фичефлагтары: «ең төменгі режим» - жеңіл жауаптар, кэш-реплалар, ауыр фичтерді ажырату.
Мульти-вендор және фейловер: баламалы PSP/KYC, бағыттарды ауыстырып қосу.
Пішіндерді валидациялау: сызбалар/линерлер/саясаттар сызбалар мен лимиттерді қауіпсіз өзгерту үшін.

5) Өзгерістерді басқару (Change Management)

Pre-release gates: тесттер, қауіпсіздік, CDC (consumer-driven contracts), схемалардың үйлесімділігі.
Канар релизі + автогейттер: 1% → 10% → 100%; жану бюджетінің p99/error rate/өсуі кезінде авто-тоқта.
Feature flags: жылдам қайтару/деплойсыз мінез-құлықты ауыстырып қосу.
Release calendar: провайдерлерде ең жоғары спорт/турнирлер мен maintenance терезелерінен аулақ боламыз.
Post-deploy checks: автосіркелер, «дейін/кейін» өлшемдерін шектермен салыстыру.

6) Тестілеу алдын алу шарасы ретінде

Unit/contract/integration: OpenAPI/AsyncAPI, CDC провайдерге/моктарға қарсы келісімшарттар.
Load & stress: прайм-тайм үшін трафик профильдері; коннектілер/IOPS/квоталар лимиттеріне арналған тестілер.
Soak/long-haul: ресурстардың жылыстауы, сағат/күн деңгейінде кідірістердің өсуі.
Chaos/game-days: брокердің құлауы/PSP/KYC, аймақтың үзілуі, «баяу провайдер».
Disaster Recovery Drills: аймақтарды ауыстырып қосу және ДБ қалпына келтіру үшін тұрақты жаттығулар.

7) Тозуды ерте анықтау

Capacity-alerts: headroom, кезек лагтары, ДБ коннектілері, кэштердегі eviction.
SLO-burn-rate: бюджетті «жағудың» қауіпті жылдамдығы кезіндегі сигнал.
Бейімделетін табалдырықтар: жалған табалдырықтарды төмендетуге арналған маусымдық/тәуліктік шаблондар.
Құрамдас алерталар: «lag ↑ + HPA at max + open circuit» ⇒ жоғары тәуекел.
Vendor health: әрбір провайдер бойынша квоталар/таймауттар/қателер + шақыру құны.

8) Сыртқы провайдерлермен жұмыс

OLA/SLA, SLO: уағдаластықтарды біздің мақсаттарымызға байланыстыру.
Playbooks фейловер: PSP-X, PSP-Y бағыттары, токендер кэши, grace-депозиттер режимдері.
Сэндбокстар және келісімшарттар: әрбір мажорлық өзгеріс алдындағы тестілік флоу.
Провайдерлердің терезелері: дашбордтардағы аңдатпалар және автоматты suppress-ережелер.

9) Деректер, конфигалар және құпиялар

Өзгерістер саясаты: екі жұп көзді code-review, схема валидациясы/JSON/YAML.
Құпиялар: KMS/Secrets Manager, ротация, шеңберлер/рөлдер бойынша бөлу.
Жалаулар/лимиттер: аудит және жылдам қайтару арқылы API арқылы өзгерту.
Көші-қон: «екі қадамдық» (expand → migrate → contract), жиынтық кері үйлесімділік.

10) Командаларды оқыту және дайындығы

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

11) Профилактика дашбордтары (минимум)

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/DB/кэш/кезек бойынша Headroom, HPA/VPA дайындық, кэш жылыту.
• Провайдерлердің жай-күйі (квоталар, лимиттер, 24 сағат ішіндегі тозу), фейловер теңшелген.
• Канареялық гейттер қосылған, қайтару фичефлагтары иелеріне қолжетімді.
• SLO/Capacity алерталары белсенді, suppression жоспарлы жұмыстарға жазылған.
• Runbook 'және жаңартылған, on-call расталған, эскалация арналары жұмыс істейді.

14) Анти-паттерндер (не болдырмау керек)

«Үлкен түнгі релиздер» канарейка мен жалаусыз.
Барлық даунстримдерге ағындардың жалпы пулдары (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-алерттерді және capacity-алерттерді қосу.
2-апта: канареялық гейттер + фичефлагтар; базалық chaos-сценарийлер (провайдер/кезек).
Апта 3: «Change Safety» және «Vendor Panel» дашбордтары, фейловер-плейбуктер.
4-апта: DR-жаттығу (ішінара), ретроспектива және тоқсанға арналған 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: Егер ресурстар аз болса, бірінші кезекте не енгізу керек?
А: сыни жолдардағы SLO-burn-алерталар, канареялық гейттер және кері қайту фичефлагтары; содан кейін - тәуекелдер картасы және провайдерлер фейловері.

Q: Алдын алу «жұмыс істейтінін» қалай түсінуге болады?
A: Change Failure Rate төмендейді, алдын алынған инциденттердің үлесі артады, MTTR және алерт шуы төмендейді, «түнгі» пейджерлер саны азаяды.

Q: Тұрақты chaos-жаттығулар қажет пе?
А: Иә. Жаттығусыз фейловер мен DR қағазға қарағанда ұзағырақ және ауырсынады.