很有可能，這種情況根本沒有發生過(譯注：這是文章是美國人寫的)。的確，有時也會出現因為網絡連接中斷而用不上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如是說。
京公網安備 11010502049343號