Disaster Recovery Plan

1）目的、領域和原則

目標：確保災難發生後（網絡、文多爾、地緣政治）及時恢復IT平臺，不違反監管要求、合同和玩家期望。
領域：生產環境（遊戲回路，支付，KYC/AML，對立面，DWH/BI店面），整合（PSP，KYC，CDN，工作室/聚合器），基礎設施（雲/K8s，網絡，秘密/密碼），數據（DB，文件，Logi）。
原則：安全至上，RTO/RPO最小化，自動化和可重復性（IaC），「默認可證明性」，定期練習。

2）系統分類和恢復目標

2.1臨界水平

Tier-1（至關重要）：付款/卡索，核心遊戲，登錄/身份驗證，CUS/制裁。
Tier-2：實時分析、營銷/CRM、DWH報告。
Tier-3：國內門戶、支助服務。

2.2個目標

RTO（恢復時間目標）：恢復服務之前的時間。
RPO（恢復點目標）：允許的時間數據丟失。
RTA （Recovery Time Actual）/RPA （Recovery Point Actual）：實際值記錄在報告中。
MTO/MBCO：最大可移植停機時間/最低可接受的服務級別（降級模式）。

目標示例（用於參考）：

Tier-1-RTO ≤ 30-60分鐘，RPO ≤ 15分鐘；Tier-2 — RTO ≤ 4 ч, RPO ≤ 1 ч;Tier-3 — RTO ≤ 24 ч, RPO ≤ 24 ч.

3） DR策略和體系結構

3.1個拓撲

Active-Active（多區域）：最小RTO/RPO,需要一致性和沖突消除。
Active-Standby（熱/熱/冷）：成本/速度平衡。
Geo數據和密鑰分離：KMS/HSM每個區域，BYOK，獨立復制路徑。

3.2數據和備份

PITR（點對點恢復）：Tier-1的交易日誌、存檔間隔≤ 5-15分鐘。
Snepshots/full back：每日/每小時，3-2-1計劃存儲（3份副本，2個媒體，1個離線/離線）。
不可移動性：WORM/對象光束，工件簽名/散列鏈。
恢復目錄：備用庫存、完整性、保質期、測試解密。

3.3應用程序和集成

Statles服務：通過IaC/CI快速部署。
Stateful組件：一致的snapshots，發射序列的編排。
集成（PSP/KYC/聚合器）：雙重封裝，倒退端口，簽名的webhooks，重新交付控制（等效性）。

4）恢復順序（通用運行簿）

1.DR腳本公告→指定DR事件指揮官（DR-IC），啟動戰爭室。
2.損壞評估：受影響的區域/子系統,相關RTA/RPA, failover激活解決方案。
3.隔離/容器：阻止源原因（網絡ACL、秘密、禁用提供程序）。

4.DR初始化：

網絡/保密/KMS →
DB/存儲/緩存 →
API/服務 → 前端/CDN →外部集成。
5.完整性檢查：反。金額，「幹」查詢，健康樣本。
6.財務/遊戲的重新分配：付款，利率，資產負債表，交易的平均重復。
7.通訊：狀態頁面，參與者/合作夥伴/監管機構；更新時間線。
8.觀察和穩定：隨著正常化而停用降解。
9.後太平間：RCA，CAPA，DRP更新。

5）專用runbooks（片段）

5.1主區損失（Active-Standby → Standby）

yaml trigger: "loss_of_region_primary OR quorum_fail >= 5m"
prechecks:
- "secondary region green"
- "replication_lag <= 15m"
steps:
- DR-IC approves region_failover
- Platform: GSLB switch → secondary
- Data: promote replicas, enable PITR streams
- Apps: redeploy with region vars; warm caches
- QA: smoke tests (login, deposit, bet, payout)
- Comms: status-page + partner notice rollback: "switch-back after 60m stability window"

5.2 DB 腐敗/PITR復原

yaml trigger: "data_corruption_detected OR accidental_drop"
steps:
- Freeze writes (feature flag), snapshot evidence
- Restore to timestamp T (<= RPO)
- Reindex/consistency checks
- Replay idempotent events from queue (from T)
- Reopen writes in throttle mode validation: ["checksum_ok", "balance_diff=0", "orders_gap=0"]

5.3 PSP在DR模式下降解

yaml trigger: "auth_rate_psp1 < baseline-3σ for 15m"
steps:
- Route X%→psp2, cap payouts, enable manual VIP
- Reconciliation plan T+0, alerts Finance
- Notify players in cashier; vendor escalation

6）數據完整性和重構

財務：存款/付款/傭金對賬，重復發送通知和重復數據消除webhook（idempotency-keys）。
遊戲回路：恢復回合狀態，必要時重播計算，防止雙重註銷/累積。
日誌/審核：前後WORM邏輯映射、簽名/散列、一致性報告。
DPO/Compliance報告：如果PII受到影響,則記錄比例、時間線和通知。

7）關鍵技術的DR（示例）

DBMS（關系）：同步/異步復制，WAL插槽，快速推廣，熱站立。
NoSQL/緩存： multiclaster, TTL致殘,冷填充,避免交叉區域寫入而不會發生沖突。
隊列/流：鏡像拓撲/群集、偏移量控制、消費者重復數據消除。
對象存儲：轉化，復制到「垃圾箱」，對象清單和保留策略。
CI/CD/工件：註冊表副本，工件簽名，關鍵容器的離線副本。
秘密/密碼：按區域KMS，獨立根鍵，帶日誌的斷面玻璃和TTL。

