【51CTO.com原创稿件】常言道：流水不腐、户枢不蠹。您企业的灾难恢复计划是否 N 久没被更新了？我们来看看一位 90 后是如何对 DRP 进行整改的案例。
话说我们公司应急响应中心新来了一位小嵇同学。作为典型的90后，他受过良好教育、个性张扬、特立独行。
那天，他对我们说：他觉得咱们现在的 DRP（灾难恢复计划）就像他过去弹钢琴一样，存在着如下三大问题：
我们当初听过了后，也没在意。可没想到几日后，他在某次 IT 管理层会议上，一边问着：“惊喜不惊喜？意外不意外？”，一边向我们展示了他改进后的 DRP。
大家虽然不喜欢这种粗暴的“手撕”方式，但耐着性子认真阅读之后，也不得不承认他的更改的确解锁了一些新技能，并填补了一些老坑点。
总的来说，这份新的 DRP 基本上“没毛病”。下面就让我们来具体看看他在原来的基础上做了哪些改进。
事前篇
清晰定义“灾难”
“傻傻”分不清楚，但是你要分清楚
原来的 DRP 上手就谈如何应对灾难，可是公司上上下下在多数情况下，经常会混淆问题（Problem）、紧急情况（Emergency）与灾难（Disaster）之间的细微差别，并造成了一旦出事就“匆忙上阵”，出现人浮于事的状况。
因此，他开宗明义地做了如下定义：
- 问题：是指单个或少量的计划外的业务和/或服务中断或质量水平骤降，造成损失较轻，直接责任部门容易迅速实施补救。
不涉及到 DRP 和 DR 相关团队，一般小于 24 小时。
- 紧急情况：是指多个不可预见性的业务和/或服务中断情况的组合，造成了一定的损失或破坏，多个部门需要尽快解决。
DR 相关团队需时刻根据实际情况触发 DRP，一般大于 24 小时但小于 48 小时。
- 灾难：是指成规模的对资产和/或服务造成了损害、损失或破坏的重大事件。需要公司管理层的参与。
DR 相关团队立即启用 DRP 并分步骤实施 DR，一般大于 48 小时。
厘清上述关系，可见对于掌握 DRP 的触发条件是至关重要的，而后续的恢复活动才能够有的放矢地进行开展。
BIA + RA
“预则立，不预则废”
业务系统在日常运营过程中，可能发生的各种灾难，对我们来说就是“天灾人祸”类的重大事件。
过去的 DRP 对于当前的生产系统来说不但已经陈旧，而且有着较大的出入。
因此要想达到有条不紊的恢复效果，就需要通过 BIA（业务影响分析）和 RA（风险分析）来识别出那些与本公司日常运营密切相关的职能模块和关键应用。
小嵇通过参考各种 SLA（服务水平协议）、事故记录、以及内/外审报告，对各类主/次要系统定义了 MTD（最大允许中断时间），区分了轻重缓急，并排定了恢复的先后次序。
在 BIA 中，他依次以“业务职能”和“关键应用”两大部分为出发点，分别根据关键（1-4 小时）、紧急（24 小时）、重要（72 小时）、一般（7 天）、非必要（30 天）五种 MTD，拟出了 2×5 =10 张表格。
下面就是两类表头的示例，大家可以批判地审视一下：
上述的 BIA 主要从“知己”的角度出发，为了实现“百战不殆”的小目标，它还努力定义了“知彼”，即 RA。
下面就是他依次引入的三个维度的参考指标：
- 内/外部威胁源或威胁代理：自然层面上的各种灾害；技术层面的，如软/硬件损坏所造成的大量数据丢失和分布式拒绝服务攻击等。
支撑系统方面的，如供电、空调和接入网络等；以及人为方面，如故意使用恶意软件进行破坏和操作疏忽与失误等。
- 风险可能性：基于过往事件/事故的记录、放置和使用区域特征、相关合规要求、自身鲁棒性，得出高中低的性质。
- 影响范围：整个组织/所有外部客户、多个站点/多个系统与服务、或是单个站点/单个系统。
最后将这些都对应到各个业务模块上形成风险分析的矩阵。由此可见，他通过对现有系统的全方位、立体“扫描”和剖析，扫清了识别层面上的“死角”，为必要时的全面复盘做好了基础性的准备工作。
团队与责任
拒绝懵逼、也拒绝“布朗运动”
旧的 DRP 仅简单定义了一个应急响应小组来全面履行灾难恢复，可是有过实战经验的小伙伴一定知道，这种“低配”是完全不够的。
在此，小嵇同学细化并深耕了 DR 团队，并为他们“赋能”。下面让我们来看看这些“破壁”的人们需要哪些必备的技能，才能帮助我们把灾难怼回去：
恢复管理团队：
- 设置紧急热线电话、保持“呼叫树（Call Tree）”的准确性。
- 审查通知模板、灾难评估报告、测试结果。
- 确保相关人员的技能和意识培训、以及演练的落实。
- 定期审阅 DRP 并落实更新。
- 批准和控制恢复全程的成本。
- 检查确认系统的恢复。
损失评估团队：
- 评估灾难影响程度、量化损失以获赔偿。
- 起草并提交损失报告。
设施资源团队：
- 编录并更新生产环境中的软/硬件列表和备件库存情况。
- 保证能在必要时获取外部服务与支援。
- 维护离站资源和备用站点，提供各类相关的参考文档和操作手册。
- 必要时安排离站资源向受损主站的调配，以及人员转往备用站点的各种后勤。
技术恢复团队：
- 向评估团队提供必要的技术和数据信息。
- 提出过渡性的临时运营方案。
- 按照既定的顺序执行具体灾难恢复的各项技术操作。
- 防止次生灾难的发生。
- 灾难期间，对备用站点提供各项技术支持。
- 事后总结，提出加固方案，并更新 DRP。
公关法务团队：
- 在各个阶段，保持与各个方面的沟通，并使用既定的模板进行相关发布。
- 给予法律、合规方面的指导。
- 如有必要，则实施电子或物理取证。
由上可见，在“大难临头”之时，如果没有明确规定好计划中相对应的团队角色和其负有的职责的话，别说什么组队打“怪”了，只要出现一位“猪一样的队友”，大家就真的只能去“领盒饭”了。
事中篇
设定应对流程
“审判日”的绝地反击
曾经的 DRP 在这个环节写得“头重脚轻”，开始响应阶段细致入微，甚至有些吹毛求疵，而实际操作中并无过多的时间去层层报告和批示。
另外，在原 DRP 中，其恢复过程过于“速度与激情”化，导致业务回归上线后就草草收场，缺乏必要的确认与总结，而小嵇改版后的 DRP 则能明显体现“步步为营”的流程感。
让我们一起往下看：
- 事故出现，初步检测与识别，并定性灾难。
- 通知管理层，吹响 DR 团队的“集结号”。
- DR 团队迅速拍马赶到，各司其职，展开深入调查与取证。
- 损失评估，分析灾难源、填写如下灾难评估模板。（注意：评估报告需在灾难发生的 4 小时之内完成并提交。）
- 对内/对外宣告灾难。注意对内可以使用不同颜色的通知模板，以便受众一目了然。对外提供可能问及的技术细节解答和支持。
- 在受灾处，根据主次关系和既定顺序，先抑制再恢复，逐步实施各种基础设施、通信线路、硬件、软件的安装和配置、以及数据的恢复。
在 DR 的各项活动中，除了要注意各个 RTO 与“里程碑”外，也要注意填写并提交如下的日志检查表。
- 实时评估并验证恢复的有效性。如有必要，迅速修改恢复流程与方法，避免滋生次生破坏。
- 各个受影响的部门对灾难的恢复结果予以确认，并对内/外宣布完成。
- 总结评审执行效果，分析与原计划的偏离，并提出改进措施。
事后篇
更新与测试
自建生态，形成闭环
我们或许都有这样的共识：IT 服务和系统是随着企业的业务动态生长，并不断迭代的，可见旧版本的 DRP 之所以能被小嵇“吊打”和“按到地上摩擦”，就是因为它针对的是彼时多年前的系统状态。
因此，为了防止老化和淘汰，小嵇版本的 DRP 特地在最后部分增加了按需更新和例行测试。
具体来说，他罗列到的更新触发条件包括如下因素的增加、变更与淘汰：
- 服务器/用户端硬件设备与模块
- 网络设备、连接与架构环境
- 机房、数据中心与外部链路
- 关键软件程序、应用平台和服务系统
- 办公自动化（OA）与协同（Collaboration）相关软/硬件产品
- 关键配置与数据格式
- 服务策略（SLA）与员工规则
为了避免出现“扎心了，老铁，这方案没法实施”的情况发生，小嵇也定义了相应的例行维护与测试频率：
俗话说：猫有九条命，但是我们的业务服务系统可没有那么多的命哦。
因此，唯有保持 DRP 可操作性和可实现性，才能让这个所谓的刚性需求不断地“满血复活”。
小结
前些时“第一批 90 后已经…”的各种段子刷爆了微信朋友圈。
但是不可否认的是 90 后一代正在成为企业内的中坚技术力量，并正在逐步向管理岗位迈进。
虽然我们公司里的 90 后在技术水平上经常被黑，但是讲真：这次以小嵇为代表的 90 后对于 DRP 的大刀阔斧式的改进，让我们这些自称佛系，却时常油腻的 70 后老年人不得不刮目相看了。
作者：陈峻
陈峻（Julian Chen） ，有着十多年的 IT 项目、企业运维和风险管控的从业经验，日常工作深入系统安全各个环节。作为 CISSP 证书持有者，他在各专业杂志上发表了《IT运维的“六脉神剑”》、《律师事务所IT服务管理》 和《股票交易网络系统中的安全设计》等论文。他还持续分享并更新《廉环话》系列博文和各种外文技术翻译，曾被(ISC)2 评为第九届亚太区信息安全领袖成就表彰计划的“信息安全践行者”和 Future-S 中国 IT 治理和管理的 2015 年度践行人物。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
