🎯 什麼情境該想到我
當你「每次上線都要等離現場很遠的人簽核，而出包後的對策永遠是再加一層簽核」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：把控制手段從「外部機構事前授權」換成「離工作最近的人做同儕審查」，同時保留必要的協調與排程。
先認清變更失敗後最常見的三種錯誤反應（書中列出的傳統變更控制加強手法）：
- 在變更申請表上加更多需要回答的問題。
- 要求更多授權：多一層管理核可（原本只要 VP of Operations，現在 CIO 也要簽）或更多利害關係人（網路工程、架構審查委員會等）。
- 要求更長的審批前置時間，好讓變更請求被「妥善評估」。
為什麼這三招會反效果：
- 它們增加步驟與核可數、放大批量（batch size）與部署前置時間，而我們已知這會降低 Dev 與 Ops 生產結果成功的機率，同時減慢我們從工作中取得回饋的速度。
- Toyota Production System 的核心信念之一：「people closest to a problem typically know the most about it」（離問題最近的人通常最了解它）。工作與系統越複雜動態，這點越明顯。
- 變更實施者（change implementer）與變更授權者（change authorizer）之間距離越遠，結果越差——這一點已被反覆證實。
- Puppet Labs 2014 State of DevOps Report 的關鍵發現：高績效組織更依賴同儕審查、更少依賴外部核可；越依賴變更核可的組織，其穩定性（MTTR、變更失敗率）與吞吐量（部署前置時間、部署頻率）都越差。
- 從 CAB 成員的處境想：面對數十萬行、上百位工程師改出來的複雜變更，一端是光讀一段百字描述或勾完檢查表根本無法可靠預測變更是否成功，另一端是痛苦地細看數千行程式碼也不太可能得到新洞見。連天天在這份程式碼裡工作的工程師，都常被「本應低風險」的變更的副作用嚇到。
書中對 CAB（change advisory board）的明確主張：在許多組織中，CAB 在協調與治理交付流程上扮演重要角色，但它的工作不該是手動評估每一個變更，ITIL 也沒有規定要這樣做。
配套：變更的協調與排程（不是核可）
- 架構越鬆耦合，需要跟其他元件團隊溝通協調的就越少；真正服務導向時，團隊能高度自主變更，局部變更不易造成全域中斷。
- 即使是鬆耦合架構，當許多團隊每天做上百次獨立部署時，變更仍可能互相干擾（例如同時進行的 A/B tests）；此時可以用 chat rooms 宣告變更，主動找出可能的碰撞。
- 更複雜的組織、耦合更緊的架構，就需要刻意排程變更：各團隊代表碰面，不是為了授權變更，而是為了排程與排序變更，把意外降到最低。
- 但某些領域（例如核心網路交換器變更這類全域基礎設施變更）永遠是高風險，一定要有技術性對策：冗餘、failover、完整測試，理想上還要有模擬。
反面案例：Knight Capital
- 一次十五分鐘的部署錯誤造成 4.4 億美元的交易損失，期間工程團隊無法停用生產服務。財務損失危及公司營運，被迫在週末被賣掉才能繼續運作而不危及整個金融體系。
- John Allspaw 指出，這類高曝光事故通常會產生兩種「反事實（counterfactual）」敘事：一是變更控制失敗，二是測試失敗——兩者聽起來都合理。
- 令人意外的事實：在低信任、命令控制型文化裡，這兩類對策往往提高問題再次發生的機率，而且後果可能更糟。
原文：「coordinating and governing the delivery process, but their job should not be to」（L9533，接 L9534「manually evaluate every change, nor does ITIL mandate such a practice.」）
原文：「One of the core beliefs in the Toyota Production System is that “people closest」（L9515，接 L9516「to a problem typically know the most about it.”」）
原文：「errors in recent memory. A fifteen minute deployment error resulted in a $440」（L9451，接 L9452「million trading loss, during which the engineering teams were unable to disable」）
原文：「representatives from the teams get together, not to authorize changes, but to」（L9579，接 L9580「schedule and sequence their changes in order to minimize accidents.」）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 這不是取消治理：CAB 在協調與治理上仍有重要角色，被取消的只是「手動逐案評估每個變更」。
- 全域基礎設施變更（核心網路交換器等）永遠高風險，不能只靠同儕審查，要有冗餘、failover、完整測試與模擬。
- 用同儕審查取代外部核可，前提是審查真的有品質——否則只是把橡皮圖章從 CAB 搬到同事身上，判準見 程式碼審查準則。
- 這一切要在高信任文化上才成立；低信任的命令控制文化裡強推，只會讓對策繼續往「再加一層簽核」倒退。