8） DR的安全和隱私

最小權利原則：通過單獨的角色/配置文件（JIT/PAM）進行DR訪問。
固定備份：離線/離線,恢復和解密測試。
監管窗口：事件提交和通知決定（監管機構/銀行/PSP/用戶）以及Legal/DPO。
可跟蹤性：DR命令的完整動作日誌，時間線簽名。

9）練習和測試類型

Walkthrough/Review：驗證文檔/角色/聯系人（季度）。
Tabletop：將腳本運行到「幹燥」並解決沖突。
技術部分：恢復單獨的服務/DB。
Full Failover/Switch-over：將流量和數據遷移到備用區域。
混沌日（可控制）：註射故障/故障以檢查自動機。

每個測試→報告RTA/RPA，偏差列表，CAPA和DRP更新。

10）度量（KPI/KRI）

RTA/RPA vs RTO/RPO（Tier-1）：≥ 95％的合規性。
DR Test Coverage： ≥ 2個完整的DR測試/年+定期部分測試。
Time-to-First-Status： DR公布後≤ 15分鐘。
Reconciliation Zero-Diff：所有現金和遊戲對賬均無差異。
Backup Integrity： 100%的選擇性恢復在本季度成功。
Config Drift：初級/中級之間的漂移（IaC比較）。
DR中的安全性：具有日誌和確認的100％ DR操作。

11） RACI（簡稱）

活動	DR-IC	Platform/SRE	Data/DBA	Security/DPO	Payments	Risk/KYC	Product/Eng	Comms/PR	Legal/Compliance
DR公告	A/R	C	C	C	C	C	C	C	C
Feilover/攀登	C	A/R	R	C	C	C	R	I	I
驗證/健康	C	R	A/R	C	C	C	R	I	I
Reconciliation	I	R	A/R	I	R	R	R	I	I
溝通方式	I	I	I	C	C	C	I	A/R	C
監管機構/PSP	I	I	I	A/R	R	R	I	C	R
後太平間/SARA	A/R	R	R	R	R	R	R	C	C

12）支票單

12.1 DR準備就緒

更新DR命令/供應商/監管機構的聯系人
復制為綠色,PITR啟用,備份測試解密
JIT/PAM可用性，「破玻璃」已驗證
Feilover花花公子和環境變量有效性
PSP/KYC 雙重免責聲明/webhooks，替代路線
狀態頁面/消息模板準備就緒

12.2在DR期間

指定DR-IC，打開戰爭室，事件時間線
隔離原因、選擇腳本、運行runbooks
完整性檢查,健康測試,煙霧測試
首次公開升級≤ 15分鐘；向SLA合作夥伴/監管機構發出通知
扣押文物進行調查

12.3 DR之後

完整的金錢/遊戲和雜誌對賬
後太平間，RCA，CAPA與日期和所有者
DRP/BIA/聯系人/IaC更新
虛構的重新測試計劃

13）模板（片段）

13.1個服務卡（DR護照）

yaml service: payments-api tier: 1 dependencies: [auth, ledger-db, psp1, psp2, kms-eu]
rto: "45m"
rpo: "15m"
backups: {pitr: true, snapshots: "hourly", immutability: "7d"}
failover: {mode: "active-standby", regions: ["eu1","eu2"]}
runbooks: ["rb_failover_region", "rb_psp_degradation"]
health_checks: ["/healthz","/readyz"]

13.2 DR測試報告（摘錄）

yaml test_id: DR-2025-10 scope: "Full switch-over eu1→eu2"
rta: "27m"
rpa: "11m"
issues:
- id: CAPA-117, desc: "долгое прогревание кэша", due: 2025-11-20, owner: SRE
- id: CAPA-118, desc: "устаревший webhook PSP#2", due: 2025-11-12, owner: Payments reconciliation: {finance: "ok", games: "ok"}
management_signoff: "2025-11-02"

13.3狀態消息模板


[UTC+02] Идет аварийное переключение в резервный регион. Игры доступны, выводы временно ограничены. Средства игроков в безопасности. Следующее обновление через 15 минут.

14）實施路線圖（6-8周）

1-2周：服務和依賴性清單，層級分類，RTO/RPO目標，拓撲選擇，DR護照。
第3周至第4周：實現備份/PITR/不變性，秘密復制/KMS，運行手冊準備和狀態。
5-6周：部分技術測試（DB/緩存/隊列），PSP/KYC/區域腳本的 tabletop。
第7周至第8周：全開關（如果可能的話），帶有RTA/RPA，CAPA的報告，DRP更新和常規測試計劃。

15）與其他維基部分集成

與：BCP，風險註冊，事件管理，Logs Policy（WORM），TPRM和SLA，ISO 27001/27701，SOC 2，PCI DSS，RBAC/Least Privilege，密碼策略和MFA，更改/發行管理。

TL;DR

Worker DRP=Tier清晰的RTO/RPO Active-Active/Standby+固定後備箱/PITR體系結構可播放的運行手冊和回收資金/遊戲定期演習和CAPA。然後，任何重大故障都會變成一個有管理的程序，可以預測的恢復時間，對監管機構和參與者來說零驚喜。

Disaster Recovery Plan

TL;DR

與我們聯繫

快速聯繫

影片即將更新

我們目前正忙於各項專案