字節(jié)跳動(dòng)大規(guī)模多云CDN管理與產(chǎn)品化實(shí)踐

在世界杯等大規(guī)模流量突發(fā)的情況下，作為承載抖音集團(tuán)業(yè)務(wù)核心流量的基礎(chǔ)設(shè)施，在運(yùn)維效率、質(zhì)量方面都可觀(guān)測(cè)、調(diào)度、容災(zāi)、成本可觀(guān)測(cè)與優(yōu)化方面都遇到了很多的挑戰(zhàn)。LiveVideoStackCon 2023上海站邀請(qǐng)了火山引擎邊緣云融合CDN團(tuán)隊(duì)負(fù)責(zé)人孫益星介紹火山引擎在多云應(yīng)用架構(gòu)下的CDN運(yùn)維管理解決方案。

大家好，我是來(lái)自火山引擎邊緣云融合CDN團(tuán)隊(duì)的孫益星，主要負(fù)責(zé)多云平臺(tái)的建設(shè)。

今天主要想跟大家分享的內(nèi)容包括三個(gè)部分：

第一部分是介紹下我們團(tuán)隊(duì)在過(guò)去幾年面向字節(jié)內(nèi)部業(yè)務(wù)，持續(xù)建設(shè)一個(gè)多云CDN平臺(tái)的演進(jìn)過(guò)程；

第二部分主要是介紹在這個(gè)過(guò)程中我們所面臨的一些主要難點(diǎn)和挑戰(zhàn)，以及是怎么解決的；

最后是介紹我們接下來(lái)的主要投入方向：如何把我們的能力開(kāi)放出來(lái)，以產(chǎn)品的形式提供給火山引擎的用戶(hù)和開(kāi)發(fā)者。

-01-

字節(jié)多云CDN平臺(tái)的演進(jìn)

首先為大家介紹一下我們面向內(nèi)部業(yè)務(wù)的多云CDN平臺(tái)，包括這個(gè)平臺(tái)有什么用以及要解決的到底是什么問(wèn)題。

字節(jié)跳動(dòng)有很多流量型的業(yè)務(wù)，包括抖音、頭條、西瓜視頻等。為了承載這樣的流量，團(tuán)隊(duì)使用了各種各樣流量加速的產(chǎn)品，包括靜態(tài)加速、動(dòng)態(tài)加速、域名解析、證書(shū)管理以及與各種配套的解決方案，比如源站緩存、回源調(diào)度、邊緣函數(shù)等。

從業(yè)務(wù)角度出發(fā)，如果有一個(gè)平臺(tái)能夠直接管理所有加速域名的配置，這將會(huì)帶來(lái)很大便利。只需要把源站儲(chǔ)存的信息發(fā)送給平臺(tái)，剩下的配置解析、流量分配、質(zhì)量管理等都是由平臺(tái)完成。

于是字節(jié)多云CDN平臺(tái)——我們叫做融合CDN平臺(tái)——應(yīng)運(yùn)而生，它向上承接所有業(yè)務(wù)方的CDN加速場(chǎng)景需求，底層對(duì)接不同的公有云服務(wù)，包含靜態(tài)加速、動(dòng)態(tài)加速等，這些服務(wù)本身由不同的廠(chǎng)商來(lái)提供，業(yè)務(wù)方在上層不需要關(guān)心它所對(duì)接的是哪些廠(chǎng)商，也不關(guān)心具體功能需求在不同的廠(chǎng)商上應(yīng)該分別怎么去實(shí)現(xiàn)，它要做的事情就是把需求提給平臺(tái)，然后由平臺(tái)協(xié)調(diào)不同廠(chǎng)商的資源，最終再交付給業(yè)務(wù)。對(duì)于業(yè)務(wù)方來(lái)說(shuō)，這就是一個(gè)普通的CDN服務(wù)平臺(tái)，像是一家廠(chǎng)商提供的打包的服務(wù)一樣，所以業(yè)內(nèi)有個(gè)比較通俗的稱(chēng)謂是融合CDN平臺(tái)。

業(yè)務(wù)對(duì)于這個(gè)平臺(tái)的訴求有以下幾點(diǎn)：

第一個(gè)訴求是質(zhì)量：業(yè)務(wù)對(duì)平臺(tái)的加速服務(wù)能力是有預(yù)期的，平臺(tái)有責(zé)任保障上層的每一個(gè)域名的可用性和加速效果；

第二個(gè)訴求是成本：成本越便宜越好；

第三個(gè)訴求是功能：不同業(yè)務(wù)有比較大的差異的，比如訪(fǎng)問(wèn)鑒權(quán)、回源rewrite，緩存時(shí)間等。每個(gè)業(yè)務(wù)都會(huì)有自己的設(shè)計(jì)和需求，作為融合平臺(tái)需要理解這些設(shè)計(jì)的差異，然后將它轉(zhuǎn)換成廠(chǎng)商可滿(mǎn)足的服務(wù)需求，最后實(shí)現(xiàn)、驗(yàn)證、最后交付給業(yè)務(wù)方；

