【深度】阿里巴巴萬級規模 K8s 集羣全局高可用體系之美

做者 |  韓堂、柘遠、沉醉
來源 | 阿里巴巴雲原生公衆號
​

前言

臺灣做家林清玄在接受記者採訪的時候，如此評價本身 30 多年寫做生涯：「第一個十年我才華橫溢，‘賊光閃現’，令周邊黯然失色；第二個十年，我終於‘寶光現形’，再也不去搶風頭，反而與身邊的美麗相得益彰；進入第三個十年，繁華落盡見真醇，我進入了‘醇光初現’的階段，真正體味到了境界之美」。
​
長夜有窮，真水無香。領略過了 K8s「身在江湖」的那種驚心動魄以及它那生態系統的繁花似錦，該是回過頭來體味高可用體系境界之美的時候了。畢竟僅能經得起敲打仍是不能獨步武林的！
​
在 K8s 高可用領域有一個問題被你們所熟知，那就是 K8s 單集羣規模帶來的 SLO 問題，如何持續保障？今天就以單集羣的規模增加帶來的高可用挑戰來做爲引子來給你們一個體感。
​
ASI 單集羣規模支撐超過社區的 5000 臺，這是個很是有意思且具有極大挑戰的事情，對須要進行 K8s 生產化的同窗，甚至具有 K8s 生產化經驗的同窗來講，必定會是個感興趣的話題。回看 ASI 單集羣規模從 100 到 10000 的發展之路，伴隨着業務的增加和創新帶來的每一次集羣規模增加，都在逐步使咱們的壓力和挑戰發生質變。
​

ASI：Alibaba Serverless infrastructure，阿里巴巴針對雲原生應用設計的統一基礎設施，ASI 是阿里公共雲服務 ACK 的阿里集團企業版。

你們知道 K8s 社區只可以支撐五千個節點，當超過這個規模時，會出現各類性能瓶頸問題，好比：

• etcd 出現大量的讀寫延遲。
• kube-apiserver 查詢 pods/nodes 延時很高，甚至致使 etcd oom。
• 控制器沒法及時感知數據變化，如出現 watch 數據延遲。

以電商場景爲例，100 節點增加到 4 千節點的時候，咱們提早針對 ASI apiserver 的客戶端和服務端作了大量的性能優化，從 apiserver 客戶端的角度優先訪問本地 cache，在客戶端去作負載均衡；apiserver 服務端主要作了 watch 優化和 cache 索引優化；在 etcd 內核上利用併發讀提高單 etcd 集羣讀處理能力，基於 hashmap 的 freelist 管理新算法提升 etcd 存儲上限，基於 raft learner 技術來提升多備能力等等。
​
從 4 千節點增加到 8 千節點，咱們又作了 qps 限流管理和容量管理優化、etcd 單資源對象存儲拆分、組件規範全生命週期落地經過客戶端的規範約束下降對 apiserver 的壓力和以及穿透到 etcd 的壓力等等。
​
終於迎來 8 千節點增加到上萬節點的時刻，咱們開始如火如荼地開展 etcdcompact 算法優化；etcd 單節點多 multiboltdb 的架構優化，apiserver 的服務端數據壓縮，經過組件治理下降 etcd 寫放大等；同時開始打造常態化的壓測服務能力，持續回答 ASI 的 SLO。
​
這些例子在高可用挑戰中司空見慣，列出的能力也只是其中一小部分，你也許很難看到能力之間的關聯和底層的演進邏輯。固然，更多的能力建設沉澱到了咱們的系統和機制當中。本篇文章會做爲一個開始，以綜述的形式分享咱們在建設 ASI 全局高可用體系中的幾個關鍵部分，再日後會有針對性地對進行技術點和演進路線的詳解。若是你們有什麼問題或者但願瞭解的部分，歡迎在評論區留言。

ASI 全局高可用概述

