（上市时间）。
即使在周末，他也会考虑指标：“那如果我测量时间呢？ 它会给我什么？
事实上，时间知识能带来什么？ 假设交货需要 5 天。 那么，下一步是什么？ 是好还是坏？ 即使这很糟糕，你也需要以某种方式减少这个时间。 但如何呢？
这些想法一直萦绕在他的心头，但他却没有找到解决办法。
伊万明白他已经触及了本质。 他之前见过的无数指标图表早就让他相信标准方法行不通，并且如果他简单地绘制（），这将没有任何用处。
怎样成为？…
公制就像普通的木尺。 在它的帮助下进行的测量无法说明原因， 为什么 被测量的物体的长度正是她显示的长度。 标尺只会显示其尺寸，仅此而已。 她不是点金石，而只是一块用来测量的木板。
他最喜欢的作家哈里·哈里森的“不锈钢老鼠”总是说：一个想法必须到达大脑的最底层并躺在那里，所以在痛苦了几天无果后，伊万决定承担另一个任务......
几天后，在阅读一篇有关在线商店的文章时，伊万突然意识到，在线商店收到的金额取决于网站访问者的行为方式。 正是他们，访客/顾客，为商店提供了资金，也是资金的来源。 商店收到的现金底线受到顾客行为变化的影响，而不是其他因素。
事实证明，为了改变测量值，有必要影响形成该值的人，即要改变一个网上商店的金额，就需要影响这家商店的顾客的行为，而要改变DevOps中的交付时间，就需要影响这次“创造”的团队，即： 在他们的工作中使用 DevOps。
Ivan 意识到 DevOps 指标根本不应该用图表来表示。 他们必须代表自己 搜索工具 决定最终交付时间的“杰出”团队。
伊万认为，没有任何指标可以显示这个或那个团队花了很长时间来交付分发的原因，因为实际上可能有一百万人和一辆小推车，而且他们很可能不是技术性的，而是组织性的。 那些。 你从指标中得到的最多的就是展示团队和他们的结果，然后你仍然必须用脚跟随这些团队并找出他们的问题所在。
另一方面，伊万的公司有一个标准，要求所有团队在多个工作台上测试组件。 在前一个看台完成之前，团队无法移动到下一个看台。 事实证明，如果我们将 DevOps 流程想象为一系列经过看台的序列，那么指标就可以显示团队在这些看台上花费的时间。 了解了团队的立场和时间，就可以与他们更具体地讨论原因。
Ivan 毫不犹豫地拿起电话，拨通了一位深谙 DevOps 底细的人的号码：
— 丹尼斯，请告诉我，是否有可能以某种方式了解球队已经通过了这个或那个看台？
- 当然。 如果构建已在工作台上成功推出（通过测试），我们的 Jenkins 将丢弃该标志。
- 极好的。 什么是旗帜？
- 这是一个常规文本文件，如“stand_OK”或“stand_FAIL”，表示程序集通过或未通过测试。 嗯，你明白了，对吧？
- 我猜是。 它是否写入存储库中程序集所在的同一文件夹？
- 是的
— 如果组件未通过测试台会发生什么情况？ 我需要重新构建吗？
- 是的
- 嗯，好的，谢谢。 还有一个问题：我是否正确理解我可以使用旗帜的创建日期作为展位的日期？
- 绝对地！
- 极好的！
伊万受到启发，挂断了电话，意识到一切都已就位。 知道构建文件的创建日期和旗帜的创建日期，就可以精确到秒地计算团队在每个看台上花费的时间，并了解他们在哪里花费最多的时间。
“了解最多的时间花在哪里，我们将确定团队，去找他们并深入研究问题。” 伊万笑了。
明天，他给自己设定的任务是绘制所绘制系统的架构草图。
待续...
来源： habr.com