《DevOps 精要:业务视角》- 读书笔记（五）

第5章 应用实践

5.1 DevOps适用性及限制

也许，前面几章给读者的感觉像是神话，如果参与在内的话就太棒了！自组织团队的员工会被完全激发起来；业务和IT将一同探索如何取悦于挚爱的客户（以及他们的钱）；IT系统将变得牢固并具有反脆弱性；变更与发布将稳定流动，与此同时，技术债务也降低了。此前选择的方式，是通过对“传统”实践与“DevOps实践”加以比较，难免会留下强调长处而掩饰缺点的感觉。

同时，我也尝试尽可能公正地考虑DevOps的方方面面。正如本书最开始所陈述的，在现代的IT管理者手里，DevOps是众多工具的一种，相对较新而已。同其他的管理工具一样，DevOps并非包治百病，它是特定问题时的良药。并且，像所有的工具一样，DevOps也有局限。让我们清醒地从实用的角度来看一下。

因为已经到了本书的最后一章，不同IT部门此刻很有可能与DevOps所描述的截然不同。需要改变的范围会相当大，只有清晰了解两个方面（收益以及可行性），才值得启动大规模的转型。让我们逐一看一下。

需要说明的是，原则上并非所有组织都应该采纳DevOps。首先，让我们排除一些特殊场景：商业软件开发、系统集成、IT外包以及面向项目的组织。这些场景的问题在于它们只参与价值流有限的一部分，参见图5.1。针对这些情况，DevOps应该如何适应，这值得另外再写一本书。

图5.1 特殊情况不做考虑
我们关注更为传统的方式：存在内部或外部的IT部门，全权负责所有IT相关的事务。实际上，这类组织的业务领域以及所有权的形式并不重要，可以是银行、保险公司、传统的组织、非盈利组织、产品或服务业务等。关键是，这个组织采用信息技术并且目标是通过IT获得最大的产出。

当以下条件满足时，组织会对DevOps感兴趣。

• 公司的核心业务高度依赖于信息科技（依赖程度很容易通过非直接的标准进行评估：例如IT成本在整个组织预算中的占比，或IT管理者在公司高层组织架构中所占的坐席）。
• 组织采用的信息技术，发生变化的几率很高。
• 核心业务要求快速响应变化，以验证新的商业想法或是猜想，参见“缩短市场响应时间”小节。
• 核心业务存在与IT相关的风险，这对业务负责人或是高层管理者是不可接受的。
• 其他提升效率的尝试与验证方法都不奏效。

举例说明前面所列举的风险：每周有一百万新客户接入苹果支付系统，其中的部分交易支付来自与苹果的产品和服务无关的完全不同的服务，这些支付最终由苹果而不是银行完成。通过比较激活的Visa卡总数（大约25亿）以及激活的iPhone设备（7亿），就可以大致衡量出银行业因此受到的损失。类似的故事也发生在安卓支付系统。无论是苹果公司还是谷歌公司，都不具备银行许可证，它们无需遵循金融组织严格的法规要求，它们不需要承担维护分行以及ATM网络的费用。它们拥有强大的金融资源、先进的技术以及忠诚的客户基础，世界上任何的金融机构都无法获得这些。IT公司的行动速度非同寻常，这直接威胁到笨重的传统银行。数十年以来，传统银行习惯于通过常规的方法获得收入：交易佣金、存款和贷款等。

如果一个组织满足上述条件，采用这种或那种形式的DevOps就有它的潜在价值。

我们应该分别描述组织应用DevOps来大幅减少技术债务积累或消除IT基础设施的脆弱性这两种情况。应该牢记的是，对于复杂的情况，采用DevOps不会直接带来利益，更不能期望快速成功；与此相反，组织和技术的变化可能会导致混乱和失控。应该小心解决长期存在的问题，深思熟虑并且审时度势，而不是期望DevOps可以魔术般地治愈所有疾病。

描述过收益，让我们来到第二个方面“可行性”。DevOps适用于所有的组织吗？很多专家倾向于乐观回答。HP LaserJet硬件部门的案例就是一个证明，这个部门拥有打印机、扫描仪以及多功能设备的硬件，有超过400名开发者，员工分布在三个国家。在转型之初，市场部门的需求只有一小部分被接受，每六个月发布一次，员工只有5%的时间工作在新功能开发上。历经四年，部门创造了诸如每天开发集成10～15次、员工的生产率提升40%、测试的时间从3周减少到1天这样的奇迹。

上述案例，事实上不属于前面所述的“业务拥有自己的IT部门”。它可以作为教学故事，对于鉴别DevOps适用性的限制没有太大帮助。但是很清楚的是，就整体而言主要的挑战是有限且明确的。

