作者簡介

李震東
騰訊 OMG運維副總監
先後負責騰訊網、騰訊新聞、騰訊視訊等多個業務的運維工作，對直播流暢，海量，秒開，低延時上有深入研究，目前專注於構建直播自動化系統，直播監控體系構建，直播播放質量優化工作，並在好聲音，livemusic演唱會，NBA直播中得到口碑驗證。

前言

我們在一些重要工作的挑戰過程中逐步在提升技術，本文就介紹我最近一年多做海量直播的工作內容，其中選擇了最具代表性的，每年有1300場的NBA直播。

1、直播業務的火熱發展

從2015年起到2016年，是整個直播行業興起的階段，湧現了大量直播的業務。直播為什麼在這一兩年帶來飛躍的提升？其實主要是有四個點組成。

• 技術驅動
  第一是技術的驅動，技術驅動包括智慧硬體、手機還有網路的頻寬提升，為大家帶來更便捷的觀看直播的服務。
• 商業驅動
  第二是商業驅動，內容IP的出現，包括體育還有類似於演唱會，像騰訊也有演唱會，每年都會有好幾百場演唱會直播，還有一些個人直播的主播形式也出現，叫喊麥。將我們的整個內容體系進行了大量的豐富。
• 內容氛圍
  第三是類似於商業的驅動，現在商業變現的方式也豐富了，包括會員的體系、打賞功能，類似於內容分銷的變現模式的出現，有了利潤以後就會給行業注入活力。
• 大眾需求
  第四是大眾的需求，因為通過線上直播的出現是豐富了娛樂的形式，尤其是國人都有比較八卦的心理，如果告訴你這是幾天前發生的，或者悄悄告訴你別人已經知道了，這時候大家覺得不過癮，如果大家能去看看現場，體驗一下這個人在幹什麼或者這個事情怎麼做的。

大家能夠掌握到第一手的資料，滿足八卦心理的時候，大家也是非常願意的。這裡其實不僅僅是女生愛八卦，男生其實也愛八卦，只是內容不一樣而已。

整體這些因素的出現，包括整個技術的輔助，是把我們整個直播的行業帶來了一些新的高度，可以說是最火的高度，什麼都可以直播，現在也在直播，感謝直播團隊，我知道他們很辛苦。

2、優秀直播需要具備的特徵

一個優秀的直播需要什麼樣的要素？人人都想直播，但是直播怎麼才能做得好？我當時是有面臨壓力的，騰訊這一個大網際網路公司，如果直播搞不好，使用者不滿意的話，會面臨巨大的口碑問題。

一些優秀的技術點我列舉了一下，包括畫質一定要清晰，比如看一場維密秀，一定要有添屏的感覺，關鍵部分不是很清晰的時候，彈幕都受不了， 1080P 畫質還不如720P。

你看一場球賽，別人都已經要投籃了，這時卡住了，然後這個球沒進，不知道當時看直播的人是什麼心情，什麼破直播。

還有音畫同步，這種場景也是非常重要的，比如有些互動環節，我說大家有個提問環節，請線上的朋友有什麼問題想問的，然後我發現難道大家對我的演講不喜歡嗎，後面有人發微信告訴我，訊號還沒傳到，我就多等兩分鐘，估計下面的人要崩潰了。

包括延時還有音畫同步，在演唱會過程中，彈幕突然罵了，又在假唱。歌星說明沒假唱，這次是真唱。還沒假唱，截圖，錄了一段視訊確實，歌詞明明已經唱到很前面了，嘴型還不對，這就是典型的音畫不同步。

當然還有更多的情況，後面我還會具體的介紹，這麼多的技術要求給到我們的直播時，因為直播確實是需要有非常高的體驗要求的業務，怎麼做好才能減少捱罵？才能減少幹不好就別乾的概率呢？

3、直播行業的技術選型

接下來跟大家介紹NBA過程中的典型場景，我們面臨這麼多的技術要求，這麼多的使用者壓力，怎麼去做技術的選型？直播還是一個蠻複雜的技術，因為它包含著很多環節。

3.1視訊直播流程

比如整個視訊直播包括從視訊採集、傳輸、包裝、編碼、推流、轉碼、分發解碼和播放等多個環節，不算其他我們總共有十八個環節，再比如說機位1機位2機位3，要做簡單的訊號處理，上衛星或者是網路傳輸，網路傳輸再傳到節目製作中心，再進行包裝，包裝完了以後開始分發給使用者。

