Part 2 从何处开始

如何在组织中迈开 DevOps 转型的第一步？谁需要参与？如何组建团队？如何保障团队成员投入精力并在最大程度上获得成功机会？本章将回答这些问题。

本部分重点讨论如下话题 ：

• 选择合适的价值流作为切入点 ；
• 理解待转型价值流中的工作 ；
• 参考康威定律设计组织架构 ；
• 通过价值流中各职能团队间更有效的协作，实现面向市场的产出 ；
• 保护团队，并为其赋能

任何转型在开始时都充满着不确定性——我们正在策划的旅程有着美好的目的地，可是几乎所有的中间步骤都是未知的。接下来的几章旨在指导思考和决策，并提供可行的措施及案例研究

5. 选择合适的价值流作为切入点

选择合适的价值流进行 DevOps 转型，这一工作值得仔细斟酌。它不仅决定了转型过程的难度，而且还决定了转型过程的参与者；它不仅影响到如何组建团队，而且还影响到如何让团队及其成员以最佳方式参与其中

5.1 绿地项目与棕地项目

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

DevOps 绿地项目通常是指一些试点项目，用于证明公有云或私有云方案的可行性，或者尝试采用自动化部署工具或相关工具等。

DevOps 棕地项目是指那些已经服务客户长达几年甚至几十年的产品或服务。这种项目通常背负大量的技术债务，譬如无自动化测试、运行在无人维护的平台上等。棕地项目在转型时可能会面临巨大的阻碍，特别是没有自动化测试，或者紧耦合架构导致团队无法独立开发、测试和部署。

5.2 兼顾记录型系统和交互型系统

双模 IT 指的是企业能够支持各种类型的服务演进。在双模 IT 中，传统的记录型系统是指类似于 ERP 的系统（例如 MRP系统、人力资源系统、财务报表系统等），它的交易和数据的正确性是至关重要的；交互型系统则是指面向客户或员工的可交互系统，例如电子商务系统和办公软件

记录型系统的变化速度通常较慢，并且有监管和合规性要求（例如 SOX）。高德纳公司称这种系统为“类型 1”，侧重于“做得正确”。

交互型系统的变化速度通常较快，因为它需要快速响应反馈，通过实验找到最能满足客户需求的方式。高德纳公司称这种系统为“类型 2”，侧重于“做得快速”

进行这样的划分也许能够带来便利，但在“做得正确”与“做得快速”之间长期存在矛盾，而 DevOps 可以有效地解决这个矛盾。

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

5.3 从最乐于创新的团队开始

在每一个组织中，不同的团队或个人都会对创新持有不同的态度。跨越鸿沟，是指克服困难并找到比创新者和早期采用者（见图 5-1）更大的群体。

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

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

5.4 扩大 DevOps 的范围

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

基于已经取得的成功，逐步扩大 DevOps 计划的应用范围。遵循低风险的顺序，有条不紊地提高可信度和影响力，并获取支持。

• 发现创新者和早期采用者
• 赢得沉默的大多数
• 识别“钉子户”

在组织内全面实施 DevOps 绝非易事。转型可能会给个人、部门和整个组织带来风险。

5.5 小结

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

6. 理解、可视化和运用价值流

一旦确定要应用 DevOps 原则和模式的价值流后，就要深刻理解如何向客户交付价值：做什么工作？谁来做？该采取什么措施改善流程？

本章接下来将探讨以下步骤：确定创造客户价值所需的团队；绘制价值流图，把必要的工作可视化；以价值流图为导向，帮助团队更好、更快速地创造客户价值。

6.1 确定创造客户价值所需的团队

在选择好 DevOps 试点应用或服务后，必须确定价值流的所有成员，他们有责任共同为客户创造价值。一般来说，包括以下这些成员。

• 产品负责人：作为业务方的代言人，定义系统需要实现的功能。
• 开发团队：负责开发系统功能。
• QA 团队：给开发团队提供反馈，并确保系统功能符合需求。
• 运维团队：负责维护生产环境，并确保系统能够良好地运行。
• 信息安全团队：负责系统和数据的安全。
• 发布经理：负责管理和协调生产环境部署以及发布流程。
• 技术主管或价值流经理：（根据精益方法论的定义）负责“从始至终地保障价值流的产出满足或超出客户（和组织）期望”

