背景

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

1-5-10 介紹

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

下圖是 1-5-10 的產(chǎn)品架構(gòu)圖：

1-5-10 場景包括事前穩(wěn)定性分析，事中應急處理，事后持續(xù)運營三個步驟。

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

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

1 分鐘發(fā)現(xiàn)

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

面臨問題

• 業(yè)務監(jiān)控的復雜性導致問題的淹沒

一個生產(chǎn)業(yè)務監(jiān)控，涵蓋了各式各樣的指標，從業(yè)務層面、應用層面、服務層面、系統(tǒng)層面,基礎設施層面等等，比如下面：

• 網(wǎng)絡傳輸監(jiān)控(丟包,延遲)
• 服務器系統(tǒng)狀態(tài)(CPU、load)
• 虛擬機，容器監(jiān)控
• 應用運行狀態(tài)(成功率、qps)
• 業(yè)務運行狀態(tài)(訂單創(chuàng)建量…)
• 用戶體驗(白屏、內(nèi)容錯誤）

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

• 監(jiān)控數(shù)據(jù)和故障不能有效關(guān)聯(lián)

什么是故障? 在日常運營中，無論什么原因?qū)е路罩袛?、服務品質(zhì)下降或用戶服務體驗下降的現(xiàn)象，稱為故障。只有清楚定義業(yè)務故障，并且將故障監(jiān)控進行關(guān)聯(lián)才能做到真正故障的快速發(fā)現(xiàn)。然而在生產(chǎn)業(yè)務中，往往只聚焦于監(jiān)控治理，而忽略了故障定義的重要性。

解決思路

監(jiān)控指標分類

可以將指標能否直接反饋業(yè)務功能是否可用，將指標分為如下類別：

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

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

以上要求 DPS 不但需要支持不同類型數(shù)據(jù)采集，還需要針對數(shù)據(jù)根據(jù)應用維度、業(yè)務維度分類處理。

故障結(jié)構(gòu)化定義

發(fā)現(xiàn)體系建設的對象是故障， 怎么去快速發(fā)現(xiàn)已經(jīng)發(fā)生的故障以及潛在可能變成故障的風險，因此對于能夠直接反映系統(tǒng)功能是否可用的指標要重點建設， 所以監(jiān)控指標的處理優(yōu)先級就是：核心指標監(jiān)控 → 非核心監(jiān)控（業(yè)務，服務）→ 系統(tǒng)監(jiān)控（環(huán)境指標）。

• 核心指標監(jiān)控

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

• 核心指標監(jiān)控
• 故障等級定義
• 負責的產(chǎn)品線
• 負責的處理人員
• 可能的影響面
• 出現(xiàn)問題之后的預案

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

這里重點是故障等級怎么來定義? 故障等級定義可以考慮影響點以及影響面聯(lián)合來定義：

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

以上要求 DPS 不但需要確立故障模型，以便故障的結(jié)構(gòu)化定義，還需要基于監(jiān)控數(shù)據(jù)的故障定級以及通告能力。

產(chǎn)品落地

DPS 在發(fā)現(xiàn)體系產(chǎn)品化上具備全鏈路監(jiān)控、故障場景結(jié)構(gòu)化，以及智能告警三個能力。

應用全鏈路監(jiān)控

通過與阿里云可觀測體系深度集成，DPS 實現(xiàn)了從用戶體驗端到基礎設施端的全鏈路監(jiān)控，包括業(yè)務日志監(jiān)控、APM 監(jiān)控、前端監(jiān)控、基礎設施監(jiān)控等。

故障場景結(jié)構(gòu)化

監(jiān)控數(shù)據(jù)本身不具備業(yè)務含義，以單條 Trace 調(diào)用鏈路為例，能夠知曉它經(jīng)過了哪些應用和接口，但是無法了解代表的業(yè)務，很難做到業(yè)務維度的精準監(jiān)控。

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

智能告警

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

5 分鐘響應

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

面臨問題

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

