Google Cloud：從SRE到Anthos DevOps的工具與實(shí)踐

寫在前面

系統(tǒng)可靠性工程（Site Reliability Engineering），簡(jiǎn)稱SRE，是在Google實(shí)踐了有15年以上的DevOps工程實(shí)現(xiàn)。

“DevOps是一種重視「軟件開發(fā)人員（Dev）」和「IT運(yùn)維技術(shù)人員（Ops）」之間溝通合作的文化、運(yùn)動(dòng)或慣例。透過自動(dòng)化「軟件交付」和「架構(gòu)變更」的流程，來使得構(gòu)建、測(cè)試、發(fā)布軟件能夠更加地快捷、頻繁和可靠。” -- 維基百科對(duì)DevOps的定義。而Google定義SRE是DevOps的一種實(shí)現(xiàn)（軟件工程意義上的實(shí)現(xiàn)，implement），SRE滿足了DevOps的五個(gè)核心要求：

1.     減低組織隔閡，特別的，指開發(fā)部門和運(yùn)維部門的隔閡

○      SRE工程師與開發(fā)人員共擔(dān)責(zé)任

○      SRE工程師和開發(fā)人員使用同樣的工具

2.     接受“系統(tǒng)失效是常態(tài)”這一事實(shí)

○      SRE擁抱風(fēng)險(xiǎn)

○      SRE用服務(wù)等級(jí)指標(biāo)（SLI）和服務(wù)等級(jí)目標(biāo)（SLO）來量化系統(tǒng)失效和可用性

○      SRE要求“不指責(zé)（Blameless）”的故障分析（Postmortem）

3.     實(shí)現(xiàn)漸次發(fā)布

○      SRE鼓勵(lì)開發(fā)者和產(chǎn)品經(jīng)理通過提高發(fā)布頻率的方式來減少發(fā)布帶來的失效

4.     大規(guī)模使用工具和自動(dòng)化

○      SRE的工作之一就是開發(fā)自動(dòng)化工具

5.     度量一切

○      SRE有一整套度量系統(tǒng)的方法

○      從根源上，SRE認(rèn)為運(yùn)維是一個(gè)軟件開發(fā)問題

Anthos是Google Cloud開發(fā)的基于Kubernetes的現(xiàn)代化應(yīng)用平臺(tái)。起初，Google的工程師開發(fā)了Borg來幫助SRE工程師們運(yùn)維數(shù)以萬計(jì)的服務(wù)器。2014年Google發(fā)布了Kubernetes，并稱之為開源版本的Borg。自此，Google不斷地將SRE的經(jīng)驗(yàn)通過Kubernetes向外輸出，這些輸出的集大成即為Anthos平臺(tái)。

從本篇開始，我們將通過一系列文章，講述SRE的實(shí)踐以及運(yùn)用Anthos簡(jiǎn)化SRE的落地過程。并且希望能回答企業(yè)IT運(yùn)維中兩個(gè)直擊靈魂的問題：

●      我的系統(tǒng)到底可靠性如何

●      開發(fā)要發(fā)新版本，到底是保我的可靠性是讓他們發(fā)新版本

SRE的實(shí)踐（一）

SRE圍繞可用性進(jìn)行運(yùn)維，從業(yè)務(wù)需求的角度來感知可用性并管理可用性是SRE實(shí)踐的重要部分。所以SRE天生就對(duì)系統(tǒng)可靠性有全面的掌握。SRE同時(shí)認(rèn)為，更新系統(tǒng)帶來的風(fēng)險(xiǎn)是可控的，而使用一個(gè)已經(jīng)無人維護(hù)的依賴組件帶來的風(fēng)險(xiǎn)是不可控的，因此，通過持續(xù)的更新才能保證系統(tǒng)的可用性。

雖然已經(jīng)有很多文章和書籍對(duì)SRE進(jìn)行了論述，但作為本系列文章的開端，我們還是想先從實(shí)踐的角度，講一講我們?cè)谧鯯RE的咨詢過程中發(fā)現(xiàn)的問題以及得到的經(jīng)驗(yàn)。

