2016年4月14-15日，由51CTO傳媒主辦的WOT2016互聯(lián)網(wǎng)運維與開發(fā)者大會在北京珠三角JW萬豪酒店召開。秉承專注技術(shù)、服務(wù)技術(shù) 人員的理念，自2012年以來，WOT品牌大會已經(jīng)成功舉辦了八屆，積累了大量的技術(shù)專家資源，獲得了廣大IT從業(yè)者和技術(shù)愛好者的一致認可，成為了業(yè)界重要 的技術(shù)分享交流平臺以及人脈拓展平臺。

本次會議分為11個技術(shù)主題，分別是：數(shù)據(jù)庫技術(shù)與應(yīng)用，大數(shù)據(jù)與運維，云計算與運維，運維安全，移動運維，容器體系構(gòu)建與實踐，運維自動化，行業(yè)運維、監(jiān)控與性能優(yōu)化、高可用架構(gòu)和分布式存儲技術(shù)。51CTO作為本次大會的主辦方，將以快速報道、現(xiàn)場專訪與后期視頻等形式展示這場盛宴。

下面是來自Google工程團隊帶頭人李聰先生給大家?guī)淼氖侵黝}為《運維理念與實踐》的精彩演講。

李聰，在Google從業(yè)七年多，帶領(lǐng)開發(fā)和維護過多個項目，包括前端、后端、線下作業(yè)等。

【以下為現(xiàn)場演講實錄】

大家好，我叫李聰。我自我介紹一下，我工作大概七八年了，主要以開發(fā)為主。運維也做過一些，跟最前面的幾位不是特別像，但是我今天給大家?guī)淼膬?nèi)容，大家會發(fā)現(xiàn)為什么我做以開發(fā)為主的，也可以給大家?guī)硪恍┓窒恚康纫幌陆o大家介紹。

我的內(nèi)容跟前面有些不一樣，這里面基本上不需要大家花錢，所以盡情的聽下去。我?guī)淼闹黝}就是運維的理念與實踐，主要是比較適合于內(nèi)部使用。只有一個目標(biāo)，就是99.9999%。我相信在座大部分都是運維方面的專家，對這個比較熟悉了，我們在做服務(wù)的穩(wěn)定性的時候，最主要談服務(wù)級別協(xié)議叫SLA。如果說最重要的一個互聯(lián)網(wǎng)指標(biāo)，就是它的可用性有多少，我們把它劃為6個級別，第一個級別最低是1個9，它的意思概念化可服務(wù)時間是在90%以上，不可服務(wù)時間是在10%以下，如果說這個服務(wù)能達到1個9以上，它就意味著說你宕機時間保持在36.5天以下，這是很差的服務(wù)了，不過事實證明，即使到今天還是有。比如說有一些買火車票的網(wǎng)站，頁面一般都用不了，我覺得可能到不了一個9。

每增加一個9，就相當(dāng)于它的可用性，宕機時間縮到上一級的10%。一般比較重要一點的服務(wù)都要到4個9、5個9、6個9，對于重要的服務(wù)，我們都是要到6個9的指標(biāo)，年宕機時間在31.5秒以下。在線時間比較容易理解，用戶可以正常使用的時間，宕機時間可能就比較復(fù)雜一點，并不是說用戶發(fā)個請求，發(fā)現(xiàn)服務(wù)端有錯誤了，這才叫宕機，這不一定的。比如說我要去打開我的一個Email，本身是幾秒鐘事情，如果搞到10分鐘，這樣就可以把它裁定為宕機了。

我現(xiàn)在給大家回顧一下歷史，我們的目標(biāo)很簡單，就是要達到6個9。我們是怎么實現(xiàn)的？如果運維不能讓我重新來一次，我應(yīng)該怎么做？我就要回顧一下歷史。首先看一下我們軟件發(fā)展起來是在80年代的時候，那個時候，我們開發(fā)流程都還是用瀑布模型，從需求、分析到設(shè)計，到開發(fā)測試，最后到發(fā)布這樣一個過程，比較老的一種開發(fā)流程了。這里面有一個比較明顯的地方，在開發(fā)流程里面，前面設(shè)計一直到測試完成，在發(fā)布之前都是在一個團體，或者說一個公司內(nèi)完成的，但是當(dāng)?shù)桨l(fā)布的時候，還是通過比如說光盤這種形式來發(fā)布給客戶，這種客戶包括客戶公司，甚至說個人之類的，在這種情況下，產(chǎn)品的開發(fā)整個流程到后面的運營是完全分開的，整個開發(fā)測試設(shè)計的過程，在軟件開發(fā)公司，運營運維就是在客戶公司部分，這兩個是完全脫節(jié)的。在80年代早期，還沒有漏洞這樣的一種說法。舉個例子，以前有顧客向軟件開發(fā)公司反映說他們的產(chǎn)品有問題，結(jié)果反過來被軟件開發(fā)公司給告了，說他們這是誹謗，告他們誹謗罪，在今天看來，這是一件很可笑的事情。發(fā)布周期一般少則幾個月，多則一兩年，甚至三年，那時候沒有特別激烈的競爭。在那個年代做的開發(fā)是一件很爽的事情，今天的開發(fā)者不可以想象那時候有多爽。