除此以外還面臨著各種使用者的需求，各種清晰度的需求，因為使用者的網路受眾都不太一樣，清晰度可能不太一樣，這是需要多清晰度的，還要設多個終端，比如說 FLV 和 HLS，再經過一定的分發去走內容分發的網路，最後到各個使用者的終端，終端還要進行適配技術，整個過程是非常複雜的。

3.2 播放體驗上的挑戰

簡單先介紹我們在NBA直播過程中面臨的技術問題和當時怎麼解決的。主要我列了四個點。

• 傳輸
  因為NBA是在美國打的，所以從美國一個攝像機拍攝一直到中國的使用者，要經歷18000公里的訊號傳輸，因為美國的製作機房是在美國的新澤西，美國東海岸，我們是在太平洋的西海岸，要橫穿整個北美大陸還要橫穿太平洋，再從中國的南端香港登入再傳到北京的演播室，再從北京演播室分發出來到千家萬戶，基本上是有18000公里的遠洋傳輸，這是需要有一些技術門檻的。
• 製作
  傳過來以後，像美國人傳過來的訊號，最簡單的是英文傳輸，當然有些人說我喜歡聽原音，但是大部分中國人有中文的需求，包括球員資訊、賽事資訊，這就需要節目包裝去提升直播過程中的視聽感受，讓中國人看身軀更舒服，更能夠接受，更容易理解。
• 播放
  另外我們還需要多角度和多清晰度，多角度是滿足於各種觀看的角度，我們在NBA實現的是有三個視角，比如說藍筐下面，左視角右視角，讓大家從不同的角度去看比賽。還有清晰度和播放，播放也是很關鍵的點，如果你的播放不流暢，不清晰甚至有馬賽克，這讓整個使用者是沒辦法接受的。如何保證使用者在播放過程中觀看不會卡頓，使用者能夠更快的看到畫面，這是需要去解決的技術問題。
• 監控
  最後是監控，環節這麼多，距離這麼遠，活躍使用者是接近過億，這麼多的終端和使用者，出故障的概率就很大，我們怎麼去保證，去把各種風險降到最低，但是風險是不可能不出現的，故障是一定出現的，怎麼樣讓故障出現以後，讓預案快速啟動，這個監控是非常重要的環節。

但是大家都有監控，騰訊也有這個課程，現在的監控是已經到了新的層面，除了現在必要的監控的各個環節以外，另外是大資料的衝擊。每天整個監控的資訊，一天差不多有2000億條，這資料如何收集起來，如何進行分析，如何快速的在極短時間內發現問題所在，幫助我們快速定位。這是一個巨大的挑戰，這就涉及到大資料處理。

我現在就開始一個個說當時我們是怎麼來解決這個問題的。這是2015年的夏季，當時接到這個任務的時候挺開心的，NBA是很大的投入，騰訊每年投入一個億，還是美金，公司把這麼重要的任務交給我們，要體現我們的價值。幹得好，升值加薪不在話下，幹得不好，可能就要去財務領工資了，所以風險和機會永遠是並存的。

4、面對傳輸問題的挑戰

4.1 挑戰一：傳輸過程中容易出現花屏和斷流

但是直播第一天的時候傻眼了，因為畫面這樣了，有深深無助的壓力。領導說，你這問題怎麼解決？因為以前從來沒搞過直播，我們就開始分析，因為傳播過程中為了滿足低延時和實時性都採用 UDP 的傳輸。

但是是像車隊一樣，很容易造成一些卡頓的情況，因為一旦傳輸要進行一些同傳的時候，包卡在那裡，視訊的畫面都是經過大量的壓縮，一個包丟失的話可能是一個區塊，一個畫素的影響，我們在傳輸過程中那麼遠的距離傳輸，勢必導致丟包，一旦丟包就出現了畫面的卡頓。當時不管是運營還是各種技術，都說要解決。其實有解決的辦法，我後面再說。

4.2 挑戰二：傳輸過程中容易出現花屏和斷流

我們當時選擇的方式是網路傳輸，從美國的新澤西機房一直到傳過北美大陸，傳過太平洋，再從香港的節點到北京，這麼大的距離，我們當時測了一下距離，是17286.59公里，這麼遠的距離，大海有自然因素，可能會有海嘯，非常容易導致整個線路的不穩定。

