動手點關(guān)注

干貨不迷路

背景

每天在世界各地都有海量用戶在短視頻 App 上分享充滿創(chuàng)意的視頻或是生活中的精彩故事。

由于使用者所在的環(huán)境不可控（高鐵、電梯等弱網(wǎng)環(huán)境），若直接播放原始畫質(zhì)的視頻，可能導(dǎo)致觀看影片的過程中出現(xiàn)卡頓甚至無法播放的情形，導(dǎo)致觀影感受不佳。為了讓不同網(wǎng)絡(luò)條件的使用者，都能順暢地觀看這些視頻，每一條視頻的發(fā)布，都需要經(jīng)過轉(zhuǎn)碼的過程，生成不同檔位的視頻，即使用戶在網(wǎng)絡(luò)不好的環(huán)境中，也能提供適合檔位的視頻，讓使用者有順暢的觀影體驗。

針對視頻轉(zhuǎn)碼的場景，目前業(yè)界通用的解決方案大多為原始視頻上傳到物件儲存后，通過事件觸發(fā)媒體處理過程，當(dāng)中可能涉及使用工作流系統(tǒng)做媒體處理任務(wù)的調(diào)度或是編排，處理完成的視頻存檔至物件儲存后再透過內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）分發(fā)給觀影者。

圖 1：媒體處理系統(tǒng)在 AWS 公有云上的業(yè)界通用解決方案

[來源]https://aws.amazon.com/media-services

在業(yè)界通用的公有云解決方案中，對開發(fā)者而言需要整合公有云上各個子系統(tǒng)，來完成視頻轉(zhuǎn)碼的生命周期，以及管理虛擬機(jī)計算資源，這需要較大的認(rèn)知成本以及對各種云服務(wù)的學(xué)習(xí)成本，對開發(fā)者來說是比較大的負(fù)擔(dān)。

在字節(jié)，視頻架構(gòu)團(tuán)隊經(jīng)過長年的技術(shù)積累，在視頻這個領(lǐng)域已經(jīng)形成了一個內(nèi)部多媒體處理 PaaS 平臺。用戶通過上傳系統(tǒng)上傳視頻到物件儲存中，接著會觸發(fā)媒體處理平臺的任務(wù)編排系統(tǒng)，下發(fā)轉(zhuǎn)碼、生成動圖、封面照等任務(wù)到具有海量資源的計算資源池，最后透過內(nèi)容分發(fā)網(wǎng)絡(luò)分發(fā)給觀影者。多媒體處理 PaaS 平臺主要由兩大子系統(tǒng)構(gòu)成，工作流系統(tǒng)與計算平臺，并提供多租戶的接入方式，用以支撐字節(jié)整個生態(tài)系的視頻處理需求。

計算平臺主要提供了一個大型的計算資源池，將各種異構(gòu)資源（CPU、GPU）封裝起來，讓團(tuán)隊內(nèi)媒體處理專業(yè)的開發(fā)者無需關(guān)注計算資源整合相關(guān)工作，可以專注于開發(fā)具有各種原子能力的無伺服器函數(shù)，提供轉(zhuǎn)碼、生成封面照、生成動圖等豐富功能。工作流系統(tǒng)則提供了任務(wù)編排的能力，能夠定義視頻上傳后需要執(zhí)行各種媒體處理任務(wù)的先后順序，并將任務(wù)下發(fā)到計算平臺利用大型的計算資源池來完成媒體處理的工作。

透過這兩大子系統(tǒng)提供的基礎(chǔ)能力，可以大大減少開發(fā)者的負(fù)擔(dān)以及提高功能迭代的速度。

圖 2：視頻架構(gòu)團(tuán)隊媒體處理系統(tǒng)解決方案

技術(shù)框架 1.0

這么龐大的一個線上系統(tǒng)，如何保持它的穩(wěn)定性，并且在線上有任何異常情況時，能夠準(zhǔn)確、快速地處理問題，減少對用戶的影響就顯得特別重要。針對部署在世界各地的多媒體處理 PaaS 平臺都會定義服務(wù)水準(zhǔn)指標(biāo) (SLI)，并以此為基礎(chǔ)定義服務(wù)水準(zhǔn)目標(biāo) (SLO)，并配置針對 SLO 的適當(dāng)報警規(guī)則。

