DevOps通过一系列追求敏捷思维的实践来提高软件交付速度和质量。当你提到DevOps时，首先想到的术语是持续集成、持续交付和部署、协作、自动化和监控。DevOps对不同的团队意味着不同的东西。一些团队都在关注自动化，而另一些团队则手动做事并且仍然认为他们在做DevOps。有些人将其视为一种文化和心态。由于DevOps围绕持续交付和快速代码交付展开，因此快速行动而不会出现任何重大错误至关重要。跟踪可以帮助您实现这一目标的DevOps指标至关重要。要在DevOps中取得成功，团队需要使用许多不同的工具。这就是为什么不同的DevOps指标对不同的开发团队至关重要。因此，在开始使用DevOps之前，您的团队应该确定DevOps对他们意味着什么。而且，团队还应该发现最大的DevOps挑战。然后，他们可以更轻松地识别需要更积极地监控的DevOps指标，以改进和创建更高质量的软件交付流程。以下是大多数团队认为重要的DevOps指标：部署频率开发和保持竞争优势、提供更高质量和准确性的更新、新功能和技术增强非常重要。增加交付强度的机会允许更大的灵活性和更好地满足不断变化的消费者需求。目标应该是尽可能频繁地进行较小的部署。当部署规模较小时，软件测试和部署会更轻松。定期测量部署频率可以更好地了解哪些改进是成功的，哪些部分需要更改。频率的快速下降可能表明其他任务或手动操作正在干扰工作流程。为了实现可持续增长和发展，建议对部署频率指标进行小而连续的更改是最佳选择。更进一步，使测试更易于管理可以衡量生产和非生产部署。这样，您将能够确定您的部署进??行QA的频率，并针对早期和较小的部署进行优化。部署时间该指标衡量执行部署所需的时间。尽管乍一看似乎无关紧要，但测量部署时间是可以指示潜在问题的DevOps指标之一。例如，如果您的部署需要一个小时，则说明有问题。这就是为什么最好专注于更小但更频繁的部署。实施者：捕获构建时间。强烈建议团队使用自动化测试通过率，以有效利用单元和集成测试来最大化速度。由于DevOps严重依赖自动化，因此使用有用的DevOps指标来衡量自动化测试的有效性。了解有多少代码调整会导致测试崩溃是很有用的。代码提交该指标计算团队在将软件实施到生产环境之前对软件所做的提交次数。这衡量了开发速度和代码的准确性。团队应该提出每个团队成员都应该遵循的标准代码提交范围。大量提交可能表明代码质量差或缺乏明确的开发目标。另一方面，当人数低于标准范围时，团队可能效率低下或组织良好。有必要确定减少或增加提交次数的原因，以保持效率和项目进度，同时仍保持团队成员的最大幸福感。缺陷逃逸率无论您在DevOps方面的经验如何，错误都会发生-特别是如果您经常进行调整。软件开发涉及实验，作为过程的一部分，您应该始终预见到错误。缺陷逃逸率指标显示您在软件缺陷投入生产之前发现它们的能力。如果您想快速交付代码，这一点尤为重要。要成功实现此目标，您需要有效地检测缺陷。费用虽然云是降低基础架构成本的绝佳解决方案，但某些计划外错误和事件的代价可能非常高。这就是为什么您应该专注于捕获不必要的成本并尝试减少它们，并且可视化您的支出来源可以在理解您最昂贵的运营方面发挥重要作用。理想的情况是拥有一种工具，可以使您的睡眠周期自动化，并且仅在实际使用它们以降低成本时才唤醒环境。失败的部署和环境健康部署通常会给您的用户带来问题，有时，我们必须撤消失败的部署。即使这不是我们希望在竞选活动中发生的事情，我们也应该始终意识到它可能会发生。频繁失败的部署是我们环境健康状况的一个指标，这将我们带到下一个指标。检测时间虽然减少甚至消除失败的更改是最好的方法，但重要的是在发生故障时快速捕获它们。确定关键绩效指标的时机将决定当前的应对工作是否合适。如此长的检测时间会触发节流，从而扰乱整个工作流程。计划外工作这是您花在最初计划之外的任务上的时间。在标准项目中，UWR（计划外工作率）不应超过25%。高UWR可以暴露因意外错误而浪费的工作，这些错误在工作流的早期显然没有被注意到。除了试图解决工单问题的返工率(RWR)，UWR也是一个重要指标。平均无故障时间(MTTF)平均无故障时间(MTTF)是有缺陷的系统在故障发生前设法运行的平均时间。持续时间从系统出现重大缺陷时开始，到机制最终崩溃时结束。MTTF用于跟踪不可修复的系统组件的状态，并评估它们在出现故障之前可以运行多长时间。该指标还允许DevOps团队在发现故障时维护关键任务系统中使用的组件的状况。应用程序性能在执行部署之前，您应该检查性能故障、未知错误和其他问题。您还可以在部署期间和之后监视整个程序输出的变化。发布后，在一些SQL查询、Web服务器调用和其他程序要求的使用方面看到重大调整是正常的。要检测它们，您可以使用监控工具，它会准确地向您显示变化是什么。平均检测时间(MTTD)当问题确实出现时，轻松识别它们很重要。您不希望发生严重的本地或大型机器故障而不知道。设置强大的应用程序监控可以帮助您轻松发现错误。平均恢复时间(MTTR)MTTR是衡量企业解决问题的效率的成功指标**。**分析业务和客户体验影响的能力提供了充分理解和确定优先级所需的视角。MTTR计算从故障到解决的总响应时间，并提供有关客户是否失去控制、经历延迟或放弃系统的信息。提高MTTR可以减少这些问题的影响，从而保持用户的幸福感。通过安装实用的应用程序管理工具快速检测问题和轻松实施补丁对于减少MTTR至关重要。提前期衡量工作流程和效率的一个重要指标是项目从概念到实施所需的估计平均时间。交货时间短表明团队灵活且反应迅速，可以快速响应反馈。与DevOps相关的敏捷方法可以为框架改进提供快速处理时间，使企业能够满足消费者需求并关注不断变化的趋势。您可以使用Jira和Trello等工具来有效地捕获交货时间。变更质量由于DevOps涉及频繁变更，您必须测量部署之间的变更率以支持部署频率数。最终目标应该是专注于进行有意义的改进，以减少不便并带来更流畅的体验。对于每个部署，监控更改量可以提供更精确的开发情况。您可以从GitHub、Bitbucket和Jira等工具中获取此信息。客户反馈积极的客户体验对于产品的生存至关重要。满意的客户和良好的客户服务会导致销售额增加。这就是为什么客户票表明客户满意度水平，反映您的DevOps流程的质量。数字越低，服务越好。总结DevOps的目的是促进开发和运营团队之间的协调和协作，以支持应用程序的快速执行，同时最大限度地减少对最终用户体验产生负面影响的中断、延迟和问题。这取决于您的市场的具体关注点，并且需要选择特定的DevOps指标进行跟踪。选择适当的成功指标进行监控将有助于指导与开发和技术相关的战略决策，同时支持当前DevOps活动的执行。
