DevOps转型之如何组建专门的转型团队

DevOps转型面临的一个固有挑战是与公司当前的业务发生冲突，这不 可避免，而且是公司成功发展的自然结果。任何一个成功运作多年（几年、几十年甚至几百年）的组织都已经建立了符合自身的实践和运行机制，例如产品开发、订单管理和供应链运营等。 同时，公司还采取各种措施延续和保护当前的运作流程，例如专业化、 注重效率和可重复性、执行审批流程以及防止差异。

虽然这对维持现状很有好处，但为了适应市场的变化，往往需要改变工作方式。这需要颠覆和创新，必然会和当前负责日常业务和内部流程的群体产生冲突，而且后者往往会胜出。

Vijay Govindarajan博士和Chris Trimble博士都是达特茅斯学院塔克商学院的教授。他们曾在The Other Side of Innovation: Solving the Execution Challenge 一书中描述了如何打破日常运作的惯性，实现颠覆性创新。

他们记录了Allstate如何成功开发和销售以客户为导向的汽车保险产品， 《华尔街日报》如何创造盈利的数字出版业务，Timberland如何开发颇具新意的越野跑鞋，以及宝马公司如何开发第一辆电动汽车。 两位博士的研究成果表明，应该组建专门的转型团队，并使之独立于负责日常运作的部门（他们称前者为“专职团队”，称后者为“绩效引擎”）。

最重要的是，这个团队应该负责实现明确定义的、可度量的、系统级的目标（例如，将“从提交代码到部署至生产环境”这一过程的前置时间减少50%）。为了做到这一点，应该采取以下措施：

• 转型团队的成员专门执行DevOps转型工作（而不是让他们继续做之前的工作，但要花20%的时间来做DevOps转型）；
• 选择熟悉多个领域的通才作为团队成员；
• 选择与其他部门长期保持良好关系的人作为团队成员；

如果可能，为团队找一个独立的办公区域，使各位成员尽可能地相互交流，并和其他部门保持适当的距离。

如果可能，要将转型团队从诸多现有的规则和规定中解放出来。毕竟，既定的流程属于一种群体意识。专门的转型团队需要创建新的流程，从而得到想要的结果，创造新的群体意识。

1.拥有共同的目标

任何改进计划的首要内容都是为未来6个月到2年设定可度量的目标。为了实现目标，团队需要付出相当大的努力，而且目标的实现应该能为整个组织和客户创造出显著的价值。

目标和时限应由管理层确定，并告知组织中所有的人。而且，应该限制同时开展过多的改进计划，避免组织和管理层负担过重。以下是改进目标的一些例子：

• 把用于产品支持和计划外工作的预算减少50%；
• 针对95%的变更，确保将从代码提交到版本发布的周期缩短为一周，甚至更短；
• 确保发布可以在工作时段进行，并且服务不中断；
• 把所有信息安全验证的工作集成到部署流水线中，以满足必需的合规性要求。

一旦明确了整体目标，团队就应该制订改进工作的详细计划与节奏。像产品开发工作一样，转型工作也应该以迭代、增量的方式进行。一般每次迭代在2～4周内完成。对于每次迭代，团队应该制订出一组能够产生价值的小目标，并朝着长期目标靠近。在每次迭代结束时，团队应该检查进度，并为下一次迭代设定新的目标。

2.保持小跨度的改进计划

在任何DevOps转型项目中，都需要保持小跨度的改进计划，正如创业公司做产品开发或客户开发一样。应该努力在数周内（最差也应该在数月内）获得可度量的改进成果或者可用的数据。通过缩短计划跨度和迭代间隔，可以做到以下几点：

• 具备重新计划和更改优先级的能力和灵活性；
• 减少工作从实施到生效的延迟时间，从而加强反馈回路，这将更有可能强化期望的行为——初步成功有利于加大投入；
• 从迭代中更快地获得经验，并将其用于下一次迭代；
• 能够更省力地获得改进；在日常工作中更快地实现有意义的差异化改进；
• 降低项目还没有取得成果就被终止的风险。

3.为非功能性需求预留20%的开发时间，减少技术债务

如何合理地设置优先级是流程改进工作的一个常见问题。毕竟，急需改进流程的组织大多没有足够的时间。技术组织则更甚，因为他们还需要偿还技术债务。

当背负沉重的金融债务时，组织只能还利息，从来都无法偿还贷款本金，而且很有可能陷入连利息都还不起的窘境。同样，无法还清技术债务的组织也会发现，在日常工作中，应付老问题已经让自己不堪重负，根本无法开展新的工作。换句话说，这些组织目前仅仅是支付技术债务的利息而已。

为了积极地管理技术债务，要确保至少把20%的开发和运维时间投入到重构、自动化工作、架构优化以及非功能性需求（有时也称为“质量属性”）上，例如可维护性、可管理性、可扩展性、可靠性、可测试性、 可部署性和安全性等（见图1）。

将20%的时间用于创造用户不可见的正面价值

20世纪90年代后期，eBay有一次死里逃生的经历。之后，Marty Cagan 6 写下了关于产品设计和管理的重要著作《启示录：打造用户喜爱的产品》。他总结了以下内容： 产品负责人和工程师之间的协作是这样的：产品负责人需要考虑把团队20%的资源分配给与工程相关的活动，用于重写或重构代码库 中有问题的部分，或者工程师认为有必要改进的部分，从而避免有一天他们对团队说：“我们需要停下来重写所有代码。”如果情况已经非常糟糕了，那就可能需要投入30%甚至更多的资源。然而，如果发现团队认为他们不需要20%的资源就能做这些事情，我会感到非常担心。

