模板包含什么
没演练过的灾备方案只是一个假设。下面这条时间线的形状,是被逐级升级的演练序列决定的,因为每一次演练都要花掉一个变更窗口,而每一次都会查出上一次查不出来的东西:
- 业务影响分析, 应用与服务清单、依赖关系梳理、业务影响访谈,以及每个服务要承诺的 RTO 与 RPO 指标;同时对照《信息系统灾难恢复规范》确定目标灾难恢复能力等级。后面所有东西的价钱都是按这组数字算出来的。里程碑:RTO/RPO 基线获批。
- 灾备策略与架构, 恢复等级划分、灾备中心或异地可用区选址(同城双活还是两地三中心)、复制与备份架构、网络与域名切换设计,以及对照指标做的成本评审。里程碑:架构方案获批。
- 建设与数据复制, 灾备侧基础设施、存储与数据库复制、备份策略调整、灾备中心的身份与安全控制(并满足等级保护对备份与恢复的要求),以及复制时延监控。里程碑:复制进入稳态并验证。
- 切换手册与文档, 按恢复等级各写一份切换手册、回退与回切流程、危机沟通通讯录,以及"谁有权宣布灾难"的启动判据。里程碑:切换手册发布。
- 演练序列, 先桌面推演,再对一级应用做一次带回退的部分切换,最后是带业务验证和回切的全量切换, , 每一次之后都要留出整改时间。里程碑:全量切换演练通过。
- 评审与常态维护, 演练报告与残余风险、管理层批准、应急人员培训、年度演练计划表,以及挂进变更管理的钩子,防止新上线的系统悄悄落在方案之外。里程碑:方案获批。
谁会用这个模板
IT韧性负责人、基础设施团队和业务连续性经理用这条时间线来构建并验证恢复能力。它从业务影响分析和RTO/RPO目标,经复制搭建和操作手册,一直到桌面推演、部分和完整切换演练,确保组织真能在目标时限内恢复,而不只是纸上谈兵。
如何调整
- RTO 和 RPO 按服务定,不要按公司定, , 支付服务和内部知识库不该在同一个等级里。
- 两个变更窗口都要早早预定;全量切换的窗口通常需要管理层批准和一段业务低谷期,这是日历约束,不是技术约束。
- 每一次演练旁边都留着回退那一行, , 没有演练过退路的切换,就是一次等着挑个坏日子发作的故障。
- 如果是分组切换而不是一次全切,按应用等级分别加行。
- 把部分切换之后的整改窗口拉长;真正有价值的发现大多出在那里。
- 把年度复演也作为带日期的行加进去,别让方案在批准十二个月之后悄悄过期。
排期建议
- 要演练回切,不只是切过去。在灾备端跑起来只是一半,多数机构昂贵的问题都是在回家的路上发现的。
- 桌面推演要放在一切技术动作之前。它便宜、不占变更窗口,而且非常可靠地能查出联系方式失效、启动权限不清,以及手册里那些默认"你应该知道"却从没写下来的步骤。
- 验证要靠业务,不是靠 ping 通。能响应的服务不等于能用的服务;全量切换期间要让真实用户完成真实业务。
- 把复制时延当成实时指标盯着。一个你没有持续测量的 RPO,只会在真出事的时候才被验证。
- 把灾备挂进变更管理。每上线一个没有定恢复等级的新应用,方案与现实之间的口子就大一分,而这个口子只有在演练那天才看得见。
- 受监管行业要按监管的演练频次排。金融等行业对切换演练的周期和报告有明确要求,那是外部时钟,不是内部计划。
相关模板
本模板为中文。尚未翻译的相关页面会以英文打开。
常见问题
建成并演练一套灾备方案要多久?
从业务影响分析到一份经过演练并获批的方案,通常九到十五个月,模板用的大约是十五个月。建设是可预测的;被拉长的是末端的演练序列,因为每次演练都要一个变更窗口,之后还要一轮整改。
RTO 和 RPO 有什么区别?
RTO 是你能停多久, , 恢复服务所需的时间。RPO 是你能丢多少数据, , 最后一份可用副本的新旧程度。RTO 决定备用基础设施,RPO 决定复制频率,两者合起来决定了这套方案的大部分成本。
为什么要演练三次而不是一次?
因为它们查出的东西不一样。桌面推演用一间会议室的成本,就能找出手册和决策链上的缺口。部分切换在有限影响范围内找出技术故障。而只有带业务验证的全量切换,才能证明 RTO 成立。每一次都要以上一次的问题已经修好为前提。
演练需要变更窗口吗?
部分切换和全量切换需要, , 它们会挪动生产流量,带着真实风险。预定窗口时要配上演练过的回退方案和明确的中止判据。桌面推演不需要窗口,这正是应当先把它榨干的原因。
它和业务连续性是什么关系?
灾难恢复是其中的技术子集:把系统和数据恢复起来。业务连续性更宽,覆盖人员、场所和流程。这份模板管灾备这一侧,不过危机沟通和灾难宣布那几行,和任何一份业务连续性计划是共用的。
这份灾备模板免费吗?
免费。可免费下载 Excel、PowerPoint 和 CSV,也可免费在线编辑,无需注册。