短視頻媒體處理系統應急響應自動化實踐

作者：萬俊瑋 2023-03-27 21:21:05

為了讓不同網絡條件的使用者，都能順暢地觀看這些視頻，每一條視頻的發布，都需要經過轉碼的過程，生成不同檔位的視頻，即使用戶在網絡不好的環境中，也能提供適合檔位的視頻，讓使用者有順暢的觀影體驗。

背景

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

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

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

圖 1：媒體處理系統在 AWS 公有云上的業界通用解決方案

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

在業界通用的公有云解決方案中，對開發者而言需要整合公有云上各個子系統，來完成視頻轉碼的生命周期，以及管理虛擬機計算資源，這需要較大的認知成本以及對各種云服務的學習成本，對開發者來說是比較大的負擔。

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

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

透過這兩大子系統提供的基礎能力，可以大大減少開發者的負擔以及提高功能迭代的速度。

圖 2：視頻架構團隊媒體處理系統解決方案

技術框架 1.0

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

圖 3：應急響應流程

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

當前的痛點

微服務及依賴數量多

在團隊中，服務的開發大部分走的是微服務架構，并且作為一個內部的 PaaS 平臺，勢必得提供全球跨區域的服務因此在服務本身以及基礎設施方面，需要有多區域以及多機房的部署。目前只看單一區域媒體處理任務調度的微服務就有 30 個，此外還需考慮相關的基礎設施的監控，如：數據庫、緩存、分布式鎖以及消息隊列等......

圖 4：數量龐大的微服務監控儀表板

因此，即使制作了如上圖全局視角的監控儀表板，但在應急事件發生的當下就能迅速的定位如此龐大的服務拓撲中的異常點，仍然是一個具有挑戰的任務。

不同指標比較基準不同

對于應急事件發生時，通常可以分為以下兩種情況：基礎設施異常、突發流量。

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

圖 5：數據庫延遲異常指標

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

圖 6：流量指標同比上升

錯誤排查涉及不同內部系統

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

圖 7：依賴系統錯誤指標環比上升

目標

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

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

量化指標

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

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

架構

技術架構 2.0

圖 9：改善后的應急響應流程

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

自動化工作流設計

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

工作流被告警的 Webhook 觸發，平臺攜帶告警上下文（時間、區域），以及預先設定在工作流中的 Metrics 查詢目標（為服務名稱、數據庫名稱、消息隊列 Topic）和異常閾值
使用 Parallel Task 方式觸發子工作流分別做：作業系統（CPU、Memory）、基礎設施以及微服務的告警診斷
每個告警診斷子工作流中，都會經過 Metrics 查詢、分析以及結果聚合三個階段
最后組裝要發送到應急響應群組的卡片并發送

圖 10：自動化工作流內部流程

Metrics Query 函數

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

Metrics 查詢模板化，針對 indicator、tags、filters 都可以撰寫 go template 語法并從 template_values 欄位帶入值。
支援一次查詢多種時間區段資料，利用 time_ranges 欄位下可定義如：30分鐘前、1天、1周前等......不同時間范圍，在一次函數呼叫中全部取得。
Metrics 下鉆功能，在 drill_downs 欄位可以定義針對原有 tags 上再額外追加 tags 來取得如：原本查詢整體服務的 CPU 使用率，再額外查詢該服務每個主機的 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 函數

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

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

JavaScript 執行函數

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

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

實際案例：MySQL 延遲診斷

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

圖 11：MySQL 延遲單實例異常

查詢延遲
，如下方的工作流定義，只需要從 Grafana 儀表板中把用來做圖的 Metrics 以及查詢條件、時間范圍、下鉆 tag 依照前面提到的 Metrics 查詢函數的 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 查詢函數執行完成后執行，主要需要提供顯示分析結果的文案、Metrics 的單位、以及各項異常分析的閾值。

MetricAnalysis:
  type: Task
  next: GroupResult
  atomicOperationRef: metric_analysis
  variables:
    metrics.@: "@.data" # 從查詢延遲函數輸出取得查詢結果
    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 則分析當下延遲與昨日對比
          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

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

GroupResult:
  type: Task
  end: true
  atomicOperationRef: jsrun
  resultSelector:
    mysqlLatency.@: "@.data" # 從分析延遲函數輸出取得查詢結果
  variables: 
    data.@: "@"
    script: | # 針對 IDC tag 分組結果
      data = data.map(x => x.data).flat().groupBy(x => x.template_values?.idc)
      
      // 排序資料并轉換格式
      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 : "無數據"
                  },
                  threshold: {
                      current: x.threshold,
                      "1d": x.time_ranges_percentage_difference ? x.time_ranges_percentage_difference["1d"]?.threshold : "無數據突增"
                      "instances": x.drill_downs?.instances
                  }
              }))
      }
      data

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

{
    "mysqlLatency": {
        "xx": [
            {
                "cluster": "xxxx",
                "idc": "xx",
                "threshold": {
                    "1d": "平均延遲昨日同比大于：50%",
                    "current": "當前平均延遲大于：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": "當前平均延遲：501.49ms"
                }
            }
        ]
    }
}

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

收益

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

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

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

總結

在面對如此大量的微服務以及種類繁多的基礎設施依賴環境下要能在應急事件發生時快速做決策以及執行應急操作，除了要有相對完整的監控之外，并且平時需要收集應急響應處理記錄，才能統計出高頻率發生的事件并歸納出一個自動化的排查流程來縮短 MTTR。

責任編輯：龐桂玉來源：字節跳動技術團隊

短視頻自動化實踐