基于字節(jié)跳動分布式治理的理念，數(shù)據(jù)平臺數(shù)據(jù)治理團(tuán)隊(duì)自研了 SLA 保障平臺，目前已在字節(jié)內(nèi)部得到廣泛使用，并支持了絕大部分?jǐn)?shù)據(jù)團(tuán)隊(duì)的 SLA 治理需求，每天保障的 SLA 鏈路數(shù)量過千，解決了數(shù)據(jù) SLA 難對齊、難保障、難管理的問題。

一、背景介紹

SLA（Service Level Agreement）：服務(wù)級別協(xié)議，對互聯(lián)網(wǎng)公司來說是網(wǎng)站服務(wù)可用性的保證。數(shù)據(jù) SLA，即數(shù)據(jù)可用性保證，一般以數(shù)據(jù)產(chǎn)出時(shí)間作為 SLA。

在海量數(shù)據(jù)任務(wù)開發(fā)場景中，因業(yè)務(wù)多樣化、數(shù)據(jù)量大、數(shù)據(jù)任務(wù)復(fù)雜等問題，導(dǎo)致數(shù)據(jù)任務(wù)鏈路依賴復(fù)雜、鏈路長、跨團(tuán)隊(duì)節(jié)點(diǎn)依賴多，因此，在實(shí)際開發(fā)運(yùn)維過程中，任務(wù)負(fù)責(zé)人為保證自身數(shù)據(jù)準(zhǔn)時(shí)產(chǎn)出，會遇到如下困難：

溝通成本高：任務(wù)負(fù)責(zé)人嘗試與上游任務(wù)負(fù)責(zé)人約定 SLA，但由于上游任務(wù)數(shù)多（可至上千個(gè)），且跨越多個(gè)團(tuán)隊(duì)，溝通成本非常高

權(quán)責(zé)不清晰：由于鏈路復(fù)雜，如何制定 SLA？誰來負(fù)責(zé)保障 SLA？

運(yùn)維壓力大：無法及時(shí)發(fā)現(xiàn)上游任務(wù)延遲，導(dǎo)致下游任務(wù)負(fù)責(zé)人承擔(dān)絕大部分運(yùn)維壓力，且運(yùn)維效果較差，往往發(fā)現(xiàn)延遲已經(jīng)錯過了補(bǔ)救的時(shí)間。

為解決上述問題，字節(jié)跳動數(shù)據(jù)平臺通過自研的 SLA 保障平臺，規(guī)范并推進(jìn)各業(yè)務(wù)團(tuán)隊(duì)進(jìn)行任務(wù)鏈路治理，有效保障數(shù)據(jù)的 SLA，數(shù)據(jù) SLA 達(dá)標(biāo)率達(dá)到 99.1%。

理想的一組任務(wù)的完成時(shí)間與對應(yīng) SLA 之間的關(guān)系如下圖所示，即各個(gè)任務(wù)及其上游任務(wù)都在對應(yīng)的 SLA 之前完成，這也是平臺的治理目標(biāo)。

二、應(yīng)用場景

SLA 保障平臺除了解決上文的困難外，對不同的用戶還有以下使用場景：

• 數(shù)據(jù)業(yè)務(wù)方：“我們團(tuán)隊(duì)的業(yè)務(wù)很依賴一份重要數(shù)據(jù)，希望能對其進(jìn)行保障，希望上游能承諾 SLA”
• 數(shù)據(jù)負(fù)責(zé)人：“我們團(tuán)隊(duì)有很多對外承諾 SLA 的數(shù)據(jù)，希望能有一個(gè)平臺對 SLA 進(jìn)行集中管理，并能提供一些統(tǒng)計(jì)大盤、風(fēng)險(xiǎn)分析等內(nèi)容”
• 數(shù)據(jù)治理方：“我們希望能提升團(tuán)隊(duì)內(nèi)核心數(shù)據(jù)的數(shù)據(jù)質(zhì)量，對齊進(jìn)行 SLA 管理，及時(shí)發(fā)現(xiàn)風(fēng)險(xiǎn)，并進(jìn)行事故復(fù)盤和改進(jìn)，最終不斷優(yōu)化數(shù)據(jù)質(zhì)量”

