原文鏈接：https://www.jianshu.com/p/6c222a0832ee
經過幾年的掙扎和討論（確切說應該是3年），老闆在釘釘羣以通告的方式正式告別伴隨我們多年的職業Title —- PE，改名爲SRE。（後續以A SRE區別Google SRE）
BigDataSRE
暫且不提名稱變化背後的含義，對於新的稱謂的意義很明顯，SRE源於Google“網站可靠性工程師”的縮寫。
這個職位在Google內部有着“崇高”的地位，他們參與產品的設計（高擴展性、高可靠性），他們決定產品是否可以上線，他們研發面向海量任務、服務器、其他人員的管理系統、基礎服務、規劃系統等等。
一時之間，SRE就是“高逼格”職業的代名詞，更讓人驚喜的是，這些工作都是運維的範疇。多年來成爲苦逼代名詞的運維崗喜極而泣！原本壓抑在內心的信條 —- “運維是最牛逼的職業” 終於得到正名。
誰都不是傻子，很快SRE帶來全新的、革命性的運維方式表面上讓運維這個行業變得光明起來，可背後涌動的“暗流”卻是我內心反覆錘問 —- “運維工程師可以轉型成SRE嗎？”，不要忘了，SRE的出生是研發工程師。
“我們常說要轉型，要做DevOps，要做SRE。可幾年來，你才發現，這只不過是一個騙局，真正需要轉型的是Dev，他們把Ops的活幹了，而Ops只能另謀出路，DevOps對Ops來說就是一個笑話。”
雖然我不完全同意我同事的這番言論，但至少他把我們心裏不願承認的，不願回答的問題給出了他的答案。
作爲一個運維老兵，也希望可以找到自己問題的答案，好在《Google SRE》一書的上市，全面且細緻的介紹了SRE工作，讓我可以近距離的瞭解和思考未來。
一、土壤：基礎設施
1.1 硬件故障
2010年，記得剛加入A雲的我，每週耗費一個工作日例行到機房處理各種硬件故障，那時候我們還只有一個數據中心，運行的服務器不過寥寥幾千臺，那時的我心裏有一個疑問：“以後怎麼辦？”，爲此後續的一年，我從事兩項相關的工作：
- 把維修自動化，主要是磁盤和內存的維修自動化，當廠商把損壞的硬件替換到服務器上之後，後面的維修動作就是一鍵觸發，自動修復並上線。
- 故障預判，其實說預判有些牽強，大部分的故障我們無法做到預判，多數情況是在小時級別後發現硬件故障。
這能在非線性的物理服務器增長中，讓同事從繁瑣的維修工作中解脫出來，但事實上，2部分的工作帶來很多的質疑：
“爲什麼機器/硬盤Hang住了，你的檢測程序卻無動於衷？”
質疑多了不同的團隊自己就要掄開膀子自己幹，造成了一些不必要的PK，這些PK漸漸的讓這些相關團隊認識到硬件是不可靠的，而不是天真的認爲“一切硬件故障可以被甄別，並可以快速隔離”。重複造了輪子，明白了一個道理。
可我並沒有在《SRE》一書中找到SRE是否經歷這樣的階段，因爲一書中提到和硬件相關內容甚少，不過在相關資料《The DataCenter As a Computer》中，能找到類似的經歷。
文章的作者之一，Jimmy Clidaras，他從04年開始從事Google Datacenter Engineering的工作，是第一個Senior Director of Google’s Platforms Infrastructure Engineering Team。
文章提到了非常有趣觀點—-爲了提到維修的效率，以下兩項工作非常關鍵：
- “每天打掃一次”數據中心裏需要維修的硬件。（而非時刻都在）
- 需要一份精確的硬件損壞和分析報告，報告來自 Google System Health
最後，他同樣提到應對的觀點：(N+?理論，該論點也反覆在SRE一書中提到)
TOLERATING FAULTS, NOT HIDING THEM.
Google System Health
我可以得出這樣的結論，Google的基礎設施團隊，他們做了大量的工作（包括科研性的工作），這一切SRE團隊並非參與者，而是“維護者”，甚至是“享用者”。（理想情況下，他們不需要再關心硬件故障或者之類，但我相信現實情況下，他們對硬件故障也耳熟能詳了。）
幸運的是（還是不幸？：）），硬件故障等問題經驗至今仍然是A雲SRE值得“分享”的一大類目。
A SRE 1:0 G SRE
1.2 硬件選型
Google的信條是：
並不會用專門的物理服務器運行專門的軟件服務器
所以，G SRE不會碰到硬件選型的煩惱。所以他們不會碰到如以下的對話：
< A TL >: “混合存儲是什麼機型？啊？爲什麼是X塊SSD硬盤呢？我的業務場景需要Y塊！” < A SRE >:”B、C等其他業務都統一了，爲了節省採購成本，請做應用的優化來適配這一款混合存儲機型。”
A SRE他們有足夠的話語權。這並不是說他們可以自主研發某一款機型，他們的背後還有基礎系統研發團隊，通常基礎研發團隊會拿出多款搭配的試驗機型供SRE來決策。一方面A SRE在這些機型之上“折中”出四不象來，看起來讓每個業務都不餓，但也都喂不飽。另一方面，A SRE開始遊說業務研發的Leader們開始做應用改造和適配，否則就會面臨到貨週期、財務等一系列的挑戰。
因爲沒有一個統一的資源調度系統（說起來很輕鬆），業務還是天然的區分了幾種不同類型的物理服務器：
機型 | 業務場景 |
|---|---|
A | CPU、MEM密集型、少量存儲 |
B | CPU密集型、大量存儲 |
C | CPU密集型、磁盤響應延遲低 |
每年A SRE（包括基礎系統、網絡團隊）因此需要做物理服務器在數據中心之間繁重的搬遷工作。
同時，針對機型的定製化改造也變得臃腫不堪，爲了對機型做某些妥協的業務通過RAID，軟RAID的方式來最小化他們應用的改造成本，而這些行爲都被記錄在A SRE提供的“應用模板”之中，它是系統裝機之後必須經過的步驟，以確保機型被正確的配置了。
機型規劃、有效縮減是A SRE必備的課題，由於缺乏長期看得見的舉措，A SRE用短期“自動化”的手段補位，相信這也是A SRE值得分享的心路歷程。
A SRE 2:0 G SRE
1.3 基礎軟件系統
1.3.1 Borg
Borg並不是SRE團隊研發的產品，無論是資料還是John Wilkes 15年的分享（其實我早知道:)）。可爲什麼每次提起Brog，就會讓人聯想到G SRE? 就像每次提及雙11，就會讓人聯想到阿里巴巴技術保障部。我覺得這種錯覺是相似的 —- 當你既是這款產品的使用者，又是這款產品的維護者，那你最適合做這款產品的代言人。
Borg讓G SRE進化，G SRE讓Borg進化。看看書中G SRE進化的例子吧
最初的自動化包括簡單的Python腳本，執行如下的操作。
- 服務管理：保障服務運行（例如，在段錯誤後重新啓動） —- borg
- 跟蹤 那些服務應該運行在那些機器上。 —- Borg
- 日誌消息解析：SSH進入每一臺機器，用正則表達式過濾日誌。 —- gRPC。
我做了標註部分，書中是這樣解釋的。
“最初的自動化努力給我們爭取了足夠的時間，把集羣管理轉化爲自治系統，而不是自動化系統。” “機器的損壞和生命週期的管理已經不需要任何操作了。成千上萬的機器加入系統，或者出現問題，被修復，這一切都不需要SRE的任何操作。”
很有意思，G SRE並沒有覺得自己曾經的工作被替代（更別提被“別人”拯救）我想唯一的可能是G SRE有極大的參與感和主導權。
A SRE在地球的另一端，仍用着“最初的自動化腳本”執行着去完成那些操作。宣稱不久將“替代”A SRE這些腳本的DevOps團隊，從1.0演進到2.0再到現在3.0，多年來風風雨雨，你來我往，既沒有兌現當年的承諾，也沒有留下“戰友”般的友誼。幹活累的時候，相互噴一嘴解解乏。
A SRE 2:1 G SRE
1.3.2 BorgMon
A SRE 2:2 G SRE
1.3.3 Jupiter&BwE
Google Jupiter和BwE(帶寬控制器)，實現了一個巨大的可供管理的虛擬網絡，在一個數據中心裏，幾百臺自研的交換機以Clos方式連接爲一體，擁有幾W個虛擬端口，提供1.3Pb/s交叉帶寬。
網絡也並不由A SRE直接維護，但A SRE在數據中心網絡問題的排查中往往會起到決定性的作用，而相比較G SRE的BwE，A SRE更有辦法能夠找那個“壞小子”應用，人肉充當帶寬控制器的角色，當然前提是時間允許的情況下。
A SRE 2:3 G SRE
1.3.4 存儲系統
D Service
A雲的存儲系統和G司類似，除了D服務。A雲並沒有D服務，底層磁盤是直接由分佈式文件系統盤古直接管理，在盤古之上也衍生出很多數據庫服務，如MaxCompute、OTS、OSS等。
或許沒有D服務，盤古僅能按照集羣來管理不同類型的磁盤，還無法做到數據中心級別。
A SRE 2.5:4 G SRE
1.3.5 分佈式鎖服務
和存儲類似，相比較可以提供多個數據中心服務的Chubby，A雲的分佈式鎖服務僅能按照集羣級別管理。
A SRE 3:5 G SRE
1.3.6 GSLB
A SRE 3:6 G SRE
1.3.7 結束
我相信G SRE的成功之一源於G基礎軟件服務成功，正如蒸汽火車和磁懸浮列車最高時速的差距並不在於“司機”的操作技巧。
二、能力：SRE研發的產品
本節只能依據書中明確提到由SRE團隊研發產品來橫向的比較。書中提到大部分Google內部幕後的軟件工程實踐都是來自SRE部門，而此類現象在A雲並不多見，相反，在A雲多數源於SRE部門的idea，而往往實踐落到了研發部門，我們稱之爲“收編”。
2.1 Auxon
容量規劃是兩個SRE都要直面的問題，而且兩者都意識到了傳統容量規劃的方法帶來的巨大開銷和不確定性。
G SRE和技術項目經理研發了Auxon，一款基於“意圖”的容量規劃工具。A SRE雖然表現上已經告別了表格的方式，但容量規劃的系統是財務主導，由研發團隊支撐，和SRE並沒有太大的關係。而A SRE更多的專注在研發如何“高效”的提供讓人信服的業務數據和趨勢分析的平臺。
從書上可以瞭解到，G司擁有不止一套容量規劃的模型和工具，用於滿足數據樣本和規劃模型之間的差異化，G SRE也意識到Auxon也無法滿足所有項目。但書中沒有提到的是大型分佈式系統的容量規劃，這背後不是簡單一個或幾個技術指標的分析與運算，容量規劃背後那些KPI的目標，不同部門相互交織，視角和理解數據的方式完全不同，A SRE要面臨的挑戰或許要大的多。
A SRE 0:1 G SRE
2.2 Layer-3 Load Balancer
對於這款產品，書中提及的篇幅不多，我翻閱了一下參考資料《Maglev: A Fast and Reliable Software Network Load Balancer》，文章的作者大多數來是Google的資深軟件研發工程師。
G SRE源自對網站的可靠性維護，自然的對負載均衡器有非常深的理解，從19、20章的描述可以感受到LB是那種根植於SRE技能條裏必備技能。根據我個人的以往工作經歷，曾經幾乎一整年的工作就是和商業負載均衡器打交道，反而到了A雲接觸的少了。
A SRE 0:2 G SRE
2.3 Sisyphus
Tesla
通用的自動化發佈框架,和G SRE類似的，A SRE團隊已經實現了支持自動化發佈的複雜部署、升級流程，這個平臺叫Tesla。同時，它也具備負責記錄每個步驟執行過程和異常通知，提供Python擴展包，唯一讓我覺得遺憾的是，Sisyphus和構建工具打通，做到代碼構建到上線快速發佈。我相信任何的線上發佈除了系統之間互通之外，也需要研發團隊、發佈團隊和SRE團隊之間的互通。而Tesla目前雖然還未和構建平臺有任何的交互，但在團隊直接的協同通知上，已經研發出了一套面向工程師的“發佈申請流程”。
Tesla平臺已經在內部運行了幾年，是由A SRE主導研發的智能運維平臺，除了自動化發佈框架，它還整合了其他很多SRE主導研發的產品。
A SRE 1:3 G SRE
2.4 其他
Google Cron&Google WorkFlow，書中有專門的章節提及，但並未直言這兩個產品是由SRE團隊研發，我想列出來的原因是本是大型分佈式系統應該依賴的基礎軟件，G SRE可以明白的闡述其軟件設計思路和實現，而A雲，早在幾年前也有類似的產品服務整個數據中心，但由於組織架構的調整，這些服務慢慢的變成“無人區”，更別提有業務應用敢使用，作爲A SRE的一員，未免令人唏噓不已。
A SRE 1:4 G SRE
三、思想：方法論
3.1 培訓新人
很不幸，我不得不承認A SRE團隊目前就是這種“浴火重生”的學習方式，幸運的話，有能力的工程師最後能夠從這種大坑裏爬出來（所以我們招人異常困難），但更常見的是，多數有能力的工程師都無法在這種環境裏成長。我們意識的問題的現狀，卻仍然沒有騰出手來改變。
雖然說，我們的初衷和G SRE相同，培養工程師個人的能力，與其讓他們傳授知識，不如自己動手（感覺我有點厚顏無恥），可與G SRE 提供明確的系統性培訓目標以及不同領域的SRE專家和研發聯繫人不同是，A SRE知識體系仍然在口口相傳。
相比較G SRE在生產系統做故障演練和破壞性學習，大多數A SRE會從測試環境成長起來，測試環境的配置問題和軟件標準化遠遠比生產環境糟糕的多，雖然A SRE可以在測試環境做一些破壞性的試驗加深對系統的理解，但相比較生產系統，這可以說是完全不同的世界。
缺少有效的事後總結和文檔能力，A SRE每週的不定期的知識技能分享也面臨無法維繼的風險。
A SRE 0:1 G SRE
3.2 接手一項服務/產品
在A雲只有部分服務是一開始就是SRE負責運維的。但和G SRE不同的是，A SRE開始剛接手服務/產品往往都是一個“爛攤子”。
爲了提高該服務的可靠性，A SRE往往會參與產品的設計和下個迭代版本的構建：
- 系統的結構體系，從下自上的高可用優化方案。
- 監控，提供更加豐富和標準的監控接口。（很多產品接手時，沒有任何監控，研發團隊甚至不清楚有什麼監控平臺。）
- 選擇指標，度量服務可用性的關鍵指標。
- 緊急事件的處理機制和升級路線。
- 服務日誌分析。
- 通過Tesla的平臺擴展產品自我快速迭代的能力。
並且往往在A SRE還未完全驗收好相關改進和方案，產品就要開門“接客”了。
- 文檔，A SRE決定了一個產品運維文檔的撰寫能力
- 諮詢，“飛機”已經起飛，始料未及的“Bug”需要研發團隊和A SRE在線找到辦法修復/臨時繞過，等待下一個迭代版本。（在這裏，原本應該提供的運維改進版本又Delay了。）
A SRE周圍充滿了人情和感性，業務產品那個不是從水深火熱之中爬出來，而我們又如何能夠袖手旁觀呢？
G SRE PRR模型是非常值得借鑑的一種接管服務的方式，G SRE的這套方法論更堅定了A SRE的未來改進的方向。
A SRE 1:2 G SRE
3.3 團隊構成
G SRE | A SRE |
|---|---|
/ | 傳統Ops |
Tech Lead | Tech Lead |
SRM | Tech Lead |
PM/TPM | / |
/ | PD |
/ | 數據分析/運營 |
SRE團隊構成多樣化，有些成員喜歡責任職責被明確的定義（僅作研發效率相關的工作），據此可以迅速安全的做出範圍內的決策，另一些成員在一個更爲動態的環境中工作，隨時切換責任。
A SRE相比G SRE是一個更爲動態的團隊，團隊內部比較來說，只有數據分析/運營的職責（技能）的SRE技能切換不太頻繁。
A SRE技術負責人承擔了不僅負責團隊技術方向，還有績效管理和橫向團隊協作等（其他一切其他人不能處理的事情），所剩的工作時間很少能夠review團隊成員的代碼，更多方通過在團隊中推進共識的建立來引領團隊。
A SRE 2:3 G SRE
四、結束語
通讀《SRE》全書，不禁讚歎！
No | A SRE | G SRE |
|---|---|---|
SRE的土壤 | 3 | 6 |
SRE的能力 | 1 | 4 |
SRE的思想 | 2 | 3 |
一千個人眼中有一千個哈姆雷特，在意識到差距的同時更不必妄自菲薄，更重要的是思考這些差距的所欠缺是努力還是思想，是再次驅動我翻開這本書細細再品的動力。
更讓我收穫的是，書中那些活生生的案例。
- 一項不穩定的服務，Bigtable穩定性造成報警過多，降低SLO減少報警，重點提升Bigtable的軟件性能。
- Gmail的手工干預哲學：是短期麻木於SRE的提供的工具減少影響還是長期找到根因，並解決。
- 遷移Mysql到Brog，Brog不是萬能，至少離開SRE在業務上做的優化，這項工作無法得以完成。
這些案例書中有的給出的答案，有的沒有，給我最大的幾點共鳴
- “世界上沒有捷徑”，我們經歷着的也是G SRE經歷過的。
- 沒有一種答案可以解決所有問題，試圖回答文章之初的問題變得可笑，SRE是一個積累的命題，尋找總開關想一勞永逸註定是徒勞無益。
- 只有非比尋常的努力，才配的上不尋常的Idea。