摘要：堅持演習谷歌定期做的演習，如最高等級的演習是定期把數據中心強制關閉，進入維護狀態。經過長期演練，谷歌內部系統的容錯能力增強。

王璞/數人云創始人&CEO

美國George Mason 大學計算機博士。曾先后供職于 Google、Groupon 和 StumbleUpon等硅谷互聯網公司。擅長分布式計算、大規模機器學習、海量數據處理。曾擔任 Google廣告部門數據平臺構架師，負責管理每秒訪問量全球最高的架構平臺。

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

隨著技術的發展，運維環境發生了新變化，比如互聯網的場景下，線上業務和線下業務的差異非常大。

大規模、分布化：

從傳統的封閉式系統架構向分布式部署的開源系統架構演進，系統規模快速增長，尤其是谷歌互聯網業務數據中心，大概有200多萬臺服務器，這個規模是十分龐大的。

技術棧復雜：

開源技術層出不窮，再加上大數據技術，技術棧變得越來越復雜。

大流量、高并發：

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

高頻變更：

大量新業務的推出，各種與業務相關的線上活動帶來高頻變更需求。

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

DevOps的知識結構非常復雜，從規劃設計階段到開發階段，對于很多企業的客戶來說無法落地，就連部分互聯網公司也未必能完完整整把DevOps從設計到開發、交付直至上線完整地落地。

運維IT服務管理流程

例：流程圖里面太多的數據和細節，很多細節至今都未深入涉及。

開發、運維一體化

DevOps是開發、運維一體化，從業務的需求到開發、交付上線一體的。

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

首先明確下概念：

DevOps有很多實踐，豐田汽車這種傳統制造業公司也用DevOps。
SRE是DevOps的一種實踐，偏互聯網公司一些，前面提到SRE在谷歌內部偏重運維部分，開發設計不是特別多，也不會提敏捷開發這些。

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

三角形的圖顯示了谷歌的SRE工程師日常工程的內容和職責，主要是工程的研發，剩下才是日常運維。

傳統運維模式

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

SRE的工作職責

開發：

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

日常運維：

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

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

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

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

應急響應：

緊急響應與傳統運維一樣需要值班，以確保系統出現任何問題都有人去解決。

SRE：

優：自動化、可編程性、效率高。
SRE強調自動化，運維的工作絕大部分是工具自動化的完成。

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

傳統運維：

優：大量經驗可借鑒、易招聘、工具多。
傳統運維經驗很豐富尤其絕大多數的企業都是傳統的模式。

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

長期關注研發工作

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

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

堅持演習

谷歌定期做SRE的演習，如最高等級的演習是定期把數據中心強制關閉，進入維護狀態。基于這種情況，開發在寫程序的時候必須考慮到容錯、數據中心不可用，硬件不能進行，所關聯的其他軟件系統不可用等情況。

經過長期演練，谷歌內部系統的容錯能力增強。一個系統容錯能力強，對于運維是良性循環，出了問題不容易宕機，SRE運維壓力自然下降。

決策與建言權

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

建設平臺化服務體系

平臺和工具實現自動化、自助化

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

SRE內部分工明確

如谷歌搜索有SRE，谷歌廣告有SRE，還有設計平臺等等都有，這些是偏業務的。雖然每個SRE部門不多，但是加起來，有一半的SRE散落在各個業務部門負責相關任務。

容量規劃和容量管理

SRE根據業務容量地規劃每個業務系統，包括搜索系統、軟件內部架構的系統，必須有準確的自然和非自然增長需求規劃

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

如一核的CPU能夠處理廣告以及搜索系統多少并發等等，這些對于性能的消耗、性能的關聯都是SRE做的，業務部門提一個數據，比如搜索部門的開發肯定提不出來業務系統要多少的CPU，提供出來的負載指標都是每一秒中搜索多少的并發和處理多少的請求。SRE通過壓力測試把負載轉化成對于資源的要求，不同的搜索部門一秒鐘處理一萬個請求，一萬個請求需要多少的CPU等等，這都是壓力測試把負載資源等關聯起來。

任何有關利用率的討論和改進

保障SLO并最大化迭代速度

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

SRE和開發之間用SLO實現最大上線的速度，也平衡了兩者之間的矛盾。

變更管理

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

有效監控

谷歌內部對監控尤其是對報警及其是嚴格的，每一個報警出來都必須有明確的動作，要執行哪個操作都寫在變更手冊里。

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

正確姿勢

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

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

谷歌內部要求出現過的問題超過三次以上，必須要有自動化修復方法，問題要么根本性的解決，要么自動化的修復。

12法則

12法則是非常好的設計模式，通用于很多互聯網應用，適合開發和運維人員。

日志

12法則要求把日志當事件流，容器很容易做到，因為容器的標準輸出都是事件流的方式。

持續集成和持續交付

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

配置管理

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

日志從定向到標準輸出

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

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

監控

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

彈性擴縮

如業務的負載太大，系統程序需要擴展實例，以前可能只有3個容器負載，現在3個不夠，要擴展到10個，怎么觸發？人為的觸發還是自動化的觸發？觸發后這個實例是否優雅終止，怎么理解？

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

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

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

紅色運維數據跟人相關，任何一個企業不希望人與業務一起增長，業務增長10倍，開發人員跟著漲到7－8倍，業務的人員漲7－8倍，顯然成本太高了。

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

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

技術干貨、外文翻譯、活動預告、這里全都有！掃碼關注數人云微信號。