• http://www.xmrcjj.com
  • |
    |
    |
    |
    移动端

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

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

    作者:陈峻来源:51CTO技术栈|2018-06-21 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邮刊
    朝阳论坛 桃园市论坛 阿尔拉镇论坛 玉门市论坛 回力娱乐场论坛
    西资岩石佛论坛 两当县论坛 阿合奇县论坛 城西区论坛 册亨县论坛