摘要：堅持演習(xí)谷歌定期做的演習(xí)，如最高等級的演習(xí)是定期把數(shù)據(jù)中心強制關(guān)閉，進入維護狀態(tài)。經(jīng)過長期演練，谷歌內(nèi)部系統(tǒng)的容錯能力增強。

王璞/數(shù)人云創(chuàng)始人&CEO

美國George Mason 大學(xué)計算機博士。曾先后供職于 Google、Groupon 和 StumbleUpon等硅谷互聯(lián)網(wǎng)公司。擅長分布式計算、大規(guī)模機器學(xué)習(xí)、海量數(shù)據(jù)處理。曾擔(dān)任 Google廣告部門數(shù)據(jù)平臺構(gòu)架師，負(fù)責(zé)管理每秒訪問量全球最高的架構(gòu)平臺。

數(shù)人云是基于容器的輕量級PaaS平臺落地企業(yè)客戶時，客戶很難理解一個平臺背后隱含的東西，任何平臺及工具都是與方法論結(jié)合的，比如研發(fā)工具、持續(xù)交付工具等等，都有一套方法和理念，今天主要分享下SRE理念在傳統(tǒng)企業(yè)中的落地實踐。

隨著技術(shù)的發(fā)展，運維環(huán)境發(fā)生了新變化，比如互聯(lián)網(wǎng)的場景下，線上業(yè)務(wù)和線下業(yè)務(wù)的差異非常大。

大規(guī)模、分布化：

從傳統(tǒng)的封閉式系統(tǒng)架構(gòu)向分布式部署的開源系統(tǒng)架構(gòu)演進，系統(tǒng)規(guī)模快速增長，尤其是谷歌互聯(lián)網(wǎng)業(yè)務(wù)數(shù)據(jù)中心，大概有200多萬臺服務(wù)器，這個規(guī)模是十分龐大的。

技術(shù)棧復(fù)雜：

開源技術(shù)層出不窮，再加上大數(shù)據(jù)技術(shù)，技術(shù)棧變得越來越復(fù)雜。

大流量、高并發(fā)：

用戶體量急劇擴張，互聯(lián)網(wǎng)場景大流量，高壓并發(fā)壓力增大。跟唯品會的朋友聊到，幾個小時的促銷時間里，近百萬的流量，這在傳統(tǒng)線下是沒有遇到過的。

高頻變更：

大量新業(yè)務(wù)的推出，各種與業(yè)務(wù)相關(guān)的線上活動帶來高頻變更需求。

國內(nèi)電商每個月都有節(jié)日促銷，都有重大的變更，互聯(lián)網(wǎng)公司至少做到一周變更一次。對于傳統(tǒng)企業(yè)客戶來講是很大的，如銀行大都是半年做一次變更。這些運維環(huán)境新的變化，主要是由于互聯(lián)網(wǎng)場景的變化所帶來的。

DevOps的知識結(jié)構(gòu)非常復(fù)雜，從規(guī)劃設(shè)計階段到開發(fā)階段，對于很多企業(yè)的客戶來說無法落地，就連部分互聯(lián)網(wǎng)公司也未必能完完整整把DevOps從設(shè)計到開發(fā)、交付直至上線完整地落地。

例：流程圖里面太多的數(shù)據(jù)和細節(jié)，很多細節(jié)至今都未深入涉及。

DevOps是開發(fā)、運維一體化，從業(yè)務(wù)的需求到開發(fā)、交付上線一體的。

上面是DevOps偏理論的部分，中間是落地到技術(shù)的部分，底層是基于軟件的基礎(chǔ)架構(gòu)。真正把DevOps落地好需要理解的東西太多，成本太高，所以谷歌在DevOps的方面，尤其在偏運維的方面總結(jié)出一套SRE理念，這套SRE的方法論是DevOps思想在谷歌運維方面的最佳實踐。

首先明確下概念：

