阿里雲解決方案架構師張平:雲原生數字化安全生產的體系建設

1.jpeg

關於今天的分享主題——“安全生產”,內容主要分爲三大部分:

  • 第一部分是安全生產的背景,以及我們對於安全生產這個領域的理解;

  • 第二部分主要介紹阿里巴巴集團的安全生產工作到底是怎麼開展的,藉此給各位有作爲參考和借鑑;

  • 第三部分是我們提煉的安全生產整體方案,幫助在座的各位去到我們自身的企業或者環境下,去落地安全生產。

數字化安全生產背景

談到安全生產,首先我們要看一個行業大背景,其實剛剛我的同事已經講到了,就是現在各行各業都在做自身業務的數字化轉型升級。我們的業務開始做上雲、線上化,應用架構開始做雲原生改造。當我們每一個業務都跑到線上去之後,我們就會發現,原來傳統的安全生產理念及管理模式,也需要轉變成線上化、數字化。

隨着線上化的系統越來越複雜,業務故障無法避免。故障的發生,對我們企業的影響是巨大的,怎麼樣提升故障的定位、處理能力及恢復能力,是現階段安全生產工作中最重要的目標。 在業務數字化轉型升級的過程中,我們每個企業都應該同時去思考,怎樣同步完成數字化安全生產體系的建設。

從業務視角的安全生產挑戰說起

2.png

關於安全生產,從以上幾個近期發生的故障可以看到,不僅僅是我們普通的企業,就算是在安全生產領域重度投入的國內外大型互聯網公司,也會出現業務故障。故障發生之後不僅僅是業務中斷、經濟損失,輿情影響也會帶來非常大的挑戰。我們怎麼樣來幫助大家把安全生產工作體系建設好?就是今天我們討論的核心主題。

在阿里巴巴集團內部,經過十多年的探索,我們沉澱了一系列的產品和服務體系,以及安全生產建設的方法論。我們總結出了“高可用、穩定壓倒一切”,作爲我們面對業務側安全生產挑戰的指導思想。

什麼是數字化安全生產

3.png

今天我們講數字化安全生產,大家可能第一印象想到的安全生產還是比較傳統的。比如一些工廠、車間、煤礦或者建築工地上,我們經常會看到一些標語、海報和一些相關的理念。傳統的安全生產,是指在生產經營活動中,爲了避免造成人員傷害和財產損失的事故而採取相應的事故預防和控制措施。

我們今天討論的這個數字化安全生產,其實是跟我們的業務數字化轉型升級是相結合的,主要解決企業業務連續性管理問題。 如發生預期或無預期的事故或災害時,企業以合理的成本和資源保護重要的業務活動,確保在規定的時間內恢復持續運行,最大程度地減少災害帶來的衝擊並將中斷影響降至最低。

數字化安全生產,有以下幾方面的特殊要求:

  • 數字化賦能的安全生產。 業務從線下轉移到線上之後,完成業務全生命週期觸點的數字化改造。這時,安全生產的重心也會從線下轉移到線上,同時安全生產工作本身也需要數字化賦能。

  • 雲原生加持的安全生產。 數字化轉型帶來了架構的升級,所有的系統都在雲上,都是利用先進的雲原生、微服務架構設計的。我們的安全生產平臺也需要同步升級,去無縫銜接適配雲原生的產品能力,以及面向未來架構的擴展能力。

  • 最佳實踐的安全生產。 安全生產體系建設需要經過實踐的檢驗。在阿里巴巴集團內部,我們有個一百多人的團隊,在安全生產建設方面持續探索,沉澱了一套非常適合各行各業的最佳實踐,並且還在持續演進。

數字化安全生產建設內容

4.png