6.2 针对团队工作绘制价值流图

在价值流中，最初的工作是确定客户需求或进行业务构思，这由产品负责人完成；然后，开发团队接手，他们通过编程实现相关功能，并将代码提交到版本控制系统中；接下来，在类生产环境中对功能进行集成和测试，最后部署到（理想情况下）能为客户创造价值的生产环境中。

绘制价值流图的目标并不是记录所有的步骤和细节，而是识别出阻碍价值流快速流动的环节，从而缩短前置时间和提高可靠性。在理想情况下，参与研讨会的成员应该有权力改变各自负责的部分(限制信息的细节程度非常重要，毕竟每个人的时间都很宝贵。)

根据价值流参与团队所提供的全部信息，应该重点分析和优化下面两类工作：

• 需要等待数周甚至数月的工作，例如准备类生产环境、变更审批流程或安全审查流程等；
• 引发或处理重大返工的工作。

价值流图的初始版本应该只包含重要的流程模块。即使是针对复杂的价值流，参与小组通常也可以在几个小时内绘制出包含 5～15 个模块的价值流图。每个模块至少应包括工作项的前置时间和处理时间（分别为图 6-1 中的 LT 和 VA <在有些情况下，处理时间也叫作增值时间（Value Added Time）>），以及由下游消费者测量的%C/A

图中的增值时间 VA 在有些工作环节里为 0，这并不意味着处理时间为 0，而是指此项工作对于客户和价值流来说并不增值

领导者帮助确定改进目标，并指导团队就假设和措施集思广益，通过实验探索各种假设，然后分析结果，以判断假设是否正确。通过不断地重复和迭代，团队把新获得的经验用于下一次实验和验证。

6.3 组建专门的转型团队

DevOps 转型面临的一个固有挑战是与公司当前的业务发生冲突，这不可避免，而且是公司成功发展的自然结果。任何一个成功运作多年（几年、几十年甚至几百年）的组织都已经建立了符合自身的实践和运行机制，例如产品开发、订单管理和供应链运营等。

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

应该组建专门的转型团队，并使之独立于负责日常运作的部门（他们称前者为“专职团队”，称后者为“绩效引擎”）。最重要的是，这个团队应该负责实现明确定义的、可度量的、系统级的目标（例如，将“从提交代码到部署至生产环境”这一过程的前置时间减少 50%）。为了做到这一点，应该采取以下措施：

• 转型团队的成员专门执行 DevOps 转型工作（而不是让他们继续做之前的工作，但要花20%的时间来做 DevOps 转型）；
• 选择熟悉多个领域的通才作为团队成员；
• 选择与其他部门长期保持良好关系的人作为团队成员；
• 如果可能，为团队找一个独立的办公区域，使各位成员尽可能多地相互交流，并和其他部门保持适当的距离。

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

6.3.1 拥有共同的目标

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

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

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

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

6.3.2 保持小跨度的改进计划

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

通过缩短计划跨度和迭代间隔，可以做到以下几点：

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

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

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

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

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

6.3.4 提高工作的可视化程度

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

6.4 用工具强化预期行为

我们的目标是强调，开发人员和运维人员不仅有着共同的目标，而且还有同一份任务列表。在理想情况下，任务列表存储在公共的工作系统中，使用统一的术语，并能全局地进行优先级排序。

采用这种方式，开发人员和运维人员可以创建共享的工作队列，而不是使用不同的工具。这样做的显著好处是，当生产事故在开发人员的工作系统中可见时，人们能清楚地知道事故会在什么时候影响到其他工作，这在使用看板图时尤为明显。

共享队列的另一个好处是统一了任务列表，每个人都能从全局的角度思考优先级最高的事情，选择对组织最有价值的工作，或能最大限度地偿还技术债务的工作。在发现技术债务时，如果不能立即解决，可以将它添加到任务列表中。对于待解决的问题，可以使用为非功能性需求预留的 20%的时间进行修复。

