說實話，伊凡經常嘲笑監控部門同事的無用功。 他們付出了巨大的努力來實現公司管理階層要求他們實現的指標。 他們太忙了，不想讓別人做任何事。
但這對管理階層來說還不夠 - 他們不斷訂購越來越多的新指標，很快就停止使用以前所做的事情。
最近，大家都在談論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 管道的特徵，另一方面，它們被認為非常簡單。
伊凡對出色的工作感到滿意，做了演示並向管理層進行了介紹。
他回來時臉色陰沉，雙手低垂。
「這真是一場慘敗，兄弟，」這位諷刺的同事微笑著…
閱讀文章中的更多內容““。
來源： www.habr.com