圖 3：應(yīng)急響應(yīng)流程

如圖 3 所示，當(dāng)服務(wù)發(fā)生異常，例如：5分鐘內(nèi)請求正確率低于 99.9% 時，觸發(fā)報警，并發(fā)送 Webhook 消息給團(tuán)隊內(nèi)研發(fā)的應(yīng)急響應(yīng)中心平臺，平臺會將當(dāng)下的值班人員創(chuàng)立一個告警處理群組，并把后續(xù)相關(guān)的報警信息都聚合到群組中，隨后就由 SRE 開始介入處理。當(dāng)前流程在創(chuàng)建告警處理群組之后，主要仰賴 SRE 去自主搜集與應(yīng)急事件相關(guān)的異常指標(biāo)，缺乏自動化工具提前做訊息的匯總，可能導(dǎo)致整體事故處理流程需要花費較多時間先梳理目前異常的指標(biāo)才能做事故止損操作。

當(dāng)前的痛點

微服務(wù)及依賴數(shù)量多

在團(tuán)隊中，服務(wù)的開發(fā)大部分走的是微服務(wù)架構(gòu)，并且作為一個內(nèi)部的 PaaS 平臺，勢必得提供全球跨區(qū)域的服務(wù)因此在服務(wù)本身以及基礎(chǔ)設(shè)施方面，需要有多區(qū)域以及多機(jī)房的部署。目前只看單一區(qū)域媒體處理任務(wù)調(diào)度的微服務(wù)就有 30 個，此外還需考慮相關(guān)的基礎(chǔ)設(shè)施的監(jiān)控，如：數(shù)據(jù)庫、緩存、分布式鎖以及消息隊列等......

圖 4：數(shù)量龐大的微服務(wù)監(jiān)控儀表板

因此，即使制作了如上圖全局視角的監(jiān)控儀表板，但在應(yīng)急事件發(fā)生的當(dāng)下就能迅速的定位如此龐大的服務(wù)拓?fù)渲械漠惓｜c，仍然是一個具有挑戰(zhàn)的任務(wù)。

不同指標(biāo)比較基準(zhǔn)不同

對于應(yīng)急事件發(fā)生時，通常可以分為以下兩種情況：基礎(chǔ)設(shè)施異常、突發(fā)流量。

第一個例子：數(shù)據(jù)庫基礎(chǔ)設(shè)施。通常在正常運作下的查詢延遲都會處于一個固定的水平，例如 10ms 。延遲上升分為：整體數(shù)據(jù)庫延遲上升（可能是當(dāng)下負(fù)載高），部分實例延遲上升（可能是部門網(wǎng)段有抖動）。

圖 5：數(shù)據(jù)庫延遲異常指標(biāo)

第二個例子，突發(fā)流量。作為一個內(nèi)部的 PaaS 平臺，勢必是提供了多租戶的功能以服務(wù)字節(jié)內(nèi)諸多團(tuán)隊的需求，且當(dāng)租戶數(shù)量達(dá)到一個量級，逐個租戶去了解他們何時有活動或是有突發(fā)流量已經(jīng)是不太合乎經(jīng)濟(jì)效益的事情，以下方的例子為例，可以看到指標(biāo)呈現(xiàn)以天為周期的規(guī)律分布，但可以看到紅框處紫色的指標(biāo)較昨天明顯得更多，這稱之為昨日同比上升。

圖 6：流量指標(biāo)同比上升

錯誤排查涉及不同內(nèi)部系統(tǒng)

第三個例子，涉及依賴系統(tǒng)的錯誤。以下圖為例，紅框處的錯誤量明顯比過去半小時要高得多，這稱之為環(huán)比上升。針對這種情況則需要到內(nèi)部的 PaaS 平臺去查詢詳細(xì)的錯誤碼以及對應(yīng)的錯誤日志。

圖 7：依賴系統(tǒng)錯誤指標(biāo)環(huán)比上升

目標(biāo)

以上三種情況，以現(xiàn)有的監(jiān)控以及排查手段，在應(yīng)急事件發(fā)生時，整個排查的過程需要比對多個儀表板甚至是不停地在儀表板上切換不同的查詢時間段來比較指標(biāo)的正常性，更甚者需要打開其他內(nèi)部系統(tǒng)來查找日志，這都大大延長了定位問題以及做應(yīng)急處理的決策時間。