为了强化共同目标，也可以使用聊天室，例如 IRC 频道、HipChat、Campfire、Slack、Flowdock和 OpenFire。聊天室可以实现信息的快速共享（而不是通过预定义的工作流处理表单），能够按需邀请他人加入聊天，能自动记录聊天内容，并且可以在事后对其进行分析。建立机制并允许团队成员互相帮助，甚至帮助其他团队的成员。这将带来惊人的变化——人们获取信息的时间或完成工作的时间从几天缩短到几分钟。此外，因为一切都被有效地记录下来，所以人们之后不再需要向别人求助，而只需要搜索聊天记录即可。

6.5 小结

本章探讨了如何确定支持价值流的团队，并通过绘制价值流图了解到了向客户交付价值所要做的工作。价值流图不仅可以显示当前工作状态的基本情况（包括前置时间和 %C/A 等指标），还可以指导团队确定未来的改进目标。

这样一来，转型团队能够快速迭代，通过实验提高效能。团队分配足够的时间修复已知缺陷和解决架构问题，包括非功能性需求等。通过在价值流中发现问题并持续偿还技术债务，前置时间和质量等各个方面都能取得显著改善。

7. 参考康威定律设计组织结构

“系统设计受限于组织自身的沟通结构。组织的规模越大，灵活性就越差，这种现象也就越明显。”
“软件的架构和软件团队的结构是一致的，说白了就是‘如果让 4 个团队开发同一个编译器，那么编译器最后会有 4个执行阶段’。”

7.1 组织原型

在决策科学领域，主要有 3 种组织结构类型：职能型、矩阵型和市场型。它们可以作为利用康威定律设计 DevOps 价值流的参考。

• 职能型组织结构注重提高专业技能、优化分工或降低成本。这些组织以专业技能为中心，有助于促进职业发展和技能发展，并且通常具有多层次的组织结构。运维部门通常采用这种组织结构（即服务器管理员、网络管理员和数据库管理员等都被划分成单独的小组）。
• 矩阵型组织结构试图结合职能型和市场型。然而，正如许多管理矩阵型组织或身处其中的人所看到的那样，这种组织结构通常都非常复杂。例如，一名员工可能需要向两个甚至更多的经理汇报。有时，矩阵型组织既实现不了职能型结构的目标，也实现不了市场型结构的目标。
• 市场型组织结构注重快速响应客户需求。这种组织往往有着扁平化的结构，由多个跨职能的部门组成（例如市场营销部门和工程技术部门等），整个组织可能往往存在冗余现象。很多实施 DevOps 的杰出组织采用了这种结构。举两个极端的例子。在亚马逊和 Netflix，每个服务团队不仅要负责特性的交付，而且还要负责服务支持。

了解上述 3 种组织结构类型之后，让我们进一步探讨过度地以职能为导向（尤其是在运维部门）为何会给技术价值流造成负面影响，就像康威定律所预测的那样。

7.2 过度职能导向的危害（“成本优化”）

让问题变得更复杂的是，执行工作的人通常都不太理解自己的工作与价值流目标有什么关系（“我之所以要配置这台服务器，是因为别人要我这么做”）。这样就无法让员工发挥创造性和主动性。

如果运维部门的每个职能团队都要同时服务于多个价值流（即多个开发团队），那么问题更是雪上加霜，因为所有团队的时间都很宝贵。

除了导致长时间等待和交付周期延长以外，这种情况也会导致糟糕的交接、大量的返工、交付质量下降、瓶颈和延期等问题。

这种僵局阻碍了组织实现重要目标，而实现这些目标的意义却远远地超过降低成本的愿望。

7.3 组建以市场为导向的团队（“速度优化”）

一般来说，为了实现 DevOps，不但要减少职能导向（“成本优化”）的负面影响，而且还要更好地运用市场导向（“速度优化”）的效果，从而使很多小团队能够安全、独立地工作，并快速地向客户交付价值。

在极端情况下，以市场为导向的团队不但要负责特性开发，而且在整个应用生命周期中还要负责测试、安全、部署和生产环境的运维。这些跨职能团队可以独立运作——能够设计和开展用户实验，构建和交付新特性，在生产环境中部署并运行服务，不依赖于其他团队就能修复任何缺陷，从而加快行动的步伐。

7.4 使职能导向有效

