🎯 什麼情境該想到我
當你「部署已經全自動、成功率很高，但每次還是得等下週三的變更審查會才能上線」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：如果部署管線建得夠好、部署夠低風險，大多數變更根本不需要走人工核准流程，因為我們已經把倚賴放在自動化測試與主動的生產監控這類控制上。這條就是把這個主張正式化、並讓變更權責單位接受。
ITIL 的三類變更（完整定義）
- Standard changes 標準變更：較低風險、遵循已建立且已核可的流程，而且可以被預先核可（pre-approved）。例如每月更新應用程式的稅率表或國碼、網站內容與樣式變更、某些影響已被充分理解的應用程式或作業系統修補。變更提案者在部署該變更前不需要核准，變更部署可以完全自動化，且應該被記錄下來以保有可追溯性。
- Normal changes 正常變更：較高風險，需要經過**約定的變更權責單位（change authority）**審查或核准。書中直言：在許多組織裡，這個責任被不當地放在 CAB（change advisory board）或 ECAB（emergency change advisory board）身上，而他們可能缺乏理解該變更全部影響所需的專業，經常導致無法接受的長前置時間——對大型程式碼部署尤其如此（可能包含數十萬甚至數百萬行新程式碼，由數百名開發者在數個月間提交）。CAB 通常會有定義明確的 RFC 表單，載明 go/no-go 決策所需資訊：期望的業務成果、規劃的 utility 與 warranty、含風險與替代方案的商業論證，以及提議的排程。
- Urgent changes 緊急變更：緊急、因而可能高風險、必須立即上線的變更（例如緊急資安修補、恢復服務）。這些變更通常需要高階主管核准，但允許事後才補文件。
書中對 DevOps 的目標宣告：DevOps 實踐的一個關鍵目標，就是把正常變更流程精簡到「連緊急變更也適用」的程度。
降級的舉證方式（怎麼說服變更權責單位）
- 先靠可靠的部署管線贏得「快速、可靠、不戲劇化的部署」的名聲。
- 提出一段夠長期間（數月或數季）的變更歷史，並提供同期間完整的生產事故清單。
- 若能展示高變更成功率與低 MTTR，就能主張我們擁有一個確實在有效預防部署錯誤的控制環境，並證明我們能有效且快速地偵測與修正任何隨之而來的問題。
- 即使被歸為標準變更，它們仍然需要在變更管理系統中可見並被記錄（Remedy、ServiceNow 等）。理想上由組態管理與部署管線工具（Puppet、Chef、Jenkins）自動執行部署並自動記錄結果，讓組織中每個人（不管是不是 DevOps）都能看見我們的變更。
- 可以把變更請求記錄自動連結到工作規劃工具（JIRA、Rally、LeanKit、ThoughtWorks Mingle）中的特定項目，例如功能缺陷、生產事故或 user story——輕量的做法是在版控 check in 的註解裡帶上規劃工具的票號，就能從生產部署追溯到版控變更，再往回追溯到規劃工具的票。
Salesforce 2012 案例
- 2007 年是他們最後一年用瀑布式流程；2009 年起的多年 DevOps 轉型使部署前置時間從六天降到五分鐘（2013 年），讓他們能更容易擴充容量，每天處理超過十億筆交易。
- 主題是「讓品質工程成為每個人的工作」：把自動化測試整合進應用與環境建立的所有階段以及 CI/CD 流程，並開源了 Rouster 來對他們的 Puppet 模組做功能測試；還定期進行破壞性測試（destructive testing）——在越來越高的負載下測到服務壞掉為止，藉此理解失效模式。Infosec 也在專案最早期就與品質工程協作。
- 關鍵成果：變更管理團隊告訴他們，透過 Puppet 進行的基礎設施變更從此被視為「standard changes」，需要遠更少、甚至完全不需要 CAB 的進一步核准。而且他們特別註明：手動的基礎設施變更仍然需要核准。
- 效應：這不只把 DevOps 流程與變更管理流程整合起來，也創造了「把更多基礎設施的變更流程自動化」的進一步動機。
配套一：降低對職責分離（separation of duty）的依賴
- 傳統做法是開發者的變更要送給 code librarian 審查核准，再由 IT Ops 推上生產。當部署頻率低（例如一年一次）且工作較不複雜時，這種區隔與交接是可行的做法。
- 但隨著複雜度與部署頻率上升，成功的生產部署越來越要求價值流中的每個人都能快速看見自己行動的結果。職責分離會拖慢並減少工程師得到的回饋，阻止工程師為自己工作的品質負全責，並降低公司創造組織學習的能力。
- 因此：在可能的情況下，我們應該避免使用職責分離作為控制手段；改用 pair programming、對 code check-in 的持續檢查、code review。若職責分離仍是必要的，這些控制也能讓我們證明我們用自己建立的控制達成了等效的成果。
配套二：Etsy ICHT 的警世故事（2014）
- 為了收斂 PCI DSS 的 CDE（cardholder data environment）範圍，支付應用 ICHT 被在實體與邏輯上與 Etsy 其餘組織完全分離，由一個完全獨立的應用團隊（開發、DBA、網路、Ops）管理；每位成員配發兩台筆電——一台給 ICHT（依 DSS 要求做不同組態，不用時鎖進保險箱），一台給 Etsy 其餘部分。
- 為滿足 PCI DSS 6.3.2 的程式碼審查要求，團隊起初指定 Bill Massie 作為變更核准者，在 JIRA 標記審查與核准，並手動部署到 ICHT 生產環境。
- 結果：他們拿到了簽署的 Report of Compliance——但團隊出現了嚴重副作用。Massie 觀察到 ICHT 團隊出現了 Etsy 其他群組都沒有的**「區隔化（compartmentalization）」**：自從實施職責分離與 PCI DSS 要求的其他控制之後，這個環境裡沒有人能當 full-stack engineer。
- 具體症狀：Etsy 其他 Dev 與 Ops 團隊緊密合作、順暢且有信心地部署，但在 PCI 環境裡，圍繞部署與維護存在著恐懼與不情願，因為沒有人能看見自己那塊軟體堆疊之外的東西；那些看似微小的工作方式改動，在開發與維運之間造出了一道無法穿透的牆，製造出 Etsy 自 2008 年以來未曾有過的張力。
- 書中的結論：合規在採用 DevOps 的組織裡是可能的；但警世之處在於高績效 DevOps 團隊的那些美德是脆弱的——即使一個有著高信任與共同目標的團隊，在被放進低信任的控制機制之後也會開始掙扎。
配套三：稽核證據自助化
- 問題：稽核員受過的訓練不適合 DevOps 工作模式。看到一萬台生產伺服器的環境，傳統上會要求抽樣一千台，外加資產管理、存取控制設定、agent 安裝、伺服器 log 的截圖證據。但當基礎設施是程式碼、auto-scaling 讓伺服器不斷出現與消失時，你要怎麼抽樣？
- 做法（Bill Shinn，AWS）：把所有資料送進遙測系統（如 Splunk 或 Kibana），這樣稽核員可以完全自助地拿到他們需要的東西——他們不需要請求資料樣本，而是登入 Kibana，搜尋某個時間區間內他們需要的稽核證據。
- 更前面一步：在控制設計階段就讓團隊與稽核員一起工作，採用迭代取徑，每個 sprint 指派一項控制，以確定該控制在稽核證據上需要什麼——這確保了服務進入生產時，稽核員能完全按需拿到所需資訊。
原文（DevOps 對變更流程的目標）：「A key goal of DevOps practices is to streamline our normal change process such that it is also suitable for emergency changes.」（L12280–12281）
原文（過度追溯的界線）：「Linking to user stories, requirements, or defects is almost certainly sufficient—any further detail, such as opening a ticket for each commit to version control, is likely not useful, and thus unnecessary and undesired, as it will impose a significant level of friction on their daily work.」（L12321–12325）
原文（避免職責分離）：「Consequently, wherever possible, we should avoid using separation of duties as a control. Instead, we should choose controls such as pair programming, continuous inspection of code check-ins, and code review.」（L12467–12469）
原文（Salesforce 的結論與但書）：「infrastructure changes made through Puppet would now be treated as ‘standard changes,’ requiring far less or even no further approvals from the CAB.」（L12432–12435）／「manual changes to infrastructure would still require approvals.」（L12435–12436）
原文（Etsy ICHT 的副作用）：「Ever since we implemented separation of duty and other controls required by the PCI DSS compliance, no one can be a full-stack engineer in this environment.」（L12541–12544）
原文（稽核證據自助化）：「This way auditors can get what they need, completely self-serviced. They don’t need to request a data sample—instead, they log into Kibana, and then search for audit evidence they need for a given time range.」（L12620–12624）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 不要為了追溯性而過度追溯。 書中畫的界線很清楚：連到 user story、需求或缺陷幾乎肯定就足夠了；再細（例如每個 commit 都開一張工單）大概沒有用，因此不必要也不受歡迎，只會給日常工作帶來顯著的摩擦。
- 標準變更不等於不記錄。 即使被歸為標準變更，仍然需要在變更管理系統中可見並被記錄；理想上由部署工具自動記錄。
- 降級的範圍要講清楚。 Salesforce 只讓「透過 Puppet 做的基礎設施變更」變成標準變更；手動的基礎設施變更仍需核准。含糊地主張「我們的變更都低風險」不會被接受。
- 合規控制可能反噬團隊。 Etsy ICHT 拿到了合規報告，代價是那個環境裡沒有人能當 full-stack engineer，並在 Dev 與 Ops 之間造出一道牆。導入任何隔離型控制前，先問這個副作用是否可接受。
- 職責分離不是不能用，而是在可能的情況下優先改用等效控制，並要能證明等效。
🔗 相關工具
- 同儕審查取代變更審批（這條的姊妹條：用同儕審查取代 CAB 的核准）
- 保護部署管線（管線的完整性是「把倚賴放在自動化控制上」的前提）
- 資安遙測（遙測系統同時是稽核證據的自助來源）
- 結對程式設計（職責分離的等效替代控制之一）
- 程式碼審查準則（職責分離的等效替代控制之一）
- 工具-部署管線與持續交付（低風險部署的名聲要先靠它建立）
- DevOps手冊