DevOps不是特别适合自己没有软件开发团队的组织，例如当所有核心软件都来自现成的商业软件（COTS）并通过用户或者管理界面进行配置。如果公司没有自己的软件开发，就没有价值流的源头，不可能控制源代码（因为无法接触到源代码，而且没有能力去理解它），强烈依赖于软件的供应商和提供商。这种依赖的负面效应是众所周知的：无论组织多大多有名，你通常只是供应商众多客户中的一个，并且无论供应商的客户管理者给了多少承诺，你将与其他客户一样，停留在同样的队列中等待开发者的关注。重要的并不是你在队列中的（优先级）数字，重要的是队列的存在。另一个依赖于外部软件的负面结果，是由于软件供应商所采纳的瀑布模式以及漫长的发布周期导致的极度延缓。有时新版本软件中的严重问题超过9个月都没有被修复，单一的故障超过半年没有被诊断出来，客户面临无望的抉择：要么继续在看起来缺陷更少、拥有长期支持的老版本上再运行两到三年，要么持续更新到新的版本，某些旧的缺陷会被修复，然而又引入了新的缺陷。我们会在5.2节中详细讨论如何在这种情况工作。

另一个DevOps实施的挑战出现在组织使用自己的软件，而开发者并非自有员工：开发的活动是采购其他公司的或开发者在某种合同下工作（自由职业、外包或诸如此类）。在这种情况下，由于完全不同的激励模式，很难完全把这些人包含在价值流中。全职员工通常更利于实现核心业务价值、助力公司成功、支持个人职业成长，最终交付高质量的产品。外部开发者倾向于基于合同范围圈定自己的职责范围，仅聚焦于实现工作订单，有时会夸大工作负荷与时长。我们同样需要考虑员工的频繁变动，员工只是部分工作在指定团队上，典型的情况是，对范围和投入的承诺是由其他人（例如，客户侧负责业务开发的主管以及外包侧的客户主管）所制定的，而真正的开发工作则由另外的人（外部开发者，以及客户IT团队的其余人员）完成。这种情况下，4.2节提出的许多原则，会变得不再可能或被扭曲。我们应该注意，五年前流行将核心流程以外的几乎所有工作都进行外包，而现在，企业回归自主软件开发和IT运维已成为趋势。在各类产业中，需要通过基于软件的信息科技获取竞争优势时，不这么做会被认为是非常愚蠢的。

“简而言之，软件正在吞噬世界。
越来越多的主流商业和产业，都运行在以软件为基础的在线服务之上，从电影业到农业到国防。赢家大多来自硅谷风格的科技创业公司，侵入并颠覆原有产业结构。在随后的10年，我预期将有更多的产业被软件颠覆，出现越来越多新型的硅谷公司瓦解产业的案例。”
——马克·安德森，2011年

实现DevOps的下一个约束，是长期存在的现有流程，其背后是决策层级、组织结构、内部管控文档、官僚主义以及企业文化等。一些大型的组织对自身改变能力的局限性有很清醒的认识，转型到DevOps，要求不只是在IT部门实施，而且也需要对业务部门进行大规模的组织调整。回顾4.1.7章节列出的传统大型企业文化对比创业公司文化的差异，就能理解转型所要求的规模和程度。非常有必要强调，对于大部分组织而言，除了在组织某些部门产生短期可证实的成功以外，对现有工作实践进行彻底的变化基本上是不可能的。

最后，下一个重大的阻力来自于独立的、紧耦合的IT架构。引入小团队需要有能力给他们分配不同的职责领域。有问题的IT系统依然作为单一实体被几十或几百名员工进行开发和维护时，很难将工作拆分到独立的团队以异步并行工作。针对这一问题，5.3节会给出一些思考。

对前面这些复杂性，很多人都会看到，还有更多因素会限制DevOps的使用。我们应该注意，这些因素往往被错误当成无法启用DevOps实施的原因。更正确的态度是将它们看成可以消除的限制或者需要寻找解决方案的任务。

