第 5 章 选择合适的价值流作为切入点
- 我们的第一个目标就是帮助所有团队测量周期，使之可视化，并尝试缩短交付周期，然后不断迭代。”
5.1 绿地项目与棕地项目
- 绿地项目是指全新的软件项目
- 棕地项目是指已经服务客户长达几年甚至几十年的产品或服务。这种项目通常背负大量的技术债务
- 很多人认为DevOps主要面向绿地项目，但成功应用DevOps进行转型的棕地项目比比皆是
5.2 兼顾记录型系统和交互型系统
- 传统记录型系统是指类似于ERP系统，记录型系统的变化通常较慢
- 交互型系统变化速度通常较快，需要快速响应反馈
5.3 从最乐于创新的团队开始
- 我们的目标是找到那些相信DevOps原则和实践，并有意愿和能力对现有流程进行创新和改进的团队
- 我们不会花费太多时间去改变保守的群体，特别是在早期阶段。相反，应该把精力集中在能创造成功且愿意承担风险的团队上，并以此为基础慢慢扩大范围
5.4 扩大DevOps的范围
- 不管如何选定切入点，都要尽早展示成果，并积极宣传
- (1) 发现创新者和早期采用者：一开始，把重点放在真正有意愿改进的团队上
- (2) 赢得沉默的大多数：在下一阶段，力求将DevOps实践扩展到更多的团队和价值流，目标是建立更稳固的群众基础
- (3) 识别“钉子户”：所谓“钉子户”，是指那些高调的、有影响力的反对者
第 6 章 理解、可视化和运用价值流
- 根据多年的经验总结出一个开始优化价值流的有效方法，就是和所有核心干系人一起演练价值流映射，从而帮助团队梳理出创造价值的所有步骤
6.1 确定创造客户价值所需的团队
- 无论价值流的复杂程度如何，其中都没有一个人能够知道为客户创造价值所要做的每一项工作，尤其是当工作由多个团队完成时。这些团队往往属于不同的部门，甚至不在同一个办公地点，考核方式也不同
6.2 针对团队工作绘制价值流图
- 绘制价值流图的目标并不是记录所有的步骤和细节，而是识别出阻碍价值流快速流动的环节，从而缩短前置时间和提高可靠性。在理想情况下，参与研讨会的成员应该有权力改变各自负责的部分1
- 根据我的经验，这样的价值流映射演练总是让人大开眼界。很多人通常是第一次看到，为了向客户交付价值，到底需要完成多少工作
- 根据价值流参与团队所提供的全部信息，应该重点分析和优化下面两类工作
- 需要等待数周甚至数月的工作，例如准备类生产环境、变更审批流程或安全审查流程等
- 引发或处理重大返工的工作
- 概念
- 工作项的前置时间：LT
- 处理时间（或增值时间）：VA（Value Added Time）
- 由下游消费者测量的%C/A
6.3 组建专门的转型团队
- 应该组建专门的转型团队，并使之独立于负责日常运作的部门（他们称前者为“专职团队”，称后者为“绩效引擎”）
- 最重要的是，这个团队应该负责实现明确定义的、可度量的、系统级的目标（例如，将“从提交代码到部署至生产环境”这一过程的前置时间减少50%）。为了做到这一点，应该采取以下措施：
- 转型团队的成员专门执行DevOps转型工作（而不是让他们继续做之前的工作，但要花20%的时间来做DevOps转型
- 选择熟悉多个领域的通才作为团队成员
- 选择与其他部门长期保持良好关系的人作为团队成员
- 如果可能，为团队找一个独立的办公区域，使各位成员尽可能多地相互交流，并和其他部门保持适当的距离
6.3.1 拥有共同的目标
- 任何改进计划的首要内容都是为未来6个月到2年设定可度量的目标。为了实现目标，团队需要付出相当大的努力，而且目标的实现应该能为整个组织和客户创造出显著的价值
- 一旦明确了整体目标，团队就应该制订改进工作的详细计划与节奏。像产品开发工作一样，转型工作也应该以迭代、增量的方式进行。一般每次迭代在2～4周内完成。对于每次迭代，团队应该制订出一组能够产生价值的小目标，并朝着长期目标靠近。在每次迭代结束时，团队应该检查进度，并为下一次迭代设定新的目标
6.3.2 保持小跨度的改进计划
- 具备重新计划和更改优先级的能力和灵活性
- 减少工作从实施到生效的延迟时间 ，从而加强反馈回路 ，这将更有可能强化期望的行为——初步成功有利于加大投入
- 从迭代中更快地获得经验 ，并将其用于下一次迭代
- 能够更省力地获得改进
- 在日常工作中更快地实现有意义的差异化改进
- 降低项目还没有取得成果就被终止的风险
6.3.3 为非功能性需求预留20%的开发时间，减少技术债务
- 为了积极地管理技术债务，要确保至少把20%的开发和运维时间投入到重构、自动化工作、架构优化以及非功能性需求（有时也称为“质量属性”）上，例如可维护性、可管理性、可扩展性、可靠性、可测试性、可部署性和安全性等（见下图）
- 产品负责人和工程师之间的协作是这样的：产品负责人需要考虑把团队20%的资源分配给与工程相关的活动，用于重写或重构代码库中有问题的部分，如果情况已经非常糟糕了，那就可能需要投入30%甚至更多的资源
- 如果组织不愿意支付这“20%的税”，那么技术债务将会最终恶化到耗尽所有可用资源的程度。终有一天，服务会变得不堪一击，特性交付将停滞不前，所有工程师都在解决可靠性问题或者寻求临时方案
案例研究 * LinkedIn的“反转行动”（2011年）
LinkedIn的“反转行动”（Operation InVersion）是一个有趣的案例，它证明了为什么要把偿还技术债务作为日常工作的一部分。2011年，LinkedIn成功进行了IPO。但半年过去了，公司依然在部署问题上苦苦挣扎。于是，他们启动了“反转行动”，在两个月内，停止所有特性开发，并对计算环境、部署和架构进行全面的优化 截至2010年，大多数新开发的特性都以新的服务部署，已经有近百个服务独立于Leo运行。但Leo本身还是只能每两周部署一次 现在，LinkedIn的工程师每天将网站进行3次重要升级 2010年，我们已经有超过150个独立的服务。今天，我们的服务超过750个
6.3.4 提高工作的可视化程度
- 组织中的每个人都有必要了解当前的工作状态。将状态进行可视化的方法有很多，最重要的是有效展示最新状态，而且要不断修订，以确保团队了解最新进展
6.4 用工具强化预期行为
- 共享队列的另一个好处是统一了任务列表，每个人都能从全局的角度思考优先级最高的事情，选择对组织最有价值的工作，或能最大限度地偿还技术债务的工作。在发现技术债务时，如果不能立即解决，可以将它添加到任务列表中。对于待解决的问题，可以使用为非功能性需求预留的20%的时间进行修复
第 7 章 参考康威定律设计组织结构
- 康威定律：“系统设计受限于组织自身的沟通结构。组织的规模越大，灵活性就越差，这种现象也就越明显。”
- 康威定律：“软件的架构和软件团队的结构是一致的，说白了就是‘如果让4个团队开发同一个编译器，那么编译器最后会有4个执行阶段’。”
- 软件开发团队的结构对软件产品的架构和成果有着巨大的影响
7.1 组织原型
- 主要有3种组织结构类型
- 职能型组织结构：注重提高专业技能、优化分工或降低成本
- 矩阵型组织结构：试图结合职能型和市场型。然而，正如许多管理矩阵型组织或身处其中的人所看到的那样，这种组织结构通常都非常复杂
- 市场型组织结构：注重快速响应客户需求。这种组织往往有着扁平化的结构，由多个跨职能的部门组成（例如市场营销部门和工程技术部门等），整个组织可能往往存在冗余现象。很多实施DevOps的杰出组织采用了这种结构
7.2 过度职能导向的危害（“成本优化”）
- 传统IT运维组织往往采用职能型结构，数据库管理员被归在一组，网络管理员归在另一组……这种方式显然会延长交付周期，特别是在大规模部署这样复杂的活动中，不得不向多个团队发出一堆工单并且对工作的交接情况进行协调，导致每一个步骤都面临长时间等待
7.3 组建以市场为导向的团队（“速度优化”）
- 将工程师及其专业技能（如运维、QA和信息安全）嵌入每个服务团队，或者得团队提供自助服务平台，其功能包括配置类生产环境、执行自动化测试或进行部署
7.4 使职能导向有效
- 左侧为职能导向：所有工作流经集中式IT运维团队
- 右侧为市场导向：所有产品团队能以自助的方式向生产环境部署松耦合的组件
7.5 将测试、运维和信息安全融入日常工作
- 共同的痛点可以强化团队的共同目标。一个经典的案例是Facebook。2009年，Facebook正经历着飞速的增长，同时在代码部署方面也遇到了重大问题。虽然并非所有问题都会直接影响到客户，但团队始终处于没完没了的救火状态中
- 为了提升部署效率，Facebook采取的最有效的一个措施就是让所有工程师、工程经理和架构师轮流值班，负责他们自己构建的服务的运维工作。通过这样做，所有构建服务的人都对自己在上游所负责的架构和代码有了亲身的感受，这对下游的工作产生了巨大的积极影响
7.6 使团队成员都成为通才
- 部门过于专业化时，就会产生筒仓
- 任何复杂的运维活动都需要在基础设施的不同部分之间多次交接和排队，这导致交付时间推迟（例如，每次网络变更都必须由网络部门的某个人实施）
- 一种对策是让每一位团队成员都成为通才（见表）
- E型人才是指在经验、专业、探索能力和执行能力4个方面都表现突出的人
7.7 投资于服务和产品，而非项目
7.8 根据康威定律设定团队边界
- 不合理的团队组织方式可能产生不良后果，这就是康威定律的副作用。这些不当的方式包括按职能划分团队（例如将开发人员和测试人员安置在不同的办公地点，或者完全外包测试人员），以及按架构层次拆分团队（如应用层、数据库层等）
- 不当的组织方式需要各个团队进行大量的沟通和协调，但仍然可能导致大量返工、对需求定义有分歧、工作交接低效，以及由于等待上游人员完工而造成的人员闲置等
7.9 创建松耦合架构，提高生产力和安全性
- 如果架构能够支持小团队独立、安全、快速地进行开发、测试和部署，就可以提高和维持开发人员的生产力，并改善部署质量。面向服务架构（Service-Oriented Architecture，SOA）就具有这种特征
- 它是一种支持独立测试和部署服务的架构方式，其典型特征是由具有限界上下文的松耦合服务组成
- 限界上下文（bounded context）是Eric Evans在《领域驱动设计》9一书中提出的概念。其思路是开发人员应该能够理解和更新服务的代码，而不必知道其对等服务的内部逻辑
保持小规模（“两个比萨原则”）
- 2002年，亚马逊在试图脱离单一代码库的转型过程中利用“两个比萨原则”保持团队规模小型化——两个比萨够团队的所有成员吃，这样的团队通常有5～10人
- 这种规模限制有4个重要作用
- (1) 它确保团队成员对系统有清晰、相同的理解。当团队规模变大时，如果要让所有人都了解系统状况，需要沟通的信息量就会成倍增加
- (2) 它限制正在开发的产品或服务的增长率。通过限制团队的规模，系统的发展速度也受到限制，这也有助于保证团队成员对系统有相同的理解
- (3) 它分散权力并实现自主。每个“双比萨”团队都尽可能地自主工作。团队负责人直接向管理层汇报，由他决定团队负责的关键业务指标（又称适应度函数），并将其作为团队实践的总体评估标准
- (4) 领导“双比萨”团队是让员工获得领导经验的一种方式。在这样的环境中，即使失败了也不会有灾难性后果。亚马逊的策略有一个关键要素，即“双比萨”团队的组织结构与面向服务架构之间的联系
- 康威定律运用得好，团队就能够安全、独立地开发、测试和向客户交付价值；而运用得不好，就会产生不良的后果，导致安全性和敏捷性遭到破坏
第 8 章 将运维融入日常开发工作
- 集中式运维团队如何取得以市场为导向的成果
- 3个通用的策略：
- 构建自服务能力，帮助开发人员提高生产力
- 将运维工程师融入服务团队
- 如果运维工程师人数紧张，则可以采用运维联络人模式
8.1 创建共享服务，提高开发生产力
- 运维部门若想取得以市场为导向的成果，一种做法是创建一套集中式的平台和工具集服务，让所有开发团队都能够通过使用这套平台和服务来提高生产力，例如搭建类生产环境、部署流水线、自动化测试工具、生产环境遥测控制台等
8.2 将运维工程师融入服务团队
- 通过融入运维工程师使产品团队能自给自足，从而降低对集中式运维的依赖程度。这些产品团队可以完全负责服务的交付和支持
- 产品团队通常有专用的预算雇用这些运维工程师，不过面试和聘用决策可能还是由集中式运维团队来完成，以确保一致性和员工的素质
- 这种范式有一个重要优势：开发团队和运维工程师的紧密配合和协作是一种极其有效的方式，能将运维知识通过交叉培训的方式融入服务团队，还可以将运维知识逐渐转换为自动化的代码，使之更可靠和更广泛地重用
8.3 为每个服务团队分派运维联络人
- 由于各种原因（如成本或者资源不足），可能无法给每个产品团队都分派运维工程师，但可以给每个产品团队指定一位运维联络人，通过这种方式同样也能得到类似的好处
8.4 邀请运维工程师参加开发团队的会议
- 可以邀请他们参与开发团队的各种会议。我们的目标是帮助运维工程师和其他非开发人员更好地了解目前开发团队的文化，并主动地参与规划工作和日常工作，从而使运维团队可以更好地为产品团队植入运维能力，并在产品上线以前就落实相关工作
8.4.1 邀请运维工程师参加每日站会
- 有些信息在开发团队内部是分散的，这是一个常见的问题。通过参加会议的运维工程师，运维部门可以充分理解开发团队的活动，从而更好地进行规划和准备
8.4.2 邀请运维工程师参加回顾会议
- 参加回顾会议的运维工程师也可以从中学习和受益。而且，当回顾的时间段里正好有部署或发布时，运维工程师应该向大家汇报结果，并给产品团队提供反馈。这样做可以改进未来工作的计划和执行方式，提高工作的质量
- 我们必须提醒所有人，改进日常工作其实比日常工作本身更重要，所有团队都必须为此预留时间（例如，每个周期都分配20%的时间用于改进工作，安排每周一天或每月一周，等等）。如果不这样做，在偿还技术债务的巨大压力之下，团队的生产力肯定会遭到破坏
8.4.3 使用看板图展示运维工作
- 使用看板图展示相关的运维工作非常少见。然而，若想使应用成功运行于生产环境（真正产生客户价值的地方），这些运维工作是必需的
- 因为运维工作是价值流的一部分，所以应该将它和与产品交付相关的其他工作一起呈现在看板图上
第二部分总结
- 我们思考并探讨了DevOps转型的多个方面，包括选择切入点，理解架构与组织的关系，以及组建转型团队，还探讨了如何将运维工作融入开发团队的日常工作