高可用是個比較複雜的命題，任何平常的變化例如服務升級、硬件更新、數據遷移、流量突增等均可能形成服務 SLO 受損，甚至不可用。
​
ASI 做爲容器平臺，並不是孤立存在，而是與雲底層及公共服務造成完備的生態系統。要解決 ASI 的高可用問題，須要縱觀全局，找出每層的最優解，最終串聯組成最優的總體解決方案。涉及到的層面包括：
​

• 雲基礎相關管理，包括可用區的選擇，規劃和硬件資產的管理
• 節點的管理
• ASI 集羣管理
• 公共服務
• 集羣運維
• 應用研發

特別是在 ASI 這個場景下，要支撐的業務集羣數量龐大，涉及到的研發運維人員衆多，功能發佈頻繁的迭代開發模式以及業務種類繁多帶來的運行時的複雜多變，相比其餘容器平臺來看，ASI 高可用面臨更多的挑戰，其難度不言而喻。
​

ASI 全局高可用設計

以下圖所示，現階段高可用能力建設總體策略以 1-5-10（故障 1 分種發現、5 分鐘定位、10 分鐘止損）爲目標牽引，注重將能力沉澱到系統或機制中，讓 SRE/Dev 可以無差異的 oncall。  
​
儘可能避免發生問題、儘快發現、定位及恢復問題，是實現目標的關鍵，爲此咱們將 ASI 全局高可用體系的實現分三大部分展開：一是基礎能力建設；二是應急體系建設；三是經過常態化壓測以及故障演練等完成上述能力的保鮮和持續演進。 
​

經過 3 個部分的輪轉驅動，實現一個 ASI 全局高可用體系的構建，其頂層是 SLO 體系和 1-5-10 應急體系。在應急體系和數據驅動的體系背後，咱們建設了大量高可用基礎能力，包括防護體系、高可用架構升級、故障自愈體系、以及持續改進機制。與此同時，咱們創建了多個基礎性平臺爲高全用體系提供配套能力，如常態化故障演練平臺、全鏈路仿真壓測平臺、告警平臺、預案中心等等。
​

全局高可用基礎能力建設

在建設全局高可用能力以前，咱們的系統在迅速發展和變化下不斷出現事故和險情，須要隔三差五去應急，致使讓問題追身的局面，而且追身後沒高效應對的手段，面臨着幾個嚴峻的挑戰：
​

• 如何在架構和能力上去提高咱們的可用性，下降系統發生故障的機率和影響面？
• 如何在覈心鏈路性能和架構上作一些突破，可以支撐這麼複雜多變的業務場景和業務增加的通用需求？
• 如何讓問題再也不追身，作好預防工做，避免應急？
• 如何在應急發生時，可以快速發現，快速診斷，快速止損？

針對這些問題，而且總結出如下幾個核心緣由：
​

• 可用性能力不足：在集團場景下，組件不斷在變化，不斷增長系統的壓力和複雜度，ASI 在生產可用性的能力上缺失，如限流降級、負載均衡等，組件容易亂用形成低級錯誤，影響集羣可用性。
• 系統風控和 pod 保護能力不足：在人爲誤操做或系統 bug 時, 容易形成業務 pod 無辜受損或者大面積受損。
• 容量風險：集羣數量幾百，組件接近一百；另外歷史問題因 podCIDR 和節點 IP 數的配置，大多 ASI 元集羣的節點規模被約束在 128 臺之內，隨着業務快速發展，對容量風險而言存在較大挑戰。
• 單集羣規模受限，加上橫向擴展能力不足影響業務發展：單集羣不斷增加規模，以及業務類型變化，組件變化都對單集羣支撐的最大規模產生影響，對 SLO 持續穩定產生影響。

1. 高可用基礎能力頂層設計

針對這些解決的問題，咱們作了高可用基礎能力的頂層設計，這些基礎能力建設總體主要分爲幾個部分：
​

