《環(huán)信全球?qū)崟r消息網(wǎng)絡(luò)技術(shù)白皮書》正式發(fā)布

　　引言

　　云計(jì)算的出現(xiàn)為企業(yè)的管理、業(yè)務(wù)開展、資源整合等帶來了極大的便利性，也是數(shù)字化建設(shè)的核心基建之一。而高可用性和穩(wěn)定性是衡量一家云服務(wù)廠商最核心的標(biāo)準(zhǔn)之一。

　　環(huán)信作為全球領(lǐng)先的互聯(lián)網(wǎng)消息云服務(wù)商，提供全面SLA 99.95%的全球公有云方 案，以及SLA99.99% 的全球?qū)Ｓ性品桨浮Ｈ绾巫龊萌�球網(wǎng)絡(luò)服務(wù)支撐，構(gòu)建超低 延時的SD-GMN 網(wǎng)絡(luò)，保持全球用戶100毫秒以內(nèi)的最佳用戶體驗(yàn)。本次將向您講述服務(wù)背后的技術(shù)故事，包括環(huán)信全球?qū)崟r消息網(wǎng)絡(luò)的的整體規(guī)劃、運(yùn)維監(jiān)測和服務(wù)、技術(shù)迭代以及持續(xù)優(yōu)化。

　　目錄

　　一、全球?qū)崟r消息網(wǎng)絡(luò)的主要挑戰(zhàn)二、環(huán)信全球?qū)崟r消息網(wǎng)絡(luò)整體規(guī)劃三、運(yùn)維監(jiān)測和服務(wù)四、擁抱邊緣計(jì)算和持續(xù)迭代優(yōu)化五、結(jié)語

　　一、全球?qū)崟r消息網(wǎng)絡(luò)的主要挑戰(zhàn)

　　環(huán)信作為國內(nèi)最早提供全球消息云服務(wù)的廠商，在提供全球?qū)崟r消息網(wǎng)絡(luò)方面面臨諸多挑戰(zhàn)，  主要包括新興市場國家基礎(chǔ)設(shè)施差、延時高， 以及 DNS 錯誤等問題。其中，消息的到達(dá)率和消息的延遲是最重要的核心指標(biāo)之一。

　　面對國內(nèi)用戶的時候，基于國內(nèi)的 5G 基礎(chǔ)設(shè)施的領(lǐng)先性，消息延遲基本不算問題， 國內(nèi)整體網(wǎng)絡(luò)延時整體可控。根據(jù)數(shù)據(jù)統(tǒng)計(jì)顯示：“國內(nèi)最慢的重慶市時延中值 84ms，那收發(fā)消息單次往返就是 84ms，再加上幾十毫秒的服務(wù)器處理時間，整體 時間控制在 100ms 左右，用戶幾乎感受不到延遲帶來的交互問題。”

　　以上數(shù)據(jù)來自speedtest.cn

　　早在2014年當(dāng)環(huán)信向海外客戶提供服務(wù)之時，受制于國外網(wǎng)絡(luò)基礎(chǔ)設(shè)施良莠不齊， 我們會發(fā)現(xiàn)海外的整體網(wǎng)絡(luò)延遲差異巨大，無法跟國內(nèi)一樣通過部署3線、8 線 bgp 的機(jī)房就能基本可用，或者使用自己攢的多線機(jī)房方案。環(huán)信全球?qū)崟r消息定義我們 收發(fā)的消息每次延時都是在 1s 內(nèi)，一旦超過 1s 我們就會感覺到有明顯的延遲。因此 我們的目標(biāo)就是單個客戶端發(fā)送消息到達(dá)服務(wù)器端不能超過 100ms。最終這個問題就演變成了我們在面對海外網(wǎng)絡(luò)的情況下如何進(jìn)行解決處理來達(dá)到這個標(biāo)準(zhǔn)。

　　以上數(shù)據(jù)來自

