本章探討組織變革管理（Organizational Change Management）理論如何在 SRE 團隊中實際應用。在回顧幾個關鍵的變革管理理論後，透過兩個案例研究展示不同風格的變革管理如何在 Google 中具體發揮作用。

本章所討論的「變革管理」指的是準備和支援個人、團隊與業務單位進行組織變革的所有方法，而非專案管理中的變更控制（change control）流程。

SRE 擁抱變革#

產品團隊存在的目的是建構產品、推出功能、取悅客戶。在 Google，大多數變革都是快節奏的，遵循「發佈並迭代」（launch and iterate）的方法。SRE 經常身處這個複雜且快速變化的環境中，負責在變革固有的風險與產品可靠性和可用性之間取得平衡。Error Budget 是實現這種平衡的主要機制。

變革管理理論概覽#

Lewin 的三階段模型#

Kurt Lewin 的「解凍-變革-凍結」（unfreeze-change-freeze）模型是最古老的變革管理理論。三個階段分別是：說服群體變革的必要性、執行變革、將新的行為模式制度化。此模型最適用於宏觀層面的組織變革規劃。

McKinsey 7-S 模型#

七個 S 代表：結構（Structure）、策略（Strategy）、系統（Systems）、技能（Skills）、風格（Style）、人員（Staff）和共享價值（Shared Values）。此模型涵蓋商業要素和人員管理要素，適用於考慮從傳統系統管理轉型到 SRE 方法的團隊。

Kotter 的八步驟變革流程#

Kotter 的流程對 SRE 團隊和組織特別相關。值得注意的是，在許多情況下（如後續的 Waze 案例），不需要刻意「創造緊迫感」——SRE 團隊面對加速增長的產品和系統，經常遭遇緊迫的擴展、可靠性和運維挑戰。SRE 因為經常站在問題發生的第一線，具有獨特的動機來領導確保產品全天候可用所需的變革。

Prosci ADKAR 模型#

ADKAR 是個人必須達成的目標的縮寫：Awareness（認知）、Desire（意願）、Knowledge（知識）、Ability（能力）和 Reinforcement（強化）。此模型提供以人為中心的框架，但在 SRE 中的適用性有限，因為運維責任通常施加相當大的時間壓力。不過，Google 已成功將 ADKAR 式流程用於引入高層級的組織變革。

情緒導向模型#

• Bridges Transition Model：描述人們對變革的情緒反應，是人員管理者的有用工具
• Kubler-Ross Change Curve：描述面對變革時人們可能經歷的情緒範圍，有助於在變革期間維持員工生產力

Deming 循環 (PDCA)#

Plan-Do-Check-Act 循環常用於 DevOps 環境中的流程改進，但不適合組織變革管理，因為它不涉及變革的人性面，頻繁劇烈的組織架構變動會削弱員工信心。

理論如何應用於 SRE#

• Kotter 的八步驟流程：適用於將變革視為核心責任的 SRE 團隊
• Prosci ADKAR 模型：SRE 管理層可考慮用於協調跨全球分佈團隊的變革
• Bridges 和 Kubler-Ross 模型：所有 SRE 主管都應熟悉，以在組織變革時支持員工

案例研究 1：Waze 的擴展——從臨時應對到計劃性變革#

背景#

Waze 是一款社群導航應用程式，2013 年被 Google 收購後經歷了活躍用戶、工程人員和運算基礎設施的顯著增長，但繼續在 Google 內部相對自主地運作。Waze 的自主權和新創精神使他們以草根式的技術回應來應對挑戰，而非管理層主導的結構化組織變革。然而，回顧來看，他們的方法顯著類似 Kotter 的變革管理模型。

訊息佇列系統的替換#

Waze 的訊息佇列系統是核心基礎設施——每個元件（即時通訊、地理編碼、路線規劃等）都透過它與其他元件通訊。隨著吞吐量顯著增長，系統無法應付日益增加的需求，導致越來越頻繁且嚴重的故障。最嚴重時，整個 Waze SRE 團隊花了近兩週全天候救火，最終不得不每小時重啟訊息佇列的部分元件。

變革過程（對應 Kotter 模型）：

1. 創造緊迫感：SRE 因為運維負擔而無暇支援新功能發布，影響了功能速度
2. 組建引導聯盟：兩位 SRE 和一位資深工程師組成策略小組
3. 形成策略願景：評估現成產品後，決定自建解決方案
4. 移除障礙、招募志願軍：開發團隊自願審查各自的程式碼以減少訊息量，壓縮層和專用佇列贏得了兩個月的喘息空間
5. 短期勝利：先遷移低流量高重要性的訊息流，在舊系統故障時提供備用路徑
6. 大規模遷移：隨著自動化遷移流程的成熟，遷移速度顯著加快
7. 制度化變革：宣佈舊系統棄用，最終新系統承載了舊系統 1000 倍以上的負載