• 性能優化和高可用架構建設：主要是從性能優化和架構升級的角度來提高整個集羣支撐的業務類型和業務量。
• 組件規範全生命週期管理：主要從規範的角度在組件的整個生命週期去落地，從出生啓用和集羣准入開始，到每一次變動，到下線整個生命週期都要防止組件亂用、野蠻生長、無限膨脹，控制組件在系統可承受範圍以內。
• ***體系建設：主要從 ASI 系統自己觸發，在從***和防護的角度來提高系統的安全，防護和風控能力。

下面針對咱們的一些痛點進行幾個關鍵能力建設的描述。
​

2. K8s 單集羣架構的痛點

• 對 ApiServer 的掌控能力不夠，應急能力不足，咱們本身的經歷，歷次集羣 Master 出現異常的次數超過 20+，歷次恢復時間最長超過 1 小時。
• ApiServer 是 APIServer 集羣的單點，爆炸半徑大。
• 單集羣規模大， Apiserver 內存水位比較高，壓力來源於頻繁的查詢，寫入更多更大的資源對象。
• 在業務層缺乏跨機房的容災能力，當 ASI 不可用的時候，只能依賴 ASI 的恢復能力。
• 集羣規模的持續擴大，離線任務的大量建立和刪除對集羣的形成更大壓力。

這裏面從兩個大的角度能夠去提升集羣架構的可用性，除了在單集羣進行架構優化以及性能突破外，還要經過多集羣這樣的橫向擴展能力去支撐更大的規模。
​

• 一是經過聯邦這樣的多集羣能力來解決單集羣的橫向擴展能力以及單地域跨集羣容災能力。
• 另一個單集羣自己的架構還能夠從隔離和優先級策略的架構角度來進行差別化 SLO 保障。

3. ASI 架構升級落地

1）APIServer 多路架構升級

核心方案就是經過對 apiserver 進行分組，經過不一樣的優先級策略進行對待，從而對服務進行差別化 SLO 保障。
​

• 經過分流以下降主鏈路 apiserver 壓力（核心訴求）
  • P2 及如下組件接入旁路 apiserver，並能夠在緊急狀況（如自身穩定性收到影響）下，作總體限流。
• 旁路 apiserver 配合主鏈路作藍綠、灰度（次級訴求）
  • 旁路 apiserver 可使用獨立版本，增長新功能灰度維度，如使用獨立的限流策略，如開啓新的 feature 功能驗證。
• SLB 災備（次級訴求）
  • 旁路 apiserver 能夠在主 apiserver 發生異常時，對外提供服務（需 controller 自行切換目標地址）。

2）ASI 多集羣聯邦架構升級

目前張北中心的一個機房就幾萬節點，若是不解決多集羣的管理問題，帶來的問題以下：
​

• 容災層面：把核心交易應用的中心單元部署在一個集羣的風險是很大的，最壞狀況下集羣不可用致使整個應用服務不可用。

• 性能層面：對於業務來講，如因核心應用在某一時點使用時極其敏感而設定各類單機最大限制、CPU 互斥獨佔保證，若是都部署在一個集羣的話，會由於集羣節點規模限制，致使應用發生堆疊，形成 cpu 熱點，性能不知足要求；對於 ASI 管控 Master 來講，單集羣無限制擴大，性能總會出現瓶頸，總有一天會沒法支撐。
• 運維層面：當某個應用擴容發現沒資源，SRE 還得考慮節點加到哪一個集羣，額外加大了 SRE 集羣管理的工做。

所以 ASI 須要達成統一的多集羣管理解決方案，幫助上層各個 Pass、SRE、應用研發等提供更好的多集羣管理能力，經過它來屏蔽多集羣的差別、方便的進行多方資源共享。
​
ASI 選擇基於社區聯邦 v2 版原本開發知足咱們的需求。
​

4. K8s 集羣遭遇規模增加帶來的極大性能挑戰

在一個大規模的 K8s 集羣中性能會遇到哪些問題呢？
​

• 首先是查詢相關問題。在大集羣中最重要的就是如何最大程度地減小 expensive request。對百萬級別的對象數量來講，按標籤、namespace 查詢 Pod，獲取全部 Node 等場景時，很容易形成 etcd 和 kube-apiserver OOM 和丟包，乃至雪崩等問題發生。