第四個(gè)訴求是服務(wù)：這個(gè)是比較寬泛的概念，就是當(dāng)我們完成了一系列的資源的配置工作后，業(yè)務(wù)在日常使用中需要看監(jiān)控，看報(bào)表，刷新預(yù)熱、排查問(wèn)題，提一些on call，這些都需要對(duì)應(yīng)的服務(wù)能力來(lái)支持。

總結(jié)下來(lái)，上層業(yè)務(wù)對(duì)于平臺(tái)有四個(gè)方面的需求：質(zhì)量、成本、功能以及服務(wù)，這個(gè)是上層業(yè)務(wù)對(duì)于平臺(tái)的需求。

從平臺(tái)的角度考慮，廠(chǎng)商越少，復(fù)雜度的可能性就會(huì)越低。但由于這是一個(gè)融合平臺(tái)，所以需要從所有字節(jié)的業(yè)務(wù)體系的角度考慮問(wèn)題。

首先就是資源的保障，資源方面要能承載日常一兩百T的業(yè)務(wù)帶寬，這已經(jīng)超出了絕大部分廠(chǎng)商的資源儲(chǔ)備。

另一方面是在例如春晚、618、世界杯或者演出賽事這種大型的活動(dòng)籌備時(shí)，我們很難在單個(gè)廠(chǎng)商上找到充足的冗余，這個(gè)冗余可能是超出常規(guī)業(yè)務(wù)量的一倍或者更多的需求，總資源池子需要多個(gè)供應(yīng)商一起協(xié)調(diào)資源。

其次是質(zhì)量，用戶(hù)分布在全國(guó)各地甚至全世界，而用戶(hù)體驗(yàn)跟節(jié)點(diǎn)的訪(fǎng)問(wèn)質(zhì)量密切相關(guān)，不同廠(chǎng)商在不同地區(qū)、不同運(yùn)營(yíng)商的節(jié)點(diǎn)分布是有比較大的差異的。這會(huì)導(dǎo)致在實(shí)際的業(yè)務(wù)表現(xiàn)中，這個(gè)地區(qū)廠(chǎng)商質(zhì)量的排序是ABC，另一個(gè)地區(qū)就變成了CAB，這種情況在海外會(huì)更明顯。對(duì)于那些時(shí)刻要求最優(yōu)服務(wù)資源的業(yè)務(wù)來(lái)說(shuō)，很難通過(guò)單個(gè)廠(chǎng)商來(lái)滿(mǎn)足要求。

質(zhì)量的另一個(gè)體現(xiàn)形式是可用性，地區(qū)性的節(jié)點(diǎn)不可用是經(jīng)常發(fā)生的，這會(huì)造成業(yè)務(wù)的質(zhì)量波動(dòng)。另外，大規(guī)模的廠(chǎng)商故障也時(shí)常會(huì)發(fā)生，如果只綁定一家廠(chǎng)商，那么它故障時(shí)流量切換也會(huì)帶來(lái)明顯的質(zhì)量影響。所以對(duì)我們來(lái)說(shuō)，保證流量較為分散的分配在多個(gè)供應(yīng)商是一個(gè)必要的措施。

價(jià)格方面也有多廠(chǎng)商的考慮，價(jià)格并不是越便宜越好。不同的業(yè)務(wù)對(duì)于質(zhì)量的要求是不同的，有些對(duì)于用戶(hù)體驗(yàn)不敏感的業(yè)務(wù)會(huì)更關(guān)注成本，對(duì)質(zhì)量的要求就沒(méi)有那么高；另一部分業(yè)務(wù)為了更好的質(zhì)量，就對(duì)價(jià)格容忍度更高一些。平臺(tái)需要價(jià)格和質(zhì)量層面為不同的業(yè)務(wù)找到不同的廠(chǎng)商，選出一個(gè)最合適的方案。

最后是功能和服務(wù)的支持，有多個(gè)廠(chǎng)商就可以在我們有新的功能需求的時(shí)候，縮短從聯(lián)調(diào)到測(cè)試到上線(xiàn)的周期，在排查具體問(wèn)題的時(shí)候也能給我們更多的信息反饋。

作為一個(gè)融合平臺(tái)，我們的目標(biāo)并不是要對(duì)接盡可能多的廠(chǎng)商，或者對(duì)接盡可能少的廠(chǎng)商。而是如果需要讓整個(gè)業(yè)務(wù)達(dá)到這樣一個(gè)理想的狀態(tài)，多廠(chǎng)商基本是一個(gè)唯一的方案。在這個(gè)方案里，資源是動(dòng)態(tài)變化的，不存在一種資源在各種場(chǎng)景下都是最好的。而是不同場(chǎng)景下總有一個(gè)最合適的，而平臺(tái)在這里的職責(zé)就是向業(yè)務(wù)方高效的交付那些最合適的資源，并保證這些資源的可靠性，這是這個(gè)平臺(tái)的核心能力。

平臺(tái)的建設(shè)經(jīng)過(guò)了兩個(gè)階段：