根據(jù)以上不同角色需求，SLA 保障平臺提出自身解決方案。針對團(tuán)隊(duì)數(shù)據(jù)治理需求，平臺提供完善的治理看板能力；針對任務(wù)鏈路復(fù)雜導(dǎo)致的 SLA 難達(dá)成，平臺通過各項(xiàng)優(yōu)化，簡化了 SLA 達(dá)成流程；針對下游任務(wù)運(yùn)維壓力大的問題，平臺優(yōu)化通知體系，及時(shí)播報(bào) SLA 狀態(tài)。

那么，SLA 保障平臺有哪些核心模塊？平臺是如何運(yùn)轉(zhuǎn)的呢？

三、核心概念介紹

3.1 角色：

• 目前 SLA 保障平臺的核心角色有三類，分別是：
• 申報(bào)人：即 SLA 提申報(bào)的人，一般是數(shù)據(jù)業(yè)務(wù)方，其提申報(bào)的目的是保障業(yè)務(wù)數(shù)據(jù)的 SLA；
• 管理員：滿足數(shù)據(jù)治理方的需求設(shè)置的角色，負(fù)責(zé)申報(bào)的審核、批準(zhǔn)、管理、統(tǒng)計(jì)、登記、復(fù)盤等，其目的是不斷優(yōu)化所屬團(tuán)隊(duì)的數(shù)據(jù)質(zhì)量。

任務(wù)負(fù)責(zé)人：即待保障 SLA 數(shù)據(jù)鏈路中的任務(wù) owner，負(fù)責(zé)確定及簽署所負(fù)責(zé)任務(wù)的 SLA，平臺會按照其簽署的 SLA 進(jìn)行保障；

3.2 任務(wù)：

即產(chǎn)出數(shù)據(jù)的任務(wù)，通過數(shù)據(jù)任務(wù)的元信息，可構(gòu)建整條數(shù)據(jù)生產(chǎn)鏈路的完整 DAG。在本平臺中，所涉及的任務(wù)元信息一般需要包含以下內(nèi)容：

3.3 申報(bào)單

申報(bào)人提起的一次申報(bào)內(nèi)容，被稱為一個(gè)“申報(bào)單”，一個(gè)申報(bào)單一般包含的核心內(nèi)容如下：

四、申報(bào)簽署流程詳解

SLA 保障的前提是先達(dá)成 SLA 協(xié)議。在 SLA 保障平臺中，以申報(bào)單簽署的形式達(dá)成 SLA 協(xié)議。平臺核心特點(diǎn)是優(yōu)化了 SLA 達(dá)成的流程，先通過 “系統(tǒng)卡點(diǎn)計(jì)算” 減少待簽署任務(wù)的數(shù)量，再通過 “SLA 推薦計(jì)算” 自動簽署部分任務(wù)，最后為剩下的待簽署任務(wù)智能提供合適的 SLA，進(jìn)一步降低簽署成本。

在申報(bào)簽署環(huán)節(jié)中，各個(gè)環(huán)節(jié)的變化將通過通知模塊傳遞信息給相應(yīng)負(fù)責(zé)人，實(shí)時(shí)通知降低信息交流成本，加速了 SLA 的達(dá)成。

4.1 流程簡介

上圖為申報(bào)簽署的一般流程，在實(shí)際操作時(shí)，如任務(wù)鏈路變化、SLA 時(shí)間商討待確認(rèn)等特殊情況，申報(bào)簽署流程會有微調(diào)。

首先需要申報(bào)人填寫申報(bào)單，在申報(bào)人提交后，系統(tǒng)會根據(jù)申報(bào)單中的申報(bào)任務(wù)拉取上游的所有任務(wù)，構(gòu)成一個(gè)完整的 DAG，并進(jìn)行任務(wù)鏈路分析。鏈路分析的結(jié)果是后續(xù)算法的前提，也是管理員審批時(shí)的重要參考因素，可以讓用戶快速了解到自身任務(wù)在鏈路中所處的位置及上下游運(yùn)行情況。

