DevOps 的價值與指標

看完〈敏捷的價值與指標〉之後，很自然的會進一步追問：「那麼，什麼才是 DevOps 圈子所認定的價值，以及對應的指標，尤其是領先指標？」

這問題其實比較容易回答。畢竟，相較於兄弟領域 agile，控制與監管，原本就是 DevOps 不可分割的一部分。

再者，DevOps 的價值主張也非常明確具體。根據 SEI 提出的 DevOps 操作型定義：¹

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.

因此，時間與品質，就是 DevOps 所認定的價值。

剩下來的疑問就是：指標？

來看看兩份經典的說法吧。

技術價值流

DevOps 巨著 The DevOps Handbook 第一章，定義技術價值流 (technology value stream) 為：「把業務構想轉化為向客戶交付價值的、由技術驅動的服務所需要的流程。」

價值流始於工程師（包括開發、QA、IT 維運和資訊安全人員）向版本控制系統提交了一個變更，止於變更成功地在生產環境中運行，為客戶提供價值，並產生有效的反饋和監控資訊。

由此觀之，DevOps 的指標，必定會緊扣在技術價值流的環節身上。

此書第一章，根據精實原則，提出三項 DevOps 衡量指標：

1. 前置時間 (lead time)。

2. 處理時間 (process time)，以及所佔的比例。

3. 返工指標 (percent complete and accurate)。²

此書第六章，進一步建議要合理設置流程改進的優先級：

為了積極管理技術債務，要確保至少把 20% 的開發和維運時間投入到重構、自動化工作、架構優化以及非功能需求上。

如果組織不願意支付這「20% 的税」，那麼技術債務將會最終惡化到靠近所有可用資源的程度。

請思考一下，這些算是領先指標，還是落後指標？與「賺錢」之間有強烈的因果關係嗎？

高績效組織

DevOps 年度報告一直是 DevOps 領域的重頭戲。在 2018 年的報告 Accelerate: State of DevOps 2018 中 ³，從全球近兩千位專業人士的調查中，歸納出五個關鍵的軟體交付與維運效能 (software delivery and operational performance; SDO performance) 層面，以及對應的指標：

1. 部署頻率 (deployment frequency)
2. 變更的前置時間 (change lead time)
3. 服務恢復時間 (MTTR)
4. 變更失敗率 (change fail rate)
5. 可用性 (availability)

請思考一下，這些算是領先指標，還是落後指標？與「賺錢」之間有強烈的因果關係嗎？

均衡感

和敏捷一樣，DevOps 也在追求一種巧妙的均衡感。不僅著眼於百米衝刺的短期成效，更著眼於馬拉松的長期績效。

一言以蔽之：在團隊中，如果看不到這種均衡感，那麼，鐵定不是 DevOps。

所以，在談要不要 DevOps 之前，務必誠實自問：這種均衡感，是你想追求的嗎？

若回答「是」，再試著找出這種均衡感的領先指標吧。