说到研发效能，大家可能会马上想到度量、指标、流程、CI/CD、代码平台等等东西。

但只是这些吗？为什么要做这些？做了这些有什么用？最终的目的是什么？…… 有很多问题冒出来。

研发效能是什么

看研发效能是什么前我们先看一下效能是什么？

效能是一个衡量资源使用的效果的概念，常用于评价在完成一定任务或达成特定目标时资源（如时间、金钱、原料等）的使用效率。效能高意味着用较少的资源投入获得了较多的产出，或者用最优的方式使用资源以达到最佳的工作绩效。

在商业和管理领域，效能是指组织或个人在达成既定目标和结果的能力。商业和管理领域中的效能更加注重最终的成果而不仅仅是资源的使用。传统意义上的效能只是商业和管理领域效能的一个过程态，但我们当下所追求还是传统意义上的效能，通过这种效能的不断达成，使得组织的效能增加，从而帮助企业更有效地管理资源，提高组织能力，并在市场竞争中保持优势。

回到研发效能是什么，这里我们限定一下范围，主要是软件开发的研发效能，有代码产出的那种研发。对于软件开发来说，主要关注的还是人力成本，或者说是时间成本。后文中的研发效能都指软件开发的研发效能。

研发效能是指通过有效地利用人力和时间资源，持续以最快的速度交付高质量的产品。 这句话可以换成上篇关于研发价值的文章中的公式：

公式：研发的价值 = 单位有效时间内产出的价值 × 有效时间 – 非正常成本 – 正常成本

这是简化的研发价值模型，可以作为理解研发价值创造的基础框架。实际应用中可能还需要进一步的细化和调整，因为价值的计算可能远比这个公式复杂。

研发效能不仅包括了技术层面的各种实践，如代码复用、自动化测试、持续集成（CI）和持续交付（CD），还包括了效能度量、流程优化，团队协作、项目管理、需求理解和用户反馈的及时整合等多个方面。

研发效能的核心目的是优化交付的价值链，通过提高效能来缩短产品从构思到市场的时间，提升产品质量，降低开发成本，以及增强对市场变化的响应能力。这不仅能提高客户满意度和用户体验，还能为企业带来更大的经济效益和更强的市场竞争力。

体系化的提升研发效能

研发效能的提升和优化是一个体系化的工作，是一个多维度、跨职能的系统性工程。包括组织文化、组织结构、技术架构、流程设计、工程系统和度量考核等。

组织文化：创新的基石

组织文化是企业的灵魂，它塑造了员工的行为和思维方式，对研发效能的提升起着至关重要的作用。一个以创新为核心的组织文化，能够激发团队成员的创造力，鼓励他们不断尝试新方法和新技术，甚至在失败中寻找改进的机会。

我们可以通过建立跨部门沟通机制、鼓励知识共享、认可员工创新成果等方式来营造一个开放和协作的工作环境。

在认知层面，特别需要对上达成共识，研发的负责人在领导层面达成一致，能够更好的推动研发效能工作的开展。

组织结构：效能的架子

组织结构决定了信息流动、资源分配和决策过程的效率。在研发效能的提升中，扁平化的管理层级、跨功能的团队配置以及灵活的人员动态管理，都能够促进创新和加速决策过程。

组织结构是提升研发效能的架子，我们可以推动小型化、自治化的团队模式，并通过灵活的项目管理和内部创业机制来激发团队的活力和创新能力。

但这只是一种较为理想的逻辑，实际中我们需要考虑当前组织的情况，人员的水平，公司的文化基因等等，不可一概而论，鞋合不合适只有脚知道

技术架构：效能的核心

技术架构的合理性直接影响研发效能。 一个良好设计的技术架构应当具备高内聚、低耦合的特点，以便于团队成员高效协作，同时保障系统的稳定性和可扩展性。

我们开发过程中会采用微服务、容器化等技术架构，以支持敏捷开发和持续集成/持续部署（CI/CD）等。

当然，微服务、容器化架构和敏捷开发、CI/CD 没有强关联，在实际落地过程中，这些都非必选项，术法落地需要更多的考虑实际的场景和条件。

流程设计：效能的流动

流程设计是确保研发活动有序进行的关键。 良好的流程设计能够最大程度地减少不必要的工作，清晰地定义每个阶段的输入和输出，以及相应的质量标准。

我们通过引入敏捷开发方法和精益思想，持续迭代流程，以消除浪费，并通过自动化工具减轻重复性工作负担。

敏捷和精益都是一种落地的方法，需要考虑实际的情况，根据过程中的生产场景细化每个环节的时间和人力消耗，消除浪费。像我们经常用到的需求交付周期、需求吞吐量（单位时间交付需求个数）、在制品数等指标都会用于这个场景的度量。

工程系统：效能的支撑

工程系统是研发效能提升的具体执行层面。它包括代码管理、构建、测试、部署等一系列工程实践，这些都需要通过系统化的工具和方法来支撑。

通过建立统一的开发环境、版本控制系统和自动化测试平台，以及监控和日志分析系统，以提升研发的效率和稳定性。这里提升效率的逻辑在于 通过系统和自动化的方式减少重复成本和认知成本。

