何时应当考虑高可用性？

“高可用性不是你能买来的东西，而是你需要去做的事。”——John Nicholson

在 IT 领域，很少有什么比高可用性（HA）解决方案更受到普遍渴望。我是说真的，只要说出这几个字，任何一位 IT 专业人士都会立刻表示他们想要它。为他们的服务器、应用、存储，当然还有他们的桌面端实现 HA。如果在任何一个系统旁边都有一个写着“HA”的复选框，我们为什么不勾选它呢？我们当然会勾选。没有人会自愿想要一个频繁出故障的系统。故障是坏事，成功是好事。

不过，首先我们必须定义 HA。HA 可以意味着许多东西。至少，HA 必须意味着相关系统的可用性必须高于“正常”水平。什么是正常？单是这一点就已经够难定义的了。HA 充其量是一个含义松散的术语。不过，在它最常见的使用语境下，也就是在常规企业级硬件上运行的常见应用这一语境下，我愿为 HA 的讨论提供这样一个起点：

正常可用性或标准可用性（SA）可被定义为：在采用最佳实践的环境中、配有企业级支持的情况下，一台常见的主流服务器运行一个常见的企业级操作系统、再运行一个常见的企业级应用所能达到的可用性。这方面的好例子可能包括：在 HP Proliant DL380（最常见的主流商用服务器）上运行 Windows Server、再运行 Exchange；又或者在 Dell PowerEdge R730 上的 Red Hat Enterprise Linux 上运行 BIND（DNS 服务器）。这些只是用来确立一个粗略基准的示例。并没有什么很好的方法来衡量这一点，但在现实世界中，凭借良好的支持合同以及快速的维修或更换，这类系统的可靠性被认为在不计入人为故障的情况下介于四个九到五个九之间（99.99% 或更高的正常运行时间）。

高可用性（HA）通常应被定义为：拥有显著高于标准可用性的可用性。“显著更高”应当至少是一个数量级的提升。因此，可靠性至少要达到五个九，而更有可能是六个九。（99.9999% 的正常运行时间。）

低可用性（LA）通常应被定义为：拥有显著低于标准可用性的可用性，其中“显著”同样意味着至少一个数量级。因此，LA 通常会被假定为大约 99% 到 99.9% 或更低的可用性。

这里的衡量非常困难，因为人为因素、环境因素以及其他因素在决定不同配置的正常运行时间方面发挥着巨大作用。同样的设备用在一种角色中可能达到五个九，而用在另一种角色中却连一个九都达不到。数据中心的质量、支持人员的技能水平、零部件更换的迅速程度、监控的细粒度以及其他众多因素，都会显著影响整体可靠性。然而，这对我们而言未必是个问题。在大多数情况下，我们可以这样去评估系统设计中由我们掌控的那些部分：使相对可靠性能够被确定下来，从而至少能够表明一种方案将优于另一种方案；这样，即便无法轻易建立精确的故障率模型，我们也能够借此进行有充分依据的决策。

需要特别指出的是，除了提供一组可供参照的示例性基准之外，高可用性或低可用性的定义中没有任何内容谈及应当如何实现这些级别——这并不是这些术语的含义。这些术语是相对于基准而言的可靠性结果集，仅此而已。实现高可用性有许多方法，不必采用通常假定的那些做法；而实现低可用性的方法则几乎是无穷无尽的。

当然，HA 可以在每一个层面上加以定义。我们可以拥有 HA 的平台或操作系统，但其上却运行着脆弱的应用。因此，在任何给定时刻都清楚我们所谈论的是哪个层面，这一点非常重要。归根结底，企业只会关心服务以高可用方式交付，而不论它是如何实现的、或在何处实现的。重要的是最终结果，而不是它如何达成的那些“幕后”细节，或者一如既往地说，结果证明手段是正当的。

如今，IT 部门极其普遍地会被平台层那些新颖而炫目的 HA 工具所分散注意力，而忘记了到技术栈更高和更低的层面去寻找 HA，以确保我们为企业提供高可用的服务；他们只盯着某一个层面，却让企业像以往一样脆弱，甚至更加脆弱。

然而在现实世界中，HA 并非总是一个可选项；而当它可选时，它是有代价的。这种代价几乎总是金钱上的，并且通常还伴随着额外的复杂性。而我们都很清楚，任何复杂性也都带来额外的风险，如果我们不小心，这种风险可能导致一次实现 HA 的尝试实际上以失败告终，甚至可能让我们落入 LA，即低可用性。

