为部署选择软件版本

我在 IT 圈子里经常看到讨论的一个话题是“我该安装哪个版本的软件”。这可能涉及数据库、应用程序、固件，或者最常见的操作系统，而随着 Windows XP 支持生命周期即将结束，这一话题已经达到了白热化的程度。

这场讨论实际上分为两派。一派认为应当始终使用最新的、想必也是最好的软件。另一派则认为软件需要成熟，主张采取“观望”的态度，甚至将每个版本都视为一个不同的产品，而非开发的连续体。

两种做法各有其优点，二者都不应在完全脱离对方的情况下存在。盲目地随意更新软件并不明智，毫无理由地回避补丁和更新同样不明智。在做出这些决策时，慎重权衡各项因素并对软件开发过程抱以同理心是很重要的。

首先，有两种完全不同的情形需要考量。一种是更新当前已有的软件，其前提假设是当前状态是“可用的”，同时也接受这种可能性：所谓“可用”可能包含一个已被发现、需要更新才能修补的安全漏洞。另一种情形是全新部署，即当前一无所有，我们从头开始。

我们先从第二种情况说起，因为它更容易给出指导。

在全新软件部署（或全新操作系统）的情况下，始终使用软件当前最新的版本，除非存在某种明确已知的技术限制阻碍这样做——例如已知的缺陷或软件不兼容。

软件不同于其他类型的产品，在当今这个在线发布补丁和更新的时代尤其如此。我认为，那种认为旧版本软件可能优于当前版本的心态，源自两方面的结合：一方面来自实体产品（手表、汽车、餐具、家具、葡萄酒），某个特定年份或型号可能因各种原因而优于较新的型号；另一方面则来自传统的软件交付方式，即成品软件不过是被“扔过墙”了事，其最终状态就那样简单地成为最终状态，没有任何合理的更新、打补丁或修复的机会。这两种情况都不适用于现代商业软件（仅有极罕见的例外）。

软件开发大致是一个连续体。正常的开发流程是在旧软件的基础上构建新软件，要么是直接的（通过为现有代码库创建更新），要么是间接的（基于构建前一版本软件所获得的知识进行重建）。其理念是每个后续版本的软件都优于其前一个版本。当然，这并不能保证，存在诸如回归错误和单纯的糟糕开发之类的概念，但总体而言，软件会随时间不断改进——尤其是当我们谈论的是用于企业、处于积极开发中的企业级软件时。新软件不仅仅是旧软件的下一个阶段，在几乎所有情况下，它还代表着补丁、缺陷修复、更新，以及在必要时方法或技术变更的当前状态。出自高质量团队的新软件，几乎无一例外地优于旧软件。软件会不断演进和成熟。

除了软件本身的质量之外，还有投资于未来这一概念。软件不是可以永远束之高阁的东西。它需要在某种程度上保持更新，否则就会停止运行，因为它所运行的平台会发生变化、某些新的因素会浮现、安全漏洞会被发现，或者需求会改变。安装旧软件意味着投资于过去，意味着投入资源去安装、学习、使用和支持旧技术。这被称为“技术债务”。这种旧技术或许能用上数年甚至数十年，但旧软件会随时间流逝而贬值，并且无论是对继续提供支持的供应商，还是对不得不维护它的最终用户而言，支持成本都会越来越高。

同样的技术债务概念也适用于相关的软件供应商。创建软件，尤其是维护该软件的多个版本，代价非常高昂。软件供应商有很大的动力去减少对旧版本的支持，以便将资源集中于当前的软件发布（这也是 SaaS 部署如此受欢迎的一个主要原因：供应商控制着可用的版本，并能通过更新淘汰旧版本）。如果客户要求支持旧版本，这笔成本必须在某处被消化，而往往它会在两方面被消化：既对所有客户产生货币层面的影响，也会降低对新产品的专注度，因为开发团队不得不分身去为旧版本打补丁，同时还要开发新版本。投入到旧版本上的精力越多，能投入到新改进上的精力就越少。

在我已经阐述的框架内，谈一谈代码成熟度很重要。人们常常将代码成熟度作为部署“旧代码”的理由，但我认为这是 IT 界对软件开发流程的一种误解。如果我们想一想一条已发布的代码线，仅仅因为它已发布并投入使用，并不会真正使它更成熟。代码不会在野外发生变化，它只是静止在那里。它的成熟度在发布之日就被“锁定”了。如果它被打了补丁，那么是的，它会在发布后“成熟”。基于相同代码库但更为新近的同一软件的后续版本，才是真正更“成熟”的代码，因为相较于同一代码的早期发布版本，它经过了更大程度的审查、更新、测试等。

这与汽车这类情形截然相反——就汽车而言，每一款发布都是全新的事物，伴随着机械问题的新可能性和不同的可靠性顾虑——在那种情况下，等上几年能让你看清哪些可靠性问题会暴露出来。软件并非如此。因此，想要更成熟软件的这一理念，会促使你去部署“最新最好的”，而非“久经考验的”。

如果我们把软件版本号当作年龄来看待，这一点就会显现出来。就软件成熟而言，Linux 3.1 比 Linux 2.4 要古老得多。它多出了十年的开发积累。

让我们用一个在今天非常切题的真实世界例子。你身处一家即将安装其首批服务器的公司。Windows Server 2012 R2 刚刚发布。你应该安装 Windows Server 2008、2008 R2（2010）、Server 2012 还是 Server 2012 R2（2013 年底）呢？

