DevOps 手冊 The DevOps Handbook

📌 30 秒摘要（Layer 3）

鳳凰專案 用小說講「為什麼」，這本用手冊講「怎麼做」。沿著三步工作法把 DevOps 落地成具體實踐：第一步（流動）→ 建部署管線、持續整合/交付、小批量發布；第二步（回饋）→ 建遙測與監控、讓問題快速浮現；第三步（持續學習）→ 無指責事後檢討、把改善與安全（左移）變成日常。

🗺 心智圖（Canvas）

DevOps手冊

🛠 DevOps 手冊

The DevOps Handbook

工具-價值流圖

🎯 什麼情境該想到我

當你知道「交付太慢」但講不出慢在哪一段，改善資源不知道該投哪裡時。

⚙️ 怎麼用

1. 先找齊人：產品負責人、開發、QA、維運、資安、發布管理、以及有權改動自己那段流程的人。開一場多日工作坊，把他們從日常工作裡抽離。
2. 第一輪只畫高階區塊：不要記錄每個細節。書中的判準是——即使是複雜的價值流，通常也能在幾小時內畫出 5 到 15 個 process block。
3. 每個區塊標三個數字：
   • 前置時間 lead time：從請求發出算到被滿足（客戶感受到的就是這個）
   • 處理時間 process time：從實際開工才起算，不含排隊等待
   • %C/A（完整且正確百分比）：問下游——你收到的東西有多少比例「拿到就能用」，不必補資料、不必澄清、不必更正
4. 把調查火力集中在兩處：工作等待數週甚至數月的地方（拿類生產環境、變更審批、資安審查），以及產生或收到大量返工的地方。
5. 畫出理想化的未來價值流圖當成 target condition，訂一個期限——書中給的是通常 3 到 12 個月。然後對每個假設做實驗、看結果、再迭代。

原文：「Typically, even for complex value streams, groups can create a diagram with five to fifteen process blocks within a few hours.」

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意

• process time / lead time 的比值才是效率指標，但改善重點放在 lead time——因為那才是客戶感受到的。書中的 Nordstrom 例子裡，%C/A 低的根因只是「申請表沒填員工編號」，這種東西不畫圖永遠看不到。

🔗 相關工具

• 工具-找出並管理約束點 —— 接續動作，價值流圖告訴你哪裡慢，約束理論告訴你先修哪一個
• 工具-等待時間與閒置產能 —— 解釋為什麼「每個人都很忙」反而讓 lead time 爆炸
• 工具-三步工作法 —— 上位框架，畫價值流圖是第一步「流動」的起手式
• 工具-把業務目標接到IT風險 —— 把圖上的等待時間翻譯成老闆聽得懂的損失

畫出 5–15 個 process block 每塊標 lead time／process time／%C/A

🚀 從哪開始

工具-部署管線與持續交付

🎯 什麼情境該想到我

當「每次發布都是大工程/要熬夜/容易出錯」，你想讓上線變成頻繁、可靠、無聊的日常時。

⚙️ 怎麼用

1. 版本控管一切：程式碼、設定、環境、基礎設施（IaC）都進 git。
2. 持續整合（CI）：每次提交自動建置 + 跑自動化測試，保持主幹隨時可發布。
3. 建部署管線：一條自動化流水線把「提交 → 測試 → 部署」串起來，一鍵（或自動）到各環境。
4. 小批量、頻繁發布：批量越小，風險越小、出錯越好定位。
5. 降低發布風險：藍綠部署、金絲雀、功能開關（feature flag）、可快速回滾。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 沒有可靠的自動化測試，CD 只是「更快地把 bug 送上線」；測試是前提。

🔗 相關工具

• 工具-三步工作法 —— 上位框架，部署管線是第一步「流動」最具體的基礎建設
• 工具-遙測與監控 —— 必要配套，發布變頻繁之後，出事能否即時看見決定敢不敢繼續快
• 工具-降低在製品WIP —— 互為因果，管線順暢才可能小批量交付，WIP 也才降得下來

工具-低風險發布模式

🎯 什麼情境該想到我