一旦我们理解了这套用来描述我们意图所必需的语言，就可以开始讨论高可用性、标准可用性、乃至低可用性在何时可能适合我们。我们之所以采用如此高层次的粒度，是因为衡量系统可靠性实在太过困难，以致过于深入细节反而变得毫无价值。

从概念上讲，所有系统都伴随着停机的风险，没有什么能够始终在线，那是不可能的。在其他条件相同的情况下，可靠性通常是要花钱的。因此，要确定哪一级别的可用性最适合某个工作负载，我们必须确定风险缓解的成本（即改变平均停机时间所需花费的金额），并将其与停机本身的成本进行比较。

这件事变得棘手而复杂，因为确定停机成本本身就已经够难的了，而确定停机风险则更加困难。在许多情况下，停机损失并不是一个固定的数字，但它也可能是。这一成本可以表示为每分钟 5 美元、每天 2 万美元或类似的形式。但一个更好的工具，是创建一条“损失影响曲线”，以展示金钱是如何随时间推移而损失的（在一个合理的区间之内）。

举例来说，一家公司在最初的五分钟里很可能完全不会有任何损失，随后损失会缓慢增加但数额很小，直到大约四个小时后，当人们再也无法改用纸张或其他替代手段、工作随之停止时，损失便从几乎为零骤增到相当庞大。又或者，有些公司可能在系统宕机的那一刻就遭受巨大损失，但损失会随时间推移而缓慢消散。损失或许只在一天中的某些时段才具有影响。也许夜间或午餐时间的中断无关紧要，但上午时段或下午时段的中断却事关重大。每家公司的影响、风险以及缓解该风险的能力都各不相同，而且往往差异极大。

有时这归结于在这家公司工作的人。当系统发生故障时，他们会不会都乐意去享用所需的如厕、咖啡、零食乃至午餐的休息时间，以便在系统修复后回来继续工作？人们会不会为了弥补一次重大中断而提早回家、明天提早到岗？是否有机器将会闲置？响应客户的能力是否会受到影响？生命维持系统是否会失效？潜在的影响不计其数，缓解不同类型故障的潜在方法也不计其数。所有这一切都必须加以考量。停机的成本可能只是企业每分每秒所产生营收的一小部分，又或者停机可能造成客户或信任的流失，其影响比每分每秒所产生的营收更为深远。

一旦我们掌握了一些粗略的损失数字可供处理，至少就有了一个起点。即便我们只知道营收约为每分钟 10 美元、预计损失约为每分钟 5 美元，我们也算有了某种起点。如果我们有一条完整的曲线，或者有一项做过更详尽数字研究的成果，那就更好了。现在我们需要大致弄清楚我们的基准会是什么。一台维护良好、在本地运行、配有良好支持合同以及良好备份与恢复流程的服务器，相当轻松就能达到四个九的可靠性。这意味着我们每五年大约会经历五个小时的停机。这实际上低于大多数环境中对 SA 通常预期的停机时间，并且有可能远低于优秀环境（如配有就近零部件与服务的高质量数据中心）中的预期水平。

那么，基于我们这个每五年约五小时的基准示例，我们就可以算出我们的潜在风险。如果我们每分钟损失约 5 美元，而预计每五年大约有 300 分钟的停机，那么我们面对的就是每五年潜在损失 1500 美元。

这意味着，最极端来说，我们绝不可能花 1500 美元去缓解那项风险，那在财务上是荒谬的。其原因有好几个。其中最大的一个是：这只是一项风险，花 1500 美元去防范损失 1500 美元几乎毫无意义，但当人们不仔细分析这些数字时，这却是一个非常常见的错误。

最大的因素在于，任何缓解手段都不是完全有效的。如果我们设法把四个九的系统提升到五个九的系统，我们也只是减少了平均停机时间的 90%，把损失从 1500 美元降到 150 美元。如果我们为这次降低花了 1500 美元，那么总的“损失”仍然是 1650 美元（防护的成本是财务损失的一种形式）。风险缓解的成本，与缓解后预计仍会发生的影响合在一起，仍然必须低于不加缓解时该风险的预计成本，否则缓解本身就是徒劳的，甚至是积极有害的。

许多人也许会质疑，为什么风险缓解的总成本必须更低、而不能仅仅相等，因为相等想必意味着我们正处于一个“风险盈亏平衡”点？这表面上看似乎成立，但由于我们处理的是风险，事实并非如此。风险缓解是一笔确定的成本——是我们预先承受的财务损害，寄望于借此减少明天的损失。但明天的风险是一种猜测，但愿是一种很有依据的猜测，但终究只是猜测。今天的成本则是确定的。今天承受确定的损害、以期减少明天可能发生的损害，只有在今天的损害很小、而明天预期或可能发生的损害非常巨大、且缓解的有效性十分显著时，才说得通。

