近日一家名为“前沿数控技术”的微创公司出名了，而且火遍IT界朋友圈。而为这家企业送上神助攻的竟然是业界知名的鹅厂。让笔者不仅感叹真实风水轮流转啊。至于事情的起因不必多说，总之一句话：“存放在腾讯云所谓三备份的存储上的企业核心数据竟然丢了，而且连鹅厂这样的大厂居然也没恢复了”。更加不要脸的是鹅厂给出的解决方案竟然是云计算的服务费不收了，外加赔偿13万。哥哥，你这是在卖硬盘吗？“前沿数控”愤而怒之，声称要起诉鹅厂赔偿1000万。
至于丢失的数据是价值13万还是1000万，这并不是笔者今天想要讨论的问题。单就这个事件本身，由于没有做好业务连续性管理而导致公司发生重大业务风险这件事情，“前沿数控”的CIO和CTO的责任是跑不掉的。毕竟资源是租的，但数据可是你们自己的啊。因此从这件事情上让我们认识到对于一个企业来说，无论是初创型企业还是一个大型企业，业务连续性管理（BCM）都是一项重要而又艰巨的任务。
风险无处不在
对于一个企业的高层领导者来说，一般负有两大责任：最大限度地促进业务增长和最大限度地保护核心资产。对于看得见的责任（促进业务增长）一般来说都会得到企业的充分重视。而对于看不见的责任（保护核心资产）而言，很多企业领导者就显得不是那么的重视了。即使这些风险有可能瞬间就能毁掉这个公司。
“天上掉下来这么个馅饼，怎么就砸到我脑袋上了？”一旦发生风险，这是企业管理者嘴里经常抱怨的一句话。不过恭喜你，这个“馅饼”就砸到你的脑袋上了。这就是风险，风险无处不在。企业面临的风险既有可能是像911袭击或者超强飓风登陆那种如电影般的毁灭性事件，也有可能是像停电、漏水、火灾这样的常见事件。但是无论事件大小，一旦事件处理失控，给企业带来的就有可能是灾难性的打击。试想一下，某一天中午，你和平常一样走出公司总部大门吃午饭，突然接到接到火警电话，并被告知总部大楼因为失火及其他消防隐患导致一周之内全面封闭检查。即使你的数据中心并没有在火灾中被损坏，请问你能保证你的正常业务不受影响吗？
业务连续性管理（BCM）从本质上说不仅仅是一个技术问题，而是一个包含着技术问题，业务问题和管理问题的综合体。对于一些大型公司而言，业务连续性和灾难恢复工作应该向企业风险管理部门汇报。而在一些较小的组织里，这个角色应该向首席运营官（COO）或者同时向COO和CTO（首席技术官）汇报。风险有可能出现在IT技术上，也有可能出现在业务流程上或管理制度里，有些可能是有一些意外事件导致的，而有些也有可能是由于人为原因造成的。当灾难来临时，我们是否有响应的预案，让业务按照我们事先规划好的路径演进，这就是业务连续性管理所要讨论的问题。
业务连续性管理（BCM）的目标和方法
业务连续性问题既是一个技术问题也是一个业务问题，但归根到底还是一个业务问题。因此在目标上也是为了最大限度地保证在灾难发生时业务损失最小化，业务连续性最大化。因此在业务保护方法上分为两种，分别是连续性保护和恢复性保护。
正所谓”再好的刀伤药也抵不上不剌口”。连续性保护方法的目标就是最大化地做好事前预防工作，尽量不让灾难发生。例如在IT技术领域最常见的方法如“消除单点故障”技术，并行处理技术，DevOps技术等。在业务领域，如事前的合规性审查，集中授权等。在管理领域，如定期的设备巡检，定期的业务Review等。都可以有效地避免风险的发生和发展。
当由于某些不可控的原因导致灾难已经发生时，就必须采用一系列的恢复性保护方法来保证业务安全了。在IT技术领域最常用的方法如备份/恢复技术，DR技术等。在业务和管理领域也有相应的技术和方法。因此本次事件从技术上讲就是因为“前沿数控”在数据安全性上采用了数据高可靠方法，而没有另外采用备份恢复策略。一旦数据出现逻辑错误，三份数据全部不可用。更尴尬的是还没有可恢复的数据，哪怕是几天前的。
业务连续性管理的流程
当灾难发生时，救人永远都是第一位的。特别是在如化工厂、或其他高危环境的组织发生灾难时更是这样。这是BCM一贯的价值观。在保证人员安全的前提下，尽最大努力保证企业核心资产的安全才会变成一项重要任务。
第二项任务就是BIA方法了。为了分析灾难对业务的影响，以及业务在灾难恢复当中的优先级，我们最常使用的一项技术使“业务影响分析”方法（BIA）。BIA方法通常有两大目标：
1. 识别事件对组织或其流程可能产生的潜在影响，以及用来定量和定性评估这些影响的标准。这些标准可能来自财务、运营、客户、法规及名誉等多个维度。
2. 在组织内以业务优先级为基础统一地定义组织每一流程的恢复时间目标（RTO）和恢复点目标（RPO）
在第二点中通常有两个问题需要注意。
问题1：企业的核心系统通常是最先恢复的系统吗？
答案是不一定。要看具体的客户行业和背景。笔者曾经半开玩笑地问过一个银行业客户一个问题：“如果某一天你们的数据中心着火了，请问你觉得最先需要恢复的业务系统是哪一个？”客户回答：“核心系统”。我回答：“不一定，我觉得可能是800/400的Call Center系统。”为什么？试想一下，银行总部大楼着火了，这个消息会分分钟的传遍整个朋友圈。如果你是这个银行的储户你会是什么反应？“我的钱还在吗？”，“我下个月的贷款还用不用还了？”如果这时候800电话2天打不通会有什么后果？一群大爷大妈分分钟包围每一个储蓄所，然后拉横幅静坐“还我血汗钱”，然后就是媒体铺天盖地的报道，然后就是更多人加入静坐和挤兑…… 因此合理引导客户预期在这个时候比恢复系统更重要。
问题2：RTO和RPO是业务目标还是技术目标？
经常会有一些朋友有这样一个误区，认为RTO和RPO是一个技术目标。当然上述两个目标有很大的技术目标的部分。但是从业务连续性的广义性上将，上述两个目标应该被归纳到业务目标的范围。及组织业务真正恢复的恢复时间和恢复点。从技术和业务两种不同角度出发，在这两个目标当中对RTO的影响相对较大。因此从这个广义上讲可能真的不存在什么双活。因为当灾难真真切切发生时，及时IT系统看上去都是好的。谁能保证没有一点业务损失呢？是否应该在重新启动业务前，需要对业务系统的每笔业务完整性做一次校验，当校验完成后才能开门营业呢？
在做完业务的BIA分析后，下一项任务就是为每一个业务场景制定业务连续性策略了。在这个阶段将通过一系列的技术和业务手段告诉董事会我们该如何达到之前BIA分析中所规定的RTO和RPO目标。这一阶段的目标主要有如下几点：
1. 通过一系列的技术和业务策略来满足BIA所规划的RTO和RPO目标
2. 通过成本分析法，制定过渡架构和迁移计划。即标识出先做哪个后做哪个
3. 获得管理层的批准并分步实施这些策略
演练与维护也是业务连续性管理中最最重要，不可获取的组成部分。要想保证业务连续性计划长期有效，这需要组织架构的支持和资金的长期支持。这一点最容易被管理层忽略。因此这一点应该在业务连续性管理项目提出时就向管理层首先提出来，并得到长期预算支持的许可。
另外关于支持企业业务连续性管理的IT技术方面，由于存在太多的架构和产品，总体上包括采用更可靠的设备、更可靠的架构、创建永久的灾备站点技术设施等，在这里就不一一赘述了。
总之，这场大戏还没收场，我和各位看官一样，抱着看热闹的不嫌事儿大的心理等待着第二季的播出。最后祝前沿数控好运，祝鹅厂好运！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。