讀書筆記 摘要
SRE是Site Reliability Engineer的簡稱，從名字可以看出Google的SRE不只是做Operation方面的工作，更多是保障整個Google服務的穩定性。
監控系統
監控系統是 SRE 團隊監控服務質量和可用性的一個主要手段。所以監控系統的設計和策略值得著重討論。最普遍和傳統的報警策略是針對某個特定的情況或者監控值，一旦出現情況或者監控值超過閾值就觸發 E-mail 報警。但是這樣的報警并不是非常有效：一個需要人工閱讀郵件和分析報警來決定目前是否需要采取某種行動的系統從本質上是錯誤的。監控不做任何事情是不可能的，有三種有效的監控輸出：
警報
意味著收到警報的用戶需要立即執行某種操作，目標是解決某種已經發生的問題，或者是避免即將要發生的問題。
這使我所擁有的每個設備都會產生大量的噪音。如果我在 5 分鐘內沒有回應，它會找到我的替代者，他的工作是采取行動。
我所在的 SRE 團隊有一個送花規則，如果問題落到替代者來處理，這對主負責人來說是個悲劇，你將需要給替代者送去花和一張卡。
工單
意味著接受工單的用戶應該執行某種操作，但是并非立即執行。系統并不能自動解決目前的情況，但是如果一個用戶在幾天內執行這項操作，系統不會受到任何影響。
日志
平時沒有人需要關注日志信息,但是日志信息依然被收集起來以備調試和事后分析時使用。正確的做法是平時沒有人主動閱讀日志,除非處理其他請求的時候被要求這么做。
應急事件處理
可靠性是 MTTF（平均失敗時間）和 MTTR（平均恢復時間）的結合結果。評價一個團隊將系統恢復到正常情況的最有效指標，就是 MTTR。任何需要人工操作的事情，都只會延長恢復時間通過事先預案并且將最佳方法記錄在“運維手冊”上通常會使 MTTR 降低 3 倍以上。
變更管理
SRE 經驗告訴我們，大概 70% 的生產事故由某種部署的變更而觸發。變更管理的最佳實踐可使用自動化來完成以下幾個項目：
采用漸進式發布機制。
迅速而準確地檢測到問題的發生。
當出現問題時，安全迅速地回退改動。
這三點可以有效地降低變更給 SRE 和最終用戶帶來的時間成本和服務質量的下降。通過將人工因素排除在流程之外，這些操作將不再受到經常發生在人身上的“狼來了”思想以及對大量重復性勞動的關注疲勞所影響。于是，變更執行的速度和安全性同時得到了提高。
預測需求和規劃容量
需求預測和容量規劃簡單來說就是保障一個業務有足夠的容量和冗余度去服務預測中的未來需求。這里并沒有任何特別的概念，但是我們發現行業內有許多團隊根本沒有這個意識和計劃去滿足這個要求。一個業務的容量規劃，不僅僅要包括自然增長(隨著用戶使用量上升,資源使用率也上升)，也需要包括一些非自然增長的因素（新功能的發布、商業推廣，以及其他商業因素在內）。
容量規劃有幾個步驟是必須的：
必須有一個準確的自然增長需求預測模型
規劃中必須有準確的非自然增長的需求來源的統計
必須有周期性壓力測試，
因為服務容量對可用性來說是極為重要的，很自然的，SRE應該主導容量規劃的過程。同時，也意味著需要主導資源部署的過程。
資源部署
資源的部署與配置是變更管理與容量規劃的結合物。在我們的經驗里，資源的部署和配置必須能夠非常迅速地完成，而且僅僅是在必要的時候才執行，因為資源通常是非常昂貴的。而且這個部署和配置的過程必須要確保能夠正確地執行完畢，否則資源就仍然處于不可用狀態。增加現有容量經常需要啟動新的實例甚至是集群，這通常需要大幅度修改現有的集群配置 ( 配置文件、負載均衡、網絡等 )，同時還要執行一系列測試，確保新上線的容量可以正確地服務用戶。因此新資源的部署與配置是一個相對比較危險的操作，必須要小心謹慎地執行。
小結
站點可靠性工程師(SRE)代表了對行業現存管理大型復雜服務的最佳實踐的一個重要突破。由一個簡單的想法“我是一個軟件工程師，這是我如何來應付重復勞動的辦法” 而生，SRE 模型已經發展成一套指導思想，一套方法論，一套激勵方法，和一個擁有廣闊空間的獨立職業。本書的其余部分探討了 SRE 的詳細方法。
原創文章，作者：zero，如若轉載，請注明出處：http://www.www58058.com/72484
內容主要介紹了工作SRE的職責與管理，寫的很詳細，排版也很不錯，繼續努力