第三章在講風險，開頭再度強調了「不該追求極端的可靠性」，我們必須考慮機會成本——可靠性的成本並非線性成長，多追求一個級別的提昇（例如 99% 提昇至 99.9%）說不定成本要提高百倍才做得到，甚至，好不容易達成後對使用者來說根本沒差
怎麼看風險？
可靠性（或者說對故障的容忍程度）是靠風險管理得出的結果。風險是一個非線性的連續體(continuum)的概念，我們要問的問題是：服務合理的風險是多少？
合理的風險更像是一個可選的區間，透過衡量「成本」、「業務風險」與「維運風險」對應後我們可以再選出一個目標值
怎麼量化風險？
故障導致的業務風險很難量化（例如媒體大肆報導導致退訂），最直接的作法是參考指標（延遲、停機時間、請求成功率等）
拿停機時間來看——可用性水準訂為 99.99%，一年當中可以接受的停機時間就是 52.56 分鐘
但對分散式服務來說，停機可能是很久才會發生一次的（較難追蹤校正），可以改用請求成功率——可用性水準訂為 99.99%，如果一天要接受 2.5 M 個請求，錯誤數量少於 250 個即可（要注意不同請求的重要性不同，直接面向使用者的請求會更重要）
可用性目標應該多久更新一次？訂定的依據是什麼？
通常以一季為單位來訂，每週或每天追蹤其變化
成本考量很重要，舉了一個很好的比較：Gmail 跟 Youtube——Gmail 定的可用性目標很高，因為如果服務中斷，會導致大量成本及嚴重後果（例如包含許多企業在內的使用者流失）；反之，為 Youtube 設定的可用性目標較低，因為快速發展更重要
可以思考下列這些問題：
- 使用者是誰？他們期望怎樣的服務水準？
- 服務是否直接關係到收入？（公司的收入或客戶的收入都算）/ 是付費還是免費？
- 競爭對手的服務水準如何？
- 多一個「9」，收益增加多少，成本增加多少？
- 服務是否為基礎設施？服務水準是否可以適用各個業務端？
如果難以訂定，可以參考「ISP 的服務錯誤率」（大約 0.01%-1%），只要可用性優於此基礎，故障就會被網際網路的噪音(noise)掩蓋掉
持續發生的零星故障 / 全網中斷哪個更糟糕？
看情況。不同故障類型不能以同樣方式來量化，要考慮不同故障會對業務端造成多大影響
同一個服務怎麼滿足不同類型的使用者？
有時服務的特性是雙面刃，書上舉了 BigTable 為例：要低延遲，利用率愈低愈好（可以更快處理），但要低成本，利用率愈高愈好（避免閒置）
我自己在使用 BigTable 也遇過這種競爭約束（competing constraints）的情況：同一個應用要服務 streaming 跟 batch 這兩種不同場景
書上提供一個解決方式：用戶隔離——低延遲使用者跟離線分析使用者分別使用不同叢集
注意：Dev/Ops 的矛盾也會出現在 SRE 與產品研發部門身上
要彌補這種落差（各種人的因素），最好是透過數據來達成共識——例如，兩個部門共同定義一組以 SLO 為基礎的單季錯誤預算
錯誤預算是一個很好的決策協調依據
怎麼計算、運用錯誤預算？
- 定義出 SLO，例如定義可容忍的停機時間 Q
- 追蹤、測量實際停機時間 P
- 計算錯誤預算 B = Q – P，如果 B > 0，代表還有剩餘的預算，就可以拿來發行新版本
也就是說，只要系統符合 SLO，就可以繼續發行新版本；如果頻繁違反 SLO，就減慢、暫停發布作業或甚至將服務退回上一版本
SLI、SLO、SLA
這章更深入討論了三個概念的細節和根本差異。就英文字來看，其實很容易理解：指標（測量什麼）、目標（測量值應該低於多少）、協議（違反目標有什麼後果）
最關鍵的 SLI 是延遲（由於使用者延遲端難以取得，通常會用伺服器端的延遲）
；其他指標包含請求錯誤率（多少請求失敗）、QPS、可用性等，甚至是想辦法取得的特殊資料（例如在瀏覽器埋追蹤工具）
通常最難的是怎麼訂 SLO，但不管怎樣，SLO 一定要有，這樣所有人（包含使用者）的預期才會一樣
因為牽扯到政策、罰款，決定 SLA 通常不是 SRE 的事。要注意的是，當我們講到 SLA，很多時候討論的其實是 SLO
如果服務被廣泛依賴又不太容易故障怎麼訂 SLO？
這邊以 Chubby 舉例，如果每季真實的故障沒有違反 SLO 的話，SRE 會故意弄一個可控的故障讓服務停機，藉此找出依賴端的問題
要用哪些指標？幾個指標才夠？
不要將監控系統的所有指標都列為 SLI，通常 4-5 個有意義（瞭解使用者的需求）的指標就夠了
最好是可以固定一套定義方法：
- 測量頻率： 10 秒一次
- 彙總間隔： 60 秒一次
- 彙總範圍：叢集的所有任務
- 包含哪些請求：從監控端發來的 HTTP GET
- 資料來源：透過監控系統訪問服務伺服器取得
- 延遲定義：服務收到請求至最後一個位元組被送出
指標怎麼彙總/分析？
取平均值會導致某些極端數據變化被淡化
多數的指標都應該採分佈統計（distributions）：例如看 50/85/95 百分位，高百分位代表最差情況
回應時間的分佈越分散，表示使用者受到長尾延遲（long-tail latency）的影響愈明顯
訂 SLO 要注意什麼？
這章的結尾提供了一些建議，首先是 SLO 愈少愈好（如果產品開發團隊無法接受某個 SLO，那就不必要）
一開始可以先訂一個比較鬆散的目標，再後期慢慢調整收斂，會比一開始就訂過高的目標來得好
如果 SLO 會公開給使用者知道，對外公開的目標可以比內部的目標還低，保留一點彈性空間
怎麼實際運用 SLO？
除了每季的評量，在日常追蹤 SLI 的時候，也需要參考 SLO，才能知道我們當前該不該行動，例如請求延遲一直上升快超過 SLO 了，就該立即做 scale out 提昇負載能力
減少瑣事
「如果正常運轉的系統需要人為干預，該將此視為一種 Bug。」
什麼是瑣事（toils）？
只跟日常維運工作中有關，有以下特性：手動、重複性、可被自動化、無長遠價值
就統計，瑣事最大來源是 interrupts （非緊急），其次是 on-call（緊急），再來是版本發行和資料更新
流程開銷（Overhead）不是瑣事，例如工作檢討、人員招聘、會議
監控系統
Google 傾向使用簡單的監控系統進行事後分析(post hoc analysis)，而不是仰賴 AI
每個 SRE 團隊一般至少有一位「監控專員」
監控系統信噪比要很高，噪音太多或警報太頻繁，員工會進入「狼來了」效應，懷疑警報的有效性，甚至忽略該警報
監控系統應該指出兩個問題：What（現象）、Why（原因）——例如「頁面響應 500/404，因為資料庫拒絕連線」——Why 可以是中間原因，不一定要是問題根源
監控可分成白箱（內部）、黑箱（外部），黑箱通常很少會用到，因為只能反映「現象」，要看到「原因」得依賴白箱
為什麼要監控？
- 分析長期趨勢，例如「使用者下個月會成長多少？」
- 時間範圍比較，例如「網站是否比上週快？」
- 臨時(ad hoc)的回溯分析 / debugging，「剛剛延遲增加了，有沒有其他現象同時發生？」
- 發出警報
- 建構儀表板來回答一些重要問題
哪些指標是必要的？
延遲、流量、錯誤率（包含顯式如500、隱式如200但包含錯誤訊息、其他策略性錯誤如響應超出1秒）、飽和度（即容量有多滿）
監控這四個指標並設定警報，是監控系統的基本要求
測量頻率怎麼決定？
系統不同部位應該以不同精度測量。須要考慮成本、服務可用性
例如：對一年停機小於 9 小時的服務（可用性 99.9%），每分鐘一次以上的監控頻率可能太頻繁
監控系統的設計原則
- 規則愈簡單愈好
- 不常用的資料收集、彙總、警報應該定期清理（例如一季沒用到就刪除）
- 只收集但沒有在儀表板顯示或拿來設定警報的規則應定期清理
短期調整還是長期修復？
舉了早期的 BigTable 爲例，先降低 SLO 讓人員有時間去解決真正的問題
另一方面舉了早期 Gmail 為例，有一個 Bug 難以修復，選擇用一個短期 workaround 去解決，但在內部造成反對聲音（有人不想留技術債）
這種衝突是很平常的，找上級討論也許是個好做法
自動化的價值
自動化大部分的好處我們都說得出來（一致性、節省時間）
這邊提到一個特別有趣的觀點，就是「自動化提供一個 platform」：有錯誤只需要修正一次就可以長期適用、可以擴張、有經濟效益
另外一個讓我很有感的價值是「自動化讓我們更深入理解現有流程」
自動化不是萬靈丹。永遠有個最後的理想方案：自治系統（autonomous system）
不是每個系統都適合自動化，例如prototype
對 SRE 而言，用自動化管理的是系統的生命週期（例如部署新的叢集），而非系統內部的資料
Google SRE 用什麼工具？
Puppet、Chef、cfengine：直接操作服務、higher-level abstractions
Perl：支援 POSIX，在系統的 API 層有很好的擴充性
在較上層做操作、封裝好處是易於理解/管理，但代價就是做得不好（leaky abstraction）的時候容易出 bug
尤其實務上會遇到的問題是很複雜的：網路斷線、系統不一致，每個步驟都可能卡住。通常這時候自動化模型只能中止並請求人為干預
內化的自動化更好
與其透過外部膠合（glue）來操作，不如系統自己來做更正確、有效率
這種膠合也是一個問題，例如透過自動化腳本去呼叫服務的 API，但服務更新到下一版後，API 變了，外部腳本也要跟著改
這邊我的理解是某些封裝（抽象）還是盡可能做在系統內部比較好，我可以想到的例子類似在容器映像檔提供的特定腳本（例如 postgresql 提供 update.sh）
當然書中說的自動化演進最終目標是自治，而不只是一連串的腳本，也就是說，解決方案已經內化到程式裡了，例如最佳案例：Borg
成功案例：MoB
Google 想把 MySQL 服務移植到 Borg 上，藉此提高資源利用率/減少成本
克服的難點是移轉的時間：master 移轉時間太長（30-90min），常須人為介入
Google 成功弄了一個自動故障移轉的程式將時間縮短到 30s（滿足錯誤預算），成功後維運成本下降 95%，硬體成本下降 60%
成功案例：自動上線叢集
初期：用 Python 做 Prodtest
Google 會在大量機台上安裝 DNS（同時需要頻繁變動與更新），要確保每個細部設定都是正確的
解法是叢集為單元去跑一連串的 Python 的單元測試（測試有順序，失敗就終止），後來甚至為每個環節都加上了自動修補腳本
雖然有解決當前問題，但更像是 workaround ，因為這種在正式環境的自動修補，其實會讓系統處在不穩定（flaky）的狀態
後期：改以服務導向
因應安全須求，SRE 的權限被降到最低，不再有 root 操作權限
解決方式是認知到這是一個服務導向架構 (SOA)，須由服務擁有者建立一組 admin server 提供管理 API（以 ACL 為基礎的認證服務，取代直接 ssh，會記錄所有 RPC 請求和響應），再由 SRE 來呼叫
看到這章的最後，其實對自動化的理解有蠻多改觀的：「自動化只是自治系統的必經之路」
我們甚至也不用擔心高度的自動化會讓人愈來愈難以介入操作（經驗剝奪），因為在未來的自治系統已不需要任何的手動操作