DevOps有很多實踐，豐田汽車這種傳統(tǒng)制造業(yè)公司也用DevOps。
SRE是DevOps的一種實踐，偏互聯(lián)網(wǎng)公司一些，前面提到SRE在谷歌內(nèi)部偏重運維部分，開發(fā)設(shè)計不是特別多，也不會提敏捷開發(fā)這些。

SRE是怎樣來的呢？2003年，谷歌數(shù)據(jù)中心規(guī)模應(yīng)該在幾千臺甚至是上萬臺的服務(wù)器，當(dāng)時沒有運維，更多叫系統(tǒng)管理員，很多系統(tǒng)管理員不能管理大規(guī)模的X86服務(wù)器的系統(tǒng)（當(dāng)時主機的IT硬件設(shè)備是大型機的設(shè)備，系統(tǒng)管理員管理的絕大部分都是小型機，谷歌從來不買大型機），于是被迫從開發(fā)中找出來7個人轉(zhuǎn)崗做生產(chǎn)運維，他們做數(shù)據(jù)管理中心運維的時候發(fā)現(xiàn)很多的問題，首先系統(tǒng)管理有很多重復(fù)性的工作，運行腳本等等，這些開發(fā)工程師對重復(fù)的工作比較抵觸，所以自己開發(fā)大量的運維工具自動化的實現(xiàn)運維，這批開發(fā)工程師就是現(xiàn)在的SRE。

三角形的圖顯示了谷歌的SRE工程師日常工程的內(nèi)容和職責(zé)，主要是工程的研發(fā)，剩下才是日常運維。

傳統(tǒng)的系統(tǒng)管理員是人盯著機器，但隨著人員的成本越來越高，需要解決的問題不盡相同且效率低下，面對服務(wù)器規(guī)模越來越大的問題，統(tǒng)運維模式已不適用于互聯(lián)網(wǎng)的場景。

開發(fā)：

SRE工程師絕大部分時間要寫代碼，必須要有很強的開發(fā)能力。

日常運維：

除了開發(fā)之外最重要的是管理資源，如所有資源的效果、性能等。

如，大規(guī)模的互聯(lián)網(wǎng)數(shù)據(jù)中心，服務(wù)器規(guī)模龐大，資源的利用率對于數(shù)據(jù)中心的成本很重要，因此降低數(shù)據(jù)成本是很有幫助的，谷歌數(shù)據(jù)中心的利用率還是比較高的，數(shù)據(jù)中心有一個數(shù)值，就是數(shù)據(jù)中心花一度電有多少是用于冷卻的，有多少是用于服務(wù)器計算的，谷歌每花1度電用到計算上，只有零點幾度電是用到服務(wù)器冷卻的。

這個怎么理解呢？對于Gmail服務(wù)，不管是活躍用戶還是非踴躍的用戶，一年使用Gmail的服務(wù)花谷歌的電費一美元不到，數(shù)據(jù)中心對于成本、資源的利用率有很苛刻的考量，SRE就是幫助谷歌實現(xiàn)數(shù)據(jù)中心最大化的利用率。因為200多萬臺的服務(wù)器，谷歌損失10%，就相當(dāng)于有20萬臺服務(wù)器是被消耗掉的，假如谷歌全部采用虛擬機的話，額外的開銷是15%左右，甚至是20%，若所有的服務(wù)器都變成虛擬機，基本上谷歌20%的資源不能用，至少幾十萬臺服務(wù)器被虛擬化了，底層的系統(tǒng)消耗對谷歌來講不能接受的。怎么樣做到高效——SRE。

對于變更管理，谷歌和傳統(tǒng)的運維不一樣，傳統(tǒng)的運維做變更時需要開發(fā)提供上線，谷歌的SRE不是開發(fā)提供給SRE上線，是SRE把各種各樣的變更發(fā)布的平臺準(zhǔn)備好，每個系統(tǒng)上線變更都是利用開發(fā)的人員自行的發(fā)布、自行上線。