　　https://www.cable.co.uk/broadband/world-wide-speed-league/2022/worldwide_speed_league_data.xlsx

　　從上面數(shù)據(jù)雖然無法看出各個國家的手機(jī)網(wǎng)絡(luò)延時，以及由于某些國家的網(wǎng)絡(luò)出口原 因?qū)е陆Y(jié)果并不完全準(zhǔn)確，但是大體上我們可以看出來網(wǎng)絡(luò)慢的都是一些新興市場的 國家和地區(qū)。這些地區(qū)主要是非洲、南美、中亞以及西亞等地區(qū)。

　　我們再來計(jì)算一下網(wǎng)絡(luò)的傳輸速率，由于國際網(wǎng)絡(luò)基本都是光纖來進(jìn)行傳遞的。光纖 延時計(jì)算：t=n*L/c，c 為光速，其中光速約為 c=30 萬公里 / 秒;光纖的材料是二氧 化硅，其折射率 n 為 1.44 左右，計(jì)算延遲的時候可以近似認(rèn)為1.5。我們用這個公式可以計(jì)算下北京到上海的延遲:最快就是 11ms 往返。但是實(shí)際情況可能就是這個數(shù) 字要乘以 2或乘以 3的數(shù)值。因?yàn)檫@里會有各個路由節(jié)點(diǎn)的損耗，以及光纖從北京到 上�？赡懿⒉皇侵本�，而比如中美海底光纜這樣的，由于有標(biāo)注整體的長度，因此很 容易計(jì)算整體延時。

　　以下這個網(wǎng)站是根據(jù) Wikipedia 整理的現(xiàn)在已有和在建的海底光纜。這里我們可以比 較清楚的看到，  國際光纜主要是在亞洲和北美之間的太平洋，北美和歐洲之間的大西 洋。(數(shù)據(jù)來源參考網(wǎng)址： https://cablemap.info/_default.aspx )

　　現(xiàn)在，我們已經(jīng)找到了核心問題，同時定義好了目標(biāo)，那就擼起袖子加油干吧!

　　從以上信息中我們可以看到，我們需要解決的是三個問題：

　　- 更近的數(shù)據(jù)中心

　　- 非發(fā)達(dá)國家的 Last mile 優(yōu)化

　　- 路徑選擇

　　最后我們也將介紹一下聲網(wǎng)環(huán)信集團(tuán)的網(wǎng)絡(luò)基礎(chǔ)設(shè)施矩陣。

　　二、環(huán)信全球?qū)崟r消息網(wǎng)絡(luò)整體規(guī)劃

　　第一：更近的數(shù)據(jù)中心

　　因?yàn)樗�有網(wǎng)絡(luò)傳輸?shù)难訒r最終都是跟光纖距離有關(guān)，所以我們需要將數(shù)據(jù)中心盡可能 的離用戶更近。于是我們分別在北美、歐洲、東南亞選取了 3 個地點(diǎn)作為海外的核心 數(shù)據(jù)中心，分別覆蓋各自本地的區(qū)域。非洲地區(qū)因?yàn)闅v史原因，非洲國家的出口網(wǎng)絡(luò) 很多都是繞道英國、法國這些發(fā)達(dá)國家。

　　有一種聲音認(rèn)為代理也可以解決，可是代理并不能解決實(shí)際數(shù)據(jù)傳輸?shù)木嚯x問題，只 能是提升網(wǎng)絡(luò)的穩(wěn)定性。

　　因此我們在出海的選擇上就選擇了如下幾個區(qū)域：

　　新加坡：覆蓋東南亞、東亞、南亞、非地中海區(qū)域的西亞國家、南非、大洋洲

　　德國：覆蓋歐洲、西亞、北非、東非、西非、中亞

　　美國 : 覆蓋北美、南美

　　基本上環(huán)信數(shù)據(jù)中心到這些地區(qū)都控制在 10000里以內(nèi)，這樣往返加上 Last mile 的速度，基本上單程收或發(fā)消息的中值我們可以控制在100ms 內(nèi)。

