业务连续性管理---策略

字数 1838阅读 1839评论 0赞 1

上篇文章聊到了6R理论今天聊聊大家去交流灾备的几个重要指标： RPO与RTO 。说通俗点，就是我能接受损失的数据和我能接受业务停上服务的时间。 那么一个灾备的指标这两个就完全涵盖了嘛？

如看下图：

![](/home/attachment/202208/26/915525_166150489560657.jpeg)

我们主要来聊聊RTO的这几个指标，其中有正常运行的RTO 100%和非常运行的RTO及最低可容忍的RTO，那么假设一个用户：A

A用户约我们来交流他的灾备中心建设通过这张图就可以商定他的灾备中心的投资预算：

如果要满足100%的运营能力，其灾备中心计算，存储，及网络能力就要与生产中心相当简单粗暴一点即： 灾备中心的投入和生产中心基本相当。

如果要满足非正常运行的能力，这个我们一般是指生产中心75%的运营能力那么我的灾备中心投入就可以适当的减少比如：

生产中心核心都是小型机那么我的的灾备中心就可以通过X86的服务器来满足，甚至可以部署在虚拟化环境来进一步减少灾备中心的投入。

那么如果要满足最低容忍限度： 50%甚至到30%的运营能力，用户可能只需要在灾备中心或者在租用一个IDC部署一套超融合把最核心的应用接管即可，甚至也可以将应用切换至AWS或者腾讯云上。

还有一点值的注意的是，当事件发生后有没有数据备份是一件至关重要的事情，备份数据是否可以恢复也是一件很核心的问题，我们见过大量的用户认为某某应用是非关键业务不需要保护结果发生事故应用无法恢复造成非常的大的损失，甚至发生丢乌纱帽，全员奖金停发的事件。

因为： 这年头没有那个应用系统是独立存在的，都是很多应用系统互相关联，经常发生恢复了90%的应用系统，但是没有恢复剩下的10%系统就是恢复不了。 。 。 。 。

还有一点值的注意的是，当事件发生这回有没有数据备份是一件至关重要的事情，有没有备份是否可以恢复也是一件很核心的问题，我们见过大量的用户认为某某应用是非关键业务不需要保护结果发生事故应用无法恢复造成非常的大的损失，甚至发生丢乌纱帽，全员奖金停发的事件。

![](/home/attachment/202208/26/915525_166150493180767.jpeg)

所以在运维阶段把数据备份好做到3-2-1原则即： 3个逻辑副本，2种介质类型，1份异地保护，当然前提这些的数据都是可验证，可恢复的。

![](/home/attachment/202208/26/915525_166150496411397.jpeg)

当事件发生后，在应用响应阶段可以通过备份存储的即时恢复将业务拉起来，这会您就不需要启动灾备数据中心，即时备份存储的性能还不能达到100%的业务性能起码还是可以满足最低容忍的RTO。

如果事件发生后，应用响应没有实现生产业务切换那只能启动灾备中心了，灾备中心启用时需要一个EOC（应急指挥中心）及相应的人员（如果发生火灾啊，地震啊，人得活着

EOC要有大屏幕和指挥台，方便领导指点江山（脑补一下）那么最重要的就要有一个灾难恢复计划即：DR Plan及灾难恢复策略，比如数据如何复制，DNS，IP如何切换等等。

所以数据中心灾难恢复标准姿势如下：
 ![](/home/attachment/202208/26/915525_166150502561262.jpeg)

![图片](https://mmbiz.qpic.cn/mmbiz_png/snsQcDcz0Xmib7GWP2ZqfNXlPNFVRs3N5f20nDjS8lic0VuaWVe8iaTQZfPgHicUJaYlyvIA9mN5XwlGYqLCVMaiaKA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)

BCM 业务连续性最佳实践

基本甭管多复杂的客户做一个数据中心灾备的过程也就如上图所示了。

项目启动确定相应人员如：BCM委会员，BCM执行团队，相应的保障部门，业务部门，IT部门，所以我们IT这块只关心数据中心DR的建设及切换流程，BCM其实是风险管理部的事情。

BIA和RA一般都是在一起做的，用于梳理用户的业务流程及查看现有的IT风险，并提交相应的报告给用户，您看就这两句其实超级麻烦，听说经常有人做着做着就抑郁了

灾备建设灾备设计

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

业务连续性管理---策略

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料