度量考核：效能的反馈

度量考核是研发效能提升过程中的反馈机制。它提供了衡量成果和改进的依据，帮助团队识别问题、跟踪进度，并调整优化策略。

以一种相对科学的方式收集和清洗数据，建立一套和当前团队贴合的指标体系，涵盖项目进度、产品质量、团队效率等各个方面，建立机制定期审视这些指标，并根据数据进行决策和改进。

度量只是我们研发效能的开始，是结果的一种呈现，我们所追求不仅仅是这个结果，而是这个结果带来的效能的提升和研发团队的价值提升。

最后

最后回答一下研发效能是不是一个伪命题这个问题：研发效能不是一个伪命题。

因为研发效能本质是一个 ROI 的逻辑，是一个提升研发价值和核心竞争力的过程。 作为一个技术管理者，这个提升操作是必须且持续要做的，现在只不过以研发效能这种方式表现出来了。

研发效能是一个多维度问题，需要从组织文化、组织结构、技术架构、流程设计、工程系统和度量反馈等方面共同努力。

组织文化是创新的基石、组织结构是效能的架子、技术架构是效能的核心、流程设计是效能的流动、工程系统是效能的支撑、度量考核是效能的反馈。

每个维度都有其独特的挑战和实践方法，但它们相互关联并共同作用。只有全面考虑这些维度并协同推进，才能够真正提升研发效能，实现快速、高质量的软件交付，并最终为用户和企业创造价值。

研发效能关注的不仅仅是技术和工具的应用，更重要的是人、流程、文化的协同进化，以及这一切如何共同作用于创造价值和实现企业战略目标的大背景下。

研发效能不仅仅体现在直接的经济效益上，它还帮助企业构建了一个可持续发展的技术优势和技术竞争力，培养了一支能够快速适应市场变化和技术进步的高效团队，并且能够不断推动产品和服务向前发展，满足甚至超越客户的期望。

每个公司每个技术团队的管理者都有自己的逻辑来回答这个问题，因为这是带团队的核心逻辑之一，且各有缘法。

今天这篇文章不是想准确的回答这个问题，也不是标准答案，只是这些问题最近引发的一些个人思考。

先抛两个公式：

公式一：研发的价值 = (业务价值 + 技术价值) – 非正常成本 – 正常成本

公式二：研发的价值 = 单位有效时间内产出的价值 × 有效时间 – 非正常成本 – 正常成本

这是简化的研发的价值模型，可以作为理解研发价值创造的基础框架。实际应用中可能还需要进一步的细化和调整，因为价值的计算可能远比这两个公式复杂。

总体来看，让价值更大在于攻守，如何攻，如何守，攻就是提高产出价值，守就是减少成本。

在攻的方面，提高产出价值包括提高业务价值和技术价值。我们都知道业务需求是做不完的，如何在做不完的业务需求里面产出更大的价值， 关键点在于业务需求本身的价值和业务价值生效的时间，将具有更大价值的业务需求更快的上线是提高研发侧业务价值的主体逻辑。当然，需求上线后可能还有 bug 之类的，这个我们作为守的那部分来聊。

提高业务价值

提高业务价值的主体逻辑包括两层意思，一个是更大价值的业务需求，另一个是更快的上线。

更大价值的业务需求我理解为做重要的事情，实际上是我们对于事项的一个优先级排序。对于重要的事情分两个阶段，一个是确定事项前的判断，一个是事项确定后的判断，确定前的判断有以下要点：

• 战略和期望：这是一个前期非常重要的判断项，公司层面的战略、技术长期规划，老板对这个组织的期望等等
• 业务影响和目标价值：直白的说，看这些事项对业务目标的达成情况的影响，对收入增长的影响，对于 NPS 这些的影响等等
• 第三方约束和风险：比如已经签了合同的，有截止时间要求的，比如一些严格的技术风险，或者稳定性的问题等等

基于以上这些我们有了一个对事情的判断，但是当这些事情过滤后对于一个管理者来说，还需要做的一个重要性的判断是资源。

资源是最后一个项，是一个相对后期的项，看我们在人力、时间，财务资源上投入多少，这个是过程态中我们要持续看的，根据这些来看我们个人和团队的精力如何分配等。资源需求较大的事项，即使重要性较高，也可能因为资源的限制而需要降低优先级。

在明确了事项的优先级后，下一步就是更快的上线了，更快的上线从研发管理的角度可以分为三个层面，研发流程、工程系统、团队协作和沟通。

1. 研发流程：

   • 精简流程：优化开发到上线的流程，减少不必要的步骤，以加快从需求到部署的时间。可以有一个系统来看每个流程阶段的时间花费，如果没有系统用表格顶一下也行。具体落地指标可以看平均需求交付周期、每流程交付时间等
   • 敏捷实践：采用敏捷方法论，如 Scrum 或 Kanban，以小批量、快速迭代的方式推进项目。在实际落地过程中可以以需求吞吐量、平均需求交付周期、每需求人力成本等。