　　新加坡數(shù)據(jù)中心主要覆蓋的地區(qū)：

　　德國數(shù)據(jù)中心覆蓋的地區(qū)：

　　美國數(shù)據(jù)中心覆蓋的地區(qū):

　　環(huán)信全球?qū)崟r消息網(wǎng)絡(luò) SD-GMN 實(shí)測數(shù)據(jù)展示：

　　第二: Last mile優(yōu)化

　　這里分為兩個問題點(diǎn)：

　　一個是本地跨運(yùn)營商的，比如印度當(dāng)?shù)鼗�本上每個邦都有自己的運(yùn)營商，比較好的是他們基本都跟 AWS 這些大的運(yùn)營商進(jìn)行 IX(Internet Exchange Point，互聯(lián)網(wǎng)交 換)。但問題點(diǎn)是一旦超過 IX 的容量就會產(chǎn)生擁塞。

　　環(huán)信的 IM SDK 不光使用 AWS GA 這些服務(wù)，同時也使用自己的 FPA(終端網(wǎng)絡(luò)加速) 方案。而 FPA 使用的方式是在主要的邦都使用本地的運(yùn)營商來進(jìn)行接入，這樣在網(wǎng)絡(luò) 高峰時期會更可靠，畢竟 IX 通常的帶寬上限都不太高。

　　另外一個問題點(diǎn)是手機(jī)網(wǎng)絡(luò)的不穩(wěn)定性。這個問題在一些新興市場國家中尤為明顯。而  FPA 可以有效的進(jìn)行弱網(wǎng)對抗，有效的避免了終端網(wǎng)絡(luò)不穩(wěn)定性。同時 FPA 也提 供了水晶球的展示，這樣方便觀測來自各個地區(qū)，各個運(yùn)營商的接入情況。

　　第三: 路徑選擇

　　路徑選擇分為兩步：

　　1、找到離用戶最快的接入地址

　　這個我們可以看到很多友商都會使用智能 DNS 這樣的方式來進(jìn)行處理。這樣的準(zhǔn) 確性并不太高。這里主要會產(chǎn)生如下問題。

　　- 用戶自定義 DNS Server 跟他自己的運(yùn)營商不匹配，雖然現(xiàn)在 bind 有擴(kuò)展是支持傳遞用戶 IP 的，但是還是有很多 DNS Server 是不支持的。

　　- 有些 DNS Server 地址對于智能 DNS 服務(wù)提供商會有誤判。

　　- DNS 解析本身耗時。

　　環(huán)信首先會使用實(shí)際出口的 IP 來進(jìn)行作為判斷依據(jù)，因此我們?nèi)�球部署了上百個 邊緣的解析節(jié)點(diǎn)保證就近接入。這些解析不光是按照運(yùn)營商，地域這些來進(jìn)行分 配地址，同時也會根據(jù) RTT，傳輸大小來進(jìn)行智能的調(diào)配。

　　同時為了解決一些新興市場國家弱網(wǎng)的情況，我們同時支持 tcp 和 udp 不同的方 式來進(jìn)行獲取。

　　2、支持多條路徑

　　環(huán)信 IM SDK 支持多種路徑選擇，于是產(chǎn)生了路徑選擇的問題。前期在環(huán)信IM SDK 里其實(shí)默認(rèn)包含了 3 種路徑，包括直連、GA、FPA 這 3 種不同的方案，后期我們也將增加新的鏈路路徑。

　　比如我們很多友商都是接入了 AWS GA，AWS 也顯示了他們 102 個加速節(jié)點(diǎn)的地址。但是我們也看到了這里有一些不合理的地方。比如我們前面列的那些網(wǎng)絡(luò)速度慢的 地區(qū)，AWS 基本沒有做覆蓋，作為創(chuàng)業(yè)公司在前期可以正常使用可能問題不明顯, 但 對于真正要面向全球化的公司后期就有點(diǎn)力不從心了。

