仅仅因为你能……

我常常看到这个观念出现在围绕虚拟化的讨论中。这是一个更宽泛、更普遍的概念，但虚拟化是许多 IT 组织所面对的“当红新技术”，而且似乎正是在这一领域，我们目前最频繁地看到“仅仅因为你能做，并不意味着你就应该做”这类问题大行其道。与 IT 中的一切事物一样，至关重要的是把所有技术决策都置于业务情境之中，从而让我们明白自己为什么选择如此行事，而不是盲目地依据流行的部署方法论、乃至更糟糕的种种迷思来做决定。

我应当指出，我认为虚拟化本身在今天对于从事 x64 计算领域工作的人而言，应当成为一个默认的决策；只有在存在明确而显著的必要性时——例如特定的硬件需求、对延迟敏感的应用程序等——系统才应在不采用虚拟化的情况下部署。除非有任何特殊需求，否则虚拟化在许多供应商那里都可以免费实施，并且无论是在当下还是在为环境做面向未来的准备方面，都能带来诸多益处。

话虽如此，我如今经常看到的，是各家公司部署虚拟化并非将其当作一种最佳实践，而是当作解决一切所感知到的 IT 问题的灵丹妙药。它当然不是。虚拟化是 IT 工具箱中一件非常重要的工具，也是我们会非常频繁去取用的工具，但它并不能解决所有问题，理应像我们所拥有的其他每一件工具一样对待，只在恰当的时候使用。

当虚拟化作为一个话题被提出来讨论时，我看到有几件事反复出现。如今许多公司转向虚拟化，并不是因为他们识别出了某种业务需求，而是因为它是当下的热门话题，人们觉得如果不实施虚拟化，自己就会以某种方式被甩在后面，或是错失某种虚无缥缈的功能。这总体上是件好事，因为它正在提升虚拟化的采用率；但它也是件坏事，因为良好的 IT 与业务决策流程正在被绕过。结果往往是，在虚拟化炒作的浪潮中，IT 部门觉得自己不仅必须实施虚拟化本身，而且还得以可能并不适合自身业务的方式去实施。

有四样东西，我经常看到它们被与虚拟化捆绑在一起，并往往被当作虚拟化的必备要求，而不论它们在特定的业务环境中是否合理。这四样东西就是服务器整合、刀片服务器、SAN 存储，以及高可用性或实时故障切换。

整合如此频繁地被吹捧为虚拟化的好处，以至于我认为大多数 IT 部门都忘记了实施虚拟化还有其他重要的理由。显然，对于几乎所有的部署而言，整合都是一项巨大的好处（当然，具体效果会因情况而异），而且几乎总是仅仅通过更好地利用现有资源就能实现。一家运行着不止一台物理服务器的公司，如果不能通过有限的整合削减掉一定程度的成本，那是相当罕见的；而在规模较大的组织中，看到数据中心的占用空间被大幅缩减也并不少见。

不过，在极端情况下，并不需要仅仅因为整合被证明是不可能的，就放弃虚拟化项目。这类情况存在于那些系统利用率很高、却又没有多少预算用于前瞻性整合投资的公司。但这些机构仍然可以对系统进行“就地”的一对一虚拟化，从而在今天获得虚拟化的其他好处，并在将来硬件需要更换时、或在未来更大、更强劲的服务器变得更具成本效益时，再着眼于整合。重要的是，不要仅仅因为虚拟化最受推崇的好处在你当前的环境中可能并不适用，就将虚拟化排除在外。

刀片服务器常常被视为虚拟化环境的不二之选。比起处理更传统的计算工作负载，刀片服务器在标准的虚拟化环境中或许表现得更好，但这一点既极具争议，也未必是适用的依据。对刀片服务器本身而言是一个好的应用场景，并不意味着对企业而言也是一个好的场景。仅仅因为刀片服务器以这种方式使用时表现得比平时更好，并不意味着它们的表现就优于传统服务器——只能说明它们有可能缩小了差距而已。