基於以上探討,爲了做好安全生產工作,核心內容我們拆解成三個部分,就是事前、事中、事後建設。

  • 事前: 我們要有相關的組織架構保障,要有事前的制度流程體系、系統架構的建設,需要具備相關係統的水位監測、故障監測能力,以及與 SLA 匹配的防護、切流、變更管控管理能力。

  • 事中: 我們要做到敏捷快速協同,讓故障快速發現、快速定位、快速恢復。比如在阿里內部,雙十一或者說大的故障場景,我們通常需要協同上百人、甚至是上千人的團隊。在這樣的一個背景下,首先我們需要統一的機制保證步調一致,以及上一位同事提到的全鏈路監測(可觀測)的能力,保障快速發現。另外還需要系統化的能力做事件處理過程的自動化協同,依賴系統的 trace 及拓撲能力實現快速定位,以及需要依賴系統的防護能力及單元化容災多活,真正實現故障的快速恢復。

  • 事後: 我們需要去反思,總結根因,定義 action。每一個故障應急完成後,我們都需要做覆盤,定級定責,產出系統改進項,保證我們的整個架構持續迭代提升。對於管理者,我們需要去分析故障的原因是什麼,處理過程的團隊配合效率怎麼樣,分團隊分產品的穩定性數據統計,然後保證我們整個安全生產管理的體系是可度量、可考覈、可管理的。最後通過可視化的能力,指標化、全局化把控業務安全生產。

阿里巴巴集團最佳實踐

阿里巴巴集團全球運行指揮中心

5.png

首先在組織保障層,我們有一個組織叫全球運行指揮中心,也就是 GOC。在集團內部,有六十多個業務 BU 把所有安全生產相關的業務,接入 GOC 統一協同處理。

然後是我們剛剛說到的監測(可觀測),這是非常重要的一個環節。我們會把所有的可觀測,以及人工反饋(比如淘寶客服、阿里雲客服收集的反饋),匯聚到統一的事件中心,利用系統化平臺做管理。

最後所有的故障應急都匯聚到兩岸三地的指揮中心,相應的應急值班同學,利用應急協同、故障定位、快恢工具進行故障應急與快恢處置,並且進行事後覆盤與改進,通過機制運營等多種策略管控整個集團的安全生產風險事件。

安全生產體系大圖

6.png

安全生產是一個完整的體系,藉助這個架構圖給大家做一個大致的介紹,集團的安全生產體系比較大,我們把整體工作拆分成一個個小的模塊。

首先有平臺的技術能力支撐。 通過前面的介紹,我們瞭解了安全生產工作涉及很多不同角色的人,來自不同業務系統的可觀測數據,安全生產管理需要壓測、故障應急協同、演練、定位、切流、覆盤等能力,我們集團內部有相應的一個平臺做有效的支撐。

在這個平臺上,建設各個領域的系統,包括故障管理、多活、全鏈路壓測、變更管控等這些能力都是在這個大的平臺上面做統一的支撐,安全生產平臺的建設, 本身也是安全生產工作的數字化轉型。

在平臺的上層,是相關的管理體系、數據運營、技術文化建設。 早期我們在做安全生產工作的時候,最大的體感就是無法度量,出了故障之後無法定位是哪裏出了問題、誰的問題,經過故障等級定義、故障分、穩定性分等機制體系及運營活動的建設,可以實現安全生產工作的可度量可考覈。

然後平臺和體系建設需要配合相關的演練來做標準化的驗收, 保證這些體系和產品能力能夠有效的落地併發揮作用。

安全生產核心要素

7.png

人員&組織

安全生產的核心主要有三部分,第一部分就是人員組織的架構建設,我們認爲安全生產是企業的一把手工程,需要建立一個自上而下的統一組織,能夠把所有安全生產能力協同起來。

在集團內部,我們是有這樣一個垂直的組織架構,指揮中心是和每個業務 BU 平級的一個部門,然後下面有相應的支持各個業務 BU 的專業角色,橫向的話有安全生產的值班長、仲裁委員會等這樣的一些組織角色,保證我們的體系能夠有效落地。

制度&流程

第二部分主要是機制流程,集團經過十多年的建設,積累了非常多的制度流程。

  • 全集團的統一的故障等級定義: 爲應急過程的資源調度、決策提供了量化的標準;

  • 標準化的應急流程: 讓事件處理快捷、有序;故障分、穩定性分的考覈標準,統一衡量安全生產的成果;

  • 故障定級、定責、爭議協商機制: 保證了安全生產工作的長效機制。

工具平臺

最後一部分就是工具。集團的制度和流程不是僅僅停留在紙面,或者掛在牆上的。我們所有的機制流程都是有相應的系統平臺做運行支撐,然後基於我們的系統能力、機器人、NLP 技術等,做到有效的落地,把所有的這些機制落到實際的每一天的工作,每一個執行環節當中。

故障等級定義

8.png

