无论从哪个角度看，停机都不能算是件好事，哪怕是计划内的常规停机也是如此。随着企业规模的扩展与全球化趋势的加剧，任何时间段可能都有员工、客户、合作伙伴乃至供应商在访问我们的基础设施；事实上大家可能越来越难找出不会影响到任何使用者的纯维护时间段。在打造一套永远在线、始终可用的业务体系时，我们没有任何捷径可走。在本文中，我们将一同分享达成这一目标的三个步骤，希望借此帮助企业在持续而稳定的发展中建立更加科学高效的常规机制。
让我们想象这样的情景：作为供职于某家大型在线电子商务零售企业的一员，我们扮演着为公司处理基础设施及硬件运转工作的角色。这天中午，公司里的基础设施那边传来噩耗：某个重要组成部分发生故障。在我们手忙脚乱想尽快终结这场骚乱的同时，企业网站遭遇停机的坏消息已经不胫而走：这不仅在无形之中令公司失去数以万计的潜在客户，社交网络上的指责之声更是令已经与我们合作的用户如坐针毡。当然，情况还可能更糟，这并不是普通的一天，而是全年访问量最大的时段之一。
哈哈，这可真是噩梦般的场景，对吧？这种在最紧要的关头发生最严重停机事件的情况，只是想想就叫人不寒而栗。客观事实也的确如此，无论是在计划内还是计划外，停机就是停机，这永远不可能成为一件好事。随着企业中越来越多的员工开始以移动方式在家中处理工作，一周五天、一天九小时的常规工作概念已经逐渐发生转变。另外，企业的全球化趋势日益加剧，这样一来每个时段可能都会有身处不同时区的员工、客户、合作伙伴以及供应商访问我们的基础设施。在这种情况下，业务体系必须保证全天候可用；任何停机事件都会给大量访问者带来影响。
在业务体系的可用性方面，还有一大更为雪上加霜的状况：客户其实很少单独在我们自己打造的企业平台上处理工作。时至今日，IT部门需要为内部员工及外部客户、合作伙伴及供应商提供两套不同的业务需求支持。不过这两个群体的需求虽然彼此独立，但却有很多相通之处：正如内部员工希望随时随地使用企业资源进行工作，外部客户同样需要获得全天候采购、接收通知或者访问企业数据及系统的能力。Forrester分析公司对这一概念的定义是“扩展型企业”，也就是说企业已经无法仅仅通过内部基础设施来处理业务中的各类需求，自给自足型工作流程如今几乎成为一种空想。
保持业务体系的正常运转与始终可用绝没有捷径可走；要实现这一目标，我们必须将成熟而稳定的流程、人力以及必要的科技有机加以结合。对于企业而言，服务方案的成熟性表现在系统的高度可用性以及灾难恢复的的协调一致方面——Forrester指出，这是衡量企业技术弹性能力的重要指标。而要实现这种服务品质，企业必须花费几年时间提升自己的管理策略，适应停机带来的影响并严格保护股东投资免受技术事故的拖累。
我们当然不可能一夜之间就让企业实现永远在线、始终可用的目标，但正所谓不积跬步无以至千里。只要遵循以下三点内容，相信大家一定能引导自己的企业走上良性顺畅的发展轨道：
第一步：了解关键性业务遭遇停机时所造成的损失
大家都知道，要通过强大的业务可用性来保障企业投资回报可不是件容易的事；尤其是在我们不了解停机事故在单位时间中会造成多少损失时，整体故障成本就更加难以估量。Forrester公司发现，由于统计工作的极高难度，大多数企业都无法准确计算自身关键性业务遭遇停机时所造成的具体损失。尽管恢复口碑及挽救客户忠诚度的工作同样难度极高，但明确事故造成的营收损失或者生产力损失仍然是一项非常有价值的业务工作。
请记住，业务中断所导致的后果并不总是完全一致：事故发生时段与持续时间对于最终故障损失起着决定性作用。举例来说，在潜在客户访问量最大的时段出现故障往往会对业务造成最大影响。显然凌晨三点的停机事件比中午出现问题要有利得多。另外，事故发生的具体日期影响也有所不同：比起某一天中连续四个小时的停机状况，将网站业务中断以半小时为限平均分配在八天完成明显更加有利。一般来说，持续时间较短的停机事件造成的负面影响要比长时间停机小得多。因此如果企业业务停机已经不可避免，那么详加规划则可以让整个过程更加顺畅且低调。
我个人的建议是，千万不要试图一次性解决基础设施中的全部问题；以服务项目为单位逐个计算，并从最关键的服务为起点分步实施。只要时间分配得当，相信我们能够将故障的负面影响降至最低。总而言之，透彻理解停机损失及成本能够有效保障企业投资的回报率，并维护我们在客户及合作伙伴中的良好声誉。
第二步：关注终端服务的可用性，而不要过分在意基础设施组件
大多数企业都在不遗余力地监控服务器及存储设备的正常运行时间，但却很少有人关注某个单独服务项目的终端正常运行时间。事实上，终端单一服务的正常运作需要基础设施中组件与软件的协调搭配方能实现。我们应当尽早转变观念，引导IT部门将注意力转移到终端服务的使用体验上，因为这才是企业留住甚至发掘新客户的关键性指标。在这个客户至上的时代，IT部门必须拿出极具竞争力且使用体验优异的服务才能获得市场的肯定，而业务流程与处理无疑是其中的重中之重。
第三步：将业务目标与技术进行合理搭配
在对自身停机损失进行准确度量并将关注重点转向终端可用性之后，下一步则是为自己的关键性服务选择合理的技术支持组合。尽管能为永远在线、始终可用的扩展型企业所用的技术为数众多——例如主动型架构、虚拟机快速启动、应用程序与服务监控解决方案以及云服务等等，但最困难的部分在于找到一套能够在支持可用性目标之余、合理保护关键性服务并符合企业运营成本要求的技术组合。不少企业都在遵循这样一套方案：将服务项目或者应用程序按关键性差异加以分类，并为每一类项目指定与之相匹配的恢复时间目标（简称RTO）、恢复点目标（简称RPO）以及服务水平协议（简称SLA）。这种分门别类的处理方法使得企业能够将适当的技术应用在适当的业务对象当中，进而在保证服务可用性的同时最大程度压缩运营成本。
100%正常运行时间根本不现实
最后，我们还要明确一点：即使是号称永远在线、始终可用的企业，仍然无法真正达成100%正常运行时间；相反，这里所说的100%仅仅是指关键性业务的连续性保障。虽然目前已经有许多公司在正常运行时间方面取得了令人瞩目的成绩，但我们必须认清这样一个现实：长时间维持100%可用是根本不可能的。干扰因素的层出不穷使得理想终究只能是理想：从基础设施故障到应用程序缺陷、从自然灾害到人为意外，甚至连计划内维护也有可能令服务项目中断那么一阵子。
既然停机现象永远无法彻底根除，最好的应对方法是适当转变自己的态度。以往发现停机之后的手忙脚乱殊不可取，积极规划、改善流程并做好预防才是正确选择。我们无法达到100%正常运行时间，但我们应该勇于直面这一现实，并努力为客户在特殊时期提供他们最需要的服务。此外，建立起快速反应机制，确保服务能够在最短时间内恢复正常。只要能做到这些，相信大家的企业必将在激烈的市场竞争中脱颖而出。
原文名：How to Build an Always-On, Always-Available Enterprise
来源：CIOAge 文: 核子可乐译
转播
分享
淘帖
()
