建立審查與協調流程以提升工作品質#

在前幾章中，我們建立了遙測資料來發現和解決問題，並從客戶建立快速回饋迴路。本章的目標是讓 Development 和 Operations 在變更進入生產環境之前就能降低風險。

傳統上，我們依賴外部團隊在部署前進行審查、檢視和審批。但這些審批者往往距離實際工作太遠，無法做出有效判斷，且所需的審批時間還會拉長變更前置時間。

GitHub 的 Pull Request 流程#

GitHub 開創的 Pull Request 是最受歡迎的跨 Dev 和 Ops 的同儕審查形式。在 GitHub，pull request 也是將程式碼部署到生產環境的機制，稱為 GitHub Flow：

1. 從 master 建立描述性命名的分支
2. 在該分支上定期提交程式碼
3. 需要回饋或準備合併時，開啟 pull request
4. 獲得審查和必要的批准後，合併到 master
5. 合併並推送到 master 後，部署到生產環境

GitHub 在 2012 年完成了驚人的 12,602 次部署。特別是在一次全公司峰會後的 8 月 23 日，完成了 563 次建置和 175 次成功部署——全部透過 pull request 流程實現。

變更審批流程的危險#

Knight Capital 事件#

Knight Capital 的失敗是近代最引人注目的軟體部署錯誤之一。一個十五分鐘的部署錯誤造成了 4.4 億美元的交易損失，迫使公司在週末被出售。

John Allspaw 觀察到，對於這類高知名度事件，通常有兩種反事實敘事：

• 變更控制失敗：更好的變更控制可能早期發現風險
• 測試失敗：更好的測試可能識別風險並取消部署

然而，在低信任、命令與控制的文化中，這類變更控制和測試的對策往往適得其反，反而增加問題再次發生的可能性。

「過度控制變更」的潛在危險#

傳統變更控制在失敗後常見的反應包括：

• 在變更申請表上增加更多問題
• 要求更多層級的管理審批
• 要求更長的變更審批前置時間

這些控制措施增加了部署流程的摩擦，增大了批次大小和部署前置時間，反而降低了成功的機率。Toyota Production System 的核心信念是：「最接近問題的人通常最了解問題。」做工作的人（變更執行者）與決定是否做工作的人（變更授權者）之間的距離越遠，結果越差。

同儕審查優於變更審批委員會#

Puppet Labs 的 2014 State of DevOps Report 發現：高績效組織更依賴同儕審查，而非外部變更審批。組織越依賴變更審批，其 IT 績效在穩定性（平均恢復時間、變更失敗率）和吞吐量（部署前置時間、部署頻率）兩方面都越差。

變更諮詢委員會（CAB）的角色應該是協調和治理交付流程，而不是手動評估每一個變更。ITIL 也不要求這樣做。

啟用變更的協調與排程#

當多個團隊在共享依賴的系統上工作時，變更需要協調以避免衝突：

• 鬆耦合架構：團隊可以高度自主地進行變更，本地變更不太可能造成全域中斷
• 即使是鬆耦合，多團隊每天進行數百次獨立部署時，仍可能互相干擾（例如同時進行 A/B 測試）。可使用聊天室宣布變更並主動發現衝突
• 緊耦合架構：可能需要團隊代表聚在一起排程和編排變更順序，但目的是協調而非授權
• 全域基礎設施變更（如核心網路交換機）始終具有較高風險，需要冗餘、故障轉移、全面測試和模擬等技術對策

啟用變更的同儕審查#

取代部署前的外部審批，我們應該要求工程師對其變更進行同儕審查（Peer Review）。在開發中稱為 code review，但同樣適用於伺服器、網路和資料庫的所有變更。

Code Review 的準則#

• 每個人的變更在提交到 trunk 之前必須有人審查
• 每個人都應監控團隊成員的提交流，以識別和審查潛在衝突
• 定義哪些變更屬於高風險，需要指定的主題專家審查（如資料庫變更、安全敏感模組）
• 如果變更太大而難以理解，應拆分為多個更小的變更

Randy Shoup 觀察到：「變更大小與整合風險之間存在非線性關係——從 10 行程式碼變更到 100 行，出錯的風險不只增加十倍。」Giray Ozil 更幽默地指出：「請程式設計師審查 10 行程式碼，他會找出 10 個問題；請他審查 500 行，他會說看起來不錯。」

Code Review 的形式#

• Pair Programming：兩位程式設計師結對工作
• Over-the-shoulder：一位開發者在作者肩膀後面看程式碼
• Email pass-around：原始碼管理系統在程式碼簽入後自動寄送給審查者
• Tool-assisted code review：使用專門工具（如 Gerrit、GitHub Pull Request、Atlassian Stash/Crucible）

案例：Google 的 Code Review#

Google 是大規模 trunk-based 開發和持續交付的典範。2013 年時，超過一萬三千名開發者在單一原始碼樹上工作，每週執行超過 5,500 次 code commit，產生數百次生產部署。2010 年，每分鐘有超過 20 個變更被簽入 trunk，每月有 50% 的程式碼庫被改動。

Google 的強制性 code review 涵蓋以下領域：

• 程式碼可讀性：強制執行語言風格指南
• 程式碼子樹所有權：維護一致性和正確性
• 程式碼透明度：跨團隊的程式碼貢獻

結論#

本章探討了如何從依賴定期檢視和審批轉向持續進行的同儕審查。透過像 GitHub 那樣將審查與協調整合到日常工作中，我們讓 Development、Operations 和 Infosec 持續協作，確保變更能可靠、安全地運作。同儕審查不僅提升變更品質，還帶來交叉訓練、同儕學習和技能提升等額外效益。