谷歌的全套應用似乎總是堅如磐石，穩固可靠。
對于身處墻外以及自備科學上網技能的你，還記得上一次是什么時候，你想上谷歌搜索點什么結果網頁崩潰了嗎？
真相是，這個答案本身就不成立，因為谷歌似乎一直都在那里，從來沒有宕機過，除非你連不上網。而除了搜索引擎，谷歌提供的各種線上服務，無論是Gmail、Google Docs還是其他，都似乎是同樣地穩定可靠。根據谷歌提供的統計數字，在2015全年99.97%的時間里，你都能暢通無阻地使用包括Gmail和Docs在內的全套谷歌應用。
似乎全世界的用戶都對此習以為常，但這完全稱得上是非常了不起的成績，只是使用谷歌的我們很少會去思考，這家公司是怎樣把“奇跡”變成日常的。
谷歌只用了短短三個詞來解釋：網站可靠性管理（Site Reliability Engineering，簡稱SRE）。
聽起來沒什么厲害的，但谷歌在十幾年前就提出了這一影響深遠的設想。這種管理哲學其實意蘊深厚且適用范圍廣泛，簡而言之，可以歸結為這么一個中心思想：
不要讓擅長管理網絡服務的IT人員來管理你司的網絡服務。讓編寫軟件的程序員自己來管理。
這么做的話，程序員就會自己開發有助于程序運作的工具，而不需要其他人另外花力氣找bug。
“我們期待著有朝一日，不需要人進行任何管理。”
——TODD UNDERWOOD，谷歌網站可靠性主管
谷歌工程副總裁Ben Treynor Sloss在新近的一篇文章里寫到：“我們的方法呈現出來的效果是，整個團隊的成員都會對手動執行任務很快地產生厭倦，也因此都掌握了編寫程序的能力來代替之前的手動操作。”
對許多硅谷中的人來說，這并不算什么新鮮的觀點?；蛘哌@么說，從亞馬遜到Box.com，整個科技界基本上都是這么干的。人們稱之為DevOps，即開發（development）和運維（operation）的合并，整合編程人員的技術與系統管理員的目標。不過，這場DevOps運動的發展雖然源自谷歌內部的SRE管理體系和亞馬遜內部類似的管理原則，但也大有不同并自成一體。只是谷歌一直都秘而不宣，就像人們好奇谷歌高效的線上運維是怎么實現的時候，他們還是保持低調行事。
但谷歌已經進入了新時期，現在的它比以前更愿意對這類話題開門見山展開討論，很大一部分原因在于谷歌想借此推廣自家的云服務，以引進更多外部的公司，在谷歌的數據和機器網絡之上運行他們的軟件，甚至還出了一本專門論述SRE內功心法的書，就叫《網站可靠性管理》（Site Reliability Engineering）。
無論是科技業的從業人士還是圈子外的每一個小白，系統管理或曰運維都是計算機技術領域最無趣的一個方面，往往出了問題才會事后諸葛亮。然而，負責谷歌日常運作的副總裁Sloss可不這么認為。恰恰相反，他認為網站可靠性是“任何一款產品最基礎的特性”，畢竟“如果沒人能用得上，這個系統就毫無用處。”
從無到有的SRE
Sloss算是這場SRE運動的“發起人”。一開始，谷歌把他招進來負責運維，正是他后來提出了SRE這個詞。“SRE就是你讓一個軟件工程師去設計一個運維團隊，”他說，“我假設自己就是一個SRE系統，并按著那樣的方式來設計并管理我的團隊。”
而對Todd Underwood來說，公司聘請Sloss這樣的程序員是再自然不過的事。他向《連線》雜志表示，“當谷歌還處于創業階段的時候，其實還有很多其他的優秀軟件工程師，他們更清楚問題可能以怎樣的形式出現，也更明白整個工程該怎么做好。但沒有人真的想去親手落實。”
這是非常“谷歌”的一種現象。配置管理工具Chef的首席技術官Adam Jacob非常同意Underwood的看法并解釋道，當線上的運營成長到足夠大的體量時，這是一種意料之中的轉型。“把軟件開發和實際運營結合起來，乃至讓二者密不可分，這是很自然要討論的問題。全面地看問題才能有更好的產出。”
若聯想到開發和運維原本是兩個“死對頭”，這種轉型就顯得格外有趣了。開發團隊希望開發新軟件，并盡可能快地讓公眾得到不同的體驗，但運維人員更希望確保萬事俱備、毫無差錯，最好的辦法就是盡可能減少變化。
“這是不相稱的兩個目標。”Underwood說。
竅門就在于，把開發和運維結合起來，消除這種對立。
Underwood把這稱為“黑格爾式的正題-反題綜合體”。他也承認，這種說法沒人會真正買單，因為“沒人還會讀黑格爾了”，他打趣道。但這種說法恰恰正中命門，谷歌正是在這樣的哲學思想指導下，把其他的業務都結合起來，加速了整個SRE的轉型進程。
把犯錯概率編入預算
其中一個重要的觀點是，為了減少開發和運維之間的沖突，公司不會苛求正常運作時間達到100%。Sloss在文章中寫到，真實情況是用戶并不需要網絡服務達到百分百可用。退一步說，用戶也分不清正常運作時間達到100%和99.999%的區別（手提電腦、WiFi、電力和ISP宕機的概率可遠遠大于0.001%）。如果設定好一個合理的、低于100%的正常運作時間目標，也就是“錯誤預算”，你就有了更大的空間來調整變化，進行試驗。
“引入’錯誤預算’解決了開發和SRE目標之間的結構性沖突問題，”Sloss寫道，
“‘停電’再也不是壞事，而是創新過程可預見的一部分，也是開發團隊和SRE團隊可以管理并且無需畏懼的正?，F象。”
與此同時，谷歌也制定了配套的制度，為的是確保新的SRE成員不會淪落成以前的系統管理員角色。大體上，谷歌規定了SRE組的成員不能把超過一半的時間用在開發之外的傳統運營上。如果運營的部分開始大于開發，谷歌就會把一些運營工作交給一般只負責開發軟件的團隊，也就是軟件工程師。“有意識地保持運營和開發工作的平衡，讓我們得以確保SRE團隊的工作帶寬，能夠投入開發創造性的自動化工程，同時保留在運維工作中手機得來的經驗智慧。”Sloss寫到。
Chef公司的Jacob則認為，50%的比例并不是那么重要，但他喜歡這種態度。他說：“這就是經濟學。我們總需要一些人來做運營的破事兒，人們總有無限的破事兒希望運營人員能夠解決。所以，給這些破事兒設個限額是完全合理的。”
在招聘SRE人員方面，谷歌甚至出臺了嚴格的指導方針。約有五成到六成SRE人員是通過工程師的招聘流程進來的，其他人則有“85%到99%”的同等技術能力，再加上“大部分軟件工程師缺乏、但對SRE工作非常有用的技術技能”，比如深入了解UNIX操作系統的內部原理或硬件聯網協議。這也是為了確保開發和運營保持適當的平衡。
登月計劃的啟示
從許多方面來看，這是一種新的管理原則。但在進一步的闡述中，谷歌團隊用了一個很老的案例。
谷歌SRE原則的精神祖先其實是“代碼女神”Margaret Hamilton，她是MIT的程序員，也是數學和電腦科學的先鋒，在上世紀六十年代為阿波羅登月計劃開發程序。Hamilton描述到，阿波羅項目的文化之一就是“從每個人、每件事上學習，包括你最不抱希望的人和事。”
Hamilton雖身為技術人員，卻在運維方面起到了重要作用。當年，她經常把自己的小女兒Lauren帶到實驗室去。有一天Lauren不小心按下一個按鈕，結果把一個用于阿波羅發射前的程序輸入到正在運行發射后方案的電腦。這立馬使得電腦崩潰，此后Hamilton便嘗試給系統加入一個新的錯誤校驗代碼，讓其能夠在真正的飛行中預防這類突發情況的發生。上司對她的想法表示反對，認為宇航員永遠不會犯這樣的錯誤。然而，在阿波羅八號的飛行中，宇航員真的發生了這樣的狀況，所幸Hamilton早在系統文檔中加入了一個變通方案。在此后的發射中，她給系統加入了錯誤校驗代碼。
“光是指出‘那樣做會崩潰的’真的沒啥作用。但如果你說，‘那樣做會崩潰的，我來告訴你怎么做’，這就非常了不起了。”Underwood是這樣解讀的，“她看到了程序將會崩潰，并看清了會怎么崩潰，然后設計出了預防方案。”
這就是DevOps，用谷歌的說法就是SRE。聽起來沒什么大不了，卻是非常強大的理念。它已經成就了谷歌。不過，像Underwood這樣的哲學家型SRE人士還有更大的雄心。他們設想，在未來的世界里，運維能夠更進一步變成代碼的一部分。Underwood說：“我們期待著有朝一日，不需要人進行任何管理。”（本文首發鈦媒體）
京公網安備 11010502049343號