故障等級定義是安全生產體系的運行基礎。我們把生產環境中,無論什麼原因造成的服務中斷或者服務品質下降及體驗下降統一定義爲故障。大家注意這是基於業務視角去定義的故障,它的好處就是能夠先於用戶發現,相比傳統的監測準確度更高。

然後再往下層的話,我們會有很多支撐平臺,如中間件、數據庫、雲平臺、網絡、服務器等等,下層的指標及故障定義,我們會根據各個業務的特點來針對性的做定義。但是總體原則還是以業務影響爲主,從上往下,只是下層系統的業務,通常就變成了上層系統的業務依賴。

基於故障等級定義的基礎,實際落地的時候,在集團內部有非常多細分種類。這裏簡單列舉幾個常用類別:P 序列表示通用等級定義、D 序列代表數據質量等級、S 序列代表影響重要客戶程度、E 序列代表輿情等級、 I 序列基礎設施相關等級

每一個序列我們通常有 4 個級別,4 代表普通故障,1 代表嚴重故障,數字越小緊急程度越高、重要性越高。

在實際落地過程中,首先我們要把所有的業務納入管理範圍,對全量業務做故障等級定義。故障等級定義需要協同各個角色,包括開發、測試、產品、運維、業務依賴方等一起來做等級定義評審,保證提前達成一致。故障等級定義正式發佈之後,大家就會按照這個等級去做投入和配套後端資源,一旦發生故障,就可以根據等級發起不同的應急流程,協調對等的資源參與應急。

每個業務場景故障等級的確定,主要參考業務重要性、影響面、持續時長來做綜合的判斷。確定好的故障等級定義要確保是結構化可度量的,要跟全鏈路可觀測做統一的協同,實現故障自動發現。

一旦發生故障之後,我們會根據可觀測指標,定義規則,自動試算故障等級,達到故障標準後通過機器人的方式自動發送故障通告,同時結合全鏈路可觀測的拓撲能力、trace 能力提供初步定位輔助。

1-5-10 機制

9.png

有了故障等級定義我們就可以精準識別業務的故障風險,及時發現並處置。那麼,如何度量故障處置的效率?這就涉及到數字化安全生產中一個最核心的一個機制,故障 1-5-10 機制。

在集團內部,所有的故障發生之後,我們定了一個考覈目標,要求業務故障 1 分鐘發現並通告,相關人員 5 分鐘內做出響應和初步定位,10 分鐘完成故障快速恢復。然後基於這樣的一個核心指導機制,我們再去向下做二級拆分,建設整個安全生產體系。

1-5-10 策略分解

10.png

1-5-10 主要關注“發現、定位、快恢”三大環節,再細分開來就會涉及架構、開發、運維的多環節。 每個環節都有自身的業務規則、相關的機制,以及有相應需要我們建設的系統。

比如“1”部分主要是涉及全鏈路可觀測,也包括我們平時比較關注的像智能基線、全鏈路監測,這些都是我們在這個環節需要去做的。

然後第二部分的話,關於 5 分鐘響應和定位,通常情況下我們都是基於移動化的方式做通告,包括短信、電話、釘釘。然後還有協同的工具,我們會基於釘釘機器人去做協同,利用 NLP 機器人技術做簽到、應急過程交互,實現 ChatOps。

關於定位的話,我們需要有可觀測系統、預案系統、變更管控這樣一些能力。通常情況下在平臺內發生一個故障的話,我們首先會收到一個故障通告,然後的話我們會收到故障前相關的一些變更信息,系統會推送這個場景相關的預案,應急人員會基於可觀測能力實現輔助定位。

關於 10 分鐘快恢部分,我們最大的一個大招,就是單元化的切流,只有系統判定出故障的影響面及預估恢復時長不可接受,我們可以基於單元化多活能力,做分單元切流,先恢復後判斷。另外小規模故障也可以基於預案系統做局部的快恢。

最後的話就是我們相關的運營機制建設與演練驗收,運營機制也是安全上非常重要的一部分,它可以保證相關安全生產的能力能夠持續的迭代。演練可以實時利用線上環境模擬故障注入,檢驗系統及流程。

可考覈的度量標準

11.png

