引言

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

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

目錄

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

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

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

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

五、結(jié)語

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

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

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

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

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

以上數(shù)據(jù)來自www.cable.co.uk

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

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

以下這個(gè)網(wǎng)站是根據(jù) Wikipedia 整理的現(xiàn)在已有和在建的海底光纜。這里我們可以比 較清楚的看到，? 國際光纜主要是在亞洲和北美之間的太平洋，北美和歐洲之間的大西 洋。

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

從以上信息中我們可以看到，我們需要解決的是三個(gè)問題:

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

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

• - 路徑選擇

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

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

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

因?yàn)樗芯W(wǎng)絡(luò)傳輸?shù)难訒r(shí)最終都是跟光纖距離有關(guān)，所以我們需要將數(shù)據(jù)中心盡可能 的離用戶更近。于是我們分別在北美、歐洲、東南亞選取了3個(gè)地點(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)定性。

因此我們在出海的選擇上就選擇了如下幾個(gè)區(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(shí)消息網(wǎng)絡(luò) SD-GMN 實(shí)測數(shù)據(jù)展示:

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

這里分為兩個(gè)問題點(diǎn):

一個(gè)是本地跨運(yùn)營商的，比如印度當(dāng)?shù)鼗旧厦總€(gè)邦都有自己的運(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ù)，同時(shí)也使用自己的 FPA（終端網(wǎng)絡(luò)加速） 方案。而 FPA 使用的方式是在主要的邦都使用本地的運(yùn)營商來進(jìn)行接入，這樣在網(wǎng)絡(luò) 高峰時(shí)期會更可靠，畢竟 IX 通常的帶寬上限都不太高。

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

第三: 路徑選擇

路徑選擇分為兩步:

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

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

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

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

• - DNS 解析本身耗時(shí)。

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

同時(shí)為了解決一些新興市場國家弱網(wǎng)的情況，我們同時(shí)支持 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個(gè)加速節(jié)點(diǎn)的地址。但是我們也看到了這里有一些不合理的地方。比如我們前面列的那些網(wǎng)絡(luò)速度慢的 地區(qū)，AWS 基本沒有做覆蓋，作為創(chuàng)業(yè)公司在前期可以正常使用可能問題不明顯， 但 對于真正要面向全球化的公司后期就有點(diǎn)力不從心了。

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

下面這個(gè)是 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多個(gè)國家和地區(qū)。當(dāng)我們 SDK 支持多條路徑選擇的時(shí)候，我們就需要有相應(yīng)的路徑選擇能力，這些能力使我們 掌握了更多的調(diào)度主動(dòng)權(quán)。

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

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

• - 用戶主動(dòng)上報(bào)來的延遲數(shù)據(jù)。?

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

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

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

在2022年下半年，某海外運(yùn)營商從歐洲到新加坡突然完全不可用，而當(dāng)時(shí)很多使用 了我們多鏈路的客戶就基本沒有影響，只是有可能在第 一次連接的時(shí)候產(chǎn)生失敗后會 立刻重試后面的鏈路，保證了整體服務(wù)的可用性。我們也立刻告知了大運(yùn)營商，但是 這次運(yùn)營商由于對端鏈路宣告的原因一直過了1個(gè)多小時(shí)才恢復(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ì)，同時(shí)我們也會使用用戶上報(bào)的方式來查看各個(gè)網(wǎng)段情況。

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

基礎(chǔ)資源選點(diǎn):集團(tuán) SD-RTN? 在全球部署了250+ 數(shù)據(jù)中心，覆蓋全球200多個(gè)國 家與地區(qū)，對于主要區(qū)域的最 低要求是五地三中心的資源覆蓋，每個(gè)區(qū)域采用核心節(jié)點(diǎn) +POP 點(diǎn)的方式。這樣一旦某區(qū)域其中一個(gè)或兩個(gè)機(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)致或大或 小的一段時(shí)間的不可用。在這樣的前提下，集團(tuán) SD-RTN? 大網(wǎng)的架構(gòu)師團(tuán)隊(duì)從設(shè)計(jì) 之初就充分考慮到了基礎(chǔ)設(shè)施的不穩(wěn)定因素。如果要用幾個(gè)關(guān)鍵詞來描述 SD-RTN? ， 那就是全球覆蓋、故障實(shí)時(shí)感知與智能調(diào)度、超低延時(shí)、彈性能力、異地多活、超高 并發(fā)，而一旦基礎(chǔ)設(shè)施出現(xiàn)故障，SD-RTN? 的故障實(shí)時(shí)感知與智能調(diào)度能力以及異 地多活的構(gòu)建方式將發(fā)揮重要作用，保障服務(wù)的高可用。

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

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

3、靈活的彈性擴(kuò)縮容能力:? SD-RTN? 大網(wǎng)的每個(gè) Region 至少具備200% 的實(shí)時(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)測的角度來看，我們主要 從以下幾個(gè)方面來梳理:

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)在單個(gè) api 的整體調(diào)用鏈會非常冗長。而由于虛擬化、容器化，導(dǎo)致現(xiàn)在的網(wǎng)絡(luò)問題點(diǎn)也是越 來越多，運(yùn)維在做研發(fā)評審的時(shí)候也要重點(diǎn)關(guān)注。

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 第三方撥測

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

3.2覆蓋多種場景和地域。

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

針對不同時(shí)區(qū)客戶的需求，環(huán)信建立了全時(shí)區(qū)運(yùn)維保障團(tuán)隊(duì)，7*24H 值班，及時(shí) 處理和反饋。并在印度、美國和國內(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)目，就是從一個(gè)星形的網(wǎng)絡(luò)架構(gòu)變成一個(gè)網(wǎng)狀的網(wǎng)絡(luò)架構(gòu)。這樣對于最終用戶的收發(fā)消息的延時(shí)就會有極大的提高。舉個(gè)例子，原 先一個(gè)阿根廷的用戶發(fā)送消息到阿根廷的用戶，網(wǎng)絡(luò)上會匯總到美國集群，然后再 分發(fā)下來。這樣整個(gè)延時(shí)就得200ms 以上了。但是如果是一個(gè)網(wǎng)狀架構(gòu)，那它可 能就是使用阿根廷的邊緣節(jié)點(diǎn)就直接傳輸了。

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

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

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

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

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

五、結(jié)語

目前環(huán)信已經(jīng)服務(wù)了30多萬家國內(nèi)用戶和數(shù)百家海外頭部客戶，作為2013年國內(nèi)最早的即時(shí)通訊云服務(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)新不僅僅是一份工作、一 個(gè) KPI，更是一種理想追求。日拱一卒無有盡，環(huán)信一直在為了用戶體驗(yàn)努力前進(jìn)!

（推廣）