DevOps案例研究：庖丁解牛，剖析Google持续交付之道
內容來源：DevOps案例深度研究 –Google持續交付實踐戰隊（本文只展示部分PPT及研究成果，更多細節請關注案例分享會，及本公眾號。）
本案例內容貢獻者：姚元慶 (Topic Leader) 、任躍兵、王紅陽、王曉敏、張彪
本次案例解讀：許舟平
解讀者說：作為起源于硅谷的跨國科技公司，谷歌的業務涵蓋互聯網搜索、廣告、云計算、AI等眾多領域，開發并運營了大量基于互聯網的產品與服務。本文將從谷歌的價值觀、發展歷程、企業文化、持續交付工程實踐、SRE團隊等多個方面來剖析谷歌獨特的持續交付之道。
（注：Google，中文稱谷歌，本文會混用google與谷歌的名稱）
引子
To organize the world's information and make it universally accessible and useful (整合全球信息，供大眾使用，使人人受益)
—Google Slogan
由拉里·佩奇和謝爾蓋·布林于1998年9月4日成立的Google，被公認為全球最大的搜索引擎公司，其主域名google.com是全世界訪問量最高的網站。
Google不僅提供其核心的網絡搜索業務，還在全世界提供豐富的線上服務，如Gmail電子郵件、Google Map、Google Calendar、YouTube等。
Google的產品同時也以應用軟件的形式進入用戶桌面，例如Google Chrome網頁瀏覽器、Picasa圖片整理與編輯軟件、Google Hangouts即時通訊工具等。
另外，Google還開發了用于移動設備的Android操作系統以及Google Chrome OS操作系統。
相比于“整合全球信息，供大眾使用，使人人受益”的官方Slogan，Google的非正式口號“Don't be evil”（不作惡）更是廣為流傳。
為了支持如此眾多的線上業務，Google在分布于全世界的數據中心內運營著上百萬臺服務器，每天處理數以億計的各種請求。谷歌是如何做到7*24支持業務上線部署和系統持續交付的呢？讓我們在本次DevOps案例研究中一探究竟。
Google的發展歷程
Google的發展概況
1996年1月，加州斯坦福大學的兩位博士生——拉里·佩奇和謝爾蓋·布林開始研究一項區別于傳統搜索“根據關鍵字在頁面中出現次數來進行結果排序”的方法，兩人開發了一個對網站之間的關系做精確分析的搜尋引擎。
1997年9月15日，拉里·佩奇和謝爾蓋·布林兩人注冊了Google域名。
1998年9月4日，在加州門洛帕克的一間車庫里，佩奇和布林創建了Google，克雷格·西爾弗斯坦（Craig Silverstein）成為公司的首位雇員。
2004年7月13日，Google收購照片整理與編輯軟件Picasa，同年10月又吞并了Keyhole公司。一年后，Google將Keyhole公司的Earth Viewer服務改名為Google地球。
2004年8月19日，Google完成首次公開募股，當初總股本27182萬股（2.718281828和數學常數e有關，常數e又被稱為歐拉數，為自然對數函數的底數，值約為2.71828）。
2005年，成立僅22個月的高科技企業Android被Google收購，成為Google麾下的移動設備操作系統。
2010年3月23日，谷歌宣布關閉在中國大陸市場的搜索服務，保留研發和市場團隊。
2011年5月，Google的月獨立訪客數量首次超過十億，與一年前同期的9億3100萬相比增長8.4%，成為全世界首個獲取該數據里程碑的網站。
2015年8月10日，Google宣布對企業架構進行調整，并創辦了一家名為Alphabet的控股公司，Google成為Alphabet旗下子公司。
Google的企業文化
不同的視角，不同的認識:
對于用戶來說，Google是一家有品質的互聯網企業。
對于硅谷的技術人員來說，Google是一個創新天堂。
對于華爾街來說，Google是一家有別于傳統的另類企業。
而對于Google員工來說，自由暢快的企業文化造就了它無窮的創造力，在這里，工作就是一種生活。
以用戶利益為準則
Google堅持為客戶帶來更多的體驗，因此建立了很多網上服務，而且它的搜索操作簡單實用，廣告跟正常搜索結果明顯分開。
不作惡也能盈利
Google不會因為任何原因操縱搜索排名位置，以滿足付了大量資金的合作伙伴排在搜索結果前列的要求。制定執行“不作惡”的標準，就是要避免做任何損傷谷歌用戶使用體驗的事情，“哪怕是以犧牲公司的收入為代價”，如不做煙草廣告以及烈性酒廣告。
行善的Google
Google基于“不作惡”原則對廣告商挑三揀四，但卻給兩百多家健康衛生、教育和非政府組織做免費廣告。
人才觀：讓員工很快樂
1）給員工20%的自由支配時間
Google給每位工程師20%的自由時間用來做自己感興趣的項目。這表現出公司對員工個人的極大信任，員工對自己工作時間的分配擁有了更大的自由裁量權。這樣的20%不是一刀切的，員工可以自己衡量當前工作進度，然后決定要不要將20%的個人時間用到自身項目上。
興趣驅動的工作中，員工可以獲得愉悅和滿足感，從而釋放創造力，許多員工為了這樣的項目甘心額外付出時間和精力。基于這種方式，Google員工的自我管理水平不斷提高，既能夠保障完成公司所分配布置的工作，又能夠不斷推出新創意，這也是Google眾多重磅產品的來源。
2）創新無處不在
在Google的企業文化中，工作可以和生活一樣是輕松歡愉的，這種舒適感可以賦予員工充分的創造力。每個員工的辦公區都各具特色，員工在上班前會得到一筆資金用來裝扮自己的辦公區。除了需要保密的項目或者部門，公司內極少有單人辦公室或封閉式辦公室，不同員工在開放的工作區域上保持親近，方便隨時溝通。
Google為每位員工配備了筆記本電腦，供他們隨時隨地進行編程、收發郵件或記錄突如其來的靈感。公司設有各種風味的餐廳，各樓層的茶水間擺放了各種零食和飲料。員工如果不喜歡被分派到的項目工作，他可以申請轉換項目。另外，在Google從事非技術工作的員工也會得到同樣的尊敬和重視。
3）避免惟命是從，自由的最大化
在Google的管理層中管理者不存在對下屬的絕對支配權力，難以做出是否雇傭、是否解雇、是否重用及加薪等決策。在Google，管理者沒有直接的決定權，決定權賦予獨立的委員會或小組，這樣的委員會或者小組可以是臨時任命的，能夠保證其獨立性和客觀性，確保作出的決策能夠有利于公司的長遠利益，而不是屈從于某一管理者的個人意志。
在Google的企業文化中，堅信每個員工都是好的，員工會為個人利益和公司利益而奮斗，這樣的主人翁意識決定了員工不是機器，而是企業進步的最大推動力。
4）不懼失敗
在現代企業經營中，企業對失敗的承受力大大降低，一次簡單的失誤就能使一家大型企業在激烈的市場競爭中歸于破產。不同于其他企業，Google的企業文化中表現出對失敗的極大包容性，允許員工在不斷嘗試中失誤，認同失誤的價值，認為其中蘊含了成功的機會。在Google的眾多項目中，對失敗的包容，往往促成了更好的創新，許多成功的項目得以脫穎而出。這也正是Google公司強大創新力的重要來源，員工的失敗不會簡單地歸于個人的失職，而是作為有意義的經歷，失誤的經驗教訓被吸取，眾多的失誤中蘊含著成功的機遇。
Google持續交付的工程實踐
谷歌產品研發及運維團隊的角色組成：
Engineering Manager
Software Engineer(SWE)
Research Scientist
Site Reliabilty Engineer(SRE)
Product Manager
Program Manager /Technical Program Manager
Google Site Reliability Engineer實踐
作為谷歌DevOps實踐中具有代表性的SRE，其工作的主要職責不僅僅是從事Operation方面的工作，更多是保障整個Google服務的穩定性，包括但不限于：
1）確保長期關注研發工作
Google將SRE團隊的運維工作限制在50%以下，SRE團隊應該將剩余時間花在研發項目上。在實踐中，SRE管理人員應該經常度量團隊成員的時間配比，如果有必要的話，可以采取一些暫時性措施將過多的運維壓力轉移回開發團隊處理。
例如，將生產環境中發現的Bug和產生的工單轉給研發管理人員去分配，將開發團隊成員加入到輪值on-call體系中共同承擔輪值壓力等。這些暫時性措施應該一直持續到運維團隊的運維工作壓力降低到50%以下。在DevOps實踐中，這種措施實際形成了一個良性循環，激勵研發團隊設計、構建出不需要人工干預、可以自主運行的系統。
2）在保障服務等級目標 SLO (Service Level Objective) 的前提下，最大化迭代速度。
產品研發部門和SRE之間可以通過消除組織架構沖突來構建良好的合作關系。在企業中，最主要的矛盾就是迭代創新的速度與產品穩定程度之間的矛盾。
3）監控
監控系統是SRE團隊監控服務質量和可用性的一個主要手段。在Google有一個規則：沒有不需要采取行動的警報。如果你遇到一個自己認為不需要執行操作的警報，你需要采用自動化的手段來修復該警報，監控不做任何事情在Google是不會存在的。一般來說，Google的SRE監控系統會有三種有效的監控輸出：警報、工單、日志。
4）緊急事件處理
可靠性是MTTF（平均失敗時間）和MTTR（平均恢復時間）的結合結果。評價一個團隊將系統恢復到正常情況的最有效指標，就是MTTR。
5）變更管理
大概70%的生產事故由某種部署的變更而觸發。變更管理的最佳實踐可使用自動化來完成以下幾個項目：采用漸進式發布機制；迅速而準確地檢測到問題的發生；當出現問題時，安全迅速地回退改動。
6）需求預測和容量規劃
需求預測和容量規劃簡單來說就是保障一個業務有足夠的容量和冗余度去服務預測中的未來需求。
7）配置
資源的部署與配置是變更管理與容量規劃的結合物。如何自動化地實現資源部署和資源調度，是SRE需要考慮的內容。
8）效率和性能
高效地利用各種資源是任何營利性服務都要關心的，因此SRE必須也承擔起任何有關利用率的討論及改進，確保在高可靠性、快速迭代的情況下效率和性能提升。
在日常工作中，當SRE需要接手某個服務前，對server的性能和穩定性都有一定的要求，比如server出現報警的次數不能超過一定的頻率，server對CPU、內存的消耗不能超過預設的指標。只有server完全滿足SRE的要求以后，SRE才會接手這個server。
當server出現問題時，SRE會先緊急修復，恢復服務，然后SRE會和SWE溝通，最終SWE來徹底修復server的bug。同時，對server的重大更新，SWE都要提前通知SRE，做好各種準備工作，才能發布新的版本。
為了能讓SRE能接手server，SWE要根據SRE的要求對server做大量的調優。首先SRE會給出各種性能指標，比如服務響應延遲、資源使用量等等；其次SRE會要求SWE給出一些server評測結果，諸如壓力測試結果、端到端測試結果等等；同時，SRE也會幫助SWE做一些性能問題排查。
基于Google Cloud Platform的持續集成與持續交付工具
與AWS、Azure、阿里云等其他云服務商不同，谷歌云的起家是從PaaS開始，Google App Engine在2008年4月發布第一個測試版本，用戶只需使用GAE提供的資源就可以開發自己的應用程序或網站，并且可以方便地托管到Google來進行運維。后來，谷歌才逐步增加和豐富了谷歌云的IaaS服務能力，在2012年6月28日的Google I/O大會上提供Google Compute Engine的預覽版，這自然使得GCP的特性和功能受到了廣大開發人員的歡迎，特別是那些希望使用DevOps工具和開源方案的開發者。
許多中小型創業公司被Google的創新性和開放性所吸引，從而使用GCP。依照獨立IT研究與咨詢服務公司Gartner的說法：
Google對于那些云原生和想要‘如Google一樣運行’的公司最具吸引力。
對于云原生和容器，Google通過開源自身的容器管理平臺Kubernetes，以及對云原生開源社區進行的技術輸出，使得GCP在云原生、微服務和DevOps上的能力持續加強，可以幫助GCP的使用者專注于應用開發、大數據分析和機器學習等應用領域。
2018年，Google更是推出了一款全新的持續集成和持續交付（CI/CD）工具 - Google Cloud Build。
谷歌對Google Cloud Build的定位是：“全面管理的持續集成與持續交付平臺，能用來快速且大規模構建、測試和部署軟件。”因此，Google Cloud Build可應用于各種架構，如虛擬機、無服務器（Serverless）、Kubernetes或者Firebase架構。
Google Cloud Build的用戶可以使用觸發程序來部署應用，當達到一定條件，可以自動觸發更新，另外也有本地部署跟云端部署兩種方式供選擇。Google Cloud Build可幫助使用者跨語言構建項目，通過和類似GitHub等配置管理工具的集成，可以在Google Cloud Build中設置持續構建流水線，自動執行構建和測試工作。
如果Google Cloud Build發現持續集成中出現問題，可以提供分析和建議，用戶還可以通過歷史錯誤、警告和過濾器來識別將阻礙程序構建與部署的問題。
另外，在監控方面，Google Cloud Monitoring服務提供從Google App Engine、Compute Engine以及Cloud SQL收集的數據來對運行的應用性能、容量和正常運行狀態進行監控。
小結
尼采說過：“你有你的路。我有我的路。至于適當的路、正確的路和唯一的路，這樣的路并不存在。”對于每一位DevOps實踐者而言，走自己的路才會達到自己想要去的那個地方。更為重要的是，一定要擁有追隨自己內心與直覺的勇氣，你可以在DevOps案例深度研究的團隊里，勇敢踏出DevOps實踐的第一步。
參考資料
Fergus Henderson，“Software Engineering at Google”， Jan 2017
Rachel Potvin and Josh Levenberg,“Why Google Stores Billions of Lines of Code in a Single Repository”, July 2016
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy編著，孫宇聰 譯《SRE: Google 運維解密》
案例研究者
拓展閱讀：DevOps案例研究：知人善任——Google敏捷核心文化
DevOps案例研究：進取到讓自己毛骨悚然，Netflix公司的簡介和文化
DevOps案例研究|史上最能“拜客戶教”的公司，是如何做到持續交付的？（第1趴）
DevOps黑客馬拉松?
9月7-8日 北京
專業大咖陪你一起進化
歡迎企業組隊PK，企業團隊報名有特惠
目前已經有兩家企業組隊！！
趕緊報名吧~??????
總結
以上是生活随笔為你收集整理的DevOps案例研究：庖丁解牛，剖析Google持续交付之道的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 云考古 | Azure 自建 RDS 让
- 下一篇： 架构杂谈《八》Docker 架构