2. 工程系统：

   • 系统工程化建设：投资于自动化测试、持续集成（CI）、持续部署（CD）等工程系统，以提高开发和部署效率。
   • 技术架构优化：根据业务需求，对技术架构进行持续优化，确保其支持快速增长和变化，并降低长期维护成本。

3. 团队协作和沟通：

   • 跨部门协作：促进开发、运维、产品和其他相关部门之间的沟通，确保需求的快速流转和问题的及时解决。
   • 沟通机制：建立高效的沟通机制，包括定期会议、即时通讯工具和项目管理软件，确保信息流通畅通。
   • 团队授权：赋予团队更大的决策权，使得团队能够快速作出决策，而不必每一项都上报等待批准。

以上是业务价值，将具有更大价值的业务需求更快的上线是核心逻辑。

提高技术价值

对于技术价值而言，逻辑略有不同，技术价值在将更大价值的技术更快的上线的基础上， 需要坚定不移的持续投入和有规划的稳步建设。

持续投入是指在资源方面，特别是人力资源方面，需要在业务需求紧张的情况下保障技术需求的投入资源占比。

有规划的稳定建设是指在保障系统稳定的前提下，有规划的对技术架构进行优化，明确技术发展路线图，按照既定的规划逐步实施技术改造和优化，确保每一步都有明确的目标和时间表。

提高有效时间内的价值

从公式二：单位有效时间内产出的价值 × 有效时间 来看，要提高研发价值，需要提高单位有效时间内产出的价值以及提升有效时间。那么如何提高单位有效时间内产出的价值？

一个是从业务层面，将具有更大价值的业务需求更快的上线，另一个从人的层面，提高单兵能力，因为研发最终是要落在人身上，强化单兵能力，对于提升整个团队的有效时间内的产出有极大地促进作用，单兵能力的高低能决定团队总体效能的高低。

至于提升有效时间，从研发管理角度来看一个是以机制形式保障研发的开发投入时间，如研发静默时间，在静默时间不允许插入非写代码相关的事项；

另一方面是以目标为导向，推动团队集中精力专注于某个目标的达成，如小黑屋之类的，当然，其本质上是延长工作时间，也就在一定程度上提升了有效时间，此法慎用，除非文化本来如此，能留下来的是能接受这种文化的人。

以上是攻的角度，也就是提高产出价值来思考，从守的角度来看，更多提就是减少成本，这里主要是减少非正常成本。

减少非正常成本

非正常成本是指在生产和运营过程中由于管理不善、技术失败、人为疏忽或外部因素导致的超出正常开支的成本。这些成本通常不是生产或提供服务的必需开支，而是由于各种非计划事件造成的损失，可以以某种方式减少或规避。

这里的非正常成本我的理解包括以下的部分：

1. 项目延期和需求变更

项目延期和需求变更会导致增加额外的人力成本，延迟了需求的上线时间，可能导致业务损失或风险发生。我们一般可以通过更精细的项目管理来减少延期，通过正式的变更控制流程，评估变更的必要性和影响，以控制变更带来的成本。

2. 技术难题

当在项目过程中遇到了预料之外的技术挑战和难题，可能会导致项目停滞，以至研发团队无法按时完成项目，需要额外的研发投入或影响产品需求计划等。

我们一般在项目开始前对技术难题进行充分调研和风险评估，如果是在项目中遇到了，快速协调资源解决，甚至是请外部的专家来解决，从内部来看，提升现有团队人才梯队，提升团队成员能力，让成为技术难题的项越来越少是更优的解决方案。

3. 产品缺陷

产品缺陷我们通常称之为线上 BUG，当一个线上 BUG 出现后就会有一个流程串起一批人来解决，这个成本比在更前置的开发阶段或测试阶段发现并解决的成本更高，甚至会影响到用户的使用和口碑。

我们一般是通过代码审核、自动化测试、生死用例、showcase 等各种流程和机制来保障和提升产品的质量，同时对于已经出现的问题，使用缺陷管理系统，确保所有缺陷被记录、跟踪并及时处理。

4. 过度设计

过度设计是指在开发过程中投入的工作远超过解决问题所需的程度，这通常体现在过于复杂的系统设计、不必要的功能，或过早优化的代码上。涉及到开发、维护和产品质量三方面，这种过度设计会导致更多的开发和测试时间，更复杂的维护工作，以及可能降低的产品质量。

在设计时尽量遵循  KISS（Keep It Simple, Stupid） 原则 ，避免不必要的复杂性。

5. 历史债务

技术债务是指由于短期内的快速开发和决策，而在长期内需要支付的额外工作。例如，为了赶项目进度，团队可能会选择快速但不完美的解决方案，而不是花费更多时间来寻找更好的解决方案。

为了解决技术债务，可能需要进行代码重构或重新设计系统，这将带来额外的开发和测试时间。此外，技术债务可能会降低开发团队的生产力，例如，如果代码质量低，团队可能需要花费更多的时间来理解代码、修复错误和添加新功能。

我们一般是要将历史债务管理起来，识别和记录技术债务，并制定计划逐步解决，同时在新项目中避免产生新的技术债务。

