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

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

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

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 value stream (from: Lean Enterprise, p.139)

DevOps value stream (from: Lean Enterprise, p.139)

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

  1. 前置時間 (lead time)。

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

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

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

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

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

將 20% 時間用於創造用戶不可見的正面價值

將 20% 時間用於創造用戶不可見的正面價值

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

高績效組織

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

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

高績效組織的 SDO 效能指標

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

均衡感

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

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

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

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


  1. SEI 提出的 DevOps 操作型定義,可視為一種狹義的 DevOps 定義。詳見〈一句話囊括 DevOps 的目標〉一文。 ↩︎

  2. 返工指標 (percent complete and accuracy),在 The DevOps Handbook 書中寫成 %C/A 符號,但在更廣大的 lean 社群中更常用 %C&A 符號(像 TKMG 維護的 Lean 術語表)。個人認為,後者比較妥當。 ↩︎

  3. 這份年度報告,也有簡體中文譯版:〈2018 全球 DevOps 现状报告〉。 ↩︎