您实际想要的 DevOps 指标与您可能在四个重要方面收集的更大的数据集不同。
你如何衡量 DevOps 的成功？谈论 DevOps 工作或云原生基础设施的“指标”，对话往往围绕熟悉的运营和生产力指标展开。正常运行时间。每秒事务数。错误已修复。承诺。可以直接跟踪的熟悉的数据类别，似乎至少与效率、环境健康状况和开发速度的某种组合相关联。
IT 团队通常会检测和记录此类数据——尤其是现在机器学习和其他现代工具可以更轻松地从大型数据集中获取洞察力，无论是用于主动、预测分析还是故障后的根本原因分析。
这不是 DevOps 指标！
但是，这并不能使一切都成为指标！度量标准被恰当地视为数据的关键绩效指标 - 一种对您来说很重要的基本方式的衡量标准。
[您的 DevOps 团队是否以最佳方式组建？请参阅我们的相关文章DevOps 成功：一种新的团队模型出现。]
您实际需要的 DevOps 工作指标与您可能在四个重要方面收集的更大的数据集不同。
1. DevOps 指标不应该太多。拍摄不超过十次，可能越少越好。从您可以衡量的所有可能事物中选择一组指标是一个深思熟虑的选择过程。同时，广撒网。除了可以从计算机系统收集的更明显的运营和开发数据之外，还考虑可以揭示更广泛的组织或流程健康问题的指标。
2. DevOps 指标应反映对您而言重要的内容。你如何定义成功？
正如麻省理工学院信息系统研究中心 (CISR) 所指出的，数字化转型项目涉及两个维度的阶段性变化：客户体验和运营效率。相关指标将根据组织最初选择关注的维度而有所不同。如果是客户体验，那么净推荐值之类的指标可能是合适的。如果是效率，更多以成本为中心的测量将是更好的匹配。
3. DevOps 指标应该以某种方式与业务成果相关联。您可能并不真正关心您的开发人员编写了多少行代码，服务器是否在一夜之间出现硬件故障，或者您的测试覆盖范围有多全面。事实上，您甚至可能并不直接关心网站的响应能力或更新的速度。但您确实关心此类指标与客户放弃购物车或前往竞争对手的程度之间的关联程度。
4. 寻找可追溯的根本原因路径。很容易提出相关的业务指标。他们是你在财报电话会议上谈论的人。但从 DevOps 和云原生基础设施指标的角度来看，需要有一条可追踪的路径来找到运营和开发团队可能影响的根本原因。因此，选择适当的度量标准是一种平衡行为，既要足够高以对业务结果产生或多或少的直接影响，又要在 IT 的职权范围内，他们可以采取直接行动来改善结果。
更好的 DevOps 指标
以下是可能与组织相关的 DevOps 指标的三个示例。
客户票数是整体客户满意度的合理代表，这反过来又会强烈影响更高级别（和高度重视）的衡量标准，例如净推荐值、客户向他人推荐公司产品或服务的意愿。同时，往往会因为与应用程序和基础设施相关的特定缺陷而提交罚单。
诸如失败部署百分比之类的衡量标准与客户看到的任何内容都没有那么直接的联系。但它表明流程问题可能导致明显的失败或只是浪费精力和时间。也许缺乏测试覆盖率，或者只是构建和部署管道存在一些系统性问题。
或者你的开发团队的工作满意度如何？当我们讨论 DevOps 时，我们经常谈论文化。也许有一个或两个指标与协作的有效性或您的培训和职业道路的有效性相关联是个好主意。
当心 DevOps 反模式
一个重要的警告：当您选择指标时，请注意反模式——鼓励非生产性或其他负面行为或根本没有意义的指标。
正如行为经济学的创始人之一丹尼尔·艾瑞利 (Daniel Ariely) 所指出的：“人类根据他们所反对的指标来调整行为。你衡量的任何东西都会促使一个人优化他在该指标上的分数。你测量的就是你会得到的。时期。”个人生产力测量可能会阻碍团队内部和团队之间的协作。简单的输出度量（例如修复的错误数量）可能与对代码质量或交付给客户的价值的更有意义的评估没有很好的相关性。
也许更常见的是收集 DevOps 指标，因为它们很容易收集，但实际上没有任何意义。客户看不到的故障可能表明存在流程问题——或者它们可能只是表明服务按设计执行。
无论如何，收集数据。存储它并分析它。越来越多地这是默认设置。但是，您选择用来绘制路径和衡量 DevOps 成功的指标应该涉及深思熟虑的决定。