6. 线上故障

线上事故对于任何技术团队来说都是一种非常严重的非正常成本。

这类事故可能会对用户产生直接的影响，包括用户体验降低、数据丢失、服务中断等。这不仅可能导致用户对产品或服务的信心降低，甚至可能导致用户流失。此外，严重的时候，线上事故还会导致公司的资产损失。

为此，我们需要建立全面的监控系统，及时发现并响应线上故障，同时制定灾备计划和故障恢复策略，以减少故障影响，并对每次故障进行事后分析，总结教训并采取预防措施避免未来的重复。

在我们的研发过程中，持续的减少以上的非正常成本是提升整体研发价值的守的逻辑。

除此之外，我们还需要考虑整体系统的复杂度，用持续优化对抗世界的不确定性。

康康说：老板要的无非是「人少活好效率高」

换句话说是成本低质量高产出多，而质量高也是为了成本低，只不过和人少的成本相比是不一样的成本。

老板看的还是 ROI

代码的质量和开发效率是研发同学工作的核心。好的代码不仅要能完成预设的任务，也要易于理解、修改和测试，以便其他开发者在未来能够维护和改进。代码的质量和开发效率可以直接反映开发人员的技术能力和专业知识。因此对于一个研发管理者来说，要想掌控一个团队的情况，从代码出发，从代码量和代码质量来度量是一个不可或缺的角度。

为何要度量代码？

代码是软件产品的基础，深入理解代码可以帮助我们更好地了解产品的健康状况、性能状况和维护情况。更重要的是，通过深入分析代码，我们可以发现代码中可能存在的问题和改进点，以便提前发现并解决问题，降低项目风险。基于代码的研发效能度量为我们提供了一个量化、可度量的评估标准，从而使我们能够更科学、更有效地管理和优化研发过程和研发分工。

基于代码的度量是什么？

基于代码的研发效能度量是一种通过对代码及代码提交进行深入分析和理解，从中洞察出可能存在的问题和改进点，以提高研发效率和产品质量的方法。这涉及到代码质量分析、代码性能分析、代码测试分析、代码维护性分析以及技术债务分析等多个方面。

从实际落地来说，基于代码的研发效能度量通常涉及到以下几个方面：

1. 代码质量：这是衡量代码健康状况的重要指标。

   • 代码复杂度：例如，使用圈复杂度（Cyclomatic Complexity）或 Halstead 复杂度（Halstead Complexity）度量代码的逻辑复杂度。
   • 代码规范性：如代码是否遵循了 PEP 8（Python编程规范）或其他语言的编程规范。
   • 代码重复率：如通过工具（如 SonarQube 或 PMD ）检测代码的重复部分，计算代码重复率。
   • 用例覆盖率：如使用工具（如 JUnit 和 Cobertura ）运行单元测试和集成测试，计算用例覆盖率。
   • 注释覆盖率：SonarQube 等工具可以分析出代码覆盖度

2. 开发活动：这是了解开发团队工作模式的重要度量。

   • 提交频率：如通过 Github 或其他版本控制系统统计每个开发人员的提交频率。
   • 代码修改频率：如统计某段代码或某个文件被修改的频率，以理解代码的稳定性。

3. 问题和缺陷：这是评估代码质量问题和风险的关键度量。

   • 缺陷密度：例如，通过错误跟踪系统（如Jira或Bugzilla）统计缺陷数量，然后除以代码行数，计算缺陷密度。
   • 问题解决时间：例如，统计从发现问题到解决问题的平均时间，了解团队的响应效率。

以上就是基于代码的研发效能洞察的主要组成部分。这些度量有助于我们理解代码的健康状况、开发过程的效率，以及代码质量的问题和风险。需要注意的是，这些度量并不能全面反映研发效能，还需要结合具体的项目情况和团队情况进行分析。

基于代码的研发效能度量如何实施

将以上的这些组成部分、时间、人、项目、团队这些结合起来就是一个基本完整的基于代码的研发效能分析系统。

做基于代码的研发效能洞察无非是回答如下的 2 类问题：

1. 做了什么，做了多少
   • 你的团队做了什么，做了多少
   • 你的团队成员做了什么，做了多少
   • 每个成员在团队中的水平处于什么样的水平，有没有特别突出的（多或少）
2. 做得怎么样
   • 你的团队的代码质量如何
   • 有没有比较突出（好或坏）的成员
   • 有没有共性的质量问题

要想回答这些问题，基于代码层面，通过代码度量研发的研发效能，影响力产出，代码质量等，拿到客观的数据度量到人、团队、项目。

我们做代码的洞察实施简化后可以有 4 步：

1.引入工具或系统：将代码这个盒子打开，看到度量后的数据。这里当然会有一个问题分析、行业方案对比的过程。

1. 机制化跟进：需要有一个组织来承接事项，无组织即无成果。结合管理人员的机制化跟进，根据度量的数据和系统的指标，以某个时间间隔来做洞察，发现问题。
2. 整体洞察：从下往上，形成整体效能的洞察，根据发现的问题，明确代码产出的问题点和能衡量状态的指标。
3. 复盘：以 3 个月以一个区间来盘点指标和问题，清晰团队/项目的变化。