第一階段是最原始的方式：我們會(huì)有固定的幾個(gè)SRE，每個(gè)人固定的對(duì)接幾個(gè)業(yè)務(wù)。大一些的業(yè)務(wù)可能會(huì)有多個(gè)專(zhuān)職，小一些的可能會(huì)由一個(gè)SRE對(duì)接多個(gè)業(yè)務(wù)。每個(gè)人都比較熟悉自己所對(duì)接的業(yè)務(wù)的需求和背景，按照自己的經(jīng)驗(yàn)去廠(chǎng)商控制臺(tái)上去配置，具體的要求也直接跟廠(chǎng)商的技術(shù)人員去溝通。在這個(gè)初始階段中，主要靠人的能力來(lái)支撐；

第二階段開(kāi)始有些通用的功能需求被提出放在平臺(tái)里：比如說(shuō)看域名的配置，數(shù)據(jù)，調(diào)流量。于是平臺(tái)的功能被分成不同的功能方向分別被建設(shè)。并且不同類(lèi)型的資源有不同的團(tuán)隊(duì)分別去實(shí)現(xiàn)。在這個(gè)階段中由于業(yè)務(wù)不斷有需求進(jìn)來(lái)，整個(gè)平臺(tái)的設(shè)計(jì)是在被需求拖著走的。這中間暴露出了一些問(wèn)題，比如權(quán)限設(shè)計(jì)、接口規(guī)范不統(tǒng)一、數(shù)據(jù)一致性有問(wèn)題等。

經(jīng)過(guò)這兩個(gè)階段之后，我們清晰的認(rèn)識(shí)到：需要有一個(gè)統(tǒng)一的設(shè)計(jì)，把這些需要用到的能力都集中起來(lái)。

經(jīng)過(guò)幾年的迭代，平臺(tái)完成了多個(gè)模塊的整合，形成了一個(gè)統(tǒng)一的管理平臺(tái)。大致分為權(quán)限管理、資源管理、質(zhì)量管理、統(tǒng)計(jì)監(jiān)控、廠(chǎng)商管理、運(yùn)營(yíng)分析幾個(gè)模塊。

-02-

多云管理的挑戰(zhàn)

接下來(lái)我跟大家分享下這個(gè)平臺(tái)建設(shè)中遇到的一些挑戰(zhàn)。

使用多個(gè)CDN廠(chǎng)商的情況在行業(yè)內(nèi)是一種普遍的現(xiàn)象。我們一開(kāi)始對(duì)于對(duì)接多廠(chǎng)商的認(rèn)識(shí)是打通API，向上統(tǒng)一封裝。但是在真正實(shí)踐時(shí)，我們發(fā)現(xiàn)事情的復(fù)雜度比預(yù)期要高很多。

首先，行業(yè)里面基本沒(méi)有公認(rèn)的規(guī)范。作為一個(gè)融合平臺(tái)，需要理解不同廠(chǎng)商的不同規(guī)范，逐個(gè)對(duì)接，避免業(yè)務(wù)踩坑。要在不同的廠(chǎng)商匯總的數(shù)據(jù)中，及時(shí)準(zhǔn)確的發(fā)現(xiàn)地區(qū)性的質(zhì)量波動(dòng)并定位原因等。

其次，當(dāng)資源選擇變多了之后，如何保證我們的選擇是最優(yōu)的變成了一個(gè)被大家關(guān)注的問(wèn)題。

最后還有一個(gè)重要的問(wèn)題：就是我去解決這些問(wèn)題的時(shí)候，應(yīng)該投入多少，怎么來(lái)評(píng)估產(chǎn)出，團(tuán)隊(duì)的價(jià)值如何量化。

我們從配置和數(shù)據(jù)兩個(gè)基礎(chǔ)的問(wèn)題開(kāi)始討論，再展開(kāi)到上層的方案，介紹我們質(zhì)量和成本的運(yùn)營(yíng)，最后討論平臺(tái)團(tuán)隊(duì)價(jià)值的問(wèn)題。

2.1|配置

行業(yè)內(nèi)配置的差異非常大。廠(chǎng)商之間沒(méi)有規(guī)范，對(duì)接成本高。廠(chǎng)商的開(kāi)放接口并不能覆蓋全部的能力，接口操作風(fēng)險(xiǎn)高，一次變更全網(wǎng)下發(fā)。有些功能還必須去和廠(chǎng)商的后臺(tái)溝通才能加入。

解決這個(gè)問(wèn)題分為三個(gè)方面：

1. 制定配置規(guī)范

所有廠(chǎng)商所有的功能集合盡可能開(kāi)放到一個(gè)規(guī)范里面，一次性實(shí)現(xiàn)完整的規(guī)范。即便人力開(kāi)銷(xiāo)會(huì)增大，但會(huì)變成一個(gè)相對(duì)來(lái)說(shuō)較為固定的投入，不會(huì)像以前那樣一直在反復(fù)的調(diào)整。

2. 規(guī)范變更流程