下一個變革循環：改善部署流程#

Kotter 的一個關鍵洞見是變革是一個循環。消除訊息佇列的瓶頸後，新的瓶頸浮現——SRE 獨佔發布流程嚴重阻礙了開發速度。

改善歷程：

• 一位資深開發者建立了微服務框架，SRE 在其中加入可靠性功能
• SRE 開發了一套工具來管理原本昂貴的發布流程
• 儘管發布流程已大幅改善，微服務的激增使 SRE 的整體負擔仍然令人擔憂
• SRE 和開發者共同規劃轉向使用 Spinnaker（開源持續部署平台）的策略
• 建立集中化儀表板展示發布狀態和指標，消除開發團隊對新流程的疑慮
• 最終超過 95% 的 Waze 服務使用 Spinnaker 進行持續部署

Waze 的教訓#

• 變革管理理論不是浪費時間——回顧來看，更正式地應用 Kotter 模型本可幫助精簡流程
• 草根變革需要 SRE 與開發的緊密合作，以及高層領導的支持
• 漸進式變革比一步到位容易管理——先展示早期勝利，證明投資的價值
• 有時現有解決方案無法支撐策略願景——建構新系統成本高昂，但如果能突破局部最佳化並實現長期增長，就是值得的

案例研究 2：SRE 中的通用工具採用#

背景與問題#

Google SRE 發現自己在多個問題領域（監控、發布與推出、事件回應、容量管理等）使用了多個獨立的軟體解決方案來解決近似的問題。這源於工具開發者與使用者和需求脫節，以及各團隊各自打造利基解決方案的長期積累。

決定做什麼#

核心問題：如果所有 Google SRE 都能使用共同的監控引擎和儀表板、共同的發布和推出工具，會如何？

策略是鼓勵對特定問題有專長和意見的工程師組成虛擬團隊，將願景轉化為可運作的軟體，最終在整個 SRE 乃至整個 Google 中被採用。

對應 ADKAR 模型，識別問題和承認機會屬於「Awareness」步驟。Google SRE 領導團隊對需求達成共識（Desire），並擁有足夠的知識和能力（Knowledge & Ability）快速進入設計階段。

設計過程的演進#

初始設計：由專家組成虛擬團隊，投入約 80% 時間在橫向專案上。但發現了痛點：

• 協調跨時區且因 on-call 而注意力分散的虛擬團隊非常困難
• 從共識收集到程式碼審查都受到缺乏集中地點和共同時間的影響
• 橫向專案的人力最初需從現有團隊抽調，減少了各團隊的工程資源

修正後的設計：轉向更熟悉的集中式模型——小型（6-10 人）、敏捷、大部分在同一地點的快速行動團隊，由具有豐富 on-call 經驗但全職專注於軟體開發的資深工程師組成。目標是讓約 60% 的 Google 工程師採用。

實施：監控案例#

Google SRE 的 Viceroy 專案成為事實上的監控和儀表板解決方案。但即使在共同框架下，各團隊仍在建構複雜的自訂儀表板。集中化開發團隊隨後建立了零配置系統（zero-config system），基於常見的服務組織模式提供標準的綜合監控視圖。隨著時間推移，大多數服務遷移至使用這些標準儀表板。

教訓#

• 遷移設計比全新設計更複雜——在不干擾已運行服務的情況下，將許多小型受限系統演化為更少、更通用的系統，是最困難的工程工作
• 建構橫向軟體需要大量傾聽——任務更像產品經理的角色，必須吸收和優先排序使用者需求
• 遷移成本必須接近零——「只需重新編譯就能獲得新功能」，且好處必須明確
• 「Knowledge-to-Ability Gap」：人們需要時間、指導和新工具的培訓才能擁抱變革
• 建構過程的透明度很重要——「如果你建構了很棒的東西，人們自然會來使用」的想法並不成立；專案必須清楚定義、提前宣傳、針對最難搞的採用者測試、遠優於現有選項，且幾乎不費力就能採用
• 採用驅動網路效應——隨著通用工具的規模和覆蓋範圍增加，對這些工具的增量改進對組織更有價值

衡量影響的關鍵問題：新開發者能多快建構和管理全球規模的服務？SRE 能多容易從一個領域轉移到另一個領域？多少服務可以用相同的原語來管理？但首要衡量指標永遠是採用率。

結論#

即使在同一家公司內，SRE 變革管理也可能需要應對各種問題空間和組織背景。因此，可能沒有單一的正式變革管理模型能完美適用於所有變革。然而，Kotter 的八步驟流程和 Prosci ADKAR 模型等框架可以為變革提供有用的洞見。在 SRE 這樣動態的環境中，所有變革的共同點是持續的重新評估和迭代。雖然許多變革可能以草根方式有機地開始，但隨著變革成熟，大多數都能從結構化的協調和規劃中受益。