在“预先付出确定成本”以减少“明天可能成本”这一理念之中，还包含着货币时间价值的概念。即便一次中断在规模和时间上都是已知的，我们也不会愿意在今天花费与明天等额的钱去缓解它，因为我们的钱在今天更有价值。

在最为极端的情形中，我们有时会看到 IT 部门要求预先花费数万乃至数十万美元，去避免在将来某个时刻——也许是许多年以后——也许损失区区几千美元。这种策略我们可以称之为“今天朝自己脸上开一枪，以免明天也许会头疼”。

这一点已被纳入评估风险缓解的概念之中，但仍值得专门指出：就 IT 设备而言，有许多尝试进行风险缓解的例子，其有效性可能并不如人们所以为的那样高。例如，把两台服务器放在同一个机架里，对于缓解主机硬件故障的风险或许会非常有效，但它无法缓解自然灾害、站点损失、火灾、大多数情况下的电击、灭火系统启动、网络中断、大多数应用故障、勒索软件攻击或其他合理可能发生的灾难。

存储设备通常配备“双控制器”，这给人一种可靠性很高的强烈印象，但一般来说这些控制器位于单一机箱之内、共享组件；即便组件不共享，固件往往也是共享的，而组件之间的通信又十分复杂；这常常导致一种故障——一个组件的故障会触发另一个组件的故障——从而使它们相当频繁地成为 LA 设备，而非人们购买时所期望的 SA 或 HA。因此，认真考虑风险缓解策略将缓解哪些风险、以及该缓解手段是否可能有效，是极为关键的。没有任何手段是完全有效的，故障的可能性始终存在，但有些策略和手段比其他的适用范围更广、更有效，而有些则纯属误导，甚至会适得其反。如果我们不小心，就可能部署一些代价高昂、却积极地破坏我们目标的产品或手段。

在追求高可用性的过程中所使用的一些手段和产品相当昂贵，其中可能包括购买冗余硬件、租赁另一栋楼宇、安装昂贵的发电机或为特殊软件付费授权。也有一些低成本的手段和软件，但在大多数情况下，任何朝着高可用性迈进的举措都会相应地带来一大笔投资资本的支出才能实现。务必牢记，高可用性是一个过程，根本没有办法简单地把高可用性买来。实现 HA 需要良好的文档、流程、规划、支持、设备、工程设计等等。在系统的世界里，HA 通常首先从环境的角度着手，配备故障转移发电机、冗余的 HVAC 系统、电源调节、空气过滤、灭火系统等等，以确保可用性所依赖的环境到位。仅此一项往往就能让进一步的投资变得没有必要，因为它能够带来惊人的成效。其次是 HA 系统设计，确保不仅技术栈的某一个层面具备高可用性，而是整个技术栈都具备，从而让关键的应用、数据或服务在尽可能多的时间里保持可用。再次是着眼于站点间的冗余，以便能够抵御洪水、飓风、暴风雪等等。当然，还有一些完全不同的手段，例如利用代为托管在远程的云计算服务。重要的是，高可用性需要广阔的思考与规划，不能仅仅作为一个明细项被购买，而且其优劣是以这样一种能力来评判的：能够回报出一个风险因子，从而带来远高于“标准”系统设计所能交付的正常运行时间或正常运行时间的可能性。

对许多企业、尤其是对那些极少进行财务风险分析、并且不断被告知 HA 是任何企业的必需品、购买最新 HA 产品毫无疑问就是他们预算应当如何花费的方式的 IT 专业人士而言，往往令人意外、几近震惊的是：当数字被仔细核算、风险缓解策略的成本与有效性的现实被纳入考量之后，会发现高可用性在任何组织中其实都鲜有用武之地，尤其是在那些规模较小或工作负载高度参差不齐的组织中。在中小企业市场中，几乎普遍可以发现，高可用性方案的成本与复杂性（复杂性反过来又带来风险，主要表现为缺乏围绕相关手段与风险评估的经验）实在太过高昂，永远无法抵消其所期望防范的那次中断可能造成的损害。当然也有例外，确实有许多企业采用高可用性解决方案是绝对明智的，但这些都是例外，远非常态。

同样明智的是，将高可用性的需求按工作负载为基础来考量，而非以部门、公司或技术为整体范围来考量。在小型企业中，常见的情形是所有工作负载共享一个共同的平台，于是某一个工作负载对高可用性的需求，可能会把其他不那么关键的工作负载一并裹挟进来。这完全没问题，而且是一种很好的方式，可以通过附带惠及那些不那么关键的工作负载，来抵消对关键工作负载进行风险缓解的成本。在一个针对不同工作负载使用了多种平台方案的较大组织中，常见的情形是：只有那些既高度关键（就停机影响所带来的风险而言）、又能切实有效地缓解风险（缓解风险的能力在不同类型的工作负载之间可能存在巨大差异）的特定工作负载，才会对其应用高可用性，而其他工作负载则交由标准手段处理。