導致故障產(chǎn)生的原因有很多，比如流量問題、網(wǎng)絡問題、編碼問題、依賴服務問題，基礎設置問題，還有配置變更問題，牽一發(fā)而動全身，在復雜的系統(tǒng)架構(gòu)和業(yè)務鏈路下，如何能夠有效地查詢到故障的上下文信息，快速定位問題？

解決思路

應急協(xié)同流程標準化

可以將故障處理流程中的人員角色分為三類： 負責協(xié)調(diào)的技術(shù)支持人員，負責應急的處理人員以及負責決策的指揮人員。

• 技術(shù)支持人員

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

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

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

• 決策指揮人員

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

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

故障初因與根因定位

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

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

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

產(chǎn)品落地

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

故障單

當故障產(chǎn)生以后，便會自動生成故障單，故障單上規(guī)定了故障的處理流程，并且自動綁定當前故障的技術(shù)支持人員，應急處理人員，相關(guān)人員只需要通過 DPS 按照流程進行故障處理即可。

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

ChatOps

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

智能定位

DPS 在定位上能力包括：

• 基于故障場景拓撲的初因定位，借助于人工配置的故障場景拓撲關(guān)系來作出推斷。舉個例子，比如購物車和下單是兩個上下游的業(yè)務，兩個業(yè)務分處于不同團隊，當購物車故障產(chǎn)生導致了下單業(yè)務故障，DPS 會自動向雙方的故障應急群發(fā)送通告，告知故障原因以及影響面，并且在兩個群同步故障進展。
• 基于全息業(yè)務鏈路的初因定位，一旦開啟全息業(yè)務功能，則無需手動創(chuàng)建拓撲關(guān)系，DPS 會自動識別出業(yè)務鏈路上下游節(jié)點的異常，關(guān)聯(lián)到故障單上。
• 基于阿里云可觀測 Insight 技術(shù)的根因定位，通過 Insight 技術(shù)可精準定位到具體哪一臺機器，哪一條調(diào)用鏈路的異常。

10 分鐘快恢

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

面臨問題

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

解決思路

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

產(chǎn)品落地

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

快恢能力標準化定義

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

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

云原生的接入方式

DPS 定義了快恢產(chǎn)品的 CRD 模型，在 CRD 里面針對不同快恢能力做了模型規(guī)范，開發(fā)者只需提供快恢產(chǎn)品的 CR，就可完成快恢系統(tǒng)的接入，流程如下圖所示：

其中 CR 里面包含了快恢執(zhí)行的鏡像，鏡像由開發(fā)者實現(xiàn)，鏡像的創(chuàng)建，擴容以及版本管理都由 DPS 平臺負責。容器鏡像需暴露一下接口：

• 快恢執(zhí)行接口，用于執(zhí)行快恢能力
• 快恢連接測試接口，用于驗證快恢系統(tǒng)可用性
• 快恢查詢接口，用于異常情況下的結(jié)果查詢
• 快恢參數(shù)提供接口，用于獲取參數(shù)的可選項，方便使用者進行填寫

快恢預案

快恢能力要通過快恢預案來執(zhí)行，快恢預案定義了快恢能力的執(zhí)行策略，主要包括以下內(nèi)容：

• 觸發(fā)策略，可與故障場景以及監(jiān)控告警做關(guān)聯(lián)，當命中觸發(fā)條件，自動推薦快恢預案。
• 審批策略，對于高危的預案設置不同層級的審批策略，保證預案執(zhí)行的安全性。
• 運行策略，可對多個不同類型快恢能力進行組合執(zhí)行。
• 通知策略，可通過多種方式對預案的全生命周期進行通知推送，保證預案執(zhí)行的透明。
• 可觀測策略，借助于 DPS 的可觀測能力，實現(xiàn)執(zhí)行過程中受損業(yè)務的監(jiān)控。

總結(jié)

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

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

作者：銀桑

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。文章來源地址http://www.zghlxwxcb.cn/news/detail-783673.html

到了這里，關(guān)于1-5-10 快恢在數(shù)字化安全生產(chǎn)平臺 DPS 中的設計與落地的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！