对许多公司来说，这听起来好像我们谈论的是两到四个完全不同的产品，每一个想必都有各自不同的选择理由。但这在很大程度上是不真实的。每个较新的版本只不过是对前一个版本的升级、更新、打补丁和功能增强。而每一个版本又都比它之前的那个更先进、更成熟。每个新版本都受益于在其前任的原始发布版本上所做的工作，以及在原始发布与后继发布之间这段期间所做的缺陷修复、补丁和功能新增。实际上，每个新发布都是其前一个版本的一次“次要发布”。如果我们看内核修订号而非这些发布的市场名称，或许会更有意义。

Windows Server 2008 就是 Windows NT 6.0。Windows Server 2008 R2 就是 Windows NT 6.1，显然是前一个发布的次要修订，甚至可以说是一次“补丁”。Windows Server 2012 是 Windows NT 6.2，而我们当前的 Windows Server 2012 R2 是 Windows NT 6.3。如果我们使用修订号而非市场名称，那么刻意去安装一个更旧、更不成熟、更新更少、补丁更少的版本，听起来几乎是疯狂的。我们想要的是最新的更新、最新的缺陷修复，以及最新的安全问题已得到解决。

对于全新软件部署而言，所安装的软件越新，就越有机会利用最新的功能特性，并在不可避免的过时最终造成影响之前拥有最长的时间。所有软件都会老化，因此安装较新的软件能为该软件持续使用最长的时间提供最佳机会。它为未知的未来提供了最佳的灵活性。

沿着这一思路推演，可能会让我们觉得部署预发布版本甚至 Beta 版软件也说得通。虽然在某些特定情况下这确实说得通，比如在“测试小组”中先行检验软件，然后再向公司整体发布，但总体而言并非如此。预发布软件的本质是它不受支持，并且可能包含永远不会得到支持的代码。在隔离环境中使用此类代码可能有益，但对于一般用途则不建议。无论整个产品处于何种成熟度水平，在预览版或 Beta 版发布与代码的最终发布之间，都有一些重要的流程需要遵循。

这就把我们带到了另一种情形，即我们正在更新现有软件的情形。这当然与全新安装是完全不同的场景，涉及的因素要多得多。

对大多数情况而言，最大的因素之一是许可。定期更新软件可能会产生许可费用，需要将其纳入效益与成本的权衡之中。某些产品，如大多数开源软件，并没有这项成本，可以在新版本一经推出时就立即更新。

更新软件的另一个真正重大的因素是更新所需的人力成本——这与全新安装不同，在全新安装中，安装的工作量在新旧软件之间实际上是打平的。事实上，新软件往往比旧软件更容易安装，这只是得益于各种改进和进步。将单一版本的软件维持十年，意味着在那段时间里没有把资源投入到升级流程中。而在那段时间里每年升级，则意味着资源被动用了十次来实施一次次单独的升级。这使得更新在成本上更难以得到合理化论证。但除了更新流程本身的工作量之外，还有对最终用户持续培训的成本——这些用户将被迫通过不断的升级，更频繁地经历更多的变化。

这可能会让更新软件听起来像是一件负面的事，但事实并非如此。它只不过是一道两边都需要加以权衡的等式。定期更新往往意味着小幅的、渐进式的变化，而非大跨度的跃进，从而让最终用户能够更自然地适应。定期更新意味着更新流程往往更容易、更可预测。定期更新意味着技术债务始终得到管理，并且较新版本所带来的益处——无论是功能、效率还是安全改进——能更早地获得，从而可以在更长的时期内加以利用。

不过，从上述两种情形中汲取我们所学到的东西，这里还有另一个重要的启示。一旦做出了执行更新的决定，问题往往就变成了“我们要更新到哪个版本？”然而实际上，每一次超出标准打补丁流程的更新，都真正类似于一次微缩版的“新软件”采购决策，而我们在做全新安装时“始终”安装可用的最新版本背后的逻辑，在这里同样适用。因此，在执行更新时，我们几乎总是应当尽可能地更新到最新——但愿能更新到当前版本。

再次套用微软的例子，我们可以设想一个如今部署着 Windows XP 的组织。该企业决定投入一个更新周期，转向较新的版本，而不仅仅是继续打补丁。微软仍在积极支持的 Windows 桌面平台有好几个版本，包括 Windows Vista、Windows 7、Windows 8 和 Windows 8.1。更新到其中较不新近的版本，会导致距离该版本生命周期终结的时间更短，从而增加组织的风险；使用较旧的版本意味着继续投资于本已陈旧的技术，这意味着技术债务的增加，以及对那些一旦可用便可能颇有裨益的新功能的接触更少。在这个特定例子中，较新的版本还被认为更安全，并且所需的硬件资源更少。

每家企业都需要为自己找到现有软件更新周期的恰当平衡点。每家企业、每个软件包都各不相同。像 Microsoft Windows、Microsoft Office 或 Oracle Database 这样的企业级软件非常好地遵循这些模型。小型软件项目以及那些接近定制范畴的项目，可能有着更为动态和难以预测的发布周期，但通常仍会遵循其中大部分规则。不妨试着对软件开发流程抱以同理心，以理解你和你的软件供应商如何才能最好地携手合作，为你的组织带来最大的价值，并将其与你减少技术债务的需求结合起来，从而以最有利于你组织的方式善用你的软件投资。

不过这些经验法则相对简单：

在进行全新部署或更新时，争取使用软件中最新的合理版本。利用任何部署机会尽可能地消除技术债务。

当软件已经存在时，则要权衡诸如人力投入、许可成本、环境一致性和兼容性测试等因素，对照功能、性能和技术债务方面的收益加以衡量。