因此如果能夠把上面的排查工作做一定程度的自動化，那就能大大提高 SRE 成員在值班時對照值班手冊 SOP（標(biāo)準(zhǔn)作業(yè)流程）來排查的速度，并能減少值班的辛苦感受。

量化指標(biāo)

平均修復(fù)時間（Mean time to repair，MTTR）包含了發(fā)現(xiàn)故障（Identify）、故障定位止損（Know）以及故障恢復(fù)（Fix）的整體時間。導(dǎo)入自動化排查工具的主要目的是減少故障定位止損的時間，目前系統(tǒng)都有設(shè)定針對 SLO 目標(biāo)的告警發(fā)生以及恢復(fù)時間的數(shù)據(jù)統(tǒng)計，因此決定以 MTTR 這個指標(biāo)來作為這次自動化系統(tǒng)導(dǎo)入的成果量化指標(biāo)。

圖 8：平均修復(fù)時間在事故時間序中的范圍

架構(gòu)

技術(shù)架構(gòu) 2.0

圖 9：改善后的應(yīng)急響應(yīng)流程

視頻架構(gòu)穩(wěn)定性團(tuán)隊研發(fā)的應(yīng)急響應(yīng)中心平臺（Emergency Center）內(nèi)建了名為 SOP Engine 的集成解決方案，提供了 SDK 讓 SRE 的成員能快速開發(fā)，如：Metrics 查詢、分析、發(fā)起 HTTP 請求等通用的無服務(wù)器函數(shù)，并能夠利用 yaml 定義狀態(tài)機(jī)工作流編排，來實現(xiàn)自定義的告警診斷或是應(yīng)急處理預(yù)案的工作流編排使用。

自動化工作流設(shè)計

整個自動化告警處理流程可以歸納成如下圖的步驟：

1. 工作流被告警的 Webhook 觸發(fā)，平臺攜帶告警上下文（時間、區(qū)域），以及預(yù)先設(shè)定在工作流中的 Metrics 查詢目標(biāo)（為服務(wù)名稱、數(shù)據(jù)庫名稱、消息隊列 Topic）和異常閾值

2. 使用 Parallel Task 方式觸發(fā)子工作流分別做：作業(yè)系統(tǒng)（CPU、Memory）、基礎(chǔ)設(shè)施以及微服務(wù)的告警診斷

3. 每個告警診斷子工作流中，都會經(jīng)過 Metrics 查詢、分析以及結(jié)果聚合三個階段

4. 最后組裝要發(fā)送到應(yīng)急響應(yīng)群組的卡片并發(fā)送

圖 10：自動化工作流內(nèi)部流程

Metrics Query 函數(shù)

Metrics 查詢函數(shù)設(shè)計了如下方范例的 API，能對接字節(jié)基于 OpenTSDB 搭建的 Metrics 平臺，主要提供以下幾種功能來大幅提升本函數(shù)的重用性。

• Metrics 查詢模板化，針對 indicator、tags、filters 都可以撰寫 go template 語法并從 template_values 欄位帶入值。

• 支援一次查詢多種時間區(qū)段資料，利用 time_ranges 欄位下可定義如：30分鐘前、1天、1周前等......不同時間范圍，在一次函數(shù)呼叫中全部取得。

• Metrics 下鉆功能，在 drill_downs 欄位可以定義針對原有 tags 上再額外追加 tags 來取得如：原本查詢整體服務(wù)的 CPU 使用率，再額外查詢該服務(wù)每個主機(jī)的 CPU 使用率。

{
????"zone":?"xx",
????"indicator":?"service.thrift.{{?.service_name?}}.call.success.throughput",
????"template_values":?{
????????"service_name":?"my_service_name",
????????"to":?"redis_cache"
????},
????"aggregator":?"avg",
????"tags":?{
????????"idc":?"literal_or(*)",
????????"cluster":?"literal_or(*)",
????????"to":?"literal_or({{?.to?}})"
????},
????"filters":?{
????????"cluster":?"my_cluster_name"
????},
????"rate_option":?{
????????"counter":?false,
????????"diff":?false
????},
????"start_at":?"now-5m",
????"end_at":?"now",
????"time_ranges":?{
????????"5mago":?{
????????????"start_at":?"now-10m",
????????????"end_at":?"now-5m"
????????}
????},
????"drill_downs":?{
????????"instances":?{
????????????"top":?1,
????????????"top_aggregator":?"max",
????????????"tags":?{
????????????????"host":?"literal_or(*)"
????????????}
????????}
????}
}