應(yīng)急響應(yīng)：

緊急響應(yīng)與傳統(tǒng)運維一樣需要值班，以確保系統(tǒng)出現(xiàn)任何問題都有人去解決。

SRE：

優(yōu)：自動化、可編程性、效率高。
SRE強調(diào)自動化，運維的工作絕大部分是工具自動化的完成。

缺：人才少、團隊搭建管理無參考、系統(tǒng)管理方式需管理層支持
SRE缺點也很明顯，就是招人難，需要有編程的能力和開發(fā)能力，對系統(tǒng)也要有很深的理解，比如對網(wǎng)絡(luò)、內(nèi)核等，同時SRE業(yè)界的參考比較少，主要是谷歌等大公司在用。

傳統(tǒng)運維：

優(yōu)：大量經(jīng)驗可借鑒、易招聘、工具多。
傳統(tǒng)運維經(jīng)驗很豐富尤其絕大多數(shù)的企業(yè)都是傳統(tǒng)的模式。

缺：人員自身技能依賴性強，人員規(guī)模與系統(tǒng)規(guī)模線性相關(guān)，各系統(tǒng)獨立需人工切換，依賴腳本管理。
傳統(tǒng)運維缺點是很多事情都是人力來做，這樣隨著服務(wù)器越來越多，業(yè)務(wù)規(guī)模越來越大，人也越來越多，效率提不上去。

長期關(guān)注研發(fā)工作

谷歌的SRE文化是做的很好的，保證SRE有比較充足的時間做研發(fā)，限制每個人的運維工作在50%以下，保證充足時間去寫程序。

SRE每8到12小時值班時間窗里最多只處理兩個事件。

堅持演習(xí)

谷歌定期做SRE的演習(xí)，如最高等級的演習(xí)是定期把數(shù)據(jù)中心強制關(guān)閉，進入維護狀態(tài)?；谶@種情況，開發(fā)在寫程序的時候必須考慮到容錯、數(shù)據(jù)中心不可用，硬件不能進行，所關(guān)聯(lián)的其他軟件系統(tǒng)不可用等情況。

經(jīng)過長期演練，谷歌內(nèi)部系統(tǒng)的容錯能力增強。一個系統(tǒng)容錯能力強，對于運維是良性循環(huán)，出了問題不容易宕機，SRE運維壓力自然下降。

決策與建言權(quán)

SRE關(guān)注的非功能性的要求，比如說穩(wěn)定性等等。這些非功能性的要求在開發(fā)寫程序的時候早早把SRE引進，如果一個系統(tǒng)盡可能滿足SRE非功能性的需求，這個系統(tǒng)是比較容易上線的，但如果一個系統(tǒng)沒有滿足SRE的要求，每個月的報警數(shù)量過多，SRE可以讓這樣的系統(tǒng)上線，但SRE不接手運維。谷歌內(nèi)部有一個說法，一個事情SRE說NO，這個事情是做不下去的。

建設(shè)平臺化服務(wù)體系

平臺和工具實現(xiàn)自動化、自助化

比如開發(fā)寫出的代碼要提交到代碼庫，對于代碼的測試和覆蓋、風(fēng)格都有很多的檢查，這些檢查不是靠人而是靠工具平臺自動化的完成。
制定各項規(guī)章制度

SRE內(nèi)部分工明確

如谷歌搜索有SRE，谷歌廣告有SRE，還有設(shè)計平臺等等都有，這些是偏業(yè)務(wù)的。雖然每個SRE部門不多，但是加起來，有一半的SRE散落在各個業(yè)務(wù)部門負(fù)責(zé)相關(guān)任務(wù)。

容量規(guī)劃和容量管理

SRE根據(jù)業(yè)務(wù)容量地規(guī)劃每個業(yè)務(wù)系統(tǒng)，包括搜索系統(tǒng)、軟件內(nèi)部架構(gòu)的系統(tǒng)，必須有準(zhǔn)確的自然和非自然增長需求規(guī)劃

