（上市時間）。
即使在週末，他也會考慮指標：「那如果我測量時間呢？ 它會給我什麼？
事實上，時間知識能帶來什麼？ 假設交貨需要 5 天。 那麼，下一步是什麼？ 是好還是壞？ 即使這很糟糕，你也需要以某種方式減少這個時間。 但如何呢？
這些想法一直縈繞在他的心頭，但他卻沒有找到解決方法。
伊凡明白他已經觸及了本質。 他之前見過的無數指標圖表早就讓他相信標準方法行不通，並且如果他簡單地繪製（），這將沒有任何用處。
怎樣成為？…
公制就像普通的木尺。 在它的幫助下進行的測量無法說明原因， 為什麼 被測量的物體的長度正是她所顯示的長度。 標尺只會顯示其尺寸，僅此而已。 她不是點金石，而只是一塊用來測量的木板。
他最喜歡的作家哈里·哈里森的“不銹鋼老鼠”總是說：一個想法必須到達大腦的最底層並躺在那裡，所以在痛苦了幾天無果後，伊万決定承擔另一個任務.. ....
幾天后，在閱讀一篇有關線上商店的文章時，伊凡突然意識到，線上商店收到的金額取決於網站訪客的行為方式。 正是他們，訪客/顧客，為商店提供了資金，也是資金的來源。 商店收到的現金底線受到顧客行為變化的影響，而不是其他因素。
事實證明，為了改變測量值，有必要影響形成該值的人，即要改變一個網上商店的金額，就需要影響這家商店的顧客的行為，而要改變DevOps中的交付時間，就需要影響這次「創造」的團隊，即： 在他們的工作中使用 DevOps。
Ivan 意識到 DevOps 指標根本不應該用圖表來表示。 他們必須代表自己 搜尋工具 決定最終交付時間的「傑出」團隊。
伊凡認為，沒有任何指標可以顯示這個或那個團隊花了很長時間來交付分發的原因，因為實際上可能有一百萬人和一輛小推車，而且他們很可能不是技術性的，而是組織性的。 那些。 你從指標中得到的最多的是展示團隊和他們的結果，然後你仍然必須用腳跟隨這些團隊並找出他們的問題所在。
另一方面，伊凡的公司有一個標準，要求所有團隊在多個工作台上測試組件。 在前一個看台完成之前，團隊無法移動到下一個看台。 事實證明，如果我們將 DevOps 流程想像為一系列經過看台的序列，那麼指標就可以顯示團隊在這些看台上花費的時間。 了解了團隊的立場和時間，就可以與他們更具體地討論原因。
Ivan 毫不猶豫地拿起電話，撥通了一位深諳 DevOps 底細的人的號碼：
— 丹尼斯，請告訴我，是否有可能以某種方式了解球隊已經通過了這個或那個看台？
- 當然。 如果建置已在工作台上成功推出（通過測試），我們的 Jenkins 將丟棄該標誌。
- 極好的。 什麼是旗幟？
- 這是一個常規文字文件，如“stand_OK”或“stand_FAIL”，表示程序集通過或未通過測試。 嗯，你明白了，對吧？
- 我猜是。 它是否寫入存儲庫中程序集所在的相同資料夾？
- 是的
— 若組件未通過測試台會發生什麼狀況？ 我需要重新建構嗎？
- 是的
- 嗯，好的，謝謝。 還有一個問題：我是否正確理解我可以使用旗幟的創建日期作為展位的日期？
- 絕對地！
- 極好的！
伊凡受到啟發，掛斷了電話，意識到一切都已就位。 知道建立文件的創建日期和旗幟的創建日期，就可以精確到秒地計算團隊在每個看台上花費的時間，並了解他們在哪裡花費最多的時間。
“了解最多的時間花在哪裡，我們將確定團隊，去找他們並深入研究問題。” 伊万笑了。
明天，他為自己設定的任務是繪製所繪製系統的架構草圖。
待續...
來源： www.habr.com