改變

我們發(fā)現(xiàn)，SRE的落地往往會(huì)在這三個(gè)方面對(duì)現(xiàn)有的IT運(yùn)維部門提出改變：

●      從組織上，SRE需要建立一個(gè)有開發(fā)能力的運(yùn)維團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)的多數(shù)精力都應(yīng)該放在開發(fā)上，用開發(fā)的運(yùn)維工具來實(shí)現(xiàn)運(yùn)維。剩下的精力應(yīng)在響應(yīng)運(yùn)維事件（On-call）和幫助業(yè)務(wù)開發(fā)人員評(píng)審軟件架構(gòu)之間分配。這三部分的時(shí)間分配常常為5:2:3

●      從流程上，SRE的運(yùn)維以服務(wù)等級(jí)目標(biāo)（SLO）為導(dǎo)向。SRE認(rèn)為100%的可靠性是不存在的，承認(rèn)系統(tǒng)存在失效的風(fēng)險(xiǎn)然后量化和管理風(fēng)險(xiǎn)才是SRE的工作目標(biāo)。在與其他部門對(duì)接時(shí)，定義并協(xié)商SLO是討論的重點(diǎn)；于日常工作時(shí)，管理和使用錯(cuò)誤預(yù)算（在一個(gè)時(shí)間段內(nèi)，可以發(fā)生故障并且不影響SLO達(dá)成的時(shí)間）則是工作核心

●      在運(yùn)維工具上，需要有工具來收集數(shù)據(jù)來實(shí)現(xiàn)“度量”從而滿足SLO的量化計(jì)算，也需要有工具來實(shí)現(xiàn)自動(dòng)化?，F(xiàn)有的工具往往需要改造以適應(yīng)SRE，選擇一個(gè)合適的起點(diǎn)可以事半功倍

另外，“不指責(zé)”文化也與企業(yè)中現(xiàn)有的“背鍋/甩鍋”文化不太兼容。當(dāng)我的同事聽說我要參加一個(gè)給傳統(tǒng)企業(yè)做的SRE咨詢項(xiàng)目時(shí)，告訴我，如果能讓客戶接受“不指責(zé)”的文化，就可以算做成功了。

流程

SRE圍繞SLO展開工作。SRE認(rèn)為100%的可靠性是不存在的，量化風(fēng)險(xiǎn)并管理風(fēng)險(xiǎn)才是正確的目標(biāo)。實(shí)際工作時(shí)，SRE會(huì)將SLO轉(zhuǎn)化更易管理的指標(biāo)：錯(cuò)誤預(yù)算，如下公式

100％ - SLO=錯(cuò)誤預(yù)算

SRE會(huì)監(jiān)控度量系統(tǒng)實(shí)際正常運(yùn)行的時(shí)間，只要正常運(yùn)行的時(shí)間高于目標(biāo)，或者說錯(cuò)誤預(yù)算還有剩余，SRE就可以做一些可能影響可用性的操作，如發(fā)布新版本等。

如下圖所示，在不同的SLO目標(biāo)下，錯(cuò)誤預(yù)算也有很大的區(qū)別：

更進(jìn)一步，當(dāng)SRE工程師們可以對(duì)錯(cuò)誤率進(jìn)行控制時(shí)，他們將可以獲得更大的錯(cuò)誤允許時(shí)間。

SLO是SRE與其他部門對(duì)接時(shí)協(xié)商確定的。一個(gè)常見的爭(zhēng)論是"我們不接受任何的宕機(jī)時(shí)間”或者是“我們要確保100%在線”。但是當(dāng)討論深入的時(shí)候，卻發(fā)現(xiàn)這些100%在線，是指去掉例行維護(hù)時(shí)間之后的在線時(shí)間，更進(jìn)一步，如果被討論的系統(tǒng)是建設(shè)有高可用（HA）的設(shè)施的，HA切換所花的時(shí)間，也會(huì)算作在線時(shí)間。然而在SRE看來，這些例行維護(hù)時(shí)間和HA切換時(shí)間都應(yīng)該被計(jì)入錯(cuò)誤預(yù)算。

