Quartz 5

DevOps 手冊 The DevOps Handbook

Properties1
tagssoftware, devops, cicd, continuous-delivery, culture

7 min read

📌 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.」

算一次給你看（自寫範例）

以下數字為自寫範例；「流動效率」「累計 %C/A」兩個彙總公式是精實價值流圖的通用算法，DevOps手冊只要求每塊標 LT／PT／%C/A，沒有寫出彙總公式（推測）。

假設一張功能需求從提出到上線，第一輪只畫 4 個區塊：

區塊前置時間 LT處理時間 PT其中在排隊%C/A（下游打的分數）
需求分析 → 交給開發10 天1 天9 天70%
開發5 天3 天2 天85%
測試（等測試環境＋回歸）8 天1 天7 天60%
變更審批＋部署4 天0.5 天3.5 天90%
  1. 總前置時間 = ΣLT = 10 + 5 + 8 + 4 = 27 天（客戶感受到的就是這個數字）。
  2. 總處理時間 = ΣPT = 1 + 3 + 1 + 0.5 = 5.5 天。
  3. 流動效率 = ΣPT ÷ ΣLT = 5.5 ÷ 27 ≈ 20.4%——一件工作有約 8 成時間在「等」，不是在「做」。
  4. 累計 %C/A（rolled %C/A） = 各區塊 %C/A 相乘 = 0.70 × 0.85 × 0.60 × 0.90 ≈ 0.321 → 約 32%——意思是只有約三分之一的工作能從頭到尾一次都不用返工就走完。
  5. 怎麼讀：
    • 排隊最多的是「需求分析」（9 天）與「測試」（7 天）——正好是書中說要盯的「等數週」型區塊。
    • %C/A 最低的是「測試」60%：下游（部署）收到的東西有 4 成要補資料或退回——是返工源頭。
    • 這時候不該先去逼開發寫快一點：就算開發 PT 從 3 天壓到 1 天，ΣLT 只從 27 降到 25 天（−7%）；把測試環境改成隨選、排隊從 7 天降到 1 天，ΣLT 直接降到 21 天（−22%）。

🧪 我實際套用的紀錄

  • 2026-08-02：（待填）

⚠️ 注意

  • process time / lead time 的比值才是效率指標，但改善重點放在 lead time——因為那才是客戶感受到的。書中的 Nordstrom 例子裡，%C/A 低的根因只是「申請表沒填員工編號」，這種東西不畫圖永遠看不到。
  • 什麼時候會失敗：
    • 現場沒有能改流程的人：書中要求「理想上要把有權改動自己那段價值流的人找來」（“assembled those people with the authority to change their portion of the value stream”）。少了他們，圖畫得再準也只是一份「大家都知道但沒人能動」的報告——例如變更審批卡 3.5 天，但審批委員會沒人出席，就只能記錄、不能改。
    • 畫完沒有後續實驗：書中的流程是「畫理想化未來圖 → 訂 3–12 個月期限 → 對假設做實驗、看結果、再迭代」，領導者要負責引導與支持這個循環。只畫現況圖、把它貼在牆上就結束，等於只做了診斷沒有治療；Damon Edwards 說畫圖常是「大開眼界」，但開眼界本身不會讓 lead time 變短（後半句為推測）。
    • 細節太多讓工作坊卡死：書中明說目標「不是記錄每個步驟與瑣碎細節」，並在註腳強調要限制收集的細節程度，因為「每個人的時間都寶貴且稀少」。第一輪超過 15 個區塊、或開始爭論某步驟是 2 小時還是 3 小時，就是走偏了的訊號——先找出最大的等待與返工，細部量測留到選定要改的那一塊再做。
    • %C/A 自己評自己（推測）：%C/A 必須由下游來打分（書中寫的是「as measured by the downstream consumers」），上游自評幾乎都會偏高，彙總出來的累計 %C/A 就失真。

🔗 相關工具

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

🚀 從哪開始

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

🎯 什麼情境該想到我

分工：《DevOps 手冊》的部署相關實踐已經展開成型錄 → 版本控管一切、主幹開發、測試金字塔、自動化自助部署、保護部署管線、解耦部署與發布、藍綠部署、金絲雀發布、功能開關、黑啟動。這張補怎麼量交付能力（DORA）、管線階段的排序原則，以及 Go 專案的具體管線。

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

⚙️ 怎麼用

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