Metrics Analysis 函數(shù)

Metrics 分析函數(shù)設(shè)計了如下圖的 API ，讓閾值、同環(huán)比分析甚至是針對 Metrics 中某一個 Tag 的下鉆分析，都能夠定制要分析的匯總結(jié)果（最大、最小、平均、總和），此外比較運算子跟閾值也能夠隨意調(diào)整，這對于后續(xù)要修改閾值或是分析的邏輯都提供了很大的便利性。

{
????"display":?{?//?必填
????????"namePrefix":?"今日",?//?可選，顯示名稱前綴，默認(rèn)：當(dāng)前
????????"name":?"延遲",?//?必填，分析結(jié)果指標(biāo)顯示名稱
????????"format":?"latencyMs"?//?可選，分析結(jié)果指標(biāo)顯示格式，不填則按原樣輸出，只顯示到小數(shù)第二位，格式支援?default,?percent,?latency,?latencyMs
????},
????"summary":?"avg",?//?必填，對哪一個匯總資料做顯示及分析?sum,?avg,?max,?min,?count
????"threshold":?{?//?可選，閾值分析
????????"value":?4,?//?必填，原始數(shù)值閾值
????????"operator":?"gt"?//?必填，比較運算子，支援?gt,?gte,?lt,?lte,?eq,?ne
????},
????"time_ranges_percentage_difference":?{?//?可選，分析不同時間偏移資料
????????"5mago":?{?//?鍵名，可自行指定名稱
????????????"display":?{?//?必填
????????????????"name":?"5分環(huán)比"?//?必填，分析結(jié)果顯示名稱
????????????},
????????????"summary":?"avg",?//?必填，對哪一個匯總資料做顯示及分析?sum,?avg,?max,?min,?count
????????????"precondition":?{?//?可選，前置條件，原始?metrics?滿足條件后才進(jìn)行變化率分析
????????????????"value":?4,?//?必填，閾值
????????????????"operator":?"gt"?//?必填，比較運算子，支援?gt,?gte,?lt,?lte,?eq,?ne
????????????},
????????????"threshold":?{?//?可選，變化率閾值
????????????????"value":?0.1,?//?必填，閾值
????????????????"operator":?"gt"?//?必填，比較運算子，支援?gt,?gte,?lt,?lte,?eq,?ne
????????????}
????????}
????},
????"drill_downs":?{?//?可選，分析不同下鉆資料
????????"instances":?{?//?鍵名，可自行指定名稱
????????????"display":?{?//?必填
????????????????"name":?"單實例"?//?必填，分析結(jié)果顯示名稱
????????????},
????????????"summary":?"max",?//?必填，對哪一個匯總資料做顯示及分析?sum,?avg,?max,?min,?count
????????????"threshold":?{?//?可選，閾值分析
????????????????"value":?10,?//?可選，單實例原始數(shù)值閾值
????????????????"stdDiff":?1,?//?可選，單實例原始數(shù)值與其他下鉆值平均比較標(biāo)準(zhǔn)差閾值
????????????????"operator":?"gt"?//?必填，比較運算子，支援?gt,?gte,?lt,?lte,?eq,?ne
????????????}
????????}
????},
????"filter":?true,?//?可選，只顯示有達(dá)到閾值的分析結(jié)果
????"metrics":?[...]?//?略，Metrics?查詢函數(shù)返回的資料內(nèi)容
}

JavaScript 執(zhí)行函數(shù)