　　就算用 Azure 和 google cloud platform 也是一樣，這幾家主要覆蓋歐美、日 韓和新加坡地區(qū)。而這些區(qū)域其實(shí)就算直連，它們的網(wǎng)絡(luò)延時也都挺好。

　　下面這個是 AWS GA 網(wǎng)絡(luò)加速節(jié)點(diǎn)：

　　除了 AWS GA，還有一些廠商在新興市場國家擁有更多的節(jié)點(diǎn)：

　　環(huán)信相對于友商的核心優(yōu)勢是除了會用到這些公有云廠商的節(jié)點(diǎn)，我們也使用自建的 Agora FPA 網(wǎng)絡(luò)，我們自建的終端加速網(wǎng)絡(luò)覆蓋了全球 230 多個國家和地區(qū)。當(dāng)我們 SDK 支持多條路徑選擇的時候，我們就需要有相應(yīng)的路徑選擇能力，這些能力使我們 掌握了更多的調(diào)度主動權(quán)。

　　但這些都是需要我們有足夠的數(shù)據(jù)來支撐和驗(yàn)證 :

　　- 我們使用了 250+ 的 FPA 節(jié)點(diǎn)來采集延遲數(shù)據(jù)。

　　- 用戶主動上報來的延遲數(shù)據(jù)。

　　我們也建立了全球 250+ 節(jié)點(diǎn)的監(jiān)測網(wǎng)絡(luò)，這樣從全球 200 個國家到我們核心機(jī)房的 延時和丟包率我們都可以做到實(shí)時監(jiān)測，這些數(shù)據(jù)將作為我們鏈路調(diào)度的核心依據(jù)。

　　在 2022 年上半年的時候，太平洋海底爆發(fā)了地震，導(dǎo)致從南美到新加坡的海底光纜 出現(xiàn)了異常。當(dāng)時環(huán)信的監(jiān)控系統(tǒng)迅速的發(fā)現(xiàn)了這個異常情況，我們就迅速的切換了 南美到新加坡的路徑，不從太平洋走，而是改道歐洲，再到亞洲。這樣雖然整體的延 時提高了，但是根據(jù)監(jiān)控和客戶反饋幾乎沒有發(fā)生丟包現(xiàn)象。

　　我們也同時迅速報告了相關(guān)的大運(yùn)營商，他們也很快的修改了整個路由走向，大家都 是一樣犧牲了延時來保證了穩(wěn)定性。

　　在 2022 年下半年，某海外運(yùn)營商從歐洲到新加坡突然完全不可用，而當(dāng)時很多使用 了我們多鏈路的客戶就基本沒有影響，只是有可能在第一次連接的時候產(chǎn)生失敗后會 立刻重試后面的鏈路，保證了整體服務(wù)的可用性。我們也立刻告知了大運(yùn)營商，但是 這次運(yùn)營商由于對端鏈路宣告的原因一直過了 1 個多小時才恢復(fù)。

　　綜上所述，如何來調(diào)度顯得至關(guān)重要，網(wǎng)絡(luò)調(diào)度里最核心的部分就是延遲和丟包，而 延遲主要是由路由走向來決定的。

　　環(huán)信通過建立了對應(yīng)的監(jiān)測節(jié)點(diǎn)來監(jiān)測主干網(wǎng)絡(luò)的情況。通常情況下，來的路由和去 的路由走向是不一樣的，所以通過使用 fping 來 ping 全球所有的網(wǎng)段，這種結(jié)果并 不完全準(zhǔn)確，最后我們通過模擬客戶網(wǎng)絡(luò)來  ping 過來會更準(zhǔn)確，這樣就完成雙向的 路由統(tǒng)計(jì)，同時我們也會使用用戶上報的方式來查看各個網(wǎng)段情況。

　　第四：基礎(chǔ)設(shè)施矩陣，機(jī)房全球分布、五地三中心資源覆蓋

