1-5-10 快恢在數字化安全生產平臺 DPS 中的設計與落地

作者：銀桑

背景

11 月 5 日，在 2022 杭州 · 雲棲大會上，數字化安全生產平臺 DPS 重磅發佈，助力傳統運維向 SRE 轉型，在數字化安全生產平臺 DPS 重磅發佈中提到了 DPS 誕生的背景，希望解決的企業問題以及核心的功能點，其中提到了 DPS 目前的兩大業務場景:"1-5-10"故障快恢和"變更三板斧"故障預防，本文將闡述 “1-5-10”故障快恢場景的背後的設計與實現。

1-5-10 介紹

1-5-10 對應故障的“1 分鐘發現-5 分鐘響應-10 分鐘恢復”，是定義故障處理的時效性目標。在阿里巴巴內部經過多年的實踐，1-5-10 早已成爲各個業務穩定性、基礎設施穩定性以及大促保障的重要牽引指標，目的是縮短故障恢復時長(MTTR)，降低故障影響。DPS 通過將阿里雲高可用產品體系與阿里巴巴安全生產理論體系相結合，實現了 1-5-10 的產品化落地。

下圖是 1-5-10 的產品架構圖：

1-5-10 場景包括事前穩定性分析，事中應急處理，事後持續運營三個步驟。

事前穩定性分析是 1-5-10 的前提，包括業務分析，風險分析以及組織分析三個維度。DPS 通過專家諮詢服務加產品線，服務組，業務場景拓撲等產品功能相結合的方式來實現。
事中應急處理是 1-5-10 的核心，包括以下幾個部分：
- 故障發現：通過建立圍繞業務應用的全鏈路監控能力，能夠實時監控業務健康度，如發現穩定性問題通報至應急保障服務組進行排查，降低故障發生的可能性。
- 故障響應：通過建立應急響應渠道和全鏈路故障定位能力，能夠快速拉通故障排查人員，基於 AIOps 智能故障定位和基於 ChatOps 進行故障狀態更新和通知流轉，提升故障處理效率。
- 故障快恢：通過建立完善的故障快恢體系，基於方案內置豐富的快恢能力，能夠根據不同的故障類型智能化推薦合適的快恢預案，縮短故障恢復時長。
事後的持續運營是 1-5-10 的效果度量，包括以下幾個部分：
- 結果指標：用來衡量穩定性保障的結果，核心是業務可用率，重大故障收斂數目以及無重大故障時長。
- 能力指標：從提升穩定性能力的角度來分析，核心就是 1-5-10 的達標率，並且支持從故障，事件，組織，人員，團隊等多維度來進行分析。

以上是 1-5-10 場景的整體產品能力介紹，下面展開介紹 1 分鐘發現，5 分鐘響應以及 10 分鐘快恢是如何設計與落地。

1 分鐘發現

要做到故障的一分鐘發現，首先需要有完善的監控/告警體系，其次需要有明確的故障結構化定義。在實際應用中，會遇到如下的一些問題：

面臨問題

業務監控的複雜性導致問題的淹沒

一個生產業務監控，涵蓋了各式各樣的指標，從業務層面、應用層面、服務層面、系統層面,基礎設施層面等等，比如下面：

