經(jīng)過幾年的掙扎和討論（確切說應該是3年），老板在釘釘群以通告的方式正式告別伴隨我們多年的職業(yè)Title --- PE，改名為SRE。（后續(xù)以A SRE區(qū)別Google SRE）

BigDataSRE

暫且不提名稱變化背后的含義，對于新的稱謂的意義很明顯，SRE源于Google“網(wǎng)站可靠性工程師”的縮寫，這個職位在Google內(nèi)部有著“崇高”的地位，他們參與產(chǎn)品的設計（高擴展性、高可靠性），他們決定產(chǎn)品是否可以上線，他們研發(fā)面向海量任務、服務器、其他人員的管理系統(tǒng)、基礎(chǔ)服務、規(guī)劃系統(tǒng)等等。一時之間，SRE就是“高逼格”職業(yè)的代名詞，更讓人驚喜的是，這些工作都是運維的范疇。多年來成為苦逼代名詞的運維崗喜極而泣！原本壓抑在內(nèi)心的信條 --- “運維是最牛逼的職業(yè)” 終于得到正名。

誰都不是傻子，很快SRE帶來全新的、革命性的運維方式表面上讓運維這個行業(yè)變得光明起來，可背后涌動的“暗流”卻是我內(nèi)心反復錘問 --- “運維工程師可以轉(zhuǎn)型成SRE嗎？”，不要忘了，SRE的出生是研發(fā)工程師。

“我們常說要轉(zhuǎn)型，要做DevOps，要做SRE?？蓭啄陙恚悴虐l(fā)現(xiàn)，這只不過是一個騙局，真正需要轉(zhuǎn)型的是Dev，他們把Ops的活干了，而Ops只能另謀出路，DevOps對Ops來說就是一個笑話?！?/p>

雖然我不完全同意我同事的這番言論，但至少他把我們心里不愿承認的，不愿回答的問題給出了他的答案。

作為一個運維老兵，也希望可以找到自己問題的答案，好在<Google SRE>一書的上市，全面且細致的介紹了SRE工作，讓我可以近距離的了解和思考未來。

1.1 硬件故障

2010年，記得剛加入A云的我，每周耗費一個工作日例行到機房處理各種硬件故障，那時候我們還只有一個數(shù)據(jù)中心，運行的服務器不過寥寥幾千臺，那時的我心里有一個疑問：“以后怎么辦？”，為此后續(xù)的一年，我從事兩項相關(guān)的工作：

1. 把維修自動化，主要是磁盤和內(nèi)存的維修自動化，當廠商把損壞的硬件替換到服務器上之后，后面的維修動作就是一鍵觸發(fā)，自動修復并上線。
2. 故障預判，其實說預判有些牽強，大部分的故障我們無法做到預判，多數(shù)情況是在小時級別后發(fā)現(xiàn)硬件故障。

這能在非線性的物理服務器增長中，讓同事從繁瑣的維修工作中解脫出來，但事實上，2部分的工作帶來很多的質(zhì)疑：

“為什么機器/硬盤Hang住了，你的檢測程序卻無動于衷？”

質(zhì)疑多了不同的團隊自己就要掄開膀子自己干，造成了一些不必要的PK，這些PK漸漸的讓這些相關(guān)團隊認識到硬件是不可靠的，而不是天真的認為“一切硬件故障可以被甄別，并可以快速隔離”。重復造了輪子，明白了一個道理。

可我并沒有在<SRE>一書中找到SRE是否經(jīng)歷這樣的階段，因為一書中提到和硬件相關(guān)內(nèi)容甚少，不過在相關(guān)資料<The DataCenter As a Computer>中，能找到類似的經(jīng)歷。

文章的作者之一，Jimmy Clidaras，他從04年開始從事Google Datacenter Engineering的工作，是第一個Senior Director of Google’s Platforms Infrastructure Engineering Team。

文章提到了非常有趣觀點 --- 為了提到維修的效率，以下兩項工作非常關(guān)鍵：

1. '每天打掃一次'數(shù)據(jù)中心里需要維修的硬件。（而非時刻都在）
2. 需要一份精確的硬件損壞和分析報告，報告來自 Google System Health

