说实话，伊万经常嘲笑监控部门同事的无用功。 他们付出了巨大的努力来实现公司管理层要求他们实现的指标。 他们太忙了，不想让别人做任何事。
但这对于管理层来说还不够 - 他们不断订购越来越多的新指标，很快就停止使用以前所做的事情。
最近，大家都在谈论LeadTime——业务功能交付的时间。 该指标显示了一个疯狂的数字——完成一项任务需要 200 天。 每个人都欢呼雀跃，并向天空举起双手！
一段时间后，噪音逐渐平息，管理层接到命令创建另一个指标。
伊万完全清楚，新的衡量标准也会悄然消失在黑暗的角落。
事实上，伊万想，知道这个数字并不能告诉任何人任何事情。 200天或2天——没有区别，因为无法通过数字确定原因并了解是好是坏。
这是一个典型的度量陷阱：似乎一个新的度量将讲述存在的本质并解释一些秘密。 每个人都对此抱有很大的希望，但由于某种原因，什么都没有发生。 是的，因为秘密不应该在指标中找到！
对于伊万来说，这已经是过去的阶段了。 他明白 进行测量，所有的秘密都必须在 ， IE。 是这个度量形成了。
对于在线商店来说，影响的对象将是带来资金的客户，而对于 DevOps 来说，影响的对象将是使用管道创建和推出发行版的团队。
有一天，坐在大厅里一张舒适的椅子上，Ivan 决定仔细思考他希望如何查看 DevOps 指标，同时考虑到影响的对象是团队这一事实。
DevOps 指标的目的
显然，每个人都希望缩短交货时间。 200天当然是不行的。
但这是个问题，怎么办？
该公司拥有数百个团队，每天有数千个发行版通过 DevOps 管道。 实际交货时间将显示为分布。 每个团队都会有自己的时间和自己的特点。 你怎么能在这乱七八糟的东西中找到任何东西呢？
答案自然而然地出现了——我们需要找到问题团队，弄清楚他们发生了什么以及为什么花了这么长时间，并向“好”团队学习如何快速完成所有事情。 为此，您需要衡量团队在每个 DevOps 站点上花费的时间：
“该系统的目的是根据球队通过看台的时间来选择球队，即因此，我们应该获得具有所选时间的命令列表，而不是数字。
如果我们知道看台上总共花费了多少时间以及看台之间的停机时间花费了多少时间，我们就可以找到这些团队，给他们打电话，更详细地了解原因并消除他们，”伊万想。
如何计算 DevOps 的交付时间
为了计算它，有必要深入研究 DevOps 流程及其本质。
该公司使用的系统数量有限，只能从这些系统获取信息，而无法从其他地方获取信息。
公司中的所有任务都在 Jira 中注册。 当一个任务被执行时，会为其创建一个分支，并且在执行后，会向 BitBucket 和 Pull Request 进行提交。 当 PR（拉取请求）被接受时，会自动创建一个发行版并将其存储在 Nexus 存储库中。
接下来，使用 Jenkins 在多个站点上部署该发行版，以检查部署的正确性、自动和手动测试：
伊万描述了可以从哪些系统获取哪些信息来计算看台上的时间：
- 来自 Nexus – 发行版创建时间以及包含命令代码的文件夹名称
- 来自 Jenkins – 每个作业的开始时间、持续时间和结果、站名称（在作业参数中）、阶段（作业步骤）、链接到 Nexus 中的分布。
- Ivan 决定不将 Jira 和 BitBucket 纳入管道中，因为…… 它们更多地与开发阶段相关，而不是与在展台上推出成品发行版相关。
根据现有信息，绘制了下图：
了解创建发行版需要多长时间以及每个发行版花费了多少时间，您可以轻松计算出整个 DevOps 管道（完整周期）的总成本。
以下是 Ivan 最终得出的 DevOps 指标：
- 创建的发行版数量
- “来到”展位并“通过”展位的发行份额
- 停留时间（停留周期）
- 完整周期（所有支架的总时间）
- 工作期限
- 展位之间的停机时间
- 同一展位上作业启动之间的停机时间
一方面，这些指标在时间方面很好地描述了 DevOps 管道的特征，另一方面，它们被认为非常简单。
伊万对出色的工作感到满意，做了演示并向管理层进行了介绍。
他回来时脸色阴沉，双手低垂。
“这真是一场惨败，兄弟，”这位讽刺的同事微笑着……
阅读文章中的更多内容““。
来源： habr.com