那個時候軟件大部分是在2個9以下，一般都是達到1個9。這里面有一個例子Windows，90年代的時候，Web軟件開始出現(xiàn)了，Web軟件出現(xiàn)，開發(fā)流程依然沒有很大的變化，還是以瀑布開發(fā)的流程為主的，但是因為它是一個Web軟件，開發(fā)與運維不是完全脫節(jié)的。我本來說是在同一個公司內(nèi)部的，我做軟件開發(fā)，我做維護給客戶來使用，那時候出現(xiàn)了很多軟件。在軟件開發(fā)公司，一般出現(xiàn)了Ops這樣一個組來提供這樣一個支持，不過這個時候，他仍然是兩個獨立的小團體在公司內(nèi)部，這時候發(fā)布周期加快了，一般可以幾個月發(fā)布一次，到一年的樣子。即使到這個時候，做軟件開發(fā)還是一件比較舒服的事情，因為很多的工作壓力，很多的運營的壓力都是在運維，開發(fā)者相對來說還是比較輕松。在這個時候，很多服務(wù)是可以達到2個9的樣子。

即使到這個時候，我不知道大家有沒有印象，如果說你在辦公室里面用一臺Windows電腦，有另外一個人走進來開了一下燈，或者關(guān)了一下燈，你這個機器可能就宕掉了。到了00年代的時候，軟件行業(yè)發(fā)生了翻天覆地的變化，包括從90年代后期瀏覽器的競爭，非服務(wù)的節(jié)點更加穩(wěn)定。就像路由器更加穩(wěn)定，如果說服務(wù)出了問題，在這之前，往往大家可能會檢查一下網(wǎng)絡(luò)有沒有連接，到這個時候，大家比如說上不了網(wǎng)，他可能會到另外一個社群網(wǎng)站看一下這個服務(wù)到底有沒有問題。

發(fā)布更加重要。因為競爭過于激烈，導(dǎo)致了所有的軟件公司壓力都非常大，他們就要不停的去發(fā)布，生產(chǎn)一些新的產(chǎn)品來吸引用戶，讓用戶滿意度更強。同時可靠性也增加了，后面我會解釋一下為什么。到00年代的時候，競爭加劇了，產(chǎn)品發(fā)布周期變短，產(chǎn)品發(fā)布壓力變大，這個時候開發(fā)與運維的矛盾也凸顯。你不停發(fā)布新的產(chǎn)品，往往就導(dǎo)致了這個產(chǎn)品不穩(wěn)定性增加，這肯定不是運營商希望的樣子，它希望這個產(chǎn)品更加穩(wěn)定，開發(fā)者希望發(fā)布發(fā)布、再發(fā)布，我要一直發(fā)布下去，運營商就希望一直穩(wěn)定下去，所以說這兩個角色之間是一種格斗的場景。這時候就出現(xiàn)DevOps這樣一個概念，DevOps是一種概念、理論與手段，來促進開發(fā)與運營之間更好的合作。

魚與熊掌是不是可以兼得？我們怎么樣去做？我們看一下怎么做的。