• 其次是寫入相關問題。etcd 適用場景是讀多寫少，大量寫請求可能會致使 db size 持續增加、寫性能達到瓶頸被限速、影響讀性能。如大量的離線做業須要頻繁的建立和刪除 pod，經過 ASI 鏈路對 pod 對象的寫放大，最終對 etcd 的寫壓力會放大幾十倍之大。

• 最後是大資源對象相關問題。etcd 適合存儲較小的 key-value 數據，在大 value 下，性能急速降低。

5. ASI 性能瓶頸突破

ASI 性能優化的方向

ASI 的性能優化能夠從 apiserver 客戶端、apiserver 服務端、etcd 存儲 3 個方面來進行優化。
​

• 客戶端側，能夠作 cache 優化，讓各個 client 優先訪問本地 informer cache，也須要作負載均衡優化，主要包括對 apiserver,etcd 的負載均衡。同時針對客戶端的各類優化，能夠經過組件性能規範，在組件啓用，准入的時候進行校驗是否知足。
• APIServer 側，能夠從訪問層，緩存層，存儲層 3 個層次進行優化。在緩存層，咱們重點建設了 cache 的索引優化以及 watch 優化，在存儲層上重點經過 snappy 壓縮算法對 pod 進行數據壓縮，在訪問層上重點建設了限流能力。

• etcd 存儲側的優化，咱們也從幾個方面作了不少工做，包括 etcd 內核層面各類算法優化工做，還有經過將不一樣資源拆分到不一樣 etcd 集羣的能力實現了基本的水平拆分能力，同時也在 etcd server 層作 multi boltdb 的擴展能力提高。

6. K8s 集羣的預防能力薄弱

在 K8s 中，kube-apiserver 做爲統一入口，全部的控制器/client 都圍繞 kube-apiserver 在工做，儘管咱們 SRE 經過組件的全生命週期進行規範約束卡點改進，好比經過在組件的啓用和集羣准入階段進行了卡點審批，經過各個組件 owner 的全面配合改造後，大量的低級錯誤獲得防範，但仍是有部分控制器或部分行爲並不可控。
​
除了基礎設施層面的故障外，業務流量的變化，是形成 K8s 很是不穩定的因素，突發的 pod 建立和刪除，若是不加以限制，很容易把 apiserver 打掛。
​
另外非法的操做或代碼 Bug 有可能形成業務 pod 影響，如不合法的 pod 刪除。
​
結合全部風險進行分層設計，逐層進行風險防控。
​

7. ASI 單集羣的預防能力增強

1）支持 API 訪問層的多維度（resource/verb/client）精細化限流

社區早期採用的限流方式主要經過 inflight 控制讀寫整體併發量，咱們當時在 apf 沒有出來以前就意識到限流能力的不足，沒有能力去對請求來源作限流。而 apf 經過 User 來作限流（或者說要先通過 authn filter）存在一些不足，一方面由於Authn 並非廉價的，另一方面它只是將 API Server 的能力按配置來作分配，並非一種限流方案和應急預案。咱們須要緊急提供一種限流能力，以應對緊急狀況，自研了 ua limiter 限流能力，並基於 ua limiter 簡單的配置方式實現了一套限流管理能力，可以很方便在幾百個集羣當中進行默認限流管理，以及完成應急限流預案。
​
下面是咱們自研的 ua limiter 限流方案和其餘限流方案的詳細對比：
​

ua limiter、APF、sentinel 在限流上的側重點是不同的：
​

• ua limiter 是根據 ua 提供一個簡單的 QPS hard limit。
• apf 更加側重於併發度的控制，考慮的是流量的隔離和隔離後的公平性。
• sentinel 功能全面，可是對於公平性的支持並無 APF 全面，同時複雜度有一些太高。

