我们来分析管道的事务数据 我们能否分析事务数据以提取大量信息？当然可以！
与所有事务数据一样，庞大的数量使我们无法发挥任何意义。这就是为什么我们应该汇总和进行分析以收集对我们组织的见解。分析可以帮助我们以点见面，以下是我们如何通过管道分析和见解改善实践的三个示例。
在每周发生的数百次部署中，我们了解到应用 A 的部署失败次数是应用 B 部署失败次数的三倍。这一发现促使我们研究了应用 A 在环境稳定性和配置管理方面的设计选择。我们了解到，该团队在其数据中心使用不稳定的虚拟机进行部署，而应用 B 则采用容器化方式。我们优先考虑对不可变基础架构的投资，并在一个月后进行了检查，以确保该投资的回报良好。果然，确实如此。可以测量，也可以修复。
另一个例子是，当我们得知应用 B 的静态代码分析错误在过去几个季度中稳步上升时，这可能意味着应用 B 背后的团队需要（重新）培训才能编写更好的代码。我们还发现，静态代码分析器出现了误报，这意味着它们在没有出现编码违规情况时就标记了编码违规。因此，我们将他们的分析器升级为知名行业标准工具，并在一定程度上减少了误报。我们组织了一次编码研讨会，讨论并解决了合理的静态分析错误。最后，团队又重现欢声笑语。
另一个有趣的见解是，应用 A 的单元测试的代码覆盖率低于应用 B 和 C，但应用 A 的生产问题数量是去年最少的。编写单元测试和测量代码覆盖率都很好。过度练习对团队没有成效，对客户也毫无用处。吸取的经验教训。
关键绩效指标 (KPI) 在引导组织朝着正确的方向前进时，我们不能依赖意见。首先，我们需要根据成功的样子来定义 KPI。其次，我们需要通过分析月、季度和年份的 KPI 来做出以数据为导向的决策。
组织 KPI 与部门 KPI 很多时候，我们已经看到各个部门定义自己的成功指标。只要这些指标与组织的目标相关，了解成功对各部门来说都是一件好事。
测试失败、暂存失败与生产失败 一些组织要求开发人员负责测试环境，QA 负责暂存环境，运维人员负责生产环境。与其让开发人员被测试环境中运行的单元测试的代码覆盖率报告所困扰，不如让他们退后一步，着眼于全局，无论他们是否负责环境，这点非常重要。
性能测试导致的暂存失败百分比可能很高，这可能是由于性能基准测试不正确或代码缓慢所致。比较分析可能表明，管道在生产中的集成冒烟测试中失败率最高，因此值得进行调查。根本原因可能是产品中的真实错误，也可能是错误的测试代码、不准确的测试数据、错误的测试配置、产品和工程之间的误解等。
进一步挖掘可能会发现错误的测试配置猖獗，您可以优先修复这些问题以修复频繁的集成故障。此外，开发人员自始至终拥有自己的代码也符合 DevOps 范例。
稳定性指数 一旦我们定义了 KPI，就必须了解单个 KPI 是否存在偏差以及在任何特定方向上严重偏差。如果是这样，我们需要将其与其他使重心接近中间的 KPI 保持平衡。其中一个 KPI 就是稳定性。
开发人员使用 FeatureLeadTime（功能提前期）来衡量稳定性，这是一项功能在生产中上线所花费的时间。一项功能包含多个提交，因此对 FeatureLeadTime 更精细的衡量标准是CheckIn2GoLive，即签入到在生产中上线所需的时间。
通过管道测量 CheckIn2GoLive，因为这可以用管道将代码从测试提升到暂存再到生产所需的时间来估算。此外，CheckIn2GoLive 还反映了 MTTR（平均解决时间）缺陷，因为错误修复在从测试到暂存再到生产的整个流程中都要经过相同的流程。
有趣的是，当我问运维时，速度通常具有负面含义，因为他们习惯规避风险。他们衡量逃脱的缺陷数量以反映故障，并根据管道发现的缺陷与逃脱的缺陷的百分比来定义稳定性。
业务根据客户满意度或回头客数量来定义稳定性。虽然这听起来很主观，但您可以通过客户提出的缺陷数量或客户反馈调查来估算该指标。
稳定性指数就是一个典型的例子，其中开发人员、运维和业务部门从自己的角度出发，坚持己见，但是，组织最好创建混合指数，而不是依赖单独一个部门的意见。因此，需要创建一个公正的组织稳定指数。性
代码质量指数 另一个需要考虑不同观点的示例是代码质量。有人说我们代码的质量反映在通过单元测试衡量的代码覆盖率上，而另一些人则说这是循环复杂性。标准静态分析器会报告代码重复、安全漏洞和潜在的内存泄漏。所有这些都是衡量代码质量的真正指标，因此创建了一个索引，其中所有这些，可能还有其他因素，都在其中发挥作用。
业务KPI 与技术 KPI 组织喜欢关注的另一个热门 KPI 是冲刺所带来的价值。一种常见的不良实践是记录版本数量，这本身并不能增加价值。您可以将位从 A 点移到 B 点，而不必为业务提供动力，但这还不够好。一些组织衡量的是该冲刺中新添加的测试数量或执行的测试总数，这些也不反映业务结果，仅反映工程工作量。冲刺中提供的价值必须与业务相关。
业务 KPI 的例子可能包括上个季度的客户获取数量和上个月的广告点击量，管道不会直接影响这些业务指标。我们尝试将业务 KPI 映射到技术 KPI 的唯一原因是要了解技术工艺与业务目标的关系。
将业务 KPI 映射到管道还可以帮助我们计算管道的 RoI（投资回报率）。领导团队使用这些指标来了解可能的改进领域并规划预算。
踏上您的旅程 不要浪费时间争论持续交付是否适合您，持续集成是否足够，或者持续部署是否是您的极乐世界。如果您踏上这段旅程，它将为您的团队不断进步创造机会！这将帮助您的团队放心地进行实验，让他们不会因为“午夜”发布而精疲力尽。
通过我们的 DevOps CI/CD 教程了解如何构建持续集成、交付和部署 (CI/CD) 管道。此外，Atlassian 的 Open DevOps 还提供了一个开放的工具链平台，允许您使用自己喜欢的工具构建基于 CD 的开发管道。