★ 怎麼知道交付能力有沒有進步：DORA 指標

DORA 目前把軟體交付表現分成吞吐量和不穩定度兩組（依 dora.dev，2026-09-25 查證）：

組別指標定義
吞吐量變更前置時間一個變更從提交到版本控制到部署到正式環境的時間
部署頻率一段時間內的部署次數，或兩次部署之間的間隔
失敗部署的恢復時間一次需要立即介入的失敗部署，要多久才恢復
不穩定度變更失敗率部署後需要立即介入的比例
部署重工率因為正式環境事故而進行的計畫外部署比例
  • 「失敗部署的恢復時間」取代了早期的 MTTR——範圍縮小到因部署造成的失敗，而不是所有事故。
  • 這兩組要一起看：只衝吞吐量而不穩定度上升，代表在把問題更快送上線；DORA 的研究結論是兩者可以同時變好，因為小批量的變更更快也更安全。

★ 管線階段的排序：便宜又快的在前面

每個階段都是一道篩子。越早失敗越便宜，所以把「跑得快、最常抓到問題」的階段放前面：

順序階段典型耗時為什麼放這裡
1格式、靜態檢查秒最便宜；錯了就不必浪費時間建置
2單元測試秒～分鐘抓大部分邏輯錯誤
3建置產物（二進位檔、容器映像）分鐘只建置一次，之後每個環境都用同一個產物
4整合測試、契約測試分鐘需要資料庫等外部資源
5部署到預備環境 + 冒煙測試分鐘驗證「能部署、能啟動」
6正式環境：金絲雀 → 全量分鐘～小時用真實流量驗證，出問題自動回滾

「只建置一次」是關鍵原則：如果每個環境各自重新建置，你在預備環境測過的東西，就不是正式環境上跑的東西。

★ Go 專案的管線（對應上表 1–3）

# 1. 靜態檢查
test -z "$(gofmt -l .)"            # 有未格式化的檔案就失敗
go vet ./...
golangci-lint run --new-from-rev=origin/main   # 只擋新增的問題（見「破窗」卡的棘輪）
 
# 2. 測試：競爭偵測 + 不使用快取
go test -race -count=1 ./...
 
# 3. 建置：可重現、帶版本資訊
CGO_ENABLED=0 go build -trimpath -o bin/app ./cmd/app
  • -trimpath：從二進位檔移除本機路徑，讓不同機器建置出的結果一致。
  • Go 會自動把版本控制資訊寫進二進位檔：在 git 倉庫中建置後，用 go version -m bin/app 可以看到 vcs.revision（commit 雜湊）、vcs.time、vcs.modified（建置時工作區是否有未提交的修改）。本機以 Go 1.26.4 驗證過（2026-09-25）。程式內可用 runtime/debug.ReadBuildInfo() 讀取，放進 /version 端點——事故時第一個問題就是「現在線上跑的是哪個 commit」。
  • CGO_ENABLED=0 產生靜態連結的二進位檔，可以放進極小的容器映像（scratch 或 distroless）。

★ 回滾要比修復快

管線的最後一道防線是回滾。設計目標：

  • 回滾是一個按鈕或一個指令，不需要重新建置（直接部署上一個已建置好的產物）。
  • 資料庫遷移要向後相容（先加欄位、程式碼上線、再移除舊欄位——見 工具-小步重構的平行改動），否則程式碼可以回滾，資料庫回不去。
  • 定期演練回滾。從沒用過的回滾程序，出事時很可能不能用。

🧪 我實際套用的紀錄

  • 2026-07-15：（待填）

⚠️ 注意

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

  • 管線太慢，大家就會繞過它：主幹上的管線超過 15–20 分鐘，工程師就會開始累積大批變更一起送，失去小批量的好處。要持續量測並縮短管線時間。

  • 不穩定的測試會毀掉對管線的信任：見 工具-破窗理論與軟體熵——flaky test 要立刻隔離。

🔗 相關工具

工具-低風險發布模式

🎯 什麼情境該想到我

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

⚙️ 怎麼用

  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：（待填）

⚠️ 注意

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

🔗 相關工具

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

① 流動 Flow

工具-遙測與監控

🎯 什麼情境該想到我

分工：《DevOps 手冊》的遙測章節已經展開成型錄 → 五層遙測覆蓋、日誌分級、均值與標準差告警、非高斯資料的異常偵測、從事故回推告警、資安遙測。這張補書中沒有的兩件事：要量什麼（黃金訊號）和什麼時候該叫醒人（SLO 與燃燒率告警）。

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

