Google Cloud：從SRE到Anthos DevOps的工具與實踐

寫在前面

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

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

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

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

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

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

○      SRE擁抱風險

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

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

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

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

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

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

5.     度量一切

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

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

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

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

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

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

SRE的實踐（一）

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

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

改變

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

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

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

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

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

流程

SRE圍繞SLO展開工作。SRE認為100%的可靠性是不存在的，量化風險并管理風險才是正確的目標。實際工作時，SRE會將SLO轉化更易管理的指標：錯誤預算，如下公式

100％ - SLO=錯誤預算

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

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

更進一步，當SRE工程師們可以對錯誤率進行控制時，他們將可以獲得更大的錯誤允許時間。

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

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

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

SLO的確定

當我們講確定SLO的時候，其實是在講兩個問題：首先，用什么指標來定義我們的SLO，然后，這個SLO應該定義為多少，即錯誤預算有多少。

讓我們先來看看跟SRE有關的幾個術語：

●      CUJ –  核心用戶旅程

●      SLI - 服務等級指標

●      SLO - 服務等級目標

●      SLA - 服務等級協(xié)議

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

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

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

小結

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