雲音樂預案平臺實踐

雲音樂技術團隊發表於2022-03-08

圖片來源:https://unsplash.com

本文作者:帝青

一、 背景

隨著服務化的大面積推開,服務穩定性越來越被重視起來,雲音樂從2018年開始進行穩定效能力建設,到最後建設成通用能力,雲音樂大概經歷了以下幾個主要階段,從2018年無穩定性保障能力的裸奔階段,到穩定效能力的搭建,再到提升易用性、效率的平臺一體化建設,
到包括近期做的預案管理平臺化建設,每一次的演進,都能為雲音樂整體穩定性添磚加瓦,今天我們主要介紹下預案平臺化建設的一些實踐;
image

1. 預案是什麼?

百度百科中給我是這樣解釋的:
預案,是指根據評估分析或經驗,對潛在的或可能發生的突發事件的類別和影響程度而事先制定的應急處置方案。

上到國家大事,下到一件很小的事情,都會涉及到一些預案:

  • 比如我們經常會看到電影中的一些場景,有PlanA、PlanB、PlanC...,其實這就是我們的預案,實施PlanA、PlanB還是PlanC是根據不同的場景來決定的;
  • 就拿這次新冠病毒疫情來說,其實政府早就有自己的一系列預案來應對不同等級的突發事件(中華人民共和國應急管理部主要負責組織編制國家應急總體預案和規劃,指導各地區各部門應對突發事件工作,推動應急預案體系建設和預案演練);
  • 雲音樂經常會做大型活動,在活動前做很多的壓測、演練,這期間會梳理在出現某些事件的情況下預案,比如某個服務扛不住了,需要做一些降級,如果還是扛不住需要繼續做降級或限流等;
2、 雲音樂預案現狀

在雲音樂大型活動保障過程中,會做常規演練、壓測等進行容量評估和摸底,對於可能出現的風險會做評估,並做防範性的準備,其實這些準備就是預案,比如Plan A, Plan B。在此之前這些預案都是維護在wiki上(例如颱風專案的各業務方預案)或者我們自己的記事本上,在具體發生了某個場景的時候我們會去執行Plan A或Plan B,所有這一切都是凌散且不統一,當涉及到大量人員時協作成本非常高預案的可執行性會比較差;另外一點就是缺乏演練,無法做到預案的有效性;

3、預案長啥樣?

預案到底是什麼,提供了什麼樣的能力?預案一般有一些通用的能力,我們去搜尋引擎裡搜預案能得到各種各樣的答案,但可以歸納為以下幾個組成部分,比如此次預案的目的、適用範圍,預案等級,預案負責人,觸發條件,達成情況(預案執行後),後置處理(如何恢復)等的一些事項,

  • 預案目的、適用範圍:本次預案主要是用於完成什麼樣的事項,能夠用到什麼場景下,比如是壓測場景、保障什麼等級的活動等;
  • 觸發條件:開啟該預案的條件是什麼,通常情況下我們會根據我們系統的狀態來看需要開啟哪個預案,比如通過監控、告警等來告訴我們當前系統所處的狀態,是否達到了預案的執行條件,比如當服務端超時閾值達到多少時,就開啟限流或者主動降級的預案;
  • 如何恢復:一般情況下,預案都是針對某個突發場景而設立的,所以在預案執行完成後,需要做一些善後的工作,將預案恢復到常態下;
  • 達成情況:預案在執行後,需要及時填寫一些達成情況,用於驗證預案是否符合預期,如果不符合預期,需要記錄不符合預期的事項,為後續預案優化和覆盤提供資料支援;
  • 預案等級:一般情況下,我們會給預案設定一些等級,看到這個等級我們就會知道當前預案的重要程度,是否有損等資訊,更容易做一些上層的梳理;以下為雲音樂的預案的等級描述:

    • L0預案:事前預案,對業務的影響程度極小,對使用者是無感知的(不會有操作體驗上的感知);
    • L1預案:對業務部分有損(會影響業務資料等),在預案准備過程中已經和業務線報備過;
    • L2預案:一般影響比較大,則需要現場決策後才能執行;

在當前預案平臺,預案目的、適用範圍,執行條件,如何恢復,達成情況做的比較簡單,都是在預案的描述資訊中進行填寫,並未進行展開;

預案會在事前做一些充分的準備,對預案做充分的討論、梳理,然後再事中的時候,當觸發了某個條件,就回去執行對應的預案,然後會記錄預案是否符合預期,在事後也會做一個預案的優化/覆盤,如下圖所示:

image

二、 預案平臺化建設

1. 預案平臺產生的背景:
  • 最初的預案來自於批量操作的需求,比如多應用限流閾值的批量操作,批量調整降級開關的能力;
  • 各業務方預案大部分情況下主要是針對配置中心配置值、限流閾值、降級規則進行調整;
  • 預案不規範:主要來源於預案的形式是多種多樣的,有些是通知我們去做什麼事情,比如檢查某個配置,檢查監控是否符合預期,有些是調整配置中心的閾值、調整限流閾值、調整降級能力,另外從認知上,比如預案等級,存在L0,L1,L2,大家對等級的認知也是不一致的;
  • 沒有相應平臺提供預案的制定、執行、管控能力:長期以來,這些文件化的預案在wiki上維護,所有這一切都是凌散且不統一,當涉及到大量人員時協作成本非常高預案的可執行性會比較差。
2. 預案平臺的概念對齊:

在雲音樂預案平臺中,有三個基本概念:

  • 資源:可以是配置中心的key/value,可以是一個限流規則,也可以是一個熔斷降級規則;
  • 預案:歸屬於一個預案組,是在某些情況下才會觸發的,比如在壓測前時,可以關閉限流,進行摸高壓測;
  • 預案組:是對同一組資源的管理,在預案組下可以有多個預案;比如有一個演練場景,需要對幾個限流資源進行調整,對於預案組下不同的預案對應的限流閾值可能是不一樣的;
    image

整體可以通過上圖進行理解,一個預案組包含了多個預案,同時包含了一個資源管理的功能,預案組中每個預案的的資源是繼承自資源管理中匯入的預案的,每個預案中的資源可以獨立調整;

平臺化後,預案格式也就能夠固定下來了,比如預案模組、負責人、預案級別、型別等資訊;

3. 平臺化能力

image

  • 平臺化(產品化)的預案平臺不僅僅是上面的一些預案自身能力,更多的還會從平臺化建設角度進行設計,比如審批能力、許可權管理、配置的安全性(釋出預覽、配置比對等)、基本的治理能力;
  • 目前支援限流、降級、配置中心的預案管理能力;
  • 執行計劃,為什麼會有這個概念,接下來我們會在預案編排中進行介紹;
4. 平臺檢視

以下為預案平臺的預案維度管理的檢視;
image

三、預案編排

很多同學會問到一個問題,預案是否需要編排?這裡的編排是指在一次活動中,有多個預案,我是有順序或者有計劃的去執行一系列的預案;
其實對於預案來說這種場景是有的,具體是看業務需求;如果預案執行的可預測性、可評估性比較差,只有在某種情況下才會被啟用(僅僅是預防使用),這種情況下不需要預案編排;
如果有些預案執行非常明確,且有些大概率會被用到的,這種編排能力就可能會用到;

所以我們支撐了另外一套能力:執行計劃,這裡需要明確下執行計劃的目標,及其相關概念&能力;

  • 執行計劃的目標:

    • 提供時間線維度的流程管理、通知能力;
    • 提供一個統一的執行檢視進行展示。
  • 概念對齊:

    • 執行計劃:執行流程的管理單位,包含一個或多個執行流程;
    • 引用執行計劃:通過引用其他執行計劃,可以對被引用的執行計劃的所屬執行流程做一個軟鏈展示;
    • 執行流程:執行計劃的最小單元,用於存放一個需要執行的內容;
    • 描述性預案:作為非執行預案外的執行內容記錄;
    • 執行預案:當前直接對接了預案模組的預案。
  • 執行計劃的能力:

    • 豐富的通知機制:目前支援popo、stone、郵件、簡訊四種通知策略;可以靈活的配置通知時機;
    • 簡單易用的許可權管控機制:目前執行計劃維度和流程維度的許可權管理能力;
    • 執行計劃關聯能力:便於執行計劃之間進行關聯,比如多個人針對自己的場景設計了各自的執行計劃,從整體上來看,需要合併為一個執行計劃,便於從整體上進行統一把控;
    • 友好的執行計劃視覺化能力;如下圖:
      image
  • 和預案打通,可以支撐預案的編排能力,一個執行計劃包含多個執行流程,執行流程可以是預案平臺中的預案。