首先要求所有的配置變更必須有一個(gè)統(tǒng)一的入口。任何操作必須在內(nèi)部的平臺(tái)實(shí)現(xiàn)，不能在廠(chǎng)商操作。入口收斂之后，所有的配置只有有權(quán)限的人才能夠發(fā)起變更，需要有熟悉業(yè)務(wù)的人來(lái)審批，審批之后由SRE來(lái)觸發(fā)實(shí)際下發(fā)的流程。配置在下發(fā)完成之后，在接口層面會(huì)檢查對(duì)應(yīng)的配置是不是符合預(yù)期結(jié)果，進(jìn)行一次重新的配置讀取，廠(chǎng)商也會(huì)給到相應(yīng)的反饋。配置下發(fā)完成之后，也會(huì)做一些調(diào)度層面的準(zhǔn)備，例如新建域名或者刪除域名。

最后在交付之前，會(huì)進(jìn)行一次完整的回歸測(cè)試。這些測(cè)試需要是配置項(xiàng)級(jí)別的，比如修改源站，我們要確認(rèn)回源相關(guān)的響應(yīng)里面有沒(méi)有新源站的信息，如果是修改訪(fǎng)問(wèn)控制規(guī)則，我們要確認(rèn)對(duì)應(yīng)條件的訪(fǎng)問(wèn)是不是真的被攔截了或是被放行了。這些回歸做完之后，意味著我們這次變更從用戶(hù)側(cè)的訪(fǎng)問(wèn)效果應(yīng)該是真的達(dá)成預(yù)期了，最后才會(huì)通知業(yè)務(wù)方這個(gè)變更完成

3. 完善測(cè)試框架

最后還有一個(gè)接口的測(cè)試框架，與前面提到的回歸測(cè)試區(qū)別在于：上述的測(cè)試是面向配置結(jié)果，而這個(gè)測(cè)試框架是面向整個(gè)配置接口。因?yàn)榻涌谵D(zhuǎn)換的實(shí)現(xiàn)很重要，并且很容易出問(wèn)題，導(dǎo)致這些問(wèn)題的原因可能是我們代碼的bug，或者廠(chǎng)商API層面的一些變更導(dǎo)致不兼容的問(wèn)題、環(huán)境的變化產(chǎn)生的影響等，這些問(wèn)題如果沒(méi)有一個(gè)很好的測(cè)試框架，就只能等它出現(xiàn)問(wèn)題的時(shí)候才能發(fā)現(xiàn)。在過(guò)去的一兩年，經(jīng)過(guò)測(cè)試框架的積累，火山引擎邊緣云完成了大約2000多個(gè)case的建設(shè)，每次API上線(xiàn)都會(huì)跑一個(gè)完整的測(cè)試，每天有定時(shí)的巡查保證廠(chǎng)商測(cè)試的功能是符合預(yù)期的。這樣大量的測(cè)試積累，也幫助我們發(fā)現(xiàn)了很多問(wèn)題。

2.2|數(shù)據(jù)

下面我們?cè)僬f(shuō)一個(gè)比較基礎(chǔ)的能力：數(shù)據(jù)。

我們知道數(shù)據(jù)產(chǎn)生的源頭分別來(lái)自于服務(wù)端和客戶(hù)端。服務(wù)端從access log開(kāi)始由廠(chǎng)商轉(zhuǎn)換成兩種數(shù)據(jù)出口，離線(xiàn)日志和實(shí)時(shí)統(tǒng)計(jì)的接口，前者延遲一般是小時(shí)計(jì)甚至天級(jí)別的，后者可能可以做到分鐘級(jí)。我們平時(shí)看到的帶寬請(qǐng)求數(shù)狀態(tài)碼都是從服務(wù)端的數(shù)據(jù)源產(chǎn)生的?？蛻?hù)端則是我們自己的業(yè)務(wù)上報(bào)客戶(hù)端的訪(fǎng)問(wèn)質(zhì)量數(shù)據(jù)，同時(shí)加上自身的撥測(cè)任務(wù)巡檢，采集一些更詳細(xì)的鏈路質(zhì)量信息。

為了做統(tǒng)一的聚合分析，這些數(shù)據(jù)被統(tǒng)一存儲(chǔ)到數(shù)據(jù)中臺(tái)的統(tǒng)一數(shù)倉(cāng)里。整體來(lái)看很容易可以理解要做什么，但是跟傳統(tǒng)的大數(shù)據(jù)系統(tǒng)相比，多云平臺(tái)的工程實(shí)現(xiàn)有出現(xiàn)一些額外的問(wèn)題。

首先就是數(shù)據(jù)的延遲，接口級(jí)別的延遲雖然是分鐘級(jí)的，但是不同廠(chǎng)商的差異也比較大，有的1分鐘、有的5分鐘、有的10分鐘。但是我們自己的調(diào)度系統(tǒng)在做切換的時(shí)候希望拿到的數(shù)據(jù)是越實(shí)時(shí)越好；

其次是接口的局限，雖然接口的延遲相對(duì)日志會(huì)低一些，但是它能提供的信息量是有限的；

