公司新来了个90后,把旧的DRP“吊打”和“按到地上摩擦”

原创
运维 系统运维
常言道:流水不腐、户枢不蠹。您企业的灾难恢复计划是否 N 久没被更新了?我们来看看一位 90 后是如何对 DRP 进行整改的案例。

【51CTO.com原创稿件】常言道:流水不腐、户枢不蠹。您企业的灾难恢复计划是否 N 久没被更新了?我们来看看一位 90 后是如何对 DRP 进行整改的案例。

[[216314]]

话说我们公司应急响应中心新来了一位小嵇同学。作为典型的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 后老年人不得不刮目相看了。

[[216317]]

作者:陈峻

陈峻(Julian Chen) ,有着十多年的 IT 项目、企业运维和风险管控的从业经验,日常工作深入系统安全各个环节。作为 CISSP 证书持有者,他在各专业杂志上发表了《IT运维的“六脉神剑”》、《律师事务所IT服务管理》 和《股票交易网络系统中的安全设计》等论文。他还持续分享并更新《廉环话》系列博文和各种外文技术翻译,曾被(ISC)2 评为第九届亚太区信息安全领袖成就表彰计划的“信息安全践行者”和 Future-S 中国 IT 治理和管理的 2015 年度践行人物。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

 

责任编辑:武晓燕 来源: 51CTO技术栈
相关推荐

2021-03-02 12:27:55

操作系统面试

2021-08-31 09:04:29

Kubernetes 运维开源

2021-06-07 08:26:35

P8员工公司

2017-07-19 09:54:31

数据CIO

2022-07-04 09:43:46

RabbitMQ消息消息队列

2017-11-28 10:09:08

语言JavaGo

2015-07-23 15:25:26

90后态度

2017-11-28 16:31:32

硬盘PythonJava

2015-08-03 10:08:36

公司变卖

2015-08-03 09:08:41

公司卖掉发工资

2010-08-17 16:14:30

无线路由AP

2014-06-11 09:04:32

游戏化管理

2023-01-04 17:19:21

MQ消息中间件

2020-11-13 07:08:51

Spring Boot应用Spring

2024-03-21 14:21:48

系统重构

2017-11-30 14:59:31

Go互联网技术栈

2022-02-15 13:20:28

特斯拉电动车

2014-08-01 14:32:29

创业90后创业

2019-08-22 10:07:33

程序员开发危机

2020-07-27 08:26:03

数据库 SQL索引
点赞
收藏

51CTO技术栈公众号