首先有人說堆人可以做到，我只要有錢，招更多的工程師，招更多的包括開發(fā)運營的工程師，這是絕對不可能的。如果你靠堆人，最多也就做到3個9到4個9，基本上就不大可能了。成套技術(shù)也是不可能的，無論這個公司技術(shù)有多強，都不可能達到6個9的級別，5個9都很難。這時候就出現(xiàn)了這兩個團隊之間的矛盾，運營就說想盡各種各樣的辦法來拖慢發(fā)布的速度，開發(fā)者就想盡各種辦法來加快發(fā)布速度。比如說運營的人說我下個月要休假，這個月就開始不要發(fā)布了，你就等一等好不好，如果你要發(fā)布的時候，我要增加你審查的流程和審查的深度，但是另外一方面開發(fā)者就會想各種辦法，比如說我這個只是波及到5%的用戶沒有關(guān)系的，或者我只改一個UI，做一個很小的改動，雙方就扯皮起來。我們怎么樣徹底的解決這種問題？我們引入了一個概念叫做SRE，這樣一個角色，跟傳統(tǒng)的運維，甚至說今天很多公司運維的概念完全不一樣。SRE的工作要來保證產(chǎn)品穩(wěn)定性，這個并不完全是他的責(zé)任。他跟開發(fā)者有一個共同目標(biāo)，開發(fā)者也要有責(zé)任保證產(chǎn)品穩(wěn)定性。

怎么做到？大概從四個方面做到，我敢說是缺一不可，只要有一個環(huán)節(jié)出了問題，都不可能做到。

第一個就是工程方法，做軟件開發(fā)與發(fā)布、運營的工程方法；第二個就是組織架構(gòu)，可能聽起來有點奇怪，組織架構(gòu)為什么會影響到產(chǎn)品的穩(wěn)定性，或者說高可用性；再就是管理理念，最后是技術(shù)支持，當(dāng)然技術(shù)支持并不是說它是最不重要的，這四個都非常重要，都是關(guān)鍵的因素。

我們先看一下工程方法。我們把服務(wù)劃為兩類，一類是自運營的服務(wù)，這個服務(wù)只有開發(fā)者去開發(fā)，再加上開發(fā)者去運行，沒有SRE的直接參與。當(dāng)然還是可以得到SRE的間接支持的，但是沒有SRE的直接支持，這種服務(wù)不是我們講的重點，這種服務(wù)一般達不了6個9，5個9就已經(jīng)不錯了。得到SRE運營直接支持的服務(wù)，這種服務(wù)我們是有要求的，不是說所有的服務(wù)，想達到6個9，你就跟我SRE一起配套工作。

我們這個服務(wù)的要求有幾個方面，比如說對SRE的負擔(dān)要小，不能讓SRE花很多精力在運營上面，基本上可以解釋為這個產(chǎn)品要足夠好，才會得到SRE的直接支持。

另外這個服務(wù)是要非常重要，比如說6個9還好，如果到5個9，這個產(chǎn)品一年比如說可以損失10億美元，類似于這樣的情況。還有一個有一種法律的要求，這個就沒有辦法了，如果有法律要求一定要配備SRE的。最后就是說有沒有SRE可以供池使用，SRE的資源池有限，我們SRE的數(shù)量非常少，相比開發(fā)者來說。我們通過錯誤預(yù)算來做，即使是SRE直接支持運營的服務(wù)，前期也是至少有6個月開發(fā)者自運營的過程，就是說前面6個月，SRE不會直接參與來支持這樣一個項目。這個服務(wù)自運營6個月以上以后，通過SRE的審查以后，SRE就可以去做直接的支持，當(dāng)然這支持以后，就會產(chǎn)生一個很快的迭代的過程。比如說每一天發(fā)布，比較快的是每天發(fā)布，如果說在發(fā)布過程中出現(xiàn)了很大的問題，SRE有可能會退出這個團隊，說你這個服務(wù)不行，我們要把你交回去，仍然由開發(fā)者自己去負責(zé)。錯誤預(yù)算，剛才簡單提了一下。我們首先要有一個概念，就是說影響產(chǎn)品不穩(wěn)定的最重要的因素是什么？我相信大家可能都知道，影響產(chǎn)品不穩(wěn)定性最重要的因素就是一個產(chǎn)品發(fā)布的過程，如果這個產(chǎn)品沒有新的迭代，可能運行了幾周、幾個月，甚至于說一年、兩年，根本不會出現(xiàn)很緊急的問題，一旦迭代發(fā)布，問題往往就出現(xiàn)了。我們引入的概念叫做錯誤預(yù)算，什么概念？概念化1減去SLA。