基于代码的研发效能度量的优势与挑战

当我们引入某些工具或系统来做了基于代码的度量或洞察后，可以得到如下的一些东西：

1. 全面的代码质量管理：通常能够全面地对代码质量进行管理，包括代码质量分析、代码审查等。
2. 技术债务管理：通常提供了一种有效的方式来管理技术债务。
3. 提高团队效率：通过对代码的持续分析和审查，可以帮助团队提高效率，减少错误和问题。
4. 提供具有洞察力的数据和报告：通常能够提供具有洞察力的数据和报告，帮助团队更好地理解代码质量和研发效能。

以上是一些好的方面，但是也有一些不好的点：

1. 需要一定的学习和适应：对于新的系统和工具，团队成员可能需要一段时间来学习和适应。
2. 可能存在一定的成本：这类系统通常需要付费使用，这可能会增加公司的开支。
3. 可能与现有的流程和工具不兼容：如果团队已经有了自己的流程和工具，那么使用新的系统可能会导致一些兼容性问题。
4. 安全或隐私问题：如果系统是基于云的服务，这意味着代码需要上传到外部服务器进行分析。这可能会引发一些安全和隐私问题。一般我们选择通过私有化部署来解决，但是成本会更高一些。

最后，随着时间的推移，可能会出现「面向指标编程」的情况。这通常发生在过度重视某些度量标准并以此作为主要驱动开发的团队或组织中。这些度量标准可能包括代码行数、问题数、提交频率、测试覆盖率等。

这样可能会带来一些问题：

1. 优化错误的指标： 有时，开发同学可能会在不影响或甚至损害总体产品质量的情况下优化这些指标。比如，如果过度关注代码行数，开发者可能会写出冗长和复杂的代码来增加代码行数。
2. 忽视质量和实用性： 过度关注指标可能会导致开发者忽视代码质量、可读性、可维护性和实用性。例如，开发者可能编写无实际价值的测试，只是为了提高测试覆盖率。
3. 鼓励短视行为： 如果某些指标被用作评估性能或提升的基准，开发者可能会采取短期行为来满足这些指标，而忽视了长期的技术健康状况。

为避免「面向指标编程」，作为团队的管理者应该谨慎选择和使用度量标准。应该选择那些能反映出代码质量、可维护性和实用性的指标，并且要注意平衡多个指标，避免过度优化某一个指标。同时，要培养一个开放的团队文化，鼓励开发同学关注长期的技术健康状况，而不仅仅是满足短期的指标。

2018 年 10 月 31 日 GitHub 通过官方博客发布了 2018 年 10 月 21 日「挂掉」的事件分析。GitHub 指出此次事件发生的原因是在 10 月 21 日 22:52UTC 进行日常维护——更换发生故障的 100G 光学设备时导致美国东海岸网络中心与美国东海岸数据中心之间的连接断开。更具体地 GitHub 分析，虽然两地的连接在 43 秒内恢复，但这次短暂的中断引发了一系列事件，这才导致了长达 24 小时 11 分钟的服务降级。

2020 年 7 月，Cloudflare 的 DNS 服务遭受了大规模的中断，影响了许多依赖其服务的网站。该故障的原因是 Cloudflare 的路由器中的一个错误配置。

以上是在网上搜索各大平台的故障描述，可以看到这些故障都是由于生产环境的变更导致的，有些是网络设备变更，有些是配置变更，有些是维护人员在线上执行了某个操作…… 如此种种。

这些问题最终都是开发人员通过系统化的建设，一个坑一个坑的填完了，但是当我们带着一个团队急速前进时，可能来不及做这些系统化的建设，此时通过流程对生产环境的变更进行管理，快速解决或规避一些问题以控制线上故障的出现。流程能保证的是我们做事的下限。

在做生产环境变更管理流程之前一定要明晰生产环境的概念和范围，在团队内达成共识，然后再去做流程，以规避因为对生产环境的概念和范围不一致，导致的误解和乌龙。

1 生产环境的概念

生产环境，也称为「产品环境」或「线上环境」，是指实际运行并对外提供服务的环境。这个环境中的软件版本、配置和数据都应该是最新的、经过充分测试的，以保证系统的稳定性和性能。线上环境需要提供24小时不间断的服务。

一个应用或环境是否属于线上环境，主要取决于它是否直接对外提供服务。例如，如果一个应用接收并处理来自最终用户的请求，那么它就是线上环境的一部分。同样，如果一个环境中的数据被用于生产服务，那么这个环境也应该被视为线上环境。

通常，生产环境包括以下 4 个部分：

• 硬件资源：例如服务器、网络设备、云服务中的硬件部分等；
• 软件资源：包括操作系统、数据库、中间件、云服务中的软件部分等；
• 应用程序：实际运行的业务代码和与之相关联的部分，如 CI/CD 工具；
• 数据：实际的用户数据和业务数据。