考慮咱們現階段的需求和場景，發現 ua limiter 落地最爲合適，由於咱們經過 user agent 的不一樣，來對於組件進行限流。固然後續進行更加精細的限流，仍是能夠考慮結合使用 APF 等方案進一步增強。
​
限流策略如何管理，數百套集羣，每套集羣規模都不太同樣，集羣節點數、pod 數都是不一樣的，內部組件有近百個，每一個組件請求的資源平均有 4 種，對不一樣資源又有平均 3 個不一樣的動做，若是每一個都作限流，那麼規則將會爆炸式增加，即使作收斂後維護成本也很是的高。所以咱們抓最核心的：核心資源 pod\node、核心動做（建立、刪除、大查詢）；最大規模的：daemonset 組件、PV/PVC 資源。並結合線上實際流量分析，梳理出二十條左右的通用限流策略，並將其歸入到集羣交付流程中實現閉環。
​
當新的組件接入，咱們也會對其作限流設計，若是比較特殊的，則綁定規則並在集羣准入和部署環節自動下發策略，若是出現大量的限流狀況，也會觸發報警，由 SRE 和研發去跟進優化和解決。
​

2）支持業務 POD 級別的精細化限流

全部 pod 相關的操做都會對接 Kube Defender 統一風控中心，進行秒級別、分鐘級、小時級、天級別的流控。該全局風控限流組件，實行中心端部署，維護各場景下的接口調用限流功能。
​
defender 是站在整個 K8s 集羣的視角，針對用戶發起的或者系統自動發起的有風險的操做進行防禦（流控、熔斷、校驗）和審計的風控系統。之因此作 defender，主要從如下幾個方面考慮：
​

• 相似 kubelet/controller 這樣的組件，在一個集羣中存在多個進程，任一單一進程都沒法看到全局的視圖，沒法進行準確的限流。
• 從運維視角，分散在各個組件中的限速規則難以配置與審計，當部分操做由於限流緣由失敗時，排查鏈路過長影響問題定位的效率。
• K8s 面向終態的分佈式設計，每一個組件都有決策的能力，那麼就須要一個集中的服務對那些危險決策進行風控。

defender 的框架圖以下所示：

• defender server 是 K8s 集羣級的服務，能夠部署多個，其中一個 active，其他 standby。
• 用戶能夠經過kubectl配置風控規則。
• K8s 中的組件，例如 controller，kubelet，extension-controller 等，均可以經過 defender sdk 接入 defender（改動很小），在進行危險操做前請求 defender 進行風控，根據風控結果決定是否繼續該危險操做。defender 做爲一個集羣級的風控防禦中心，爲 K8s 集羣的總體穩定性進行保駕護航。

3）數字化容量治理

在只有幾個 core 集羣的場景下，依靠專家經驗管理容量徹底能夠輕鬆搞定，但隨着容器業務的快速發展，覆蓋泛交易、中間件、新生態、新計算以及售賣區等業務在接入 ASI，短短几年時間就發展了幾百個集羣，再發展幾年數以千計萬計？如此多的集羣依靠傳統的人肉資源管理方式難以勝任，人力成本愈來愈高，特別是面臨諸如如下問題，極易形成資源使用率低下，機器資源的嚴重浪費，最終形成部分集羣容量不足致使線上風險。
​

• 組件變動不斷，業務類型和壓力也在變化，線上真實容量（到底能扛多少 qps）你們都不得而知，當業務須要增大流量時是否須要擴容？是否橫向擴容也沒法解決問題？
• 早期申請容器資源隨意，形成資源成本浪費嚴重，須要基於容器成本耗費最小化明確指導應該合理申請多少資源（包括 cpu，內存及磁盤）。同一個地域，同一個元集羣的業務集羣，一個集羣浪費了資源就會形成其餘集羣資源的緊張。

在 ASI 中，組件變化是常態，組件容量如何自適應這種變化也是一個很是大的挑戰。而平常的運維及診斷需要有精準的容量數據來做爲備容支撐。
​
所以咱們決定經過數據化指導組件申請合理的（成本低，安全）容器資源。經過數據化提供平常運維所須要的容量相關數據，完成備容，在生產水位異常時，完成應急擴容。
​