我們實際應(yīng)用過程中，是按季度結(jié)算的，一個季度的預(yù)算沒有用完，是不能到下一個季度的，如果用完了，這個季度，我們不會允許你再做一次新的發(fā)布，是這樣的。如果你這個預(yù)算用完了就要凍結(jié)，凍結(jié)的話，就是說你就不可以再做新的發(fā)布，到下一個季度可以繼續(xù)開支。因為我們通過數(shù)字來說話，完全有一個簡單目標(biāo)SLA，簡單的一個數(shù)字，這里面不涉及到政治斗爭的過程，不是說老板說了這個東西太重要了，還要發(fā)布，但是你的預(yù)算如果用完了，你不能發(fā)布，就跟社會現(xiàn)實中的法律是一樣的。這樣看起來就是一個共同的目標(biāo)，我們一個季度比如說只有0.001%的錯誤預(yù)算，從SRE角度來說，肯定希望這個產(chǎn)品越多越好。開發(fā)者角度來說，希望這個季度結(jié)束以前，一定不能用完0.001%的錯誤預(yù)算，一旦用完了，后面在這個季度之內(nèi)，再也沒有辦法發(fā)布新的產(chǎn)品了。

比如說我們的SLA是4個9，可用錯誤預(yù)算是0.01，如果說一個季度過去兩個月了，已經(jīng)用了0.003，還剩下0.007，這個還沒有什么擔(dān)心，因為距離錯誤預(yù)算用完還有很長距離。但是如果說已經(jīng)用了0.008，只剩下0.002了，如果沒有這樣一個很好的機制，放到一般的開發(fā)與運營的兩種角色關(guān)系來說，開發(fā)者肯定說我這個產(chǎn)品很重要，我一定要發(fā)布，但是這個時候，在我們的研發(fā)完全不一樣了，因為開發(fā)者會衡量一下，我只剩下0.002%了，如果這個發(fā)布再出現(xiàn)了問題，我可能下面剩下的這一個月，我再也沒有機會發(fā)布新的產(chǎn)品了，責(zé)任就是從傳統(tǒng)的運營的角度，就轉(zhuǎn)化到了開發(fā)者的角度。

作為一個運營人員，他沒有辦法證明你這個新的產(chǎn)品到底有多危險、到底有多安全，但是作為開發(fā)者，你有責(zé)任去衡量這個東西來使用。下一個工程方法。我這是從一個新的產(chǎn)品發(fā)布開始的，第一步比如說產(chǎn)品需求出來了、開發(fā)出來了，正在開發(fā)測試，開始內(nèi)部上線了，內(nèi)部上線一段時間以后，要做可不可以上線的審查，這個審查純粹是SRE在幫產(chǎn)品團隊做的一個審查，這不算是SRE直接的一個參與，他們在審查過程中，因為他們的運營經(jīng)驗比較豐富，審查過程中發(fā)現(xiàn)有什么問題，他會讓你改正提高。縱坐標(biāo)是穩(wěn)定性，橫坐標(biāo)是時間軸，當(dāng)通過了以后，到T0時間，就會開始發(fā)布，發(fā)布時間開始，外部用戶就已經(jīng)可以看到產(chǎn)品了。這個時候我想說一下，比如說我們的目標(biāo)是6個9，這個時候只能達到5個9或者4個9，雖然外面用戶已經(jīng)看到了，但是處于自運營的狀態(tài)，開發(fā)者自己去維護。這個過程中，開發(fā)者會不斷的增加產(chǎn)品的穩(wěn)定性，這個時候新的產(chǎn)品不是最重要的，要增加穩(wěn)定性，因為他們要把這個產(chǎn)品在現(xiàn)實生產(chǎn)環(huán)境中做得更好，可以通過SRE的審查，然后可以把運營這一部分交接到SRE那邊去。比如說到6個月的時候，這個產(chǎn)品的主要目的是說要把這個產(chǎn)品交到SRE去運營，主要就是有什么緊急狀況，就會尋呼SRE。這個時候如果達到6個9，一切審查內(nèi)容都過了，這個時候SRE就會正式介入，來支持這樣一個日常的運營工作。

