建立回饋機制，讓 Dev 與 Ops 安全部署程式碼#

本章探討如何建立回饋機制，使價值流中的每個階段都能持續改善，從產品設計、開發、部署到營運與退役。透過這些機制，我們確保服務在專案最早期就具備「生產就緒」（production ready）的能力，並將每次發布與生產問題的經驗教訓融入未來工作中。

利用遙測資料讓部署更安全#

當任何人執行生產環境部署時，我們必須主動監控生產遙測資料（production telemetry），以快速判斷功能是否如預期運作。部署完成不等於工作結束——只有在生產環境中確認一切正常運作，才算真正完成。

部署後的回應策略包括：

• 關閉功能開關（Feature Toggle）：最簡單且風險最低，無需重新部署
• Fix Forward：修改程式碼修復缺陷，再透過部署流水線推送到生產環境
• Roll Back：切回上一版本，例如透過 blue-green 或 canary 發布模式

當我們擁有自動化測試、快速部署流程和充足的遙測資料時，fix forward 可以非常安全。關鍵在於能快速確認一切是否正常運作。

案例：Etsy 的部署追蹤#

Etsy 將每次部署和變更事件疊加在指標圖表上，確保價值流中的每個人都能看到相關活動，實現更好的溝通協調以及更快的偵測與恢復。

在 Etsy 的案例中，一次 PHP 程式碼部署造成了 PHP 執行時警告的飆升，開發者在幾分鐘內就發現問題，產生修復並部署到生產環境，在不到十分鐘內解決了問題。

開發人員參與 Pager 輪值#

即使部署順利，複雜服務仍然會發生意外問題和故障。如果這些問題沒有被上游工程師看見，就會導致 Ops 工程師持續承受痛苦。

為了防止這種情況，我們應該讓開發人員、開發主管和架構師加入 pager 輪值，分擔處理營運事件的責任。這確保了：

• 價值流中的每個人都能獲得對其架構和編碼決策的切身回饋
• 功能只有在生產環境中正常運作、不造成過多問題時才算「完成」
• 缺陷修復速度更快——New Relic 的經驗顯示「半夜叫醒開發者後，缺陷修復得比以往都快」
• Dev 管理層認識到：功能標記為「完成」不等於商業目標達成

無論是市場導向團隊還是功能導向團隊，核心原則不變：當開發者獲得其應用程式在生產環境中表現的回饋（包括出問題時的修復），他們會更貼近客戶，這為整個價值流創造出共同投入的文化。

讓開發者跟隨工作到下游#

情境調查（Contextual Inquiry）是互動設計和使用者體驗設計中最強大的技術之一——產品團隊觀察客戶在自然環境中使用應用程式。這經常揭示出令人震驚的問題，例如完成簡單任務需要數十次點擊、從多個畫面複製貼上文字等。

我們的目標是將這種技術應用於觀察內部客戶的工作方式：

• 開發者應跟隨工作到下游，觀察下游工作中心如何與其產品互動
• 透過親眼目睹客戶的困難，開發者能做出更好、更明智的日常決策
• 這會產生對程式碼非功能面向的回饋——可部署性、可管理性、可操作性等
• UX 觀察能在源頭創造品質，並在價值流中建立更多同理心

Gene Kim 分享了他在 Tripwire 的經歷：一次客戶觀察發現，每週預期客戶執行的操作竟需要 63 次點擊。這成為他在公司建立 UX 實踐的原因之一。

讓開發者先自行管理生產服務#

即使開發者在類生產環境中撰寫和運行程式碼，Operations 仍可能在正式發布時遭遇災難性的問題。這是因為營運學習往往發生在軟體生命週期太晚的階段。

Google 的做法#

Google 採取的策略是讓開發團隊先自行管理其生產服務，之後才有資格交由集中式 Ops 團隊（SRE）接手管理。這確保了：

• 開發者負責部署和生產支援，更可能實現平順的轉交
• 服務必須在開發者自行管理至少六個月後，才有資格獲派 SRE

定義上線要求#

為防止問題服務進入生產環境並造成組織風險，我們需要定義上線要求（Launch Requirements），包括：

• 缺陷數量與嚴重程度：應用程式是否按設計運作？
• Pager 警報的類型與頻率：是否產生難以承受的警報量？
• 監控覆蓋率：出問題時是否有足夠的監控來恢復服務？
• 系統架構：服務是否足夠鬆耦合以支持高頻率變更與部署？
• 部署流程：是否有可預測、確定性且充分自動化的部署流程？
• 生產衛生（Production Hygiene）：是否有足夠好的生產習慣讓他人也能接管支援？

服務交還機制（Service Handback）#

對於已在生產中的服務，我們需要一個服務交還機制——當服務變得過於脆弱時，Operations 有權將生產支援責任退回給開發團隊。

這個機制是一個壓力釋放閥，確保 Operations 不會陷入管理脆弱服務的困境，同時確保他們有足夠的能力投入改善和預防性工作。

案例：Google 的 LRR 與 HRR#

Google 建立了兩套安全檢查機制：

• Launch Readiness Review (LRR)：在新服務對客戶公開之前必須完成
• Hand-Off Readiness Review (HRR)：在服務轉交給 Ops 管理狀態時執行，標準比 LRR 更嚴格

這些檢查清單隨時間演進，讓每個團隊都能受益於所有先前發布的集體經驗。Tom Limoncelli 指出：「最快獲得 HRR 生產審核通過的團隊，是那些從早期設計階段就與 SRE 合作的團隊。」

使用異常偵測技術#

當生產資料不符合高斯分布時，傳統的三個標準差規則會導致過度警報或不足警報的問題。

許多生產資料集呈現非高斯分布（例如卡方分布）。Dr. Nicole Forsgren 解釋：「在 Operations 中，許多資料集是卡方分布。使用標準差不僅會導致過度或不足警報，還會產生無意義的結果。」

平滑化技術（Smoothing）#

移動平均（Moving Averages）可以平滑短期波動，突顯長期趨勢或週期。

更進階的過濾技術包括 Fast Fourier Transform (FFT) 和 Kolmogorov-Smirnov 檢定，後者常用於比較週期性或季節性資料中的差異。

案例：Netflix 的自動擴展（Scryer）#

Netflix 開發的 Scryer 工具透過預測客戶需求模式來提前配置所需容量，解決了 Amazon Auto Scaling 的三個問題：

1. 需求急速飆升時，AWS 實例啟動太慢，算力來不及應對
2. 故障後需求急降導致過度移除算力
3. 未考慮已知的使用流量模式

Scryer 利用離群值偵測、FFT 和線性回歸來平滑資料，同時保留合法的流量尖峰，實現了驚人的預測準確度。

案例：進階異常偵測#

Kolmogorov-Smirnov 檢定是一種非參數技術，不對正態性或任何機率分布做假設，非常適合 Operations 資料。它透過比較兩個機率分布來發現週期性資料中的差異。

使用 K-S 檢定後，系統能偵測到三個標準差規則遺漏的異常交易量下降，在問題影響客戶之前就發出警報。

結論#

本章討論了在日常工作各階段改善服務的回饋機制：部署變更到生產環境、出問題時修復程式碼、讓開發者跟隨工作到下游、建立非功能需求，甚至將問題服務交還給開發團隊自行管理。透過建立這些回饋迴路，我們讓生產部署更安全，提升程式碼的生產就緒程度，並在 Dev 與 Ops 之間建立更好的合作關係。