需要著重提示的一點,預案平臺和執行計劃是兩個不同的概念,執行計劃是讓我們具有編排、通知的能力,而預案是可以作為被編排,每個預案可以作為執行計劃中的一個執行流程;執行計劃主要是協助業務開發同學做一些流程編排,及流程通知能力,不只是做預案的編排,也能夠做一些checklist的管理、通知、看板等能力。

四、一些最佳實踐

預案平臺已有云音樂內部廣泛接入,主要是針對穩定效能力的一些配置,同時在預案配置時需要關注的問題;

1. 限流、降級、配置中心預案

能夠實現限流、降級、配置中心的單獨預案能力,同時可以實現在將多個應用、多產品的不同的限流、降級、配置中心的值管理組合到一個預案組中,以達到組合場景下的預案管理能力,並且配有許可權管理的能力;

image.png

2. 預案配置需要關注的問題

在設計一個預案時是根據一些場景或演練結果等進行假設的,這個場景可能暫時是我們自身的產品、技術方案設計上或程式碼上的一些問題,假設我們做了一些優化,但是預案沒有及時調整,那麼這個預案的有效性就會大打折扣,這時候可能我們會考慮如何及時的將我們的預案有效性提升,防止預案腐化;

  • 預案腐化

    • 預案的建設和程式碼、產品實現息息相關,而程式碼、產品一直處於快速迭代當中,預案和系統架構一樣,在經歷一次又一次的需求迭代後不斷被“腐化”。如何預案保持活性?目前一個好的方案是將預案演練進行到底,可以配合故障演練一起來做。當然,預案在我們一次次演練和線上實操時不斷被完善和補充,這是一個雙贏的過程。
    • 為了避免預案腐化,保持預案的可執行性,儘量將預案的內容縮減,不要擴大;
  • 預案常態化演練:

    • 預案建設是穩定性建設中非常重要的一環,預案設計完成後,不是擺在那裡,等對應的觸發條件達成後,直接開啟,試想一個場景,一個預案在設計了半年後發現出現某個問題符合觸發條件,我們這時候要開啟,但是預案此時是否已經不符合之前的條件,相關同學可能都沒有太大的信心,這是缺乏日常演練導致的結果,所以針對預案要做常態化的演練,這樣在常規情況下,才能夠更好的進行預案的管理和優化,更好的避免預案腐化;

六、未來規劃

未來主要會做一些場景打通方面的事項,也會根據業務的試用情況做一些及時的調整,做更多的可擴充套件的能力,同時在平臺化方向也會持續建設;

  1. 場景化打通:對於現有的故障演練平臺、NPT壓測平臺、活動保障平臺,都需要預案能力;
  2. 故障演練平臺的打通,需要為故障演練平臺設計一個預案,當某個故障被mock後,需要開啟某個預案,使得能夠在無損或部分有損的去快速拉起服務或保障服務不死;
  3. NPT壓測平臺,有很多同學在壓測的時候需要做一些摸高,但又要保障服務的穩定性,不至於被持續的流量打垮,所以也許要做一個限流的閾值調整能力,這個調整能力是可以得到沉澱的,並且可以將NPT壓測和預案常態化進行關聯,保障預案的持續有效,不至於被快速腐化;
  4. 活動保障平臺:搞一次活動尤其是大型活動需要做很多的壓測、穩定性保障的事項,所以在這個過程中會涉及到很多的開關、配置、限流等的能力,需要設計N套預案應對;
  5. 預案的平臺化建設能力增強

    • 預案資源層監控能力;
    • 預案效果視覺化驗證;
    • 風險巡檢能力;
    • 更豐富的治理能力;
    • 預案自動化執行能力鋪墊;
    • 執行計劃依賴關係能力;
  6. 預案日常化推進,儘量避免預案腐化;

七、總結

  • 預案平臺是在對配置批量處理需求上建設起來的,而這些批量能力是其中最簡單的一種需求場景,預案建設是業務穩定性保障中非常重要的一環,同時預案的平臺化建設能夠給業務的穩定性保障帶來事半功倍的效果;
  • 更多維度進行預案的嘗試(場景化打通),將有助於對風險意識、穩定性的提升;
  • 如何將預案演練做到日常化,防止預案腐化仍然是我們需要後續需要繼續探索的方向。
本文釋出自網易雲音樂技術團隊,文章未經授權禁止任何形式的轉載。我們常年招收各類技術崗位,如果你準備換工作,又恰好喜歡雲音樂,那就加入我們 grp.music-fe(at)corp.netease.com!

相關文章