老话说得好，否极泰来。

　　最近，我和一位搞技术的朋友有过一次谈话，他是一家大型技术供应商的架构师。在我们的谈话中，他一直说云计算好，宣称甲方若是购买了云服务，CIO都可以不要了。他的理由是，乙方销售直接向甲方市场副总裁推销云计算方案，合同签订之后的产品选型、系统实施和运维管理，乙方全程操办，无关甲方IT的事儿-那么甲方何必还要IT部门呢？

　　从这个极端的例子可以看出，云计算有时候使事情变得更糟。但是从我的角度，云计算的高可用性也的确能使事情变好。

　　例如，规划灾备及业务连续性方案，有了云计算的支持，要比几年前轻松得多。在过去（说了，仅仅几年前），无论你需要冷备份、热备份还是实时备份，你只能自己动手建。而且，估算备份所需的开销也总是很不容易。更有甚者，当你还得说服他人-哪怕是再慷慨的董事会-给这些正常状态下毫无用处的东西投资，可想而知有多难。

　　另一方面，使用云计算产品，我们只是利用他人的成果和我们既有的基础设施，从而缩短实施周期，减少工作成本。因此，只要大胆求证，小心调研，轻松打造灾备/业务连续性方案不是问题。下面我来解释一下我的做法。

　　规划灾备/业务连续性方案的第一步，是识别可能出现的风险。这里的“风险”，包括所有的自然、人为灾难。不同地区，潜在自然灾害的表现形式有所不同，但不外乎飓风、地震、火灾和洪灾。另外一方面，潜在人为灾难的表现形式，从心怀不满者（可以是任何一个人）的报复行为，到重大事故（有人闯进变压站导致的停电），到没有任何动机的傻帽行为（例如，系统管理员不小心关闭了数据中心的冷却系统，导致服务器损坏，他却一点都没意识到）。

　　接下来，我会定性分析特定风险发生的概率和影响。仍举例说明，森林火灾对我数据中心的影响大么？因为我的数据中心所在地更像沙漠，所以，森林火灾对我数据中心的影响，是属于天文数字般的小概率事件。停电对我的影响有多大？因为我的数据中心已建有防范冬日暴雪影响的设施，可能发生灾难不再考虑掉电的可能及影响。

　　在识别出可能发生的风险及其概率/影响之后，我会设计风险弱化方案。如何对付停电？发电机和UPS。如何对付傻帽行为？严密的操作流程和自动纠错系统。如何应对潜在的自然灾害？我认为，云计算可以解决这一难题。

　　我的灾备/业务连续性方案包括两个重要组成部分，一是云计算，二是系统分类。系统分类是我最喜欢的一种做法。通常我将业务/应用系统分为三类，A，B和C类。A类系统，是系统宕机超过几分钟业务就会严重受损的系统。B类系统，是系统宕机一段时间后（从几小时到几天），业务才可能受损的系统。C类系统，系统允许宕机更长时间，业务都不会受到影响。这样的系统分类也是制定服务水平协议（SLA）和灾备/业务连续性计划的基础。对于A类系统，即使有冷备、热备甚至实时备份，我都担心业务难免受影响，因此我为A类系统引入更大的冗余。我的风险评估，也仅仅是针对A类系统。

　　例如呼叫中心的电话。如果电话出现故障，客户订单无法处理，因此电话系统属于A类系统-不是整个呼叫中心的电话系统，而只是处理客户订单的那些电话装置。仅仅几年前，我还在就如何建立一个呼叫中心的异地分部而操心。当云计算系统开始支持高可用性的呼叫服务后，我的生活开始变得简单多了-因为在我眼里本来是A类的呼叫中心，不再需要我如此地重视。