既可能关键、又能借助高可用性得到有效应对的工作负载，其例子可能是一个在线订购系统：多区域复制所造成的延迟对整个系统的影响微乎其微，但一旦系统发生故障而丢失订单，在财务上却可能影响极大。一个高可用性也许易于实现、却收效甚微的工作负载例子，可能是一个为常见 HR 问题提供解答的内部 Intranet 站点；对于这样一个系统，为了避免少量偶发的停机而投入成本，根本不划算。一个风险很高、但风险缓解的成本或有效性使其不切实际乃至根本不可能的系统例子，可能是一个金融“tick”数据库，它要求摄入海量的低延迟数据，而维持一个副本不仅会代价惊人，还可能引入足以削弱该系统充分运行能力的延迟。每一家企业、每一个工作负载都是独一无二的，都应当被仔细评估。

当然，高可用性手段是可以分阶段实施的；它并非一项要么全有、要么全无的工程。通过具备应用层的容错能力来防范系统硬件、虚拟化平台或存储的故障，从而缓解系统级故障的风险，这或许是切实可行的。但对于同一个工作负载，防范单一站点的损失也许就没有什么价值了。如果某个工作负载只服务于某个特定站点，或者其价值根本不足以支撑实现跨站点故障切换所需的巨额投资，那么它很容易就会落在“中间地带”。工作负载只实施部分高可用性解决方案是非常常见的，这往往是因为一个 IT 部门可能只负责其中的一部分，而对诸如电力保障和 HVAC 之类的事项没有发言权；但最常见的原因或许在于，某些高可用性手段被视为高曝光度、易于向管理层推销，而另一些（比如高质量的电力和空调）则往往连提都不会被提及，尽管它们可能轻而易举就提供了更高的性价比。之所以会选择某些手段而非另一些，是有充分理由的，因为它们影响着不同的风险组成部分，而某些风险对某个具体企业或工作负载可能有着不同的影响。

高可用性需要审慎思考它是否值得考虑，并且在实施方面需要更加审慎的思考。构建真正的 HA 系统需要投入大量的精力与专业知识，并且通常需要可观的成本。要弄清楚 HA 的哪些组成部分有价值、哪些没有，不仅需要广博的技术专长，还需要财务与管理方面的技能。各部门必须广泛协作，才能真正理解 HA 将如何影响一个组织、以及何时它才值得投资。至关重要的是要牢记，在一个组织中、或对某个工作负载而言，对高可用性的需求绝非什么板上钉钉的定论，而如果发现广泛的高可用性、乃至随意的高可用性实践在经济上原来并不切实际，也丝毫不应感到意外。

在许多方面，这是因为标准可用性已经达到了这样一种状态，以致需要缓解的风险持续不断地越来越少。企业基础设施中所使用的技术组件，尤其是服务器、网络设备和存储，已经变得如此可靠，以致我们必须防范的停机时间相当之低。对高可用性那种条件反射式需求的信念，大多源自一个不同的年代——那时可靠的硬件价格高得难以承受，而即便是最昂贵的设备，按现代标准衡量也相当不可靠。这种任何设备都可能在任何时刻发生故障的迫近末日之感，源自一个更早的年代，而非当下这个年代。现代设备虽然显然仍带有风险，却可靠得惊人。

除了其他风险之外，在高可用性解决方案上过度投资还带有可能十分巨大的财务与业务风险。它在业务不确定的局面下增加了技术债务。如果业务突然增长会怎样，或者更糟，如果业务突然萎缩、转变方向、被收购或彻底倒闭会怎样？即便对其防护的需求已经消失，对高可用性的投资也已经花出去了。如果技术或地点发生变化会怎样？部分乃至全部的高可用性投资，可能在其预期使用寿命到来之前就已损失殆尽。

作为 IT 从业者，评估技术解决方案的收益、风险与成本，正是我们工作的核心所在。与企业基础设施中的其他一切一样，确定风险缓解的类型、防护的价值、以及在财务上多少才算合适，是我们的关键职责，不容敷衍或忽视。我们绝不能想当然地假定高可用性是必需的，也不能假定它可以被简单略去。正是在这种性质的分析之中，IT 为组织带来了它最大的价值之一。也正是在这里，我们拥有最大的潜力去大放异彩。