肥乡| 南充| 鄂州| 鄂州| 龙州| 广灵| 巴彦| 和顺| 沁县| 孟村| 新晃| 绥棱| 清河| 湖北| 围场| 梅州| 望江| 鄢陵| 改则| 大安| 忻城| 罗定| 峰峰矿| 绛县| 乌马河| 弓长岭| 古交| 林口| 石台| 四川| 龙陵| 鹿泉| 贞丰| 梧州| 阳西| 沐川| 英吉沙| 马龙| 黄冈| 炎陵| 宽城| 怀宁| 榕江| 汉阴| 孟村| 青浦| 平乐| 青阳| 江门| 宜宾县| 海阳| 延吉| 萍乡| 大新| 沁县| 汶川| 绍兴县| 丹江口| 河津| 兴化| 科尔沁右翼中旗| 祁门| 云集镇| 平果| 海兴| 南平| 淮阳| 北戴河| 鸡西| 田林| 惠来| 北宁| 玉门| 循化| 铁山| 六合| 多伦| 霍山| 青田| 盂县| 高青| 鲁山| 孟津| 晋中| 都兰| 尖扎| 大冶| 佳木斯| 潮州| 萧县| 西盟| 五指山| 涟水| 临安| 鼎湖| 伊金霍洛旗| 台北县| 信宜| 阿城| 汶川| 义马| 柘城| 大渡口| 平昌| 梁山| 滨海| 绥芬河| 顺平| 白朗| 赫章| 集美| 尼木| 康平| 井陉| 永泰| 连城| 夏县| 东兴| 番禺| 松潘| 通山| 东海| 郴州| 太和| 海阳| 威县| 抚顺县| 陈仓| 峨山| 金平| 利辛| 科尔沁左翼后旗| 仁寿| 河北| 绥化| 安泽| 门头沟| 邓州| 荆州| 宁夏| 隆化| 济阳| 海伦| 肥城| 射阳| 东阳| 梨树| 明水| 桃园| 望江| 南通| 辽阳市| 谢家集| 巴塘| 东营| 霍林郭勒| 丰宁| 南涧| 广丰| 高要| 南阳| 东沙岛| 凤庆| 双阳| 永修| 馆陶| 留坝| 罗城| 罗城| 金湖| 成都| 武威| 洪湖| 新密| 东港| 马祖| 定襄| 崇明| 鹤山| 沧源| 乌鲁木齐| 舟曲| 林芝镇| 宁县| 通城| 谷城| 萨嘎| 汝城| 四川| 松江| 武平| 两当| 酉阳| 灵宝| 黔江| 许昌| 应城| 扬州| 酉阳| 曲周| 筠连| 定襄| 洛隆| 兴平| 博白| 华县| 大冶| 蚌埠| 五峰| 龙泉| 霍林郭勒| 礼县| 郧县| 共和| 岢岚| 韶关| 塔河| 任县| 马尔康| 昔阳| 邻水| 竹溪| 井陉矿| 巴南| 崇仁| 固安| 东胜| 独山子| 河曲| 博野| 电白| 合江| 彭泽| 新龙| 荥阳| 通城| 彰武| 商洛| 景东| 镇沅| 象州| 怀集| 乌兰浩特| 建湖| 柳州| 萝北| 揭阳| 互助| 兴海| 秦皇岛| 民和| 龙门| 南木林| 易县| 东兴| 开阳| 德钦| 兴隆| 临邑| 安多| 黄骅| 罗甸| 惠民| 永丰|
|
|
|
|
移动端

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

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

作者:陈峻来源:51CTO技术栈|2018-05-22 09:31

年前最后一场技术盛宴 | 1月27日与京东、日志易技术大咖畅聊智能化运维发展趋势!


【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】

【编辑推荐】

  1. 业务连续/灾难恢复计划如何将天气事件包含在内
  2. 灾难发生时云备份至关重要
  3. 灾难恢复计划如何使企业免受业务中断?
  4. Veeam Shaun McLagan:作好数据灾备和恢复,让业务持续在线
  5. 从勒索软件中恢复:备份厂商能提供哪些帮助?
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

网管员必读—服务器与数据存储

《网管员必读—服务器与数据存储》全面、系统地介绍了在中、高级网络管理和网络工程实施中两个重要方面的主流技术和应用:硬件服务器和数据...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊
马湾海峡论坛 城东论坛 获嘉县论坛 长沙县论坛 大同县论坛
福利镇论坛 青河县论坛 那桐镇论坛 岱仙瀑布论坛 霞浦县论坛