【我們為什麼挑選這篇文章】你有遇過任何 Google 服務無法使用的時候嗎？服務不斷線對我們來說可能理所當然，實際執行卻需要花費極大的技術與心力。這篇文章揭露了 Google 的「網站可靠性工程 (SRE)」如何讓他們能同時做好服務的開發與運營 。（責任編輯：黃筱雯）
作者/微信公眾號運維派（ID：yunweipai）
很有可能，這種情況根本沒有發生過（譯注：這文章是美國人寫的）。的確，有時也會出現因為網絡連接中斷而用不上 Google 的情況；但是 Google 的基礎性在線服務——從搜索引擎到 Gmail 再到 Google Docs 等等——幾乎永遠垂手可及。
根據 Google 官方的數據，2015 年該公司旗下的 Google App 套件在 99.97%的時間裡都處於可用狀態。 也許我們認為這是理所當然的，但它的確是一個了不起的事實；而全世界數十億的 Google 用戶似乎從來沒有停下來想想：Google 是如何把一件如此激動人心的事情處理得如此波瀾不驚的。
用軟體取代人工
Google 用了這三個詞來解釋這個問題：Site Reliability Engineering（中文可譯為：網站可靠性工程 ，後文簡稱 SRE）。也許這三個詞聽起來並不是特別性感，但它們確實是（名字聽起來更不性感）的 Google 在 10 年前就已經秉承的核心理念。
這個理念很難用一兩句話說清楚，不過可以歸結到一個中心思想：讓碼農而非那些專門從事網絡服務的 IT 人士來運營網絡服務。如果這個思想得以執行，那麼碼農們就會開發出一種不需要人為介入的工具來幫助完成運營工作（這裡所說的運營，主要是指維護服務的穩定和性能）。
「我們透過這種方法建立這樣一個團隊：大家都比較厭倦自己親自動手去完成任務，而是透過寫出軟體來取代此前需要人工完成的事情。」一位名叫 Ben Treynor Sloss 的 Google 員工在一篇文章中寫道。
對於矽谷的很多人來說，這似乎已經成為一個常識；從亞馬遜到 Box.com，這種方法已經被整個科技圈所採用。人們稱其為 DevOps（Development 加上 Operations）模式，意即通過某種努力將軟體開發者與系統管理員聯繫起來。但是以 Chef 和 Puppet 為代表，自從 DevOps 模式從 Google 的 SRE 漸漸衍生出來之後已經發生了很大的改變。只不過 Google 在過去的十年裡一直對 SRE 默不作聲，但是過去它在應對大規模高效率的網絡操作時的確是這麼做的。
不過目前 Google 已經進入到一個新的階段，它更願意討論 SRE 的相關問題了。（這主要是因為 Google 想推銷自己的雲端服務，以便外界公司能夠用上自己的軟體服務。）不僅如此，Google 還專門寫了一本書來探討關於 SRE 的問題。
好吧，這本書的名字就是 Site Reliability Engineering。此書剛剛被 O’Reilly（譯注：一個專注於科技類書籍的出版公司）出版，而來自 Sloss 的那篇論文被作為此書的第一章。如果你對 DevOps 感興趣，那麼此書在必讀之列；即使不感興趣，這本書的開頭——序言、介紹以及第一章——也足以讓我們了解到 Google 這個全世界最大的網絡帝國的驅動之道。
對於很多科技公司——其實也可以是科技圈之外的所與人——而言，系統管理（或者說運作， 隨你怎麼稱呼）是收尾工作，是電腦科技最煩人的一個方面之一。但是 Sloss，也就是外界所知道的 Google 內部負責「不間斷運行」的副總裁，卻把這個問題反過來看，辯稱網站可靠性「是所有產品最基礎的功能」，畢竟，「如果一個系統不能工作，那麼它一點用處都沒。」
黑格爾的對立統一理論
Sloss 就是 SRE 的原點。早年 Google 招他來負責公司的運營項目時，他創立了這個項目。「當你要求一個軟體工程師去設計一個運作團隊的時候，SRE 就產生了」，他說，「我設計並管理這個團隊；這個團隊運作起來就像我自己是一個 SRE 一樣。」
Todd Underwood 目前是 Google 的一個 SRE 總監；他認為 Google 雇佣 Sloss 這樣的碼農是一件非常自然的事情。「當 Google 還處於早期發展階段時候，就已經有軟體工程師很清楚地意識到哪裡會出問題以及如何解決這些問題，但是他們中沒有人願意親自去處理這些事情。」
這其實是一件麻煩事。但是 Chef 的 CTO（首席技術官）Adam Jacob 也認為要想成長為一個大體量的公司，做出這種轉變也是應該的。「將軟體開發和實際運營連接在一起是一件非常自然的事情，你不可能將兩者自然分開；尤其是當你歷史地看待這個問題的時候，你可能會更加意識到這一點。」
考慮到在傳統意義上開發和運營是完全不搭界的兩個層面，你會覺得這種轉變非常有意思。開發人員致力於寫出一個新的軟體，然後修改，最後再盡可能快地將軟體推向大眾用戶；而運營人員則是保證不出差錯，而最好的方式是將變化減少到最小。「這些本來是毫不相干的目標」，Underwood 說，「不過開玩笑的是， 當你把開發和運營聯繫起來，你就開始消彌他們之間的競爭目標了」。
Underwood 稱之為「黑格爾的對立統一理論」；不過當他這麼說的時候，沒有人買帳。「人們都不再讀黑格爾了」，他自嘲說。不過這種描述方式說到點子上了。一旦這種准備就緒，Google 就加快了將所有的好想法都付諸這種模式的進程。
開發與運營之間的平衡
有一個很重要的想法是： 為了減少開發和運營之間的衝突，Google 並不要求 100%的正常運行時間。 正如 Sloss 在書中所寫，實際上並不需要保證網絡服務 100%的時間裡處於可用狀態。用戶也並不能真正區分出 100%和 99.999%的區別（實際上他們的筆記本、WiFi、電量掉線的時間遠遠超過 0.001%）。如果你在 100%之下設置一個合理的在線時間比例——誤差預算——那麼你將會足夠的時間做出改變並且調試完畢。
「誤差預算的運用消解了開發工作和 SRE 工作之間的衝突誘因」，Sloss 說，「一次中斷不再是一件壞事。它存在於一個創新過程中的可預期範圍之內；這樣一來，開發部門和 SRE 部門都能夠解決這個問題，而不會感到害怕。」
與此同時，Google 公司也推出一些相應的規定來保證 SRE 不會演變為老式的系統管理。原則上，SRE 不允許花費 50%以上的時間在傳統的運營工作（與編程相抵觸）上。
如果在一個 SRE 團隊中，運營的優先權已經超過了開發，Google 就會將一些運營人員調配到普通的軟體開發工作中去。「有意識地調節開發和運營之間的平衡，能夠保證 SRE 們有足夠的空間去投入到有創造性的、自動化的工程中去 ，」Sloss 說，「當然，他們同時也得聽取運營部門的意見。」
Chef 公司的 Jacob 認為這裡所提到的 50%的比率並沒有那麼重要，但是他喜歡這種態度。他說「那是業務，總要有人去處理運營工作；而且運營工作幾乎是無窮無盡的，所以你硬要給他們扣上一頂帽子也是可以理解的。」
在雇佣 SRE 時，Google 甚至制定了嚴格的規範。在招募的人員中，有 50%到 60%的人員會通過像其他所有 Google 工程師那樣的嚴格考核，剩下的需要擁有 85%到 99%的 Google 工程師技能，加上一些特殊適用於 SRE 但是大多數軟體工程師不具備的技能——比如說對於 UNIX 操作系統和硬件網絡協議了如指掌等。這些都是為了保證開發和運營之間能夠保證一個恰當的平衡。
SRE 的雄心
從多種層面上而言，這是一種全新的理念。但是在他的書中，當他們試圖描述這種理念的時候，Google 團隊卻選用了一個比較老舊的例子。Google SRE 的精神先行者是一個來自 MIT 的名為 Margaret Hamilton 的程序員，她在六十年代為阿波羅飛船編寫了登月程序。正如 Hamiltion 自己說的那樣，阿波羅項目中衍生出的部分文化是向所有人和所有事物學習，包括那些看起來學不到什麼的人和事。
雖然 Hamilton 是一個碼農，但她在運營中承擔重要角色。為了證明這一點，這本書中講了一個故事：她經常帶她的女兒 Lauren 進入到計算機實驗室，有一天，Lauren 恰好碰到一個按鈕，然後把阿波羅的預發射程序植入到一個正在運行「發射後場景」程序的計算機中去。
這一下讓整個系統卡死；Hamilton 試圖在系統中添加一段錯誤監測代碼，以便在真實的飛行過程中能夠阻止這種錯誤。她的上司否決了整個想法，辯稱宇航員絕不會犯這種錯誤；但是在阿波羅 8 號中，宇航員的確犯了這麼一個錯誤。幸運的是，Hamilton 在系統文檔中加入了一個變通方案。在後續工作中，她還是加入了這段錯誤監測代碼。
如果你過來跟我說「它會死機」，那沒有什麼用；但是如果你說「它會死機，讓我來告訴你怎麼解決」，那你就很棒了——Underwood 說。「而在我們這裡，會有人既知道會出現一些問題，也知道問題出在哪裡，並且能找出方案防止問題發生。」
這就是 DevOps，或者用 Google 的話說，SRE。這三個詞聽起來沒什麼，但是它的確是一個非常強大的想法。通過它，Google 已經誕生了，但是對於某些像 Underwood 這樣富有哲學思維的 SRE 來說，他們有著更大的雄心。在他們的構想中，運營本身比開發前進得更快。
「我們希望長久以後，沒有人再做運營了。」Underwood 如是說。
延伸閱讀
【工程師不再是高薪保證】在礦工都能 coding 的年代，工程師將成新「藍領工人」
【最勵志 PM 故事】不靠 Coding 統御工程師，Sundar Pichai 用領導能力躍升 Google CEO
【工程師的手殘故事】Gitlab 員工意外刪除資料庫，漏夜開直播搶修 8 小時
（本文經原作者運營派授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈Google 是如何做到從不宕機的？〉。）
人工智慧 x 雲端應用 Solution 是什麼？
10 分鐘填寫 TO 趨勢調查問卷，就送您人工智慧黃金時代必備祕笈：1. 結果分析報告
2. 系列專題報導
3. 趨勢專家對台灣 IT 雲端化轉型的完整建議>> 填問卷 Get 祕笈