在理想情況下，為保證申報(bào)任務(wù)順利推進(jìn)，需要該任務(wù)的所有上游任務(wù)都簽署 SLA 才算完成簽署。而鏈路復(fù)雜導(dǎo)致的上游任務(wù)多、跨團(tuán)隊(duì)溝通成本高、SLA 難以確定等問題，成了整體 SLA 達(dá)成的最大阻礙。通過“卡點(diǎn)計(jì)算”與“SLA 推薦計(jì)算”可以跨越此阻礙。

4.2 卡點(diǎn)計(jì)算

本系統(tǒng)采取一定的“卡點(diǎn)策略”，計(jì)算出此 DAG 中的部分需要被簽署的任務(wù)，此類任務(wù)稱為“卡點(diǎn)任務(wù)”，這個(gè)過程稱之為“卡點(diǎn)計(jì)算”。計(jì)算得到卡點(diǎn)任務(wù)后，在簽署過程中可以忽略其他任務(wù)，從而大大降低簽署成本。

一個(gè)申報(bào)單會關(guān)聯(lián)多個(gè)任務(wù)（即該申報(bào)任務(wù)及其上游的卡點(diǎn)任務(wù)），同理一個(gè)任務(wù)也會關(guān)聯(lián)多個(gè)申報(bào)單，因?yàn)樵谝粋€(gè) DAG 中，申報(bào)任務(wù)可能從任意節(jié)點(diǎn)起，因此二者是 N:N 的關(guān)系。

當(dāng)兩個(gè)申報(bào)單有部分任務(wù)列表重合時(shí)，如 Task4 關(guān)聯(lián)了兩個(gè)申報(bào)單，該任務(wù)的申報(bào)方、治理團(tuán)隊(duì)等數(shù)據(jù)是兩個(gè)申報(bào)單的去重合集，而等級則取所有申報(bào)單中最高者。

4.3 SLA 推薦計(jì)算

利用任務(wù)及其上下游任務(wù)的歷史運(yùn)行信息，再結(jié)合推薦算法，得到該任務(wù)的推薦 SLA，這個(gè)過程稱之為SLA 推薦計(jì)算。

在負(fù)責(zé)人簽署 SLA 之前，SLA 推薦算法會智能計(jì)算每個(gè)任務(wù)的推薦的 SLA，并以此進(jìn)一步通過算法自動簽署部分待簽署的任務(wù)，進(jìn)一步降低簽署成本。據(jù)平臺數(shù)據(jù)統(tǒng)計(jì)，此功能可以自動簽署近40% 的 SLA，是最核心的功能之一。

而對于剩余的待簽署任務(wù)，會將算法推薦的 SLA 提供給任務(wù)負(fù)責(zé)人。任務(wù)負(fù)責(zé)人可以直接選擇直接用這個(gè) SLA 簽署，也可以自行決定 SLA。一般情況下，智能推薦的 SLA 已經(jīng)能滿足絕大多數(shù)的需求，通過推薦 SLA，任務(wù)負(fù)責(zé)人更快的做出簽署決定，再次降低了簽署成本。

4.4 系統(tǒng)保障監(jiān)控

當(dāng)一個(gè)申報(bào)單完成簽署之后，平臺將對申報(bào)單中的任務(wù)進(jìn)行保障服務(wù)。保障服務(wù)的核心就是通過監(jiān)控 SLA 的狀態(tài)變化及時(shí)播報(bào)消息通知，為相應(yīng)負(fù)責(zé)人及時(shí)提供一手資料，以此降低運(yùn)維成本。對于一個(gè)離線任務(wù)，評價(jià)其 SLA 主要是依據(jù)其完成時(shí)間和其所承諾的 SLA 來判斷，SLA 的狀態(tài)分為四種，分別是：

• 未到 SLA：即當(dāng)前時(shí)間，任務(wù)未產(chǎn)出，且還未到 SLA 時(shí)間（繼續(xù)監(jiān)控）；
• 已達(dá)成：即任務(wù)已完成，且完成時(shí)間在所承諾的 SLA 之前（發(fā)送就緒通知）；
• 已延遲：即任務(wù)未完成，且當(dāng)前時(shí)間已在所承諾的 SLA 之后（發(fā)送延遲通知）；
• 已延遲（產(chǎn)出）：即任務(wù)已完成，但完成時(shí)間在所承諾的 SLA 之后（發(fā)送延遲產(chǎn)出通知）；

