本章探討 SRE 實踐如何從 Google 內部擴展到外部客戶與更廣泛的業界。隨著越來越多公司採用 SRE 原則，一個重要的趨勢浮現：你與客戶之間的界線需要變得模糊。當你的產品成為平台，可靠性就不再只是你自己的事，而是與客戶的合作關係。
我們認為不證自明的真理#
可靠性是最重要的功能#
這個論點很簡單：
- 如果系統不可靠，使用者不會信任它
- 如果使用者不信任系統，有選擇時他們不會使用它
- 所有軟體系統都受網路效應支配，沒有使用者的系統毫無價值
- 你就是你所衡量的，所以要謹慎選擇指標
使用者而非監控決定你的可靠性#
唯一重要的可靠性衡量標準是使用者如何體驗可靠性。如果你的使用者擔心你的平台造成了他們正在經歷的不穩定，告訴他們「我們的監控看起來沒問題，問題一定在你那端」不會讓他們滿意。這就是所謂的峰終定律（peak-end rule）——他們體驗到的不穩定就是他們在選擇競爭對手時會記住的。
你的監控、日誌和告警的價值僅在於幫助你在客戶之前發現問題。
如果你運營平台，可靠性就是合作關係#
當產品只透過視覺介面（如網頁）由人類使用者消費時，使用者體驗的可靠性幾乎完全取決於你的工作。但一旦加入 API、部分「使用者」是機器，你就在運營一個平台，規則隨之改變。
當客戶在你 99.999% 可用性的平台上建構只有 99% 可用性的系統時，他們的最佳體驗是 98.99901%。他們做的選擇直接影響他們的體驗，但他們會將所有體驗歸因於你的服務——即使不是「你的錯」。
一切重要的東西最終都會成為平台#
隨著系統價值隨使用者增長，你會想觸及其他大型使用者群體。其他系統也會想透過 API 觸及你的受眾。即使你決定不建立機器可消費的 API，其他人也會包裝你的 UI 成為 API 來消費——唯一的區別是你無法控制結果。
當客戶遇到困難時，你必須放慢腳步#
客戶的挫折會成為你的摩擦力。即使沒有傳統支援管道，你仍會花時間在 StackOverflow、Twitter、Facebook 等平台上分類問題和回應投訴。投入幫助客戶的精力就是無法投入推進系統的精力。
許多團隊（和公司）讓時間慢慢被客戶的故障/修復問題吞噬，導致創新預算不斷萎縮。這些團隊被 toil 消耗殆盡。一旦陷入這種狀態，很難脫身（參見第 6 章）。
這同樣適用於內部平台團隊——你的客戶就是公司內部消費你系統的團隊，而且你更可能最先遇到這個問題。
你需要與客戶一起實踐 SRE#
如果你希望客戶在你的平台上設計和運營可靠的系統，你必須教他們怎麼做。即使你能完美地將知識濃縮成高擴展性的內容（書籍、部落格、影片等），你仍然需要一種方式來了解應該包含什麼內容。隨著平台成長和改進，這些課程會改變。
最好的學習方式是與客戶一起「做 SRE」。這不一定意味著接管客戶系統的 pager，但需要進行大部分通常在 pager 交接之前的工作（即系統已達到最低可行可靠性要求）。
如何與客戶一起做 SRE#
步驟 1：SLO 和 SLI 是你的溝通語言#
你的生活會好得多，如果客戶使用 SLI 來衡量、根據 SLO 來告警，並與你分享這些衡量結果。否則你會花大量精力在這樣的對話中：
客戶：API 呼叫 X 通常花費時間 T，但現在花費時間 U。我們認為你有問題。 你：效能看起來符合我們的預期，我們這邊一切正常。 （對話陷入循環，永遠無法得到滿意的答案）
更好的對話方式是：
客戶：我們的應用程式 FOO 的 SLO 消耗速度太快，SLI X 和 Y 都崩了，它們都依賴你的 API X。 你：好的，讓我看看 API X 在我們系統中的表現。
這種對話更有效率，因為：(a) 只在 SLO 受到威脅時才發生，(b) 依賴雙方理解的指標和目標。
建議的簡單練習：與客戶坐下來，解釋 SLO、SLI 和 error budget，特別是你如何在團隊中實踐它們，然後幫助他們用這些術語描述在你平台上構建的關鍵應用程式。記住，在沒有明確 SLO 的情況下，客戶會不可避免地自己發明一個，而且不會告訴你，直到你不符合為止。
步驟 2：審計監控並建立共享儀表板#
客戶選定基本 SLO 後，下一步是確認他們是否在衡量正確的東西。根據經驗，高達一半的客戶衡量（和告警）對其 SLO 毫無影響。指出這一點並幫助他們關閉無關告警，對雙方都有益。
具體步驟：
- 幫助客戶將有用的衡量組裝成 SLI 以計算 SLO
- 找出 SLO 中未被覆蓋的部分，幫助客戶補齊
- 建立共享的 SLO 儀表板——雙方都能看到應用程式的 SLO 表現以及相關的系統效能資訊
- 目標：當客戶因 SLO 受威脅而聯繫你時，不需要額外交換太多資訊
步驟 3：衡量與重新協商#
收集一兩個月的資料後，客戶可能會有一個殘酷的覺醒：他們以為運行在「五個 9」（99.999%）的應用程式，實際上可能只達到 99.5%–99.9%。
初始震驚過後，這是指出「使用者並沒有一直在抱怨，所以你可能從來不需要一直沒有真正達到的五個 9」的好時機。
關鍵問題是：使用者對應用程式效能的滿意度如何？ 如果使用者滿意，且沒有證據顯示改善效能會增加使用者採用/留存率，那就完成了。定期重新評估以確保預算和優先級仍然正確。
步驟 4：設計審查與風險分析#
深入了解客戶的應用程式設計和運營方式：
- 是否有隱藏的單點故障（SPOF）？
- 部署和回滾是否手動？
- 本質上就是對你自己內部應用程式進行的相同審查
按每個問題消耗的 error budget 排序，觀察客戶選擇修復哪些項目來「賺回」他們想要的可靠性等級。從這些審查中你能學到：
- 客戶如何使用你的平台
- 他們在使用時犯了哪些可靠性錯誤
- 他們在嘗試改善時選擇了哪些取捨
這也幫助客戶對其當前應用程式應有的可靠性設定合理預期，進而影響他們的感知，有助於贏得和保持他們的信任。
步驟 5：練習、練習、再練習#
與客戶建立操作紀律：
- 進行模擬問題練習（Wheel of Misfortune、災難恢復測試、紙上演練等）
- 建立團隊間在危機時有效溝通的健康肌肉記憶
- 不僅分享事後分析，還要進行聯合事後分析（joint postmortems）
- 這些練習能建立信任、降低 MTTR、發現可以整合為平台功能增強的營運邊界案例
要有策略且有紀律#
很快你就會發現不可能與所有客戶執行這些步驟。不要嘗試將此模型擴展到每個人。應基於原則做出選擇，常見方法包括：
- 營收覆蓋（Revenue coverage）：選擇最少數量的客戶以涵蓋 XX% 的營收。適合營收集中在少數大客戶的情況。
- 功能覆蓋（Feature coverage）：選擇最少數量的客戶以涵蓋 XX% 以上的平台功能。適合平台高度多樣化、有長尾客戶做各種不同事情的情況。
- 工作負載覆蓋（Workload coverage）：平台使用可能由少數明確的使用案例或客戶類型主導。從每個群組取樣一到兩個客戶是獲得平台覆蓋和發現使用案例間操作差異的好方法。
無論選擇哪種方法，都要堅持使用。混合匹配會讓利害關係人困惑，並迅速壓垮你的團隊。
結論#
過去幾年，SRE 職業和角色已廣泛傳播到 Google 之外。隨著組織採用 SRE 原則，將會經歷許多與 Google 相同的拐點——包括需要模糊客戶結束和你開始的界線。在這種操作深度上與個別客戶合作是一個令人期待的新疆界，而 Google 自身也仍在這條路上前進。越走越遠，就越確信這是你也需要踏上的旅程。