網絡傳輸監控(丟包,延遲)
服務器系統狀態(CPU、load)
虛擬機，容器監控
應用運行狀態(成功率、qps)
業務運行狀態(訂單創建量…)
用戶體驗(白屏、內容錯誤）

當故障發生的時候，可能上述任何一層的指標都會出現異常，如果不能對指標進行合理的分層和針對性的建設，就會被淹沒在一堆指標告警監控裏面，不但可能忽略真正的問題，還有可能使得運維人員難以應付。

監控數據和故障不能有效關聯

什麼是故障? 在日常運營中，無論什麼原因導致服務中斷、服務品質下降或用戶服務體驗下降的現象，稱爲故障。只有清楚定義業務故障，並且將故障監控進行關聯才能做到真正故障的快速發現。然而在生產業務中，往往只聚焦於監控治理，而忽略了故障定義的重要性。

解決思路

監控指標分類

可以將指標能否直接反饋業務功能是否可用，將指標分爲如下類別：

業務指標：業務指標可以直觀的反饋業務或者系統功能是否正常可用，常用的指標有業務請求吞吐量、業務成功率、業務錯誤率、業務性能；另外對於金融類的業務來說，數據正確性也是要觀測的指標，比如資金對賬、數據一致性等。業務指標的監控方式優先採用日誌監控，通過對業務日誌的加工，識別出成功率、響應率、業務身份等等因素，因此需要業務日誌有比較好的格式化，對於資損類的故障監控可以通過訂閱 binlog、業務消息的方式來進行對賬。
服務指標：服務指標是指能夠反饋業務依賴的接口服務是否可用的指標，統計的指標類型類似於業務指標，只不過一個接口維度，同樣可以分爲吞吐率、成功率、錯誤率以及性能。比如對於一個數據庫服務，對於一個查詢服務來說，它的幾個指標如下:

環境指標：環境指標又可以是資源指標，用來反饋底層基礎設施或者依賴服務可用率，對於資源類的指標可以分爲四個類型
- 使用率是資源繁忙的時間百分比，或正在使用的資源容量的百分比。
- 飽和度是資源無法服務（通常已排隊）的請求工作量的度量。
- 錯誤表示資源產生的工作中可能無法觀察到的內部錯誤。
- 可用性表示資源響應請求的時間百分比。此指標僅針對可以主動定期檢查可用性的資源定義。
異常事件：監控指標相對是連續的，對於一些離散的，不頻繁的異常可以通過事件(Event)監控來進行獲取，並且相對於單一的監控指標，事件還提供了一些上下文的信息，事件舉例：

以上要求 DPS 不但需要支持不同類型數據採集，還需要針對數據根據應用維度、業務維度分類處理。

故障結構化定義

發現體系建設的對象是故障，怎麼去快速發現已經發生的故障以及潛在可能變成故障的風險，因此對於能夠直接反映系統功能是否可用的指標要重點建設，所以監控指標的處理優先級就是：核心指標監控 → 非核心監控（業務，服務）→ 系統監控（環境指標）。

核心指標監控

核心指標監控就是能夠直接反饋功能是否可用，核心指標的下跌或者其他異常一定會導致不同程度的故障，因此對於核心指標要通過故障場景的方式來定義應急平臺上，所謂的故障場景包含了以下幾個方面：

核心指標監控
故障等級定義
負責的產品線
負責的處理人員
可能的影響面
出現問題之後的預案

比如對於交易下單業務下跌這一應急場景來說，可以有如下例子：

這裏重點是故障等級怎麼來定義? 故障等級定義可以考慮影響點以及影響面聯合來定義：

影響點：可以是用戶體驗，資金損失以及社會輿情。
影響面：變化服務，持續時間，投訴數量，資損金額等。
非核心監控：因爲故障一旦發生，後面會有一連串的應急制度，所以對於故障要謹慎定義並且收斂，那麼對於非核心監控的變化，我們可以採用風險預警的方式，風險預警就是對可能會導致故障的因素做出預警，同樣也會涉及到產品線，處理人員，預案等信息，同時預警會有一個升級成故障的機制，比如預警多次或者影響面擴大。上面的核心監控和非核心監控都需要有橫向的監控值班人員來進行統一關注，特別是故障發生之後需要有技術支持類的角色來進行組織和響應處理。
系統監控：因爲系統監控異常的概率非常高，特別是大規模集羣下，部分機器的 CPU，內存等資源發生變化是常有的事情，對於這些系統級別的告警，只需要配置普通的告警規則即可，由各個應用系統人員獨自去處理即可；如果是大規模的機器故障，必然會導致核心或者非核心監控的告警，這些系統監控指標可以作爲定位的數據來源。

以上要求 DPS 不但需要確立故障模型，以便故障的結構化定義，還需要基於監控數據的故障定級以及通告能力。

產品落地

DPS 在發現體系產品化上具備全鏈路監控、故障場景結構化，以及智能告警三個能力。

應用全鏈路監控

通過與阿里雲可觀測體系深度集成，DPS 實現了從用戶體驗端到基礎設施端的全鏈路監控，包括業務日誌監控、APM 監控、前端監控、基礎設施監控等。

故障場景結構化

監控數據本身不具備業務含義，以單條 Trace 調用鏈路爲例，能夠知曉它經過了哪些應用和接口，但是無法瞭解代表的業務，很難做到業務維度的精準監控。

DPS 提供了全息業務鏈路治理功能，可通過請求參數、cookie 等上下文標記對調用鏈路進行染色形成業務鏈路，對染色後的鏈路按照業務維度進行聚合生成業務活動，構建從產品線->業務活動->業務鏈路->故障場景的治理體系。
DPS 支持按照業務受損程度，數據影響面以及輿情影響面來劃分不同的故障等級，並且支持按照故障的持續時間和影響面來自動對故障進行升降級。

智能告警

當事件/故障產生以後，需要通過告警觸達到處理人員。在一個重大業務故障的持續時間內，不光已有的告警事件會繼續發送，由於爆炸半徑的不斷擴大也會產生新的告警事件，DPS 會對告警事件進行過濾，降噪聚合等操作，根據事件的時間，影響面，業務特徵等歸納到相同的故障下，避免告警的持續通告。

5 分鐘響應

要做到故障的 5 分鐘響應，首先需要有一套標準的應急響應流程，其次需要能夠快速定位問題，作出恢復決策。在實際應用中，會遇到如下的一些問題：

面臨問題

應急協同缺乏標準流程驅動
- 故障發生後的應急操作，往往需要多個技術團隊和技術工種協作完成，涉及到研發，運維，測試等不同角色，誰來組織應急，誰來處理，誰來做決策，需要有一定的應急機制，來確保相關人員能夠快速響應和高效協作。
- 故障應急需要從故障源採集環境信息，關聯不同的環境信息，分析故障原因，採取行動（展示、推送、處理、通知。但是當處理故障的規模放大，面對着多系統、多團隊的軟件組織，如何能夠高效地完成信息的採集、傳遞和處理？
無法快速定位問題

導致故障產生的原因有很多，比如流量問題、網絡問題、編碼問題、依賴服務問題，基礎設置問題，還有配置變更問題，牽一髮而動全身，在複雜的系統架構和業務鏈路下，如何能夠有效地查詢到故障的上下文信息，快速定位問題？

解決思路

應急協同流程標準化

可以將故障處理流程中的人員角色分爲三類：負責協調的技術支持人員，負責應急的處理人員以及負責決策的指揮人員。

技術支持人員

技術支持在應集中起到了非常關鍵的作用，對內，要有效組織直接處理人員的集中和協作；對外，負責對接業務部門同步信息，同時屏蔽各方對技術團隊和故障處理人員的干擾。當出現一個嚴重故障後，技術支持通常要做如下關鍵事項：

確定故障影響面以及定級。當故障產生之後，需要根據故障定級標準，快速做出初步判斷，確認影響面，以及故障等級。
組織應急。對於無法馬上恢復或需要定位排查的故障，需要將相關技術團隊主管和開發人員召集在一起，可以是線下會議室的形式，也可以是線上即時通訊拉羣的方式，同時確認故障處理主要指揮者。
信息通報。組織應急之後，需要每隔一段時間，對故障進展做一次信息同步。同時，如果等級和故障信息變化，也要同步出來，直至故障排除，業務恢復。並且技術支持要確保處理故障人員能夠相對地專注在故障處理上，而不是響應來自各方的詢問。
處理人員

處理人員由一線研發負責，要遵循“先簽到，再止血，後恢復”的原則，即在技術支持進行故障通告後，研發在處理前需要進行簽到通告，以防止多人處理引發的衝突問題。在處理中要優先止血，防止故障影響面的擴大，這就需要能夠快速判斷故障的初因以及執行合理的預案。最後是故障的徹底恢復，包括根因定位以及影響面的消除。

決策指揮人員

指揮人員用於重大故障恢復時候的決策，當嚴重故障涉及到了多個業務影響面，無法由研發人員獨立做出決策，就需要上升。

以上要求 DPS 不但需要將應急流程通過平臺流程來驅動，並且需要爲不同的角色人員提供特定的功能以幫助其更好地進行故障處理。

故障初因與根因定位

在進行故障定位需要從初因和根因兩個方面來處理。初因即導致故障的直接因素，需要能夠快速給出結論，以便於故障的快速止血，根因即導致故障的根本原因，在複雜的系統中要徹底定位問題往往耗費許久，因此根因定位一般用於故障的恢復以及覆盤改進。

初因定位包括全局變更診斷，比如故障發生前的發佈變更，配置變更或者是數據變更，像在阿里有 80%的故障是由於變更導致，因此需要能夠快速的收集並且查詢到指定時間的變更操作，對可疑變更進行回滾操作。此外也可從業務鏈路維度進行初因定位，查看當前故障業務的上下游業務是否異常，如果是因爲上下游業務影響導致，則需要對上下游業務進行降級之類的處理。

根因定位包括代碼 BUG 類定位，進程內資源不足，基礎設施異常等方面。

產品落地

DPS 在響應體系上包含了故障單，ChatOps 以及智能定位三塊能力。

故障單

當故障產生以後，便會自動生成故障單，故障單上規定了故障的處理流程，並且自動綁定當前故障的技術支持人員，應急處理人員，相關人員只需要通過 DPS 按照流程進行故障處理即可。

面向技術支持人員，DPS 提供了故障通告，等級變更，故障時間線，故障影響面管理等功能，幫助其更好地進行組織協調
面向應急處理人員，DPS 會自動根據故障場景定義推薦合適的快恢預案，爲了保證執行安全預案不會自動執行，處理人員可根據推薦建議選擇
面向指揮決策人員，DPS 提供了安全生產大盤，提供了全局的業務影響面視角以及故障處理視角，幫助其瞭解故障影響面和不同人員的處理狀態

ChatOps

ChatOps 能夠給故障處理流程帶來更好的透明度，實現信息共享的同時提升應急效率和便捷性。像釘釘，企業微信都是作爲 ChatOps 承載平臺的好選擇，基於這些平臺的開放能力，DPS 打造了一個應急機器人，通過應急機器人可以直接在手機端進行故障處理，包括簽到，進展更新，快恢執行等，獲取和 PC 控制檯一樣的使用體驗。

智能定位

DPS 在定位上能力包括：

基於故障場景拓撲的初因定位，藉助於人工配置的故障場景拓撲關係來作出推斷。舉個例子，比如購物車和下單是兩個上下游的業務，兩個業務分處於不同團隊，當購物車故障產生導致了下單業務故障，DPS 會自動向雙方的故障應急羣發送通告，告知故障原因以及影響面，並且在兩個羣同步故障進展。
基於全息業務鏈路的初因定位，一旦開啓全息業務功能，則無需手動創建拓撲關係，DPS 會自動識別出業務鏈路上下游節點的異常，關聯到故障單上。
基於阿里雲可觀測 Insight 技術的根因定位，通過 Insight 技術可精準定位到具體哪一臺機器，哪一條調用鏈路的異常。

10 分鐘快恢

1-5-10 場景的核心是快恢，發現體系和響應體系建設都是爲了快速的恢復故障。要建設快恢體系首先需要建立起快恢能力，其次要針對故障特徵合理使用快恢能力。

面臨問題

故障恢復的手段有很多，比如應用重啓，系統回滾，機器下線，重新發布，擴容限流等等，但是這些快恢能力分散在不同的系統裏面，難以管控。
在雲原生下各類平臺框架爆發式增長，開發者可以很便捷地引入各類技術，但是存在概念和使用方式差異化的問題，比如限流能力多個框架都可提供，但是不同框架間的定義卻不相同，增加了認知和配置成本。
由於缺乏快恢能力的標準化建設，導致快恢能力缺乏統一的度量標準，能力間難以組合和複用，新的快恢能力難以快速集成到平臺。
快恢能力的使用不存在銀彈一說，能力選擇上要考慮實施成本以及時效性等多方面因素，同時一些嚴重故障可能需要多種快恢能力的組合，比如應用集羣裏面某臺機器出現了異常，重啓以及下線隔離都可解決問題，很明顯隔離相比重啓有更好的時效性。

解決思路

通過定義快恢的公共抽象模型以及每個能力分類的抽象模型，實現快恢能力標準化，來降低不同產品間的認知成本和配置成本。
快恢能力聲明式設計，即對於使用方來說只需要知曉快恢的最終成功與否，而不需要關心中間過程，但是往往快恢系統本身是不提供這樣面向終態的能力，而是命令式的原子能力，這就需要有個中間層來對這些能力進行封裝。比如企業使用了阿里雲 ECS，需要通過 API 來執行 ECS 重啓，但是 ECS 的重啓 API 是異步執行，即執行重啓之後，返回成功並不代表重啓成功，需要調用查詢 API 來不斷的輪詢。這段重啓後再輪詢的邏輯實現由於不屬於業務正常邏輯，而是爲快恢做的封裝，因此這段邏輯在承擔快恢平臺角色的 DPS 裏是最合適的。類似這樣的案例還有很多，因此平臺需要支持快恢能力的擴展。
快恢能力推薦，即根據故障的特徵以及快恢執行時效性來推薦適合的快恢能力，以阿里電商架構的業務故障爲例，每一層的快恢手段都會有所差異，比如：
- 單元級故障，採用切流
- 機房級故障，採用隔離切流
- 接入層故障，採用切流
- 鏈路級故障，採用降級依賴
- 應用層故障，採用切流，重啓，降低
- 數據層故障，採用主備切換

產品落地

DPS 在快恢體系建設上包括快恢能力標準化定義，雲原生化的快恢產品接入以及快恢預案三塊能力。

快恢能力標準化定義

通過對阿里快恢的數據分析，DPS 將快恢分爲重啓，回滾，擴容，切流，限流以及降級六板斧六個類別，並且已經完成重啓和切流的快恢能力模型設計。拿切流舉例，切流本質上是將流經某個地址的流量進行再分配的過程，因此 DPS 設計切流模型時分爲流量地址，流量篩選以及流量路由三個部分，對於網關組件(ApiSix、Ingress...)等，流量地址即入口域名，流量篩選即根據 Http、Tcp 等方式對流量進行篩選，流量路由即不同地址的流量分配。數據庫的主備切換也可以抽象成寫流量的調度，主變成備的過程，即寫流量從主 100%，備 0% 到主 0%，備 100% 的過程。

需要注意的是 DPS 定位故障快恢，在模型定義要簡易清晰，因此只抽象出不同快恢產品的通用模型，不會去兼容快恢產品的所有配置規則。

雲原生的接入方式

DPS 定義了快恢產品的 CRD 模型，在 CRD 裏面針對不同快恢能力做了模型規範，開發者只需提供快恢產品的 CR，就可完成快恢系統的接入，流程如下圖所示：

其中 CR 裏面包含了快恢執行的鏡像，鏡像由開發者實現，鏡像的創建，擴容以及版本管理都由 DPS 平臺負責。容器鏡像需暴露一下接口：

快恢執行接口，用於執行快恢能力
快恢連接測試接口，用於驗證快恢系統可用性
快恢查詢接口，用於異常情況下的結果查詢
快恢參數提供接口，用於獲取參數的可選項，方便使用者進行填寫

快恢預案

快恢能力要通過快恢預案來執行，快恢預案定義了快恢能力的執行策略，主要包括以下內容：

觸發策略，可與故障場景以及監控告警做關聯，當命中觸發條件，自動推薦快恢預案。
審批策略，對於高危的預案設置不同層級的審批策略，保證預案執行的安全性。
運行策略，可對多個不同類型快恢能力進行組合執行。
通知策略，可通過多種方式對預案的全生命週期進行通知推送，保證預案執行的透明。
可觀測策略，藉助於 DPS 的可觀測能力，實現執行過程中受損業務的監控。

總結

數字化轉型下如何保證業務連續性？1. 首先思想觀念要轉變，從被動運維向主動運維再到持續改。2. 協作方式的轉變，必須要有業務思維，從業務場景出發，打破團隊邊界，讓普通業務人員也參與到安全生產的運維保障中。3. 技術方式的轉變，要不斷提升自動化運維水平，通過打造一體化平臺，爲業務保障人員提供統一的工作界面和空間，統一能力標準，統一實現接口，實現能力複用和組合，並且加強數據化運營。

1-5-10 場景作爲 DPS 推出的首個業務場景，在阿里安全生產最佳實踐的基礎上，結合外部企業客戶訴求持續性的改進優化，以幫助企業更好建設故障應急響應機制，提升業務連續性。受限於篇幅，本文中還存在很多未展開的討論細節，後續也會陸續更新。

如果您對於數字化安全生產平臺 DPS 有任何疑問，歡迎使用釘釘掃描二維碼加入釘釘交流羣，期待與您共創！