從下圖可以看到在任務(wù)達(dá)成、未達(dá)成兩種情況下，隨著時(shí)間的推移，其 SLA 狀態(tài)的變化。

SLA 的實(shí)時(shí)狀態(tài)是數(shù)據(jù)業(yè)務(wù)方所需要的重要信息，因此平臺會所有任務(wù)的 SLA 進(jìn)行監(jiān)控，并在 SLA 狀態(tài)變化時(shí)實(shí)時(shí)對相關(guān)人員發(fā)送通知，相關(guān)人員根據(jù)收到的通知知曉 SLA 的具體情況，并能做出應(yīng)對措施。

五、復(fù)盤管理詳解

復(fù)盤管理是本平臺提供的響應(yīng)式治理服務(wù)的實(shí)現(xiàn)方式，是數(shù)據(jù)治理方的重點(diǎn)關(guān)注對象。復(fù)盤管理又分為問題管理與事故管理，問題管理側(cè)重于“為什么”——即整理分析 SLA 破線的原因，事故管理側(cè)重于“怎么做”——即 SLA 破線事故之后該怎么治理。

5.1 問題管理

問題管理模塊的整體目標(biāo)是滿足數(shù)據(jù)治理團(tuán)隊(duì)對 SLA 問題的登記管理，支持對登記后的問題數(shù)據(jù)進(jìn)行不同維度根因數(shù)據(jù)分析，輔助用戶對問題根因進(jìn)行治理，沉淀治理問題經(jīng)驗(yàn)。

平臺在進(jìn)行系統(tǒng)保障監(jiān)控時(shí)，會在 SLA 延遲時(shí)進(jìn)行通知播報(bào)，并持續(xù)提醒負(fù)責(zé)人進(jìn)行問題登記。在問題登記時(shí)，平臺提供了一組根因樹輔助登記，明確問題根因類別，方便統(tǒng)計(jì)分析。任務(wù)負(fù)責(zé)人進(jìn)行問題登記后，累積數(shù)據(jù)展示在問題看板上，數(shù)據(jù)治理方由此做問題分析歸納總結(jié)。

平臺保證了 SLA 延遲記錄與問題之間是一一對應(yīng)的關(guān)系，并在問題看板上關(guān)聯(lián)了 SLA 詳情信息，包括任務(wù)鏈路、負(fù)責(zé)人、任務(wù)起止時(shí)間等。

問題登記往往是一個(gè)從多到少的過程，前期出現(xiàn)的問題在逐一治理解決后，將對后期的治理起到很好的參考警示作用，它的數(shù)據(jù)價(jià)值如下：

• 不同 SLA 問題類型的趨勢分布，針對性的治理問題
• 相同根因引發(fā)了多少 SLA 問題，涉及影響多少數(shù)據(jù)資產(chǎn)
• 哪些數(shù)據(jù)資產(chǎn)經(jīng)常出現(xiàn) SLA 問題，問題的分類以及是什么根因造成的
• SLA 問題經(jīng)驗(yàn)總結(jié)，方便類似問題發(fā)生后，后期做推薦輔助快速定位根因

根據(jù)平臺運(yùn)營的記錄顯示，常見的問題有資源隊(duì)列阻塞、上游任務(wù)故障、數(shù)據(jù)傾斜等。某數(shù)據(jù)團(tuán)隊(duì)雙月問題登記總結(jié)如下，問題數(shù)量和問題根因種類得到了有效的收斂：

5.2 事故管理

事故管理用于記錄 SLA 破線事故的復(fù)盤與改進(jìn)管理，每個(gè)事故至少對應(yīng)一條 SLA 問題記錄，而每個(gè) SLA 問題不一定會造成事故。