安全生產工作有一個很大的痛點就是無法度量,通常我們不知道哪個產品穩定性好,哪個團隊做得好,更不知道未來的改進方向。基於以上的產品技術體系建設,我們設計了很多運營標準。

  • 故障分: 每一個故障發生之後,系統會自動評判一個分值,基本的計算邏輯就是影響面、持續時長、設定權重。它是一個結果指標,用來衡量產品和應急效率,通過持續的運營,我們可以制定團隊的故障分 quota 值,進而來設定安全生產相關的未來目標。

  • 穩定性分: 由工程設計、架構、運維等領域的 14 個指標構成。我們會去抓每一個業務開發團隊,設計環節的 cover review,運行環節的可觀測覆蓋率,發佈過程中的灰度的能力以及事後的 action 完成率等指標,通過系統化的方式生成評判指標。穩定性分是過程指標,考覈安全生產相關的投入情況。

故障分和穩定性分基本上是最核心的兩大指標, 是用來評判一個團隊在安全生產領域做得是不是合格的重要標準。此外還有很多業務可用性、熔斷、變更管控等等一系列機制,這些機制都會跑到各自相關的系統平臺裏面,實現自動化管理。

應急流程

12.png

對於應急流程,我們會把所有的事件都歸集到 GOC。事件接入主要有兩種類型,一個是用戶側反饋,這塊是人工的部分,基於智能客服對接;另一部分是可觀測告警,我們對接了集團業務 BU 數十個監測系統。大量的告警數據進來之後,就涉及到收斂、抑制和智能算法處理,再結合後臺的機器人處理過濾,最後會融合到統一的平臺做故障等級判定,事件或故障會走釘羣做協同,普通非緊急事件走工單,系統之間會有相應的協同,處理過程通過知識庫做有效的沉澱,全流程數據通過大屏做統一可視化展示。

處理過程全部在釘羣裏完成,故障通過之後,相關人員需要羣裏簽到,應急過程都會通過羣裏面來做統一呈現。一旦有重大故障的話,我們會升級到我們的高管羣,協同更多的人。

機制運營

13.png

除了剛剛講到的產品能力和相關的組織架構以外,機制運營也是安全生產工作非常重要的組成部分。我們會有非常豐富的運營活動,各種各樣的評獎,表現優秀的團隊的經驗能夠得到分享,做得不好的團隊可以去總結改進,以此來保證安全生產的長效機制。

數字化安全生產體系建設方案

數字化安全大圖

14.png

企業要做安全生產建設的話,核心分爲兩大部分 :一部分是技術體系建設,一部分是服務體系建設。

技術體系部分,我們需要形成統一的平臺。剛剛其實有個同學已經提到了,說現在企業裏面監測系統非常多,各個業務都有。然後從應用層、中間層、數據庫、雲平臺、網絡都有各自的系統。如果說我們按照這樣一個分散的方式去建的話,其實很難形成統一的應急指揮中心的效果。我們建議是建一個統一平臺,然後這個平臺具備安全生產的各種可操作的能力,把各系統的業務能力整合起來,形成統一的指揮中心。

在服務這塊的話,我們要保證機制文化、組織架構能夠有效支持安全生產工作的落地。

數字化安全生產平臺

15.png

關於數字化安全生產平臺,我們設計了一個框架,通過各個領域的組裝,整合現有能力,比如說可觀測能力、預案、工單、事件管理,把它抽象成一個整體的平臺,人員及事件全生命週期統一管理。然後通過平臺我們形成相應的業務領域,支撐我們各種各樣不同的業務場景,服務於上層各種各樣的業務,這個是統一的安全生產平臺建設的整體架構思路。

數字化安全生產體系建設-全生命週期服務設計

16.png

事前

企業需要在做遠期規劃的時候,把安全生產相關的產品架構、業務架構設計清晰,需要有相應的業務管理的思考。

事中

運行過程中,我們要考慮系統能力建設,比如說演練、壓測、限流、多活等等,保證我們能夠有效地評估和防範風險。

這裏介紹一個案例,就是這段時間大家比較熟悉的一個業務應用,疫情防控系統,如健康碼、場所碼、核酸檢測。前期我們會去給整個系統做壓測,評估線上的容量水位。

評估的結果是線上生產系統的容量上線是 1 萬 QPS,我們即按這個流量準備系統資源,這個時候如果說峯值流量超過 1 萬 QPS,那我們會通過配置流量防護的能力,保證系統在極端情況下也不至於說整個崩掉。

然後再往上一層,如果系統對於 SLA 要求更高,那我們還需要建設系統的雙活能力,這是安全生產的一個大招。我們要保證這個業務系統在極端情況下,整體崩掉的時候,我們有相應的雙活的站點可以接管業務。所有這些能力,都需要在統一的平臺裏面來做相應的統一調度管理。

