任何嘗試「做 DevOps」的組織，早晚都會購買 Jenkins、採用 Kubernetes 並撰寫 Terraform，但部署風險依然很高、團隊依然超載，MTTR（平均修復時間）也毫無進展。正確的工具無法解決底層架構與文化錯誤的問題。這正是 The Five Ideals（五項理想）的出發點：一個概念框架，將 DevOps 從「工具套件」區分開來，並真正視其為一種組織工作、團隊與系統的不同方式。

概念起源

五項理想由 Gene Kim 在《The Unicorn Project》（2019）中提出，這本技術小說是《The Phoenix Project》（2013）的概念續作，而後者普及了 DevOps 的「三條路徑」（流程、回饋與持續學習）。《The Phoenix Project》從營運角度看待 DevOps 轉型，《The Unicorn Project》則從開發角度敘述同一故事，而五項理想正是源於一位開發人員試圖對過度耦合的遺留系統進行簡單變更時所產生的挫折。

此框架並不取代三條路徑，而是將其細化為更具體的原則，方便用作評估團隊流程、架構與文化的檢核清單。

五項理想摘要

# 理想 一句話說明
1 局部性與簡潔性 團隊無需依賴數十個其他團隊即可變更系統
2 專注、流程與喜悅 工作得以在無頻繁中斷上下文的情況下進行
3 日常工作的改善 保留時間用於修復流程，而非僅交付成果
4 心理安全 犯錯與通報錯誤不會受到懲罰
5 以客戶為中心 所有技術決策均以為使用者創造的價值來評估

1. 局部性與簡潔性

Locality and Simplicity

此理想描述團隊能在無需協調、談判或等待其他團隊的情況下完成變更的程度。一項簡單變更所跨越的服務、團隊與依賴越多，局部性就越低，風險、交付時間與意外破壞的可能性就越大。

設計不良的微服務架構就是典型的問題：它非但沒有降低耦合，有時只是將程式碼耦合轉移到網路層，導致一項業務變更必須觸及五到十個不同服務，每個服務都有各自的團隊、管線與部署時程。

低局部性                          高局部性
─────────────────                   ────────────────
1 項業務變更      →         1 項業務變更
   ↓ 觸及 8 個服務                   ↓ 觸及 1 個服務
   ↓ 5 個團隊參與                    ↓ 1 個團隊參與
   ↓ 3 條部署管線                    ↓ 1 條部署管線
   ↓ 時程：3 週                      ↓ 時程：2 天

Enter fullscreen mode Exit fullscreen mode

實務上，這轉化為具體的架構決策：定義良好的有界上下文（Domain-Driven Design）、平台團隊提供自助式服務而非要求提單，以及在核准技術設計前先問「這項變更需要通知幾個團隊？」的紀律。

2. 專注、流程與喜悅

Focus, Flow, and Joy

工程工作需要進入心流狀態，也就是能從頭到尾解決複雜問題的深度專注。根據《The Unicorn Project》引用的研究，這種狀態平均需要 15 到 20 分鐘才能在一次中斷後達到。如果開發人員每 10 分鐘就被會議、緊急訊息或跨專案上下文切換打斷，就永遠無法進入心流——「整天工作卻毫無產出」的感覺正是這種現象的直接症狀。

此理想在於設計工作環境——不僅是日程，還有系統本身——以保護這種狀態：

  • 減少開發人員執行一項任務所需接觸的系統數量（與理想 1 直接相關）
  • 開發與測試環境能在數分鐘而非數天內啟動，避免因等待而受阻
  • 以自動化部署取代需要全程關注的手動檢查清單
  • 保護無會議的深度工作時段

預期成果不只是生產力，而是字面意義上的「喜悅」：真正從解決問題並看到工作交付給客戶中獲得滿足，而非因官僚程序而感到疲憊。

3. 日常工作的改善

Improvement of Daily Work

Mike Rother 在《Toyota Kata》中以 Gene Kim 直接引用的句子總結此理想：「改善日常工作比做日常工作本身更重要。」在持續交付壓力下的團隊往往接受手動流程與不良工具為「事情本來就是這樣」，從不保留時間修復根本原因，只是一週又一週地滅火。

此理想要求明確且定期地保留時間，用於：

  • 自動化重複的手動任務（例如：仍以手動腳本執行的部署步驟）
  • 重構每週產生摩擦的程式碼或管線片段
  • 調查重複問題的根本原因，而非只是再次繞過 