• 如前所述对创建DevOps团队的准备不足。例如，一些组织鼓励他们的员工远程工作，而不是在特定时间内必须在办公室内工作。这种情况经常存在于地理上异地分布的公司，IT部门的员工不在同一个地点。很多组织的组织架构相当僵硬，无法满足创建跨职能团队的要求。所有这些并不是阻止DevOps之路的因素，它们只需要适当变化和更正。虽然不易，但并非不可能。
• 对信息安全或合规的“特殊”要求。“特殊”一词特意用了引号，对相关公司针对安全与合规进行仔细的调研会发现，事实上这个组织与同行业中其他的组织没什么本质区别。是的，合规的或是信息安全的要求应该考虑，但这更应该是一个方法和技术的问题，而非一律采取保守选项。
• 极少采用虚拟化和云计算，或干脆摒弃这些技术以及采用过时的编程语言。这一点在本书的第1章就有提及，也展示了采纳云计算的必要性。如1.1节所述，正是因为它们，DevOps才变得可能。企业限制虚拟化的使用，会对实施DevOps产生相当的难度。总之，选择具体的技术是每个公司自己的选择，如果一个新的管理工具要求采纳新的信息科技，相关的技术变化就应该纳入计划并付诸实施。

图5.2总结了所有主要的DevOps驱动力以及所有制约DevOps被采纳的因素。

图5.2 对DevOps的兴趣点以及已知的限制

显然，有约束因素并不会让DevOps不可能引入公司。在困难的条件下，依然可以从DevOps中获得收益，并且诸多约束都可以用不同的方式克服。显而易见的是，这些约束条件会增加采纳DevOps的复杂性。当遇到约束时，很难事先了解它会造成多么难以对付的障碍。无论如何，HP硬件开发的例子以及现有众多DevOps主机架构实施案例，表明这种约束可能比通常想到的还要多，但依然有可能克服。

5.2 COTS

为尽力在IT上进行节约、降低系统的复杂性并快速获得回报，很多组织遵循“最小化自主软件开发并且尽可能多的采购现成软件”的原则。现成可用软件甚至拥有一个名字：COTS（现成商业软件）。这种方式非常普遍，并且也有足够好的理由。但是，正如前面所示，COTS的使用会成为采纳DevOps的严重阻碍。当组织面对DevOps与COTS的“兼容性”问题，我们有以下一系列建议。

首先，不要在战略地位的业务线上使用COTS。在竞争力取决于信息和信息科技的时代，有必要最大化的保有灵活度以及控制力，这通常无法从COTS获得。因而，任意一个严肃的专家都会给你的第一条建议是，在你重要的业务领域中消除COTS，迁移到自主软件开发。

如果暂时采用COTS是不可避免的，则针对相关的应用及其管理策略牢记如下分级选择。

• 开放式应用，例如Salesforce，让你可以采用标准的功能，适配到业务流程中。
• 封闭式应用，例如Adobe产品系列，无法进行任何适配。
• 平台式应用，例如Microsoft Dynamics，是构建自有IT系统的基础。

对于COTS，在DevOps实践范围内，有必要遵循与自主软件相同的原则。避免用户或管理界面的安装和配置界面；事实上，你必须学习COTS安装过程的细节，理解安装器做了什么、创建和修改了什么文件、修改了什么数据库，等等。其次，创建自己的脚本，仿照原始安装器的工作。你可能需要在不同的在用或计划要用的环境下，开发一系列的脚本来安装和配置系统：测试环境、验收环境或生产环境。所有的脚本都应该保存在版本控制系统中。如果有必要，应用类库、二进制以及其他的支持文件，也可以保存在版本控制系统或是在制品库系统中。核心原则是减少手工和复杂的安装与配置流程，取而代之以可知并且可控的脚本进行自动化部署。

同样，也建议重新考虑在运维侧配置软件的方式。当应用被配置和升级时，自动化控制系统可以识别出几乎从来没有改变的区域，以及几乎每次都会修改的配置项和文件，这意味着后者应该在版本控制系统中严格管控。终极目标是在版本控制之下，在任意时刻都保持所有应用设置的完整拷贝。

至少可以考虑以下方案：

• 1．通过标准化的COTS配置工具，例如IDE（集成开发环境），将配置与变更通过钩子结合。一旦管理员或开发者修改了应用中的任何信息，钩子将检测到发生的变更，将其转化为适合版本控制系统的格式并发送最终文件；在一些情况下，需要检查变更之间的冲突。随后，利用内建的配置导入机制，可能不需要使用IDE就能变更或重建系统设置。这种配置管控是最便宜的，但并非所有IT系统都支持。
• 2．应用的设置被导出为适合版本控制系统的格式。比较理想的是，这种导出是自动化的，由COTS中的变更触发。如果没有触发器，这一导出被匹配并排期到系统中的变更流（例如每天晚上）。通常情况下，版本控制系统能够比较新进的文件与已存储的文件，如果没有变化就无需跟踪，信息也不会重复。这种方式相较于第一种更昂贵，但更为普遍。
• 3．最昂贵的方法是针对COTS不支持配置导出但具备一定导入能力的情况。构建自己的COTS配置应用。所有的配置都通过此应用完成；配置文件所需的格式保存在版本控制系统中，并且以COTS的格式导入到目标IT系统。