　　基礎(chǔ)資源選點(diǎn)：集團(tuán) SD-RTN™ 在全球部署了 250+ 數(shù)據(jù)中心，覆蓋全球 200多個國 家與地區(qū)，對于主要區(qū)域的最低要求是五地三中心的資源覆蓋，每個區(qū)域采用核心節(jié)點(diǎn) +POP 點(diǎn)的方式。這樣一旦某區(qū)域其中一個或兩個機(jī)房發(fā)生故障，依靠技術(shù)可以將 故障城市的流量全部切換到運(yùn)行正常的機(jī)房。

　　供應(yīng)鏈管理:不依賴單家供應(yīng)商的基礎(chǔ)資源 ( 包括:機(jī)房、硬件、網(wǎng)絡(luò)等 )，當(dāng)一家 供應(yīng)商出現(xiàn)問題，可以快速切換到其他服務(wù)正常的供應(yīng)商。

　　眾所周知，基礎(chǔ)設(shè)施會因?yàn)橥话l(fā)的網(wǎng)絡(luò)擁塞、硬件故障、不可抗力等因素導(dǎo)致或大或 小的一段時間的不可用。在這樣的前提下，集團(tuán) SD-RTN™ 大網(wǎng)的架構(gòu)師團(tuán)隊(duì)從設(shè)計(jì) 之初就充分考慮到了基礎(chǔ)設(shè)施的不穩(wěn)定因素。如果要用幾個關(guān)鍵詞來描述 SD-RTN™ ， 那就是全球覆蓋、故障實(shí)時感知與智能調(diào)度、超低延時、彈性能力、異地多活、超高 并發(fā)，而一旦基礎(chǔ)設(shè)施出現(xiàn)故障，SD-RTN™ 的故障實(shí)時感知與智能調(diào)度能力以及異 地多活的構(gòu)建方式將發(fā)揮重要作用，保障服務(wù)的高可用。

　　1、故障實(shí)時感知與智能調(diào)度：從全球來看，公網(wǎng)網(wǎng)絡(luò)的波動是較為頻繁的， SD-RTN™ 的網(wǎng)絡(luò)嗅探服務(wù)能夠?qū)崟r的感知網(wǎng)絡(luò)的質(zhì)量，結(jié)合 AI Ops ( 智能運(yùn)維 ) 的分析能力，能夠?qū)崿F(xiàn)分鐘級的用戶遷移，保障用戶的音視頻體驗(yàn)。

　　2、異地多活：  SD-RTN™ 大網(wǎng)將全球資源劃分為多個 Region ( 區(qū)域 )，在 Region 內(nèi)依然能夠做到最低 N+3 ( 即：在最大的 3 個資源集群不可用的情況下，剩余的 資源依然能夠承接當(dāng)前 Region 的負(fù)載 ) 資源冗余的要求，不僅如此，Region 之 間依然能夠形成互補(bǔ)的態(tài)勢，某個 Region 故障時，可以通過互補(bǔ) Region 進(jìn)行 承接。

　　3、靈活的彈性擴(kuò)縮容能力：  SD-RTN™ 大網(wǎng)的每個 Region 至少具備 200% 的實(shí)時 彈性擴(kuò)縮容能力，具備應(yīng)對突發(fā)事件的能力，配合智能調(diào)度能夠充分合理的進(jìn)行資 源使用。

　　三、運(yùn)維監(jiān)測和服務(wù)

　　隨著微服務(wù)化的浪潮，運(yùn)維復(fù)雜度在迅速增加，傳統(tǒng)運(yùn)維已經(jīng)捉襟見肘，為此，環(huán)信 投入了巨大的資源和人力解決了傳統(tǒng)運(yùn)維的痛點(diǎn)，從運(yùn)維監(jiān)測的角度來看，我們主要 從以下幾個方面來梳理:

　　1. 從最終的效果來作為評判標(biāo)準(zhǔn)，選取業(yè)務(wù)上最核心的指標(biāo)