最后，他同樣提到應對的觀點：(N ?理論，該論點也反復在SRE一書中提到)

TOLERATING FAULTS, NOT HIDING THEM.

Google System Health

我可以得出這樣的結(jié)論，Google的基礎(chǔ)設施團隊，他們做了大量的工作（包括科研性的工作），這一切SRE團隊并非參與者，而是“維護者”，甚至是“享用者”。（理想情況下，他們不需要再關(guān)心硬件故障或者之類，但我相信現(xiàn)實情況下，他們對硬件故障也耳熟能詳了。）

幸運的是（還是不幸？：）），硬件故障等問題經(jīng)驗至今仍然是A云SRE值得“分享”的一大類目。

** A SRE 1:0 G SRE **

1.2 硬件選型

Google的信條是：

并不會用專門的物理服務器運行專門的軟件服務器

所以，G SRE不會碰到硬件選型的煩惱。所以他們不會碰到如以下的對話：

<A TL>: '混合存儲是什么機型？??？為什么是X塊SSD硬盤呢？我的業(yè)務場景需要Y塊！'
<A SRE>:'B、C等其他業(yè)務都統(tǒng)一了，為了節(jié)省采購成本，請做應用的優(yōu)化來適配這一款混合存儲機型。'

A SRE他們有足夠的話語權(quán)。這并不是說他們可以自主研發(fā)某一款機型，他們的背后還有基礎(chǔ)系統(tǒng)研發(fā)團隊，通?；A(chǔ)研發(fā)團隊會拿出多款搭配的試驗機型供SRE來決策。一方面A SRE在這些機型之上“折中”出四不象來，看起來讓每個業(yè)務都不餓，但也都喂不飽。另一方面，A SRE開始游說業(yè)務研發(fā)的Leader們開始做應用改造和適配，否則就會面臨到貨周期、財務等一系列的挑戰(zhàn)。

因為沒有一個統(tǒng)一的資源調(diào)度系統(tǒng)（說起來很輕松），業(yè)務還是天然的區(qū)分了幾種不同類型的物理服務器：

| 機型 | 業(yè)務場景
|--------|
| A | CPU、MEM密集型、少量存儲
| B | CPU密集型、大量存儲
| C | CPU密集型、磁盤響應延遲低

每年A SRE（包括基礎(chǔ)系統(tǒng)、網(wǎng)絡團隊）因此需要做物理服務器在數(shù)據(jù)中心之間繁重的搬遷工作。

同時，針對機型的定制化改造也變得臃腫不堪，為了對機型做某些妥協(xié)的業(yè)務通過RAID，軟RAID的方式來最小化他們應用的改造成本，而這些行為都被記錄在A SRE提供的“應用模板”之中，它是系統(tǒng)裝機之后必須經(jīng)過的步驟，以確保機型被正確的配置了。

機型規(guī)劃、有效縮減是A SRE必備的課題，由于缺乏長期看得見的舉措，A SRE用短期“自動化”的手段補位，相信這也是A SRE值得分享的心路歷程。

** A SRE 2:0 G SRE **

1.3 基礎(chǔ)軟件系統(tǒng)

1.3.1 Borg

Borg并不是SRE團隊研發(fā)的產(chǎn)品，無論是資料還是John Wilkes 15年的分享（其實我早知道:)）?？蔀槭裁疵看翁崞養(yǎng)rog，就會讓人聯(lián)想到G SRE? 就像每次提及雙11，就會讓人聯(lián)想到阿里巴巴技術(shù)保障部。我覺得這種錯覺是相似的 --- 當你既是這款產(chǎn)品的使用者，又是這款產(chǎn)品的維護者，那你最適合做這款產(chǎn)品的代言人。

Borg讓G SRE進化，G SRE讓Borg進化?？纯磿蠫 SRE進化的例子吧

最初的自動化包括簡單的Python腳本，執(zhí)行如下的操作。

• 服務管理：保障服務運行（例如，在段錯誤后重新啟動） --- borg
• 跟蹤 那些服務應該運行在那些機器上。 --- Borg
• 日志消息解析：SSH進入每一臺機器，用正則表達式過濾日志。 --- gRPC。

我做了標注部分，書中是這樣解釋的。

