昨天我們聊到 DevOps 成熟度模型，並談到它雖然能作為一項參考與學習的資源，但也是有人對成熟度模型持不同的意見。

那麼除了成熟度模型，我們還能用什麼評量 DevOps 的進展與成效呢？

現在最有名的指標即是做過多年 DevOps 調查的 DORA 所出品的 DORA metrics ！

（擷取自網頁。）

（在 2021 新增加了一項 Metric - reliability，但目前還太新，因此尚未被廣泛的討論。截圖來自網頁。）

DORA Metrics 現在應該是全球最廣為人知與熱門的 DevOps Metrics，畢竟 DORA 被 Google 給買了，等於出現了一個大金主，替 DORA 多年以來辛苦做的 DevOps 調查與分析直接給予了高度的肯定。

網路上已經有很多專家與顧問公司或供應商在解釋 DORA Metrics，因此這裡就不再重複說明它的內容了，我們還是回來聊一聊該如何看待 DORA Metrics 吧！

乍看 DORA Metrics 的內容，我們會發現好像與「成熟度模型」有些相似，一樣都是列出了幾個項目進行評比，然後與全球或是同業的數據進行比較，藉此瞭解自己的團隊是落在哪個位置。

再來是這幾個評比項目，都非常的「數據」，都是一些可以直接用數字呈現的 Metric，並不會有模糊的評比空間（例如：你覺得你們團隊的溝通順暢嗎？），舉例來說第一項 Deployment Frequency（部署頻率），如果團隊就是每月只發佈一次程式，那就是能得到每月一次這個明確的數字。

這樣的 Metrics 真的能夠反映團隊的 DevOps 進展與成效嗎？以及這樣的 Metrics 真的能適用在不同的企業組織嗎？而且 DevOps 不是還包含了「文化」這一層面的議題嗎？

因此還是那句老話「役物而不役於物」，如果你真的想要使用 DORA Metrics 但又不想尋找國外貴貴的顧問公司，那麼同樣是 DORA 那些專家出品的好書《Accelerate》，恐怕會是你首先需要詳讀的書籍，並再加上每一年的 The state of DevOps Report，總之先去了解這群專家到底是怎麼做出這些研究與 Metrics 的，以及他們是如何看待其中的文化議題。

（翻拍自 《Accelerate》中文版 P.212。）

接著開始收集你自己的數據吧！如果不知道怎麼收集！？那⋯⋯那⋯⋯那就改用 GitLab 吧！（誤）XD

上面其實也不是真的「誤」，因為 GitLab 也確實將 DORA Metrics 放 GitLab 的功能當中，因此如果你的團隊是使用 GitLab 完成從開發到維運的所有工作，也都有按著 GitLab 規定的方式使用，那麼 GitLab 還真的是可以幫你計算出你團隊的 DORA Metrics。

（GitLab 官方部落格所展示 GitLab 能夠分析出 DORA Metrics。）

因此同理，其實你想要透過「工具」去收集 DORA Metrics 現在是做得到的，只是各家供應商或隨著你使用的 DevOps 工具不同，你需要費的功夫不同。

（在 GitHub 上有一個 Topic 是 dora-metrics）

就算你還不打算精準的計算自家的 Metrics，也不妨先簡單的填一下這個 Quick Check，先憑感覺的評比一下自家團隊是落在哪個水平吧。當然還是要提醒一下，這些評比結果都是參考用的資訊，跟成熟度模型一樣，並非說你一定達到某個等級才是正確的，而是要根據這些資訊去釐清自己團隊的現況與能力邊界，然後找出你的持續改善之路。

最後是 DORA 除了提供前述的 Metrics 之外，他們還有列出非常多項組織在實踐 DevOps 時所需的能力（Capability），並且有一張動態的圖表，這些都是在評量 DevOps 進展與成效時，非常重要的參考資訊。

（截圖自DORA 官網。一覽能力最終會帶來哪些結果。）

（截圖自DORA 官網。分為四個面向，分別列出多項重要的能力。）

今年在 DevOpsDays Taipei 2022，iThome 的副總編輯王宏仁，以及台積電的講者都有分享到 DORA Metric 的運用案例，我想這些應該多少能夠應證 DORA Metrics 是有其值得參考之處。

（截圖來自 DevOpsDays Taipei FB粉專照片，貼文提到 國外有企業參考 DORA 指標，並根據自己的狀況做了一些調整，像是多一個指標是「新人上手時間」。）

連續假期大家玩得愉快嗎？現在是 10/11 的 00:22，幾個小時後又是上班日，所以今天的 DevOps 輕鬆聊，就只分享到這裡嘍！我們明天見～