再次是采集能力，采集時(shí)會(huì)出現(xiàn)接口不可用，被限頻等問(wèn)題，這就要求我們的采集系統(tǒng)能夠識(shí)別哪些錯(cuò)誤需要重試，針對(duì)廠(chǎng)商主動(dòng)地控制自己的采集頻率；

最后是采集的數(shù)據(jù)質(zhì)量如何保障，廠(chǎng)商對(duì)于接口的實(shí)時(shí)性是沒(méi)有辦法100%保證的，接口報(bào)錯(cuò)很頻繁。采集數(shù)據(jù)還沒(méi)出來(lái)時(shí)，有問(wèn)題的數(shù)據(jù)如何修正，修正之前如何判斷這個(gè)數(shù)據(jù)是不是可信的。

整個(gè)建設(shè)分為三個(gè)階段：

第一階段是多源數(shù)據(jù)采集。解決包括客戶(hù)端的、服務(wù)端的、實(shí)時(shí)的、離線(xiàn)的不同數(shù)據(jù)源的適配；

第二階段是數(shù)據(jù)可靠性建設(shè)。廠(chǎng)商的數(shù)據(jù)、日志、API、賬單等數(shù)據(jù)會(huì)有對(duì)比過(guò)程，如果發(fā)現(xiàn)某個(gè)數(shù)據(jù)出現(xiàn)問(wèn)題，會(huì)發(fā)起主動(dòng)的修復(fù)。同時(shí)會(huì)對(duì)整個(gè)數(shù)據(jù)大盤(pán)進(jìn)行實(shí)時(shí)性監(jiān)控。上層系統(tǒng)會(huì)根據(jù)數(shù)據(jù)做置信度判斷。結(jié)合服務(wù)端的QPS和業(yè)務(wù)側(cè)上報(bào)的數(shù)據(jù)，判斷當(dāng)前數(shù)據(jù)是否真實(shí)可信。如果不可信，需要使用其他的數(shù)據(jù)擬合進(jìn)行針對(duì)性的修復(fù)。

第三階段是統(tǒng)一數(shù)倉(cāng)。數(shù)據(jù)采集之后，會(huì)使用統(tǒng)一的規(guī)范儲(chǔ)存到數(shù)據(jù)倉(cāng)庫(kù)里，向上會(huì)提供統(tǒng)一的API查詢(xún)和信息查詢(xún)能力。在實(shí)際操作過(guò)程中，可能會(huì)遇到API層面無(wú)法實(shí)時(shí)采集地區(qū)運(yùn)營(yíng)商級(jí)別數(shù)據(jù)的情況。業(yè)務(wù)方在查詢(xún)的時(shí)候，需要把這部分查詢(xún)實(shí)時(shí)轉(zhuǎn)化成接口的請(qǐng)求轉(zhuǎn)發(fā)給廠(chǎng)商，以達(dá)到相同的效果。

右側(cè)是整體的模式圖。底層是統(tǒng)一的數(shù)據(jù)中臺(tái)，負(fù)責(zé)數(shù)據(jù)的采集、計(jì)算、存儲(chǔ)、對(duì)外提供查詢(xún)的接口，上層包括監(jiān)控、運(yùn)營(yíng)、策略等不同模塊，面向不同的用戶(hù)提供不同的功能。

2.3|質(zhì)量管理

介紹完配置和數(shù)據(jù)這兩個(gè)基礎(chǔ)的能力，下面向上講一些業(yè)務(wù)方更關(guān)心的橫向的能力，首先是質(zhì)量保障。

作為一個(gè)融合平臺(tái)，業(yè)務(wù)方如果有感覺(jué)到質(zhì)量出現(xiàn)問(wèn)題，一般是出現(xiàn)了故障。平臺(tái)要做的事情就是把質(zhì)量的標(biāo)準(zhǔn)提高，盡可能避免對(duì)業(yè)務(wù)產(chǎn)生影響。很多問(wèn)題對(duì)上層沒(méi)有影響，但是在內(nèi)部已經(jīng)走了一個(gè)完整的故障處理流程，包括問(wèn)題的檢測(cè)發(fā)現(xiàn)、通知告警、診斷定位、預(yù)案恢復(fù)。對(duì)于一些比較明顯的問(wèn)題，不管有沒(méi)有對(duì)業(yè)務(wù)造成影響，我們也會(huì)做內(nèi)部的復(fù)盤(pán)和改進(jìn)。

在這個(gè)流程中，我們要面對(duì)各種各樣的問(wèn)題，比如如何保證檢測(cè)到的告警的有效性、縮短定位的時(shí)長(zhǎng)、提升我們無(wú)人工干預(yù)自動(dòng)恢復(fù)的比例，以及后面的復(fù)盤(pán)定級(jí)需要怎么做。這里我簡(jiǎn)單介紹下這個(gè)過(guò)程：

最基礎(chǔ)的能力是監(jiān)控的數(shù)據(jù)源，相較于剛才的多源數(shù)據(jù)采集，還定制了廠(chǎng)商側(cè)的告警上報(bào)、實(shí)時(shí)錯(cuò)誤日志推送等能力，也會(huì)結(jié)合業(yè)務(wù)側(cè)的SDK打點(diǎn)、撥測(cè)數(shù)據(jù)、以及自有節(jié)點(diǎn)的一些質(zhì)量數(shù)據(jù)。這些統(tǒng)一到數(shù)倉(cāng)里，構(gòu)建了一個(gè)比較實(shí)時(shí)的質(zhì)量庫(kù)。