# 範例：sprint 中保留的技術債務時間區塊，
# 不只是程式碼
sprint_capacity:
  feature_work: 70%
  bugs: 15%
  improvement_of_daily_work: 15%

Enter fullscreen mode Exit fullscreen mode

若無此受保護的時間，團隊就會累積 Gene Kim 所稱的「流程債務」——在營運摩擦中，相當於程式碼中的技術債務。

4. 心理安全

Psychological Safety

此詞由哈佛研究員 Amy Edmondson 提出，並被 Google 的 Project Aristotle 確認為高績效團隊最重要的決定因素。它意味著專業人員可以承認錯誤、質疑資深決策或通報生產問題，而無需擔心遭到報復——這決定了問題是在成本低廉的早期被通報，還是隱瞞到變成重大事故。

此理想在 DevOps 團隊中最相關的實務是無責怪的事後檢討（blameless postmortem）

有責怪的事後檢討 無責怪的事後檢討
「誰在未審核的情況下部署？」 「為什麼管線允許在沒有強制審核的情況下部署？」
重點在懲罰個人 重點在修正系統
類似事故下次會被隱瞞 類似事故下次會立即通報

心理安全並非缺乏品質標準——而是保證當錯誤發生時，它會成為整個團隊的學習機會，而非個人受罰的原因。

5. 以客戶為中心

Customer Focus

最後一項理想是其他所有理想的決勝標準：所有技術決策都必須以為產品使用者創造的價值來評估——而非以解決方案的優雅或團隊的技術偏好來評估。Gene Kim 將任何消耗工程時間卻未為最終客戶產生可感知價值的努力稱為「技術虛榮工作」（vanity engineering work）：僅為了採用更新技術堆疊而重寫穩定服務、最佳化無人使用的路由，或為假設性需求建立抽象層。

以此理想為導向的團隊通常以將技術交付與業務成果連結的指標來衡量自身工作——不僅是正常運行時間與部署速度，還有留存率、滿意度以及客戶感知到價值的時間。

五項理想如何與 DevOps 實務連結

理想 在實務中的呈現
局部性與簡潔性 微服務架構、有界上下文、基礎設施自助服務
專注、流程與喜悅 自動化 CI/CD 管線、短暫的開發環境、減少會議
日常工作的改善 Sprint 保留時間用於自動化與流程債務
心理安全 無責怪的事後檢討、無評判的程式碼審查文化
以客戶為中心 依據業務指標排定優先順序、將 MTTR 降低視為使用者感知可靠性的指標

五項理想同時出現並非巧合：自動化部署管線（理想 2）之所以存在，是因為有人保留時間來建置它（理想 3）；而這段時間只有在架構允許局部變更時（理想 1）才值得投資。這些理想相互強化——在其中一項上有所不足，往往會侵蝕其他理想。

應用五項理想的良好實務

  • 將理想作為架構檢核清單，而非僅作為文化檢核清單——在設計新服務時，詢問它在一項簡單變更中需要多少團隊
  • 衡量中斷，而非僅衡量 velocity——每日上下文切換次數與交付的故事點同樣重要
  • 在規劃中保護日常工作改善的時間，以固定百分比的產能，而非「如果有剩餘時間」
  • 稽核貴公司的事後檢討是否真正無責怪——如果「是誰做的？」這個問題比「為什麼系統允許這樣做？」先出現，心理安全就只存在於紙面上
  • 用理想 5 的問題審查技術待辦項目——如果「這為客戶創造什麼價值？」的答案模糊，就是技術虛榮工作的跡象

結論

五項理想並非附有逐步說明的實施框架，而這正是它們的優勢：它們作為診斷透鏡，用來找出為什麼 DevOps 轉型即使在公司購買了所有正確工具後仍陷入停滯。一個團隊可能擁有 Kubernetes、CI/CD 管線與完整的可觀測性，但如果背後的架構迫使團隊之間高度依賴（理想 1），或害怕犯錯導致問題隱藏到變成事故（理想 4），部署仍然會緩慢且有風險。

在購買下一個工具之前，值得用貴團隊目前的流程對照五項理想：其中哪一項目前最弱，幾乎總是 DevOps 轉型未達預期成果的原因。

參考文獻

  • Kim, Gene. The Unicorn Project (2019) — IT Revolution Press
  • Kim, Gene; Behr, Kevin; Spafford, George. The Phoenix Project (2013) — IT Revolution Press
  • Rother, Mike. Toyota Kata (2009) — McGraw-Hill
  • Edmondson, Amy. The Fearless Organization (2018) — Wiley