本章介紹 Lean Manufacturing 的基礎理論，以及 The Three Ways – 所有可觀察到的 DevOps 行為與模式都可由此推導而出。

DevOps 簡史#

DevOps 的技術、架構與文化實踐，代表了多個哲學與管理運動的匯流。DevOps 是將實體製造與領導力領域中最受信賴的原則應用於 IT 價值流的成果，汲取自以下知識體系：

  • Lean 與 Theory of Constraints（約束理論）
  • Toyota Production System（豐田生產系統）
  • Resilience Engineering（韌性工程）
  • Learning Organizations（學習型組織）
  • Safety Culture（安全文化）
  • High-trust Management Models（高信任管理模型）

Lean 運動#

Lean 的核心信念包括：製造前置時間（manufacturing lead time）是品質、客戶滿意度和員工幸福感的最佳預測指標，而小批次工作是縮短前置時間的關鍵。

Lean 原則聚焦於透過系統思維為客戶創造價值：

  • 建立恆常的目的意識（constancy of purpose）
  • 擁抱科學思維
  • 建立流動與拉動（flow and pull），而非推動（push）
  • 在源頭確保品質
  • 以謙遜領導，尊重每個人

Agile 宣言#

2001 年，十七位軟體開發界的領導者創建了 Agile Manifesto，強調：

  • 頻繁交付可運作的軟體（數週而非數月）
  • 小批次、增量式發布取代大型瀑布式發布
  • 小型、自我激勵的團隊在高信任管理模式下工作

Agile Infrastructure 與 Velocity 運動#

  • 2008 年：Patrick Debois 與 Andrew Schafer 在 Agile 大會上倡議將 Agile 原則應用於基礎設施
  • 2009 年：John Allspaw 與 Paul Hammond 在 Velocity 大會發表經典演講 “10 Deploys per Day: Dev and Ops Cooperation at Flickr”
  • 2009 年：Patrick Debois 創辦第一屆 DevOpsDays，「DevOps」一詞由此誕生

Continuous Delivery 運動#

Jez Humble 與 David Farley 將持續建構、測試與整合的概念擴展為 Continuous Delivery，定義了 deployment pipeline（部署流水線）的角色：確保程式碼與基礎設施始終處於可部署狀態，所有提交到主幹的程式碼都能安全地部署到生產環境。

Toyota Kata#

Mike Rother 在 2009 年提出 Improvement Kata（改善型）的概念：每個組織都有工作慣例，而改善型要求為每日的改善工作建立結構，因為持續的日常實踐才能改善結果。不斷設定目標狀態、每週檢視成果、持續改善日常工作，正是 Toyota 的指導原則。

製造業價值流#

Value Stream（價值流）是 Lean 的基本概念之一，定義為「組織為回應客戶需求所進行的一系列活動」。

在製造業中，價值流容易觀察：從收到客戶訂單、原料投入產線開始。為了實現快速且可預測的前置時間，通常會專注於：

  • 建立平穩均勻的工作流
  • 小批次作業
  • 減少在製品（WIP）
  • 防止返工，避免將缺陷傳遞給下游
  • 持續針對全局目標優化系統

技術價值流#

同樣的原則適用於技術工作。在 DevOps 中，技術價值流定義為：將業務假設轉化為向客戶交付價值的技術服務的過程。

  • 輸入：業務目標、概念、想法或假設
  • 過程：Development 團隊將其轉化為 user stories 與功能規格，實作為程式碼，簽入版本控制，整合測試
  • 輸出：服務在生產環境中運行，為客戶創造價值

價值只有在服務於生產環境中運行時才被創造。我們不僅要確保快速交付，還要確保部署不會造成服務中斷、安全或合規問題。

部署前置時間（Deployment Lead Time）#

本書聚焦於部署前置時間 – 從工程師將變更簽入版本控制開始，到該變更在生產環境中成功運行為止。技術價值流包含兩個階段：

  1. 設計與開發（Design and Development）：類似 Lean Product Development，高度變異、高度不確定
  2. 測試與營運（Testing and Operations）：類似 Lean Manufacturing，追求可預測性與機械化，目標是最小化變異性

Lead Time vs. Process Time#

在 Lean 社群中，衡量價值流績效的兩個關鍵指標：

  • Lead Time（前置時間）：從請求提出到完成交付的時間
  • Process Time（處理時間）：從開始處理到完成的時間（不含排隊等待）

Figure 2: Lead time vs. process time of a deployment operation

因為前置時間是客戶真正感受到的，我們通常將改善重點放在此處。而處理時間佔前置時間的比例，則是衡量效率的重要指標 – 實現快速流動幾乎總是需要減少工作在佇列中等待的時間。

常見情境：部署前置時間長達數月#

在大型、複雜的組織中，尤其是使用緊密耦合的單體應用程式時，部署前置時間常以月計。這時我們會遇到：

  • 整合測試環境稀缺
  • 大量依賴手動測試與多重審批流程
  • 合併所有團隊的變更時才發現什麼都無法運作
  • 修復每個問題需要數天甚至數週

Figure 3: A technology value stream with a deployment lead time of three months

DevOps 理想：部署前置時間以分鐘計#

在 DevOps 理想狀態下，開發者能快速獲得回饋，獨立地實作、整合、驗證程式碼，並將其部署到生產環境。這透過以下方式實現：

  • 持續將小型變更簽入版本控制
  • 執行自動化與探索性測試
  • 模組化、鬆耦合的架構，讓小團隊能高度自主運作

Figure 4: A technology value stream with a lead time of minutes

%C/A – 衡量返工的指標#

技術價值流中第三個關鍵指標是 %C/A（Percent Complete and Accurate，完整且準確百分比）。此指標反映價值流中每個步驟的輸出品質 – 透過詢問下游客戶：收到的工作有多少比例是「可直接使用」的，無需修正、補充遺漏資訊或釐清不清楚的地方。

The Three Ways：DevOps 的核心原則#

The Phoenix Project 將 Three Ways 呈現為所有可觀察到的 DevOps 行為與模式的底層原則。

Figure 5: The Three Ways

The First Way：Flow（流動）#

加速從 Development 到 Operations 再到客戶的工作流動。 為了最大化流動，我們需要：

  • 使工作可見化
  • 縮小批次大小與工作間隔
  • 內建品質，防止缺陷傳遞到下游
  • 持續針對全局目標優化

實踐包含：持續建構、整合、測試與部署；按需建立環境；限制 WIP；建構安全可變更的系統與組織。

The Second Way：Feedback（回饋）#

建立從右到左、快速且持續的回饋流。 透過放大回饋來：

  • 預防問題再次發生，或實現更快的偵測與復原
  • 在源頭創造品質，在需要之處嵌入知識
  • 建立更安全的工作系統，在災難性故障發生前就能發現並修復問題

透過即時發現問題並群聚解決（swarming），我們持續縮短並放大回饋迴路，最大化組織的學習與改善機會。

The Third Way：Continual Learning and Experimentation（持續學習與實驗）#

打造一個具生成性的高信任文化。 支持：

  • 動態、有紀律、科學化的實驗與冒險方法
  • 從成功與失敗中創造組織學習
  • 將局部發現轉化為全局改善
  • 讓每個人都能運用組織的累積集體經驗來工作
Backward The Three Ways The First Way: The Principles of Flow Forward