往右就是數(shù)據(jù)的檢測(cè)告警，數(shù)據(jù)會(huì)根據(jù)不同的維度聚合，比如域名的、業(yè)務(wù)的、AB測(cè)試的都可能有不同的告警規(guī)則。這些規(guī)則可以是例如狀態(tài)碼異常比例、播放錯(cuò)誤率比例這類(lèi)靜態(tài)的規(guī)則，也可以是根據(jù)時(shí)序數(shù)據(jù)的特征和歷史趨勢(shì)動(dòng)態(tài)判斷告警閾值應(yīng)該是多少。我們對(duì)于周期性的和非周期的時(shí)序數(shù)據(jù)都可以支持動(dòng)態(tài)閾值的告警。

當(dāng)告警觸發(fā)后，會(huì)進(jìn)入根因分析流程，判斷這個(gè)告警產(chǎn)生的真實(shí)原因是什么。比如當(dāng)業(yè)務(wù)方客戶(hù)端錯(cuò)誤率上升時(shí)，需要判斷對(duì)應(yīng)的是哪個(gè)域名，這個(gè)域名是放在哪個(gè)廠(chǎng)商上，對(duì)應(yīng)的各個(gè)維度的監(jiān)控是否正常。這些判斷會(huì)涉及到時(shí)序數(shù)據(jù)異常檢測(cè)、不同數(shù)據(jù)的相關(guān)性分析等等?；旧衔覀兂Ｒ?jiàn)的異常都會(huì)有完整的根因分析邏輯，直到排查出最終的問(wèn)題，比如到底是廠(chǎng)商側(cè)的問(wèn)題還是我們?cè)凑镜膯?wèn)題還是地區(qū)性的網(wǎng)絡(luò)問(wèn)題。

這樣最終在告警發(fā)送時(shí)，已經(jīng)帶著完整的診斷結(jié)果通知我們的SRE。比如，當(dāng)前的現(xiàn)象是客戶(hù)端錯(cuò)誤率上升，原因是源站問(wèn)題，對(duì)應(yīng)中間的檢查結(jié)果是怎樣的。這時(shí)候我們可以直接通知業(yè)務(wù)方處理自己的源站問(wèn)題了。

如果是廠(chǎng)商的問(wèn)題，例如地區(qū)性的節(jié)點(diǎn)不可用，除了會(huì)通知廠(chǎng)商之外，我們還會(huì)自動(dòng)去執(zhí)行一些預(yù)案。最常見(jiàn)的就是切流，把對(duì)應(yīng)地區(qū)的調(diào)度權(quán)重從問(wèn)題廠(chǎng)商上調(diào)走，同時(shí)保持對(duì)廠(chǎng)商對(duì)應(yīng)地區(qū)的主動(dòng)探測(cè)，當(dāng)廠(chǎng)商的流量正常時(shí)再切回來(lái)。最后這個(gè)質(zhì)量問(wèn)題的影響時(shí)長(zhǎng)、故障定級(jí)等等會(huì)在質(zhì)量系統(tǒng)中有明確的體現(xiàn)，廠(chǎng)商側(cè)也可以根據(jù)我們反饋的信息進(jìn)行檢查和改進(jìn)。

這樣最終整套的系統(tǒng)就實(shí)現(xiàn)了閉環(huán)，質(zhì)量數(shù)據(jù)的檢測(cè)會(huì)觸發(fā)告警和根因，自動(dòng)的根因分析和預(yù)案執(zhí)行能夠自動(dòng)的改善質(zhì)量數(shù)據(jù)。

過(guò)去幾年我們一直在改善閉環(huán)里的執(zhí)行效率和準(zhǔn)確性，讓更多的問(wèn)題能夠被自動(dòng)預(yù)案來(lái)覆蓋。目前的告警準(zhǔn)確性，就是那些波動(dòng)異常經(jīng)過(guò)智能閾值判斷，以及降噪處理后，被確認(rèn)真的是異常的占了98%以上，80%以上的告警會(huì)帶著準(zhǔn)確的根因分析信息一同提供給SRE和技術(shù)支持的同事。

2.4|成本運(yùn)營(yíng)

成本運(yùn)營(yíng)在過(guò)去幾年一直是一個(gè)令人非常頭疼的問(wèn)題。由于數(shù)據(jù)的敏感性，我們最初做了很多的限制，導(dǎo)致相關(guān)的技術(shù)只能局限在一個(gè)很小的范圍內(nèi)討論。但是這個(gè)團(tuán)隊(duì)要解決的工程問(wèn)題還是非常復(fù)雜的，需要充分的投入。比如每個(gè)月一到月初就要花大量的時(shí)間去校驗(yàn)廠(chǎng)商的賬單數(shù)據(jù)是不是準(zhǔn)確，還有像成本分?jǐn)偂⒉▌?dòng)歸因等方面都存在很大的挑戰(zhàn)。解決辦法一種是讓業(yè)務(wù)方熟悉我們的成本邏輯，自己去分析，另一種方式是從平臺(tái)層面提供統(tǒng)一的能力來(lái)幫助業(yè)務(wù)。