事後

最後一部分是事後相關的改進。這部分內容其實涉及面也非常廣,比如說我們的應急協同能力的改進,產品架構的改進,整個管理機制的改進。改進是否按時完成,落地效果是否理想也是一個非常重要的閉環。我們需要有平臺做相應的支撐。

數字化安全生產-全息可觀測平臺

17.png

關於平臺能力建設,我們把每一個重要環節拆開來看。首先是可觀測,這部分的話其實就是剛剛我們講的 acos 的全鏈路監測,再補充一點就是我們的可觀測不一定要依賴於某一個平臺,而是要把業務現場所有監測能力做有效整合。acos 實現兼容專有云 arms 應用監測,並且增強了業務、日誌、異構監測系統的接入能力,通過可視化能力的提升,實現快速定位。

數字化安全生產-全鏈路壓測

18.png

第二部分是全鏈路壓測。我們在做安全生產的過程中,最核心的內容之一是要先了解我們的平臺到底是怎樣的一個處理能力,我們要摸清楚系統的水位,極限的承載能力。這樣的話,真實業務的峯值流量到來時,我們才能做到心中有數,輕鬆應對。

全鏈路壓測在集團內的各種大促活動中都屬於至關重要的環節,每次全鏈路壓測都是在生產系統進行的,這樣可以保證所有壓測出來的數據是真實的,相應的短板和系統問題,跟線上的問題是一模一樣的,準確找到短板,提升業務系統整體的壓力水位。

數字化安全生產-“1-5-10”應急協調

19.png

這裏主要介紹 1-5-10 應急協同,安全生產體系在實際的建設過程中,首先我們需要把人工反饋的這個事件和告警統一的接入,然後從業務角度進行故障等級定義,保證故障的 1分鐘快速發現,準確及時的通告。

在應急過程中,我們會有相應的橫向支撐能力,包括資源的拉通,跨團隊、跨廠商的人員協同,devops 能力, Chatops 能力的植入,保證系統能夠自動找到接口人,並且輔助完成快速定位。

在建設初期,主要依賴於我們自己的現有能力做有效整合。當然成熟的方案我們都有,但不一定是說我們起步要完全改版、重新開始,通常企業更需要基於我們現有的現狀來做。然後快恢部分包括相關的預案、容災雙活等相關的規則能力。1-5-10 是安全生產建設中,最容易落地和最快速能夠看到效果的部分。

數字化安全生產-流量防護

20.png

關於流量防護的能力,剛剛已經大概提到了一部分。

在現實環境中,爲了應對突發流量峯值,我們需要準備額外的資源。這個其實是一個成本和效率的一個折中方案。有些業務可能我們在建的時候就會評估一個業務的峯值,基於這個峯值,我們可能不會無限量的來準備計算資源、存儲資源,但是業務峯值來了之後,我們又不可能讓我們的系統停止服務。

所以我們就需要系統的限流能力,保證極端情況下業務可用,並且給運維操作預留擴容時間。通常情況下,我們再配合剛剛介紹的全鏈路壓測,可以通過流量防護能力,配合我們雲原生容器化相關的彈性能力,來保證相關的流量洪峯能夠平穩過渡,最大限度地支撐整體業務的穩定性。

數字化安全生產-容災多活解決方案

21.png

容災多活是安全生產的一個終極大招,當出現大面積故障的時候,如果我們依賴獨立的定位和恢復能力,可能無法滿足重要系統的 SLA,這個時候我們就需要建設業務級的容災多活。

在我們高階的容災方案中,整體架構都是單元化的,也就是業務級異地多活的方案。但是很多企業通常主導方案還是災備,通過做數據庫同步,存儲複製,每個應用自己管自己的那一部分,來獲得相關的容災能力。

容災多活系統中有一個總的管控平臺,把流量接入層,中間件以及數據庫,做協同管理。可以理解爲我們是一個大的流量調度系統,然後保證在業務發生故障之後,它可以自動地去做單個應用的流量調度,單個應用的相關業務切流可以自助化執行,切換過程平臺自動化完成,不需要應用做手工調整。

多活建設在資源利用率、切換成功率、自動化程度方面都有明顯的優勢,也是個企業安全生產建設的終極目標。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章