事故可以在任意節(jié)點(diǎn)進(jìn)行，一般在 SLA 破線并造成實(shí)際的業(yè)務(wù)影響之后，需要進(jìn)行事故登記，事故登記同樣會關(guān)聯(lián)相關(guān)的 SLA 信息。一個(gè)事故的處理流程如下所示：

如圖所示，事故主要包含 SLA 事故明細(xì)、SLA 事故根因、改進(jìn)計(jì)劃及 SLA 消耗這幾部分，在這其中可以關(guān)注以下幾點(diǎn)：

• 事故在登記時(shí)，會根據(jù)事故明細(xì)確認(rèn)事故根因，并讓相應(yīng)負(fù)責(zé)人提出改進(jìn)計(jì)劃
• 用戶可以訂閱事故，在事故的復(fù)盤狀態(tài)及其改進(jìn)計(jì)劃的完成狀態(tài)變化時(shí)，都會通知訂閱人
• 任務(wù)的改進(jìn)計(jì)劃在完成前，每日都會提醒計(jì)劃負(fù)責(zé)人，直到計(jì)劃完成為止

SLA 事故管理平臺的數(shù)據(jù)是數(shù)據(jù)治理方治理成果的重要依據(jù)，也是整個(gè) SLA 保障平臺使用效果的體現(xiàn)，它的數(shù)據(jù)價(jià)值如下：

• 對事故的復(fù)盤歸檔管理，方便后期隨時(shí)查閱，定位相關(guān) SLA 信息
• 針對不同數(shù)據(jù)團(tuán)隊(duì)發(fā)生 SLA 事故的整體情況進(jìn)行對比查看，互相借鑒
• 對事故的改進(jìn)計(jì)劃管理跟蹤，驗(yàn)收 SLA 的治理效果

以下是某個(gè)團(tuán)隊(duì)的雙月事故統(tǒng)計(jì)：

通過上述數(shù)據(jù)可知，本平臺有效保障了核心任務(wù)的穩(wěn)定產(chǎn)出，輔助降低了穩(wěn)定性事故發(fā)生的概率，現(xiàn)在每雙月該類型事故數(shù)量長期維持在個(gè)位數(shù)。

六、平臺架構(gòu)總結(jié)

平臺整體主要分為基礎(chǔ)組件、規(guī)劃式治理服務(wù)、響應(yīng)式治理服務(wù)三大塊，系統(tǒng)組件架構(gòu)圖如下：

6.1 規(guī)劃式治理服務(wù)

所謂“規(guī)劃式治理”，即在問題發(fā)現(xiàn)前治理，通過主動規(guī)劃約定 SLA 的形式保障任務(wù)產(chǎn)出。規(guī)劃式治理是 SLA 相關(guān)問題發(fā)現(xiàn)的過程。

規(guī)劃式治理服務(wù)即“提供以申報(bào)單簽署的方式達(dá)成 SLA 協(xié)議的服務(wù)”，包括在此過程中申報(bào)單的生命周期管理操作，申報(bào)任務(wù)的鏈路分析，以及達(dá)成 SLA 之后的系統(tǒng)保障監(jiān)控，服務(wù)于“申報(bào)簽署流程”。

6.2 響應(yīng)式治理服務(wù)

響應(yīng)式治理是指通過復(fù)盤管理模塊對 SLA 相關(guān)的事故/問題進(jìn)行登記、管理、復(fù)盤的過程。在發(fā)現(xiàn) SLA 相關(guān)問題之后，需要對問題進(jìn)行處理，形成一個(gè)完整的閉環(huán)，在發(fā)現(xiàn)問題后進(jìn)行的治理成為響應(yīng)式治理。

響應(yīng)式治理服務(wù)模塊抽象出問題登記和事故管理兩個(gè)模塊，更加靈活的服務(wù)于數(shù)據(jù) SLA 的問題歸因與事故統(tǒng)計(jì)。

6.3 基礎(chǔ)組件

基礎(chǔ)組件提供了配置、播報(bào)、看板等基本功能模塊服務(wù)，為規(guī)劃式、響應(yīng)式治理服務(wù)提供了必要支撐，是整體 SLA 保障服務(wù)不可或缺的一環(huán)。