“最初的自動化努力給我們爭取了足夠的時間，把集群管理轉(zhuǎn)化為自治系統(tǒng)，而不是自動化系統(tǒng)?！?br> “機器的損壞和生命周期的管理已經(jīng)不需要任何操作了。成千上萬的機器加入系統(tǒng)，或者出現(xiàn)問題，被修復，這一切都不需要SRE的任何操作?！?/p>

很有意思，G SRE并沒有覺得自己曾經(jīng)的工作被替代（更別提被“別人”拯救）我想唯一的可能是G SRE有極大的參與感和主導權(quán)。

A SRE在地球的另一端，仍用著“最初的自動化腳本”執(zhí)行著去完成那些操作。宣稱不久將“替代”A SRE這些腳本的DevOps團隊，從1.0演進到2.0再到現(xiàn)在3.0，多年來風風雨雨，你來我往，既沒有兌現(xiàn)當年的承諾，也沒有留下“戰(zhàn)友”般的友誼。干活累的時候，相互噴一嘴解解乏。

** A SRE 2:1 G SRE **

1.3.2 BorgMon

** A SRE 2:2 G SRE **

1.3.3 Jupiter&BwE

Google Jupiter和BwE(帶寬控制器)，實現(xiàn)了一個巨大的可供管理的虛擬網(wǎng)絡，在一個數(shù)據(jù)中心里，幾百臺自研的交換機以Clos方式連接為一體，擁有幾W個虛擬端口，提供1.3Pb/s交叉帶寬。

網(wǎng)絡也并不由A SRE直接維護，但A SRE在數(shù)據(jù)中心網(wǎng)絡問題的排查中往往會起到?jīng)Q定性的作用，而相比較G SRE的BwE，A SRE更有辦法能夠找那個“壞小子”應用，人肉充當帶寬控制器的角色，當然前提是時間允許的情況下。

** A SRE 2:3 G SRE **

1.3.4 存儲系統(tǒng)

D Service

A云的存儲系統(tǒng)和G司類似，除了D服務。A云并沒有D服務，底層磁盤是直接由分布式文件系統(tǒng)盤古直接管理，在盤古之上也衍生出很多數(shù)據(jù)庫服務，如MaxCompute、OTS、OSS等。

或許沒有D服務，盤古僅能按照集群來管理不同類型的磁盤，還無法做到數(shù)據(jù)中心級別。

** A SRE 2.5:4 G SRE **

1.3.5 分布式鎖服務

和存儲類似，相比較可以提供多個數(shù)據(jù)中心服務的Chubby，A云的分布式鎖服務僅能按照集群級別管理。

** A SRE 3:5 G SRE **

1.3.6 GSLB

** A SRE 3:6 G SRE **

1.3.7 結(jié)束

我相信G SRE的成功之一源于G基礎(chǔ)軟件服務成功，正如蒸汽火車和磁懸浮列車最高時速的差距并不在于“司機”的操作技巧。

本節(jié)只能依據(jù)書中明確提到由SRE團隊研發(fā)產(chǎn)品來橫向的比較。書中提到大部分Google內(nèi)部幕后的軟件工程實踐都是來自SRE部門，而此類現(xiàn)象在A云并不多見，相反，在A云多數(shù)源于SRE部門的idea，而往往實踐落到了研發(fā)部門，我們稱之為“收編”。

2.1 Auxon

容量規(guī)劃是兩個SRE都要直面的問題，而且兩者都意識到了傳統(tǒng)容量規(guī)劃的方法帶來的巨大開銷和不確定性。

G SRE和技術(shù)項目經(jīng)理研發(fā)了Auxon，一款基于“意圖”的容量規(guī)劃工具。A SRE雖然表現(xiàn)上已經(jīng)告別了表格的方式，但容量規(guī)劃的系統(tǒng)是財務主導，由研發(fā)團隊支撐，和SRE并沒有太大的關(guān)系。而A SRE更多的專注在研發(fā)如何“高效”的提供讓人信服的業(yè)務數(shù)據(jù)和趨勢分析的平臺。

