选择价值流作为切入点时的四个模型

今天我们将从多个方面评估入选的价值流，包括是选择绿地项目还是棕地项目，以及是选择交互型系统还是记录型系统。我们还将权衡转型的风险和收益，并评估相关团队对转型的消极程度。

1. 绿地项目与棕地项目

软件服务或产品常被分为绿地项目和棕地项目，这两个术语最初用于描述城市规划和建设项目。绿地项目是指在未开发的土地上建设的项目，而棕地项目则是指在以前用于工业生产的土地上建设的项目，这样的土地可能受到有毒物质或污染物的侵蚀。在城市的发展过程中，许多因素使得绿地项目比棕地项目更容易实施——前者既不需要拆除建筑，也不需要清除有毒物质。

在技术领域，绿地项目是指全新的软件项目。这种项目通常还处在规划或实施的早期阶段，有机会构建全新的应用和基础设施，并没有太多限制。开展绿地软件项目相对更容易，在项目预算或团队已到位时更是如此。另外，因为是从零开始，所以对已有的代码库、流程和团队没有太多顾虑。

DevOps绿地项目通常是指一些试点项目，用于证明公有云或私有云方案的可行性，或者尝试采用自动化部署工具或相关工具等。2009年，National Instruments发布了Hosted LabVIEW。这便是一个DevOps绿地项目。

National Instruments是一家具有30年历史的老牌企业，拥有5000名员工，年营业额达10亿美元。为了使Hosted LabVIEW快速上市，该公司组建了一个新的团队，并允许该团队在现有的IT流程之外运作，同时探索公有云的使用。最初的团队成员包括一名应用架构师、一名系统架构师、两名开发人员、一名系统自动化开发人员、一名运维负责人和两名海外运维人员。通过应用DevOps实践，团队交付产品的周期比平常缩短了一半时间。

DevOps棕地项目是指那些已经服务客户长达几年甚至几十年的产品或服务。这种项目通常背负大量的技术债务，譬如无自动化测试、运行在无人维护的平台上等。在Nordstrom的案例中，店内餐厅系统和电子商务系统都是棕地项目。

虽然很多人认为DevOps主要面向绿地项目，但成功应用DevOps进行转型的棕地项目比比皆是。事实上，在2014年DevOps企业峰会上分享的转型案例中，棕地项目所占的比例超过60%。在转型前，这些项目的产品或服务与客户需求存在巨大差异，而DevOps转型为它们创造了巨大的业务价值。

实际上，Puppet Labs的《2015年DevOps现状报告》通过调查数据指出，应用的年龄并不是影响性能的主要因素；相反，性能取决于应用架构在当前（或重构后）是否具有可测试性和可部署性。维护棕地项目的团队可能非常愿意尝试DevOps，尤其在他们认为传统方法无法实现当前目标的情况下（特别是当优化已经迫在眉睫时）棕地项目在转型时可能会面临巨大的阻碍，特别是没有自动化测试，或者紧耦合架构导致团队无法独立开发、测试和部署。本书各章都会讨论如何解决这些问题。

以下是两个成功转型的棕地项目案例。

CSG国际 ：2013年，CSG国际的营收为7.47亿美元，员工数量超过 3500，其计费服务涉及9万多名客服人员，面向5000多万客户提供视频、语音和数据计费服务，总交易次数超过60亿，每月打印和邮 寄的纸质账单超过7000万张。CSG国际最初的改进对象是其票据打 印系统。票据打印是公司的一项主要业务，该系统涉及一个通过 COBOL开发的大型机应用和20个相关技术平台。作为转型的一部分，公司开始每天都在类生产环境中进行部署，并将发布频率提高了一倍，从每年2次增加到4次。通过这些措施，公司显著地提升了应用的可靠性，同时将代码部署时间从两周缩短为不到一天。

Etsy ：2009年，Etsy仅有35名员工，创造了8700万美元的年收入。 但是，每当在节假日零售高峰期间，Etsy就需要吃力地处理蜂拥而至的订单。因此，公司开始彻底实施转型，并最终成为最杰出的DevOps公司之一，也为2015年的IPO成功奠定了基础。

2.兼顾记录型系统和交互型系统

高德纳公司近年来帮助双模IT （bimodal IT）这一概念得到普及。双模IT指的是企业能够支持各种类型的服务演进。在双模IT中，传统的记录型系统是指类似于ERP的系统（例如MRP系统、人力资源系统、财务报表系统等），它的交易和数据的正确性是至关重要的；交互型系统则是指面向客户或员工的可交互系统，例如电子商务系统和办公软件。记录型系统的变化速度通常较慢，并且有监管和合规性要求（例如SOX）。高德纳公司称这种系统为“类型1”，侧重于“做得正确”。交互型系统的变化速度通常较快，因为它需要快速响应反馈，通过实验找到最能满足客户需求的方式。高德纳公司称这种系统为“类型2”，侧 重于“做得快速”。