在进行虚拟化时，刀片服务器需要用与不进行虚拟化时同样严苛的标准来评估，而且它们往往仍然无法提供选择它们、而非选择更灵活的替代方案所需要的那种长期业务价值。刀片服务器远算不上虚拟化的必需品，而且在我看来，它往往实在是一个相当糟糕的选择。

最常见的误解之一，就是认为转向虚拟化就必然也要转向诸如 SAN 之类的共享存储。这种思维定式，是对“同时也想从虚拟化中获得其他好处”这一愿望的明显反应；而这些好处即便不要求 SAN，也能从 SAN 中获益良多。在多个系统之间进行负载均衡或故障切换的能力，会因为有了一个共享的存储后端而得到极大的便利。认为这是一项硬性要求，乃是一种迷思；但复制式的本地存储也带来了它自身的复杂性和局限性。

然而，共享存储远算不上虚拟化本身的必需品，而且和一切事物一样，需要就其自身加以评估。如果虚拟化对你的环境而言是合理的，但你并不需要任何要求使用 SAN 的功能，那么就在不使用共享存储的情况下进行虚拟化。在许多情况下，基于本地存储的虚拟化都是一种理想的部署方案。没有必要不先认真考虑一番就摒弃这种做法。

最后一项被假定为虚拟化所必需的主要功能，是系统级的高可用性，即为你的操作系统提供即时故障切换。毫无疑问，系统层面的高可用性是虚拟化为我们带来的一项绝佳益处。然而，在实施虚拟化之前，很少有公司需要这种级别的高可用性，而要借助虚拟化来实现它所需的基础设施和软件，其价格标签往往高得离谱，以至于让人难以从成本上证明其合理性。

高可用性系统既复杂，又往往是矫枉过正。即便是最关键的系统，需要透明故障切换的业务系统也是极为罕见的；而那些确有此需求的公司，几乎肯定早已部署好了故障切换流程。我一直看到有公司在考虑虚拟化时转向高可用性，原因仅仅是某个供应商看到了一个机会，可以把最初的需求大幅度地过度兜售。高可用性的成本，很少能被相应缩减停机时间所带来的潜在收入损失的减少所证明其合理性。在非高可用的虚拟化环境中，如果备份处理得当，一台发生故障的硬件设备所导致的停机时间或许只能以分钟来衡量。这意味着，高可用性必须以每年潜在地消除区区几分钟的计划外停机时间——再减去因系统复杂性增加而承担的任何额外风险——来证明其成本的合理性。即便在规模最大的组织中，这一点也很少能在任何大范围内得到证明；而在规模更适中的公司里，这种情况则更是闻所未闻。但如今我们却发现，许多小型企业在那些原本完全可以承受多日停机、却几乎不会造成什么财务损失的系统上，以极高的代价实施着高可用性系统，原因仅仅是营销资料鼓吹了这个概念。

和任何事物一样，虚拟化以及它所带来的所有相关可能性，都需要结合正在考虑采用它们的组织的具体情境，逐一加以评估。如果某项具体功能对你的业务而言并不合理，就不要想当然地认为你必须购买或实施那项功能。许多组织实施了虚拟化，却只使用了这些“假定”功能中的少数几项，甚至一项都不用。不要把虚拟化看成一个黑箱，而要看清它的各个组成部分，并像考量任何其他技术项目一样去考量它们。

经常发生的，是一种滚雪球效应：某一项功能（很可能是高可用性）在没有进行恰当的业务评估的情况下，就被假定为必需的。接着，一套共享存储系统——往往被假定为高可用性所必需的——又作为另一笔被假定的开支被添加进来。即便最终并没有购买高可用性功能，使用 SAN 的决定也可能早已做出，而且在计划发生变更之后也未能被重新审视。以我的经验，发现这类项目中有时超过一半的总支出花在了采购方甚至无法说清为何要购买的产品上，是非常常见的。

这个观念并不止步于虚拟化。请把它推广到你所做的一切事情上。让 IT 始终保持在业务的视角之下，不要想当然地认为，采用了某一种技术就自动意味着你必须采纳那些在大众认知中与之相关联的其他技术。