在 Metrics 聚合以及機(jī)器人卡片信息組裝的步驟中，不同的 Metrics 的聚合條件以及機(jī)器人卡片顯示邏輯各不相同，如果分別開發(fā)會讓整體函數(shù)的重用性以及開發(fā)效率降低，因此利用了 github.com/rogchap/v8go 這個套件開發(fā)了可以對輸入 JSON 數(shù)據(jù)動態(tài)執(zhí)行 JavaScript 的函數(shù)來處理這一系列的用途，誰叫 JavaScript 就是處理 JSON 格式數(shù)據(jù)的最好方式呢，如下，對 JSON 內(nèi)的 Array 數(shù)據(jù)都能用原生的 JavaScript 做群組、排序、倒序以及映射的操作，十分便利。

{
????"script":?"data.flat().map(x?=>?x?*?2).filter(x?=>?x?>?5).reverse()",
????"data":?[
????????[1,2,3,4,5],
????????[6,7,8,9]
????]
}

實際案例：MySQL 延遲診斷

下圖是一個實際異常診斷的例子如何用上述三個函數(shù)做組合，下圖以 MySQL 延遲作為例子，可以看到大部分的 MySQL 延遲正常范圍在 1s 以下，其中一臺主機(jī)的延遲突然上升至 20.6s 這在應(yīng)急響應(yīng)中是需要被主動發(fā)現(xiàn)出來并且是有可能造成應(yīng)急事件的異常。

圖 11：MySQL 延遲單實例異常

• 查詢延遲

  ，如下方的工作流定義，只需要從 Grafana 儀表板中把用來做圖的 Metrics 以及查詢條件、時間范圍、下鉆 tag 依照前面提到的 Metrics 查詢函數(shù)的 API 定義填入就能做 Metrics 查詢。

MetricQuery:
??type:?Task
??next:?MetricAnalysis
??atomicOperationRef:?metric_query
??variables:
????zone:?xxx
????indicator:?mysql.latency.pct99
????tags:
??????idc:?literal_or(*)
??????db:?my_database
????aggregator:?avg
????start_at:?now-30m
????end_at:?now
????time_ranges:
??????1d:
????????start_at:?now-1d30m
????????end_at:?now-1d
????drill_downs:
??????instances:
????????top:?30
????????top_aggregator:?max
????????tags:
??????????host:?literal_or(*)
??????????port:?literal_or(*)

• 分析延遲

  ，下方的工作流定義，會在 Metrics 查詢函數(shù)執(zhí)行完成后執(zhí)行，主要需要提供顯示分析結(jié)果的文案、Metrics 的單位、以及各項異常分析的閾值。

MetricAnalysis:
??type:?Task
??next:?GroupResult
??atomicOperationRef:?metric_analysis
??variables:
????metrics.@:?"@.data"?#?從查詢延遲函數(shù)輸出取得查詢結(jié)果
????filter:?true
????display:
??????name:?延遲
??????format:?latencyMs
????summary:?avg?#?整體延遲平均超過?500ms?視為異常
????threshold:
??????value:?500
??????operator:?gt
????time_ranges_percentage_difference:
??????1d:
????????display:
??????????name:?昨日同比
????????summary:?avg
????????precondition:?#?整體延遲平均超過?200ms?則分析當(dāng)下延遲與昨日對比
??????????value:?200
??????????operator:?gt
????????threshold:?#?整體延遲平均超過昨日的?50%?視為異常
??????????value:?0.5
??????????operator:?gt
????drill_downs:
??????instances:
????????display:
??????????name:?單實例
????????summary:?max?#?單一?MySQL?實例延遲最大超過?1s?視為異常
????????threshold:
??????????value:?1000
??????????operator:?gt

• 分組結(jié)果

  ，這個工作流步驟相對簡單，主要針對 Metrics 分析函數(shù)的結(jié)果，以特定的 tag 做分組并排序，在這個例子里，我們希望利用 IDC（機(jī)房）來做分組的鍵，因此在以下工作流定義中就把執(zhí)行上述邏輯的 JavaScript 代碼引入即可。

