1. 课程导入

欢迎进入《银行RPO RTO与灾难恢复演练实战》课程。在正式进入技术细节之前，我们需要先建立三个基本认知：银行为什么必须做灾难恢复？监管到底要求什么？本课程将带你掌握哪些能力？只有把“为什么做”和“做到什么程度”想清楚，后面的RPO、RTO计算、切换演练和复盘才有判断标准。

一、银行灾难恢复的现实背景

银行是典型的高可用、强一致、强监管行业。一次核心系统中断，影响的不只是内部办公，而是柜面、手机银行、支付清算、ATM、信贷和监管报送等关键业务。与普通互联网系统不同，银行灾难恢复面对的是“资金不能错、账务不能乱、监管不能等”的三重约束。

从故障来源看，银行面临的风险可分为四类：

• 基础设施故障：机房断电、空调失效、网络中断、存储阵列损坏。
• 系统与软件故障：数据库崩溃、中间件异常、版本发布回退失败。
• 人为与操作风险：误删数据、配置错误、变更未按流程执行。
• 外部与区域性灾难：地震、洪水、疫情、大范围网络攻击或勒索软件。

这些风险决定了灾难恢复不是“买一套备份软件”就能解决，而是覆盖组织、流程、技术、场地和人员的系统工程。RPO（Recovery Point Objective，恢复点目标）回答“最多能丢多少数据”，RTO（Recovery Time Objective，恢复时间目标）回答“最多能停多久”。两者共同构成灾难恢复能力的量化标尺。

二、监管要求与合规底线

国内银行灾难恢复主要受国家金融监督管理总局（原银保监会）、中国人民银行及相关行业标准约束。监管关注点通常集中在业务连续性管理、灾难恢复预案、演练频次、外包与云服务连续性、重要业务恢复优先级等方面。以下清单可作为合规自查的起点：

监管关注维度	典型要求	落地证据
业务连续性管理	建立BCM体系，明确重要业务与恢复优先级	业务影响分析报告、BCM制度
灾难恢复预案	覆盖场景、组织、流程、资源与回退条件	预案文档、版本记录、审批记录
演练与测试	定期开展桌面推演、切换演练和真实接管	演练方案、演练记录、问题整改单
RPO/RTO指标	重要业务系统需明确并验证指标可达	指标定义表、演练实测数据
外包与云连续性	供应商需提供连续性证明与退出机制	合同条款、供应商演练报告

三、本课程的知识框架与学习目标

本课程共30章，围绕“指标—架构—演练—复盘”四条主线展开。第1章建立背景与框架，后续章节逐步深入RPO/RTO测算、数据复制技术、双活与主备架构、切换脚本、演练组织、故障注入、复盘改进和监管汇报。

学习目标如下：

1. 能准确区分RPO与RTO，并结合业务影响分析为不同系统设定合理指标。
2. 能读懂银行常见灾难恢复架构，包括同城双活、异地灾备、两地三中心。
3. 能设计并执行一次完整的灾难恢复演练，包括方案、脚本、切换、验证和回退。
4. 能通过日志、监控和实测数据定位RTO不达标的原因并推动整改。
5. 能输出符合监管要求的演练报告与整改闭环材料。

下面这张图展示了本课程的核心逻辑：业务需求驱动指标设定，指标驱动架构与技术选择，架构通过演练验证，演练结果再反馈到指标和预案优化，形成持续改进闭环。

四、案例场景：一次“看似成功”的演练

某城商行核心系统采用同城双活架构，日常监控显示数据库同步延迟低于1秒，备份任务每天成功。年度演练中，团队按预案将核心数据库切换到同城灾备中心，业务验证通过，演练报告结论为“RTO 30分钟，RPO 0”。

但三个月后真实故障发生时，切换耗时超过2小时，且部分交易流水丢失。复盘发现三个问题：

• 演练时切换的是“预生产环境”，真实生产环境的连接池、DNS和防火墙策略未同步验证。
• RPO 0仅针对数据库，未覆盖消息队列和文件存储，导致部分异步交易丢失。
• 切换脚本依赖人工输入参数，真实故障时关键人员不在场，操作被延误。

五、学习建议与常见误区

学习本课程时，建议你带着自己所在银行或项目的真实系统来思考：它的重要业务是什么？当前RPO/RTO是多少？最近一次演练是什么时候？切换脚本是否经过真实环境验证？

需要特别避免的误区包括：

1. 指标拍脑袋：RTO写“4小时”却没有业务影响分析支撑，也没有实测数据。
2. 重建设轻演练：灾备中心建成后长期不切换，设备、版本和人员都已变化。
3. 重技术轻组织：只关注复制软件，忽略决策授权、通讯录和应急指挥流程。
4. 重恢复轻回退：没有定义回退条件和回退步骤，切换失败后无法安全返回。
5. 重结果轻证据：演练结论只有“通过”，缺少日志、截图、时间戳和问题清单。

本章作为课程导入，已经明确了银行灾难恢复的背景、监管要求、核心指标和课程框架。接下来，你将逐步掌握从指标设定到演练落地的完整方法，并能够用可验证的数据证明灾难恢复能力真实可用。