坦率地说，伊万经常对监控部门同事的徒劳努力大笑。 他们付出了巨大的努力来实施公司管理层订购的指标。 他们太忙了，不想做其他任何事情。
而且管理还不够-它不断订购越来越多的指标，很快就停止使用以前所做的事情。
最近，每个人都在谈论LeadTime-业务功能的交付时间。 该指标显示了一个疯狂的数字-完成一项任务需要200天。 每个人都吟，,吟，举手向天堂！
一段时间后，噪音逐渐平息，管理层下达命令以建立另一个指标。
伊万十分清楚，新指标也将在一个黑暗的角落悄然消亡。
确实，伊万沉思着，知道这个数字对任何人都说不了什么。 200天或2天-没有区别，因为无法通过数字确定原因并了解其好坏。
这是一个典型的指标陷阱：新指标似乎可以说明存在的本质并解释一些秘密。 每个人都希望如此，但是由于某种原因什么也没发生。 是的，因为绝不能在度量标准中寻求秘密！
对于Ivan来说，这是一个过去的阶段。 他了解
度量标准只是用于
度量的普通木尺 ，并且所有秘密都必须以
影响为
目标 ，即 以此度量形式。
对于在线商店而言，影响力的对象将是为其带来财富的客户，对于DevOps，则是使用管道创建和推出发行版的团队。
有一次，伊万坐在舒适的扶手椅上坐在大厅里，决定考虑团队是影响对象这一事实，仔细考虑他想如何查看DevOps指标。
目标DevOps指标
显然，每个人都希望减少交货时间。 200天当然是徒劳的。
但是，这就是问题吗？
该公司拥有数百个团队，每天都有数千个发行版通过DevOps渠道。 实际交货时间将看起来像分配。 每个团队都有自己的时间和特点。 您怎么能至少在这团混乱中找到东西？
答案自然而然地出现了-您需要找到有问题的团队，弄清楚他们发生了什么，为什么这么久，然后学习如何快速与“好”团队一起做所有事情。 为此，您需要测量每个DevOps展台上的团队所花费的时间：
“该系统的目的是根据展位通过的时间来选择球队，即 最后，我们应该获得具有所选时间的团队列表，而不是数字。
“如果我们找出一个机架总共花费了多少时间，以及每个机架之间的停机时间所花费的时间，我们可以找到团队，打电话给他们，更详细地了解原因并消除它们，”伊万认为。
如何计算DevOps的交货时间
要计数，有必要深入研究DevOps流程及其本质。
该公司使用数量有限的系统，并且只能从它们那里获得信息，而在其他任何地方都无法获得。
公司的所有任务都在吉拉（Jira）注册。 当任务开始工作时，会为其创建早午餐，并在实现后对BitBucket和Pull Request进行提交。 接受PR（Pull Request）时，将自动创建一个分发工具包，并将其存储在Nexus存储库中。
此外，使用詹金斯（Jenkins）在多个机架上推出了发行版，以检查滚动，自动和手动测试的正确性：
Ivan绘制了从哪些系统可以获取哪些信息来计算展位时间：
- 从Nexus-发布创建时间和包含命令代码的文件夹的名称
- 从詹金斯（Jenkins）-开始时间，每个工作的持续时间和结果，工作台名称（在工作参数中），阶段（工作步骤）以及指向Nexus中发行版的链接。
- Ivan决定不在管道中包括Jira和BitBucket，因为 它们与开发阶段更相关，而不是与展台周围的最终发行量相关。
根据现有信息，得出以下方案：
知道创建了多少时间分配以及在每个分配上花费了多少时间，您可以轻松地计算出整个DevOps管道（整个周期）的总成本。
结果是来自Ivan的DevOps指标：
- 创建的发行数量
- “登录”到展台并“粘贴”到展台的分配份额
- 在展位上花费的时间（展位周期）
- 全周期（所有展台的总时间）
- 工作时间
- 展台之间简单
- 在一个支架上启动作业之间就很简单
一方面，指标在时间方面很好地表征了DevOps管道，另一方面，它们被认为非常简单。
对出色的工作感到满意，Ivan作了介绍，然后将其介绍给管理层。
他皱着眉头，双手放下。
“这真是惨败，兄弟，”讽刺的同事笑了。
继续阅读文章“ 快速的结果如何帮助Ivan” 。