從書上可以了解到，G司擁有不止一套容量規(guī)劃的模型和工具，用于滿足數(shù)據(jù)樣本和規(guī)劃模型之間的差異化，G SRE也意識到Auxon也無法滿足所有項目。但書中沒有提到的是大型分布式系統(tǒng)的容量規(guī)劃，這背后不是簡單一個或幾個技術(shù)指標的分析與運算，容量規(guī)劃背后那些KPI的目標，不同部門相互交織，視角和理解數(shù)據(jù)的方式完全不同，A SRE要面臨的挑戰(zhàn)或許要大的多。

** A SRE 0:1 G SRE **

2.2 Layer-3 Load Balancer

對于這款產(chǎn)品，書中提及的篇幅不多，我翻閱了一下參考資料<Maglev: A Fast and Reliable Software Network Load Balancer>，文章的作者大多數(shù)來是Google的資深軟件研發(fā)工程師。

G SRE源自對網(wǎng)站的可靠性維護，自然的對負載均衡器有非常深的理解，從19、20章的描述可以感受到LB是那種根植于SRE技能條里必備技能。根據(jù)我個人的以往工作經(jīng)歷，曾經(jīng)幾乎一整年的工作就是和商業(yè)負載均衡器打交道，反而到了A云接觸的少了。

** A SRE 0:2 G SRE **

2.3 Sisyphus

Tesla

通用的自動化發(fā)布框架,和G SRE類似的，A SRE團隊已經(jīng)實現(xiàn)了支持自動化發(fā)布的復雜部署、升級流程，這個平臺叫Tesla。同時，它也具備負責記錄每個步驟執(zhí)行過程和異常通知，提供Python擴展包，唯一讓我覺得遺憾的是，Sisyphus和構(gòu)建工具打通，做到代碼構(gòu)建到上線快速發(fā)布。我相信任何的線上發(fā)布除了系統(tǒng)之間互通之外，也需要研發(fā)團隊、發(fā)布團隊和SRE團隊之間的互通。而Tesla目前雖然還未和構(gòu)建平臺有任何的交互，但在團隊直接的協(xié)同通知上，已經(jīng)研發(fā)出了一套面向工程師的“發(fā)布申請流程”。

Tesla平臺已經(jīng)在內(nèi)部運行了幾年，是由A SRE主導研發(fā)的智能運維平臺，除了自動化發(fā)布框架，它還整合了其他很多SRE主導研發(fā)的產(chǎn)品。

** A SRE 1:3 G SRE **

2.4 其他

Google Cron&Google WorkFlow，書中有專門的章節(jié)提及，但并未直言這兩個產(chǎn)品是由SRE團隊研發(fā)，我想列出來的原因是本是大型分布式系統(tǒng)應該依賴的基礎(chǔ)軟件，G SRE可以明白的闡述其軟件設計思路和實現(xiàn)，而A云，早在幾年前也有類似的產(chǎn)品服務整個數(shù)據(jù)中心，但由于組織架構(gòu)的調(diào)整，這些服務慢慢的變成“無人區(qū)”，更別提有業(yè)務應用敢使用，作為A SRE的一員，未免令人唏噓不已。

** A SRE 1:4 G SRE **

3.1 培訓新人

很不幸，我不得不承認A SRE團隊目前就是這種“浴火重生”的學習方式，幸運的話，有能力的工程師最后能夠從這種大坑里爬出來（所以我們招人異常困難），但更常見的是，多數(shù)有能力的工程師都無法在這種環(huán)境里成長。我們意識的問題的現(xiàn)狀，卻仍然沒有騰出手來改變。

雖然說，我們的初衷和G SRE相同，培養(yǎng)工程師個人的能力，與其讓他們傳授知識，不如自己動手（感覺我有點厚顏無恥），可與G SRE 提供明確的系統(tǒng)性培訓目標以及不同領(lǐng)域的SRE專家和研發(fā)聯(lián)系人不同是，A SRE知識體系仍然在口口相傳。

相比較G SRE在生產(chǎn)系統(tǒng)做故障演練和破壞性學習，大多數(shù)A SRE會從測試環(huán)境成長起來，測試環(huán)境的配置問題和軟件標準化遠遠比生產(chǎn)環(huán)境糟糕的多，雖然A SRE可以在測試環(huán)境做一些破壞性的試驗加深對系統(tǒng)的理解，但相比較生產(chǎn)系統(tǒng)，這可以說是完全不同的世界。

