你不能虚拟化那个！

在 IT 行业，我们常常遇到这种情况：某个厂商告诉我们，某个系统无法被虚拟化。其理由五花八门。在 IT 这一方，我们总是震惊于厂商竟会提出如此荒谬的主张；而同样令我们震惊的是，客户（或经理）往往对此深信不疑。多年来，厂商们一直在努力打磨这套销售说辞，我认为有必要对其加以剖析。

问题的根源在于，厂商几乎总是在寻找方法，既降低自身成本，又从客户身上获取更多利润。这驱动了许多在其他情况下会被视为反常的行为。

许多许多厂商试图做的一件事，就是限制其产品获得支持的场景。通过这样做，他们为自己做好了干脆不提供支持的准备——支持成本高昂且难以保证。这是一种常见的策略。在某些情况下，这种做法激进到任何可被接受的生产部署场景根本就不存在。

实现这一点的一种非常常见的手段，就是不支持任何受支持的操作系统，从而实际上让厂商自己的软件被弃用（例如，放到今天，这意味着只支持 Windows XP 及更早版本）。另一个例子是只支持那些并未获得相应使用场景授权许可的产品（一个例子是要求将 Windows 10 这样的产品当作服务器来使用）。而最常见的情况之一，就是禁止虚拟化。

这些场景将客户置于两难境地，因为一方面，他们有行业最佳实践、标准部署准则、内部工具以及必须遵守的策略；另一方面，厂商却常常禁止正确的系统设计、规划与管理。这些需求彼此冲突。

当然，没有人指望每一个厂商都能支持每一种潜在的场景。必须设定界限。但在支持合理、部署良好的系统，与主动要求采用不可接受的糟糕部署之间，存在着一道巨大的鸿沟。我们希望我们的厂商能像业务伙伴那样行事，与我们共享对我们成功的关注，或者至少共享对其产品成功的关注，而不是直接试图破坏这两个目标。我们希望，至少在最低限度上，厂商能为任何合理的部署场景提供尽力而为的支持，并且很可能为按照最佳实践、经过妥善工程设计的场景提供有保证的支持。

想象这样一个世界：遵守限速、系好安全带反而会让你的汽车保修失效，而只有在你鲁莽驾驶且毫无防护时才能获得支持！

关于虚拟化，有一些重要的事情需要弄清楚。首先，虚拟化是一项由来已久的行业最佳实践，在任何面向服务的生产部署场景中都被期望使用。虚拟化绝非新事物，即使在小型企业市场，它跻身最佳实践之列也已远超十年，而在企业领域更是已有数十年之久。我们早已过了那个把以非虚拟化方式运行系统视为可接受做法的阶段，这其中也包括那些已经运行了很长时间的遗留部署。

当然，几乎任何规则都总会有罕见的例外。某些系统需要访问非常特殊的硬件，虚拟化可能无法实现，不过有了现代的硬件直通技术，这在今天几乎闻所未闻。还有一些超低延迟系统无法被虚拟化，但这些通常仅限于规模最大的国际投资银行和最激进的对冲基金，而且即便是这些传统使用场景中的大多数，也已经因虚拟化的改进而被消除，使得连这类情形都变得罕见。但归根结底，如果你无法虚拟化，你应该为此感到遗憾，并且你会清楚地知道为什么在你的情况下它不可能实现。在所有其他情况下，你的服务器都需要是虚拟的。

它是否不重要？

如果一个厂商不允许你遵循健康部署的标准最佳实践，这又说明了厂商对其自身产品持何种看法呢？如果换作任何其他部署，我们会立刻质疑：既然打算依赖这个系统，为什么要把它部署得如此糟糕。如果我们的厂商迫使我们以这种方式行事，我们也应该以同样的方式作出反应——如果厂商对待其产品的认真程度还不如我们对待最微不足道的 IT 服务，那我们又何必如此呢？

用我们工程界的话来说，这是一种我们的需求（生产系统）与制造该系统的厂商对待它的方式（业余爱好或娱乐系统）之间的“阻抗失配”。如果我们需要让自己的业务依赖于这个产品，我们就需要一个真正参与其中、理解业务需求的厂商——一个具有生产思维的厂商。如果该产品并非面向业务或并未为业务做好准备，我们就需要意识到这一点。我们需要质疑：为什么我们会觉得，应该在生产环境中使用一个我们要依赖并要求获得支持、但本就不打算以这种方式使用的服务。

它是否受支持？它是否正在接受测试？

从客户的角度来看，一件经常被忽视的事情是：某个产品所必需的支持资源是否到位。一个产品的支持团队变得人手单薄、甚至彻底消失，而公司却仍在继续销售该产品，指望从中尽可能多地榨取价值，并寄希望于要么能勉强应付问题，要么在厂商被发现确实无力提供支持的境地时干脆退还客户的钱款——这种情况并不罕见。

