谷歌服務為什么如此強大?
發(fā)布日期:[2016/4/11] 編輯:奇億廣州網(wǎng)站建設
谷歌服務在全球互聯(lián)網(wǎng)界已是穩(wěn)定立足,無論是搜索業(yè)務還是其它業(yè)務,哪怕在退出中國的幾年里,我們依舊感受得到它的強大,谷歌是怎么做到的呢?
對于身處墻外以及自備科學上網(wǎng)技能的你,還記得上一次是什么時候,你想上谷歌搜索點什么結果網(wǎng)頁崩潰了嗎?
真相是,這個答案本身就不成立,因為谷歌似乎一直都在那里,從來沒有宕機過,除非你連不上網(wǎng)。而除了搜索引擎,谷歌提供的各種線上服務,無論是Gmail、Google Docs還是其他,都似乎是同樣地穩(wěn)定可靠。根據(jù)谷歌提供的統(tǒng)計數(shù)字,在2015全年99.97%的時間里,你都能暢通無阻地使用包括Gmail和Docs在內(nèi)的全套谷歌應用。
似乎全世界的用戶都對此習以為常,但這完全稱得上是非常了不起的成績,只是使用谷歌的我們很少會去思考,這家公司是怎樣把“奇跡”變成日常的。
谷歌只用了短短三個詞來解釋:網(wǎng)站可靠性管理(Site Reliability Engineering,簡稱SRE)。
聽起來沒什么厲害的,但谷歌在十幾年前就提出了這一影響深遠的設想。這種管理哲學其實意蘊深厚且適用范圍廣泛,簡而言之,可以歸結為這么一個中心思想:
不要讓擅長管理網(wǎng)絡服務的IT人員來管理你司的網(wǎng)絡服務。讓編寫軟件的程序員自己來管理。
這么做的話,程序員就會自己開發(fā)有助于程序運作的工具,而不需要其他人另外花力氣找bug。
“我們期待著有朝一日,不需要人進行任何管理。”
——TODD UNDERWOOD,谷歌網(wǎng)站可靠性主管
谷歌工程副總裁Ben Treynor Sloss在新近的一篇文章里寫到:“我們的方法呈現(xiàn)出來的效果是,整個團隊的成員都會對手動執(zhí)行任務很快地產(chǎn)生厭倦,也因此都掌握了編寫程序的能力來代替之前的手動操作!
對許多硅谷中的人來說,這并不算什么新鮮的觀點。或者這么說,從亞馬遜到Box.com,整個科技界基本上都是這么干的。人們稱之為DevOps,即開發(fā)(development)和運維(operation)的合并,整合編程人員的技術與系統(tǒng)管理員的目標。不過,這場DevOps運動的發(fā)展雖然源自谷歌內(nèi)部的SRE管理體系和亞馬遜內(nèi)部類似的管理原則,但也大有不同并自成一體。只是谷歌一直都秘而不宣,就像人們好奇谷歌高效的線上運維是怎么實現(xiàn)的時候,他們還是保持低調(diào)行事。
但谷歌已經(jīng)進入了新時期,現(xiàn)在的它比以前更愿意對這類話題開門見山展開討論,很大一部分原因在于谷歌想借此推廣自家的云服務,以引進更多外部的公司,在谷歌的數(shù)據(jù)和機器網(wǎng)絡之上運行他們的軟件,甚至還出了一本專門論述SRE內(nèi)功心法的書,就叫《網(wǎng)站可靠性管理》(Site Reliability Engineering)。
無論是科技業(yè)的從業(yè)人士還是圈子外的每一個小白,系統(tǒng)管理或曰運維都是計算機技術領域最無趣的一個方面,往往出了問題才會事后諸葛亮。然而,負責谷歌日常運作的副總裁Sloss可不這么認為。恰恰相反,他認為網(wǎng)站可靠性是“任何一款產(chǎn)品最基礎的特性”,畢竟“如果沒人能用得上,這個系統(tǒng)就毫無用處。”
從無到有的SRE
Sloss算是這場SRE運動的“發(fā)起人”。一開始,谷歌把他招進來負責運維,正是他后來提出了SRE這個詞。“SRE就是你讓一個軟件工程師去設計一個運維團隊,”他說,“我假設自己就是一個SRE系統(tǒng),并按著那樣的方式來設計并管理我的團隊。”
而對Todd Underwood來說,公司聘請Sloss這樣的程序員是再自然不過的事。他向《連線》雜志表示,“當谷歌還處于創(chuàng)業(yè)階段的時候,其實還有很多其他的優(yōu)秀軟件工程師,他們更清楚問題可能以怎樣的形式出現(xiàn),也更明白整個工程該怎么做好。但沒有人真的想去親手落實!
這是非!肮雀琛钡囊环N現(xiàn)象。配置管理工具Chef的首席技術官Adam Jacob非常同意Underwood的看法并解釋道,當線上的運營成長到足夠大的體量時,這是一種意料之中的轉(zhuǎn)型!鞍衍浖_發(fā)和實際運營結合起來,乃至讓二者密不可分,這是很自然要討論的問題。全面地看問題才能有更好的產(chǎn)出!
若聯(lián)想到開發(fā)和運維原本是兩個“死對頭”,這種轉(zhuǎn)型就顯得格外有趣了。開發(fā)團隊希望開發(fā)新軟件,并盡可能快地讓公眾得到不同的體驗,但運維人員更希望確保萬事俱備、毫無差錯,最好的辦法就是盡可能減少變化。
“這是不相稱的兩個目標!盪nderwood說。
竅門就在于,把開發(fā)和運維結合起來,消除這種對立。
Underwood把這稱為“黑格爾式的正題-反題綜合體”。他也承認,這種說法沒人會真正買單,因為“沒人還會讀黑格爾了”,他打趣道。但這種說法恰恰正中命門,谷歌正是在這樣的哲學思想指導下,把其他的業(yè)務都結合起來,加速了整個SRE的轉(zhuǎn)型進程。
把犯錯概率編入預算
其中一個重要的觀點是,為了減少開發(fā)和運維之間的沖突,公司不會苛求正常運作時間達到100%。Sloss在文章中寫到,真實情況是用戶并不需要網(wǎng)絡服務達到百分百可用。退一步說,用戶也分不清正常運作時間達到100%和99.999%的區(qū)別(手提電腦、WiFi、電力和ISP宕機的概率可遠遠大于0.001%)。如果設定好一個合理的、低于100%的正常運作時間目標,也就是“錯誤預算”,你就有了更大的空間來調(diào)整變化,進行試驗。
“引入’錯誤預算’解決了開發(fā)和SRE目標之間的結構性沖突問題,”Sloss寫道,
“‘停電’再也不是壞事,而是創(chuàng)新過程可預見的一部分,也是開發(fā)團隊和SRE團隊可以管理并且無需畏懼的正常現(xiàn)象!
與此同時,谷歌也制定了配套的制度,為的是確保新的SRE成員不會淪落成以前的系統(tǒng)管理員角色。大體上,谷歌規(guī)定了SRE組的成員不能把超過一半的時間用在開發(fā)之外的傳統(tǒng)運營上。如果運營的部分開始大于開發(fā),谷歌就會把一些運營工作交給一般只負責開發(fā)軟件的團隊,也就是軟件工程師!坝幸庾R地保持運營和開發(fā)工作的平衡,讓我們得以確保SRE團隊的工作帶寬,能夠投入開發(fā)創(chuàng)造性的自動化工程,同時保留在運維工作中手機得來的經(jīng)驗智慧!盨loss寫到。
Chef公司的Jacob則認為,50%的比例并不是那么重要,但他喜歡這種態(tài)度。他說:“這就是經(jīng)濟學。我們總需要一些人來做運營的破事兒,人們總有無限的破事兒希望運營人員能夠解決。所以,給這些破事兒設個限額是完全合理的!
在招聘SRE人員方面,谷歌甚至出臺了嚴格的指導方針。約有五成到六成SRE人員是通過工程師的招聘流程進來的,其他人則有“85%到99%”的同等技術能力,再加上“大部分軟件工程師缺乏、但對SRE工作非常有用的技術技能”,比如深入了解UNIX操作系統(tǒng)的內(nèi)部原理或硬件聯(lián)網(wǎng)協(xié)議。這也是為了確保開發(fā)和運營保持適當?shù)钠胶狻?BR> 登月計劃的啟示
從許多方面來看,這是一種新的管理原則。但在進一步的闡述中,谷歌團隊用了一個很老的案例。
谷歌SRE原則的精神祖先其實是“代碼女神”Margaret Hamilton,她是MIT的程序員,也是數(shù)學和電腦科學的先鋒,在上世紀六十年代為阿波羅登月計劃開發(fā)程序。Hamilton描述到,阿波羅項目的文化之一就是“從每個人、每件事上學習,包括你最不抱希望的人和事!
Hamilton雖身為技術人員,卻在運維方面起到了重要作用。當年,她經(jīng)常把自己的小女兒Lauren帶到實驗室去。有一天Lauren不小心按下一個按鈕,結果把一個用于阿波羅發(fā)射前的程序輸入到正在運行發(fā)射后方案的電腦。這立馬使得電腦崩潰,此后Hamilton便嘗試給系統(tǒng)加入一個新的錯誤校驗代碼,讓其能夠在真正的飛行中預防這類突發(fā)情況的發(fā)生。上司對她的想法表示反對,認為宇航員永遠不會犯這樣的錯誤。然而,在阿波羅八號的飛行中,宇航員真的發(fā)生了這樣的狀況,所幸Hamilton早在系統(tǒng)文檔中加入了一個變通方案。在此后 的發(fā)射中,她給系統(tǒng)加入了錯誤校驗代碼。
“光是指出‘那樣做會崩潰的’真的沒啥作用。但如果你說,‘那樣做會崩潰的,我來告訴你怎么做’,這就非常了不起了!盪nderwood是這樣解讀的,“她看到了程序?qū)罎ⅲ⒖辞辶藭趺幢罎,然后設計出了預防方案。”
這就是DevOps,用谷歌的說法就是SRE。聽起來沒什么大不了,卻是非常強大的理念。它已經(jīng)成就了谷歌。不過,像Underwood這樣的哲學家型SRE人士還有更大的雄心。他們設想,在未來的世界里,運維能夠更進一步變成代碼的一部分。Underwood說:“我們期待著有朝一日,不需要人進行任何管理!
谷歌業(yè)務如何發(fā)展到今天,它的成功值得每一個創(chuàng)業(yè)者去深思。
本文由奇億網(wǎng)站建設原創(chuàng),原文地址:http://www.studstu.com/news/1470.html,轉(zhuǎn)摘請保留版權,謝謝。
2016/4/11 微商亂象對去中心化帶來的影響
2016/4/9 網(wǎng)站SEO的那些偽技巧
2016/4/9 小心微信營銷三大坑
2016/4/9 淺談社區(qū)o2o未來發(fā)展關注焦點
2016/4/9 農(nóng)村電商的發(fā)展需要解決哪些問題?
2016/4/9 辛苦原創(chuàng),百度不買單怎么辦?
2016/4/8 建設單頁式網(wǎng)站的五大理由
2016/4/8 跨境電商政策改變對未來創(chuàng)業(yè)者的影響
2016/4/8 O2O對于互聯(lián)網(wǎng)巨頭BAT來說是機遇
2016/4/8 做不好網(wǎng)站seo的個人反思
2016/4/8 生鮮電商難找盈利模式背后的危機
2016/4/7 提升用戶體驗,網(wǎng)頁設計需遵循十大規(guī)則
2016/4/7 利用微電商自救的o2o之路
2016/4/7 電商行業(yè)將嚴格監(jiān)管質(zhì)量標準化
2016/4/7 社區(qū)O2O運營該怎么做?
2016/4/7 了解你的用戶是微信支付必須遵循的原則
2016/4/6 以papi醬為代表的網(wǎng)紅為什么這么紅?
2016/4/6 如何將seo更好地運用在網(wǎng)站建設中?
2016/4/6 建站中CSS樣式表常見的兩種使用方法
2016/4/6 從七個方面提高網(wǎng)站建設用戶體驗
對于身處墻外以及自備科學上網(wǎng)技能的你,還記得上一次是什么時候,你想上谷歌搜索點什么結果網(wǎng)頁崩潰了嗎?
真相是,這個答案本身就不成立,因為谷歌似乎一直都在那里,從來沒有宕機過,除非你連不上網(wǎng)。而除了搜索引擎,谷歌提供的各種線上服務,無論是Gmail、Google Docs還是其他,都似乎是同樣地穩(wěn)定可靠。根據(jù)谷歌提供的統(tǒng)計數(shù)字,在2015全年99.97%的時間里,你都能暢通無阻地使用包括Gmail和Docs在內(nèi)的全套谷歌應用。
似乎全世界的用戶都對此習以為常,但這完全稱得上是非常了不起的成績,只是使用谷歌的我們很少會去思考,這家公司是怎樣把“奇跡”變成日常的。
谷歌只用了短短三個詞來解釋:網(wǎng)站可靠性管理(Site Reliability Engineering,簡稱SRE)。
聽起來沒什么厲害的,但谷歌在十幾年前就提出了這一影響深遠的設想。這種管理哲學其實意蘊深厚且適用范圍廣泛,簡而言之,可以歸結為這么一個中心思想:
不要讓擅長管理網(wǎng)絡服務的IT人員來管理你司的網(wǎng)絡服務。讓編寫軟件的程序員自己來管理。
這么做的話,程序員就會自己開發(fā)有助于程序運作的工具,而不需要其他人另外花力氣找bug。
“我們期待著有朝一日,不需要人進行任何管理。”
——TODD UNDERWOOD,谷歌網(wǎng)站可靠性主管
谷歌工程副總裁Ben Treynor Sloss在新近的一篇文章里寫到:“我們的方法呈現(xiàn)出來的效果是,整個團隊的成員都會對手動執(zhí)行任務很快地產(chǎn)生厭倦,也因此都掌握了編寫程序的能力來代替之前的手動操作!
對許多硅谷中的人來說,這并不算什么新鮮的觀點。或者這么說,從亞馬遜到Box.com,整個科技界基本上都是這么干的。人們稱之為DevOps,即開發(fā)(development)和運維(operation)的合并,整合編程人員的技術與系統(tǒng)管理員的目標。不過,這場DevOps運動的發(fā)展雖然源自谷歌內(nèi)部的SRE管理體系和亞馬遜內(nèi)部類似的管理原則,但也大有不同并自成一體。只是谷歌一直都秘而不宣,就像人們好奇谷歌高效的線上運維是怎么實現(xiàn)的時候,他們還是保持低調(diào)行事。
但谷歌已經(jīng)進入了新時期,現(xiàn)在的它比以前更愿意對這類話題開門見山展開討論,很大一部分原因在于谷歌想借此推廣自家的云服務,以引進更多外部的公司,在谷歌的數(shù)據(jù)和機器網(wǎng)絡之上運行他們的軟件,甚至還出了一本專門論述SRE內(nèi)功心法的書,就叫《網(wǎng)站可靠性管理》(Site Reliability Engineering)。
無論是科技業(yè)的從業(yè)人士還是圈子外的每一個小白,系統(tǒng)管理或曰運維都是計算機技術領域最無趣的一個方面,往往出了問題才會事后諸葛亮。然而,負責谷歌日常運作的副總裁Sloss可不這么認為。恰恰相反,他認為網(wǎng)站可靠性是“任何一款產(chǎn)品最基礎的特性”,畢竟“如果沒人能用得上,這個系統(tǒng)就毫無用處。”
從無到有的SRE
Sloss算是這場SRE運動的“發(fā)起人”。一開始,谷歌把他招進來負責運維,正是他后來提出了SRE這個詞。“SRE就是你讓一個軟件工程師去設計一個運維團隊,”他說,“我假設自己就是一個SRE系統(tǒng),并按著那樣的方式來設計并管理我的團隊。”
而對Todd Underwood來說,公司聘請Sloss這樣的程序員是再自然不過的事。他向《連線》雜志表示,“當谷歌還處于創(chuàng)業(yè)階段的時候,其實還有很多其他的優(yōu)秀軟件工程師,他們更清楚問題可能以怎樣的形式出現(xiàn),也更明白整個工程該怎么做好。但沒有人真的想去親手落實!
這是非!肮雀琛钡囊环N現(xiàn)象。配置管理工具Chef的首席技術官Adam Jacob非常同意Underwood的看法并解釋道,當線上的運營成長到足夠大的體量時,這是一種意料之中的轉(zhuǎn)型!鞍衍浖_發(fā)和實際運營結合起來,乃至讓二者密不可分,這是很自然要討論的問題。全面地看問題才能有更好的產(chǎn)出!
若聯(lián)想到開發(fā)和運維原本是兩個“死對頭”,這種轉(zhuǎn)型就顯得格外有趣了。開發(fā)團隊希望開發(fā)新軟件,并盡可能快地讓公眾得到不同的體驗,但運維人員更希望確保萬事俱備、毫無差錯,最好的辦法就是盡可能減少變化。
“這是不相稱的兩個目標!盪nderwood說。
竅門就在于,把開發(fā)和運維結合起來,消除這種對立。
Underwood把這稱為“黑格爾式的正題-反題綜合體”。他也承認,這種說法沒人會真正買單,因為“沒人還會讀黑格爾了”,他打趣道。但這種說法恰恰正中命門,谷歌正是在這樣的哲學思想指導下,把其他的業(yè)務都結合起來,加速了整個SRE的轉(zhuǎn)型進程。
把犯錯概率編入預算
其中一個重要的觀點是,為了減少開發(fā)和運維之間的沖突,公司不會苛求正常運作時間達到100%。Sloss在文章中寫到,真實情況是用戶并不需要網(wǎng)絡服務達到百分百可用。退一步說,用戶也分不清正常運作時間達到100%和99.999%的區(qū)別(手提電腦、WiFi、電力和ISP宕機的概率可遠遠大于0.001%)。如果設定好一個合理的、低于100%的正常運作時間目標,也就是“錯誤預算”,你就有了更大的空間來調(diào)整變化,進行試驗。
“引入’錯誤預算’解決了開發(fā)和SRE目標之間的結構性沖突問題,”Sloss寫道,
“‘停電’再也不是壞事,而是創(chuàng)新過程可預見的一部分,也是開發(fā)團隊和SRE團隊可以管理并且無需畏懼的正常現(xiàn)象!
與此同時,谷歌也制定了配套的制度,為的是確保新的SRE成員不會淪落成以前的系統(tǒng)管理員角色。大體上,谷歌規(guī)定了SRE組的成員不能把超過一半的時間用在開發(fā)之外的傳統(tǒng)運營上。如果運營的部分開始大于開發(fā),谷歌就會把一些運營工作交給一般只負責開發(fā)軟件的團隊,也就是軟件工程師!坝幸庾R地保持運營和開發(fā)工作的平衡,讓我們得以確保SRE團隊的工作帶寬,能夠投入開發(fā)創(chuàng)造性的自動化工程,同時保留在運維工作中手機得來的經(jīng)驗智慧!盨loss寫到。
Chef公司的Jacob則認為,50%的比例并不是那么重要,但他喜歡這種態(tài)度。他說:“這就是經(jīng)濟學。我們總需要一些人來做運營的破事兒,人們總有無限的破事兒希望運營人員能夠解決。所以,給這些破事兒設個限額是完全合理的!
在招聘SRE人員方面,谷歌甚至出臺了嚴格的指導方針。約有五成到六成SRE人員是通過工程師的招聘流程進來的,其他人則有“85%到99%”的同等技術能力,再加上“大部分軟件工程師缺乏、但對SRE工作非常有用的技術技能”,比如深入了解UNIX操作系統(tǒng)的內(nèi)部原理或硬件聯(lián)網(wǎng)協(xié)議。這也是為了確保開發(fā)和運營保持適當?shù)钠胶狻?BR> 登月計劃的啟示
從許多方面來看,這是一種新的管理原則。但在進一步的闡述中,谷歌團隊用了一個很老的案例。
谷歌SRE原則的精神祖先其實是“代碼女神”Margaret Hamilton,她是MIT的程序員,也是數(shù)學和電腦科學的先鋒,在上世紀六十年代為阿波羅登月計劃開發(fā)程序。Hamilton描述到,阿波羅項目的文化之一就是“從每個人、每件事上學習,包括你最不抱希望的人和事!
Hamilton雖身為技術人員,卻在運維方面起到了重要作用。當年,她經(jīng)常把自己的小女兒Lauren帶到實驗室去。有一天Lauren不小心按下一個按鈕,結果把一個用于阿波羅發(fā)射前的程序輸入到正在運行發(fā)射后方案的電腦。這立馬使得電腦崩潰,此后Hamilton便嘗試給系統(tǒng)加入一個新的錯誤校驗代碼,讓其能夠在真正的飛行中預防這類突發(fā)情況的發(fā)生。上司對她的想法表示反對,認為宇航員永遠不會犯這樣的錯誤。然而,在阿波羅八號的飛行中,宇航員真的發(fā)生了這樣的狀況,所幸Hamilton早在系統(tǒng)文檔中加入了一個變通方案。在此后 的發(fā)射中,她給系統(tǒng)加入了錯誤校驗代碼。
“光是指出‘那樣做會崩潰的’真的沒啥作用。但如果你說,‘那樣做會崩潰的,我來告訴你怎么做’,這就非常了不起了!盪nderwood是這樣解讀的,“她看到了程序?qū)罎ⅲ⒖辞辶藭趺幢罎,然后設計出了預防方案。”
這就是DevOps,用谷歌的說法就是SRE。聽起來沒什么大不了,卻是非常強大的理念。它已經(jīng)成就了谷歌。不過,像Underwood這樣的哲學家型SRE人士還有更大的雄心。他們設想,在未來的世界里,運維能夠更進一步變成代碼的一部分。Underwood說:“我們期待著有朝一日,不需要人進行任何管理!
谷歌業(yè)務如何發(fā)展到今天,它的成功值得每一個創(chuàng)業(yè)者去深思。
本文由奇億網(wǎng)站建設原創(chuàng),原文地址:http://www.studstu.com/news/1470.html,轉(zhuǎn)摘請保留版權,謝謝。