可能有些同學就說了，為什麼不用衛星傳輸？衛星傳輸是很簡單的，只要經過兩個衛星就行，美國衛星發過歐洲的衛星，歐洲的衛星再中轉給中國的衛星。

衛星傳輸確實是簡單，但是價格是非常昂貴的，可以說通過衛星傳輸的話，差不多是網路傳輸的價格的50倍，網路傳輸價格已經很貴了，如果1300場都用衛星傳輸不太現實。

4.3 傳輸優化解決方案

• 容錯技術
  技術有時候碰到問題才能夠體現出價值來，我把這個任務接下來了，丟包有辦法解決，我們當時採用了糾錯的技術，會把包的傳輸變成一個矩陣，在每橫每列多出一個交驗包，像這樣10乘10的矩陣，每行每列丟一個包的時候，是可以通過校驗碼把它補齊的。如果發100個包，通過加上20個校驗碼的話，每行每列不管丟哪一個包，是不會出現任何的畫面抖動的。就提升了原來UDB傳輸過程中的可靠度，我們當時的網路專線的容錯可靠度能夠達到千分之一。

  所以出現剛才的畫面，網路很難再提升了，很難再去做更大的優化。我們直接把丟包率的要求降低到了10%，但是連續丟包也是不行，一行丟兩個包或者三個包也是不行。這樣就把整個畫面容錯率降到差不多千分之五的概率。

  原來一場比賽每天都會有一些畫面的情況，但是現在已經把一場比賽基本上是十場比賽才可能出現一個很短暫、很細微的畫面感覺。如果大家在遠距離傳輸中出現問題，可以去看這個糾錯技術，這個矩陣只要不斷變小的話，甚至變成2-2的矩陣的話，糾錯能力會更強。

  但是它帶來另外一個因素，加了大量糾錯碼的話，會把傳輸過程中的位元速率變大，因為加了糾錯碼以後，像已經加了20%的流量，原來只要1兆的，加上之後可能到1.2兆，典型的是用空間去換取時間的方式。

  我們當時還研究了美國軍方無線傳輸過程中的方式，這裡就不說了，基本上就能夠解決。

• 多鏈路備份
  剛才說的還有千分之五的概率，怎麼解決呢？我們做了網路備份的技術。我們在北美大陸和太平洋專線部署了三條專線，每條專線會有紅色或者綠色或者是黃色，還有黑色，顏色只是代表著一些訊號傳輸的區別，因為我們不是每一路訊號都進行備份操作或者是有多份的備份，有些只對主訊號進行多備份的傳輸。通過這麼複雜的網路，降低了不管是在正常情況下的丟包概率，還是在應對比較複雜的自然氣侯，還有一些小概率的比如施工導致專線影響。

  當然我們在重要比賽的時候，還是會把衛星的傳輸訊號當成一個備用方案，所以訊號的傳輸過程中主要是利用糾錯的技術和多轉多發的技術，去降低我們在整個訊號傳輸過程中的花屏或者中斷的影響。

5、面對製作技術的挑戰

5.1 視覺優化-字幕

當訊號完美傳到製作中心的時候，這時候就開心要進行一些節目製作中的包裝了，比如說加一些字幕，通過字幕機把球員資訊轉化成中文的資訊。

5.2 視覺優化-AR

我們還可以利用一些AR技術，將我們在比賽過程中一些互動的過程，或者一些資料的分析加到直播畫面過程中。

5.3 視覺優化-多角度

比較重要的一點是多角度，這是提升使用者在觀看過程中的吸引力，比如加了英文的原音還有低角度和右籃板多視角的技術。整個過程完成了節目的傳輸和製作包裝的過程。

6、面對播放問題挑戰

6.1 問題一：播放流暢度問題

到了重點的地方了，節目已經準備好了，接下來就要傳給使用者，傳播給使用者的過程中，具體是有要求的，就是流暢度。

• 第一個是2秒法則，當一個使用者開啟視訊的時候，如果超過兩秒時間，使用者這時候選擇離開的可能性會逐步增大，每增加一秒鐘的時間，開啟時間超過一秒，使用者的離開率可能會增加6%，我們就要趕在使用者兩秒之內看到我們的畫面，使用者是上帝，不能考驗他們的耐心，超過兩秒人就會走。
• 第二是卡頓的影響，這也是從資料中分析的，如果使用者每增加一秒鐘的卡頓，使用者的觀看時長就會降低1%，使用者離開的可能性也就越大。我們怎麼去解決在播放過程中的流暢性這樣一個問題？