　　1.1 用戶連接 5 秒失敗率。

　　1.2 用戶收發(fā)消息 1 秒失敗率。

　　1.3 在線用戶數(shù)。

　　1.4 在線消息數(shù)。

　　1.5 以上數(shù)據(jù)再通過運(yùn)營商，國家地區(qū)等多種維度來進(jìn)行分類。

　　2. 梳理收發(fā)消息的完整調(diào)用鏈

　　但是隨著業(yè)務(wù)越來越復(fù)雜，基礎(chǔ)組件也越來越多，微服務(wù)化又會導(dǎo)致現(xiàn)在單個 api 的整體調(diào)用鏈會非常冗長。而由于虛擬化、容器化，導(dǎo)致現(xiàn)在的網(wǎng)絡(luò)問題點(diǎn)也是越 來越多，運(yùn)維在做研發(fā)評審的時候也要重點(diǎn)關(guān)注。

　　因此我們一般分為網(wǎng)絡(luò)監(jiān)控，基礎(chǔ)監(jiān)控和調(diào)用鏈的監(jiān)控。

　　2.1 網(wǎng)絡(luò)監(jiān)控

　　我們需要確定各個節(jié)點(diǎn)之間的延時和丟包率，以及帶寬的使用率，這個是需要 做到秒級。

　　- 內(nèi)部延時和丟包，這里要特別注意要區(qū)分好物理層網(wǎng)絡(luò)的丟包延時以及虛擬容 器層網(wǎng)絡(luò)的丟包和延時。

　　- 外部網(wǎng)絡(luò)供應(yīng)商的延時和丟包。這個在監(jiān)控的時候要注意區(qū)分大小包以及不同的協(xié)議。對于有多個運(yùn)營商組成起來的線路，最好是分段去監(jiān)測，這樣后期可以快速判斷。

　　2.2 基礎(chǔ)監(jiān)控

　　- 服務(wù)器級別，操作系統(tǒng)級別。這里需要注意的是 Linux 有些監(jiān)控指標(biāo)我們需要多個角度去判斷。

　　- 基 礎(chǔ) 組 件 級 別 監(jiān) 控，包 括 Redis、 tendis、 kafka、 rabbitmq、 nginx、 haproxy、consul 等 等，得 益 于 整 個 prometheus 的 生 態(tài) 非 常 好，都 有 對 應(yīng) 的 exporter 來監(jiān)控。但是其實(shí)問題不是在監(jiān)控，  而是在部署架構(gòu)上就需要考 慮好高可用和快速的擴(kuò)縮容上。

　　- 應(yīng)用服務(wù)自身的 qps，  負(fù)載，jvm，  以及內(nèi)部邏輯核心指標(biāo)的上報接口的采集 和監(jiān)控。

　　2.3 調(diào)用鏈監(jiān)控

　　- 需要有一個統(tǒng)一的 traceid 來覆蓋整個調(diào)用流程。

　　- 調(diào)用流程需要包含 connect、read、response 的時間，以及請求次數(shù)。

　　- 要進(jìn)行抽樣，但是要保證單一鏈條完整性。

　　3. 第三方撥測

　　3.1 從外部角度來模擬監(jiān)控。

　　3.2 覆蓋多種場景和地域。

　　4. 全時區(qū)服務(wù)

　　針對不同時區(qū)客戶的需求，環(huán)信建立了全時區(qū)運(yùn)維保障團(tuán)隊(duì)，7*24H 值班，及時 處理和反饋。并在印度、美國和國內(nèi)建立了一支英文的技術(shù)專家團(tuán)隊(duì)，為海外客戶 提供英文的技術(shù)和方案支持。

　　四、擁抱邊緣計(jì)算和持續(xù)迭代優(yōu)化

　　1. 真正的邊緣計(jì)算