當你「不敢上線」——每次發布都得挑深夜、出事只能硬著頭皮往前修，你想讓發布變成可以隨時做、隨時退的動作時。

⚙️ 怎麼用

1. 先把兩件事拆開（這是所有模式的前提）：
   • 部署 deployment ＝把某個版本裝到某個環境。一次部署可以完全不伴隨任何功能發布。
   • 發布 release ＝讓某功能對全部或一部分客戶可用（例如只開給 5% 的人）。
   • 架構要求：發布功能不應該需要改應用程式碼。
2. 拆開之後責任也拆開：Dev 與 Ops 對「快速頻繁部署的成功」負責，產品負責人對「發布的業務成果」負責。剩下的只有 release risk。
3. 選模式——兩大類：
   • 環境型（通常完全不用改應用程式）：藍綠部署（兩套環境切流量，回滾＝把流量切回去）、金絲雀發布（逐級晉升到越來越關鍵的環境，每級都監控）、叢集免疫系統（指標偏離預期範圍就自動回滾）
   • 應用型（改應用、但更細緻）：功能開關（用組態開關功能，可回滾、可優雅降級、可做 A/B）、黑啟動（功能全部部署但對使用者不可見，用真實生產流量測）
4. 判準：先問「要不要改應用程式」。不想動程式就從環境型下手，藍綠最容易套用到既有系統；需要對「誰看得到」做細緻控制才進到功能開關與黑啟動。
5. 能隨選部署之後，「多快把新功能開給客戶」就變成業務與行銷決策，不再是技術決策——這是這整套做法真正的回報。

原文：「as we become able to deploy on demand, how quickly we expose new functionality to customers becomes a business and marketing decision, not a technical decision.」

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意

• 資料庫是藍綠部署最容易破功的地方。書中偏好的解法是把資料庫變更與應用變更解耦：只做加法變更、絕不變動既有資料庫物件，且應用程式不對「生產環境會是哪個資料庫版本」做任何假設。用「兩個資料庫互切」的做法時，回滾會遺失切換後未遷移的交易。

🔗 相關工具

• 工具-部署管線與持續交付 —— 前提條件，沒有可靠的自動化管線，這些模式無從施展
• 工具-遙測與監控 —— 必要配套，金絲雀與叢集免疫系統都靠指標決定推進還是回滾
• 工具-三步工作法 —— 上位框架，落在第一步「流動」
• 解耦部署與發布 —— 型錄條目，含 Jez Humble 對持續交付與持續部署的正式定義

版本控管一切・主幹開發（每人每天至少 check in 一次） 虛擬安燈繩・不可變基礎設施

① 流動 Flow

工具-遙測與監控

🎯 什麼情境該想到我

當你「總是等使用者回報才知道出事」、上線後對系統健康一無所知時。這是三步工作法第二步（回饋）的核心。

⚙️ 怎麼用

1. 到處埋遙測：在應用、基礎設施、業務層都產生指標、日誌、追蹤（三大支柱）。
2. 監控要涵蓋業務指標，不只 CPU/記憶體——「訂單成功率」比「機器負載」更早反映問題。
3. 建立告警：針對關鍵指標設閾值/異常偵測，讓問題主動找上你。
4. 讓資訊人人可見：儀表板公開，部署、事件都上牆，形成快速回饋迴路。
5. 用資料做決策（A/B、假說驗證），而非靠猜。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 告警太多＝沒有告警（狼來了）；聚焦真正可行動的訊號。

🔗 相關工具

• 工具-部署管線與持續交付 —— 前一環，能頻繁上線的前提是出事能馬上看見
• 工具-無指責事後檢討 —— 後一環，遙測提供事實，檢討把事實變成組織的學習
• 工具-服務容錯設計 —— 互為表裡，監控負責看見異常，容錯負責在你看見之前先撐住

五層遙測・3σ 告警（99.7%） 開發者共同輪值 on-call・同儕審查取代 CAB

② 回饋 Feedback

工具-無指責事後檢討

🎯 什麼情境該想到我