6.2 解決方案-CDN技術

首先是最普世的技術，CDN 的技術，我們在全國部署了500個 CDN 的節點，包括新疆、香港這些地區，包括很偏遠的雲貴地區。

CDN 是一個比較成熟的技術了，把使用者的內容推到離使用者最近的地方，擁有500個節點以後，還做了提升使用者接入速度的技術，我們直接使用IP的排程，沒有經過 DNS 的解析，節省了使用者在接入過程中的時間。另外就是我們會對整體狀況進行實時統計。

有了優秀的 CDN 技術和覆蓋以後，是不是就真的能夠滿足兩秒開啟的要求？其實不是的，因為直播過程中有一個重要的特點是，直播開始的效率。

直播不是24小時都有的，有時候訊號沒有了，使用者根本就不用去看，但是一旦直播開始，比如說一場球賽開始，這時候使用者會有非常強的直播效應就是進入效應。

6.3 問題二海量使用者播放體驗保障問題

像騰訊擁有包括微信、QQ的渠道，NBA一場比賽開始的時候，一分鐘內我們的使用者就能夠達到峰值，每一分鐘進入大概都是在200多萬。

人多的時候就會擁擠，不是技術無能，是使用者實在太多了，我們可以去想象一下，每次在刷票的過程中，看到12306的時候，每個人都罵12306的時候，我是堅決不罵的，因為那個量確實太大了，每天有多少人，具體的資料12306都會公佈。

在海量使用者的時候，大家都想在那個時刻進入的時候，確實是很難支撐的，那怎麼辦？生活還是要繼續，儘量還是要保住飯碗。

6.4 解決方案—排程策略

在快速海量的使用者進入的過程中，在這麼強大的使用者衝擊下面，它會造成對使用者的衝擊分為哪些方面，我這裡總結了是兩個方面。

第一個是使用者快速進入的時候會造成區域性系統的擁塞，另外就是使用者實在太多了，我的系統沒辦法支撐了，這時候該怎麼辦？區域性的擁塞是用預排程的策略，就是使用者來得快，我的應對機制更快。

第二是柔性降級，是海量技術裡非常重要的一個思路，其實是通過服務有損的方式對使用者提供服務。

舉個例子，比如說現在只准備了一百個位置，卻來了兩百人的時候，這時候該怎麼辦？如果是無序的，什麼都不幹，可能會在現場打起來，那會引起更大的混亂。

這時候怎麼辦？如果你的平臺的能力已經無法完全支撐這麼多使用者，預估是不準的時候怎麼辦？就需要有柔性降級的策略，我接下來詳細說。

天下武功唯快不破。當用戶快速進入，勢必而言會對區域性系統給出很大壓力，我們怎麼快速分解這部分壓力？這裡用了兩個重要方式。

• SNMP協議採集資料延時資訊
  第一個方式是用簡單網路協議SNMP協議直接採集交換機流量，這時候統計起來了，使用者找進來了，可能延遲三四秒，但是每三十秒都有三萬人的進入，而且直播是高頻寬的服務，上萬人可能就已經出現了幾十G、上百G的擴張。這時候我們不在統計網卡里，統計交換機流量，把流量收集的資料延時降到最低。
• 預測技術及時分流
  另外一個技術是採用預測的技術，預測的技術就是跌倒了以後把自己看看我是怎麼跌倒的，分析一下自己跌倒姿勢的技術。每個使用者雖然我們說使用者是快速介入的，但是是有一定規律的，我們通過每一場比賽，使用者進入了一個規律，我們去看曲線，使用者如果一分鐘內進入多少萬，這時候對於衝破這個機房的概率是多大。

  當我們滿足什麼條件時，機房衝破的概率一旦超過60%的時候，可能流量還沒有到60%，只到30%，但是我們發現流量的產生曲線已經大概率可能出現衝破機房的情況時，我們就把機房提前分流，它就不再進入機房了。

之前我們跌倒就是因為延遲只有一分鐘，但是一分鐘過程中使用者進入這個領域的時候，已經完全把機房衝跨了，但是我們開始預測，只要前一分鐘的曲線，可能會出現把機房衝爆，就不再給機房導流。提前進行分流，通過預排程方式解決區域性的擁塞問題，就是快，甚至是通過預測的方式。