事实上，这是为一个没有源代码的应用重建一个开发环境。然而，工作到此还没结束，有必要开发能够自动化执行的测试来检查引入的变更，包括整个系统的操作、与其他系统的集成以及互动。自动化的测试是部署流水线的一部分，也应该为COTS工作。

COTS的最佳使用场景，是定期、快速并且自动化在生产环境中从无到有完整重建应用，它应该基于配置管理系统中的数据，并且不需要系统停机，做到对用户无感。这种级别的控制，保证系统发生变更时不会造成意外，并且不成功的变更会自动回滚到早先的版本。

5.3 架构演进

在5.1节中，我们强调了大多数成立于2010年之前的组织所面临的挑战以及单体架构，系统组件之间紧密的关联。现代的应用由一组相互作用的对象组成，结构之间的彼此连接建立在业务逻辑、数据、IT基础设施以及其他因素之上。如图5.3所示，一旦系统被设计并开发成单一实体，在横向（对象，以及之间的通信）及纵向（应用、服务器、DBMS、数据交换的协议以及接口）上均是如此，这种单体架构会引发如下一系列的问题。

图5.3 一个非常简单的单体架构IT系统示例（没有显示所有的关联）

• 即使是系统某一部分的小小变化，也会引起对其他部分的负面的、经常无法预料的影响。
• 众多开发人员并行工作在系统功能上，各自都需要资源来进行协同。
• 只有少数员工了解IT系统的整体概况以及所有的依赖与约束；这种员工迅速变得极有价值、无可替代并且严重超负。
• IT系统的任何文档很快就变得过时。
• IT系统的开发和运维以自然的方式切割：运维以及支持的员工无法介入复杂的系统架构细节，因而即使是最简单的问题，他们也只能上传给开发人员。
• 很难识别小的自主团队能负责的领域，因而敏捷开发最主要的好处也被抹杀，无法达到期望。
• 现有的架构无法完全满足当前的需要，创建之后就很快过时了：不得不在没有足够信息、缺乏开发和使用系统经验时做出关键的架构决策。
• 大量的强关联导致改变和发展架构变得异常困难。

对于这些挑战，传统的应对方案是引入正式的管理流程，增加管控的数量，这会减缓变更的速度。例如，为修正一个缺陷做的一行代码修改，对开发人员而言只需要几分钟，而发布到生产环境却需要等待几个月。系统必须作为整体进行测试，将多个开发人员所做的修改进行集成。作为应对，IT部门又引入了额外的人为障碍，即发布日历。事实上，如果变更的测试很复杂，并且需要大量的资源，应该尽可能少进行。不幸的是，这种非常严格的方式对防止缺陷进入生产环境毫无帮助。

这些单体架构的问题由来已久，自运维与开发第一个大型信息系统之时就存在了。工程师一直在寻求更好的方法：模块化的架构、单核架构、事件驱动的架构（采用代理或中介）、面向服务的架构（SOA）等，以及上述方式的混合。但是，正如《构建演进式架构》的作者所述，它们都有明显的问题，有时甚至存在更高的复杂性，这让它们很难适用于DevOps实施。

近年来备受关注的一个激进并且有希望的方案是著名的微服务架构。应用程序被设计为一系列基于领域的元素：每一个“负责”IT系统特定的一部分核心部分，包括所有必要的技术以及基础设施组件，例如数据库以及依赖的类库。这些服务之间并非“链接”在一起，与此相反，它们完全通过指定的程序接口或消息队列进行通信。任何服务都不应该知道其他服务的内部实现或是对其有任何的依赖。遵循“无共享”的原则。

按照前面的建议，有可能达成一种状态：修改任意的服务都可以独立于其他的服务进行，并由一个专门的团队进行。每一个服务彼此独立工作，同时又与IT系统作为一个整体工作，这让遵循DevOps的基本原则成为可能，如价值流、部署流水线、让一切都在版本控制系统中、自动化配置管理以及完成的定义。发布排期以及几个月的漫长（上线）等待都不复存在，变更管理流程也可以极大地简化。

另一个巨大的机会点是转化为演进式的架构，持续遵循新的业务需求以及浮现的新兴技术。例如，负责领域A的团队，可以为功能准备一个新的版本，而须禁用当前的版本。服务B，用了老版本的服务A，继续保持原状而不会有质量损失。与此同时，服务C，为新版本的服务A而设计，可以访问到新的功能。渐渐的，整个应用都将升级，与领域A已改进的新版本进行工作，早先的老版本可以被禁用。这不需要通过一个大型的隔夜迁移来等待所有的组件都就位。通过与上述同样的方式，可以独立于其他团队和领域对单个服务进行重构，减少累积的技术债务。