6.3.1 系統(tǒng)配置

• 治理團(tuán)隊(duì)配置

治理團(tuán)隊(duì)為 SLA 的管理團(tuán)隊(duì)，每個(gè)申報(bào)單都需要綁定一個(gè)治理團(tuán)隊(duì)，治理團(tuán)隊(duì)主要負(fù)責(zé)審批申報(bào)單。

• 數(shù)據(jù)團(tuán)隊(duì)配置

數(shù)據(jù)團(tuán)隊(duì)為數(shù)據(jù)的歸屬方，一個(gè)數(shù)據(jù)團(tuán)隊(duì)對應(yīng)一個(gè)業(yè)務(wù)團(tuán)隊(duì)，數(shù)據(jù)團(tuán)隊(duì)的設(shè)計(jì)保障了各個(gè)業(yè)務(wù)團(tuán)隊(duì)獨(dú)立治理的需求。平臺通過對數(shù)據(jù)團(tuán)隊(duì)的靈活配置支持，可以更細(xì)粒度的劃分?jǐn)?shù)據(jù)與任務(wù)的歸屬，解決權(quán)責(zé)不清的問題。

• 訂閱配置

訂閱管理是配置訂閱信息的平臺，本平臺的訂閱為 SLA 監(jiān)控的通知播報(bào)，通過訂閱管理可以將通知指定發(fā)動到個(gè)人或者群組。訂閱管理是 SLA 監(jiān)控保障服務(wù)不可或缺的一環(huán)。

6.3.2 通知播報(bào)

通知播報(bào)是本平臺所提供的基礎(chǔ)通知能力，是降低溝通成本、實(shí)現(xiàn)保障服務(wù)、提升用戶體驗(yàn)的重要手段。在重要節(jié)點(diǎn)變更、用戶操作、SLA 狀態(tài)變化等情況下，都會進(jìn)行通知播報(bào)。通知播報(bào)形式多樣，根據(jù)不同的場景，有普通文本消息、加急消息、卡片通知、郵件通知、電話通知等。

6.3.3 SLA 大盤展板

SLA 大盤展板是數(shù)據(jù)治理方最為關(guān)心的部分，展板提供當(dāng)日 SLA 整體統(tǒng)計(jì)信息、SLA 延遲趨勢分析信息、SLA 等級分布明細(xì)、任務(wù)健康度明細(xì)、團(tuán)隊(duì) SLA 達(dá)成信息統(tǒng)計(jì)等豐富信息，是很多團(tuán)隊(duì)數(shù)據(jù)治理指標(biāo)重要參照來源。

七、未來展望

未來字節(jié)跳動數(shù)據(jù)治理團(tuán)隊(duì)將持續(xù)打磨 SLA 保障平臺，在卡點(diǎn)策略優(yōu)化、SLA 推薦算法優(yōu)化、基于 SLA 的任務(wù)管理機(jī)制上持續(xù)提升技術(shù)能力：

• 卡點(diǎn)策略優(yōu)化：卡點(diǎn)計(jì)算作為優(yōu)化簽署流程中核心一環(huán)，卡點(diǎn)策略優(yōu)化代表著簽署流程進(jìn)一步的簡化，未來可以探索利用更多有效的信息優(yōu)化卡點(diǎn)策略。
• SLA 推薦算法優(yōu)化：SLA 推薦算法是本平臺的核算算法之一，已經(jīng)申請了專利。隨著業(yè)務(wù)的拓展，以及不同種類任務(wù)的支持，此算法還有廣闊的提升空間，如進(jìn)一步提升自動簽署率，進(jìn)一步提升準(zhǔn)確率等。
• 基于 SLA 的任務(wù)管理機(jī)制：任務(wù)簽署 SLA 信息之后，即可依托 SLA 信息進(jìn)行資源調(diào)度優(yōu)化，并進(jìn)行資源分配傾斜。

同時(shí)，文中闡述的部分能力已經(jīng)通過火山引擎 DataLeap 產(chǎn)品向企業(yè)客戶開放，更多關(guān)于SLA治理的資料請關(guān)注腳本之家其它相關(guān)文章！