前言
這篇文章是《SRE實戰手冊》學習筆記的第二篇，理解SRE之后，就要找到切入點來落地。
理解SRE中的指標和目標
SRE強調穩定性，一般是看整體的系統情況，也就是常說的"3個9"、"4個9"這樣可量化的數字。
這個“確定成功請求條件，設定達成占比目標”的過程，在SRE中就是設定穩定性衡量標准的SLI和SLO的過程。
1、SRE的兩個核心
SLI(Service Level Indicator)：服務等級指標，即選擇哪些指標來衡量穩定性（狀態碼為非 5xx 的比例）；
SLO(Service Level Objective)：服務等級目標，指設定的穩定性目標（大於等於 99.99%）；
落地SRE的第一步：選擇合適的SLI，設定合理的SLO，SLO是SLI要達成的目標。
監控體系是SRE體系中很重要的組成部分，也是最直觀的指標產出展示方式。
2、常見的監控指標
3、選擇監控指標的考量點
兩個因素
- 要衡量誰的穩定性？即先找到穩定性主體；
- 這個指標能夠標識這個實例是否穩定嗎？
兩大原則
- 選擇能夠標識主體是否穩定的指標，如果不是該主體本身或不能標識主體穩定性的指標，就要排除在外；
- 針對電商這類有用戶界面的業務系統，優先選擇與用戶體驗強相關或用戶可以明顯感知的指標；
4、快速識別SLI指標的方法
VALET是5個單詞的首字母，分別是Volume、Availability、Latency、Error 和 Ticket。
1）Volume-容量：指服務承諾的最大容量是多少。比如一個應用集群的 QPS、TPS、會話數以及連接數；
2）Availablity-可用性：代表服務是否正常。比如請求調用的非 5xx 狀態碼成功率，就可以歸於可用性；
3）Latency-時延：指響應是否足夠快，這是會直接影響用戶體驗的指標。時延的分布符合正態分布，建議以類似“90%RT<=80ms，或者 95%RT<=120ms”這樣的方式來設定時延SLO的置信區間。設定不同的置信區間來找出這樣的用戶占比，有針對性地解決；
4）Errors-錯誤率：錯誤率有多少？除了 5xx之外，還可以把 4xx列進來，或增加一些自定義的狀態碼，看哪些狀態是對業務有損的，來保障業務和用戶體驗；
5）Tickets-人工介入：是否需要人工介入？如果一項工作或任務需要人工介入，那說明一定是低效或有問題的，這里可以將tickets理解為門票。
一個周期內，門票數量是固定的，比如每月 20 張，每次人工介入，就消耗一張，如果消耗完了，還需要人工介入，那就是不達標了。
5、Google-VALET-dashboard
6、如何通過SLO計算系統可用性
系統可用性Availability = Successful request / Total request，常見的計算方式有如下兩種：
1）根據成功的定義來計算：Successful =(狀態碼非 5xx)&(時延<=80ms)；
2）SLO方式計算：Availability=SLO1&SLO2&SLO3（即綜合維度的指標衡量）；
SLO1：99.95%狀態碼成功率；
SLO2：90%RT<=80ms；
SLO3：99%RT<=200ms；
對系統相關監控指標要分層，識別出我們要保障穩定性的主體（系統、業務或應用）是什么，然后基於這個主體來選擇合適的 SLI 指標。
不是所有的指標都是適合做 SLI 指標，它一定要能夠直接體現和反映主體的穩定性狀態。可以優先選擇用戶或使用者能感受到的體驗類指標，比如時延、可用性、錯誤率等。
達成穩定性目標的共識機制
知道了SRE的核心是設定目標和指標，但在具體落地過程中，該如何找到切入點呢？反過來看，可以制定一個允許犯錯的次數標准，只需要去監控這些錯誤，就是一個很好的落地切入點。
1、設定錯誤預算
允許犯錯的次數標准在SRE體系中叫做Error Budget，即錯誤預算。錯誤預算其實和駕照記分制是一樣的，最大的作用就是“提示你還有多少次犯錯的機會”。
錯誤預算的計算方式通過SLO推導得到，參考計算公式：Availability=SLO1&SLO2&SLO3。
2、如何應用錯誤預算
2.1穩定性燃盡圖
特點：盡可能直觀的將錯誤預算表現出來，隨時可以看到它的消耗情況。同時加入錯誤預算消耗告警，如達到80%時開始預警，通過控制各種變更等手段來降低預算消耗頻次。
參考：Google的錯誤預算燃盡圖
注意事項：
- 應用錯誤預算，應該設定合理的周期，推薦4個自然周；
- 要考慮到特殊場景如雙11大促，如果這些特殊場景處在某個考核周期內，應適當放大錯誤預算的值；
2.2故障定級機制
判斷一個問題是不是故障，除了看影響時長，還有一點就是按照問題消耗的錯誤預算比例來評估。
通過錯誤預算來定義故障等級就可以做到量化，一旦可以被量化就意味着可以標准化，有了標准就可以進而推進達成共識。
參考：業內常見的故障定級維度和定義
P0：系統中斷1小時以上，造成大范圍的用戶不可用；
P1：系統中斷30分鍾到1小時，造成部分用戶不可用；
P2：系統核心模塊或功能出問題，造成大量用戶投訴；
P3：系統次要模塊或功能出問題，造成部分用戶投訴；
P4：便於模塊或功能出問題，未導致不可用或投訴，但影響用戶體驗；
其他維度：如造成公司資產損失超過一定額度或者企業品牌受影響，這些因素要綜合考慮！
2.3穩定性共識機制
由於每個人對穩定性的認知不同，因此通過建立穩定性共識機制並且積極推動，也是一種很好的實踐方式。
參考：推動穩定性共識機制的2個指導原則
- 預算充足或者未消耗完之前，對問題的發生要有容忍度；
- 剩余預算消耗過快或即將消耗完之前，SRE 有權中止和拒絕任何線上變更；
從推行的角度來講，涉及到跨團隊溝通共識機制。建立穩定性共識機制一定是 Top-Down，也就是自上而下，至少要從技術 VP 或 CTO 的角度去推行。
而且當有意見不一致的情況出現時，還要逐步上升，直至 CTO 角度來做決策。一定要自上而下推進周邊團隊或利益方達成共識。
2.4基於錯誤預算的告警
監控告警有一點很重要的是告警降噪收斂。即不要被“狼來了”的告警搞定疲憊不堪，要有對應的處理機制。
參考：常見的告警降噪收斂方案
- 告警合並：即相同或相似的告警，合並后發送；
- 基於錯誤預算告警，即只關注對穩定性造成影響的告警，如“單次問題錯誤預算消耗超過20%”；
3、如何衡量SLO的有效性
衡量 SLO 及錯誤預算策略是否有效，就是看實際運行后是否真的能達到我們的期望。見下面三個關鍵維度：
- SLO達成情況：用達成（Met），或未達成（Missed）來表示。
- "人肉"投入程度：英文表示為Toil，泛指需要大量人工投入、重復繁瑣且沒有太多價值的事情。用投入程度高(High)和低(Low)來表示；
- 用戶滿意度：Customer Satisfaction，可理解為用戶體驗，通過真實和虛擬的渠道獲得。真實渠道如客服投訴、客戶訪談和輿情監控獲取；虛擬渠道如真機模擬撥測。用投入程度高(High)和低(Low)來表示；
參考：不同維度不同情況的應對策略
針對上述的幾種情況，將這些策略總結起來，主要有如下三種策略：
3.1收緊SLO
原因為目標設定太低，即SLO達成(Met)，但是用戶不滿意(Low)，常見表現方式為客訴增多或內部吐槽變多；
3.2放寬SLO
原因為目標設定太高，SLO達不成(Missed)，但用戶反饋很不錯(High)，這樣會造成錯誤預算提前消耗完，導致很多變更暫停，產品延期，甚至會做一些無謂的優化，這時可以適當放寬SLO；
3.3保持現狀，對有問題的維度采取針對性的優化
在SLO可以達成的情況下，盡量提升用戶價值交付效率，圍繞這個終極目標，不斷優化自己的SLO和錯誤預算策略。
落地SLO時要考慮的因素
1、確定核心鏈路SLO
所謂核心鏈路，即某個系統為用戶提供業務價值的主流程。
以電商系統來說，導購-搜索-商品詳情-購物車-下單-支付即為核心鏈路。
指導原則：先確定核心鏈路的SLO，然后根據核心鏈路進行SLO拆解。
1.1確定核心鏈路
通過全鏈路跟蹤的技術手段來找出所有應用，即呈現出調用關系的系統拓撲圖。
常見工具：cat、jaeger、zipkin、pinpoint、skywalking。
1.2確定核心應用
根據業務場景和特點，從繁雜的應用中通過不斷討論和分析來確認核心應用。
以電商系統為例，核心應用一般有index、search、product、order、coupom、payment等。
參考：核心交易鏈路圖
1.3確認強弱依賴
核心應用之間的依賴關系，稱之為強依賴，而其它應用之間的依賴關系，我們稱之為弱依賴。
其中包含兩種關系，一種是核心應用與非核心應用之間的依賴，另一種是非核心應用之間的依賴。
當然，還可以通過其他方式確認強弱依賴關系，比如：是否可以直接熔斷等。
2、設定SLO的四大原則
2.1核心應用的SLO要更嚴格，非核心應用可以放寬。 這么做是為了確保SRE精力能夠更多地關注在核心業務上；
2.2強依賴之間的核心應用，SLO要一致。 如下單的 Buy 應用依賴 Coupon 這個促銷應用，我們要求下單成功率的 SLO 要 99.95%，就會要求 Coupon 的成功率 SLO 也要達到 99.95%；
2.3核心應用對非核心的弱依賴，有降級、熔斷和限流等服務治理手段。 這樣做是為了避免由非核心應用的異常而導致核心應用 SLO 不達標；
2.4核心應用錯誤預算要共享，如果某核心應用錯誤預算消耗完，那整條鏈路原則上都要停止變更操作。
可以根據實際情況適當寬松，如果某核心應用自身預算充足，且變更不影響核心鏈路功能，可以按照自己的節奏繼續做變更。
3、如何驗證核心鏈路SLO
3.1容量壓測
容量壓測的主要作用，就是看 SLO 中的 Volume，也就是容量目標是否可以達成。
另一個作用就是看在極端的容量場景下，驗證限流降級熔斷等服務治理策略是否可以生效。
3.2Chaos Engineering-混沌工程
混沌工程可以幫助我們做到在線上模擬真實的故障，做線上應急演練，提前發現隱患。
容量壓測是模擬線上真實的用戶訪問行為，混沌工程是模擬故障發生場景，主動產生線上異常和故障。
混沌工程是 SRE 穩定性體系建設的高級階段，一定是 SRE 體系在服務治理、容量壓測、鏈路跟蹤、監控告警、運維自動化等相對基礎和必需的部分非常完善的情況下才能考慮。
4、如何選擇系統驗證的時機
參考：Google的建議
4.1錯誤預算充足就可以嘗試，盡量避開錯誤預算不足的時間段。因為在正常業務下，我們要完成 SLO 已經有很大的壓力了，不能再給系統穩定性增加新的風險。
4.2評估故障模擬帶來的影響，比如，是否會損害到公司收益？是否會損害用戶體驗相關的指標？如果造成的業務影響很大，那就要把引入方案進行粒度細化，分步驟，避免造成不可預估的損失。
4.3選擇業務量相對較小的情況下做演練。這樣即使出現問題，影響面也可控，而且會有比較充足的時間執行恢復操作，同時在做全鏈路壓測之前，先進行單鏈路和混合鏈路演練，只有單鏈路全部演練通過，才會執行更大規模的多鏈路和全鏈路同時演練。
4.4生產系統穩定性在任何時候，都是最高優先級要保證的。不能因為演練導致系統異常或故障，這是不被允許的。所以，一定要選擇合適的時機，在有充分准備和預案的情況下實施各類驗證工作。