定义了生产环境，从生产环境衍生出生产环境的变更。

2 生产环境变更的概念和分类

生产环境的变更是指在生产环境中对任何一部分进行的修改，包括应用程序的更新、配置的修改、硬件设施的更换等。而线上故障大多来源于生产环境的变更，对生产环境的变更进行管理和控制，在较大程度上可以减少对系统稳定性产生影响。

生产环境的变更从其组成出发，再加上外部流量，可以分为 5 类：

2.1 硬件资源变更

硬件资源变更主要包含所有与物理硬件和云服务硬件配置相关的更换、升级或维护。

• 硬件规格调整：例如，升级处理器（CPU）、扩充内存（RAM）、更换硬盘等。
• 网络设备更新：包括替换路由器、交换机或进行固件更新等。
• 存储设备变动：磁盘扩容、存储设备更换等场景会包含在内。
• 云服务硬件调整：如云计算服务中服务器规格的调整、增减虚拟机实例、增减 POD 数、网络设备变更等。

2.2 软件配置变更

软件配置变更涵盖了所有与操作系统、数据库、中间件以及云服务软件设置的修改。

• 操作系统参数调整：比如，优化操作系统性能通过调整系统参数等。
• 数据库设置变动：例如，数据库参数调整或修改索引，导致数据库负载提升甚至锁表导致的无法读写等线上事故。
• 中间件配置更新：如修改消息队列的设置，调整缓存策略导致缓存穿越或者缓存雪崩等线上问题时有发生。
• 云服务软件配置调整：包括了云服务的安全规则更新、网络配置变动等。

2.3 应用程序变更

应用程序变更主要包含了所有与业务代码和将业务代码发布到生产环境的 DevOps 工具的更改。

• 代码变更：代码变更是我们最最常见的变更类型，主要是通过修改代码改变应用程序并通过发布系统发布到生产环境。这也是我们变更管理中风险最大的地方，因为变更的人，变更的位置和逻辑等都是不确定的。除了正常的发布变更，应用的回滚也是应用变更的回滚，因为其改动了线上的应用。实际中，代码变更在逻辑上包括了修复 bug、优化性能、增加新功能等，都需要对应用程序代码进行更新。
• 配置变更：指应用系统的配置变更，一般是通过配置系统来变更，触发线上应用的热更新或滚动，配置如果是写死在代码中，会变为代码变更。
• 依赖库更新：实际业务中需要对应用程序所依赖的库或框架进行更新，有些更新可能需要改代码，或者代码本身已经是这么个逻辑，在构建的时候就会带出去。
• DevOps 工具变更：例如，升级工具版本，或者对某些功能进行调整。
• DevOps 工具配置变更：如发布脚本中对于 dev 或 prod 环境的配置修改等等，都是高风险操作，线上有着血淋淋的故障。

2.4 数据变更

数据变更很少被人当作变更处理，因为很多时候就是正常的业务操作，如管理后台的批量操作这些，但是这些批量操作如果发生在高峰时期，可能会对线上业务带来较大的影响，轻则速度变慢，重则线上事故。数据变更可以分为线上数据的清理、迁移、更新等操作。

• 数据清理：如定期删除过期数据，清理无效数据节省成本等等，基于不同的目的，将数据清除，除了可能会影响性能，如果清理错了，将会导致用户丢失，以至用户资产的损坏，这将会是很大的线上事故。
• 数据迁移：如将数据从一个数据库迁移到另一个数据库，或者因为业务升级，数据需要从一种逻辑迁移到另一种逻辑，除了负载压力，更多的可能是数据错乱或者数据丢失，这两种情况都会引发用户投诉。
• 数据更新：如前面说的管理后台批量更新，或者上线新模块在已有的数据库上初始化数据等等，这种最多的情况是其引发的 DB/ES 等存储类中间件的高负载导致服务的异常或引发线上事故。

2.5 流量变更

流量变更和上面四个类别不同，其是从外部来看的，主要包含了流量变化的情况。这里不考虑攻击类的流量。流量一般是带来高负载，或者由高负载引发的链路异常或雪崩，从而导致整体服务异常或线上事故。

• 负载调整：如对调整负载均衡策略，更改流量路由等由于考虑不周引发某些节点过热或流量过大，引发级联反应，从而出现异常或事故。
• 后台投放或大型促销活动：如没有提前通知的后台投放或大型促销活动、特殊事件导致的流量激增，可能需要进行负载调整或资源扩容等，如果某些链路存在容量上限，或者达到扩容的上限，就会引起线上异常或事故。

以上 5 种类型画成简单的脑图，如下：

3 变更管理

变更管理是指以可控的方式对线上的服务、配置或基础设施进行变更，从而减少变更对业务和服务质量的影响，快速处理变更可能带来的问题，提升系统的稳定性。

变更管理，咱们从组织和流程机制两个方面来看。

3.1 组织

一个事情要想有力的执行下去，一定是有一个组织来保障事情的整体节奏和推进。

从组织的角度，整个变更管理的组织成员角色可以分为以下几种：

