背景

每天在世界各地都有海量用戶在短視頻 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)境中，也能提供適合檔位的視頻，讓使用者有順暢的觀影體驗(yàn)。

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

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

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

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

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

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

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

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

技術(shù)框架 1.0

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

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

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

當(dāng)前的痛點(diǎn)

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

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

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

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

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

對(duì)于應(yīng)急事件發(fā)生時(shí)，通?？梢苑譃橐韵聝煞N情況：基礎(chǔ)設(shè)施異常、突發(fā)流量。

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

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

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

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

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

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

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

目標(biāo)

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

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

量化指標(biāo)

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

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

架構(gòu)

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

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

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

自動(dòng)化工作流設(shè)計(jì)

整個(gè)自動(dòng)化告警處理流程可以歸納成如下圖的步驟：

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

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

Metrics Query 函數(shù)

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

• Metrics 查詢模板化，針對(duì) indicator、tags、filters 都可以撰寫 go template 語法并從 template_values 欄位帶入值。
• 支援一次查詢多種時(shí)間區(qū)段資料，利用 time_ranges 欄位下可定義如：30分鐘前、1天、1周前等......不同時(shí)間范圍，在一次函數(shù)呼叫中全部取得。
• Metrics 下鉆功能，在 drill_downs 欄位可以定義針對(duì)原有 tags 上再額外追加 tags 來取得如：原本查詢整體服務(wù)的 CPU 使用率，再額外查詢?cè)摲?wù)每個(gè)主機(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è)計(jì)了如下圖的 API ，讓閾值、同環(huán)比分析甚至是針對(duì) Metrics 中某一個(gè) Tag 的下鉆分析，都能夠定制要分析的匯總結(jié)果（最大、最小、平均、總和），此外比較運(yùn)算子跟閾值也能夠隨意調(diào)整，這對(duì)于后續(xù)要修改閾值或是分析的邏輯都提供了很大的便利性。

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

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

在 Metrics 聚合以及機(jī)器人卡片信息組裝的步驟中，不同的 Metrics 的聚合條件以及機(jī)器人卡片顯示邏輯各不相同，如果分別開發(fā)會(huì)讓整體函數(shù)的重用性以及開發(fā)效率降低，因此利用了 github.com/rogchap/v8go 這個(gè)套件開發(fā)了可以對(duì)輸入 JSON 數(shù)據(jù)動(dòng)態(tài)執(zhí)行 JavaScript 的函數(shù)來處理這一系列的用途，誰叫 JavaScript 就是處理 JSON 格式數(shù)據(jù)的最好方式呢，如下，對(duì) 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]
    ]
}

實(shí)際案例：MySQL 延遲診斷

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

圖 11：MySQL 延遲單實(shí)例異常

• 查詢延遲
  ，如下方的工作流定義，只需要從 Grafana 儀表板中把用來做圖的 Metrics 以及查詢條件、時(shí)間范圍、下鉆 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(*)

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

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)下延遲與昨日對(duì)比
          value: 200
          operator: gt
        threshold: # 整體延遲平均超過昨日的 50% 視為異常
          value: 0.5
          operator: gt
    drill_downs:
      instances:
        display:
          name: 單實(shí)例
        summary: max # 單一 MySQL 實(shí)例延遲最大超過 1s 視為異常
        threshold:
          value: 1000
          operator: gt

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

GroupResult:
  type: Task
  end: true
  atomicOperationRef: jsrun
  resultSelector:
    mysqlLatency.@: "@.data" # 從分析延遲函數(shù)輸出取得查詢結(jié)果
  variables: 
    data.@: "@"
    script: | # 針對(duì) 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)過以上三個(gè)工作流的執(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": "單實(shí)例最大延遲大于：1s",
                            "value": "單實(shí)例最大延遲：20.6s"
                        }
                    ]
                },
                "usage": {
                    "1d": "平均延遲昨日同比：62%",
                    "current": "當(dāng)前平均延遲：501.49ms"
                }
            }
        ]
    }
}

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

收益

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

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

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

總結(jié)

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