自从Ivan首次考虑DevOps指标以来，已经过去了一周，意识到他们需要在他们的帮助下管理产品交付时间 （上市时间）。
即使在周末，他仍在思考指标：“那，我该如何测量时间？ 它会给我什么？”
确实，时间知识会带来什么？ 假设交货需要5天。 那接下来呢？ 是好是坏？ 即使这很糟糕，您也需要以某种方式减少此时间。 但是如何？
这些想法没有使他休息，但没有解决办法。
伊万知道他已经达到了本质。 他很久以前见过无数的指标图，很久以前就使他相信标准方法是行不通的，而且，如果您仅构建一个图（
甚至是同类 ），就没有任何意义。
怎么样？...
公制就像普通的木尺。 在其帮助下进行的测量不会告诉您被测物体恰好显示其长度的原因。 该行将仅显示其大小，仅此而已。 它不是哲学家的石头，而仅仅是被测量的木板。
他心爱的作家哈里·哈里森（Harry Harrison）的“不锈钢老鼠”总是说：这种想法应该触及大脑的深处，然后躺在那里，所以伊凡（Ivan）决定再做几天又没有结果的任务...
几天后，Ivan读了一篇有关在线商店的文章，突然意识到，在线商店收到的款项取决于网站访问者的行为。 他们（访客/顾客）将钱财交给商店，是他们的货源。 商店收到的现金总量受客户行为变化的影响，而不受其他因素的影响。
事实证明，为了改变测量值，有必要影响那些形成该值的人。 要更改在线商店必须影响该商店客户行为的金额，并更改DevOps中的交货时间，就必须影响“创造”该时间的团队，即 在他们的工作中使用DevOps。
Ivan意识到DevOps指标根本不应该代表图形。 他们应该成为
寻找构成最终交付时间的“杰出”团队的
工具 。
Ivan认为，没有任何度量标准能够显示该团队长期以来一直提供该分发软件的原因，因为实际上可能有100万个小车，而且它们可能不是技术上的，而是组织上的。 即 您可以期望从度量标准中获得的最大收益是显示团队及其结果，然后您仍然必须前往这些团队并找出发生了什么情况。
另一方面，伊凡（Ivan）的公司有一项标准，规定所有团队必须在几个展台上检查组装。 在上一个摊位完成之前，团队无法移动到下一个摊位。 事实证明，如果您将DevOps流程想象为一系列经过的机架，那么指标可以显示团队在这些机架上花费的时间。 了解了团队的立场和时间，可以更具体地与她谈谈原因。
Ivan毫不犹豫地拿起电话，拨了一个熟悉DevOps内部的人的电话号码：
-丹尼斯，请告诉我，是否可能以某种方式了解球队通过了这个或那个立场？
-当然了 如果组件已成功在架子上铺开（通过测试），我们的詹金斯便会丢下旗帜。
-超级 什么是国旗？
-这是类型为“ stand_OK”或“ stand_FAIL”的常规文本文件，表示组件已通过或未通过支架。 好吧，明白了吧？
-原则上可以。 是否将其写入存储库中的同一文件夹，程序集在哪里？
-是的
-如果装配没有通过支架，将会发生什么？ 您需要重新组装吗？
-是的
-好的，谢谢。 另一个问题是：我是否正确理解我可以将标志创建日期用作展位通过的日期？
-绝对！
-超级！
受到鼓舞，伊万放下电话，意识到一切都准备就绪。 知道装配文件的创建日期和标志的创建日期，就可以精确到一秒计算出团队在每个展位上花费的时间，并了解他们在哪里花费最多的时间。
“了解最耗时的地方，我们将逐点找到团队，去研究他们并找出问题。” 伊万笑了。
对于明天，他为自己设定了素描所绘制系统架构的任务。
待续...