• 变更管理主导者：一般来说，这个角色通常由技术团队的高级管理者来担任，并且这个事情它本身是一个从上向下的事情，需要更上层的负责人来推进事项，一般是 CTO 或 VP，或质量的负责人。他们需要确保变更管理策略和流程的成功实施，对整个变更管理过程负责，并需要对所有的变更决策拥有最后的决定权。

• 变更管理委员会：这是一个跨部门的团队，包括来自业务、开发、运维、质量保证等部门的代表。他们的任务是评审即将进行的变更，评估其对业务的影响，以及是否符合公司的战略目标。他们还负责改进变更管理流程，并对变更管理的效果进行监督和评估。在实际的实施过程中可能没有正式的名称叫委员会，可能叫 XXX 质量小组，或者就是某个研发中心的管理团队兼任。

• 变更经理：这个角色负责确保变更管理流程的日常运行，是实际的变更控制推进者，他们需要协调变更的执行，确保所有的变更都通过了必要的评审，已经准备好了回滚计划，并且变更后的效果已经得到了验证。在实际的实施过程中，变更经理大概率是某个 Leader 或者质量的负责人，或者 PM。

• 变更执行人：这个角色负责协调变更的具体实施，例如安排变更的时间，通知相关人员，收集反馈，等等，一般这种变更由一线的开发，SRE 来做，也有大一些的公司有专门的职位。

3.2 流程机制

变更管理有一个理想状态的标准流程，其大概如下：

1. 变更申请：在我们的流程中可能是创建发布记录，或者申请紧急发布
2. 变更评审：变更评审主要是检查变更过程是否完备，以降低变更的风险，其包括如下内容：
   1. 就绪分析：材料是否完备，人员、设备、软件、网络是否就绪，测试是否达到上线要求等。
   2. 风险分析：架构、性能、业务、合规等方面的风险评估，变更内容是否属于需求范围，变更是否可控。
   3. 重要程度：变更属于一般、重要、紧急、标准哪一种。
   4. 变更审查：内容是否满足业务需求，内容是否通过测试，测试是否全面、有效。
   5. 应急管理：变更步骤、应急方案、回滚方案、应急预案是否完备。
   6. 变更实施：变更计划时间如何安排，发布及回退操作步骤是否完备，自动化步骤情况。
   7. 变更验证：变更涉及的业务、技术验证方法与时间安排。
3. 变更审批：相关负责人对于变更评审的结果进行确认，并审批通过。
4. 变更执行
   1. 根据发布计划执行发布操作，一般应该有一个灰度的过程；
   2. 验证线上功能并回归主流程；
   3. 持续灰度，观察用户直到灰度完成。
5. 变更验收
   1. 对发布的功能进行验收，对于影响范围内的功能进行验收，对业务主流程进行回归验收；
   2. 留守，并观察日志、监控服务负载等，这个操作是为了及时发现验收检查漏掉的问题，或者及时处理隐藏的问题，以减少变更后产生的问题对线上业务的影响。

我们做这个流程是形式上的安慰，还是僵化的惯性，还是能真正地解决问题，是我们在做这个流程以及执行这个流程中需要着重思考的问题。

在变更前，即我们变更线上环境前需要自己做 Code Review，以及交叉的检查，以尽量减少问题流转到后面的操作中，节省问题的处理成本。

在标准流程之外，另外还有两个特别重要的点，一个是周知，一个是盘点。

周知在形式上可以是邮件、群通知、群消息，通过这些方式，将研发自己做的前面所定义的线上变更周知给相关方：「我们做了 XXX 操作，可能会影响 XXX ，你们看下对你们自己有没有影响，如果有相关告警可以找我。」

变更虽然有流程，但是流程保证的是过程，对于过程中的问题通过变更盘点的方式，阶段性回顾问题和成果，在变更委员会中达成共识并继续迭代。在每次迭代的时候我们可以问自己如下的一些问题：

• 与上次回顾相比，变更对线上的影响有更严重吗？有影响到稳定性吗？
• 变更流程是否有什么问题，是否需要专项来解决？是否应该解决？
• 上次回顾安排的事项落实了吗，对应的情况如何，是否有更新到流程或系统中？

以上的回顾操作我们建议以某个管理系统来承载，并且这个管理系统是带有通知等功能，以更好的将变更相关的信息周知出去。当然，也可能直接共享文档+群通知来搞。

4 小结

上面的变更管理只是流程方面的，对于实际中变更管理最好是能在类似于 DevOps 系统中的落地，最少也是在项目管理或流程系统中落地。

生产环境的变更管理是一项复杂而重要的任务。通过对生产环境的良好理解，结合有效的组织、流程和系统工具，我们可以实现对生产环境变更的有效管理，保证业务的稳定运行，提升用户的使用体验，同时也提升了我们自身的运维效率和质量。这也是我们做研发管理必须要完成的任务之一。

软件工程瀑布模型（waterfall model）概念，起源于 Winston Royce 发表于 1970 年的著名文章 “Managing the Developmentof Large Software Systems” (Proc. Westcon, IEEE CS Press, 1970, pp.328-339)。