容量管理，要定期做壓力測試，把對于資源的要求測出來

如一核的CPU能夠處理廣告以及搜索系統(tǒng)多少并發(fā)等等，這些對于性能的消耗、性能的關(guān)聯(lián)都是SRE做的，業(yè)務(wù)部門提一個數(shù)據(jù)，比如搜索部門的開發(fā)肯定提不出來業(yè)務(wù)系統(tǒng)要多少的CPU，提供出來的負(fù)載指標(biāo)都是每一秒中搜索多少的并發(fā)和處理多少的請求。SRE通過壓力測試把負(fù)載轉(zhuǎn)化成對于資源的要求，不同的搜索部門一秒鐘處理一萬個請求，一萬個請求需要多少的CPU等等，這都是壓力測試把負(fù)載資源等關(guān)聯(lián)起來。

任何有關(guān)利用率的討論和改進

保障SLO并最大化迭代速度

如某個業(yè)務(wù)系統(tǒng)新版本20%不可靠，新版本不如老版本穩(wěn)定，老版本99%可靠，新版本有20%可靠，則新版本全部上線無法達到99%的穩(wěn)定，于是只能上線一部分，服務(wù)5%的用戶，這樣最多有1%的用戶沒有辦法用服務(wù)，仍滿足SRE提出來的系統(tǒng)要求99%的可靠性。

SRE和開發(fā)之間用SLO實現(xiàn)最大上線的速度，也平衡了兩者之間的矛盾。

變更管理

變更管理：70%的生產(chǎn)都是由變更引起的。谷歌的變更一定是間接發(fā)布，其系統(tǒng)有自動回滾，這樣降低了新版上線帶來的影響。

有效監(jiān)控

谷歌內(nèi)部對監(jiān)控尤其是對報警及其是嚴(yán)格的，每一個報警出來都必須有明確的動作，要執(zhí)行哪個操作都寫在變更手冊里。

谷歌的三種有效輸出：告警、工單、日志。

正確姿勢

值班時任何一個報警必須有明確的動作。谷歌要求報警發(fā)生以后，值班人查閱手冊就可以應(yīng)對問題。

若告警是新的，值班SRE不做處理，升級告警，讓開發(fā)過來幫忙處理。值班時SRE主要解決線上問題，一旦出現(xiàn)問題，尤其是告警很嚴(yán)重的問題，通過工具半自動回滾，回滾之后保證業(yè)務(wù)穩(wěn)定、可用，讓業(yè)務(wù)快速恢復(fù)起來。

谷歌內(nèi)部要求出現(xiàn)過的問題超過三次以上，必須要有自動化修復(fù)方法，問題要么根本性的解決，要么自動化的修復(fù)。

12法則

12法則是非常好的設(shè)計模式，通用于很多互聯(lián)網(wǎng)應(yīng)用，適合開發(fā)和運維人員。

日志

12法則要求把日志當(dāng)事件流，容器很容易做到，因為容器的標(biāo)準(zhǔn)輸出都是事件流的方式。

持續(xù)集成和持續(xù)交付

流程我們跟很多的企業(yè)碰撞過，尤其是傳統(tǒng)企業(yè)，流程需要監(jiān)管，沒有辦法做到完全的自動化，需要大量人去做。如變更的申請需要人，構(gòu)建和一部分的測試可以做到自動化，讓工具去完成，但是還有大量的測試在企業(yè)中是人工的，尤其是一些IT部門過來做的測試。有很多工具可以把變更的情況自動化的處理，變更中遇到很多的問題自動化的記錄下來，方便變更后的審查。

配置管理

將配置的文件外掛到容器內(nèi)部，程序可以訪問，另外配置文件封裝起來，跟程序封裝在一起，這些方法沒有對錯，只是哪些客戶能接受哪些客戶不能接受的問題。