前一节建议组建以市场为导向的团队，但值得一提的是，职能导向也可以成就高效运转的组织（见图 7-1）。组建跨职能和以市场为导向的团队是实现快速流动和可靠性的一种方式，但并不是唯一的方式。只要价值流中的所有人都能意识到客户和组织的目标，不管他们在组织中处于什么位置，都可以通过职能导向取得所预期的 DevOps 成果。

左侧为职能导向：所有工作流经集中式 IT 运维团队；右侧为市场导向：所有产品团队能以自助的方式向生产环境部署松耦合的组件

7.5 将测试、运维和信息安全融入日常工作

在高效能组织中，人们有着共同的目标。保证质量、可用性和安全性不是某个部门的职责，而是所有人日常工作的一部分。

“我现在用的比喻是，Ops 是进攻内锋，Dev 则负责重要位置（如四分卫或外接手）。Dev 的工作是持球冲锋，Ops 的工作则是保证 Dev 有足够的时间向前冲。”

7.6 使团队成员都成为通才

一种对策是让每一位团队成员都成为通才（见表 7-1）。给工程师提供学习必要技能的机会，让他们有能力构建和运行所负责的系统，并定期让他们在不同的职位间轮岗。全栈工程师这个术语现在通常是指那些熟悉或至少大致理解整个应用栈（例如代码、数据库、操作系统、网络和云）的通才。

表 7-1 专家、通才与 E 型人才

I 型（专家）	T 型（通才）	E 型
精通某个领域	精通某个领域	精通某几个领域
其他领域的技能或经验很少	拥有很多领域的技能	有多个领域的实践经验，执行能力强，能持续创新
很快遇到瓶颈	能突破瓶颈	潜力无限
对下游的浪费和影响不敏感	对下游的浪费和影响敏感
抵制灵活或可变的计划	帮助制订灵活和可变的计划

E 型人才是指在经验、专业、探索能力和执行能力 4 个方面都表现突出的人。

我们希望鼓励员工学习，帮助员工克服学习焦虑和获得相关技能，并让他们明确地规划职业生涯，等等。这样做有助于培养员工的成长型思维模式——毕竟，学习型组织需要的是愿意学习的人。通过鼓励每位员工积极学习并为其提供培训和支持，我们将以可持续性最强、成本最低的方式造就强大的团队。

7.7 投资于服务和产品，而非项目

实现高绩效的另一种方法是组建稳定的服务团队，持续提供资金，让他们执行自己的战略和计划。这些团队应该有工程师专门负责兑现对内部或外部客户的具体承诺，如特性、故事和任务等。

基于产品的投资模式注重组织成绩和客户成果，包括公司营收、客户终身价值，以及客户采用率，同时尽可能减少付出（如时间和精力、代码行数等）。与之形成鲜明对比的是传统项目的衡量指标，譬如项目是否在既定的预算、时间和范围内完成

7.8 根据康威定律设定团队边界

不合理的团队组织方式可能产生不良后果，这就是康威定律的副作用。这些不当的方式包括按职能划分团队（例如将开发人员和测试人员安置在不同的办公地点，或者完全外包测试人员），以及按架构层次拆分团队（如应用层、数据库层等）

在理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协调

7.9 创建松耦合架构，提高生产力和安全性

在紧耦合的软件架构中，即使是微小的变更也可能导致大规模的故障。因此，负责某个组件的开发人员不得不和负责其他组件的开发人员不断地协调与沟通，包括走各种复杂的变更管理流程。

面向服务架构（Service-Oriented Architecture，SOA）就具有这种特征。面向服务架构这一概念在 20 世纪 90 年代被提出，它是一种支持独立测试和部署服务的架构方式，其典型特征是由具有限界上下文的松耦合服务组成。

松耦合的架构意味着在生产环境中可以独立更新某一项服务，而无需更新其他服务。该服务必须与其他服务以及共享数据库解耦（可以共享数据库服务，但需要保证它们没有共同的数据库模式）

限界上下文（bounded context）其思路是开发人员应该能够理解和更新服务的代码，而不必知道其对等服务的内部逻辑。各服务严格通过 API 交互，因此不必共享数据结构、数据库模式或对象的其他内部表示。限界上下文确保服务被划分成独立的部分，并具有明确定义的接口，这也使测试更加容易