首先需要明確的是數(shù)據(jù)因?yàn)楹湾X(qián)相關(guān)，確實(shí)是很敏感的，因?yàn)樯婕暗缴虅?wù)的保密問(wèn)題等，但是錢(qián)可以拆分成兩部分：一部分是單價(jià)，一部分是用量。單價(jià)只有有權(quán)限的人才能可見(jiàn)，所以我們額外做了一套系統(tǒng)，把價(jià)格隔離起來(lái)管理。用量信息則沒(méi)有那么敏感，大部分業(yè)務(wù)方都會(huì)接觸用量信息。將單價(jià)隔離開(kāi)以后，平臺(tái)的負(fù)責(zé)人就可以深度的參與到用量的優(yōu)化之中。這些用量，比如邊緣帶寬、存儲(chǔ)、專(zhuān)線(xiàn)會(huì)分別對(duì)應(yīng)到不同的分?jǐn)?a href="http://wenjunhu.com/v/tag/2562/" target="_blank">算法中去，讓每一種資源的用量都有一個(gè)固定的邏輯分?jǐn)偟阶钚〉某杀締卧?，一般就是域名。域名在總的用量上面占多大比例是可以明確的，成本單元有自己的組織歸屬，包括葉子結(jié)點(diǎn)和跟結(jié)點(diǎn)的歸屬都可以映射過(guò)去。

對(duì)于業(yè)務(wù)方來(lái)說(shuō)，可以直觀(guān)的看到每月的帶寬上漲到底是哪些業(yè)務(wù)甚至是域名導(dǎo)致的問(wèn)題，這個(gè)就是我們近期面向業(yè)務(wù)方開(kāi)放的成本分析能力。

在排查問(wèn)題的時(shí)候，每一層的數(shù)據(jù)都是可校驗(yàn)的。所有域名的總用量加和，一定等于我們分?jǐn)偳暗目傆昧考雍?。每個(gè)資源的總用量，乘以對(duì)應(yīng)的單價(jià)，一定等于對(duì)應(yīng)的資源花掉的錢(qián)。做數(shù)據(jù)校驗(yàn)的時(shí)候，只需要一層層的校驗(yàn)就好了。

2.5|平臺(tái)價(jià)值

剛才說(shuō)了我們作為一個(gè)多云管理的平臺(tái)，資源是來(lái)自于底層的廠(chǎng)商，流量來(lái)自于上層的業(yè)務(wù)，平臺(tái)做的事情只是把這個(gè)資源更好的交付給業(yè)務(wù)，協(xié)助我們的業(yè)務(wù)使用好這些資源。

在這個(gè)過(guò)程中我們投入了接口開(kāi)發(fā)、QA、數(shù)據(jù)工程、運(yùn)營(yíng)分析、調(diào)度系統(tǒng)、質(zhì)量監(jiān)控、權(quán)限管理還有前臺(tái)、文檔等等，但是向上還是要落實(shí)到業(yè)務(wù)層面可以感知到的收益上，就是我的質(zhì)量是不是有保障，還有我的成本是不是在持續(xù)的優(yōu)化。

所以一直以來(lái)衡量我們的團(tuán)隊(duì)產(chǎn)出的指標(biāo)一直都是一些相對(duì)固定的維度，質(zhì)量、成本、效率、穩(wěn)定性。

最近一年來(lái)整套的系統(tǒng)設(shè)計(jì)才逐漸完整，把線(xiàn)上問(wèn)題收斂穩(wěn)定下來(lái)。到現(xiàn)在為止依然要投入很多的人力去維護(hù)我們配置接口的迭代、數(shù)據(jù)的保障、以及平臺(tái)化的功能建設(shè)。另一方面，正是因?yàn)橛辛藰I(yè)務(wù)體量的支撐，我們團(tuán)隊(duì)的投入價(jià)值才能最大化。

過(guò)去一段時(shí)間里，我們也跟火山引擎的客戶(hù)和開(kāi)發(fā)者做了一些技術(shù)上的交流，去介紹我們是怎么管理多云的。一個(gè)經(jīng)常提出來(lái)的問(wèn)題是，我有什么簡(jiǎn)單的辦法實(shí)現(xiàn)你這套系統(tǒng)，我可以不要那么復(fù)雜的前臺(tái)界面、審批流程。但是那些關(guān)鍵的能力，比如質(zhì)量管理、成本分析，我們?cè)趺礃硬拍苡米钚〉耐度胱銎饋?lái)。

所以在去年我們對(duì)系統(tǒng)又重新做了一次改造，把底層的關(guān)鍵能力，數(shù)據(jù)系統(tǒng)配置系統(tǒng)調(diào)度系統(tǒng)還有中間的一些核心解決方案，逐步的開(kāi)放成我們的產(chǎn)品能力，放到火山引擎上面提供出來(lái)。這個(gè)就是我們的多云CDN產(chǎn)品。