GroupResult:
??type:?Task
??end:?true
??atomicOperationRef:?jsrun
??resultSelector:
????mysqlLatency.@:?"@.data"?#?從分析延遲函數(shù)輸出取得查詢結(jié)果
??variables:?
????data.@:?"@"
????script:?|?#?針對?IDC?tag?分組結(jié)果
??????data?=?data.map(x?=>?x.data).flat().groupBy(x?=>?x.template_values?.idc)
??????
??????//?排序資料并轉(zhuǎn)換格式
??????for?(const?key?in?data)?{
??????????data[key]?=?data[key].
??????????????sort((a,?b)?=>?a.original_value?-?b.original_value).
??????????????reverse().
??????????????map(x?=>?({
??????????????????...x.tags,
??????????????????usage:?{
??????????????????????current:?x.value,
??????????????????????"1d":?x.time_ranges_percentage_difference???x.time_ranges_percentage_difference["1d"]?.value?:?"無數(shù)據(jù)"
??????????????????},
??????????????????threshold:?{
??????????????????????current:?x.threshold,
??????????????????????"1d":?x.time_ranges_percentage_difference???x.time_ranges_percentage_difference["1d"]?.threshold?:?"無數(shù)據(jù)突增"
??????????????????????"instances":?x.drill_downs?.instances
??????????????????}
??????????????}))
??????}
??????data

最終經(jīng)過以上三個工作流的執(zhí)行，可以得到以下資料輸出結(jié)果，基本上有異常的 Metrics 以及診斷結(jié)論都已經(jīng)結(jié)構(gòu)化的方式做好分組以及過濾，并附有診斷結(jié)論，可以作為聊天機(jī)器人訊息的輸入使用。

{
????"mysqlLatency":?{
????????"xx":?[
????????????{
????????????????"cluster":?"xxxx",
????????????????"idc":?"xx",
????????????????"threshold":?{
????????????????????"1d":?"平均延遲昨日同比大于：50%",
????????????????????"current":?"當(dāng)前平均延遲大于：1s",
????????????????????"instances":?[
????????????????????????{
????????????????????????????"name":?"mysql.latency.pct99{cluster=xxxx,dc=xx,host=xxx-xxx-xxx-001}",
????????????????????????????"original_value":?20600.546,
????????????????????????????"tags":?{
????????????????????????????????"cluster":?"xxxx",
????????????????????????????????"idc":?"xx",
????????????????????????????????"host":?"xxx-xxx-xxx-001"
????????????????????????????},
????????????????????????????"threshold":?"單實例最大延遲大于：1s",
????????????????????????????"value":?"單實例最大延遲：20.6s"
????????????????????????}
????????????????????]
????????????????},
????????????????"usage":?{
????????????????????"1d":?"平均延遲昨日同比：62%",
????????????????????"current":?"當(dāng)前平均延遲：501.49ms"
????????????????}
????????????}
????????]
????}
}

而針對應(yīng)用容器相關(guān)的指標(biāo)診斷，如：CPU、Memory，或是應(yīng)用本身的 Metrics 指標(biāo)都是遵照類似的邏輯來編排工作流，只要替換查詢的 Metrics 以及診斷的閾值即可。

收益

有了以上的自動化分析工具，在視頻架構(gòu)團(tuán)隊的日常應(yīng)急響應(yīng)流程中得到了很大的收益，在一次應(yīng)急事件中，某一個 IDC 的網(wǎng)路發(fā)生故障，如下圖：某一個 IP 的錯誤以及延遲都特別高，在應(yīng)急響應(yīng)處理群中自動觸發(fā)的診斷都能直接把這類異常直接發(fā)現(xiàn)出來，就能馬上針對異常的實例進(jìn)行處置操作。

圖 12：自動化工具在事故群組中展示異常指標(biāo)的匯總訊息

本自動化流程完整導(dǎo)入后統(tǒng)計 MTTR 縮短成效如下圖，從2022年10月初開始導(dǎo)入到目前2023年1月底，每雙周統(tǒng)計一次 MTTR：從初期的 70 分鐘，到目前 17 分鐘，總體下降約 75.7%。

總結(jié)

在面對如此大量的微服務(wù)以及種類繁多的基礎(chǔ)設(shè)施依賴環(huán)境下要能在應(yīng)急事件發(fā)生時快速做決策以及執(zhí)行應(yīng)急操作，除了要有相對完整的監(jiān)控之外，并且平時需要收集應(yīng)急響應(yīng)處理記錄，才能統(tǒng)計出高頻率發(fā)生的事件并歸納出一個自動化的排查流程來縮短 MTTR。文章來源地址http://www.zghlxwxcb.cn/news/detail-424651.html