保持小规模（“两个比萨原则”）
2002 年，亚马逊在试图脱离单一代码库的转型过程中利用“两个比萨原则”保持团队规模小型化——两个比萨够团队的所有成员吃，这样的团队通常有 5～10 人。

康威定律帮助我们根据期望的沟通模式设定团队边界，但也鼓励缩小团队规模，减少团队间的沟通，并保持团队的专业领域小且有界限。

这种规模限制有以下 4 个重要作用

1. 它确保团队成员对系统有清晰、相同的理解。当团队规模变大时，如果要让所有人都了解系统状况，需要沟通的信息量就会成倍增加。
2. 它限制正在开发的产品或服务的增长率。通过限制团队的规模，系统的发展速度也受到限制，这也有助于保证团队成员对系统有相同的理解。
3. 它分散权力并实现自主。每个“双比萨”团队都尽可能地自主工作。团队负责人直接向管理层汇报，由他决定团队负责的关键业务指标（又称适应度函数），并将其作为团队实践的总体评估标准。然后，团队能够自主采取行动来最大限度地提升该指标。
4. 领导“双比萨”团队是让员工获得领导经验的一种方式。在这样的环境中，即使失败了也不会有灾难性后果。

7.10 小结

我们可以看到架构和组织设计的巨大影响。康威定律运用得好，团队就能够安全、独立地开发、测试和向客户交付价值；而运用得不好，就会产生不良的后果，导致安全性和敏捷性遭到破坏。

8. 将运维融入日常开发工作

我们的目标是能够以市场为导向，让小团队快速、独立地为客户提供价值。但在以职能为导向的集中式运维团队里，实现该目标是有挑战的，因为运维团队不得不满足许多开发团队的各种迥然不同的需求。结果导致运维工作需要较长的交付周期，并且需要反复地调整工作的优先级，而且部署结果总是不尽人意

通过使开发团队拥有更强的运维能力，可以以市场为导向创造出更多的业务成果，并能最终提高效率和生产力。

集中式运维团队如何取得以市场为导向的成果。以下是 3 个通用的策略：

• 构建自服务能力，帮助开发人员提高生产力；
• 将运维工程师融入服务团队；
• 如果运维工程师人数紧张，则可以采用运维联络人模式。

8.1 创建共享服务，提高开发生产力

运维部门若想取得以市场为导向的成果，一种做法是创建一套集中式的平台和工具集服务，让所有开发团队都能够通过使用这套平台和服务来提高生产力，例如搭建类生产环境、部署流水线、自动化测试工具、生产环境遥测控制台等。这样，开发团队就能够把更多的精力和时间用在功能构建上，而不是消耗在获取交付和支持生产环境特性所必需的基础设施上。

在理想情况下，运维提供的所有平台和服务应该是全自动化的，并且能按需提供，不需要开发人员提交工单，然后再等待运维团队手动处理，这能保证运维不成为客户的瓶颈

内部共享服务团队应该不断地发掘能在组织内部广泛应用的工具链，判断哪些是能通过集中式平台提供的，并让每个人都可以使用。一般来说，发现经实践验证的工具并拓展其使用范围，要比从零开始构建这些功能更容易成功。

8.2 将运维工程师融入服务团队

若想取得以市场为导向的成果，另一种做法是通过融入运维工程师使产品团队能自给自足，从而降低对集中式运维的依赖程度。这些产品团队可以完全负责服务的交付和支持。

通过将运维工程师融入开发团队，他们的工作优先级几乎完全受所在产品团队的目标驱动，而不再专注于解决自己的问题。因此，运维工程师与其内部和外部客户的联系更加紧密了。此外，产品团队通常有专用的预算雇用这些运维工程师，不过面试和聘用决策可能还是由集中式运维团队来完成，以确保一致性和员工的素质。

对于新的大型开发项目，可以在启动阶段就融入运维工程师。他们的工作包括参与做什么和如何做的辅助决策，影响产品架构，辅助内部和外部的技术选型，帮助创建内部平台的新功能，甚至产生新的运维能力。当产品上线之后，运维工程师可以帮助开发团队承担运维责任。

这种范式有一个重要优势：开发团队和运维工程师的紧密配合和协作是一种极其有效的方式，能将运维知识通过交叉培训的方式融入服务团队，还可以将运维知识逐渐转换为自动化的代码，使之更可靠和更广泛地重用

