作者 | 韓堂、柘遠、沉醉
來源 |
阿裡巴巴雲原生公衆号
前言
台灣作家林清玄在接受記者采訪的時候，如此評價自己 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 單叢集規模的性能瓶頸突破上等多個方面進行深入的解讀，敬請期待。
ASI 作為雲原生的引領實施者，它的高可用，它的穩定性影響着甚至決定着阿裡集團和雲産品的業務的發展。ASI SRE 團隊長期招人，技術挑戰和機會都在，感興趣的同學歡迎來撩：[email protected]，[email protected]。
數字時代，如何更好地利用雲的能力？什麼是新型、便捷的開發模式？如何讓開發者更高效地建構應用？科技賦能社會，技術推動變革，拓展開發者的能量邊界，一切，因雲而不同。
點選立即報名活動，2021 阿裡雲開發者大會将會帶給你答案。