目前咱們完成了水位監控、全量風險播報、預調度、profile 性能數據定時抓取、進而經過組件規範中推動 CPU 內存以及 CPU 內存比例優化。正在作的包括自動化的規格建議，節點資源補充建議，以及自動化導入節點，結合 chatops 正在打造釘羣「一鍵備容」閉環。另外還在結合全鏈路壓測服務數據，得出各個組件的基線對比，經過風險決策，進行發佈卡點，確保組件上線安全。同時將來會結合線上真實的變動，來持續回答真實環境的 SLO 表現，精準預測容量。
​

全局高可用應急能力建設

高可用基礎能力的建設能夠爲 ASI 提供強有力的抗風險保障，從而在各類風險隱患出現時，儘量保證咱們服務的可用性。可是在風險出現後，如何快速介入消滅隱患，或者在高可用能力沒法覆蓋的故障出現後，進行有序止損，就變成了一個很是具備技術深度和橫向複雜度的工程難題，也讓 ASI 的應急能力建設成爲咱們很是重要的投入方向。
​
在建設應急體系之初，咱們的系統因爲迅速的發展和變化，不斷出現的事故和險情，明顯的暴露出當時咱們面臨的幾個嚴重的問題：
​

• 爲何客戶老是早於咱們發現問題？
• 爲何恢復須要這麼長的時間？
• 爲何一樣的問題會重複出現？
• 爲何只有幾我的能處理線上的問題？

針對這些問題，咱們也進行了充分的腦暴和探討，而且總結出如下幾個核心緣由：
​

• 發現問題手段單一：只有 metrics 數據做爲最基本暴露問題的手段。
• 定位問題能力缺少：只有少數監控大盤，核心組件的可觀測能力建設程度沒有統一。
• 恢復手段缺少體系：線上問題的修復須要臨時敲命令，寫腳本，效率低且風險大。
• 應急缺乏體系規範：缺少與業務方聯動，工程師思惟嚴重，不是以止損爲第一目標，對問題嚴重度缺少意識。
• 長期問題缺少跟蹤：線上發現的隱患，或者事故覆盤的跟進項，缺少持續跟進能力，致使重複踩坑。
• 缺少能力保鮮機制：業務變化很是快速，致使一些能力在一段時間後，進入一個「不會用也不敢用，也不能保證必定能用」的尷尬境地。

1. 應急能力建設頂層設計

針對這些亟待解決的問題，咱們也作了應急能力的頂層設計，架構圖以下：
​

應急能力建設總體能夠分爲幾個部分：
​

• 1-5-10 應急體系：針對線上出現的任何突發風險，都能作到「一分鐘發現，五分鐘定位，十分鐘恢復」的底層能力和機制。
• 問題追蹤跟進：針對線上發現的全部風險隱患，不管嚴重與否，都能持續跟蹤推動的能力。
• 能力保鮮機制：針對建設的 1-5-10 能力，鑑於其使用頻率比較低的本質特性。

2. 應急能力建設子模塊建設

針對頂層設計中的每一個子模塊，咱們都已經作出了一些階段性的工做和成果。
​

1）一分鐘發現：問題發現能力

爲了解決沒法早於客戶發現問題的難題，咱們的工做最重要的目標就是要作到：讓一切問題都無處遁形，被系統主動發現。
​
因此這就像是一場持久戰，咱們要作的，就是經過各類可能的手段去覆蓋一個又一個新的問題，攻佔一個又一個城池。
​
在這個目標的驅使下，咱們也總結出一套很是行之有效的「戰略思想」，即「1+1 思想」。它的核心觀點在於，任何發現問題的手段，均可能由於對外部的依賴或者自身穩定性的缺陷，致使偶發的失效，因此必須有可以做爲互備的鏈路來進行容錯。
​
在這個核心思想的指導下，咱們團隊建設了兩大核心能力，即黑盒/白盒報警雙通道，這兩個通道的各有各的特色：
​