当然，微服务架构引发了很多挑战。需要认真研究领域如何分布，很难做到一劳永逸，需要持续审视并更新系统的服务结构。有必要遵循清晰的规则来定义并记录接口与版本。发生重大迁移时保持数据引用一致性：从数据库系统层面到领域层面。有必要监控每一个服务，不止是用于运维控制，也用于追踪使用情况。

容器化的引入对近些年微服务架构的扩展产生了巨大的贡献。它使得无须我们分配一个专有的虚拟机来为服务组织一个独立的工作空间；并且所有容器的创建和管理的操作都是基于软件的，包括按需动态增加容量以及当需求下降时释放相应的资源。

然而，对大多数组织而言，迁移到微服务绝非易事。一些公司拨款并启动了大型的项目，旨在为新的架构“重写”现有的信息系统。这类项目经年累月而且通常都不会取得成功，有两个原因：首先，迁移的规模是如此之巨大，以至于即使其他的工作都冻结，也不可能在合理的时间内完成工作；其次，随着新开发的进行，系统持续为响应业务需求进行演化，这给功能的同步带来了更多的困难。

相较于启动一个大型的成功几率极小的项目（并且绝对不会快速成功），专家建议将架构的升级作为一个持续的活动来进行管理，并且将其当作日常开发工作的一部分。处理下一个业务需求时，可以将现有系统的一部分分配到一个分离的领域，同时保证相关必要环节的支持：一个与主体系统交互的编程接口、一系列的测试、一个部署流水线。如图5.5所示，以业务需求作为变更的主要驱动力，单体架构的独立部分将逐渐一步一步地用微服务架构实现。

图5.5 将现有应用系统逐渐迁移为微服务架构

5.4 DevOps与ITSM

在过去二十多年中，许多公司在ITIL上投入了数百万英镑、美元和欧元。这些支出通常都有其正当的理由：组织寻求管理信息科技相关问题的方案，并且努力改进IT部门的效率。在企业IT管理领域，类似ITIL和COBIT的知识体系通常被认为是行业标准，尽管这里用“标准”一词并不完全准确。很多公司希望从ITIL中获益，很多公司其实也一定程度地获得了投资回报。

误区：DevOps与ITIL不兼容
DevOps实践可以与ITIL流程相互兼容。但为支持DevOps实践所倡导的更短的前置时间与更高的部署频率，ITIL流程中的许多方面可以完全通过自动化实现，这就解决了许多与配置和发布管理流程相关的问题。由于DevOps在服务事件发生时要求快速检测和恢复，ITIL在服务设计、事件和问题管理方面的规程仍然一如既往地重要。
-------选自《DevOps实践指南》

然而，第3章“原则”以及第4章“关键实践”中的很多主张以及案例，对于传统的IT部门而言并不容易接受，新的实践与大多数的大型企业当前采用的相去甚远。这将是一个挑战么？

DevOps专家相信，根本性的困难是不存在的。本节开头引自《DevOps实践指南》的内容是一个典型的示例。一些IT服务管理专家甚至更为这些新的愿景所鼓舞，急切地去掌握新的主张。2017年，在很多国家的ITSM年度会议上，我们看到很多演讲内容甚至是整个专场都被DevOps以及数字化转型这样的主题所占据。看起来几乎所有的专家都一致认为基于ITIL的流程可以在一定程度上可以与DevOps适配或吻合，与此同时，组织在ITIL方面的投资回报可以得到保障。然而，一切并没有那么简单。

如图5.6所示，在DevOps与ITSM之间存在着根本对立的矛盾，这一观点需要澄清。IT服务管理（以及基于流程的活动管理）的两个关键原则之一，是由IT以服务的方式来交付业务价值。服务模式中必不可少的一环是客户与供应商之间的关系：前者决定了需要什么以及为什么需要，后者将风险、成本与成果相关联。这些关系要求记录在服务级别协议（SLA）中，包含各方职责。如果客户对交付的服务质量不满意，可以尝试影响服务提供商并基于已签署的协议提出申诉，甚至是更换供应商。同样，如果供应商发现客户制造的麻烦大于收益，他们可以终止协议并将注意力放在其他的客户身上。当然，对客户内部的供应商而言并非这么简单，但基本原则一样。

图5.6 ITSM与DevOps的本质

