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

联系我们

快速联系

视频即将更新

我们目前正忙于各项项目