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

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

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

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

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

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

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

-01-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-02-

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

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

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

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

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

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

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

2.1|配置

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

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

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

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

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

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

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

3. 完善測試框架

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

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

下面我們再說一個(gè)比較基礎(chǔ)的能力：數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

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

2.3|質(zhì)量管理

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

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

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

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

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

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

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

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

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

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

2.4|成本運(yùn)營

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

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

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

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

2.5|平臺價(jià)值

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

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

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

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

過去一段時(shí)間里，我們也跟火山引擎的客戶和開發(fā)者做了一些技術(shù)上的交流，去介紹我們是怎么管理多云的。一個(gè)經(jīng)常提出來的問題是，我有什么簡單的辦法實(shí)現(xiàn)你這套系統(tǒng)，我可以不要那么復(fù)雜的前臺界面、審批流程。但是那些關(guān)鍵的能力，比如質(zhì)量管理、成本分析，我們怎么樣才能用最小的投入做起來。

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

-03-

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

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

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

3.1|資源管理

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

3.2|監(jiān)控分析

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

3.3|智能運(yùn)維

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

3.4|FinOps

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

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