与此同时，DevOps的主张在很大程度上基于单一团队的概念，包括IT和业务在内。因此，各种角色一起工作，关注长期的成功，而不是短期的胜利，当然更不会过多关注书面上的协议。团队中不同角色的成员携手共进，途中道路也变得愈加清晰可见。团队对失败早已达成一致，一旦失败，他们不会相互问责，而是从自身的错误去学习。在极致情况下，IT与业务之间的边界完全消失，这与前面称为“我们与他们”的工作方式截然不同。

对于如何解决ITSM和DevOps这一主要矛盾，答案尚未明朗，相对而言，即便是小的方面也存在分歧。

• 如前所述，DevOps的实践在很多方面与传统IT部门的惯常实践不同，并且很多IT主管还未准备好接受新的理念。
• DevOps的资金以完全不同的方式设置：资金是分配给产品，而不是项目。
• 长期以来，企业IT部门的原则是以成本优化为基本原则，DevOps则建议切换到以提高速度为原则。
• ITIL定义的变更管理关注于降低风险，通过相当缓慢并且严格的正式流程实现，包含诸多的控制、通知、协议以及审批。然而，DevOps所提倡的变更，则是在伴随自动化测试以及日志记录的情况下，越快越好。
• 由于大量通过繁重的手工操作来收集和更新配置信息，ITIL中所描述的配置管理以及配置管理数据库实践中很难实现。与此同时，DevOps中的配置管理在很大程度上是自动化的并且是强制的，以至于“配置”这一术语在DevOps实践中有了一个新的含义。
• 与ITIL相比，在DevOps实践中“发布”的概念发生了变化，从“发布是一个复杂的、有准备的、测试过的、实时执行的变更”到“新功能对客户可用”。
• 事件管理实践，包括支持业务线的分离以及问题的升级，被DevOps中的另一个原则所取代：“谁构建，谁来运行（You build it, you run it）。”
• 问题管理（处理事故根因）在DevOps实践中显得毫无意义：在ITSM中问题管理极具挑战性，而在DevOps实践中却并非必要。
• ITIL中的容量管理是基于容量计划的极大延伸，应该涵盖对IT资源的所有需求，并且通常与公司每年的预算周期绑定。在DevOps实践中，容量必须在需要的那一刻就绪，不能因为找供应商、签合同、等待交付等事宜而被延误。

事实证明，无论从哪一方面来讲，ITIL的主张都不同于DevOps的实践。也许这些矛盾并非不可调和，在一些场景中只需对现有ITSM流程进行些许调整即可。然而在另外一些场景下，需要对ITIL流程进行大刀阔斧的改革。

5.5 货物崇拜

大量的团队寻求掌握一种新的管理实践，却没有把足够的精力放在“管理”上，而只是关注于“实践”。迭代开发现在变得流行了？好吧，我们将安排两周一个迭代。周围的每个人都在进行每天的Scrum站立会议？太棒了，我们现在也做到了。他们说Kanban很有道理？没问题，我们也搞一个Kanban。DevOps流水线无法脱离自动化？没问题，我们会要求这些家伙选择并实施一些系统。

这种盲目注重形式而非目标的意义及原则的行为，被称为“货物崇拜”。这一概念是在1945年提出的，在当时与信息科技领域毫无关联。在人类学研究中，科学家们研究巴布亚新几内亚当地的风俗与习惯，发现并描述了一种现象：当地的土著居民对物质和精神收益的获取，更依赖于神灵和上帝的意愿。为得到这类收益，通常会在一位萨满或是长辈的指导下进行一系列动作和仪式。货物崇拜的范例在更早就有发现，最早的记录是在1885年斐济群岛。更偶然的发现证实，这种崇拜在大洋洲的一些地方保留至今。

货物崇拜最引人注目的著名事例是二战期间以及随后发生在美拉尼西亚群岛的故事。这些岛屿在当时对作战行动极具战略意义。一开始，日本空军登陆这些岛屿，带来前所未有的货物、衣服、药品、食物和武器等。随后，这些岛屿被反法西斯联盟控制，基于种种原因，当地民众坚定认为这些当地绝对无法产生的商品出现与白人从天而降关联起来。战后不久，这些岛屿失去了它们的重要性，军事基地被削减，外国人离开了领土。为了寻找一种方法来恢复货物的流动，原住民将这些宝藏曾经从天空而降的过程逐一进行最精确的复制。举例来说，他们开始用美军的颜色来装饰自己，在阅兵场上进行军事游行，生产竹制的来复枪，复制最近发生过的所有其他外在特征。例如，他们修建了建筑物，复制了机场的指挥所，包括内部设备和天线，但用的都是竹子（图5.7）。他们清除了丛林中的其他地面，以创造出更多的“机场”。他们安装了相当精致的飞机复制品。当然，所有这些行为都没有导致外国人返回或是收到新的货物。

