背景

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

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

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

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

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

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

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

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

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

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

技術(shù)框架 1.0

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

圖 3：應急響應流程

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

當前的痛點

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

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

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

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

不同指標比較基準不同

對于應急事件發(fā)生時，通?？梢苑譃橐韵聝煞N情況：基礎設施異常、突發(fā)流量。

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

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

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

圖 6：流量指標同比上升

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

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

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

目標

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

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

量化指標

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

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

架構(gòu)

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

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

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

自動化工作流設計

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

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

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

Metrics Query 函數(shù)

Metrics 查詢函數(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 來取得如：原本查詢整體服務的 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 函數(shù)

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

{
    "display": { // 必填
        "namePrefix": "今日", // 可選，顯示名稱前綴，默認：當前
        "name": "延遲", // 必填，分析結(jié)果指標顯示名稱
        "format": "latencyMs" // 可選，分析結(jié)果指標顯示格式，不填則按原樣輸出，只顯示到小數(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 滿足條件后才進行變化率分析
                "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ù)值與其他下鉆值平均比較標準差閾值
                "operator": "gt" // 必填，比較運算子，支援 gt, gte, lt, lte, eq, ne
            }
        }
    },
    "filter": true, // 可選，只顯示有達到閾值的分析結(jié)果
    "metrics": [...] // 略，Metrics 查詢函數(shù)返回的資料內(nèi)容
}

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

在 Metrics 聚合以及機器人卡片信息組裝的步驟中，不同的 Metrics 的聚合條件以及機器人卡片顯示邏輯各不相同，如果分別開發(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 以下，其中一臺主機的延遲突然上升至 20.6s 這在應急響應中是需要被主動發(fā)現(xiàn)出來并且是有可能造成應急事件的異常。

圖 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 則分析當下延遲與昨日對比
          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（機房）來做分組的鍵，因此在以下工作流定義中就把執(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é)論，可以作為聊天機器人訊息的輸入使用。

{
    "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"
                }
            }
        ]
    }
}

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

收益

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

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

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

總結(jié)

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