關(guān)于我們
書單推薦
新書推薦
|
SRE:Google運(yùn)維解密
大型軟件系統(tǒng)生命周期的絕大部分都處于“使用”階段,而非“設(shè)計(jì)”或“實(shí)現(xiàn)”階段。那么為什么我們卻總是認(rèn)為軟件工程應(yīng)該首要關(guān)注設(shè)計(jì)和實(shí)現(xiàn)呢?在《SRE:Google運(yùn)維解密》中,Google SRE的關(guān)鍵成員解釋了他們是如何對(duì)軟件進(jìn)行生命周期的整體性關(guān)注的,以及為什么這樣做能夠幫助Google成功地構(gòu)建、部署、監(jiān)控和運(yùn)維世界上現(xiàn)存zui大的軟件系統(tǒng)。通過閱讀《SRE:Google運(yùn)維解密》,讀者可以學(xué)習(xí)到Google工程師在提高系統(tǒng)部署規(guī)模、改進(jìn)可靠性和資源利用效率方面的指導(dǎo)思想與具體實(shí)踐——這些都是可以立即直接應(yīng)用的寶貴經(jīng)驗(yàn)。
任何一個(gè)想要?jiǎng)?chuàng)建、擴(kuò)展大規(guī)模集成系統(tǒng)的人都應(yīng)該閱讀《SRE:Google運(yùn)維解密》!禨RE:Google運(yùn)維解密》針對(duì)如何構(gòu)建一個(gè)可長(zhǎng)期維護(hù)的系統(tǒng)提供了非常寶貴的實(shí)踐經(jīng)驗(yàn)。
√ 超級(jí)暢銷書,國(guó)外在線書店長(zhǎng)居前列,打標(biāo)#1 Best Seller
√ 運(yùn)維高燒不退,谷歌神書問世,繼續(xù)為這一熱潮推波助瀾 √ 本書解密全球神秘又讓人仰望的技術(shù)崗位——谷歌SRE √ 未出先火,本書原著問世時(shí)各大社區(qū)火爆異常、人氣爆棚
如果用一個(gè)詞語來描述 Google 的歷史,那就是不斷地“擴(kuò)大規(guī)模”(scaling up)。Google 的成長(zhǎng)經(jīng)歷,是計(jì)算機(jī)行業(yè)中數(shù)一數(shù)二的成功故事,標(biāo)志著整個(gè)社會(huì)向 IT 為中心的商業(yè)模式的轉(zhuǎn)變。Google 很早就開始實(shí)踐 IT 與商業(yè)模式的結(jié)合,也是向社區(qū)推廣DevOps 理念的先行者。本書就是由來自公司各個(gè)部門,切身參與甚至主導(dǎo)了整個(gè)行業(yè)轉(zhuǎn)型實(shí)踐的人寫成的。
Google 是在一個(gè)系統(tǒng)運(yùn)維工程師行業(yè)轉(zhuǎn)型的階段發(fā)展壯大的。Google 的發(fā)展史就像是對(duì)傳統(tǒng)的系統(tǒng)運(yùn)維理念發(fā)出的革命宣言:我們無法按照傳統(tǒng)方式運(yùn)維Google 系統(tǒng),必須要思考一種新的模式,但是同時(shí)我們也沒有時(shí)間等待其他人驗(yàn)證和支持我們的理論。在Principles of Network and System Administration(參見文獻(xiàn)[bur99])一書的介紹中,我提出了一種觀點(diǎn):系統(tǒng)運(yùn)維本質(zhì)上是人與計(jì)算機(jī)共同參與的一項(xiàng)系統(tǒng)性工程。當(dāng)時(shí)的一些評(píng)論者對(duì)這種觀點(diǎn)表示了強(qiáng)烈的反對(duì):“這個(gè)行業(yè)還遠(yuǎn)遠(yuǎn)沒有成熟到可以稱為一項(xiàng)工程”。在那時(shí),我甚至對(duì)整個(gè)運(yùn)維行業(yè)產(chǎn)生了懷疑,認(rèn)為這個(gè)行業(yè)在個(gè)人英雄主義與神秘色彩中已經(jīng)永久地迷失了自己,無法前進(jìn)。但是,這時(shí)Google 誕生了,Google 的高速發(fā)展將我的預(yù)言變成了現(xiàn)實(shí)。我之前的定義變成了一個(gè)具體的詞語:SRE,站點(diǎn)可靠性工程師。我的幾個(gè)朋友切身參與了這個(gè)新職業(yè)的創(chuàng)立,用軟件工程理念和自動(dòng)化工具定義了這個(gè)行業(yè)。一開始,他們顯得很神秘,Google 公司內(nèi)的體驗(yàn)和整個(gè)行業(yè)也格格不入,Google 太特殊了! 隨著時(shí)間的推移,公司內(nèi)外交流逐漸增多。這本書的目標(biāo)就是將SRE 的一些思考和實(shí)踐帶給整個(gè)行業(yè),以促進(jìn)交流。 在本書中,我們不僅僅展示了 Google 是如何建設(shè)維護(hù)其富有傳奇色彩的大型計(jì)算集群的。更重要的是,我們展示了在建設(shè)過程中,Google 工程師團(tuán)隊(duì)是如何學(xué)習(xí)、成長(zhǎng)、反復(fù)修改,zui后定義出一套完整的工具和科技體系的過程。IT 行業(yè)大多自我封閉,交流過少,很多從業(yè)人員都或多或少地受教條主義的限制。如果Google 工程師團(tuán)隊(duì)能克服這個(gè)慣性,保持開放的精神,那么我們也能夠一起和他們面對(duì) IT 行業(yè)內(nèi)zui尖端的挑戰(zhàn)。 這本書由一群有共同目標(biāo)的 Google 工程師寫就的短文組成。本書的作者們聚集在同一個(gè)公司旗下,為了同一個(gè)目標(biāo)努力,本身就是一件很特別的事情。在本書的各個(gè)章節(jié)之間經(jīng)常能看到軟件系統(tǒng)的共同點(diǎn),以及工作模式上的共通之處。我們經(jīng)?梢詮亩鄠(gè)角度分析不同的決策選擇,了解他們是如何一起解決公司內(nèi)部多種利益沖突的。這些文章并不是嚴(yán)謹(jǐn)?shù)膶W(xué)術(shù)研究論文,而是這些人的切身經(jīng)歷。雖然本書的作者們有著不同的工作目標(biāo)、寫作風(fēng)格,以及技術(shù)背景,但是他們都嘗試著去真誠(chéng)地描述自己遇到的問題和解決的經(jīng)歷。這和 IT 行業(yè)內(nèi)的普遍文風(fēng)截然不同,風(fēng)格迥異。有些作者會(huì)宣稱:“不要做A,只有做B 才是正確的。” 另一些作者會(huì)更謹(jǐn)慎,行文更富有哲學(xué)性。這其實(shí)恰恰代表了整個(gè) IT 行業(yè)內(nèi)不同個(gè)性融合的現(xiàn)狀。而我們作為讀者,作為觀察者,并不了解整個(gè)Google 的歷史,也沒有參與到具體的決策過程中,無法全面了解當(dāng)事人所面臨的糾纏不清的挑戰(zhàn),只能帶著謙遜的態(tài)度遠(yuǎn)遠(yuǎn)旁觀。在閱讀本書的過程中,相信讀者一定會(huì)產(chǎn)生出許多疑問:“他們當(dāng)時(shí)為什么沒有選擇X ?”“ 如果他們選擇了Y,結(jié)果會(huì)是怎樣?”“ 如果多年之后回頭再看,這個(gè)選擇會(huì)是正確的嗎?” 這些問題,恰恰是閱讀本書的zui大收獲,因?yàn)槲覀兊?次有機(jī)會(huì)將自己的經(jīng)歷、選擇和本書陳列的決策邏輯相互對(duì)應(yīng),從中發(fā)現(xiàn)不足和缺陷。 這本書的成書過程也堪稱奇跡。今天,我們能感受到整個(gè)行業(yè)都在鼓吹厚顏無恥的 “代碼拿來主義”(just show me the code)。開源軟件社區(qū)內(nèi)部正在形成一種“不要問我問題”的風(fēng)氣,過于強(qiáng)調(diào)平等卻忽略領(lǐng)域?qū)<业囊庖姟oogle 是行業(yè)內(nèi)為數(shù)不多的,愿意投入精英力量鉆研本質(zhì)問題的公司,而且這些公司精英很多都有工學(xué)博士學(xué)位。工具永遠(yuǎn)只是解決方案中的一個(gè)小小組件,用來鏈接日益龐雜的軟件、人和海量的數(shù)據(jù)。這本書中沒有萬能藥,沒有什么東西能解決一切問題,但是這恰恰是本書的宗旨:相比zui后的軟件結(jié)果、架構(gòu)設(shè)計(jì)而言,真實(shí)的設(shè)計(jì)過程、作者本身的思考經(jīng)歷更有價(jià)值。實(shí)現(xiàn)細(xì)節(jié)永遠(yuǎn)只是短暫存在的,但是文檔化的設(shè)計(jì)過程卻是無價(jià)之寶。有機(jī)會(huì)了解到這些設(shè)計(jì)的內(nèi)幕真是太難得了! 這本書,歸根到底,記錄了 Google 這個(gè)公司的成長(zhǎng)經(jīng)歷。書中的很多故事都是由相互重疊的故事組成的,這恰恰說明了擴(kuò)展一個(gè)計(jì)算機(jī)系統(tǒng),要比簡(jiǎn)單按照書本上的標(biāo)準(zhǔn)架構(gòu)放大困難得多。一個(gè)公司的成長(zhǎng),意味著整個(gè)公司商業(yè)模式和工作模式的擴(kuò)展,而不是簡(jiǎn)單的資源擴(kuò)張。僅此一點(diǎn),這本書就物超所值了。 自省,是一個(gè)在 IT 行業(yè)內(nèi)部并不流行的詞語。我們不斷重復(fù)發(fā)明各種系統(tǒng)。很多年以來,只有 USENIX LISA 大會(huì)論壇以及其他幾個(gè)專注于操作系統(tǒng)的會(huì)議會(huì)討論一些 IT 基礎(chǔ)設(shè)施的設(shè)計(jì)和實(shí)現(xiàn)。很多年后的今天,IT 行業(yè)已經(jīng)天翻地覆,但是本書仍然彌足珍貴:它詳細(xì)記錄了Google 邁過分水嶺時(shí)期的全過程。很顯然,這些經(jīng)歷沒有辦法完全復(fù)制,也許只能被模仿,但是卻可以啟發(fā)讀者,指引未來。本書作者們表現(xiàn)出了極大的真誠(chéng),顯示了謙遜的風(fēng)格,以及極強(qiáng)的凝聚力、領(lǐng)導(dǎo)力。這些文章記錄了作者們的希望、擔(dān)憂、成功與失敗的經(jīng)歷。我向這些作者們和編者們的勇氣致敬,正是這種坦率,讓我們能夠作為旁觀者和后來人,從前人的經(jīng)歷中學(xué)習(xí)到zui寶貴的知識(shí)。 Mark Burgess In Search of Certainty 一書作者 Oslo,2016 年3 月 序言 軟件工程有的時(shí)候和養(yǎng)孩子類似:雖然生育的過程是痛苦和困難的,但是養(yǎng)育孩子成人的過程才是真正需要花費(fèi)絕大部分精力的地方。但是,傳統(tǒng)軟件工程專業(yè)花費(fèi)了很多精力討論軟件的開發(fā)過程,而不是其后的維護(hù)過程。有統(tǒng)計(jì)顯示, 一個(gè)軟件系統(tǒng)的40%~90% 的花銷其實(shí)是花在開發(fā)建設(shè)完成之后不斷維護(hù)過程中的。行業(yè)內(nèi)流行的一個(gè)說法是:一個(gè)系統(tǒng)如果已經(jīng)開發(fā)完成,部署在生產(chǎn)環(huán)境上,那么它就是 “穩(wěn)定的”,就不需要那么多工程師花費(fèi)精力去優(yōu)化、維護(hù)。我們認(rèn)為這個(gè)說法是錯(cuò)誤的。從這個(gè)視角出發(fā),我們認(rèn)為如果軟件工程職業(yè)主要專注于設(shè)計(jì)和構(gòu)建軟件系統(tǒng), 那么應(yīng)該有另外一種職業(yè)專注于整個(gè)軟件系統(tǒng)的生命周期管理。從其設(shè)計(jì)一直到部署,歷經(jīng)不斷改進(jìn),zui后順利退役。這樣一種職業(yè)必須具備非常廣泛的技能,但是和其他職業(yè)的專注點(diǎn)都不同。Google 將這個(gè)職位稱為站點(diǎn)可靠性工程師(SRE,Site Reliability Engineering)。 那么,站點(diǎn)可靠性工程師究竟代表著什么呢?的確,這個(gè)詞語并不能夠特別清晰地描述這個(gè)職位的意義;旧厦總(gè) Google SRE 都會(huì)被經(jīng)常問到這個(gè)職位到底代表什么意思,以及他們的日常工作究竟是什么。 將這個(gè)詞語展開來說:首先,也是zui重要的一點(diǎn),SRE 是工程師(engineer)。SRE 使用計(jì)算機(jī)科學(xué)和軟件工程手段來設(shè)計(jì)和研發(fā)大型、分布式計(jì)算機(jī)軟件系統(tǒng)。有的時(shí)候,SRE 和產(chǎn)品研發(fā)團(tuán)隊(duì)共同工作,其他時(shí)候我們需要開發(fā)這些系統(tǒng)的額外組件:例如備份系統(tǒng)和負(fù)載均衡系統(tǒng)等。理想情況下,同時(shí)推進(jìn)這些組件在多個(gè)項(xiàng)目中復(fù)用。還有的時(shí)候,我們的任務(wù)是想出各種各樣的辦法用現(xiàn)有組件解決新的問題。 其次,SRE 的關(guān)注焦點(diǎn)在于可靠性。Ben Treynor Sloss,Google 負(fù)責(zé)7×24 運(yùn)維的副總裁,SRE 名稱的發(fā)明者,宣稱可靠性應(yīng)該是任何產(chǎn)品設(shè)計(jì)中zui基本的概念:任何一個(gè)系統(tǒng)如果沒有人能夠穩(wěn)定地使用,就沒有存在的意義。因?yàn)榭煽啃?是如此重要,因此SRE 專注于對(duì)其負(fù)責(zé)的軟件系統(tǒng)架構(gòu)設(shè)計(jì)、運(yùn)維流程的不斷優(yōu)化,讓這些大型軟件系統(tǒng)運(yùn)行得更可靠,擴(kuò)展性更好,能更有效地利用資源。但是,SRE 并不是無止境地追求完美:當(dāng)一個(gè)系統(tǒng)已經(jīng) “足夠可靠” 的時(shí)候,SRE 通常將精力轉(zhuǎn)而投入到研發(fā)新的功能和創(chuàng)造新的產(chǎn)品中。 zui后,SRE 的主要工作是運(yùn)維在分布式集群管理系統(tǒng)上運(yùn)行的具體業(yè)務(wù)服務(wù)(service)。不論是遍布全球的存儲(chǔ)服務(wù),還是億萬用戶賴以工作的 E-mail 服務(wù),還是 Google zui初的 Web 搜索服務(wù)。SRE 中的“ S” zui開始指代的就是google.com 的運(yùn)維服務(wù),因?yàn)镾RE的第1個(gè)工作就是維持網(wǎng)站的正常運(yùn)轉(zhuǎn)。隨著時(shí)間的推移,SRE 逐漸接管了 Google 內(nèi)部絕大部分產(chǎn)品系統(tǒng),包括 Google Cloud Platform 這類開發(fā)者平臺(tái),也包括內(nèi)部的一些非網(wǎng)站類的基礎(chǔ)設(shè)施系統(tǒng),例如 Bigtable。 雖然我們?cè)谶@里將 SRE 的職位定義得比較寬泛,但是在這樣一個(gè)互聯(lián)網(wǎng)業(yè)務(wù)高速發(fā)展的時(shí)代,這個(gè)職位的出現(xiàn)毫不奇怪。同樣,雖然在應(yīng)用系統(tǒng)運(yùn)營(yíng)維護(hù)的過程中有數(shù)不清的重要環(huán)節(jié)需要關(guān)注,我們zui關(guān)注的是“可靠性”這一點(diǎn)也不奇怪。在Web 服務(wù)領(lǐng)域里,對(duì)服務(wù)器端軟件的優(yōu)化和修改是相對(duì)可控的,變更管理與生產(chǎn)安全又結(jié)合得非常緊密,一種類似于 SRE 的職業(yè)早晚會(huì)在這個(gè)環(huán)境下誕生。 雖然 SRE 這個(gè)行業(yè)是在 Google 內(nèi)部,從Web 社區(qū)中誕生的,但我們認(rèn)為這個(gè)職業(yè)對(duì)其他團(tuán)隊(duì)和組織也有很多值得借鑒的地方。本書是對(duì)闡述SRE 發(fā)展過程的一次嘗試:我們既希望將這些寶貴經(jīng)驗(yàn)共享給其他相關(guān)行業(yè),也希望能從其他行業(yè)中汲取知識(shí),從而更好地定義各種角色和術(shù)語。為了這個(gè)目的,本書將通用的理論、設(shè)計(jì)理念和思想,與實(shí)際的應(yīng)用工具介紹等分開。在某些需要結(jié)合Google 內(nèi)部信息討論主題的時(shí)候,我們相信讀者可以進(jìn)行類比,將書中的理念與自己的實(shí)際環(huán)境相結(jié)合,以便得出更為有效的結(jié)論。本書中也包含了一些對(duì) Google 內(nèi)部生產(chǎn)環(huán)境的介紹,將 Google 內(nèi)部環(huán)境與外部常見的開源類軟件相對(duì)應(yīng)。這樣可以讓本書的一些設(shè)計(jì)理念與實(shí)踐的結(jié)合度更強(qiáng),應(yīng)用起來更容易。 zui后,我們當(dāng)然希望社區(qū)內(nèi)出現(xiàn)更多、更可靠的軟件系統(tǒng)。我們知道,創(chuàng)業(yè)企業(yè)甚至中型企業(yè)經(jīng)常對(duì)如何應(yīng)用這些理念和技術(shù)感到困惑?煽啃跃拖癜踩,越早關(guān)注越好。這就意味著一些小型創(chuàng)業(yè)公司,在應(yīng)付日常面臨的種種挑戰(zhàn)時(shí),也應(yīng)該抽出一部分精力來面對(duì)可靠性這個(gè)話題。這與蓋房子有些類似,如果一開始將整個(gè)地基打好并保持繼續(xù)修繕,要比蓋好房子之后再重新修改設(shè)計(jì)要容易得多。本書第4 部分著重介紹了 SRE 團(tuán)隊(duì)如何進(jìn)行內(nèi)部培訓(xùn)、如何加強(qiáng)內(nèi)部溝通等zui佳實(shí)踐,很多都可以直接拿來應(yīng)用。 對(duì)中型企業(yè)來說,企業(yè)內(nèi)部可能已經(jīng)有這樣的一組人在做著與SRE 非常類似的工作。這些人可能并不叫 SRE 這個(gè)名字,甚至可能沒有受到管理層的重視。在這樣的企業(yè)中,提高可靠性zui好的辦法往往就是去認(rèn)可這些人的工作,并配備足夠的激勵(lì)機(jī)制。在牛頓被世界正式認(rèn)可為物理學(xué)家之前,他經(jīng)常被稱作是zui后的煉金術(shù)師。而這些專注于可靠性的工程師們,正如當(dāng)年的牛頓一樣,是一個(gè)新時(shí)代的開拓者。 如果一定要為SRE 尋找一個(gè)起源的話,誰才能夠被稱為世界上第1個(gè)SRE 呢?我們選擇了 Margaret Hamilton,MIT 教授,參與了阿波羅登月計(jì)劃的軟件開發(fā)工作。她的工作具有現(xiàn)代SRE 的一切特性。用她自己的話來講:“團(tuán)隊(duì)文化就是從一切經(jīng)歷中不斷學(xué)習(xí),包括來自那些我們zui意想不到的地方的經(jīng)歷! 在Apollo 7 飛船研發(fā)期間的某一天,Margaret 帶著她的小女兒 Lauren 一起來到公司。在 Margaret 忙著和組員們?cè)诖笮陀?jì)算機(jī)上運(yùn)行飛行模擬測(cè)試的時(shí)候,她的小女兒偷偷地按下了控制臺(tái)上的 DSKY 鍵。整個(gè)模擬程序出乎意料地崩潰了,導(dǎo)致整個(gè)火箭發(fā)射程序意外終止。Margaret 和組員調(diào)試后發(fā)現(xiàn),原來Lauren 意外觸發(fā)了 P01 這段子程序的執(zhí)行,導(dǎo)致了整個(gè)模擬過程的失敗。(該子程序是起飛前調(diào)試程序,執(zhí)行時(shí)會(huì)刪除現(xiàn)存的導(dǎo)航信息,如果在火箭飛行過程中執(zhí)行這段程序,計(jì)算機(jī)將無法繼續(xù)維持火箭航線,后果將是災(zāi)難性的。) 憑借著 SRE 的直覺, Margaret 為項(xiàng)目組提交了一個(gè)軟件改動(dòng),申請(qǐng)?jiān)陲w行程序中增加一項(xiàng)特殊狀態(tài)檢查,以避免飛行員在飛行過程中意外觸發(fā)P01 程序的執(zhí)行。但不幸的是,NASA 管理層認(rèn)為,這項(xiàng)錯(cuò)誤發(fā)生的可能性太小,根本不值得為此添加這項(xiàng)修改。于是Margaret 沒有能夠成功提交這項(xiàng)軟件修改。她只能在火箭飛行手冊(cè)中添加了一段文字,寫道:“在飛行過程中,請(qǐng)勿觸發(fā)P01 程序! (當(dāng)時(shí)增加這段文字時(shí),很多NASA 工程師都認(rèn)為這很好笑,認(rèn)為Margaret 是小題大做,幾乎所有人都認(rèn)為宇航員經(jīng)過如此長(zhǎng)時(shí)間的專業(yè)訓(xùn)練,是絕對(duì)不會(huì)犯如此低級(jí)的錯(cuò)誤的。) 幾天后,在Apollo 8 飛船執(zhí)行下一項(xiàng)飛行任務(wù)時(shí)。宇航員 Jim Lovell、William Anders和Frank Borman 三人執(zhí)行一個(gè)長(zhǎng)達(dá)四天的飛行計(jì)劃途中,Jim Lovell 意外地觸發(fā)了 P01程序的執(zhí)行。更巧的是,當(dāng)天正好是美國(guó)圣誕節(jié),大部分工程師都休假去了?上攵,當(dāng)時(shí)NASA 的一片混亂狀態(tài)。這次不是演習(xí),而是人命關(guān)天的危急時(shí)刻,如果不能及時(shí)解決,三名宇航員將永遠(yuǎn)無法安全返回了。所幸,當(dāng)時(shí) Margaret 的飛行手冊(cè)更新中恰恰提到了這種情形,并且提供了重新上傳數(shù)據(jù)以及恢復(fù)執(zhí)行的有效辦法,在有限的時(shí)間內(nèi)解決了問題,使任務(wù)可以繼續(xù)進(jìn)行。 Margaret 曾經(jīng)說過:“無論對(duì)一個(gè)軟件系統(tǒng)運(yùn)行原理掌握得多么徹底,也不能阻止人犯意外錯(cuò)誤。” 在這次危機(jī)過后,Margaret 之前提交的修改申請(qǐng)很快就被批準(zhǔn)了。 雖然Apollo 8 的事故發(fā)生在幾十年前,但是工程師們一定不會(huì)對(duì)此感到陌生, 類似的場(chǎng)景總是在不斷重演。希望讀者以史為鑒,只有靠著對(duì)細(xì)節(jié)的不懈關(guān)注,做好充足的災(zāi)難預(yù)案和準(zhǔn)備工作,時(shí)刻警惕著,不放過一切機(jī)會(huì)去避免災(zāi)難發(fā)生。這就是SRE zui重要的理念!歡迎加入SRE 的大家庭! 如何閱讀本書 這本書是由一系列短文組成的, 由Google SRE 成員和前成員共同寫就。相比之下,這本書更像是一本會(huì)議文集。本書的每一章都可以作為一個(gè)獨(dú)立部分進(jìn)行閱讀,但是讀者也可以根據(jù)自己的興趣選擇某些章節(jié)重點(diǎn)閱讀。(如果本書中引用了某些額外文章,你可以在參考文獻(xiàn)中找到。) 讀者可以按照任何順序閱讀本書,但是我們推薦從第2 章和第3 章開始。這兩章描述了Google 的生產(chǎn)運(yùn)行環(huán)境,以及SRE 是如何系統(tǒng)化認(rèn)知與量化“風(fēng)險(xiǎn)”的(畢竟 “風(fēng)險(xiǎn)” 是SRE zui關(guān)注的要點(diǎn))。讀者當(dāng)然也可以選擇逐章閱讀,本書邏輯上分為以下幾個(gè)部分:理念性介紹(第Ⅱ部分)、zui佳實(shí)踐(第Ⅲ部分)和管理經(jīng)驗(yàn)(第Ⅳ部分)。每一部分都配有簡(jiǎn)介,并且配有SRE 成員以前發(fā)表的文章的引用地址。 最后,本書配有網(wǎng)站https://g.co/SREBook,其中包括了一些有益讀物, 希望讀者能從中獲得閱讀的樂趣。 ……
Betsy Beyer,是Google 紐約負(fù)責(zé)SRE 的一名技術(shù)文檔作家。她之前曾為遍布全球的Google 數(shù)據(jù)中心與Mountain View 硬件運(yùn)維團(tuán)隊(duì)編寫文檔。在搬到紐約之前,Betsy 是Stanford 大學(xué)技術(shù)性寫作課程的講師。她曾經(jīng)學(xué)習(xí)國(guó)際關(guān)系與英文文學(xué),并在Stanford和Tulane 獲得學(xué)歷。
Chris Jones,是Google App Engine 的一名SRE。Google App Engine 是一個(gè)PaaS 服務(wù),每天處理超過280 億個(gè)請(qǐng)求。他的辦公室在舊金山,他之前的工作包括Google 廣告統(tǒng)計(jì)、數(shù)據(jù)倉(cāng)庫(kù),以及用戶支持系統(tǒng)的維護(hù)。在之前,Chris 曾經(jīng)在學(xué)校IT 行業(yè)任職,同時(shí)參與過競(jìng)選數(shù)據(jù)分析,以及一些BSD 內(nèi)核的修改。他有計(jì)算機(jī)工程、經(jīng)濟(jì)學(xué),以及技術(shù)政策學(xué)的學(xué)位。同時(shí)他也是一名有執(zhí)照的職業(yè)工程師。 Jennifer Petoff,是Google SRE 團(tuán)隊(duì)的一名項(xiàng)目經(jīng)理,工作地點(diǎn)在都柏林,愛爾蘭。她曾經(jīng)負(fù)責(zé)管理大型全球項(xiàng)目,包括:科學(xué)研究、工程、人力資源,以及廣告等。Jennifer在加入Google 之前,曾在化工行業(yè)任職八年。她獲得了Stanford 大學(xué)的化學(xué)博士與學(xué)士學(xué)位,同時(shí)她還擁有Rochester 大學(xué)的心理學(xué)學(xué)位。 Niall Murphy,是Google 愛爾蘭團(tuán)隊(duì)廣告SRE 的負(fù)責(zé)人。他擁有20 年互聯(lián)網(wǎng)行業(yè)經(jīng)驗(yàn),目前是INEX(愛爾蘭網(wǎng)絡(luò)互聯(lián)樞紐)的主席。他曾經(jīng)寫作以及參與寫作很多科技文章與書籍,包括O’Reilly 出版的IPv6 Network Administration,以及很多RFC。他目前在參與書寫愛爾蘭互聯(lián)網(wǎng)發(fā)展史。他擁有計(jì)算機(jī)科學(xué)、數(shù)學(xué),以及詩(shī)歌學(xué)的學(xué)歷(他當(dāng)時(shí)一定是想錯(cuò)了。K壳芭c妻子和兩個(gè)兒子居住在都柏林。 孫宇聰,前Google SRE(2007-2015),山景城總部,曾參與構(gòu)建運(yùn)維Youtube 全球CDN網(wǎng)絡(luò),2008年奧運(yùn)會(huì)直播項(xiàng)目,構(gòu)建維護(hù)海量視頻編碼傳輸系統(tǒng)。后參與Google內(nèi)部云平臺(tái)運(yùn)維工作,負(fù)責(zé)運(yùn)維全球百萬級(jí)別服務(wù)器集群,以及Borg、Omega等大規(guī)模集群理系統(tǒng)。2015年加入Coding,任CTO一職。回國(guó)后,積極推動(dòng)國(guó)內(nèi)容器化運(yùn)維架構(gòu)升級(jí)。目前是開放運(yùn)維聯(lián)盟之應(yīng)用運(yùn)維規(guī)范制定組,高可用運(yùn)維規(guī)范制定者。
前言 xxxi
序言 xxxv 第Ⅰ部分 概覽 第1 章 介紹 2 系統(tǒng)管理員模式 2 Google 的解決之道:SRE 4 SRE 方法論 6 確保長(zhǎng)期關(guān)注研發(fā)工作 6 在保障服務(wù)SLO 的前提下最大化迭代速度 7 監(jiān)控系統(tǒng) 8 應(yīng)急事件處理 8 變更管理 9 需求預(yù)測(cè)和容量規(guī)劃 9 資源部署 10 效率與性能 10 小結(jié) 10 第2 章 Google 生產(chǎn)環(huán)境:SRE 視角 11 硬件 11 管理物理服務(wù)器的系統(tǒng)管理軟件 13 管理物理服務(wù)器 13 存儲(chǔ) 14 網(wǎng)絡(luò) 15 其他系統(tǒng)軟件 16 分布式鎖服務(wù) 16 監(jiān)控與警報(bào)系統(tǒng) 16 軟件基礎(chǔ)設(shè)施 17 研發(fā)環(huán)境 17 莎士比亞搜索:一個(gè)示范服務(wù) 18 用戶請(qǐng)求的處理過程 18 任務(wù)和數(shù)據(jù)的組織方式 19 第Ⅱ部分 指導(dǎo)思想 第3 章 擁抱風(fēng)險(xiǎn) 23 管理風(fēng)險(xiǎn) 23 度量服務(wù)的風(fēng)險(xiǎn) 24 服務(wù)的風(fēng)險(xiǎn)容忍度 25 辨別消費(fèi)者服務(wù)的風(fēng)險(xiǎn)容忍度 26 基礎(chǔ)設(shè)施服務(wù)的風(fēng)險(xiǎn)容忍度 28 使用錯(cuò)誤預(yù)算的目的 30 錯(cuò)誤預(yù)算的構(gòu)建過程 31 好處 32 第4 章 服務(wù)質(zhì)量目標(biāo) 34 服務(wù)質(zhì)量術(shù)語 34 指標(biāo) 34 目標(biāo) 35 協(xié)議 36 指標(biāo)在實(shí)踐中的應(yīng)用 37 運(yùn)維人員和最終用戶各關(guān)心什么 37 指標(biāo)的收集 37 匯總 38 指標(biāo)的標(biāo)準(zhǔn)化 39 目標(biāo)在實(shí)踐中的應(yīng)用 39 目標(biāo)的定義 40 目標(biāo)的選擇 40 控制手段 42 SLO 可以建立用戶預(yù)期 42 協(xié)議在實(shí)踐中的應(yīng)用 43 第5 章 減少瑣事 44 瑣事的定義 44 為什么瑣事越少越好 45 什么算作工程工作 46 瑣事繁多是不是一定不好 47 小結(jié) 48 第6 章 分布式系統(tǒng)的監(jiān)控 49 術(shù)語定義 49 為什么要監(jiān)控 50 對(duì)監(jiān)控系統(tǒng)設(shè)置合理預(yù)期 51 現(xiàn)象與原因 52 黑盒監(jiān)控與白盒監(jiān)控 53 4 個(gè)黃金指標(biāo) 53 關(guān)于長(zhǎng)尾問題 54 度量指標(biāo)時(shí)采用合適的精度 55 簡(jiǎn)化,直到不能再簡(jiǎn)化 55 將上述理念整合起來 56 監(jiān)控系統(tǒng)的長(zhǎng)期維護(hù) 57 Bigtable SRE :警報(bào)過多的案例 57 Gmail :可預(yù)知的、可腳本化的人工干預(yù) 58 長(zhǎng)跑 59 小結(jié) 59 第7 章 Google 的自動(dòng)化系統(tǒng)的演進(jìn) 60 自動(dòng)化的價(jià)值 60 一致性 60 平臺(tái)性 61 修復(fù)速度更快 61 行動(dòng)速度更快 62 節(jié)省時(shí)間 62 自動(dòng)化對(duì)Google SRE 的價(jià)值 62 自動(dòng)化的應(yīng)用案例 63 Google SRE 的自動(dòng)化使用案例 63 自動(dòng)化分類的層次結(jié)構(gòu) 64 讓自己脫離工作:自動(dòng)化所有的東西 66 舒緩疼痛:將自動(dòng)化應(yīng)用到集群上線中 67 使用Prodtest 檢測(cè)不一致情況 68 冪等地解決不一致情況 69 專業(yè)化傾向 71 以服務(wù)為導(dǎo)向的集群上線流程 72 Borg :倉(cāng)庫(kù)規(guī)模計(jì)算機(jī)的誕生 73 可靠性是最基本的功能 74 建議 75 第8 章 發(fā)布工程 76 發(fā)布工程師的角色 76 發(fā)布工程哲學(xué) 77 自服務(wù)模型 77 追求速度 77 密閉性 77 強(qiáng)調(diào)策略和流程 78 持續(xù)構(gòu)建與部署 78 構(gòu)建 78 分支 79 測(cè)試 79 打包 79 Rapid 系統(tǒng) 80 部署 81 配置管理 81 小結(jié) 82 不僅僅只對(duì)Google 有用 83 一開始就進(jìn)行發(fā)布工程 83 第9 章 簡(jiǎn)單化 85 系統(tǒng)的穩(wěn)定性與靈活性 85 乏味是一種美德 86 我絕對(duì)不放棄我的代碼 86 “負(fù)代碼行”作為一個(gè)指標(biāo) 87 最小 API 87 模塊化 87 發(fā)布的簡(jiǎn)單化 88 小結(jié) 88 第Ⅲ部分 具體實(shí)踐 第10 章 基于時(shí)間序列數(shù)據(jù)進(jìn)行有效報(bào)警 93 Borgmon 的起源 94 應(yīng)用軟件的監(jiān)控埋點(diǎn) 95 監(jiān)控指標(biāo)的收集 96 時(shí)間序列數(shù)據(jù)的存儲(chǔ) 97 標(biāo)簽與向量 98 Borg 規(guī)則計(jì)算 99 報(bào)警 104 監(jiān)控系統(tǒng)的分片機(jī)制 105 黑盒監(jiān)控 106 配置文件的維護(hù) 106 十年之后 108 第11 章 on-call 輪值 109 介紹 109 on-call 工程師的一天 110 on-call 工作平衡 111 數(shù)量上保持平衡 111 質(zhì)量上保持平衡 111 補(bǔ)貼措施 112 安全感 112 避免運(yùn)維壓力過大 114 運(yùn)維壓力過大 114 奸詐的敵人—運(yùn)維壓力不夠 115 小結(jié) 115 第12 章 有效的故障排查手段 116 理論 117 實(shí)踐 119 故障報(bào)告 119 定位 119 檢查 120 診斷 122 測(cè)試和修復(fù) 124 神奇的負(fù)面結(jié)果 125 治愈 126 案例分析 127 使故障排查更簡(jiǎn)單 130 小結(jié) 130 第13 章 緊急事件響應(yīng) 131 當(dāng)系統(tǒng)出現(xiàn)問題時(shí)怎么辦 131 測(cè)試導(dǎo)致的緊急事故 132 細(xì)節(jié) 132 響應(yīng) 132 事后總結(jié) 132 變更部署帶來的緊急事故 133 細(xì)節(jié) 133 事故響應(yīng) 134 事后總結(jié) 134 流程導(dǎo)致的嚴(yán)重事故 135 細(xì)節(jié) 135 災(zāi)難響應(yīng) 136 事后總結(jié) 136 所有的問題都有解決方案 137 向過去學(xué)習(xí),而不是重復(fù)它 138 為事故保留記錄 138 提出那些大的,甚至不可能的問題:假如…… 138 鼓勵(lì)主動(dòng)測(cè)試 138 小結(jié) 138 第14 章 緊急事故管理 140 無流程管理的緊急事故 140 對(duì)這次無流程管理的事故的剖析 141 過于關(guān)注技術(shù)問題 141 溝通不暢 141 不請(qǐng)自來 142 緊急事故的流程管理要素 142 嵌套式職責(zé)分離 142 控制中心 143 實(shí)時(shí)事故狀態(tài)文檔 143 明確公開的職責(zé)交接 143 一次流程管理良好的事故 144 什么時(shí)候?qū)ν庑际鹿省?144 小結(jié) 145 第15 章 事后總結(jié):從失敗中學(xué)習(xí) 146 Google 的事后總結(jié)哲學(xué) 146 協(xié)作和知識(shí)共享 148 建立事后總結(jié)文化 149 小結(jié)以及不斷優(yōu)化 151 第16 章 跟蹤故障 152 Escalator 152 Outalator 153 聚合 154 加標(biāo)簽 155 分析 155 未預(yù)料到的好處 156 第17 章 測(cè)試可靠性 157 軟件測(cè)試的類型 158 傳統(tǒng)測(cè)試 159 生產(chǎn)測(cè)試 160 創(chuàng)造一個(gè)構(gòu)建和測(cè)試環(huán)境 163 大規(guī)模測(cè)試 165 測(cè)試大規(guī)模使用的工具 166 針對(duì)災(zāi)難的測(cè)試 167 對(duì)速度的渴求 168 發(fā)布到生產(chǎn)環(huán)境 170 允許測(cè)試失敗 170 集成 172 生產(chǎn)環(huán)境探針 173 小結(jié) 175 第18 章 SRE 部門中的軟件工程實(shí)踐 176 為什么軟件工程項(xiàng)目對(duì)SRE 很重要 176 Auxon 案例分析:項(xiàng)目背景和要解決的問題 177 傳統(tǒng)的容量規(guī)劃方法 177 解決方案:基于意圖的容量規(guī)劃 179 基于意圖的容量規(guī)劃 180 表達(dá)產(chǎn)品意圖的先導(dǎo)條件 181 Auxon 簡(jiǎn)介 182 需求和實(shí)現(xiàn):成功和不足 183 提升了解程度,推進(jìn)采用率 185 團(tuán)隊(duì)內(nèi)部組成 187 在SRE 團(tuán)隊(duì)中培養(yǎng)軟件工程風(fēng)氣 187 在SRE 團(tuán)隊(duì)中建立起軟件工程氛圍:招聘與開發(fā)時(shí)間 188 做到這一點(diǎn) 189 小結(jié) 190 第19 章 前端服務(wù)器的負(fù)載均衡 191 有時(shí)候硬件并不能解決問題 191 使用DNS 進(jìn)行負(fù)載均衡 192 負(fù)載均衡:虛擬IP 194 第20 章 數(shù)據(jù)中心內(nèi)部的負(fù)載均衡系統(tǒng) 197 理想情況 198 識(shí)別異常任務(wù):流速控制和跛腳鴨任務(wù) 199 異常任務(wù)的簡(jiǎn)單應(yīng)對(duì)辦法:流速控制 199 一個(gè)可靠的識(shí)別異常任務(wù)的方法:跛腳鴨狀態(tài) 200 利用劃分子集限制連接池大小 201 選擇合適的子集 201 子集選擇算法一:隨機(jī)選擇 202 子集選擇算法二:確定性算法 204 負(fù)載均衡策略 206 簡(jiǎn)單輪詢算法 206 最閑輪詢策略 209 加權(quán)輪詢策略 210 第21 章 應(yīng)對(duì)過載 212 QPS 陷阱 213 給每個(gè)用戶設(shè)置限制 213 客戶端側(cè)的節(jié)流機(jī)制 214 重要性 216 資源利用率信號(hào) 217 處理過載錯(cuò)誤 217 決定何時(shí)重試 218 連接造成的負(fù)載 220 小結(jié) 221 第22 章 處理連鎖故障 223 連鎖故障產(chǎn)生的原因和如何從設(shè)計(jì)上避免 224 服務(wù)器過載 224 資源耗盡 225 服務(wù)不可用 228 防止軟件服務(wù)器過載 228 隊(duì)列管理 229 流量拋棄和優(yōu)雅降級(jí) 230 重試 231 請(qǐng)求延遲和截止時(shí)間 234 慢啟動(dòng)和冷緩存 236 保持調(diào)用棧永遠(yuǎn)向下 238 連鎖故障的觸發(fā)條件 238 進(jìn)程崩潰 239 進(jìn)程更新 239 新的發(fā)布 239 自然增長(zhǎng) 239 計(jì)劃中或計(jì)劃外的不可用 239 連鎖故障的測(cè)試 240 測(cè)試直到出現(xiàn)故障,還要繼續(xù)測(cè)試 240 測(cè)試最常用的客戶端 241 測(cè)試非關(guān)鍵性后端 242 解決連鎖故障的立即步驟 242 增加資源 242 停止健康檢查導(dǎo)致的任務(wù)死亡 242 重啟軟件服務(wù)器 242 丟棄流量 243 進(jìn)入降級(jí)模式 243 消除批處理負(fù)載 244 消除有害的流量 244 小結(jié) 244 第23 章 管理關(guān)鍵狀態(tài):利用分布式共識(shí)來提高可靠性 246 使用共識(shí)系統(tǒng)的動(dòng)力:分布式系統(tǒng)協(xié)調(diào)失敗 248 案例1 :腦裂問題 249 案例2 :需要人工干預(yù)的災(zāi)備切換 249 案例3 :有問題的小組成員算法 249 分布式共識(shí)是如何工作的 250 Paxos 概要:協(xié)議示例 251 分布式共識(shí)的系統(tǒng)架構(gòu)模式 251 可靠的復(fù)制狀態(tài)機(jī) 252 可靠的復(fù)制數(shù)據(jù)存儲(chǔ)和配置存儲(chǔ) 252 使用領(lǐng)頭人選舉機(jī)制實(shí)現(xiàn)高可用的處理系統(tǒng) 253 分布式協(xié)調(diào)和鎖服務(wù) 253 可靠的分布式隊(duì)列和消息傳遞 254 分布式共識(shí)系統(tǒng)的性能問題 255 復(fù)合式Paxos :消息流過程詳解 257 應(yīng)對(duì)大量的讀操作 258 法定租約 259 分布式共識(shí)系統(tǒng)的性能與網(wǎng)絡(luò)延遲 259 快速Paxos 協(xié)議:性能優(yōu)化 260 穩(wěn)定的領(lǐng)頭人機(jī)制 261 批處理 262 磁盤訪問 262 分布式共識(shí)系統(tǒng)的部署 263 副本的數(shù)量 263 副本的位置 265 容量規(guī)劃和負(fù)載均衡 266 對(duì)分布式共識(shí)系統(tǒng)的監(jiān)控 270 小結(jié) 272 第24 章 分布式周期性任務(wù)系統(tǒng) 273 Cron 273 介紹 273 可靠性 274 Cron 任務(wù)和冪等性 274 大規(guī)模Cron 系統(tǒng) 275 對(duì)基礎(chǔ)設(shè)施的擴(kuò)展 275 對(duì)需求的擴(kuò)展 276 Google Cron 系統(tǒng)的構(gòu)建過程 277 跟蹤C(jī)ron 任務(wù)的狀態(tài) 277 Paxos 協(xié)議的使用 277 領(lǐng)頭人角色和追隨者角色 278 保存狀態(tài) 281 運(yùn)維大型Cron 系統(tǒng) 282 小結(jié) 283 第25 章 數(shù)據(jù)處理流水線 284 流水線設(shè)計(jì)模式的起源 284 簡(jiǎn)單流水線設(shè)計(jì)模式與大數(shù)據(jù) 284 周期性流水線模式的挑戰(zhàn) 285 工作分發(fā)不均造成的問題 285 分布式環(huán)境中周期性數(shù)據(jù)流水線的缺點(diǎn) 286 監(jiān)控周期性流水線的問題 287 驚群效應(yīng) 287 摩爾負(fù)載模式 288 Google Workflow 簡(jiǎn)介 289 Workflow 是模型—視圖—控制器(MVC)模式 290 Workflow 中的執(zhí)行階段 291 Workflow 正確性保障 291 保障業(yè)務(wù)的持續(xù)性 292 小結(jié) 294 第26 章 數(shù)據(jù)完整性:讀寫一致 295 …… 第27 章 可靠地進(jìn)行產(chǎn)品的大規(guī)模發(fā)布 322 …… 第Ⅳ部分 管理 第28 章 迅速培養(yǎng)SRE 加入on-call 341 …… 第29 章 處理中斷性任務(wù) 355 …… 第30 章 通過嵌入SRE 的方式幫助團(tuán)隊(duì)從運(yùn)維過載中恢復(fù) 363 …… 第 31 章 SRE 與其他團(tuán)隊(duì)的溝通與協(xié)作 370 …… 第32 章 SRE 參與模式的演進(jìn)歷程 383 …… 第Ⅴ部分 結(jié)束語 第33 章 其他行業(yè)的實(shí)踐經(jīng)驗(yàn) 398 …… 第34 章 結(jié)語 408 附錄A 系統(tǒng)可用性 411 附錄B 生產(chǎn)環(huán)境運(yùn)維過程中的最佳實(shí)踐 412 附錄C 事故狀態(tài)文檔示范 417 附錄D 事后總結(jié)示范 419 附錄E 發(fā)布協(xié)調(diào)檢查列表 423 附錄F 生產(chǎn)環(huán)境會(huì)議記錄示范 425 參考文獻(xiàn) 427 索引 439
譯者序
當(dāng)我在2016 年年初聽說本書的英文版即將面世時(shí),第一時(shí)間就意識(shí)到這將是一本不可多得的經(jīng)典之作。我作為Google SRE 曾經(jīng)的一員,看到本書中提到的那些熟悉的技術(shù)和理念時(shí)非常興奮——現(xiàn)在終于有機(jī)會(huì)用一種體系化、結(jié)構(gòu)化的方式將這些知識(shí)和技術(shù)與大家分享了! Google SRE 全球共計(jì)約1000 人,負(fù)責(zé)運(yùn)維Google 的大部分家喻戶曉、不可或缺的商業(yè)應(yīng)用。同時(shí),SRE 還負(fù)責(zé)運(yùn)維幕后那些全球首屈一指的計(jì)算基礎(chǔ)設(shè)施,不管是全球百萬臺(tái)級(jí)別的服務(wù)器集群,還是全球一流的網(wǎng)絡(luò)架構(gòu),背后都有SRE 的身影。每個(gè)小的傳統(tǒng)運(yùn)維問題在這個(gè)平臺(tái)上似乎都被無限放大了。但是與此同時(shí),Google 恰恰又是利用最傳統(tǒng)、最樸素的軟件工程方法將其一一解決的。 SRE 是一群天生的懷疑論者,我們懷疑一切宣傳起來“高大上”的技術(shù),以及任何“神奇”的產(chǎn)品——我們只想看具體的設(shè)計(jì)架構(gòu)、實(shí)現(xiàn)細(xì)節(jié),以及真實(shí)的監(jiān)控圖表。SRE 在保障系統(tǒng)可靠性方面并沒有什么萬能藥,有的只是這種極強(qiáng)的務(wù)實(shí)態(tài)度(pragmatic)。這種務(wù)實(shí)的態(tài)度決定了SRE 會(huì)認(rèn)真對(duì)待運(yùn)維問題。在設(shè)計(jì)評(píng)審中,他們會(huì)認(rèn)真推演各種災(zāi)難場(chǎng)景。在每周例會(huì)時(shí),他們又會(huì)討論如何消除和防范事故發(fā)生、優(yōu)化各種警報(bào)策略以及增強(qiáng)自動(dòng)化功能。在平時(shí)工作中,他們則會(huì)精心維護(hù)團(tuán)隊(duì)的各種文檔和項(xiàng)目源代碼,一點(diǎn)一點(diǎn)地提高服務(wù)質(zhì)量;仡^看來,SRE 其實(shí)是一群崇尚工匠主義的人,我們堅(jiān)信只要不斷地解決根源問題,服務(wù)質(zhì)量就一定會(huì)得到提升。而SRE 正是用這種“日拱一卒”的方法造就了Google 這個(gè)世界級(jí)的奇跡。 本書的風(fēng)格亦是如此。書中很多章節(jié)用務(wù)實(shí)的語言記錄了Google SRE 團(tuán)隊(duì)在面臨各種困難時(shí)的思考過程、所采用的解決方案以及事后總結(jié)的經(jīng)驗(yàn)教訓(xùn)。本書中沒有介紹任何“魔法系統(tǒng)”,也沒有提供任何“奇技淫巧”,有的只是對(duì)問題本質(zhì)發(fā)人深省的深入探討。從這種意義上講,本書體系化地覆蓋了運(yùn)維工作的方方面面,是一本運(yùn)維行業(yè)的教科書。我希望通過翻譯此書,能將這種體系和理念分享給更多的人。期待與大家更深入地探討與交流! 回首在Google 度過的8 年時(shí)光,我想感謝我所有的前同事,感謝他們對(duì)我的各種幫助,這段職業(yè)經(jīng)歷是我終生難忘的。而且,我還要感謝我的家人,是他們的耐心陪伴和幫助才讓我踏踏實(shí)實(shí)地度過了這200 多個(gè)小時(shí),完成了我人生中最大的一個(gè)Project。 孫宇聰 2016 年8 月3 日 傍晚
你還可能感興趣
我要評(píng)論
|