《騰訊1300場NBA直播背后的技術力量》要點：
本文介紹了騰訊1300場NBA直播背后的技術力量，希望對您有用。如果有疑問，可以聯系我們。

作者簡介

李震東
騰訊 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、總結

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

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

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/4181.html