本页内容
要点速览
- 灾难恢复（DR）是业务连续性中的IT部分：在发生中断后恢复系统和数据。
- 业务影响分析用于确定哪些业务流程最重要，以及每个流程能承受多长时间的中断。
- 恢复时间目标（RTO）和恢复点目标（RPO）把业务上的承受能力转化为技术目标。
- 恢复操作手册把计划变成分步说明，让其他人在压力之下也能照着执行。
- 桌面推演和技术恢复测试能检验计划是否可行，并让计划保持最新。
灾难恢复、业务连续性与事件响应
这几个概念彼此交叉，把它们区分开会更清楚。业务连续性规划关注的是整个机构在中断期间如何继续运营：备用办公场所、手工替代流程、供应商安排和对外沟通。灾难恢复是其中的技术部分：让系统、应用和数据恢复运作。事件响应则关注如何发现、遏制和调查勒索软件或账户被入侵等安全事件。
遭遇网络攻击时，这三者会同时运作：事件响应判断何时可以安全地恢复，灾难恢复负责执行恢复，业务连续性规划则确保期间客户仍能得到服务。一份好的灾难恢复计划会引用另外两者，而不是试图取而代之。
从业务影响分析开始
业务影响分析（BIA）是与企业运营负责人进行的一次结构化讨论，是所有恢复决策的基础。
列出关键业务流程
找出能带来收入、服务客户或履行义务的活动，例如开具发票、发放薪资、排班、访问客户档案和电子邮件。
梳理依赖关系
为每个流程列出它所依赖的应用、数据、设备、网络服务、身份和第三方。别忘了DNS、互联网连接、多因素身份验证和支付处理商等容易被忽视的环节。
估算不同时长的影响
询问每个流程中断一小时、一天和一周分别会造成什么后果，综合考虑财务、客户、合同、法律和声誉方面的影响。
确定可承受范围
就每个流程可承受的最长停机时间，以及企业能承受重新录入或丢失多少数据达成一致。
排序并签字确认
把系统划分为不同的恢复层级，并由管理层批准优先顺序，因为它们将决定计划和预算。
通俗理解RTO和RPO
恢复时间目标（RTO）
系统最多可以停机多久，影响才会变得无法接受。四小时的RTO意味着，恢复方案必须切实能在四小时内恢复系统，其中包括发现问题和决定采取行动所需的时间。
恢复点目标（RPO）
以时间衡量，您最多能承受丢失多少数据。一小时的RPO要求至少每小时备份或复制一次；如果只在夜间备份，就意味着可能丢失最多一天的工作成果。
分层
并非每个系统都需要同样的目标。第一层可能是身份、电子邮件和核心业务应用；第三层可能是可以等上几天的归档数据。
成本随目标而定
RTO和RPO越短，成本越高，因为需要复制、备用基础设施或更高级别的服务。业务影响分析让企业能在权衡成本的前提下选择目标。
选择恢复策略
目标确定后，为每个层级选择一种恢复方式，并确认它能够达成目标。
- 从备份恢复到现有或替换硬件：成本最低，恢复时间最长，适用于较低层级的系统。
- 恢复或故障转移到云基础设施：能在云环境中直接启动受保护服务器的备份平台，可以在没有第二间办公室的情况下缩短恢复时间。
- 复制到备用系统：保存接近实时、随时可以启动的副本，适用于RTO和RPO都很短的情况。
- 软件即服务（SaaS）的高可用性：Microsoft 365和其他SaaS平台让您的计划无需涵盖基础设施恢复，但仍需要规划数据备份、身份恢复和访问安排。
- 针对勒索软件的洁净室恢复：在隔离环境中对恢复的系统进行扫描和验证后再重新接入网络，以免把攻击者连同数据一起恢复回来。
- 手工替代流程：纸质表格、电话联络网或只读导出数据，让关键流程在系统恢复期间继续运转。
编写人人都能照着做的恢复操作手册
恢复操作手册是针对某个具体系统或某种具体场景的分步恢复流程。它应当让一位从未接触过该系统、但具备专业能力的技术人员，在凌晨两点、承受压力的情况下也能使用。这意味着要写明备份的确切位置、需要使用的账户及其凭据的存放地点、操作顺序、如何验证恢复成功，以及某一步失败时该联系谁。
顺序很重要。身份通常排在第一位，因为没有可用的管理员账户和多因素身份验证，其他一切都无法管理。接着是网络和DNS，然后是核心数据和应用，最后是较低层级的系统。要明确记录依赖关系，免得有人花一个小时恢复一个应用，却发现它的数据库服务器还没恢复。
把恢复操作手册存放在灾难期间仍能取用的地方：打印版、离线加密副本，或不依赖于主租户的独立云端位置。附上一份最新的联系人名单，包括员工、IT服务商、互联网和电话运营商、主要软件供应商、网络保险公司和银行。
角色分工与沟通
明确分配角色：负责做决定的事件负责人、指挥恢复工作的技术负责人、向员工、客户和供应商通报情况的沟通负责人，以及记录决定和时间节点的记录员。在小企业里，一个人可能身兼数职，但每个角色都应指定一名后备人选。
事先为员工、客户和供应商准备好沟通模板，并约定在电子邮件和Teams无法使用时改用哪些渠道。如果是安全事件，在对外发表声明之前，请先咨询保险公司和法律顾问，因为措辞可能同时影响隐私义务和保险理赔。
用桌面推演和技术演练检验计划
未经测试的计划只是一种假设。以下两类测试相辅相成。
桌面推演
召集决策者用一两个小时演练一个真实的场景，例如周一早上发现勒索软件，或一场火灾导致办公室关闭。由主持人逐步引入新情况，小组依据计划讨论如何决策。缺口很快就会暴露出来：联系人缺失、权限不清、对备份的错误假设。
技术恢复测试
在隔离环境中真正从备份恢复一个系统，并对照RTO计时。由业务人员验证数据是否完整、应用是否正常运行。
事后复盘
记录哪些做法有效、哪些无效，以及每个缺口由谁在何时之前解决。趁细节还记忆犹新，立即更新恢复操作手册。
持续维护
至少每年审查一次计划；在发生重大变化后也要审查，例如引入新应用、搬迁办公室、更换服务商或关键岗位人员变动。
核对您的网络保险保单
许多网络保险保单对事件处理方式设有条件，例如须及时通知保险公司、须使用经批准的事件响应公司。请仔细阅读保单，并把其中的要求写入计划，以免恢复过程中的决定影响理赔。
常见问题
灾难恢复计划应该写多长？
够用即可，不必更长。许多小企业采用一份简短的计划文件，涵盖优先顺序、角色和联系人，再为每个关键系统配备单独的恢复操作手册，效果就很好。
RTO和RPO有什么区别？
RTO是系统必须在多长时间内恢复；RPO是您最多能承受丢失多少最近的数据。某个系统可能需要在一天内恢复，但丢失的数据不能超过一小时。
如果所有东西都在Microsoft 365里，还需要灾难恢复计划吗？
需要，只是会简单一些。您仍然需要应对数据被删除或被加密、管理员账户被入侵、设备丢失或互联网中断等情况，也需要明确由谁做决定、员工如何继续工作。
多久应该进行一次桌面推演？
对大多数中小型机构来说，至少每年一次是合理的节奏；在系统、服务商或关键人员发生重大变化后，再额外进行一次。