图5.7 虚拟化的现代竹制电脑

任何受过教育的人都明白，这个故事不可能以其他的方式结束，仅仅通过盲目复制一些形式上的东西以期获得同样的产品，是异想天开且不现实的。然而，故事中土著人所犯下的这种显而易见的错误，在每天的商业环境中却经常被忽视。通过不经思考照抄敏捷软件开发仪式来期望加快产品上市的例子，在众多企业实践中比比皆是。

值得注意的是，货物崇拜的现象同样也经常出现在企业IT服务管理以及DevOps实践中。只是目前还没有足够的信息和调研来统计这一现象。

5.6 从当前所处位置启航，迭代推进

“针对IT管理者关于如何进行DevOps，你会给出什么建议？”
“立即开始！今天就是开始的最好日子。”
——对话加里·格鲁佛（Gary Gruver），2017

本书前面的章节，旨在为读者构建一个变革前行的整体感觉：采用DevOps意味着新的管理原则和全新的信息科技工作方式。很多人知道，从他们自身经验来说，大的转型绝非易事。管理IT基础设施已经极具挑战，同时业务主管还在不断提出上市时间这个令人棘手的问题，还有来自各方源源不断的压力，主管会竭尽所能地待在自己的舒适区里。因为在这个舒适区里，事情更为清晰并且可预测，即便不如意愿中那么美好。大规模的变更不应该困扰并阻止你，这不是必须在输和赢之间做出选择。

如果发现自己处在5.1节所描述的情况，就真的没有借口再继续等待。DevOps运动正处在它的开始阶段。当然，在企业信息科技领域依然存在很多没有答案的问题。那么是否值得等待别人发现这些答案呢？绝对不是！正如本书一开始就讲到的，先行者也许做的不是最好的，但他们积累了经验，会让他们比后进者更迅速地向前发展。当前，在DevOps领域有太多的出版物、活动以及布道者，不可能存在信息的真空。与此相反，从嘈杂的噪音中过滤信息变得越来越重要。市面上已公开的并不一定与事实完全相符。市场的热度和盲目炒作掩藏了真正的挫折和失败，并且，当今每个人都有可能突然就变成一个“专家”。因此，你需要在具体的主题域建立自己的观点，提出自己的问题，去寻找答案，这比以往任何时候都更加重要。

如IT服务管理一样，常见的错误是去尝试“实施”DevOps。你当然无法实施DevOps，这一用词就像“实施一个健康饮食”或“实施一个锤子”一样没有意义。DevOps可以采纳，像其他任意的管理工具一样，用来解决组织里具体的问题。DevOps不是一个软件产品，后者可以安装和启动；DevOps也不是一个工程师，后者可以雇佣来给IT带来新的订单。在很多方面，DevOps需要文化与组织的变化，而这些变化并非只局限于IT部门。

如同IT部门一样，业务部门在同样的关键领域也同样需要变化：组织、文化以及工具。如果相信已经遵从新工作原则的IT部门仍能与遵循传统工作方式的业务部门直接展开工作，就未免太天真了。相反，DevOps并不只是意味着开发与运维之间的隔阂需要消失，IT与业务之间也如此。如果这一目标状态太过遥远，至少两者需要有新的交互方式以及新的IT投资原则。缺乏组织决策层强有力的、毫无条件的支持，这类变化无法实现。“我全力支持你，但时间、金钱、努力以及我的个人参与除外”，来自管理层的这种承诺毫无意义。

DevOps的应用在任何情况下都不应该以项目的方式进行。项目的方式意味着在有限的时间以及预算内获得特定的结果，DevOps意味着一场没有终点的马拉松比赛，从今天直至永远。因此，没有比“DevOps实施项目”更没有意义的词语组合了。

有必要持续对员工进行培养。不只是培训，而是持续的培养。此外，有必要为分享知识和经验教训创建一个舒适的环境。这些机制应该持续验证。已经在公司建立并且被专家主动采用的机制，应该进一步发扬光大。那些不奏效的，应该剔除，被新的机制取而代之。应该避免诸如对部署流水线进行技术研究的事情，这很容易只见树木不见森林；仅仅在组织一部分构建的流水线，不会带来预期的收益。我们应该关注在研究DevOps原则和理念，创建一个新的运维和IT管理文化。

与其他的组织变革一样，人们会做出不同的反应：有些人会拥抱变化并做出额外的努力，有些人会保持中立或是怀疑，而其他人会跳起来反对，或是蓄意破坏变革推进。在这方面，DevOps与其他组织变革没有区别，而当前的管理者已经积累了充足的技巧。

