關(guān)于SRE，數(shù)人云之前給大家分享很多相關(guān)的文章，想必大家已經(jīng)有了一定的了解，今天給大家?guī)?lái)的這篇文章，分別從Xero和Google的角度討論一些工具和框架，以及SRE的一些準(zhǔn)則。
Xero的SRE之路
作為一個(gè)SRE，作者主要關(guān)心的是如何保持應(yīng)用平臺(tái)的穩(wěn)定，減少崩潰，然而這也是不能避免的，本文會(huì)通過(guò)Xero的SRE經(jīng)驗(yàn)去討論一些工具和框架。
任何故障的開始都是至關(guān)重要的，因此需要在發(fā)現(xiàn)故障的第一時(shí)間就提醒能解決問(wèn)題的人。
大多數(shù)的生產(chǎn)問(wèn)題，都是通過(guò)監(jiān)控基礎(chǔ)設(shè)施進(jìn)行檢測(cè)的，用于告警的通道工具已經(jīng)隨著時(shí)間的推移而發(fā)生了變化，但是基本的流程仍然大同小異，如下圖所示：
自動(dòng)告警Pipeline
自動(dòng)化Pipeline可以確保工程師快速、正確、一致和可靠的進(jìn)行工作，理想的情況下， 所有的告警都應(yīng)該是自動(dòng)化的，但有時(shí)我們會(huì)接觸到一些沒(méi)有被發(fā)現(xiàn)的問(wèn)題，所以希望有一種方法可以允許其他團(tuán)隊(duì)報(bào)告保留自動(dòng)告警Pipeline，因此決定將這些請(qǐng)求轉(zhuǎn)換為自動(dòng)告警，如下所示：
手動(dòng)報(bào)警Pipeline
使用這種方法，自動(dòng)和手動(dòng)告警都以同樣的方式送達(dá)工程師，但是每個(gè)告警都有什么呢？
剖析一個(gè)告警
- 出現(xiàn)了什么錯(cuò)誤？問(wèn)題的性質(zhì)和嚴(yán)重性？
- 故障出現(xiàn)后，都有哪些地方收到了影響？
- 它怎么能固定下來(lái)呢？鏈接到Runbooks或者How-to文檔。
嘗試編寫自動(dòng)告警模板以滿足這些需求，對(duì)于手工報(bào)告的問(wèn)題，依賴于通過(guò)在線表單提供這些信息，希望填寫表格的過(guò)程是速度且無(wú)痛的，所以只有第一個(gè)問(wèn)題是強(qiáng)制性的：
- 能否概括一下這個(gè)問(wèn)題，比如，到底出了什么問(wèn)題？
- 哪個(gè)站點(diǎn)/URL有問(wèn)題？可以幫助識(shí)別受影響的地方。
- 問(wèn)題是否僅限于特定的地點(diǎn)，幫助我們隔離網(wǎng)絡(luò)/CDN問(wèn)題。
- 問(wèn)題是什么時(shí)候開始的？幫助設(shè)置日志/度量搜索的時(shí)間尺度。
- 誰(shuí)在關(guān)注這些問(wèn)題？這樣可以將它們包含在事件的Pipeline中
雖然這些信息不可能如監(jiān)控系統(tǒng)所提供的那樣具體明確，但它仍然可以減少SRE工程師所需要的調(diào)查工作。
On-call as code
我們使用第三方的呼叫管理系統(tǒng)，允許我們建立多個(gè)On-call團(tuán)隊(duì)，定義每個(gè)團(tuán)隊(duì)的輪換，并將每個(gè)團(tuán)隊(duì)連接到監(jiān)控基礎(chǔ)設(shè)施，告警是針對(duì)擁有受影響系統(tǒng)的團(tuán)隊(duì)的，但是SRE為每個(gè)團(tuán)隊(duì)提供了額外的層，如下所示：
告警升級(jí)
在20多個(gè)產(chǎn)品和服務(wù)的呼叫團(tuán)隊(duì)中，On-call管理配置已經(jīng)演化為相當(dāng)復(fù)雜的設(shè)置，隨著越來(lái)越多的團(tuán)隊(duì)加入其中，我們的支持模式也在不斷地發(fā)展，要手動(dòng)設(shè)置所有的東西將是一項(xiàng)艱巨的任務(wù)，處于這個(gè)原因，我們創(chuàng)建了一個(gè)“On-call as code”系統(tǒng)，類似于Chef這樣的基礎(chǔ)設(shè)施代碼框架。
On-call configuration pipeline
延伸閱讀：
Chef 是一款自動(dòng)化服務(wù)器配置管理工具，可以對(duì)所管理的對(duì)象實(shí)行自動(dòng)化配置，如系統(tǒng)管理，安裝軟件等。Chef 由三大組件組成：Chef Server、Chef Workstation 和 Chef Node。
Chef Server 是核心服務(wù)器，維護(hù)了一套配置腳本（Cookbook），與每個(gè)被管節(jié)點(diǎn)（Chef Node）交互并給出配置指令。
Chef Workstation 提供了我們與 Chef Server 交互的接口：我們?cè)?Workstation 上創(chuàng)建定義 Cookbook，并將 Cookbook 上傳到 Chef Server 上以保證被管機(jī)器能從 Chef Server 上取得最新的配置指令。
Chef Node 是安裝了 chef-client 并注冊(cè)了的被管理節(jié)點(diǎn)，可以是物理機(jī)或者虛擬機(jī)或者其他對(duì)象。Chef Node 每次運(yùn)行 chef-client 時(shí)都會(huì)從 Chef Server 端取得最新的配置指令（Cookbook）并按照指令配置自己。
一套 Chef 環(huán)境包含一個(gè) Chef Server，至少一個(gè) Chef Workstation，以及一到多個(gè) Chef Node。
團(tuán)隊(duì)可以通過(guò)將更改合并到Git存儲(chǔ)庫(kù)來(lái)更新他們的調(diào)用配置，然后，CI/CD系統(tǒng)運(yùn)行一個(gè)Rake任務(wù)，它通過(guò)調(diào)用管理系統(tǒng)來(lái)同步存儲(chǔ)庫(kù)，這種方法為我們提供了一系列的好處：
所有的配置更改都可以通過(guò)標(biāo)準(zhǔn)的Git工作流進(jìn)行同行評(píng)審。
CI服務(wù)器可以“Lint”每個(gè)配置更改，以驗(yàn)證它滿足一些基本需求（例如，每個(gè)團(tuán)隊(duì)需要一個(gè)管理員）。
允許團(tuán)隊(duì)手動(dòng)設(shè)置他們的調(diào)用輪換，因?yàn)镺n-call系統(tǒng)的Web界面提供了一種簡(jiǎn)單的方法，然而，團(tuán)隊(duì)調(diào)用設(shè)置的所有其他組件都由同步任務(wù)執(zhí)行。
新團(tuán)隊(duì)不需要擔(dān)心設(shè)置他們的告警端點(diǎn)或?qū)⑺麄兊膱F(tuán)隊(duì)與SRE的時(shí)間表聯(lián)系起來(lái)，同步任務(wù)從一個(gè)最小的配置文件自動(dòng)地構(gòu)建每個(gè)團(tuán)隊(duì)的調(diào)用配置，如果團(tuán)隊(duì)需要一個(gè)不尋常的調(diào)用設(shè)置，那他們就可以置頂額外的配置文件來(lái)這樣做。
未來(lái)，可以很容易地改變所有團(tuán)隊(duì)的標(biāo)準(zhǔn)調(diào)用配置，例如更改每次升級(jí)之間的時(shí)間限制。
在這些倡議中，我們?yōu)楣芾砹己玫臅r(shí)間奠定了基礎(chǔ)：
告警以相同的方式發(fā)出，無(wú)論它們是自動(dòng)檢測(cè)還是手動(dòng)報(bào)告。
每個(gè)告警的內(nèi)容都包含了足夠的信息，讓工程師開始計(jì)劃響應(yīng)。
On-Call作為代碼系統(tǒng)，確保所有的團(tuán)隊(duì)都能以一致的方式接受告警。
雖然工作流程、優(yōu)先級(jí)和日常操作從SRE團(tuán)隊(duì)到另一個(gè)SRE團(tuán)隊(duì)之間都有細(xì)微的差別，但都與他們支持的服務(wù)有著基本的信任，并堅(jiān)持相同的核心原則。
一般來(lái)說(shuō)，SRE團(tuán)隊(duì)負(fù)責(zé)可用性、延遲性、性能、效率、變更管理、監(jiān)控、緊急響應(yīng)以及服務(wù)的容量規(guī)劃。
我們已經(jīng)為SRE團(tuán)隊(duì)與其環(huán)境交互（不僅僅是生產(chǎn)環(huán)境，還包括開發(fā)團(tuán)隊(duì)、測(cè)試團(tuán)隊(duì)、用戶等等）制定了相關(guān)的規(guī)則和原則，這些規(guī)則和工作實(shí)踐幫助我們保持對(duì)工程工作的關(guān)注，而不是運(yùn)維工作。
Google SRE準(zhǔn)則
確保持久專注于工程
Google在50%的時(shí)間內(nèi)為SREs的運(yùn)維工作設(shè)置上限，他們的剩余時(shí)間應(yīng)該用在項(xiàng)目工作的編程技能上，在實(shí)踐當(dāng)中，這是通過(guò)監(jiān)控SRE們所做的運(yùn)維工作數(shù)量來(lái)完成的，并將多余的運(yùn)維工作重新定向到產(chǎn)品開發(fā)團(tuán)隊(duì)：重新分配Bug將開發(fā)人員集成到On-Call pager roUNK中等等。
當(dāng)運(yùn)維負(fù)載下降到50%或更低時(shí)，重新向結(jié)束，這也提供了一個(gè)有效的反饋機(jī)制，引導(dǎo)開發(fā)人員構(gòu)建不需要人工干預(yù)的系統(tǒng)，當(dāng)整個(gè)組織——SRE和開發(fā)人員理解為什么這個(gè)機(jī)制存在時(shí)，這種方法很有效，并且支持沒(méi)有溢出事件的目標(biāo)，因?yàn)楫a(chǎn)品沒(méi)有產(chǎn)生足夠的運(yùn)維負(fù)載來(lái)要求她。
當(dāng)他們專注于運(yùn)維工作時(shí)，在平均每8-12小時(shí)中，SRE應(yīng)該最多接受兩個(gè)事件，這個(gè)目標(biāo)量給呼叫工程師足夠的時(shí)間準(zhǔn)確快速地處理事件，清理和恢復(fù)正常服務(wù)，然后進(jìn)行事后剖析，如果有兩個(gè)以上的事件經(jīng)常發(fā)生在呼叫轉(zhuǎn)移上，問(wèn)題就無(wú)法徹底調(diào)查，工程師們也無(wú)法從這些事件中吸取教訓(xùn)，一種尋呼機(jī)疲勞的情況下也不會(huì)隨著規(guī)模而提高，相反，如果每次轉(zhuǎn)換時(shí)，調(diào)用的SRE始終接受不到一個(gè)事件，那么這就無(wú)異于在浪費(fèi)時(shí)間。
對(duì)于所有重大事件，無(wú)論是否尋呼，都應(yīng)該寫死后的紀(jì)錄，沒(méi)有觸發(fā)界面的后期紀(jì)錄甚至更有價(jià)值，因?yàn)樗鼈兛赡苤赋隽嗣黠@的監(jiān)控漏洞，這個(gè)調(diào)查應(yīng)該確定發(fā)生的細(xì)節(jié)，找出事件的所有根源，并分配行動(dòng)來(lái)糾正問(wèn)題化或改進(jìn)下次處理的方法，Google在一個(gè)免費(fèi)的分析文化下運(yùn)行，目標(biāo)是揭露出錯(cuò)誤并應(yīng)用工程來(lái)修復(fù)這些錯(cuò)誤，而不是去避免或盡量最小化它們。
追求最大的變化速度而不違反服務(wù)的SLO
產(chǎn)品開發(fā)和SRE團(tuán)隊(duì)可以通過(guò)消除各自目標(biāo)中的結(jié)構(gòu)性沖突來(lái)享受高效的工作關(guān)系，結(jié)構(gòu)沖突是在創(chuàng)新和產(chǎn)品穩(wěn)定性之間，正如前面所述，這種沖突往往是間接表達(dá)的，在SRE中，我們將這個(gè)沖突引入到前面，然后通過(guò)引入錯(cuò)誤預(yù)算來(lái)解決它。
預(yù)算錯(cuò)誤源于這樣一種觀察， 即100%是所有東的錯(cuò)誤可靠性目標(biāo)，一般來(lái)說(shuō)，對(duì)于任何軟件服務(wù)或系統(tǒng)100%可用和99.999%可用，有許多其他系統(tǒng)用戶和服務(wù)之間的路徑（他們的筆記本電腦，家里的WIFI，ISP，電網(wǎng)……），這些系統(tǒng)集體遠(yuǎn)遠(yuǎn)低于99.999%，因此，99.999……和100%的差異在于其他不可用性的丟失，而且用戶無(wú)法從需要添加走貨0.001%的可用性中獲益。
如果100%是一個(gè)系統(tǒng)的錯(cuò)誤可靠性目標(biāo)，那么，系統(tǒng)的正確可靠性目標(biāo)是什么？這實(shí)際上并不是一個(gè)技術(shù)問(wèn)題——這是一個(gè)產(chǎn)品問(wèn)題，應(yīng)該考慮以下因素：
考慮到他們是如何使用產(chǎn)品的，用戶滿意的程度是多少?
對(duì)于那些對(duì)產(chǎn)品的可用性不滿意的用戶有什么選擇?
用戶在不同可用級(jí)別上使用該產(chǎn)品會(huì)發(fā)生什么情況?
業(yè)務(wù)或產(chǎn)品必須建立系統(tǒng)的可用性目標(biāo)，一旦確定了目標(biāo)，錯(cuò)誤預(yù)算就是一個(gè)減去可用性的目標(biāo)。一個(gè)99.99%可用服務(wù)是0.01的不可用，允許0.01的不可用性是服務(wù)的錯(cuò)誤預(yù)算，我們可以把預(yù)算畫在問(wèn)么想要的任何東西上，只要不超支。
那么要如何花費(fèi)這個(gè)錯(cuò)誤預(yù)算呢？開發(fā)團(tuán)隊(duì)希望推出特性并吸引新用戶，理想情況下，我們會(huì)把所有的錯(cuò)誤預(yù)算都花在我們發(fā)布的新產(chǎn)品上，以快速啟動(dòng)它們，這個(gè)基本前提描述了整個(gè)錯(cuò)誤預(yù)算模型，一旦SRE活動(dòng)在這個(gè)框架中被概念化，通過(guò)注入階段性的滾轉(zhuǎn)和1%的實(shí)驗(yàn)等策略釋放錯(cuò)誤預(yù)算，可以優(yōu)化更快的啟動(dòng)。
錯(cuò)誤預(yù)算的使用解決了開發(fā)和SRE之間的結(jié)構(gòu)沖突，SRE的目標(biāo)實(shí)在是“0消耗”；相反，SRE和產(chǎn)品開發(fā)人員的目標(biāo)是將錯(cuò)誤預(yù)算花在獲得最大特征速度上，這種改變?cè)斐闪瞬煌礄C(jī)不再是“壞”的事情——它是創(chuàng)新過(guò)程中預(yù)期的一部分，而且發(fā)展和SRE團(tuán)隊(duì)都在管理，而不是一直憂心忡忡。
監(jiān)控
監(jiān)控是服務(wù)所有者跟蹤系統(tǒng)的健康和可用性的主要手段之一，因此，應(yīng)當(dāng)深思熟慮地構(gòu)建監(jiān)控策略，一個(gè)典型的、常見的監(jiān)控方法是觀察特定的值或條件，然后在超過(guò)該值或條件時(shí)觸發(fā)電子郵件告警，然而，這種類型的電子郵件告警并不是一個(gè)有效的解決方案；一個(gè)需要一個(gè)人閱讀電子郵件并決定是否需要采取某種行動(dòng)的系統(tǒng)從根本上是有缺陷的，監(jiān)控不應(yīng)該要求人對(duì)告警區(qū)域的任何部分進(jìn)行解釋，相反，應(yīng)用應(yīng)做口譯，只有當(dāng)它們需要采取行動(dòng)時(shí)，才去通知SRE。
三種有效地監(jiān)控輸出：
告警：意味著SRE需要立即采取行動(dòng)來(lái)應(yīng)對(duì)正在發(fā)生或即將發(fā)生的事情，以改善這種情況。
Tickets：表示SRE需要采取行動(dòng)，但不是馬上，系統(tǒng)不能自動(dòng)處理這種情況，但如果一個(gè)人在幾天內(nèi)采取了動(dòng)作，就不會(huì)造成事故。
日志記錄：無(wú)需日日查看的信息，但它被記錄為診斷錯(cuò)誤或反芻的目的。
應(yīng)急響應(yīng)
可靠性是指故障時(shí)間（MTTF）和平均修復(fù)時(shí)間（MTTR）的函數(shù)，評(píng)估應(yīng)急反應(yīng)有效性地最相關(guān)的指標(biāo)是反應(yīng)小組能多快地將系統(tǒng)恢復(fù)到健康狀態(tài)，即MTTR。
一個(gè)能夠避免需要人工干預(yù)的緊急情況的系統(tǒng)比需要實(shí)際操作的系統(tǒng)有更高的可用性，當(dāng)SRE有需求時(shí)，我們發(fā)現(xiàn)，在“劇本”中提前記錄是最佳實(shí)踐，在MTTR中產(chǎn)生大約3倍的改進(jìn)，而不是“即興發(fā)揮”的策略，谷歌SRE依賴于on -call playbooks，除了諸如“不幸之輪”這樣的練習(xí)，還可以讓工程師對(duì)on - call事件做出反應(yīng)。
效率和性能
任何時(shí)候，有效利用資源都是非常重要的，由于SRE最終控制了供應(yīng)，因此它也必須參與任何有關(guān)使用的工作，因?yàn)槔寐适墙o定服務(wù)如何工作的一個(gè)函數(shù)，以及它是如何響應(yīng)的。密切關(guān)注服務(wù)的供應(yīng)策略，它的使用為服務(wù)的總成本提供了非常大的杠桿。
資源使用是需求（負(fù)載）、容量和應(yīng)用效率的函數(shù)。SRE預(yù)測(cè)需求，提供能力，并可以修改軟件，這三個(gè)因素是服務(wù)效率的很大一部分（盡管不是全部）。
隨著負(fù)載的增加，應(yīng)用系統(tǒng)會(huì)變得越來(lái)越慢，服務(wù)的減少等同于能力的喪失，在某一個(gè)時(shí)刻，當(dāng)某個(gè)緩慢的系統(tǒng)停止服務(wù)，這相當(dāng)于無(wú)限的慢。SRE提供以特性的響應(yīng)速度滿足容量目標(biāo)，因此對(duì)服務(wù)的性能非常感興趣，SRE和產(chǎn)品開發(fā)人員將（并且應(yīng)該）監(jiān)控和修改服務(wù)以提高其性能，從而增加容量和提高效率。
以上是小數(shù)今天給大家分享的文章，眾所周知，SRE的理念最早出自Google，而數(shù)人云老王（王璞）曾供職于Google的廣告部門，對(duì)于SRE有著深入的研究，在數(shù)人云的Meetup上就曾以SRE為題進(jìn)行了多次分享，同時(shí)小數(shù)也給大家分享了多篇SRE相關(guān)的文章，有興趣的可以點(diǎn)擊查看：
