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