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 生產就緒程度評審