當事故發生後，你想「真正學到教訓、避免重演」，而不是找戰犯讓大家更不敢說真話時。

⚙️ 怎麼用

1. 前提假設：每個人在當下都是基於已知資訊做出合理判斷——問題出在系統與流程，不是壞人。
2. 重建時間線：事實導向地還原「發生了什麼、何時、當事人當下看到什麼」。
3. 追系統性成因，不追個人責任：問「什麼樣的系統/流程讓這個錯誤變得可能且不易發現」。
4. 產出可執行的改善項：加護欄、補監控、改流程，並追蹤落實。
5. 公開分享：把教訓擴散到整個組織，把學習制度化。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 一旦開始究責，人就會隱藏資訊、事故根因永遠查不清——心理安全是前提（見 工具-心理安全感）。

🔗 相關工具

• 工具-遙測與監控 —— 檢討的原料，沒有時間軸與指標就只能靠記憶推測事故經過
• 工具-區分修復與掩蓋症狀 —— 檢討的品質關卡，行動項是真修根因還是只是加了個 retry
• 工具-三步工作法 —— 上位框架，事後檢討落在第二步「回饋」與第三步「持續學習」的交界

工具-注入故障與韌性演練

🎯 什麼情境該想到我

當你有一份寫得很漂亮的復原程序，但從來沒有人真的執行過它，你不確定真出事那天它管不管用時。

⚙️ 怎麼用

1. 先定義失效模式，再測它。書中的判準很直接：不設計自己的失效模式，你就只會拿到隨機而且通常很危險的那種。
2. 日常層級——持續注入故障：Chaos Monkey 的做法是持續且隨機殺掉生產伺服器，目的是逼服務做到不需人工介入就能自動復原。關鍵排程判準：在正常上班時間製造與修復這些問題，不要留給半夜。
3. 年度層級——辦 Game Day（五步驟）：
   1. 先排定一個未來的災難事件（例如模擬摧毀整座資料中心）
   2. 給團隊時間準備——消除所有單點故障、建好監控與 failover 程序
   3. 定義並執行演練（資料庫 failover、關掉重要網路連線），遇到問題就修、修完再測
   4. 到了排定時間真的執行——Amazon 的做法是不預告地把一整座設施斷電，讓系統自然失效、讓人照著自己的流程走到底
   5. 逐次加強強度與複雜度，目標是讓它感覺像「平凡一天的一部分」
4. 收成的是潛伏缺陷：那些只有在注入故障後才會冒出來的問題——例如「復原用的監控系統本身也被你製造的故障關掉了」。

原文：「a service is not really tested until we break it in production.」（Jesse Robbins，Amazon 的 “Master of Disaster”）

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意

• 這件事的前提是心理安全感與無指責文化。在會究責的組織裡刻意弄壞生產環境，只會讓人學會不要當那個按下按鈕的人。書中把「注入故障」與「無指責事後檢討」並列為正義文化的兩根支柱，順序不能顛倒。

🔗 相關工具

• 工具-無指責事後檢討 —— 配套支柱，演練完的學習要靠它才收得回來
• 工具-心理安全感 —— 前提條件，沒有它就沒人敢真的把東西弄壞
• 工具-遙測與監控 —— 演練的儀表板，看不到系統狀態就不知道降級有沒有成功
• 遊戲日、注入生產故障 —— 型錄條目，含 Google DiRT 與 Netflix Simian Army 的細節

改善閃電戰（期間不做功能工作） 技術選型收斂・單一共用原始碼儲存庫

③ 持續學習與實驗

工具-資安與合規左移

🎯 什麼情境該想到我

當資安與稽核總是在最後一刻出現、擋住上線，或丟給你一份沒人有時間處理的漏洞清單時。

⚙️ 怎麼用