缺少有效的事后總結(jié)和文檔能力，A SRE每周的不定期的知識技能分享也面臨無法維繼的風險。

** A SRE 0:1 G SRE **

3.2 接手一項服務/產(chǎn)品

在A云只有部分服務是一開始就是SRE負責運維的。但和G SRE不同的是，A SRE開始剛接手服務/產(chǎn)品往往都是一個“爛攤子”。

為了提高該服務的可靠性，A SRE往往會參與產(chǎn)品的設計和下個迭代版本的構(gòu)建：

• 系統(tǒng)的結(jié)構(gòu)體系，從下自上的高可用優(yōu)化方案。
• 監(jiān)控，提供更加豐富和標準的監(jiān)控接口。（很多產(chǎn)品接手時，沒有任何監(jiān)控，研發(fā)團隊甚至不清楚有什么監(jiān)控平臺。）
• 選擇指標，度量服務可用性的關(guān)鍵指標。
• 緊急事件的處理機制和升級路線。
• 服務日志分析。
• 通過Tesla的平臺擴展產(chǎn)品自我快速迭代的能力。

并且往往在A SRE還未完全驗收好相關(guān)改進和方案，產(chǎn)品就要開門“接客”了。

• 文檔，A SRE決定了一個產(chǎn)品運維文檔的撰寫能力
• 咨詢，“飛機”已經(jīng)起飛，始料未及的“Bug”需要研發(fā)團隊和A SRE在線找到辦法修復/臨時繞過，等待下一個迭代版本。（在這里，原本應該提供的運維改進版本又Delay了。）

A SRE周圍充滿了人情和感性，業(yè)務產(chǎn)品那個不是從水深火熱之中爬出來，而我們又如何能夠袖手旁觀呢？

G SRE PRR模型是非常值得借鑒的一種接管服務的方式，G SRE的這套方法論更堅定了A SRE的未來改進的方向。

** A SRE 1:2 G SRE **

3.2 團隊構(gòu)成

SRE團隊構(gòu)成多樣化，有些成員喜歡責任職責被明確的定義（僅作研發(fā)效率相關(guān)的工作），據(jù)此可以迅速安全的做出范圍內(nèi)的決策，另一些成員在一個更為動態(tài)的環(huán)境中工作，隨時切換責任。

A SRE相比G SRE是一個更為動態(tài)的團隊，團隊內(nèi)部比較來說，只有數(shù)據(jù)分析/運營的職責（技能）的SRE技能切換不太頻繁。

A SRE技術(shù)負責人承擔了不僅負責團隊技術(shù)方向，還有績效管理和橫向團隊協(xié)作等（其他一切其他人不能處理的事情），所剩的工作時間很少能夠review團隊成員的代碼，更多方通過在團隊中推進共識的建立來引領(lǐng)團隊。

** A SRE 2:3 G SRE **

通讀<SRE>全書，不禁贊嘆！

一千個人眼中有一千個哈姆雷特，在意識到差距的同時更不必妄自菲薄，更重要的是思考這些差距的所欠缺是努力還是思想，是再次驅(qū)動我翻開這本書細細再品的動力。

更讓我收獲的是，書中那些活生生的案例。

1. 一項不穩(wěn)定的服務，Bigtable穩(wěn)定性造成報警過多，降低SLO減少報警，重點提升Bigtable的軟件性能。

2. Gmail的手工干預哲學：是短期麻木于SRE的提供的工具減少影響還是長期找到根因，并解決。
3. 遷移Mysql到Brog，Brog不是萬能，至少離開SRE在業(yè)務上做的優(yōu)化，這項工作無法得以完成。

這些案例書中有的給出的答案，有的沒有，給我最大的幾點共鳴

1. “世界上沒有捷徑”，我們經(jīng)歷著的也是G SRE經(jīng)歷過的。
2. 沒有一種答案可以解決所有問題，試圖回答文章之初的問題變得可笑，SRE是一個積累的命題，尋找總開關(guān)想一勞永逸注定是徒勞無益。
3. 只有非比尋常的努力，才配的上不尋常的Idea。