Marty Cagan指出，如果组织不愿意支付这“20%的税”，那么技术债务将 会最终恶化到耗尽所有可用资源的程度。终有一天，服务会变得不堪一击，特性交付将停滞不前，所有工程师都在解决可靠性问题或者寻求临时方案。

通过这20%的投入，开发人员和运维人员可以为日常工作中所遇到的问题提供长久的对策，并保证技术债务不会妨碍快速、安全地开发和运营。同时，缓解员工的技术债务压力也可以降低工作倦怠程度。

* 案例研究 *

LinkedIn的“反转行动”（2011年）

LinkedIn的“反转行动”（Operation InVersion）是一个有趣的案例，它证明了为什么要把偿还技术债务作为日常工作的一部分。2011年，LinkedIn成功进行了IPO。但半年过去了，公司依然在部署问题上苦苦挣扎。于是，他们启动了“反转行动”，在两个月内，停止所有特性开发，并对计算环境、部署和架构进行全面的优化。

LinkedIn成立于2003年，其目标是帮助用户“建立社交网络，以获得更好的就业机会”。网站在上线后的第一周就获得了2700名会员。一年后，会员数超过了100万，并呈指数级增长。截至2015年11月，LinkedIn已经拥有超过3.5亿名会员，用户每秒产生数万次请求，后台系统每秒要处理数百万次查询。

起初，LinkedIn主要运行在自己开发的应用Leo上，这是一个单体Java应用，通过servlet服务每个页面，并使用JDBC连接后台的Oracle数据库。然而，早年为了跟上不断激增的流量，团队从Leo中解耦了两个关键服务：一个是在内存中处理会员连接关系的查询，另一个是以这个查询为基础进行会员搜索。

截至2010年，大多数新开发的特性都以新的服务部署，已经有近百个服务独立于Leo运行。但Leo本身还是只能每两周部署一次。

LinkedIn的高级工程经理Josh Clemm说，Leo在2010年面临重大挑战。尽管使用了添加内存和CPU的垂直扩容方式，“但在生产环境中，Leo还是会经常崩溃，并且很难进行故障排除和恢复，发布新特性也非常困难……很显然，我们需要‘终结Leo’，并将它拆分成 许多个有一定功能的小型无状态服务”。

Bloomberg的记者Ashlee Vance在2013年描述道：“当LinkedIn试图同时发布许多新特性时，网站经常会崩溃，工程师需要加班到深夜去解决问题。”到2011年秋天，工程师对挑灯夜战已经习以为常。

LinkedIn的一批顶级工程师，包括在IPO前3个月加入公司的工程副总裁Kevin Scott，决定彻底停止新特性的开发工作，把整个部门投入到整顿网站核心基础设施中去，这被称为“反转行动”。

Kevin Scott发起“反转行动”的目的是将其“作为一个文化宣言注入团队文化。在LinkedIn的系统架构被重构之前，不做任何新特性开发——这是公司和团队需要做的”。

他这样描述其中的压力：“上市以后，所有人都盯着我们，而我们却告诉管理层，所有的工程师在未来两个月里不会发布任何新特性，他们要全身心投入‘反转行动’。这确实是一件很恐怖的事情。”

然而，Ashlee Vance却描述了“反转行动”的巨大成果：“LinkedIn创建了一整套有助于代码开发的软件和工具。从那以后，新特性不再需要等上好几周才能上线。在工程师开发完一个新服务后，会有一系列的自动化检查机制，去测试它与现有特性的交互是否会有潜在问题，然后直接将其发布到LinkedIn网站。现在，LinkedIn的工程师每天将网站进行3次重要升级。”通过建立一套更安全的工作系统，他们不再需要挑灯夜战，反而有了更多的时间开发富有创意的新特性。

Josh Clemm在提到LinkedIn的规模化时写道：“规模化的效果能在许多维度上进行度量，包括组织层面。‘反转行动’使整个开发部门都专注于改进工具、部署流程、基础设施和开发人员的生产力。它成功地实现了我们所需的工程敏捷性，从而让我们今天能够规模化地构建新产品。2010年，我们已经有超过150个独立的服务。今天，我们的服务超过750个。”

Kevin Scott说：“不管是个人目标，还是团队目标，都是帮助公司盈利。如果你有机会领导工程师团队，最好从CEO的角度看问题，透彻理解公司、业务、市场、竞争环境需要什么，并将这些理解应用到你的团队中，帮助公司赢得市场。”

通过偿还近10年的技术债务，LinkedIn的“反转行动”实现了稳定性和安全性，同时为公司下一阶段的成长奠定了基础。然而，它花费了两个月处理非功能性需求，并以牺牲在IPO时向市场承诺的特性为代价。通过在日常工作中发现和解决问题，能有效地管理技术债务，避免“背水一战”。

4.提高工作的可视化程度

为了能够明确团队是否正朝着既定目标前进，组织中的每个人都有必要了解当前的工作状态。将状态进行可视化的方法有很多，最重要的是有效展示最新状态，而且要不断修订，以确保团队了解最新进展。 

 总之，组建专门的转型团队不仅有利于团队本身，而且对“绩效引擎”也有好处。通过让独立的团队尝试新的实践，组织的其他部门得以避免创新带来的潜在风险。