《Google SRE》讀後感

注：這是去年國慶時的一篇讀書筆記，最近線上故障頻繁，從新讀了下這篇讀書筆記，以爲《Google SRE》很是棒，遂從簡書再搬家到博客園，但願你們受益。個人簡書地址：daoqidelv

國慶長假，出門太堵，遂待在魔都，花了三天時間將《Google SRE》中文版翻了一遍，好書一本，不論是開發人員、運維人員仍是架構師，均可以讀一讀，受益不淺的。

鑑於本身是作開發的，因此對於運維相關流程化的內容沒有涉獵。不過這部份內容對於運維leader應當是大有裨益的。

SRE是個全能手，DevOps的實踐者

SRE全稱：Site Reliability Engineering，翻譯過來就是：站點可靠性工程師。SRE的職責確保站點的可用，爲了達到這個目的，他須要對站點涉及的系統、組件熟悉，須要關注生產運行時的狀態，爲此，他須要有不少工具和系統支撐其完成上述工做，好比自動化發佈系統，監控系統，日誌系統，服務器資源分配和編排等，這些工具須要他們本身完成開發和維護。

SRE是一個綜合素質很高的全能手，須要懂服務器基礎架構、操做系統、網絡、中間件容器、經常使用編程語言、全局的架構意識、很是強的問題分析能力、極高的抗壓能力（以便沉着高效地排障），他們還須要懂性能調優理論...

SRE的工做是Develop+Operate的結合，SRE是DevOps的實踐者，他們的工做內容和職責和傳統運維工程師差很少：發佈、部署、監控、排障，目標一致。可是SRE的手段更加自動化，更高效，這種高效來源於自動化工具、監控工具的支撐，更由於其做爲這些工具的開發者，不斷優化和調整，使整個工具箱使起來更加駕輕就熟，這也是DevOps的魅力所在。

分佈式環境運維大不一樣於傳統運維

個人理解：在分佈式環境下，系統的複雜度增大、維護目標增多，按照傳統的手工或者半自動維護來作，是不行的。因此，須要轉變思路：

事務性的工做工具化。好比：版本發佈、服務器監控；

讓系統自反饋。完善的監控告警機制，完善的日誌記錄和分析體制，可視化系統的健康狀態，使得系統變得可追蹤和調校；

分佈式策略應對巨量運維對象。負載均衡、流控、數據完整性、批處理的變得不同，須要從新設計和實踐。同時，更要重視連鎖式故障。

分佈式系統的核心——分佈式共識

分佈式共識問題是指「在不穩定的通訊環境下一組進程之間對某項事情達成一致的問題」。

分佈式共識系統能夠用來解決：領頭人選舉、關鍵共享狀態、分佈式鎖等問題。或者絕對點，全部的分佈式問題都應當考慮到分佈式共識的問題。

分佈式共識的理論基礎和實現都不是很好理解，抽時間搞清楚是大有裨益的，這裏羅列一下幾個關鍵詞：

拜占庭問題

可複製狀態機

Paxos算法

Zookeeper

Chubby

監控很重要！很重要！很重要！

監控是SRE眼睛的延伸。

監控系統應當解決兩個問題：現象（什麼東西出故障了？），緣由（爲何出故障？）

現象—— 用戶可感知的現象，好比：登錄不了、支付訂單變慢；

緣由—— 形成現象的潛在因素，可能只是中間因素或者相關因素，並不是根本緣由，根本緣由須要SRE介入分析並肯定。好比：login 服務CPU超過警惕值，訂單服務器的CLOSE_WAIT狀態的TCP連接數猛增等等。

四個黃金指標：時延、流量（PV）、錯誤、飽和度（服務器資源使用狀況）。前三個是對服務進行監控，後一個是對服務器進行監控，固然也能夠包含容器的狀態監控，好比線程池、GC等。

幾條箴言：

指標簡化到不能再簡化

關注長尾現象，要時延分佈，而不是平均時延

慎重發出緊急警報，預防「狼來了」現象，緊急警報都是課操做的，且不能慣性得出結論的問題

警報不要重複，避免浪費SRE的注意力

排障

定位故障點。合理斷定問題的嚴重程度，嘗試儘快恢復服務或者緩解問題。

藉助監控工具和日誌工具檢查系統或者服務狀態。服務時延和錯誤率、系統資源使用狀態狀況、日誌統計分析

逐層檢查和分解問題，解析問題現象，不斷假設/驗證地進行診斷，找到根本緣由

發佈

自動化發佈應看成爲基礎設施，第一優先級建設，他的重要性和自動化測試同樣。以前參加的「軟件工程的精益化管理」課程實驗中，實踐證實了自動化工具的威力很大，可以明顯提高整個團隊的生產力。

關於自動化發佈的內容和分享網上很是多，並且國內各大互聯公司分享出來的材料也是汗牛充棟，用到是能夠學習。

反思 and 總結

這兩個優勢對於SRE非常重要，反思使得SRE從失敗中學習教訓，總結使SRE從時間中得到經驗，我的和團隊須要學習和踐行這種精神，可是對事不對人。

Google的作法是：時過後總結機制。

避免指責，提供建設性意見，充滿正能量

過後總結報告須要評審，避免低質量的過後總結帶來負面影響

google的過後總結模板

追本溯源、懷疑一切

SRE是天生懷疑論者，懷疑一切，眼見爲實，追本溯源是本性，感受本身的性格還蠻適合的~

擁抱風險

傳統運維是厭惡風險的，可是開發和產品卻更關注變化速度，他們都但願迭代速度越快越好，可是這回給系統運行帶來風險，因此這天生是矛盾。

爲了解決風險和變化的矛盾，google提出了SLI-->SLO-->SLA的機制。

SLI——服務質量指標，如：延時、吞吐量、錯誤率、可用性等

SLO——服務質量目標，服務的某個SLI的目標值，或者目標範圍。好比：SLI<=目標值，min=

SLA——服務質量協議（Agreement），服務（SRE）和用戶（開發、產品）之間的一個明確的、或者不明確的協議，描述了在達到或者沒有達到SLO以後的後果。或者能夠轉化爲先行的KPI，好比系統可用性99.99%等。

開發和運維針對某個系統協商好一個SLA後，你們有一個量化的指標，一旦出現衝突時，算一下，看看是否違反SLA，若是違反，那麼就升級走流程。這樣既靈活，也有章可循。若是開發團隊牛逼，代碼質量高或者運氣好，你能夠迭代快，反之你須要慢點來，間接地，你們都對線上系統負責了。

反直覺的真理

一、不要承諾你的系統100%可靠。

由於這樣會要其餘人過度依賴於你，一旦你出問題，那麼將成爲衆矢之的，相反的，你應當對本身的系統瞭如指掌，好比能承受的壓力，可用性目標，一些明顯的坑，一些不支持的屬性等，廣而告之。

二、有意識地破壞你的系統

不一樣於演練，而是真實生產系統，在可控範圍內，人爲製造故障，而後在有人值守的狀況下，找到系統的短板和問題。這樣等到真正的故障來臨時，能夠有章可循，快速解決問題。

主動暴露本身的不足好於別人忽然揭發你，固然更重要的是要及時糾正不足。

 線上排障實踐

如何快速處理線上故障

線上故障處理——大量異常堆棧日誌輸出影響服務可用性

線上故障處理——發佈順序錯誤引發的數據庫異常

線上故障處理——發佈順序錯誤引發的數據庫異常