1. 先認清人數比例：書中給的數字是 Dev : Ops : Infosec ≈ 100 : 10 : 1。資安以這種比例被稀釋時，除了做合規勾選什麼也做不了——唯一的出路是自動化，並把資安放進 Dev 與 Ops 的日常工作裡。
2. 把預先核可的東西放進共用儲存庫：把資安已 pre-blessed 的函式庫與服務（2FA、bcrypt 密碼雜湊、秘密管理、正確組態的 OpenSSL、集中式 log）放進共用版控。判準：工程師用了這些，該模組就不必再另外排一次資安設計審查——這是把資安變成阻力最小路徑的關鍵。
3. 把資安測試放進部署管線，四類一起跑：
   • 靜態分析（非執行期，“testing from the inside-out”）：Brakeman、Code Climate、掃被禁函式如 exec()
   • 動態分析（執行期，“testing from the outside-in”）：Arachni、OWASP ZAP
   • 相依掃描：盤點所有二進位與可執行相依有無已知漏洞
   • 原始碼完整性與簽章：每位開發者有自己的 PGP key、所有 commit 簽章、CI 產物簽章且 hash 記錄到集中式 log 供稽核
4. 回饋要給對人：不要產一份巨大 PDF 報告 email 出去，而是把修復所需的確切資訊，給造成那個漏洞的那位開發者。也要知道自己何時送出 false positive 並修正——不然開發者很快就不信任你的工具了。
5. 用變更歷史去換取「標準變更」資格：拿出數月到數季的變更歷史 ＋ 同期完整的生產事故清單，證明高變更成功率與低 MTTR，就能主張這些低風險變更可預先核可、不必每次送 CAB。書中明確指出：CAB 有協調與治理的角色，但不該手動評估每一個變更，ITIL 也沒有規定要這樣做。

原文：「the ratio of engineers in Development, Operations, and Infosec in a typical technology organization is 100:10:1.」

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意

• 職責分離（separation of duties）不是唯一解，而且有代價。 書中拿 Etsy 的 PCI DSS 隔離環境當警世故事：合規報告拿到了，但那個環境裡沒有人能當 full-stack engineer，部署與維護開始出現恐懼與不情願。書中的建議是盡可能改用結對、持續檢查 check-in、code review 這些控制，並能證明達到等效結果。

🔗 相關工具

• 工具-部署管線與持續交付 —— 承載平台，資安測試就是管線裡多加的幾道自動化測試
• 工具-遙測與監控 —— 偵測面的另一半，資安遙測跟營運遙測該進同一套工具
• 工具-無指責事後檢討 —— 每次資安事件也開一次檢討，是知識轉移給工程團隊的機制
• 四類應用資安自動測試、把變更重歸類為標準變更 —— 型錄條目，含 Twitter 漏洞率降 60% 與 Salesforce 的完整做法

四類資安測試進管線・預先核可函式庫 把低風險變更降級為 standard change

🔐 資安與合規

Link to original

🧰 這本書給我的工具

• 工具-價值流圖 — 想改善但講不出到底卡在哪一段時
• 工具-部署管線與持續交付 — 想讓發布變頻繁、可靠、無痛時
• 工具-低風險發布模式 — 上線只能挑半夜、不敢頻繁發布時
• 工具-遙測與監控 — 想快速發現問題、用數據決策時
• 工具-無指責事後檢討 — 出事後想從失敗學習而非追究人時
• 工具-注入故障與韌性演練 — 復原程序從來沒有真的演練過時
• 工具-資安與合規左移 — 資安永遠最後一刻擋上線、稽核證據準備不完時

📖 完整型錄：43 條 DevOps 實踐（詳解在 reference/）

🚀 從哪開始

• 價值流圖 Value Stream Mapping、專責轉型團隊 Dedicated Transformation Team、保留 20% 產能給非功能需求 Reserve 20% for Non-Functional Requirements

🏗 組織與架構

• 自助服務平台 Self-Service Platform、康威定律作為設計工具 Conway’s Law、兩個披薩團隊 Two-Pizza Team、演進式架構 Evolutionary Architecture

⚡ 第一步・流動：技術實踐

• 隨選環境與基礎設施即程式碼 On-Demand Environments & Infrastructure as Code、版本控管一切 Version Control Everything、不可變基礎設施 Immutable Infrastructure、修改完成的定義 Modify the Definition of Done、測試金字塔 The Testing Pyramid、只自動化可信的測試 Automate Only Trustworthy Tests、虛擬安燈繩 Virtual Andon Cord、主幹開發 Trunk-Based Development、自動化自助部署 Automated Self-Service Deployment