虽然这个模型可能是个误会，可以见 Craig Larman 和 Victor Basili 教授在 2003 年发表于 IEEE Computer 杂志的封面文章 《Iterative and Incremental Development: A Brief History》 中为我们讲解了一段非常精彩的有关瀑布模型的历史故事，这也可以说是世界软件工程史最大的误解之一。

他其实一直倡导的是迭代、递增和演进式开发，他在那篇文章中描述的瀑布模型其实只是一种最简单的情况，并不是普遍适用的，现在看也不是一种先进、最佳的方案。

瀑布模型的生命周期，包括需求分析阶段、设计阶段、实现阶段和测试阶段等等，其中测试又可以分为单元测试、功能测试、系统集成测试等。

测试左移是在瀑布模型的基础上，为弥补瀑布模型的不足，不让测试工作只成为产品交付前的最后一道屏障，而将测试往前提，将测试贯穿于整个软件研发生命周期中。

这里为什么是左移呢，是因为我们大多数的阅读习惯是从左到右，左在前。当把整个传统软件生命周期在一条直线上辅平，从左到右分为是从需求分析阶段、设计阶段、实现阶段到测试阶段，所以当我们想把测试提前的时候，在这条直线上，就是往左移了。

测试左移一词（shift-left testing）最早可能出现在 Arthur Hicken 的博客里，在他的博客中提到了对测试左移的看法。见这里：The Shift-Left Approach to Software Testing

其依据的核心逻辑是随着软件进入生命周期的后段，发现一个问题并解决的成本会急剧地增加，如下图所示：

成本增加的原因可能有如下几种：

• 关联方多：越后期，关联的模块越多，定位一个问题，解决一个问题需要联动的各方更多，成本显著增加；
• 影响面大：后期影响范围更大，修复一个问题需要考虑的问题更多；
• 流程拉长：当到测试甚至线上再出现问题，整个处理问题的流程拉长，从开发阶段的开发自我闭环，到测试阶段，测试和开发互动，到线上用户、客服、测试、产品和开发都要介入，其流程长度完全不一样。

从图上看，当左移后这些成本会显著减少。不仅仅是减少成本，还可以减少当出现质量问题时，归责于测试团队的问题，以及关于质量的责任问题的扯皮过程。在我们传统的研发过程中，测试同学处于一个被动接受需求，被动接收开发完的功能进行测试，能主动改变的事情不多，而往往背锅的时候都会有测试团队。

测试左移的核心逻辑或原则个人认为有以下三点：

1. 开发同学是质量的第一负责人，测试同学是共同责任人并辅助开发同学做好质量工作；
2. 预防 BUG 比发现 BUG 更重要，工作的重心是预防而非发现；
3. 测试同学以一个相对外部的视角来提供质量建议以辅助开发同学做好异常处理，以提升开发同学的开发质量和技术能力，从而提升整体研发的效能。

在测试左移的研发流程中，测试同学有以下职责：

1. 测试同学主动参与整个研发过程，从产品阶段的质量需求，到设计阶段的方案设计（测试人员往往对全局更加了解）等；
2. 测试同学通过手工或者自动化的方式，对 prod、stage、fat 等环境的应用进行频繁的测试，而不用困在流程中等提测后再进行，更主动进行测试；
3. 在流程中负责主流程的质量验证；
4. 测试同学负责线上问题的跟进和闭环；

我们理想中把这种模式严格落地后，线上质量会提升并且开发同学的能力会有极大的增强。

这里可能会有同学提出关于人力成本的考虑，觉得把测试工作转嫁到了开发同学，或者觉得测试同学的思维模式是找问题，开发同学潜意识不愿意找，不愿意把自己写出的东西弄崩溃，认为需要有一个测试环节等等问题。

但是当开发是质量的第一责任人，并作为一个独立的主体，对自己开发的代码负责，对自己负责的应用负责时，会想办法来预防 BUG，提升质量，那些思维模式的问题会随之改变。

在我的职业生涯中也经历了几年自己开发，自己测试，自己发布的时光，感觉很爽，就是一点，特别谨慎（害怕），因为此时你会是一个独立的主体来解决问题，你得为你自己的代码质量买单，此时会想尽一切办法不出 BUG，预防 BUG，包括极度严谨的多次的 Code Review，每次都要走的多级灰度部署，验证，日志查看，留守。其导致的结果是在一个超过十亿 PV 的应用（中间还有大版本升级、基础环境的升级等大范围的操作）上两年没有出现过大的事故（当然有灰度过程中的问题，但是及时发现并解决）。

那么，作为一个技术团队管理者在开始践行测试左移时需要考虑什么？

1. 团队是否适合做测试左移，测试左移对于开发同学的要求会比较高？
2. 是一把梭，还是先试点，需要评估一下这个改动的影响范围，考虑灰度一下？
3. 业务需要快还是慢，对于慢业务用传统的瀑布是否更合适一些？
4. 左移到什么程度？

回到主题，测试左移到底移了什么？

我的理解，测试左移，移的是角色职责，移的是责任主体，移的是质量意识，这些不移，其它移了都会是事倍功半。