SRE Google運(yùn)維解密 閱讀與摘錄 第一部分概覽
序言
SRE Site Reliability Engineering 站點(diǎn)可靠性工程師
SRE是工程師。SRE使用計算機(jī)科學(xué)和軟件工程手段來設(shè)計和研發(fā)大型、分布式計算機(jī)軟件系統(tǒng)。
SRE的關(guān)注焦點(diǎn)在于可靠性。
因為可靠性是如此重要，因此SRE專注于對其復(fù)雜的軟件系統(tǒng)架構(gòu)設(shè)計、運(yùn)維流程的不斷優(yōu)化。
SRE的主要工作是運(yùn)維在分布式集群管理系統(tǒng)上運(yùn)行的具體業(yè)務(wù)服務(wù)。
第一章 介紹
DevOps 這個名詞的核心思想是近早將IT相關(guān)技術(shù)與產(chǎn)品設(shè)計和開發(fā)過程結(jié)合起來，著重強(qiáng)調(diào)自動化而不是人工操作，以及利用軟件工程手段執(zhí)行運(yùn)維任務(wù)等。
SRE團(tuán)隊職責(zé)：可用性改進(jìn) 延遲優(yōu)化 性能優(yōu)化 效率優(yōu)化 變更管理 監(jiān)控 緊急事務(wù)處理以及容量規(guī)劃與管理
Google SRE 核心方法論：
確保長期關(guān)注研發(fā)工作
Google 將SRE團(tuán)隊的運(yùn)維工作現(xiàn)在在50%內(nèi)。
在保障服務(wù)SLO的前提下最大化迭代速度
產(chǎn)品研發(fā)部門和SRE之間可以通過消除組織架構(gòu)沖突來構(gòu)建良好的合作關(guān)系。在企業(yè)中，最重要的矛盾就是迭代創(chuàng)新的速度與產(chǎn)品穩(wěn)定程度之間的矛盾。正如上文所說，其表現(xiàn)形式可能是間接的。在SRE模型中，我們選擇正面面對這種矛盾，使用的工具是錯誤預(yù)算。
通過引進(jìn) “錯誤預(yù)算”的概念，我們解決了研發(fā)團(tuán)隊和SRE團(tuán)隊之間的組織架構(gòu)沖突。SRE團(tuán)隊的目標(biāo)不再是 “零事故運(yùn)行” ，SRE團(tuán)隊和產(chǎn)品研發(fā)團(tuán)隊目標(biāo)一致，都是在保障業(yè)務(wù)服務(wù)可靠性需求的同時盡可能加快功能上線速度。
監(jiān)控系統(tǒng)
監(jiān)控系統(tǒng)是SRE團(tuán)隊監(jiān)控服務(wù)質(zhì)量和可用性的一個重要手段。
應(yīng)急事件處理
可靠性是 MTTF（平均失敗時間）和 MTTR（平均恢復(fù)時間）的函數(shù)。
變更管理
SRE的經(jīng)驗告訴我們，大概70%的生產(chǎn)事故由某種部署的變更而觸發(fā)。
需求預(yù)測和容量規(guī)劃
需求預(yù)測和容量規(guī)劃簡單來說就是保障一個業(yè)務(wù)有足夠的容量和冗余度去服務(wù)預(yù)測中的未來需求。
資源部署
資源的部署（provisinging）是變更管理與容量規(guī)劃的結(jié)合物。
效率與性能
高效利用各種資源是任何贏利性服務(wù)都要關(guān)心的。
第二章 Google生產(chǎn)環(huán)境：SRE視角
硬件
管理物理服務(wù)器的系統(tǒng)管理軟件
管理物理服務(wù)器
Borg 是一個分布式集群操作系統(tǒng)。其與 Apache Mesos 類似，Borg 負(fù)責(zé)在集群層面管理任務(wù)的編排工作。
存儲
1 D 是一個文件服務(wù)器，幾乎運(yùn)行在整個集群的所有物理服務(wù)器上。
2 D服務(wù)的上一層被稱之為 Colossus，Colossus建立了一個覆蓋了整個集群的文件系統(tǒng)。
3 構(gòu)建與 Colossus 之上，有幾個類似數(shù)據(jù)庫的服務(wù)可供選擇：
a Bigtable 是一個NoSSQL數(shù)據(jù)庫。
b Spanner 是可以提供SQL接口以及滿足一致性要求的全球數(shù)據(jù)庫。
c 另外幾種數(shù)據(jù)庫系統(tǒng)，例如 Blobstore也可用。
網(wǎng)絡(luò)
GSLB 全球負(fù)載均衡系統(tǒng)
其他系統(tǒng)軟件
分布式鎖服務(wù)
Chubby 集群鎖服務(wù)提供一個與文件系統(tǒng)類似的API用來操作鎖。
監(jiān)控與警報系統(tǒng)
監(jiān)控系統(tǒng)是服務(wù)運(yùn)維中不可或缺的部分
軟件基礎(chǔ)設(shè)施
Stubby 所有的 Google 服務(wù)之前都使用遠(yuǎn)程調(diào)用（RPC）通信。
Protocol Buffer 是 Google RPC 的傳輸格式，通常簡寫為 Protobuf，與 Apache Thrift 類似。
研發(fā)環(huán)境
SRE Google運(yùn)維解密 閱讀與摘錄 第二部分指導(dǎo)思想
第3章 擁抱風(fēng)險
SRE 旨在尋求快速創(chuàng)新和高效的服務(wù)運(yùn)營業(yè)務(wù)之間的風(fēng)險的平衡。
管理服務(wù)的可靠性主要在于管理風(fēng)險，而且管理風(fēng)險的成本可能很高
第4章 服務(wù)質(zhì)量目標(biāo)
SLI是指服務(wù)質(zhì)量指標(biāo)（indicator）——該服務(wù)的某項服務(wù)質(zhì)量的一個具體量化指標(biāo)。大部分服務(wù)都將請求延遲——處理請求所消耗的實踐——作為一個關(guān)鍵的SLI。
可用性（availability）是另外一個SRE重視的SLI，代表服務(wù)可用時間的百分比。
第5章 減少瑣事
第6章 分布式系統(tǒng)的監(jiān)控
監(jiān)控系統(tǒng)中最重要的一點(diǎn)就是整個“生產(chǎn)故障，人工處理緊急警報，簡單定位和深入調(diào)試”過程必須要保持非常簡單，必須能被團(tuán)隊中任何一個人所理解。
4個黃金指標(biāo) 延遲 流量 錯誤 飽和度
第7章 Google的自動化系統(tǒng)的演進(jìn)
自動化的演進(jìn)遵循以下路徑
1 沒有自動化
2 外部維護(hù)的系統(tǒng)特定的自動化系統(tǒng)
3 外部維護(hù)的通用的自動化系統(tǒng)
4 內(nèi)部維護(hù)的系統(tǒng)特定的自動化
5 不需要任何自動化的系統(tǒng)
第8章 發(fā)布工程
發(fā)布工程是Google內(nèi)部的一項具體工作。發(fā)布工程與產(chǎn)品研發(fā)部門的軟件工程師（SWE），以及SRE一起定義發(fā)布軟件過程中的全部步驟——包括軟件是如何存儲于源代碼倉庫中的，構(gòu)建時是如何執(zhí)行編譯的，如何測試、打包，最終進(jìn)行部署的。
第9章 簡單化
一個對SRE管理系統(tǒng)的方法不錯的總結(jié)是：“我們的工作最終是在系統(tǒng)的靈活性和穩(wěn)定性上維持平衡。”
SRE Google運(yùn)維解密 閱讀與摘錄 第三部分具體實踐
第10章 基于實踐序列數(shù)據(jù)進(jìn)行有效報警
第11章 on-call 輪值
第12章 有效的故障排查手段
第13章 緊急事件響應(yīng)
第14章 緊急事故管理
第15章 事后總結(jié)：從失敗中學(xué)習(xí)
第16章 跟蹤故障
第17章 測試可靠性
第18章 SRE 部門中的軟件工程實踐
第19章 前端服務(wù)器的負(fù)載均衡
第20章 數(shù)據(jù)中心內(nèi)部的負(fù)載均衡系統(tǒng)
第21章 應(yīng)對過載
第22章 處理連鎖故障
第23章 管理關(guān)鍵狀態(tài)：利用分布式共識來提高可靠性
第24章 分布式周期性任務(wù)系統(tǒng)
第25章 數(shù)據(jù)處理流水線
第26章 數(shù)據(jù)完整性：讀寫一致
第27章 可靠地進(jìn)行產(chǎn)品的大規(guī)模發(fā)布
SRE Google運(yùn)維解密 閱讀與摘錄 第四部分管理
第28章 迅速培養(yǎng) SRE 加入on-call
第29章 處理中斷性任務(wù)
第30章 通過嵌入 SRE 的方式幫助團(tuán)隊從運(yùn)維過載中恢復(fù)
第31章 SRE 與其他團(tuán)隊的溝通與協(xié)作
第32章 SRE 參與模式的演進(jìn)歷程
典型服務(wù)的生命周期：設(shè)計 構(gòu)建和實現(xiàn) 發(fā)布 運(yùn)維 退役
SRE會考量該服務(wù)的幾個方面：
系統(tǒng)的體系結(jié)構(gòu)和跨服務(wù)依賴
指標(biāo)的選擇、度量和監(jiān)控
緊急事件處理
容量規(guī)劃
變更管理
性能：可用性、延遲和資源效率
SRE Google運(yùn)維解密 閱讀與摘錄 第五部分結(jié)束語
第33章 其他行業(yè)的實踐經(jīng)驗
內(nèi)容來自 SRE Google運(yùn)維解密，Betsy Beyer，孫宇聰，2016-11