🎛 第一步・流動：低風險發布

• 解耦部署與發布 Decouple Deployments from Releases、藍綠部署 Blue-Green Deployment、金絲雀發布 Canary Release、功能開關 Feature Toggles、黑啟動 Dark Launching

📡 第二步・回饋：遙測與告警

• 五層遙測覆蓋 Five-Layer Telemetry、日誌分級 Logging Levels、均值與標準差告警 Standard Deviation Alerting、非高斯資料的異常偵測 Anomaly Detection for Non-Gaussian Data、從事故回推告警 Alert Reset from Incidents、開發者共同輪值 Dev Shares Pager Rotation

🔬 第二步・回饋：實驗與審查

• B Testing & Hypothesis-Driven Development、同儕審查取代變更審批 Peer Review over Change Approval、程式碼審查準則 Code Review Guidelines、結對程式設計 Pair Programming、大膽砍掉官僚流程 Cut Bureaucratic Processes

🔁 第三步・持續學習

• 廣泛公開事後檢討 Publish Post-Mortems Widely、注入生產故障 Inject Production Failures、遊戲日 Game Day、改善閃電戰 Improvement Blitz、技術選型收斂 Technology Standardization、單一共用原始碼儲存庫 Single Shared Source Code Repository

🔐 資安與合規左移

• 預先核可的資安函式庫 Preventive Security Controls、四類應用資安自動測試 Four Categories of Application Security Testing、保護部署管線 Protect the Deployment Pipeline、資安遙測 Security Telemetry、把變更重歸類為標準變更 Re-categorize as Standard Changes

✨ 關鍵重點（Layer 1–2）

• 這是三步工作法的實作大全（總綱見 工具-三步工作法）：鳳凰專案 講「為什麼」，這本逐項講「怎麼做」。
• 先量再改：價值流圖第一輪只畫 5–15 個 process block，每塊標 lead time／process time／%C/A；理想化的未來圖訂 3–12 個月為期限。技術債固定吃掉至少 20% 的 Dev 與 Ops 產能。
• 第一步・流動：版本控管一切（2014 State of DevOps 發現 Ops 是否用版控比 Dev 更能預測績效）、主幹開發（每人每天至少 check in 一次）、測試金字塔（涵蓋率低於 80% 就讓套件失敗、build 守住十分鐘）、把部署與發布解耦後用藍綠／金絲雀／功能開關／黑啟動控制風險。
• 第二步・回饋：五層遙測（business／application／infrastructure／client／pipeline）、3σ 告警只讓 0.3% 的資料點觸發、開發者一起輪值 on-call、用同儕審查取代 CAB 逐案審批（ITIL 從未規定 CAB 要手動評估每個變更）。
• 第三步・持續學習：無指責事後檢討開完才准結案、Game Day 與 Chaos Monkey 在上班時間製造故障、改善閃電戰期間不允許做功能工作。
• 資安左移：Dev : Ops : Infosec 的人力比例是 100 : 10 : 1——資安只能靠自動化與預先核可的函式庫存活；Twitter 把 Brakeman 接進 build 後漏洞發現率降 60%。

💬 金句原文（Layer 0）

• 「比日常工作更重要的，是改善日常工作。」——Mike Orzen，《Lean IT》作者

  “Even more important than daily work is the improvement of daily work.”

• 「規模 1 倍時管用的東西，很少在 10 倍或 100 倍時還管用。」——Randy Shoup（前 eBay／Google）

  “What works at scale 1x rarely works at scale 10x or 100x.”

• 「一個服務，要到你在生產環境把它弄壞為止，才算真的測過。」——Jesse Robbins，Amazon 的「災難大師」

  “a service is not really tested until we break it in production.”

🔗 相關

• 故事版：鳳凰專案（IT 管理視角）、獨角獸專案（開發者視角）
• 主題總覽：DevOps 主題地圖