# Google 如何針對行星級基礎設施進行行星級工程設計？ > 原文： [http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html](http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html)  Google 如何保持其所有服務正常運行？ 他們似乎從來沒有失敗過。 如果您想知道我們在 [GCP NEXT 2016](https://cloudplatformonline.com/next2016-schedule.html) 上發表的演講中的精彩幕后花絮， [Melissa Binde](https://www.linkedin.com/in/mbinde) ，Google Storage SRE 總監： [Google 如何針對行星級基礎架構](https://www.youtube.com/watch?v=H4vMcD7zKM0)進行行星級工程。 梅利莎（Melissa）的講話很簡短，但充滿智慧，而且以一種胡說八道的方式表達出來，使您認為服務是否失敗梅利莎（Melissa）絕對是您想要的那種人。 哦，什么是 SRE？ 它代表*站點可靠性工程*，但定義更難以理解。 就像您要求道的定義時得到的答案一樣。 正如 Google 的本·斯洛斯（Ben Sloss）24x7 副總裁所明確指出的那樣，這不僅僅是一個過程，更是一個過程，他將 SRE 定義為： > 當軟件工程師承擔了過去稱為操作的任務時會發生什么。 讓它在您的頭部反彈一會兒。 最重要的是，有一件事很清楚：SRE 是生產的保管人。 SRE 是 google.com 和 GCP 的客戶體驗的托管人。 對我來說，一些演講重點： * **點檢正常運行時間的破壞性激勵與功能**相比。 SRE 試圖解決想要推送功能的開發人員與想要通過不推送功能來維持正常運行時間的系統管理員之間的天然緊張關系。 * **錯誤預算**。 這就是預期會失敗的想法。 這不是一件壞事。 用戶無法確定服務的運行時間是 100％還是 99.99％，因此您可能會出錯。 這減少了開發人員和運營人員之間的緊張關系。 只要維持錯誤預算，您就可以推出新功能，而運營方也不會受到指責。 * **目標是立即恢復服務。 故障排除將在稍后進行。** 這意味著在恢復服務后，您需要大量日志記錄和工具來進行調試。 由于某種原因，這使[較早的文章](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html)上的內容閃爍了起來，同樣基于 Google SRE 的講話：*備份無用。 這是您關心的*還原。 * **沒有無聊的分頁哲學**。 當頁面進入時，應該是一個有趣的新問題。 您不希望無聊的 SRE 處理重復性問題。 這就是機器人的目的。 演講中其他有趣的話題是：SRE 的組織結構如何？ 如何聘請開發人員擔任側重于生產的角色并使他們滿意？ 我們如何保持團隊在 Google 內部的價值？ 我們如何幫助我們的團隊更好地溝通并解決與數據而非斷言或權力奪取的分歧？ 讓我們繼續吧。 以下是 Google 如何針對行星級基礎設施進行行星級工程... ## 保持平衡：點檢正常運行時間的破壞性動機與功能 * 系統管理員會在站點正常運行時獲得 Cookie 的正常運行時間。 當網站停滯不前時，我們會吸引訪問者，訪問者會給我們錢。 * 開發人員會獲得功能的 Cookie。 發布一個新功能，訪問者來了，他們給了我們錢。 * 生產凍結，也就是新功能的凍結，通常映射為增加正常運行時間。 * 開發人員和系統管理員之間存在天生的緊張關系。 開發人員會獲得發布功能的 Cookie。 系統管理員會獲取 Cookie 以確保正常運行時間。 * 因此，系統管理員因阻止新功能發布而獲得獎勵。 如果開發人員能夠解決系統管理員的問題，他們將獲得獎勵。 * 開發人員進行他們所謂的 Beta 測試是為了盡快發布功能。 * 系統管理員執行他們所謂的啟動審核，以減慢新功能。 * 您的團隊將所有的時間都花在彼此抗爭上，因此您會增加停機次數，風險，混亂和無政府狀態。 * 您想要的是消除異想天開的命令。 請按規則處理，以便團隊可以有目標并共同努力。 * 與 devops 一樣，有一種方法可以使開發人員和操作人員一起工作。 問題是，devops 無論走到哪里都有不同的含義。 相反，SRE（站點可靠性工程）定義明確。 * **SRE：** **當您要求軟件工程師設計和運行操作時會發生什么情況**-Ben Sloss 24x7 VP，Google * 軟件工程師-事實證明，當知道軟件的人也運行服務時，服務可以更好地運行。 他們對什么使它打勾有深刻的理解。 * 設計和運行-實際上是設計您的生產環境，而不是讓它成為意外的事故。 * 假設有 1000 個 SRE 在 Google 的基礎架構上工作：網絡，計算，存儲等。有多少個 SRE 負責云計算？ * 所有。 * google.com 和 GCP（HTG1）的運行之間沒有界限。 不需要讓云團隊和內部團隊進行溝通的開銷。 他們創造了一種環境，可以幫助所有人協同工作。 ## 技能：SRE 是一個印章團隊和圣職 * 本節的標題是我的描述。 具有技能的 SRE 必須是精英。 在工作方面，他們僅致力于這種幾乎準神秘的事物，稱為生產。 * SRE 必須比開發人員更熟練，才能完成相同的工作： * 他們需要更大的技能范圍。 * 所有 SRE 必須通過完整的軟件開發人員面試才能被錄用。 * 所有 SRE 必須通過一次非抽象的大型系統設計采訪。 * SRE 必須具有相同的軟件技能，這是不同的應用領域。 * 開發人員專心于產品經理并制作功能。 * SRE 依賴于生產，以使生產達到最佳狀態。 * **當將面向開發和面向生產的觀點結合在一起時，最終的設計會更強大**。 * 入職流程示例給出了 SRE 帶來的一個示例，該過程在將團隊的項目置于 SRE 的責任之下時發生。 在評估團隊的軟件時，他們發現： * 當達到規模時，它將在生產中失敗。 * 開發人員已隱式假定某種呼叫不會失敗。 * 他們假設請求的分配是均勻的。 * 他們以為不會受到用戶的關注。 * 他們假定所有請求的大小均處于平均水平。 * 他們在兩條尾巴上失敗了（沒有給出解釋）。 ## 組織：為開發人員提供不讓運營工作積聚的理由 * 該系統必須設計為不增加運營工作，因為如果開發人員不從事工作，他們將不會那么在意。 * **SRE** 的開發預算。 如果您的系統的運營開銷很大，那么您獲得的開發人員就不會那么多，那么您就無法推廣那么多的功能。 * SRE 具有完全不同的命令鏈。 他們有自己的副總裁，與開發副總裁分開。 這賦予了他們權力和權力。 當生產意味著他們需要拒絕時，它允許他們說不。 一堆不是的傳呼猴子。 * 當開發人員說他們可以捐贈人數時，SRE 不必接受。 SRE 可以說服務不夠重要，請自己繼續提供支持。 * SRE 是一種稀缺資源。 并非 Google 的每個團隊都有 SRE。 云確實可以，但是不是每個其他團隊，甚至不是云中的每個小服務，都只是重要的。 ## 環境：如何使開發人員在生產團隊中保持快樂？ * **至少有 50％的工作需要為項目工作**。 不待命。 不是門票。 不開會。 實際上是在做項目工作。 * 如果項目工作量過多，則開發人員會為 SRE 分配更多的人員，或者將額外的工作流轉給開發人員團隊。 * 什么是項目工作？ * 通過切換基礎數據庫技術來改善服務的延遲。 * 編寫自動化以加速部署。 * 跨服務的項目。 Google 作為一項內部服務，可以由其他服務（通常由軟件 bot）在內部進行查詢，如果可以安全地將計算機停機，可以安全地將機架停機或者將數據中心安全地停機，則可以返回 Google ？ * SRE 是一支志愿軍。 沒有草稿。 * 您可以隨時轉入另一個 SRE 團隊。 * 您可以隨時轉換為 dev。 * Mission Control 是一個程序，開發人員可以在其中試用 SRE 并查看他們是否喜歡它。 * 團隊很流暢。 人們來自團隊，分享經驗，分享觀點。 ## 預算：您可以支出任意預算的錯誤預算 * 如果您有 3 個 9 的可用性，目標是不將其提高到 4 個 9，那么您的錯誤預算為.1％。 * **如果您想更快地推出功能并使 GCP 變得更好，那就去做吧。 直到用盡錯誤預算。** * 如果您希望進行較差的測試，使軟件定期出現故障并且必須不斷回滾，那么您也可以選擇該選項，但是錯誤預算很快就會用光，并且您將無法啟動 。 * 錯誤預算按季度循環。 * 有一個逃生閥：三枚銀子彈。 * 一個開發人員可以說我真的需要推動，請給我一個銀彈。 * SRE 會說“ OK”，但您必須說服 VP 您實際需要推動。 * 這個儀式聽起來很愚蠢，但功能非常強大。 它將控制權交給開發人員。 他們有 3 個靈丹妙藥，由他們的副總裁來決定是否合適。 * 錯誤預算基于每個服務。 因此，如果多個開發團隊使用相同的服務，則它們共享相同的預算。 * SRE 不在交戰的開發團隊中間。 他們必須弄清楚如何花費錯誤預算。 * 機外。 如果所有其他方法都失敗了，并且開發人員和 SRE 確實不同意，則 SRE 可以派遣開發團隊。 * 像和睦的離婚。 * 這是至關重要的逃生閥門，因此團隊在很長一段時間內都不會出現令人討厭的分歧。 * 很少見，但確實發生了。 一個示例場景是，如果團隊不想在其 ACID 類型項目中使用 Spanner，如果開發團隊說他們想建立自己的團隊，那么 SRE 團隊可以說他們不想為團隊提供支持。 去建立自己的數據庫，因為這對生產不利。 * SRE 是 google.com 和 GCP 的生產托管人，SRE 是客戶體驗的托管人。 ## SRE 支持在頻譜上 * 聊天和咨詢。 與開發人員聊天。 進行白板會議。 * 協同設計。 與開發人員一起創建設計。 * 完全所有權。 完全擁有的服務。 所有容量，所有供應，所有頁面。 * 頁面是保持誠實的一種方式。 它們不是 SRE 的目的。 * 負責制作的人應該抓這些頁面，因為這樣可以使他們的皮膚保持游戲中的外觀。 * 它還有助于使 SRE 的技能，專長和觀點保持最新。 ## 是什么讓事情順利進行？ 文化和過程 * Google 會進行常規的培訓和通話陰影處理。 * Google 也有一個名為：**不幸輪盤**的過程-卷軸游戲。 * 一個人是地牢大師，他們有一個受害者，團隊輪流嘗試猜測發生了什么。 * Google 運行非常復雜的系統。 除了進行培訓的人之外，很少有人真正知道發生了什么以及答案是什么。 * 這對新的來電者很有用。 讓他們在受控環境中進行測試。 * 一些團隊在某些場景中會破壞生產并讓新手對其進行修復。 * 對退伍軍人也有好處。 最好重新整理您的知識，尤其是在使用非常復雜的系統時。 ## 事件管理 * 場景：您正在呼叫 gmail，并且您獲得了一張票證，用戶可以看到其他用戶的電子郵件。 你是做什么？ 關閉 gmail。 * **Oncallers 被完全授權采取一切措施來保護用戶，保護信息，保護 Google。** 如果這意味著要關閉 gmail 甚至關閉所有 google.com，那么作為 SRE，您的副總裁將為您提供支持，而您的 SVP 將為保護 Google 提供支持。 * **目標是立即恢復服務。 故障排除將在稍后進行。** * 有二進制狀態的記錄。 有日志。 * 醒著，開發人員在辦公室，所有人都在時，請進行故障排除。 目的是使服務重新啟動并運行。 ## 你該怪誰？ * 當“新開發者”推送代碼并破壞 google.com 達三個小時時，您應該對誰負責？ a）新開發者 b）代碼審查。 c）缺乏測試（或被忽略）的測試。 d）缺乏針對代碼的適當的金絲雀程序。 e）缺乏快速回滾工具。 * 除了新開發者以外的所有東西。 **如果新開發人員編寫的代碼會導致該網站癱瘓，那不是開發人員的錯。 這是開發人員和工作人員之間所有關口的錯。** * **絕對不允許人為錯誤傳播到人外。** 查看允許部署損壞的代碼的過程。 ## 無罪的崗位形態 * 避免責備文化至關重要。 * 研究表明，大多數事件是人為錯誤引起的。 * **最好通過了解實際發生的事件來解決事件。** 不知道發生了什么的最好方法？ 通過尋找責任人來揭開每一個事件。 * 人們真的很擅長隱藏，并確保沒有線索，并確保您實際上不知道發生了什么。 試圖怪罪只會使您的工作更加困難。 * 在 Google 誰搞砸了誰寫的事后驗尸。 這樣可以避免命名和遮擋。 使他們有能力糾正錯誤。 促成失敗的每個人都應盡可能誠實地參與進來，并寫下您如何陷入困境。 * 已在全體會議上給予拆除該站點的獎金，因為他們立即擁有該站點，因此他們擁有了該站點。 他們上了 IRC，并將其回滾。 他們說出來并如此迅速地照顧好他們，便獲得了獎金。 * 無賴并不意味著沒有名稱和細節。 這意味著我們不會因為事情出錯的原因而選擇別人。 不應發生諸如斷電之類的事情，應予以解雇。 * 深度防御 * 由于策略是縱深防御，因此事后評估模板將操作分為預防，檢測和緩解措施。 * **我們希望防止中斷，我們希望更快地檢測到它們，并希望減輕影響。** * 如果類似的情況再次發生，它將不會傳播到很遠，持續太久或影響那么多的客戶。 ## 分頁的無聊哲學 * 團隊喜歡看什么樣的頁面？ 新的和有趣的。 * 您知道如何解決的頁面很無聊。 您應該創建一個機器人來解決該問題。 * Google 發明了許多機器人。 他們不喜歡無聊。 * 如果您可以寫下修復它的步驟，那么您可能可以編寫自動化來修復它。 * 不要做機器人可以為您做的事情。 * 構建漫游器的結果是，理想情況下，每個頁面都是全新的，因此不會感到無聊。 甚至經驗豐富的工程師也可能在每次尋呼機關閉時都看到一些新內容。 * **這是哲學的根本變化。 如果一切正常，重復的事件很少，則意味著您在調試系統時不會像以前那樣沉迷于此。** ## 需要更強大的調試工具 * **如果所有問題都是新問題，則意味著您需要更強大的調試工具來查找問題。** * 文本日志不是調試工具。 如果您不知道要查找的內容，則無法在日志文件中查找模式的標準調試無法進行。 使用 GCP 大小的平臺，您需要瀏覽多少個外觀才能找到失敗的外觀？ * Google 嚴重依賴于各種可視化工具來解決不熟悉的問題并盡快恢復服務。 * 繪圖工具：石墨，InfluxDB + Grafana，OpenTSDB。 * 這些和其他提到的工具不是 Google 使用的工具，因此不建議使用，但它們是有用工具的開放源代碼示例。 * 很高興看到正在發生的一切。 Google 擁有數十億億個流程，因此您需要匯總視圖才能理解事物。 * **Google 在其二進制文件中放置了很多工具。** 在新情況下，您并不總是知道您要尋找的東西。 * 創建一個框架，使開發人員可以輕松地插入監視框架。 * 大量存儲空間專門用于存儲監視數據。 * **的想法是，您不想在中斷期間進行故障排除。 中斷僅與恢復服務有關。** * 故障排除是您稍后醒來時要執行的操作。 開發人員經常參與故障排除過程，因為他們對系統有更深入的了解。 * 歷史數據必須可用，以便故障恢復后可以進行故障排除。 恢復不會導致中斷監視數據丟失。 * 這種方法可以使停機時間盡可能短，同時可以在以后解決問題。 * 事件繪圖-對于關聯事件非常有用。 * 充分利用人類的模式匹配能力，很難編寫機器人來做到這一點。 * 給出了一個圖表示例，其中每行是一個數據中心，列是時間，單元格中的顏色是事件類型。 * 這可以幫助您找到不是單個事件的模式，例如導致級聯故障的軟件推出，或者一起重復出現的錯誤簇，或者如果您看到延遲尖峰之后立即出現錯誤尖峰 重復一遍。 這些都將有助于確定問題的根本原因。 * 可視化過程跟蹤-有時您需要深入到過程級別以識別性能問題。 * 開源選項不多：Performance Co-Pilot + vector。 * Google 有一個非常復雜的框架，可將示例查詢拉入存儲并提供完整的跟蹤記錄。 * 可視化工具的優點是很難理解時間戳。 可視化工具使您可以更輕松地折疊，展開和比較事件。 * 網絡流量和容量 * 開源選項：仙人掌，天文臺和 Nagios * 事實證明，很多存儲緩慢的問題實際上是網絡問題。 * 如果您正在查看存儲系統，但無法弄清為什么它對網絡的訪問速度很慢。 * 您需要一個工具來快速查看網絡狀態。 哪些鏈接超載？ 您看到多少個包錯誤？ 鏈接斷開了嗎？ * 日志文件-當所有其他失敗時 * 開源：ElasticSearch + Logstash（+ Kibana） * 您不想遍歷日志文件。 您需要一個具有更多類似查詢的 SQL 的系統，以便您可以挖掘日志。 * 日志應易于使用且易于理解。 ## Stackdriver 錯誤報告 * 如果您想看看 SRE 所擁有的那種工具的例子，那么請看 [Google Stackdriver 錯誤報告](https://cloud.google.com/error-reporting/) 。 * 這是他們能夠用于服務的內部工具。 * 通過分析堆棧跟蹤將分組錯誤并進行重復數據刪除 * 系統了解所使用的通用框架并相應地對錯誤進行分組。 * 該計劃將做更多。 Google 內部擁有廣泛的工具，他們希望向云客戶提供這些工具。 ## 相關文章 [ * [在 HackerNews](https://news.ycombinator.com/item?id=12116121) 上/ [在 Reddit](https://www.reddit.com/r/programming/comments/4tg31p/how_does_google_do_planetscale_engineering_for_a/) 上 * 圖書：[網站可靠性工程：Google 如何運行生產系統](https://www.amazon.com/Site-Reliability-Engineering-Production-Systems-ebook/dp/B01DCPXKZ6)。 它是由從事實際 SRE 工作的實際 Google SRE 編寫的，是作者 500 年綜合經驗的結果。 * [大規模計算，或者說 Google 如何扭曲我的大腦](http://matt-welsh.blogspot.com/2010/10/computing-at-scale-or-how-google-has.html) * [網站可靠性工程師-使 Google 保持 24/7 全天候運行](http://transcriptvids.com/v2/yXI7r0_J29M.html) * [服務水平和錯誤預算](https://www.usenix.org/conference/srecon16/program/presentation/jones) * [SREcon](https://www.usenix.org/conference/srecon16) 。 會議視頻[可用](https://www.usenix.org/conference/srecon16/program)。 看起來內容很多。 * [小組：誰/什么是 SRE？](https://www.usenix.org/conference/srecon16/program/presentation/definition-of-sre-panel) * [策略：規劃停電的 Google 樣式](http://highscalability.com/blog/2010/3/5/strategy-planning-for-a-power-outage-google-style.html) * [Google 如何備份互聯網以及 EB 級其他數據](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html) * [什么是“網站可靠性工程”？](https://landing.google.com/sre/interview/ben-treynor.html) * [成為 Google 的網站可靠性工程師（SRE）感覺如何？](https://www.quora.com/What-is-it-like-to-be-a-Site-Reliability-Engineer-SRE-at-Google) * [我的警惕](https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/preview#)的哲學，作者：Rob Ewaschuk，Google SRE * [這是 Google 確保（幾乎）永不衰敗的方式](http://www.wired.com/2016/04/google-ensures-services-almost-never-go/) FWIW，Stack Driver 并不是他們能夠用于服務的內部工具； 這是 Google 購買的 SaaS 創業公司。 https://techcrunch.com/2014/05/07/google-acquires-cloud-monitoring-service-stackdriver/