⚙️ 怎麼用

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

★ 要量什麼：三套常用的指標框架

框架指標適合
四個黃金訊號（Google SRE）延遲、流量、錯誤、飽和度任何對外服務
REDRate（請求率）、Errors（錯誤率）、Duration（耗時分布）請求驅動的服務（API、微服務）
USE（Brendan Gregg）Utilization（使用率）、Saturation（飽和度／排隊）、Errors資源：CPU、記憶體、磁碟、連線池

延遲要看分布，不看平均：平均 50 ms 可能是 99% 的請求 10 ms、1% 的請求 4 秒。用 p50、p95、p99，而且成功和失敗的請求要分開算——快速失敗的錯誤會把延遲平均拉低，讓圖表看起來很好。

★ 什麼時候叫醒人：SLO 與錯誤預算

  1. SLI（指標）：例如「成功且在 300 ms 內完成的請求比例」。
  2. SLO（目標）：例如「30 天內 SLI ≥ 99.9%」。
  3. 錯誤預算 = 1 − SLO = 0.1%——30 天內允許千分之一的請求不好。

錯誤預算把「可靠性 vs 開發速度」變成可以量的東西：預算還很多 → 可以大膽上線；預算快用完 → 凍結風險高的變更，先處理可靠性。

★ 燃燒率告警：比「錯誤率 > X%」好的告警方式

燃燒率 = 實際錯誤率 ÷ 錯誤預算率。燃燒率 1 代表「剛好在 30 天內用完預算」；燃燒率 10 代表 3 天就用完。

Google《SRE Workbook》的建議起始值（2026-09-25 查證）：

條件對應的燃燒率動作
1 小時內消耗 2% 的預算14.4呼叫值班人員
6 小時內消耗 5% 的預算6呼叫值班人員
3 天內消耗 10% 的預算1開工單

這些數字可以自己推導：燃燒率 = 消耗的預算比例 × (SLO 週期 ÷ 視窗長度)。

  • 2% × (30 天 × 24 小時 ÷ 1 小時) = 0.02 × 720 = 14.4
  • 5% × (720 ÷ 6) = 0.05 × 120 = 6
  • 10% × (30 天 ÷ 3 天) = 0.1 × 10 = 1

換算成錯誤率：SLO 99.9% 時，燃燒率 14.4 = 錯誤率 1.44%。

多視窗：Workbook 建議同時要求長視窗（1 小時）與短視窗（5 分鐘）都超過門檻才告警——長視窗確保問題夠嚴重，短視窗確保問題還在發生（已經恢復的事故不會繼續叫人）。

★ Go 的埋點

需求做法
結構化日誌標準函式庫 log/slog（Go 1.21+）：slog.Info("order created", "order_id", id, "amount", amt)，輸出 JSON 方便查詢
指標Prometheus 的 client_golang，或 OpenTelemetry metrics
分散式追蹤OpenTelemetry：ctx 一路傳下去，trace ID 就跟著走——這也是為什麼 Go 的函式第一個參數是 ctx
執行時期狀態net/http/pprof（CPU、記憶體、goroutine）；不要對外公開這個端點

把日誌和追蹤串起來：在日誌裡帶上 trace ID，事故時才能從一條錯誤日誌直接跳到完整的請求路徑。

🧪 我實際套用的紀錄

  • 2026-07-15：（待填）

⚠️ 注意

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

  • 高基數標籤會把監控系統打垮：把 user_id、request_id 當成 Prometheus 標籤，每個值都會產生一條新的時間序列。這類資訊放在日誌或追蹤裡，不要放在指標標籤。

🔗 相關工具

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

② 回饋 Feedback

工具-無指責事後檢討

🎯 什麼情境該想到我

分工：《DevOps 手冊》怎麼把事後檢討擴散到整個組織 → 廣泛公開事後檢討。這張補一份可以直接用的模板、寫法上的具體規則，以及好的行動項長什麼樣子。

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

⚙️ 怎麼用

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

★ 事後檢討文件的模板

# 事後檢討：<一句話描述，例：9/12 訂單 API 錯誤率 30%，持續 42 分鐘>
 
## 摘要（三句話）
發生了什麼、影響多大、怎麼恢復的。
 
