🛠 DevOps 手冊

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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風險 —— 把圖上的等待時間翻譯成老闆聽得懂的損失

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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 對持續交付與持續部署的正式定義

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

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

🔗 相關工具

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

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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 的完整做法