SRE團隊職責：
確保服務可以正常運轉，主要方向包括：
- 可用性改進
- 延遲優化
- 性能優化
- 效率優化
- 變更管理 （漸進式發佈）
- 監控
- 緊急事務處理
- 容量規則與管理 （N+2 模式，google--> 15倍）
SRE核心處理思想：
- 災難預演與演習
- 確保系統按照預想方式應對故障
- 尋找系統中未預料的弱點
- 尋找其他提高魯棒性的方式避免事故發生
- 從組織架構層面關注
- 關注細節
- 冗餘容量
- 模擬線上災難演習
- 培訓考覈
- 縱深防禦
- 書寫時候總結
- 究竟發生了什麼？
- 相應的有效速度
- 下次可以採用其他方案解決問題
- 如果避免
- 自動化與降低日常運維負載
- 結構化、理智決策
- 決策是事先決定的
- 決策的信息源是清楚的
- 任何假設都要明確說明
- 數據驅動優於情感驅動
服務可靠性層級模型：
錯誤預算：
1- 可靠性目標
在一個明確的、客觀的指標來決定服務在一個單獨的季度中能接受多少不可靠性。用來控制調節發佈速度
瑣事：手動性、重複性、可以被自動化的、戰術性沒有持久價值的工作
SLI：服務質量指標（請求延遲、錯誤率、系統吞吐量、可用性、持久性）
- 不要以目前的狀態爲基礎選擇目標
- 保持簡單，避免絕對值
- SLO越少越好
SLO：服務質量目標（服務某個SLI的目標值或目標範圍）
- 留出一定安全區
- 實際SLO也不要過高
SLA：服務質量協議（描述沒有達到SLO之後的後果）
服務可用性度量：
基於時間的可用性：=系統正常運行時間 / (系統正常運行時間 + 停機時間)
合計可用性：= 成功請求數 / 總的請求數
可靠性管理：
MTTF ---- 平均失敗時間
MTTR ---- 平均恢復時間
監控系統的4個黃金指標：
- 延遲
- 流量
- 錯誤
- 飽和度
監控系統的三類輸出：緊急警報、工單、日誌
傳統測試：
- 單元測試：檢驗某一個獨立的軟件單元
- 集成測試：檢驗組件的功能
- 系統測試
- 冒煙測試
- 性能測試
- 迴歸測試
- 生產測試
- 配置測試
- 壓力測試
金絲雀測試：在典型工作負載的服務子集中進行測試。最終用戶的驗收測試
識別異常任務的方法：跛腳鴨狀態
後端任務正在監聽端口，並且可以服務請求，但是已經明確要求客戶端停止發送請求
- 任務編排系統發送一個SIGTERM信號給該任務
- 後端任務進入跛腳鴨狀態，同時請求它的所有客戶端發送請求給其他後端任務
- 任何在後端進入跛腳鴨狀態時正在進行的請求仍會繼續進行
- 隨着請求恢復被髮送回客戶端，該後端任務的活躍請求逐漸降低爲0
- 在配置的時間過後，後端程序要麼自己乾淨退出，要麼任務編排系統主動幹掉它
流量相關：
QPS：每秒處理的請求數單位 （用來規劃服務容量）
過載處理思路：
- 客戶端：某個用戶超過資源配額時，後端任務應該迅速拒絕該請求。客戶端主動限制請求速度
- 自適應節流：
請求數量、請求接數量
新的請求以 max(0,requests-K*accepts / (requests + 1))
增加K會使算法不再激進，減少會使算法激進
後端的請求都會標記爲以下四種：
- 最重要
- 重要
- 可丟棄的 SHEDDABLE_PLUS
- 可丟棄的 SHEDDABLE
- 客戶端配額不夠時，後端按優先級分級拒絕請求
- 某個任務進入過載時，低優先級請求會先被拒絕
- 自適應節流系統會根據每個優先級分別計數
情況1：如果大部分後端任務處於過載狀態，請求應該不再重試，而是一直向上傳遞給請求者
情況2：小部分任務過載應該立即重試該請求，重試注意點：
- 增加每次請求重試次數的限制
- 每個客戶端的重試次數限制
- 客戶端在請求元數據中加入一個重試次數
情況3：對於超大數量的連接可能造成後端的過載，建議採取以下策略：
- 將負載傳遞給數據中心負載均衡算法
- 強制要求批處理任務使用某些特定的批處理代理後端任務（代理轉發請求，並回復轉發給客戶端）
防止服務器過載：
- 壓力測試，過載情況的失敗模式
- 提供降級結果
- 在過載情況下主動拒絕請求
- 上層系統應該主動拒絕請求
- 容量規劃（只能減少可能性）
限流的解決方案：
子集化：限制某個客戶端任務需要連接的後端任務數量
子集選擇算法：
- 隨機選擇
- 確定性算法
def Subset(backends,client_id,subset_size):
subset_count = len(backends) / subset_size
# 將客戶端劃分爲多輪，每一輪計算使用同樣的隨機配列的列表
round = client_id / subset_count
random.seed(round)
random.shuffle(backends)
# subset_id 代表了目前的客戶端
subset_id = client_id % sebset_count
start = subset_id * subset_size
return backends[start:start + subset_size]
每輪計算使用不同的重排列表時
不同輪中的客戶端會使用不同的列表，同一輪中的客戶端也會使用不同的列表子集。從而達到了負載均勻分佈
加權輪詢策略：
每個客戶端爲子集中的每個後端任務保持一個“能力”值，仍然以輪詢方式分發，但是客戶端會按照能力值權重比例調節。收到每個回覆之後，後端會在回覆中提供當前觀察到的請求速率、每秒錯誤值，以及目前資源利用率。客戶端根據目前成功請求的數量，以及對應的資源利用率進行週期性調節。
連鎖故障
- 服務器過載（服務器故障，導致其他服務過載）
- 資源耗盡
CPU:
- 請求的數量上升
- 隊列過長
- 線程卡住
- CPU死鎖或卡住
- RPC超時
- CPU緩存效率下降
內存：
- 任務崩潰
- Java垃圾回收速率加快，導致CPU使用率上升
- 緩存命中率下降
線程
文件描述符
資源之間的相互依賴
服務不可用
連鎖故障觸發條件：
- 進程崩潰
- 進程更新
- 新的發佈
- 自然增長
- 計劃中或計劃外的不可用
解決連鎖故障：
- 增加資源
- 停止健康檢查導致的任務死亡
- 重啓
- 丟棄流量
- 進入降級模式
- 消除批處理負載
- 消除有害流量
隊列長度比線程池大小更小會更好，當服務處理速度無法跟上請求到達速率時，儘早拒絕會更好
流量拋棄：根據CPU使用量、內存使用量以及隊列長度進行節流
慢啓動與冷緩存
保持調用棧永遠向下
如果在層內交互會導致：
- 分佈式死鎖
- 交互延遲上升
- 系統會更加複雜
分佈式共識：
分佈式協調失敗可能原因：
- 網絡慢
- 某些消息可以通過，某些消息被丟棄
- 單方面節流措施
腦裂問題：如果主無法確定副實例健康度，會將自己標記爲不可用，升級人工處理
分佈式協調和鎖服務：
- 屏障
- 鎖
可靠分佈式隊列和消息傳遞：
- 隊列
- 原子性廣播
法定租約：分佈式共識性能優化手段，降低延遲和提高讀操作吞吐量
給系統中的法定人數進程發放一個租約，這個租約是帶有具體事件範圍的。這個法定租約有限期內，任何對該部分數據的操作都要被法定租約中的所有進程相應。如果租約中的任何一個副本不可用，那麼該部分數據在租約過期前將無法被修改
分佈式共識的主要物理限制：網絡往返時間RTT、數據寫入持久化存儲時間
故障域：系統中可能由於一個故障而同時不可用的一組組件
週期性任務
cron：僅僅是單臺物理機器
冪等性---> 在最差情況下跳過好於執行兩次
crond：系統守護進程，負責加載cron任務的定義列表，任務會在對應時間啓動
anacron：在恢復運行時，會試圖運行那些在宕機時間本來應該運行的程序。通過將所有已註冊的cron任務上次運行的時間記錄在一個文件中來實現
大型分佈式cron系統注意點：
- 跟蹤cron任務的狀態
- cron任務部署多個副本的同時，會採用Paxos分佈式共識算法保證狀態一致
- Leader & Flower
（Leader進程是唯一一個主動啓動的Cron任務進程，內部有一個內置調度器。該調度器按照預定啓動時間排序維護一個Cron列表）
Cron要通過Paxos協議通知其他副本
追隨者需要保持跟蹤Leader狀態，修阿婆更新副本內部該系統的下次預計啓動時間
WorkFolow模型：MVC模式
流水線可能產生的問題：
- 驚羣
- 摩爾負載模式：某些執行過程重疊，導致共同消耗某些資源
正確性保障：配置文件、租約、唯一文件名
- 配置文件本身作爲屏障，保障工作進程的輸出永遠與配置一致
- 所有工作結果都必須由當前擁有租約的進程提交
- 工作進程的輸出文件都是全局唯一命名的
- 客戶端和服務端會在每次操作的時候校驗主任務令牌token
沒有人真的想備份數據，他們只想要恢復數據
數據備份
- 軟刪除（懶刪除：某段時間以後真刪除）
- 備份和相關的恢復方法
考慮點：
- 備份和還原的方法
- 全量或增量建立恢復點頻率
- 備份的存儲位置
- 備份的保留時間
- 一級備份：頻率高，可以快速恢復的備份
- 二級備份：用來爲服務所使用的數據提供額外保護的
- 三級備份：冷存儲，異地備份
- 複製機制（備份的備份）
- 早期預警
LCE：發佈協調工程師。負責測試發佈可能出現的問題，以及不同開發小組之間協調工作。例如：生產評審
良好的發佈流程：
輕量級、魯棒性、完整性、可擴展性、適應性
達到的目的：
簡化、高度定製、快速完成
灰度發佈：逐漸發佈產品和服務可以降低風險
功能開關：可以將新功能逐漸發佈給0%~100%的用戶
服務端控制客戶端
過載行爲和壓力測試：負載均衡、物理機故障、同步客戶端行爲、外界攻擊
on-call工程師的特點：
- 事後總結
- 故障處理分角色演習
- 破壞真的東西，並修復
- 維護文檔
- 儘早實戰
生產會議議程：
- 即將到來的生產環境變化
- 性能指標
- 故障
- 緊急警報
- 非緊急警報事件
- 之前的代辦事項
PRR 生產就緒程度評審