• 黑盒通道：基於黑盒思想，從客戶視角把 ASI 總體當作黑盒，直接發出指令，探測正向功能；好比直接擴容一個 statefulset。
• 白盒通道：基於白盒思想，藉助系統內部暴露出來的各類維度的可觀測性數據的異常波動來發現潛在問題；好比 APIServer 的內存異常上漲。

黑盒通道對應的具體產品叫作 kubeprobe，是由咱們團隊脫胎於社區 kuberhealthy 項目的思想上進行更多的優化和改造造成的新產品，而且也成爲咱們判斷集羣是否出現嚴重風險的重要利器。
​
白盒通道的建設相對更爲複雜，它須要建設在完備的可觀測數據的基礎之上，纔可以真正發揮它的功力。因此爲此咱們首先從 metrics、日誌、事件 3 個維度分別基於 SLS 建設 3 種數據通道，將全部可觀測數據統一到 SLS 上管理。另外咱們也建設了告警中心，負責完成對當前上百套集羣的告警規則的批量管理，下發能力，最終構造了出了一個數據完備，問題覆蓋普遍的白盒告警系統。最近還在進一步將咱們的告警能力向 SLS 告警 2.0 遷移，實現更加豐富的告警功能。
​

2）五分鐘定位：問題根因自動定位能力

隨着線上問題排查經驗的不斷豐富，咱們發現有不少問題會比較頻繁地出現。它們的排查方法和恢復手段基本已經比較固化。即使某個問題背後的緣由可能有多種，可是隨着線上排查經驗的豐富，基本均可以慢慢迭代出對這個問題的排查路線圖。以下圖所示，是針對 etcd 集羣不健康的告警設計的排查路線：
​

若是把這些相對比較確認的排查經驗固化到系統中，在問題出現後能夠自動觸發造成決策，勢必能夠大幅減小咱們對線上問題的處理耗時。因此在這個方面，咱們也開始了一些相關能力的建設。
​
從黑盒通道方面，kubeprobe 構建了一套自閉環的根因定位系統，將問題排查的專家經驗下沉進系統中，實現了快速和自動的問題定位功能。經過普通的根因分析樹以及對失敗巡檢探測事件/日誌的機器學習分類算法（持續開發投入中），爲每個 KubeProbe 的探測失敗 Case 作根因定位，並經過 KubeProbe 內統一實現的問題嚴重性評估系統（目前這裏的規則仍比較簡單），爲告警的嚴重性作評估，從而判斷應該如何作後續的處理適宜，好比是否自愈，是否電話告警等等。
​

從白盒通道方面，咱們經過底層的 pipeline 引擎的編排能力，結合已經建設的數據平臺中的多維度數據，實現了一個通用的根因診斷中心，將經過各類可觀測數據從而排查問題根因的過程經過 yaml 編排的方式固化到系統中，造成一個根因診斷任務，而且在觸發任務後造成一個問題的診斷結論。而且每種結論也會綁定對應的恢復手段，好比調用預案、自愈等等。
​

兩種通道都經過釘釘機器人等手段實現相似 chatops 的效果，提高 oncall 人員的處理問題速度。
​

3）十分鐘恢復：恢復止損能力

爲了可以提高運行時故障的止損恢復速度，咱們也把恢復止損能力的建設放在第一優先級，這個方面咱們的核心準則是兩個：
​

• 止損能力要系統化，白屏化，可沉澱。
• 一切以止損爲目標，而不是以找到絕對的根由於目標。

因此在這兩個準則的驅使下，咱們作了兩個方面的工做：
​