进行这样的划分也许能够带来便利，但在“做得正确”与“做得快速”之间长期存在矛盾，而DevOps可以有效地解决这个矛盾。Puppet Labs的报告根据精益制造的经验教训指出，高绩效组织能够兼顾高水平的生产能力和可靠性。

此外，由于各个系统相互依赖，因此对其中任一系统的改变都受限于最难改变的系统（这往往就是记录型系统）。CSG国际的产品开发副总裁Scott Prugh曾说：“我们拒绝采用双模IT，因为每一位客户都应同时享有速度和质量。这意味着团队必须追求技术卓越，不管系统是有30年历史的大型机应用，还是Java应用，抑或是移动端应用。”

因此，在改进棕地系统时，不但要努力降低复杂性，提高可靠性和稳定性，而且还应该将系统变得更快、更安全、更容易变更。即使只是为绿地交互型系统增加新功能，也常常会给所依赖的棕地记录型系统带来可靠性问题。使下游的系统能够进行更安全的变更，可以帮助整个组织更快速、更安全地实现目标。

3.从最乐于创新的团队开始

在每一个组织中，不同的团队或个人都会对创新持有不同的态度。Geoffrey A. Moore曾经在《跨越鸿沟》一书中用曲线描绘了这种现象。所谓跨越鸿沟，是指克服困难并找到比创新者和早期采用者（见图1）更大的群体。

图1：技术采用曲线（来源：《跨越鸿沟》）

换句话说，创新者和早期采用者往往能迅速接受新的想法，而其他人则较为保守（这些人又可分为早期从众者、晚期从众者和落后者）。我们的目标是找到那些相信DevOps原则和实践，并有意愿和能力对现有流程进行创新和改进的团队。在理想情况下，这些群体将是DevOps转型的拥趸。

我们不会花费太多时间去改变保守的群体，特别是在早期阶段。相反，应该把精力集中在能创造成功且愿意承担风险的团队上，并以此为基础慢慢扩大范围。即使取得了最高层的支持，也要避免使用“大爆炸”的方式（即遍地开花式的开始），而应该将精力集中于少数几个试点领域，确保它们取得成功，然后再逐步扩展。

4. 扩大DevOps的范围

不管如何选定切入点，都要尽早展示成果，并积极宣传。将大的改进目标分解成渐进式的小步骤。这样做不但能提高改进速度，还可以在错误选择价值流后及早发现。通过及早发现错误，团队可以快速回滚和重试，并根据新的经验做出不同的决定。

基于已经取得的成功，逐步扩大DevOps计划的应用范围。遵循低风险的顺序，有条不紊地提高可信度和影响力，并获取支持。以下列表整理自麻省理工学院管理学教授Roberto Fernandez博士的课程，介绍了当推进变革时，如何基于已获得的支持扩大影响。

（1）发现创新者和早期采用者 ：一开始，把重点放在真正有意愿改进的团队上。这些同事与我们志同道合，他们是探索DevOps的第一批志愿者。这些同事最好受人尊重，并对组织中的其他人有着很大的影响力。他们的支持有助于提升创新的可信度。

（2）赢得沉默的大多数 ：在下一阶段，力求将DevOps实践扩展到更多的团队和价值流，目标是建立更稳固的群众基础。通过与接受DevOps的团队合作，即便他们并不是最有影响力的团队，也能对扩大群众基础有所帮助。有了更多的成功之后，就会产生从众效应，进一步增强影响力。需要谨慎避免与唱反调的人发生冲突。

（3）识别“钉子户” ：所谓“钉子户”，是指那些高调的、有影响力的反对者。他们最有可能抵制（甚至破坏）DevOps计划。一般来说，只有在获得大多数人的支持并建立起足够稳固的群众基础后，才考虑如何应对这个群体。

在组织内全面实施DevOps绝非易事。转型可能会给个人、部门和整个组织带来风险。Ron van Kemenade是ING集团的首席信息官，帮助该集团成功转型为广为人赞的技术组织。他说过：“变革需要勇气，尤其是当有人不断地挑战和抵制你的时候。但如果从小处做起，就没什么可怕的。任何领导者都需要勇于分配团队在可控的范围内冒一些险。”

管理学大师德鲁克说过：“小鱼在小池塘里成为大鱼。”通过谨慎地选择DevOps转型的切入点，我们在组织的某些领域内进行实验、学习并创造价值，但不会给整个组织带来不可逆的后果。同时，通过这种方式，我们能够建立稳固的群众基础，赢得在组织中推广DevOps的机会，从而获得更多支持者的认可和感激。