日志從定向到標(biāo)準(zhǔn)輸出

很多日志文件在傳統(tǒng)企業(yè)按照文件的方式收集過來，日志里面針對問題有特定審查和審批的流程等等。

容器對于應(yīng)用程序做標(biāo)準(zhǔn)化的封裝，日志文件寫到容器內(nèi)部，程序不做任何的更改，通過外部手段對容器進行內(nèi)部搜索，帶來了大量的問題，如果程序在容器內(nèi)寫了大量的日志怎么辦？日志文件達好幾G的文件怎么辦？嚴(yán)重的破壞容器的性能，這個也有優(yōu)點和缺點。如日志文件外掛在容器外，客戶已有處理方法，對于容器要有額外的配置、額外的參數(shù)，容器要遷移到別的服務(wù)上，怎么樣保證碎片化的日志被完整收集起來，仍然有很多的問題，不同的容器有不同的方法。

監(jiān)控

目前碰到的客戶絕大部分有成型的監(jiān)控體系，且客戶不希望用了容器平臺以后又有新的監(jiān)控系統(tǒng)，因此要跟客戶已有的系統(tǒng)對接打通。

彈性擴縮

如業(yè)務(wù)的負(fù)載太大，系統(tǒng)程序需要擴展實例，以前可能只有3個容器負(fù)載，現(xiàn)在3個不夠，要擴展到10個，怎么觸發(fā)？人為的觸發(fā)還是自動化的觸發(fā)？觸發(fā)后這個實例是否優(yōu)雅終止，怎么理解？

實例收縮也很復(fù)雜，很多傳統(tǒng)的企業(yè)都是交易型的，不能隨便動，觸發(fā)準(zhǔn)則絕大部分沒有見過自動的收縮，是人工觸發(fā)的動作。大部分企業(yè)處理應(yīng)用，必須保證程序上處理的業(yè)務(wù)完了才能關(guān)閉。怎么判斷程序處理掉了？這時候又要對現(xiàn)有程序進行改造，客戶又不想改那個程序怎么辦？比如通過跟負(fù)載均衡器感知一個程序以及后臺實例流量完全結(jié)束了再關(guān)掉，這是很多現(xiàn)實落地的考慮。

怎么樣判斷模型是成功的？這里有一個曲線，SRE講究自動化以及提升平臺效率。

藍色代表業(yè)務(wù)規(guī)模，對等過來是開發(fā)人員的數(shù)量，也可以理解成數(shù)據(jù)中心服務(wù)器的數(shù)量，這個跟業(yè)務(wù)規(guī)模是成正比的，業(yè)務(wù)規(guī)模大業(yè)務(wù)人員多，開發(fā)人員肯定多，負(fù)載高服務(wù)器的數(shù)量多，藍色的曲線一定是快速的通道，任何一個企業(yè)都希望業(yè)務(wù)快速增長。

紅色運維數(shù)據(jù)跟人相關(guān)，任何一個企業(yè)不希望人與業(yè)務(wù)一起增長，業(yè)務(wù)增長10倍，開發(fā)人員跟著漲到7－8倍，業(yè)務(wù)的人員漲7－8倍，顯然成本太高了。

SRE模型成功的標(biāo)準(zhǔn)是業(yè)務(wù)快速的增長，人不需要同比增加，通過平臺自動化滿足業(yè)務(wù)增長需求。如谷歌從2003年開始幾千至一萬臺的服務(wù)器增加到現(xiàn)在200多萬臺，而人按照這個比例來增長，這就是整個SRE不斷帶來的效率提升。

以上是數(shù)人云對于SRE落地傳統(tǒng)行業(yè)的思考，如有更多想法請加小數(shù)微信：xiaoshu062 進數(shù)人云微信群交流。

技術(shù)干貨、外文翻譯、活動預(yù)告、這里全都有！掃碼關(guān)注數(shù)人云微信號。