• 建設預案中心：中心化沉澱咱們全部的止損能力到系統中，白屏管理，接入，運行。一方面也能夠將之前散落在各個研發手中或者文檔中的預案統一收攏中心端統一管理，實現了對預案的中心化管控。另外一方面預案中心也開發了支持用戶經過 yaml 編排的方式來錄入預案的能力，從而實現低成本接入。
• 建設通用止損手段集：根據過往歷史經驗，結合 ASI 的特有特性，建設多種通用的止損能力集合，做爲應急時的重要抓手。包括了組件原地重啓，組件快速擴容，controller/webhook 快速降級，集羣快速切換隻讀等等經常使用功能。

4）問題持續跟蹤機制 BugFix SLO

針對缺少跟進能力的問題，咱們提出了 BugFix SLO 機制。正如名字所描述的那樣，咱們認爲每一個發現的問題都是一個要被修復的 「Bug」，而且針對這種 Bug 咱們作了一下工做：
​

• 一方面，定義了一系列分類方法保證問題可以明確到團隊和具體的一個負責人。
• 一方面，定義解決優先級，即解決這個問題的 SLO，L1 - L4，不一樣優先級表明不一樣的解決標準，L1 表明必須當天內迅速跟進而且解決。

每兩週，經過過去一段時間收集的新的問題，咱們會產出一份穩定性週報，進行問題解決程度的通曬以及重點問題的同步。另外也會在每兩週進行一次全員拉會對齊，對每一個新問題的負責人肯定，優先級確認進行對齊。
​

5）能力驗收保鮮機制

因爲穩定性風險是相對低頻發生的，因此對穩定性能力的最好的保鮮手段就是演練，因此在這個基礎之上咱們設計或者參與了兩種演練方案，分別是：
​

• 常態化故障演練機制
• 生產突襲演練機制

【常態化演練機制】

常態化故障演練機制的核心目的在於以更頻繁的頻率對 ASI 系統相關的故障場景以及針對這個故障的恢復能力進行持續驗收，從而既發現某些組件的在穩定性方面的缺陷，也能夠驗收各類恢復手段預案的有效性。
​
因此爲了可以儘量提高演練頻率，咱們：
​

• 一方面開始建設自身的故障場景庫，將全部場景進行入庫，分類，管理，保證場景的覆蓋面夠全面。
• 另外一方面同質量保證團隊合做，充分利用其 chorus 平臺提供的注入故障能力將咱們的設計場景逐個落地，而且配置爲後臺持續運行。咱們還藉助該平臺靈活的插件豐富能力，將平臺同咱們的告警系統，預案系統進行 API 對接，在故障場景被觸發注入後，能夠徹底經過後臺自動調用的模式完整的針對這個場景的注入、檢查、恢復都經過後臺運行完成。

鑑於常態化演練的演練頻率如此之高，咱們一般在一個專用的集羣中進行持續的後臺演練場景觸發，以下降由於演練帶來的穩定性風險。

【生產突襲演練機制】

常態化故障演練即使作的再頻繁，咱們也不能徹底保證在生產集羣真的出現一樣的問題，咱們是否可以以一樣的方式進行應對；也沒有辦法真正確認，這個故障的影響範圍是否與咱們預期的範圍一致；這些問題最根本的緣由仍是在於咱們在常態化故障演練中的集羣通常是沒有生產流量的測試集羣。
​
因此在生產環境進行故障模擬纔可以更加真實的反應線上的實況，從而提高咱們對恢復手段的正確性的信心。在落地方面，咱們經過積極參與到雲原生團隊組織的季度生產突襲活動，將咱們一些相對複雜或者比較重要的演練場景實現了在生產環境的二次驗收，與此同時也對咱們的發現速度，響應速度也進行了側面評估，不只發現了一些新的問題，也爲咱們如何在測試集羣設計更符合線上真實狀況的場景帶來了不少參考輸入。

寫在最後

本篇僅做爲開篇從總體上介紹了 ASI 全局高可用體系建設上一些探索工做以及背後的思考，後續團隊會針對具體的領域好比 ASI 應急體系建設，ASI 預防體系建設，故障診斷與恢復、全鏈路精細化 SLO 建設和運營、ASI 單集羣規模的性能瓶頸突破上等多個方面進行深刻的解讀，敬請期待。