　　相對于傳統(tǒng)的管理方便的數(shù)據(jù)中心，環(huán)信正在利用邊緣計(jì)算來持續(xù)優(yōu)化網(wǎng)絡(luò)服務(wù)。我們看到了諸如 Mastodon 這些項(xiàng)目，就是從一個星形的網(wǎng)絡(luò)架構(gòu)變成一個網(wǎng)狀的網(wǎng)絡(luò)架構(gòu)。這樣對于最終用戶的收發(fā)消息的延時就會有極大的提高。舉個例子，原 先一個阿根廷的用戶發(fā)送消息到阿根廷的用戶，網(wǎng)絡(luò)上會匯總到美國集群，然后再 分發(fā)下來。這樣整個延時就得 200ms 以上了。但是如果是一個網(wǎng)狀架構(gòu)，那它可 能就是使用阿根廷的邊緣節(jié)點(diǎn)就直接傳輸了。

　　但這并不是說不需要中心端了，  中心端會依舊保留，包括一些管理功能，離線功能 等。在邊緣計(jì)算的實(shí)踐方面最近環(huán)信在和國內(nèi)某頭部運(yùn)營商相關(guān)項(xiàng)目上做了一些非 常重大的落地。

　　2. 自動化運(yùn)維

　　如今行業(yè)都有一個共識，即運(yùn)維復(fù)雜度在迅速增加，然而傳統(tǒng)運(yùn)維已經(jīng)捉襟見肘， 為此，環(huán)信持續(xù)迭代整個監(jiān)控和報警系統(tǒng)。從早期的 Ganglia、nagios、zabbix 搭配 opentsdb、influxdb，到現(xiàn)在的 Prometheus 一統(tǒng)天下。

　　為了解決傳統(tǒng)運(yùn)維的痛點(diǎn)：7*24H 不間斷保障 ; 高一致性和高質(zhì)量的執(zhí)行結(jié)果 ; 統(tǒng) 一高效的運(yùn)維效率。環(huán)信引入了 stackstorm  自動化執(zhí)行框架來保證常見的故障可 以自動化高一致性的處理完成。

　　同時，我們投入了巨大的資源和人力在 AIOps 的落地上。AIOps ( 智能運(yùn)維 ) 能在1分 鐘 之 內(nèi) ( 包 含 了 數(shù) 據(jù) 聚 合 、上 報 、判 斷 、執(zhí) 行 、恢 復(fù) 等 整 體 端 到 端 時 間 ) 識 別 機(jī) 房 異 常并且自動運(yùn)維。我們在具體實(shí)現(xiàn)中主要是快速識別問題點(diǎn)，這個原先是非常依賴業(yè) 務(wù)運(yùn)維人員的經(jīng)驗(yàn)，以前我們內(nèi)部統(tǒng)計(jì)的時候就發(fā)現(xiàn)找到問題原因平均時間為10多 分鐘，而現(xiàn)在真正處理故障或者規(guī)避故障在幾分鐘內(nèi)就能迅速完成。

　　五、結(jié)語

　　目前環(huán)信已經(jīng)服務(wù)了 30 多萬家國內(nèi)用戶和數(shù)百家海外頭部客戶，作為 2013 年國內(nèi)最早的即時通訊云服務(wù)商，我們早在 2014 年就最先在硅谷設(shè)立了團(tuán)隊(duì)提供海外服務(wù)支持，環(huán)信國內(nèi)和海外用戶積累以及技術(shù)口碑的建立與我們的持續(xù)技術(shù)迭代優(yōu)化息息相關(guān)。

　　“寫代碼，是一件愉快的事”，這不僅是環(huán)信官網(wǎng)上的一句 slogan，也是環(huán)信在成功 路上不可缺少的一種特質(zhì)。對于環(huán)信的團(tuán)隊(duì)來說，技術(shù)的創(chuàng)新不僅僅是一份工作、一 個 KPI，更是一種理想的追求。日拱一卒無有盡，環(huán)信一直在為了用戶體驗(yàn)努力前進(jìn)!