當(dāng)轉(zhuǎn)為SLO模式后，運(yùn)維人員可以更靈活的使用這些錯(cuò)誤預(yù)算，并且可以更合理的規(guī)劃和設(shè)計(jì)發(fā)布流程，最終實(shí)現(xiàn)在不改變SLO的前提下，增加發(fā)布頻率。舉例來說，灰度發(fā)布可以把錯(cuò)誤率控制在一個(gè)很小的程度，如果在發(fā)布過程中，監(jiān)控錯(cuò)誤預(yù)算的消耗，并在錯(cuò)誤預(yù)算消耗到一定程度時(shí)，暫停發(fā)布或者中止發(fā)布，就可以實(shí)現(xiàn)以可控的錯(cuò)誤預(yù)算消耗來完成發(fā)布這一目標(biāo)，從而實(shí)現(xiàn)更多的版本發(fā)布。更進(jìn)一步，如果把上面的 “發(fā)布-監(jiān)控-控制” 的過程進(jìn)行自動(dòng)化，則可以實(shí)現(xiàn)無人值守的自動(dòng)發(fā)布，解除開發(fā)人員和運(yùn)維人員之間的隔閡，提高生產(chǎn)效率。在之后的文章中，我們也會(huì)講述一個(gè)自動(dòng)化發(fā)布的案例，本篇按下不表。

對(duì)于企業(yè)管理者來說，全面部署SLO模式，還能幫助管理者對(duì)IT系統(tǒng)整體的健康狀態(tài)有一個(gè)更全面精確的認(rèn)識(shí)。進(jìn)一步，通過識(shí)別薄弱環(huán)節(jié)，管理者會(huì)更清楚的知道如何投入資源以獲得更好的健康狀況。

SLO的確定

當(dāng)我們講確定SLO的時(shí)候，其實(shí)是在講兩個(gè)問題：首先，用什么指標(biāo)來定義我們的SLO，然后，這個(gè)SLO應(yīng)該定義為多少，即錯(cuò)誤預(yù)算有多少。

讓我們先來看看跟SRE有關(guān)的幾個(gè)術(shù)語：

●      CUJ –  核心用戶旅程

●      SLI - 服務(wù)等級(jí)指標(biāo)

●      SLO - 服務(wù)等級(jí)目標(biāo)

●      SLA - 服務(wù)等級(jí)協(xié)議

這些定義有些抽象，我們用一個(gè)實(shí)際的例子來解釋，以內(nèi)存緩存服務(wù)為例，提供數(shù)據(jù)的讀寫即構(gòu)成其CUJ，針對(duì)這兩個(gè)CUJ，它們的操作成功率和操作延遲，我們就獲得了四個(gè)SLI，針對(duì)這幾個(gè)SLI，我們就有討論SLO的依據(jù)。SLO和SLA之間的區(qū)別在于，SLO應(yīng)用于企業(yè)內(nèi)部部門之間，而SLA是企業(yè)與其客戶簽訂的協(xié)議，因此SLA會(huì)引入罰則。所以SLA從數(shù)值上往往低于SLO。

而當(dāng)我們要確定內(nèi)存緩存服務(wù)的SLO時(shí)，我們知道網(wǎng)站應(yīng)用的用戶不會(huì)直接訪問內(nèi)存緩存，用戶只感受到網(wǎng)站本身的可用性：操作是否成功，操作是不是很慢：

通過這種方式，應(yīng)用的SRE工程師和內(nèi)存緩存服務(wù)的SRE工程師就可以分別確定自己的SLO需求和對(duì)對(duì)方的SLO的期望，從而協(xié)商出各自的SLO。

小結(jié)

本篇介紹了在SRE實(shí)踐過程中對(duì)運(yùn)維部門的改變，以及從流程的上如何建立SRE體系核心的SLO協(xié)商。在以后的文章中，我們會(huì)討論SRE在組織上如何改變運(yùn)維，以及SRE對(duì)工具提出的要求。