排程策略—柔性策略
另外的方式就是柔性解決全域性擁塞風險，當然我們有一個非常豐富的使用者線上預測體系，也會根據每一場比賽的球隊粉絲數還有不可控因素，還有這場比賽推哪些渠道和引流，每個比賽之前都會有專業的資料分析，比如這場比賽可能會有五百萬人或者六百萬人，但實際上預測是很重要的環節，但不是絕對安全的環節。沒辦法預測完全準確，就像九三閱兵的時候，大家都預測有多少人會看閱兵，最後讓我們大跌眼鏡，每個人都在看閱兵，所以預測不是絕對可靠的，只能做一個理論的依據。

方法一：排隊
如果我預測的一桌人，來了兩桌人怎麼辦？怎麼樣不形成現場的混亂，這時候一定要有柔性機制，我們有很多的方法。

第一個方法就是排隊，當一個使用者去預測，比如只有五百萬人，卻來了五百零二萬人的時候，這時候不要直接擠進來，直接進來就容易進行資源的競爭，直播是一個高資源頻寬的業務，一旦形成資源競爭，使用者下載不到足夠資料就會產生卡頓，這時候就讓他先不進來，讓他先等一等。

方法二：柔性降級
有人說等不了怎麼辦？那也沒有辦法，如果進來了就會影響剩下的五百萬人，可能就會打起來的情況。也可能會提供一些更豐富的場景，比如說如果使用者特別多的時候，像演唱會甚至比賽，這時候我們會提供一些視訊流，沒辦法提供就是提供音訊流，像王菲演唱會專門提供了音訊流，如果使用者太多了，頻寬不夠，使用者還可以選擇音訊。

這就是柔性降級的重要策略，千萬不要因為超出預期了，讓這部分人去無序和現有已經能夠服務很好的人造成資源競爭，如果產生這種競爭的話，整個服務體系就會全部崩潰了，所以一定要有預案，要有一個准入機制，或者有一些降級的豐富的手段，既能保證現有的使用者，體驗不受到影響，也能對想進來的人有一個很好的預案去解釋。

排程策略就是這兩種，如果使用者在快速進入過程中的話，如果只是區域性的，那就是以快制快，通過更快的速度拿到我們現場的機房流量，另外一個方式就是通過柔性方式，當用戶來得我們無法承擔的時候，不是說使用者從A機房挪到B機房能夠解決的時候，這時候就要極少解決，排隊或者降級策略，比如說音訊或者低清晰度畫質，來滿足部分使用者，避免他造成全域性使用者的影響。

把2秒法則和卡頓解決之後，通過在應對各種使用者場景的技術的情況下，就能夠很好的把流暢度需求解決掉，使用者還是會有一些需求的，兩秒是使用者基本的耐心，但是使用者還想更快看到畫面，這裡有個重要的技術就是秒開的技術，就是如何讓使用者更快看到畫面，事情無絕對，能做到極致。

6.5 解決方案—提升使用者看到畫面的速度

這裡用的是I幀壓縮去掉影象的空間冗餘度，I幀是可以完全解碼的，只是幀內的壓縮，沒有摻雜時間的屬性，I幀能夠獨立解碼出來，P幀需要依賴於I幀，這時候是解不出來畫面的，需要去參考前面的I幀，通過I幀把背景資訊和運動資訊補齊，這裡是帶運動引數才能解出來，而B幀是雙向幀，也是解不出來，它還要依賴於後面的P幀，所以基本上就是這樣的畫面壓縮邏輯。B幀就需要同時拿到I幀和P幀，根據拿到的壓縮資料去解壓。

之前是一個無序的過程，就是可能會給你I幀，也會給你B幀，也會給你P幀，如果你下的是B幀，那解不出來，把I幀先下完，再把P幀下完，才能夠解壓出來。這種情況就會出現需要下載更多的資料，等待更長的時間才能看到畫面，這樣對於追求技術極致的人是沒辦法忍受的。

我們就用了一個技術，讓使用者更快看到畫面的技術，首先我都是下I幀，這個和播放器一起去改造，使用者下到I幀馬上畫面就出來，降低使用者的時間，降低了接近兩百毫秒，讓我們的上帝去看到畫面的速度又提升了兩百毫秒。