大多数软件合同都规定，可从厂商处获取的最大赔偿不过是产品的成本，或是购买它所花费的金额。在这样的情况下，厂商提供一个他们无法支持的产品并不承担任何风险——即便他们为支持收取高额费用。如果客户设法用起来了，那很好，他们照样收钱。如果客户用不起来，而厂商又无法支持，他们损失的也只是本就永远拿不到的钱。承担全部风险的是客户，而非厂商。

当然，这也暗示着该产品几乎没有或根本没有持续的测试，这一点应当引起额外的关注。产品现在能运行，并不意味着它将来还能继续运行。让一个不受支持、甚至更糟糕——根本无法支持的产品跑起来并投入使用，意味着随着时间推移，你越来越依赖一个潜在支持水平很可能不断下降的产品，它会随着时间慢慢变得越来越糟，而与此同时，对支持的需求以及对该软件的依赖却预期会不断增加。

如果一个专有产品被部署在生产环境中，并且为了迁就支持方面的要求而决定放弃最佳实践部署，这又如何能纳入决策矩阵之中？这是否应当意味着妥善的支持根本不存在？同样，正如前面所说，这暗示着与我们需求的失配。

 

它是否仍在开发中？

如果软件的部署需求遵循的是陈旧、过时的做法，或者要求使用过时的（或并不算合理地保持最新的软件或设计），那么我们就不得不质疑该产品当前仍在开发的可能性。在某些情况下，我们可以通过观察软件发布周期一段时间来作出判断，但并非所有情况都行得通。有一种合理的担忧是，该产品可能已经“死亡”，没有任何剩余的开发团队还在为它工作。这些代码可能只是陈旧的技术债，被拿出来出售，指望从一个已被弃置的旧代码库上再赚取最后那么几美元。这个过程实际上远比人们通常以为的要常见得多。

较小的软件公司往往能够成功开发出一款初始的软件产品，将其推向市场并供人购买，却无力在初次发布之后保留或重新组建其开发团队。事实上，这是一种非常常见的情形。这让客户手握一款预期会随着时间推移越来越缺乏生命力的产品，其部署场景的风险与日俱增，而数据也越来越难以剥离出来。

 

如果平台本身都不受支持，它又怎么可能受支持？

某些更极端情形中常见的一个悖论是：某款软件为了够得上“受支持”的资格，要求使用另一些软件，而那些软件要么已经脱离支持，要么从未针对其预期使用场景受过支持。常见的例子包括要求服务器系统运行在桌面操作系统之上，或者要求使用某些已经完全不再受支持的操作系统、数据库或其他组件版本。后一种情形常见得令人胆寒。在这样的情况下，人们不得不发问：那么究竟还能不能存在一种部署，使该软件可被视为“受支持”？如果技术栈中的某一部分始终脱离支持，那么整个技术栈都是不受支持的。无论如何，总会有一个可以拒绝提供支持的理由。因此，那个本应让我们要求避开最佳实践的理由，同样会从一开始就排除选择该软件本身。

是否缺乏行业技能与知识？

或许，我们在这类软件支持问题上所面临的问题在于：开发该软件的团队根本不懂好的软件是如何打造的，和/或好的系统是如何部署的。在所有可能将我们引向这种境地的原因中，这是最合理、最站得住脚的原因之一。但是，正如前面那些假设性的原因一样，它依然让我们对软件的质量以及支持是否真正可得心存忧虑。如果我们不能信任厂商妥善处理系统中最显眼的部分，我们又为何要在那些我们无法验证的部分上把他们当作专家来求助呢？

最大的问题

对于那些以解锁本被扣留的支持为交换、却提出存疑的部署与维护实践要求的软件而言，其最大、最根本的问题，并不像我们通常以为的那样是一个整体软件质量的问题，而是一个可行的支持与开发实践的问题。这些问题暗示着对长期支持的重大担忧，这本应让我们强烈质疑：既然从一开始我们就有着非常显眼、非常严重的顾虑，我们为何还要选择这些软件包，同时还指望从它们那里获得强有力的支持。

当然，确实存在这样的情况：没有其他软件产品能满足某项需求，或者没有任何具有更合理可行性的产品。这种情况应当极为罕见，而如果这样的情况确实存在，那么对于希望进入这一特定领域的厂商来说，它应当被视为一个重大的市场机遇。

从业务的角度来看，至关重要的一点是：绝不能为了盲目或近乎盲目地遵从厂商的要求，而将技术基础设施的最佳实践完全置之不理——这些要求在任何其他情形下都会被视为鲁莽或不专业。为什么我们如此频繁地疏于以应有的方式，对我们业务赖以依存的核心产品提出卓越性的要求呢？这会让我们的业务陷入风险之中，不仅源于行为本身，更远远地源于这样一项要求的存在所暗示的种种风险。