## 影響
- 時間：09:14–09:56（42 分鐘）
- 範圍：約 30% 的下單請求失敗；估計影響 1,200 位使用者
- 錯誤預算：消耗本月 18%
 
## 時間線（全部用同一個時區）
| 時間 | 事件 | 資訊來源 |
|---|---|---|
| 09:02 | 部署 v2.41.0（含連線池設定變更） | 部署紀錄 |
| 09:14 | 錯誤率開始上升 | 監控圖表 |
| 09:21 | 告警觸發，值班人員收到通知 | 告警系統 |
| 09:30 | 值班人員懷疑資料庫，檢查慢查詢（沒有發現） | 事後訪談 |
| 09:48 | 注意到部署時間與錯誤開始時間吻合，決定回滾 | 聊天紀錄 |
| 09:56 | 回滾完成，錯誤率恢復正常 | 監控圖表 |
 
## 促成因素（不是「根本原因」，通常有好幾個）
1. 連線池上限從 50 改成 5（設定檔的單位誤解）
2. 設定變更沒有在預備環境以正式環境的流量測試
3. 儀表板沒有顯示「最近的部署」，讓值班人員花了 18 分鐘才聯想到部署
 
## 做得好的地方
- 告警在 7 分鐘內觸發
- 回滾程序順利，8 分鐘完成
 
## 行動項
| 行動 | 類型 | 負責人 | 期限 | 追蹤單 |
|---|---|---|---|---|
| 連線池設定加上合理範圍的驗證（< 10 時拒絕啟動） | 預防 | @alice | 9/20 | #812 |
| 儀表板加上部署標記 | 偵測 | @bob | 9/19 | #813 |
| 部署後 10 分鐘內錯誤率上升時自動回滾 | 緩解 | @carol | 10/1 | #814 |

★ 寫法規則：讓文件保持「無指責」

避免改成為什麼
「Alice 應該要檢查……」「設定變更的流程沒有要求……」「應該」是事後諸葛；當下的人不知道事後才知道的事
「人為疏失」描述當時的決策與依據的資訊「人為疏失」是調查的起點，不是結論
「根本原因是……」（單一）「促成因素」（多個）複雜系統的事故幾乎都有多個因素同時成立
「他沒注意到……」「儀表板沒有顯示……」把問題從人身上移到系統上，才能改善

核心提問從「誰做錯了」換成「當時看到的資訊，為什麼讓這個決定顯得合理？」——這個問題的答案，才指向可以改善的系統缺陷。

★ 好的行動項：預防、偵測、緩解三種都要有

類型目的例子
預防讓這類錯誤無法發生設定驗證、型別檢查、權限限制
偵測發生時更快發現告警、儀表板、部署標記
緩解發生時影響更小、恢復更快自動回滾、功能開關、限流

好的行動項要具體、有負責人、有期限、有追蹤單。「加強注意」「提升意識」「多做測試」都不是行動項——它們無法被驗證是否完成。

★ 「5 個為什麼」的限制

「問 5 次為什麼」容易把分析導向一條線性的因果鏈，最後停在某個人的決定上。複雜系統的事故更像是好幾個條件同時成立（上面例子的三個促成因素，少了任何一個都可能不會發生或更快被發現）。用「還有什麼因素讓這件事發生或惡化」取代「為什麼」，比較不會漏掉。

🧪 我實際套用的紀錄

  • 2026-07-15：（待填）

⚠️ 注意

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

  • 無指責不等於沒有責任：它針對的是誠實的錯誤。故意違規、刻意繞過安全機制屬於另一種處理。區分的目的是讓人敢說出真實經過，而不是讓所有行為都免責。

  • 沒有追蹤的行動項等於沒寫：在下次事後檢討前，回頭檢查上次的行動項完成了多少。

🔗 相關工具

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

🎯 什麼情境該想到我

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

⚙️ 怎麼用

  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：（待填）

⚠️ 注意

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

🔗 相關工具

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

③ 持續學習與實驗

工具-資安與合規左移

🎯 什麼情境該想到我

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

⚙️ 怎麼用

  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 這些控制，並能證明達到等效結果。

🔗 相關工具

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

🔐 資安與合規

Link to original

🧰 這本書給我的工具

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

🚀 從哪開始

🏗 組織與架構

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

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

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

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

🔁 第三步・持續學習

🔐 資安與合規左移

✨ 關鍵重點（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.”

🔗 相關

Graph View

Backlinks