但在體育大型的賽事直播，尤其是個人主播的時候，體現的優勢會更加明顯，通過這些技術，我記得有一個有意思的問題。當時有一個同學說，這個東西很難嗎？我說其實感覺不是特別難，概念一說很清楚，改造的話估計一兩個星期就可以了。

他說，為什麼不難的技術，其他的直播或者行業做不到呢？我當時回答的是，我覺得做技術或者海量的話其實應該有兩個點，第一個是單純一個點解決起來是不困難的，困難的是把一個技術體系，針對於這個業務，這個方面遇到的各種問題解決。

我們解決了 CDN 問題，解決了純屬問題，在 CDN 上又直接排程問題，解決了流暢性上海量衝擊的問題，再加上解決了開啟畫面快速的問題，實際上是有很多的點去解決的。把整個點再覆盤一下，才慢慢形成一套方法，並不是一兩個點能夠來解決。

所以海量技術並不是容易解決，而是過程中不放棄，把每個技術點做到極致，而且是非常適合自己的業務體驗的極致。

7、面對海量監控問題的挑戰

7.1 監控的目的

最後說一下關於監控的問題，全流程監控是為了發現質量問題，比如說基礎監控是最底層的，包括 CPU、記憶體、網絡卡、IO硬體，還有網路，因為現在都是網際網路服務，網路監控是必須的，比如說點到點 ping 的延時，udp探測，鏈路分段檢測，慢速這些監控，另外就是播放，播放屬於業務層，這個時候就需要有包括對播放量、開啟時間、卡頓時長、卡頓率和失敗率，包括一些碼流去監控。

另外針對直播的業務屬性，更加偏向業務的監控，比如說直播流，比如說黑屏能不能監控，使用者看到的畫面是不是螢幕已經變黑了，或者可能是馬賽克，可能有慢速或者丟包導致的情況，另外就是靜音，直播過程中使用者是不是聽不到畫面了，或者爆音，使用者聽到刺耳的聲音，還有轉碼這些過程。這是一個立體化的模型，所有這些點聚合起來的時候，前面我提到各種資料上報，包括後臺日誌。

7.2 監控的挑戰-日誌分析效率

日誌整體一天是2千億條，未來可能會超過5千億條，這麼大的量半天以後拿到結果或者一天後再拿到結果，黃花菜都涼了，怎麼辦？我們需要的是分鐘級的。

傳統的方式已經不再適應需求，現在面臨的是每天千億的資料，每條可能有一百個維度，資料量每天超過100，我們還需要有一個秒級的響應，要求開啟的速度是10秒鐘響應，延遲是30秒。這時候我們就要引入新的技術，面向分析，面向搜尋的技術，去推進我們在監控領域面臨的資料量的挑戰。

7.3解決方案-大資料處理

這是我們的大資料處理流程，其實是一個比較經典的大資料處理流程，是從各個終端，包括蘋果、安卓、TV、PAD、PC web 這些，把資料上報以後，通過日誌式的採集系統接收，經過簡單的清洗和Kafka傳遞到Spark叢集，計算維度，統計完了以後生成我們的資料產品。

鷹眼日誌就是基於ES來進行開發的，這裡就是把大資料的經驗分享一下，主要是運用實時運算，來實現播放流程的監控和 CDN 測速監控，這套架構基本上滿足天2千億條和100T以上的資料，維度是非常多的，差不多一條日誌一百多的複雜的資料。

一旦有了監控的資料，能夠快速得到的時候，你就真的能夠先人一步去發現問題，什麼樣的問題也能夠快速獲取。這裡的技術其實涵蓋很多方面，雖然說起來很簡單，但是涵蓋了海量運營的技術基礎，涵蓋流媒體的基礎，涵蓋大資料技術。

怎麼把資料拿出來，實時分析出來，還涵蓋了 CDN 的網路傳輸技術，怎麼保證網路數量，怎麼在 CDN 的過程中快速加速，還有怎麼把原來 DNS 的方式變成IP直聯的方式，其實是包含很多方式的，這可能不是一下子能夠說得很清楚，相當於是拋磚引玉。

8、總結

海量的運營技術是很大的體系，希望大家遇到這種情況的時候，能夠勇敢站出來，面臨挑戰，只要我們有一個追求卓越的心不斷嘗試，大部分人都是能做到更好的，這就是我的一點心得

文章來自微信公眾號：高效運維