我后面講一下這個審查的例子有哪些內(nèi)容，這是一個反交接的過程。比如說前面那部分一直是SRE在支持運營，結(jié)果突然有一段時間，出現(xiàn)問題太多了，穩(wěn)定性急劇下降，也很難以改善，SRE就有權(quán)利提出來反交接，反交接就是說產(chǎn)品回歸到開發(fā)者去運營，我們就不管了，就是這樣的意思。剛才講的審查內(nèi)容有哪些。比較重要的就是監(jiān)視系統(tǒng)，監(jiān)測你產(chǎn)品的健康程度，比如說你的內(nèi)存、用量，什么CPU，像什么延遲之類的一系列的東西。還有儀表盤，不是用來發(fā)尋呼的，大家肉眼主動監(jiān)測去觀看的，比如說可以看到過去6個月或者8個月這個延遲的變化是多少。比如說上個月延遲0.001秒，現(xiàn)在變成0.002秒這是怎么回事，類似這樣。SRE審查事件發(fā)生頻率與類型，過去6個月自運營過程中，出現(xiàn)了哪些事故，這些事故有多嚴(yán)重，屬于哪些類型的，過后是怎樣修復(fù)的。有兩方面作用，一方面幫助SRE了解這個產(chǎn)品的健康程度，為他們以后運營做一個鋪墊。另外一方面也是考核這個產(chǎn)品在過去6個月當(dāng)中，到底有沒有什么重要的問題，你是怎么樣修復(fù)的，最后是怎么樣解決的。

還有一個審查叫做系統(tǒng)架構(gòu)，他們會衡量一下這個系統(tǒng)架構(gòu)是不是合理。還有一個就是發(fā)布的過程，過去6個月，你這個發(fā)布是怎樣發(fā)布的，發(fā)布的頻率是多少類似于這種，同時還會有一些Bug，比如說測試Bug、用戶反饋Bug這樣一種。

再下面講的是組織架構(gòu)。剛才講的是工程方法，前面一系列工程方法是保證6個9的條件。組織架構(gòu)也是一個，它比較簡單，就只有一頁PPT。一種是左邊這種，開發(fā)與SRE，同時給一個產(chǎn)品主條上去，另外一個就是到上面經(jīng)理，再到上面經(jīng)理，最后到總經(jīng)理。SRE給他的經(jīng)理，再到上面的經(jīng)理，再到總經(jīng)理，我們選擇哪個總呢？很顯然應(yīng)該選擇第二種。第一個給最底層的經(jīng)理，他的權(quán)限太大了。比如說他會認為這個新的產(chǎn)品非常重要，我要把它給發(fā)布出去，SRE基本上就沒有什么辦法了。但是第二種組織架構(gòu)下面，經(jīng)理1和經(jīng)理2說話都不算，他們會堅守方法論，如果你錯誤預(yù)算到達了，你就不能發(fā)布了，這個是可以保證的。組織架構(gòu)同時涉及到管理理念，最高級別就是剛才那個經(jīng)理3，他一定要支持我們所做的這樣一種錯誤預(yù)算的方法論，如果錯誤預(yù)算用完了，你一定不能發(fā)布，他必須支持這個東西。包括到下面的經(jīng)理、工程師或者SRE都必須要理解，也要去執(zhí)行，我們做得比較好的最終是數(shù)字為王，一定按數(shù)字說話，這樣也不會傷同事之間的和氣。

我總結(jié)一下前面講的非技術(shù)方面的知識，通過非技術(shù)的手段，怎么樣打造很高的SRE的。SRE與運營商之間要有共同的目標(biāo)，他們都是希望產(chǎn)品穩(wěn)定，有共同利益和共同的手段，大家一起做。根據(jù)經(jīng)驗就是說每個產(chǎn)品越早與SRE合作，整個后面的過程就會越順利，我的經(jīng)驗就是說在我們需求分析有了以后，在做產(chǎn)品架構(gòu)的時候，就去跟SRE合作，這樣會比較好。

下面講的就是技術(shù)支持這一塊，光有這些非技術(shù)的功能方法、管理理念、組織架構(gòu)還是不夠的，我們要有足夠的技術(shù)支持。從SRE的角度來說，他們不是特別熟悉產(chǎn)品的代碼，因為像產(chǎn)品開發(fā)，他們每天好多小時，每周好幾天都泡在代碼里面，但是SRE是從另外一個角度來考慮這個問題，他并沒有很熟悉，但是他們要有很強的技術(shù)能力，他不熟悉產(chǎn)品本身沒有關(guān)系，但是他有很強的技術(shù)能力。