8.3 为每个服务团队分派运维联络人

由于各种原因（如成本或者资源不足），可能无法给每个产品团队都分派运维工程师，但可以给每个产品团队指定一位运维联络人，通过这种方式同样也能得到类似的好处

集中式运维团队依然管理着所有环境（不只是生产环境，还包括预生产环境），负责确保它们的一致性。派遣的运维工程师的责任是理解下列内容：

• 新产品的功能是什么，为什么要开发这个产品；
• 它是怎样工作的，可运维性如何，可扩展性和监控能力如何（强烈建议以图示说明）；
• 怎样监控和收集指标，如何确认应用的功能正常；
• 架构和模式是否与以往的做法不同，这样做的理由是什么；
• 是否对基础设施有额外的需求，它的使用对基础设施容量的影响如何；
• 特性的发布计划。

相比融入运维工程师的模式而言，分派运维联络人的方式能支持更多的产品团队。我们的目标是确保运维不会成为产品团队的瓶颈。如果发现由于运维联络人的工作量过大而导致产品团队无法实现目标，那么就可能需要减少每个联络人所支持的团队数量，或者临时将运维工程师融入某些产品团队。

8.4 邀请运维工程师参加开发团队的会议

我们的目标是帮助运维工程师和其他非开发人员更好地了解目前开发团队的文化，并主动地参与规划工作和日常工作，从而使运维团队可以更好地为产品团队植入运维能力，并在产品上线以前就落实相关工作。

8.4.1 邀请运维工程师参加每日站会

每日站会的目的是在整个团队范围内分享信息，同时了解所有正在做和将要完成的工作。通过让团队成员相互分享信息，可以发现面临难题的任务，然后用互助的方式找到解决方法，从而从整体上推进工作。此外，团队负责人的到场，还能加速解决优先级和资源冲突问题。

有些信息在开发团队内部是分散的，这是一个常见的问题。通过参加会议的运维工程师，运维部门可以充分理解开发团队的活动，从而更好地进行规划和准备。

8.4.2 邀请运维工程师参加回顾会议

运维工程师可以在回顾会议上提供如下反馈。

• “在两周前，我们发现了监控的一个盲点，团队就如何解决也达成了一致意见，该问题目前已经被解决。上周二，监控系统收到一个告警事件，我们快速地定位到故障，并在客户服务受到影响之前，就把它处理完毕了。”
• “上周那次部署的难度和所用的时间都是一年之最。这里，我们列出一些改进想法，与大家分享。”
• “上周所做的市场促销活动比预期的困难多了，我们不应该再搞类似的促销活动了。为了能完成销售目标，我们其实可以尝试一些其他方案。”
• “在上次部署期间，最大的问题是：生产环境的防火墙规则已经多达数千行了，这导致每次变更都非常困难，而且风险也很高。我们应该考虑重新设计网络流量的管控规则。”

运维团队的反馈能帮助产品团队更好地认识和理解自己所做出的决策对下游团队的影响。当产生负面影响时，我们必须做出相应的改变，防止未来再出现类似的状况。同时，运维团队的反馈也有助于发现更多的问题和缺陷，甚至可以帮助团队发现某些架构问题。

团队的回顾会议也能确定一些改进工作，例如缺陷修复、重构和将手动操作自动化。

8.4.3 使用看板图展示运维工作

因为运维工作是价值流的一部分，所以应该将它和与产品交付相关的其他工作一起呈现在看板图上。通过这种方式，团队能够更加清晰地看到将代码发布到生产环境里需要做的所有工作，并跟踪与产品支持相关的所有运维工作。另外，团队还能够从看板图上看出哪些运维工作受阻，以及需要改进哪些方面。

看板图是工作可视化管理的理想工具。可视化是将运维工作融入产品价值流的关键。如果在这方面做得好，不管组织结构如何调整，我们都能取得以市场为导向的成果

8.5 小结

本章探讨了如何将运维工作融入开发团队的日常工作，以及如何使运维工作可视化。可以采用三种方式：创建共享服务，提高开发生产力；将运维工程师融入服务团队；为每个服务团队分派运维联络人。最后，本章描述了运维工程师如何融入开发团队的日常工作，包括参加每日站会、计划会议和回顾会议。