-03-

火山引擎多云產(chǎn)品能力

多云CDN底層還是對(duì)接不同資源廠(chǎng)商，包含不同服務(wù)類(lèi)型。但中間層正在經(jīng)歷一個(gè)深度的改造，從右到左不斷地將我們的核心能力孵化為開(kāi)放的產(chǎn)品；從左到右，以上云的形式不斷地將我們已有系統(tǒng)的實(shí)現(xiàn)以更加規(guī)范的設(shè)計(jì)和概念定義去做重構(gòu)，讓一些原本比較模糊的內(nèi)部概念能夠以一個(gè)內(nèi)外部用戶(hù)能理解的方式去運(yùn)行。

在這套系統(tǒng)之上，現(xiàn)有的融合平臺(tái)會(huì)變得越來(lái)越薄，未來(lái)可能只會(huì)保留一些跟內(nèi)部業(yè)務(wù)深度耦合的部分，比如流程的審批、內(nèi)部業(yè)務(wù)的預(yù)案等。業(yè)務(wù)方還是使用我們?nèi)诤掀脚_(tái)的界面，但是這個(gè)平臺(tái)的底層未來(lái)會(huì)和火山引擎的客戶(hù)一樣是我們這個(gè)多云產(chǎn)品的用戶(hù)，通過(guò)它提供的開(kāi)放接口能力去管理各自的資源。

3.1|資源管理

多云CDN產(chǎn)品去年剛剛上線(xiàn)，就已經(jīng)完成了基本的資源管理能力。平臺(tái)現(xiàn)在支持已經(jīng)完成接口規(guī)范化改造的國(guó)內(nèi)外廠(chǎng)商。在接口能力上配置的統(tǒng)一查詢(xún)功能已經(jīng)完成，也支持了像域名創(chuàng)建、證書(shū)更新這樣的能力，更完整的配置變更流程正在做產(chǎn)品化的改造。在資源管理的基礎(chǔ)上，業(yè)務(wù)組織、權(quán)限、統(tǒng)計(jì)聚合的能力也完成了，一些拓展的功能，比如在TOS文件變更的時(shí)候同時(shí)刷新多個(gè)廠(chǎng)商的CDN，我們稱(chēng)之為聯(lián)動(dòng)刷新的能力，有了多云的平臺(tái)就比較容易實(shí)現(xiàn)，目前正在被實(shí)際使用。

3.2|監(jiān)控分析

在數(shù)據(jù)的能力上，統(tǒng)計(jì)的API和日志的API在第一階段都已經(jīng)支持。剛剛完成了數(shù)據(jù)采集的能力，可以直接幫助用戶(hù)從API采集數(shù)據(jù)然后存下來(lái)，在這個(gè)數(shù)據(jù)能力之上，用戶(hù)可以做不同廠(chǎng)商數(shù)據(jù)的統(tǒng)一聚合，或者靈活的對(duì)比不同廠(chǎng)商的數(shù)據(jù)。未來(lái)我們還會(huì)開(kāi)放自定義報(bào)表的能力，幫助我們的客戶(hù)分析全局的業(yè)務(wù)數(shù)據(jù)。

3.3|智能運(yùn)維

在監(jiān)控能力上，有了剛才說(shuō)的數(shù)據(jù)采集的能力，加上我們的撥測(cè)能力，以及未來(lái)會(huì)開(kāi)放的客戶(hù)數(shù)據(jù)上傳的通道，我們把內(nèi)部的智能告警、根因分析、自動(dòng)容災(zāi)的預(yù)案也都放到了產(chǎn)品上，未來(lái)會(huì)結(jié)合我們自己的質(zhì)量庫(kù)幫助我們的客戶(hù)更好的分析業(yè)務(wù)質(zhì)量、提升服務(wù)的可靠性。

3.4|FinOps

近期，成本管理能力已經(jīng)上線(xiàn)?？偟膩?lái)說(shuō)就是將成本運(yùn)營(yíng)能力開(kāi)放，結(jié)合數(shù)據(jù)采集能力和賬單分析能力，幫助客戶(hù)準(zhǔn)確的分析賬單構(gòu)成、業(yè)務(wù)成本構(gòu)成和波動(dòng)的原因。未來(lái)還會(huì)結(jié)合不同的計(jì)費(fèi)模型，幫助業(yè)務(wù)方更好的分析成本，組成對(duì)應(yīng)的優(yōu)化方案。

上述就是整個(gè)多云CDN產(chǎn)品的演進(jìn)過(guò)程?；鹕揭娑嘣艭DN產(chǎn)品在去年上線(xiàn)，目前還在快速地迭代過(guò)程中。我們期望和我們的廠(chǎng)商、開(kāi)發(fā)者一起，為火山引擎的用戶(hù)，實(shí)現(xiàn)一個(gè)規(guī)范、統(tǒng)一、安全、高效、智能的多云流量管理平臺(tái)。