1.70%的事故由變更引起

2.谷歌的SRE傾向于DEVOPS，兼顧效率（快速上線更新）與質量（降低事故率）

3.SRE大致發(fā)展歷程：手動（憑經驗容易誤操作）→自動→智能

4.緩慢的不斷重啟的實例優(yōu)于永不重啟泄露資源的實例

5.SLA（service level agreement）：請求延遲；錯誤率；系統(tǒng)吞吐量（QPS）；可用性；持久性

SLO（object）：SLI的目標范圍

SLI（indicator）：從目標反推指標

6.多創(chuàng)新，少做瑣事（DRY），但合理的瑣事有助于放松

7.監(jiān)控系統(tǒng)的4個黃金指標：延遲；流量；錯誤；飽和度（saturation）：達到100%之前性能就會嚴重下降

8.監(jiān)控出現(xiàn)的現(xiàn)象及原因分析：最好能深挖

9.自動化程序：能力，即準確性；延遲，任務開始到執(zhí)行完畢的時間；相關性，自動化所涵蓋的實際流程比例

10.on-call（本質為瑣事）的比例，每季度兩到三次

11.復雜操作系統(tǒng)本質就是動態(tài)和不穩(wěn)定的→系統(tǒng)的穩(wěn)定性與靈活性如何追求平衡

12.有效的故障排查手段：反復采用假設-排除手段的過程

12.1.誤區(qū)：關注錯誤現(xiàn)象，或錯誤理解現(xiàn)象含義；不能正確修改配置信息，輸入的信息或系統(tǒng)環(huán)境不能安全和有效地測試；過早將問題歸結為極不可能的因素；念念不忘之前發(fā)生過的系統(tǒng)問題（認為只要發(fā)生過一次，就可能再次發(fā)生）；試圖解決與當前系統(tǒng)相關的一些問題，顛倒因果（如數(shù)據(jù)庫異常和環(huán)境溫度同時出現(xiàn)，優(yōu)先解決溫度問題，卻忽略了溫度異常可能只是結果）→相關性不等于因果關系

13.正確判斷問題嚴重程度（一定的判斷力；保持頭腦冷靜）

14.出現(xiàn)大型問題，應首先回退，優(yōu)先恢復業(yè)務正常，再進行故障定位和排查（用戶對業(yè)務感知很敏感）

14.1.檢查：監(jiān)控指標；日志（按需、快速、有選擇啟用）；暴露目前的系統(tǒng)狀態(tài)；使用該系統(tǒng)的一個真實客戶端（采集具體返回信息）→查看服務端口是否正常運行；檢查最近對系統(tǒng)的修改（無外力因素，系統(tǒng)會持續(xù)正常工作）

15.緊急恢復（故障處理）→按流程管理→設立warroom而非各自為戰(zhàn)

16.事后總結輸出（做到對事不對人）：影響，采取的措施，根因，預防措施等，可提供大量經驗

17.連鎖故障：

1）服務器過載：單點故障

2）資源耗盡：不同種類的資源

3）CPU資源不足：正在處理的請求數(shù)量上升（可能進入隊列排隊）；隊列過長；線程卡住（等待某個鎖而無法處理請求）；CPU死鎖或請求卡住（排隊進程訪問←→看門狗watchdog殺死）；RPC超時（服務器過載時，回復客戶端RPC變慢→超時→客戶端重試→更嚴重的超時）；CPU緩存效率下降（CPU使用過多→任務分配至CPU核心→緩存失敗）

4）內存：請求數(shù)量上升→消耗更多內存存放請求，回復及RPC對象→直至耗盡

內存耗盡可能導致的情況：任務崩潰（因超過資源限制被容器管理器（VM或其他）驅逐，或因程序自身邏輯；Java垃圾回收（GC）速率加快，導致CPU使用率上升：GC死亡螺旋（當CPU資源減少，請求處理速度變慢，內存使用率上升→GC觸發(fā)次數(shù)增多→CPU資源進一步減少）；緩存命中率下降（向后端發(fā)送更多的RPC，導致后端任務過載）

5）線程：線程不足→錯誤或健康檢查失敗→服務器因此增加線程→占用更多內存

6）文件描述符：不足時導致無法建立網絡連接→健康檢查失敗

18.隊列管理：當請求速度超過單個請求的處理速度，請求進入排隊→線程池和隊列同時飽和→消耗內存并使延遲升高

隊列長度比線程池大小更小會更好→盡早拒絕請求

19.流量拋棄：在軟件服務器臨近過載時，主動拋棄一定量的負載

1）根據(jù)CPU、內存使用量及隊列長度等進行節(jié)流→返回HTTP 503（服務不可用）

2）將標準的先入先出改為后入先出隊列模式

3）使用可控延遲算法

4）適用于基礎共享服務采用的方式：精確識別客戶端；將請求按優(yōu)先級處理

20.優(yōu)雅降級：降低服務質量

21.重試

1）請求延遲和截止時間：定義前端會等待多長時間；恰當?shù)慕刂箷r間需在多個限制條件中尋求平衡

2）超過截止時間：客戶端已經放棄該請求，繼續(xù)處理無意義，應在請求過程的每個階段之前，都檢查是否還有足夠的剩余時間處理請求

3）截止時間傳遞：讓服務器采用截止時間傳遞和取消傳遞的策略（整個RPC樹）

，將傳遞出去的截止時間減少一點，將網絡傳輸和處理時間考慮在內

4）給發(fā)出的截止時間設置一個上限

5）請求延遲的雙峰分布（Bimodal）：當延遲上升時，額外注意延遲的分布狀況；無法完成的請求→→盡早返回一個錯誤，而非等完整個時間

22.慢啟動和冷緩存：

1）進程在剛啟動時通常比穩(wěn)定狀態(tài)下請求更慢一些：必需的初始化進程；運行時性能優(yōu)化

2）服務器在緩存沒有充滿之前效率很低，非常耗時：上線一個新的集群（緩存為空）；在某個集群維護之后恢復服務狀態(tài)（數(shù)據(jù)過期）

解決方法：重啟（將緩存在多個服務器共享）；將緩存從一個軟件服務器拿到另外的獨立服務器，如memcached

23.管理關鍵狀態(tài)：利用分布式提高可靠性

1）網絡問題的出現(xiàn)（早晚）

2）服務應用如何實現(xiàn)強一致性和高可用（ACID，常用于關系型數(shù)據(jù)庫；BASE，常見于Nosql）

BASE：基本可用（basically available）、軟狀態(tài)（soft state）、最終一致性（eventually consistency）→多主復制（multimaster replication）

24.系統(tǒng)的工作原理、運維方式、故障模擬、應急處理方式

25.后備系統(tǒng)和精心設計的API←→操作的東西應更抽象而非具體

26. stackoverflow.com

27. openpyxl.readthedocs.io/en/stable

?

?

?

總結

以上是生活随笔為你收集整理的SRE_Google运维解密_笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。