我們的SRE基本上都有一定的開發(fā)背景，大概一半一半，要有運營的能力，即使之前沒有進來以后，我們也是做一個類似于50%、50%的細分，50%的時間在做跟開發(fā)相關(guān)的事情，讓你具備這個能力；另外50%的時間做其他的事情。工具角度來說，我們內(nèi)部是要有一系列的工具來支持這樣一個高可用性的服務(wù)的。從底硬件來說，機器、存儲、帶寬，這個存儲當(dāng)然包括軟件方面，然后到更高一點的軟件層技術(shù)架構(gòu)來說，我們要有錯誤處理，比如說某一個點出了問題，怎么樣處理，這樣一系列的東西。包括自動化的配置安裝、監(jiān)控、儀表盤，這里面工具幾乎所有都是自動化的。作為一個開發(fā)者來說，他可能所有的東西對他來說都是黑盒的。

我們的SRE做得比較好的，還給工程師開發(fā)者提供了一系列的支持，比如說郵件系統(tǒng)的咨詢，有關(guān)問題通過郵件方式咨詢，有公開的視頻培訓(xùn)，還有一些面對面的咨詢，還有一些公布了審查的列表，同時還有一個發(fā)布委員會，如果你有什么需求，提前去咨詢，發(fā)布委員會也會幫助你解決問題。   測試方面也是很重要的一塊，也算是一個技術(shù)測試。我們的自動化測試，從最底層的最微觀的單元測試，一直到宏觀的系統(tǒng)測試，中間組件測試，這是對每個產(chǎn)品發(fā)布的硬性要求。組件到單元測試往往是通過開發(fā)者自己來寫的，到系統(tǒng)測試往往就會有一些測試專員來做這個東西。我們還會做壓力測試，地球上發(fā)生過很多次本身小測試沒有問題，但是上線以后，壓力變大以后可能就出現(xiàn)問題了。這四種測試是必須的，對于每個產(chǎn)品來說都是必須的。

手工測試，對于所有用戶可見的分析都有手工測試的設(shè)計。

下面講工具。剛才我大概講了一下，這里面有一些比較稍微細一點的。最重要的就是監(jiān)測，一旦有問題，那邊馬上會發(fā)這樣一個尋呼，我們監(jiān)測有黑盒、白盒，白盒的就是說你通過services本身來暴露出來的狀態(tài)，比如說你的延遲程度。還有黑盒監(jiān)測，跟剛才有點像，比如說我不管你這個服務(wù)是干嗎的，我就是簡單發(fā)一個過去，不管你這里面有什么，發(fā)現(xiàn)你用了多長時間，反饋結(jié)果對不對。

第二點就是儀表盤，如果想得到SRE的支持這也是必須的，SRE要有能力在任何時間、任何地點，在他想要看的時候，就可以看到你這個服務(wù)的狀態(tài)。

再下面就是基礎(chǔ)架構(gòu)的支持，這個也非常重要。我們做一個復(fù)雜的系統(tǒng)，不是說做一個簡單的services，還要依賴很多其他的東西。比如說你的數(shù)據(jù)庫、你的網(wǎng)絡(luò)、你的存儲，對于每一塊來說，都要有很強的革命性才能夠使得你這個服務(wù)達到目標(biāo)。比如說這個服務(wù)做得非常好，結(jié)果數(shù)據(jù)庫不行，你這個服務(wù)也是不行的。

最后一點，如果說上面某一個技術(shù)，萬一哪個地方出了問題怎么辦？我們做oncall。第一個級別5分鐘必須響應(yīng)，如果你的產(chǎn)品出了問題，我們馬上發(fā)一個Page，oncall人員在5分鐘之內(nèi)必須響應(yīng)，我知道這個問題，我馬上會出現(xiàn)。oncall人員分幾個級別，第一個級別，一般來說希望你在5分鐘之內(nèi)馬上反映，第二個級別就是說如果第一級別有什么意外情況，比如說你在這個地區(qū)沒有網(wǎng)絡(luò)，沒有收到，或者說你在洗澡之類的沒有收到，二級就會響應(yīng)。三級往往就是技術(shù)人員，三級往往是開發(fā)團隊的一個人，因為他對這個產(chǎn)品非常熟悉，在一級、二級遇到問題5分鐘之內(nèi)響應(yīng)了，辦了一段時間之后，發(fā)現(xiàn)不能解決這個問題，就要找第三級oncall，找他們協(xié)助解決。

我就這樣總結(jié)了一下，大概四個方面來使我們達到這樣一個6個9的目標(biāo)，希望給大家?guī)硪环N幫助，謝謝大家！

以上是51CTO.com記者從一線為您帶來的精彩報道。后續(xù)我們還有更加精彩的獨家報道，敬請關(guān)注。