对于有遗留IT基础设施的组织，一种通用的方式是鉴别与其他系统松耦合连接的系统（这些通常是现代的“数字化”应用）。采用这些系统作为试点：它们通常比较容易应用基本的DevOps元素，包括价值流、部署流水线、版本控制系统和自动化配置管理等。这一经验可以随后应用于其他系统，但不要指望这是容易的事。不幸的是，所有IT系统都有其自身的独特性，IT团队以及业务部门也是如此。尽管如此，从简单的情况开始，你可以更有信心地继续前行。

很容易对自己或其他人解释说为什么不应该进行新的尝试或是为什么新的实践行不通，也无法落地。这是一种众所周知的认知陷阱，只能通过行动来规避。

凯尔西·海托尔（Kelsey Hightower），Google Cloud Platform高级开发者&布道师，非常直截了当地说：“在那个领域没啥好说的。（……）对我而言，那是支柱。CI/CD, DevOps，我们只能去说，去聆听，去搞明白，或与公司之外的另一个团队一起搞明白。”

5.7 以价值流为核心

设想在一个组织中，定义出一个小范围的并且易于控制的试点区域；为实现更多的收益，有计划地改变这个区域内IT运营以及管理的方式；在这个区域里更快发布新产品，更快验证业务想法，引入反脆弱性越接近于控制技术债务。到底应该首先做什么呢？

对于那些已经踏上征程的组织，最好建议从团队开始。4.2节描述的团队，成功的几率就越大。

然后，应该映射“现状”的价值流。这一练习有助于建立一个对当前流程统一的理解和认知，然后识别瓶颈点并寻找浪费。即使在继续下一步之前，你也可以尝试改变流程以减少浪费。还有可能创建一个假设清单，包含有待验证的可能造成最大浪费的领域、延迟以及活动。这份清单随后会派上用场，作为未来改进的基础。

现在是时候开始为价值流构建自动化的部署流水线了。流水线没有必要在第一天就规划为全自动的。一个基本的流水线只要至少包含编译以及初始的测试，就足以作为起点。使用流水线的第一手经验，将引导演进的方向。需要牢记在心的是，资源有限，不应该立即为自己设定一个标准很高的目标，然后竭力实现某些无法触及的理想。

度量价值流中关键指标的重要性毋庸置疑。对于价值流的每一个阶段，都可以设定很多指标，但最大化度量指标的数量绝非目的。首先，可以管理最重要的三个指标：前置时间、处理时间以及正确率。持续监控这些关键指标，将揭示出能够产生最大提升效应的领域。

当了解并发现需要改进的领域，就有可能演化出价值流的理想版本，并准备一份有待改进的清单。工作改进不应该被视为是一次性的事件，而是永久可持续的工作。应该作为日常的实践，定期、主动、有方法地寻找并消除浪费。这是团队中每个人的日常任务。

为移除限制并最小化浪费，可以从DevOps、精益产品以及敏捷软件开发的武器库中，选取最适合的工具。因此，人们的行为不是由宣称的实践来决定的，而是通过对价值流的分析，设定目标并选取最适合的工具与实践。

然后是循环的收尾：当实施计划的变更后，有必要理解预期的改进是否已经实现、关键指标的值是什么、下一个瓶颈在哪里以及能够采取什么措施来消除瓶颈。正如已经多次提及的，最主要的是踏上征程并开始沿着这条没有终点的征程持续前行。

以某些团队为例，在早先阶段就确定价值流的最终目标状态，然后系统化地逐步朝着这个状态前进。这种路径看起来会很复杂，也很冒险，因为早期阶段犯错的可能性极大。此外，也没有必要在一开始就定义最终的状态，它的定义可以在不断尝试中进行摸索。

一旦在试点区域建立价值流，下一个合乎逻辑的步骤是将经验与实践扩展到其他领域。这种方式是可行的，但当多个DevOps团队分别进行工作，最终需要整合为一个更大的组织形式或几十个人一起参与到组织级DevOps实践中时，最有趣也是最复杂的任务开始了。大型组织中规模化DevOps是一个独立的并且意义重大的知识领域，不在本书的讨论范围内。

5.8 小结

公正审视，需要客观地呈现其实质、特性、优势及限制。我最不想看到的情况是，读者把DevOps曲解为解决现代IT管理所面临的所有问题的最佳手段。本章关于DevOps适用性的讨论很长，关于COTS、单体架构以及服务方法等令人不适的问题，答案依然并不明显。

然而有一点相当明确：这取决于你，是自己去寻求答案，还是等着别人来告诉你他们的伟大成就。“他们的”在这里是关键词。为取得个人成就，必须立即采取行动，而不是等待和观望。