快速發(fā)現(xiàn)和定位問題的能力是快速恢復(fù)系統(tǒng)的基石，只有先做到快速發(fā)現(xiàn)和定位問題，才能談如何解決問題，盡量減少用戶損失。那么如何在復(fù)雜的大規(guī)模場(chǎng)景中，做到真正的先于用戶發(fā)現(xiàn)和定位問題呢？我會(huì)將我們?cè)诠芾泶笮?nbsp; Kubernetes  集群過程中快速發(fā)現(xiàn)和定位問題的一些經(jīng)驗(yàn)和實(shí)踐帶給大家——我們是如何通過自研通用鏈路探測(cè)+定向巡檢工具 KubeProbe 應(yīng)對(duì)遇到的大規(guī)模集群的穩(wěn)定性挑戰(zhàn)的。

鏈路探測(cè)： 模擬廣義用戶行為，探測(cè)鏈路和系統(tǒng)是否異常

定向檢測(cè)： 檢查集群異常指標(biāo)，發(fā)現(xiàn)未來存在或可能存在的風(fēng)險(xiǎn)點(diǎn)

系統(tǒng)增強(qiáng)： 發(fā)現(xiàn)問題提速增效，根因分析

發(fā)現(xiàn)問題之后： 后置檢查和自愈，Chat-Ops

01 業(yè)務(wù)背景和挑戰(zhàn)

Cloud Native

阿里云云原生應(yīng)用平臺(tái)的容器服務(wù)團(tuán)隊(duì)，擁有 ACK 、ASI 等產(chǎn)品，管理了大規(guī)模的 Kubernetes 集群，不僅向外部公有云用戶提供 Kubernetes 服務(wù)，還承擔(dān)了阿里巴巴集團(tuán)上云，阿里巴巴應(yīng)用全面容器化的工作。

目前，整個(gè)阿里巴巴的業(yè)務(wù)都跑在 Kubernetes 集群上并實(shí)現(xiàn)了云原生和容器化，例如：天貓/淘寶/高德/考拉/餓了么等等。容器服務(wù)作為阿里云的管控底座，各種云服務(wù)也運(yùn)行在這些集群之上，例如視頻云/dataworks /MSE 微服務(wù)引擎/MQ 消息隊(duì)列等等。我們需要對(duì)這些基礎(chǔ)設(shè)施的穩(wěn)定性負(fù)責(zé)。

現(xiàn)在，云原生的架構(gòu)越來越流行，越來越多的產(chǎn)品和應(yīng)用開始選擇云原生架構(gòu)，這里有一張圖，大致示意了現(xiàn)代的云原生應(yīng)用架構(gòu)，應(yīng)用生于云上，長(zhǎng)于云上，各級(jí)提供分層的服務(wù)，這種分層的服務(wù)能夠讓業(yè)務(wù)和應(yīng)用專注于業(yè)務(wù)層，屏蔽平臺(tái)和基礎(chǔ)設(shè)施層的復(fù)雜概念。

從穩(wěn)定性的角度來講，這種應(yīng)用的架構(gòu)分層，上層應(yīng)用的穩(wěn)定性就會(huì)開始依賴底層基礎(chǔ)設(shè)施的支持；另外，大一統(tǒng)的基座既為大規(guī)模的資源調(diào)度優(yōu)化和在離線混部提供場(chǎng)景，也對(duì)基礎(chǔ)設(shè)施團(tuán)隊(duì)維護(hù)大規(guī)模集群的穩(wěn)定性問題提出極大的挑戰(zhàn)。

這里有兩張形象的圖示可以展現(xiàn)出云原生應(yīng)用架構(gòu)下的業(yè)務(wù)應(yīng)用和平臺(tái)層基礎(chǔ)設(shè)施的關(guān)系，Kubernetes 集群是非常復(fù)雜的，一個(gè)單集群的鏈路組件就有數(shù)十個(gè)甚至上百個(gè)之多，何況是大規(guī)模的多 集群管理呢？ 但運(yùn)行在上層 的業(yè)務(wù)同學(xué) 并不會(huì)感知到 復(fù)雜，因?yàn)槲覀円呀?jīng)把復(fù)雜包掉了，留給用戶的是一個(gè)簡(jiǎn)單的統(tǒng)一接口 。 就像 淘寶這 樣的應(yīng)用其實(shí)是非常復(fù)雜的，但在 用戶看 來只 是一個(gè)簡(jiǎn)單的提交訂單而已，按鍵背后蘊(yùn)含著 極其復(fù)雜的內(nèi)容。 為什么做到這樣？ 因?yàn)槲覀儼褟?fù)雜留給了自己，把簡(jiǎn)單交給了用 戶。

很多時(shí)候，好的應(yīng)用開發(fā)者不一定是基礎(chǔ)設(shè)施專家，云原生讓業(yè)務(wù)專注業(yè)務(wù)，基礎(chǔ)設(shè)施專注基礎(chǔ)設(shè)施。同時(shí)，業(yè)務(wù)很多時(shí)候也只能關(guān)心業(yè)務(wù)自身的穩(wěn)定性，業(yè)務(wù)大多數(shù)時(shí)候沒有能力關(guān)心，或者是不希望投入大量的人力關(guān)心基礎(chǔ)設(shè)施和平臺(tái)層的穩(wěn)定性，所以，關(guān)于平臺(tái)層和基礎(chǔ)設(shè)施的穩(wěn)定性問題上，我們需要把復(fù)雜留給自己，把簡(jiǎn)單留給用戶，為用戶提供穩(wěn)定的平臺(tái)層服務(wù)。同時(shí)，更加關(guān)心全局穩(wěn)定性和全局的可用性，而不是單點(diǎn)可用性。

容器服務(wù)是阿里巴巴集團(tuán)業(yè)務(wù)以及阿里云管控/云服務(wù)的底座，上面跑著各種各樣的業(yè)務(wù)，如電商業(yè)務(wù)/中間件/二方業(yè)務(wù)/搜索/阿里云云服務(wù)等等。此外還有數(shù)百個(gè)自研和開源的組件，每年數(shù)十萬次的組件變更/數(shù)千個(gè)集群/數(shù)十萬臺(tái)節(jié)點(diǎn)，甚至大的集群?jiǎn)渭汗?jié)點(diǎn)規(guī)模已過萬。業(yè)務(wù)架構(gòu)更是紛繁復(fù)雜，有單租集群、多租集群、vc 集群、聯(lián)邦集群等等，同時(shí)還有各種在離線混布、統(tǒng)一調(diào)度、大促活動(dòng)。在運(yùn)行時(shí)也存在多種形態(tài)，如 runC，runD 等等。

因此組件的繁雜、變更頻繁、用戶場(chǎng)景各異、集群規(guī)模龐大、業(yè)務(wù)架構(gòu)復(fù)雜……都給業(yè)務(wù)帶來了挑戰(zhàn)：

挑戰(zhàn)一：如何降低系統(tǒng)風(fēng)險(xiǎn)。 場(chǎng)景復(fù)雜，業(yè)務(wù)形態(tài)各異，任何一個(gè)不起眼細(xì)節(jié)的遺漏或環(huán)節(jié)的處置不慎都有可能導(dǎo)致傷害的擴(kuò)大化；

挑戰(zhàn)二：如何對(duì)用戶集群的穩(wěn)定性負(fù)責(zé)。 如何先于用戶發(fā)現(xiàn)和定位問題成為容器服務(wù)生產(chǎn)穩(wěn)定性建設(shè)的重中之重，也是全局高可用體系的基石。

系統(tǒng)是如此的復(fù)雜，任何一個(gè)不起眼的細(xì)節(jié)遺漏或處理不慎都有可能導(dǎo)致非預(yù)期的傷害，我們要怎樣才能降低系統(tǒng)風(fēng)險(xiǎn)呢？另外我們又是如何對(duì)形態(tài)各異的用戶集群運(yùn)行時(shí)全局穩(wěn)定性負(fù)責(zé)的呢？如何才能先于用戶發(fā)現(xiàn)和定位這些集群中已經(jīng)存在或即將發(fā)生的問題，是保障集群的穩(wěn)定性建設(shè)的重中之重，也是 Kubernetes 全局高可用體系的基石。

02 思考和方案

Cloud Native

基于這些挑戰(zhàn)，我們做了一些思考和預(yù)設(shè)。下圖是一個(gè)極度簡(jiǎn)化的用戶發(fā)布擴(kuò)容鏈路，雖說極度簡(jiǎn)化，但實(shí)際我們?nèi)钥梢钥闯?，鏈路還是比較復(fù)雜的。

為了保障這次用戶的擴(kuò)容/發(fā)布鏈路暢通，我們首先帶來幾個(gè)預(yù)設(shè)：

預(yù)設(shè) 1： 鏈路復(fù)雜組件眾多，各組件分別升級(jí)迭代，數(shù)據(jù)監(jiān)控?zé)o法無死角覆蓋全部場(chǎng)景；

預(yù)設(shè) 2： 即使鏈路中各組件/節(jié)點(diǎn)監(jiān)控?cái)?shù)據(jù)正常，也不能保證集群整體鏈路 100% 可用，只有經(jīng)過實(shí)際業(yè)務(wù)全鏈路探測(cè)才能確定實(shí)際可用的結(jié)論；

預(yù)設(shè) 3： 反證法在證明集群不可用場(chǎng)景一定優(yōu)于舉證法，即使 100% 監(jiān)控?cái)?shù)據(jù)正常，但只要發(fā)布失敗則證明鏈路不通。

另外，在單集群之外，我們還要關(guān)注多集群的管理，下面是一些多集群管控中的不穩(wěn)定性因素示例，可以看到，多集群場(chǎng)景下，穩(wěn)定性管控的復(fù)雜度會(huì)被放大，我們繼續(xù)帶來幾個(gè)預(yù)設(shè)：

預(yù)設(shè) 4： 在大規(guī)模集群場(chǎng)景下數(shù)據(jù)一致性的問題會(huì)愈加顯現(xiàn)，并且可能引發(fā)嚴(yán)重故障，成為一個(gè)顯著的不穩(wěn)定因素；

預(yù)設(shè) 5： 集群內(nèi)的監(jiān)控告警鏈路存在自依賴風(fēng)險(xiǎn)，如果集群故障，則監(jiān)控告警也有可能同時(shí)故障。

接下來是我們基于以上預(yù)設(shè)的一些解決方案。

探索和解決方案

1.  鏈路探測(cè)

鏈路探測(cè)即模擬廣義上的用戶行為，探測(cè)鏈路是否暢通，流程是否無異常。

想要做到先于用戶發(fā)現(xiàn)系統(tǒng)問題，我們自己首先要成為系統(tǒng)用戶，并且是使用最多、了解最深、無時(shí)無刻不在使用和感知系統(tǒng)狀態(tài)的用戶。

所謂鏈路探測(cè)，就是模擬廣義上的用戶行為，去對(duì)集群組件鏈路中的各種等待探測(cè)的對(duì)象去做探測(cè)。此處要特別說明的是，這里的用戶并不僅僅指的是狹義上使用系統(tǒng)的同學(xué)，而是更廣義的用戶，或者可以理解和引申成為依賴下游。

另外，在實(shí)現(xiàn)全鏈路探測(cè)的同時(shí)，拆解電路，實(shí)現(xiàn)全電路中的短路探測(cè)也是非常必要的，也是對(duì)全鏈路探測(cè)的一個(gè)補(bǔ)充。

2.  定向巡檢

定向巡檢是指檢查和分析大規(guī)模集群的異常指標(biāo)，找到已有或?qū)砜赡艽嬖诘娘L(fēng)險(xiǎn)點(diǎn)，就像檢修管道一樣。

例如有若干個(gè)集群，它分為很多集群組，不同集群組之間的 etcd 冷/熱備是否配置齊備，風(fēng)控限流配置是否正常，webhook 版本是否正常，混部參數(shù)是否一致，包括它的證書有效期是不是快要到期了等等。不同的集群組之間可能有所差別，但同類型集群之間是有一個(gè)轉(zhuǎn)衡的，因此我們可以定向做一些巡檢。

接下來是關(guān)于鏈路探測(cè)的一些常見場(chǎng)景：

就像一個(gè)游戲策劃，如果他連自己制作的游戲都不玩，他可能發(fā)現(xiàn)游戲機(jī)制的問題，把這個(gè)游戲越做越好嗎？我們要做到先于用戶發(fā)現(xiàn)系統(tǒng)問題，那我們自己首先就要先成為系統(tǒng)的用戶，并且一定是使用最多的，了解最深的，無時(shí)無刻不在使用和感知系統(tǒng)狀態(tài)的用戶。

另外，所謂鏈路探測(cè)，就是讓自己成為自己系統(tǒng)的用戶，模擬廣義上的“用戶”行為去對(duì)集群/組件/鏈路里的各種等待探測(cè)的對(duì)象去做探測(cè)。

一定要注意，這里的“用戶”并不僅僅指的是狹義上使用系統(tǒng)的同學(xué)，而是更廣義的用戶，或者可以理解引申為依賴下游。

例如業(yè)務(wù)同學(xué)要發(fā)布業(yè)務(wù)，就必然要經(jīng)過 git 系統(tǒng)，再到發(fā)布系統(tǒng)，再到我們底層的基礎(chǔ)設(shè)施平臺(tái)，也就是我們的 ASI，這就是一次全鏈路探測(cè)流程。在這里業(yè)務(wù)同學(xué)就是用戶，探測(cè)對(duì)象可以是全鏈路。

但如果我們把 etcd 看作一個(gè)系統(tǒng)服務(wù)，那么 APIServer 就是它廣義上的用戶，我們模擬 APIServer 請(qǐng)求 etcd 這條鏈路的探測(cè)也就有了意義。

另外像 MSE 操作 zookeeper，外部用戶通過阿里云控制臺(tái)創(chuàng)建 ACK 集群，PaaS 平臺(tái)操作聯(lián)邦集群，甚至視頻云業(yè)務(wù)方發(fā)起一次轉(zhuǎn)碼任務(wù)，都是一樣的道理。

還有一點(diǎn)要關(guān)注的就是，雖然全鏈路探測(cè)看起來很美，但很多時(shí)候，全鏈路探測(cè)同時(shí)還很長(zhǎng)，可能等到失敗的時(shí)候問題已經(jīng)很大了。所以，在實(shí)現(xiàn)全鏈路探測(cè)的同時(shí)，拆解鏈路，實(shí)現(xiàn)全鏈路中的短鏈路探測(cè)也是非常必要的，也是對(duì)全鏈路探測(cè)的一個(gè)補(bǔ)充。

上圖是定向巡檢的場(chǎng)景，相比鏈路探測(cè)關(guān)注于鏈路可用性，定向巡檢的核心還是在大規(guī)模的集群場(chǎng)景下，數(shù)據(jù)一致性是非常困難的問題，數(shù)據(jù)不一致，將導(dǎo)致一些隱患，可能會(huì)在未來引發(fā)某些不確定性的故障。

所謂定向巡檢就是對(duì)整個(gè)集群或鏈路中的各項(xiàng)數(shù)據(jù)、指標(biāo)做已知原因的檢查，找出不一致或數(shù)據(jù)偏離的點(diǎn)，判斷是否可能引發(fā)風(fēng)險(xiǎn)，從而做到防患于未然，治未病。

比如我們這個(gè)里邊有同一種類型的集群組，A 集群發(fā)現(xiàn)它的證書有效期不到三年，而其他集群的證書有效期都有三年；B 集群的 webhook 版本可能是 v2，而其他集群的 webhook 版本是 v3；C 集群的風(fēng)控限流配置并沒有配一個(gè)驅(qū)逐 Pod 的限流，但其他集群都配配置了驅(qū)逐 Pod 的限流，這肯定是不符合預(yù)期的；再比如 D 集群的 etcd 的冷/熱備沒有配置或者是運(yùn)行不正常，我們也可以先把它檢查出來。

03 系統(tǒng)實(shí)現(xiàn)

Cloud Native

基于上面許許多多的背景預(yù)設(shè)以及方案，我們?cè)O(shè)計(jì)并實(shí)現(xiàn)了一套巡檢/探測(cè)平臺(tái)，我們?nèi)∶麨?KubeProbe (并未開源，和現(xiàn)在社區(qū)上有類似命名的項(xiàng)目沒有任何聯(lián)系)。

我們?cè)缙谝苍紤]使用社區(qū)項(xiàng)目 Kuberhealthy，并為 Kuberhealthy 做過一些代碼貢獻(xiàn)，修復(fù)過一些嚴(yán)重的代碼 Bug，最終因?yàn)楣δ苌喜惶m用于我們的場(chǎng)景，我們選擇了自研自建。

上圖是一套中心架構(gòu)，我們會(huì)有一套中心管控系統(tǒng)。用戶的用例會(huì)通過統(tǒng)一倉庫的鏡像的方式接入，使用我們通用的 sdk 庫，自定義巡檢和探測(cè)邏輯。我們會(huì)在中心管控系統(tǒng)上配置好集群和用例的關(guān)系配置，如某用例應(yīng)該執(zhí)行在哪些集群組上，并做好各種運(yùn)行時(shí)配置。我們支持了周期觸發(fā)/手動(dòng)觸發(fā)/事件觸發(fā)(如發(fā)布)的用例觸發(fā)方式。用例觸發(fā)后會(huì)在集群內(nèi)創(chuàng)建一個(gè)執(zhí)行巡檢/探測(cè)邏輯的 Pod，這個(gè) Pod 里會(huì)執(zhí)行各種用戶自定義的業(yè)務(wù)巡檢/探測(cè)邏輯，并在成功和失敗后通過直接回調(diào)/消息隊(duì)列的方式通知中心端。中心端會(huì)負(fù)責(zé)告警和用例資源清理的工作。

我舉一個(gè)例子，比如 Kubelet 在我們的組件運(yùn)維平臺(tái)上做分批發(fā)布，每批次都會(huì)觸發(fā)一次相關(guān)集群的鏈路探測(cè)用例作為后置檢查，一旦我們發(fā)現(xiàn)某次發(fā)布的后置檢查失敗，我們會(huì)阻斷掉用戶的當(dāng)前發(fā)布，防止傷害擴(kuò)大，同時(shí)第一時(shí)間告警以及通知相關(guān)同事進(jìn)入排查，是否組件新版本不符合預(yù)期。

同時(shí)，我們也支持第三方的事件回調(diào)，可以更快的集成進(jìn)三方系統(tǒng)中。

另外，我們對(duì)于某些需要 7*24 小時(shí)不間斷的高頻次短周期探測(cè)用例，我們還實(shí)現(xiàn)了另外一套常駐分布式架構(gòu)，這套架構(gòu)使用一個(gè)集群內(nèi)的 ProbeOperator 監(jiān)聽 Probe Config CRD 變化，在探測(cè) pod 中周而復(fù)始的執(zhí)行探測(cè)邏輯。這套架構(gòu)，完美復(fù)用了 KubeProbe 中心端提供的告警/根因分析/發(fā)布阻斷等等附加功能，同時(shí)使用了標(biāo)準(zhǔn)  Operator 的云原生架構(gòu)設(shè)計(jì)，常駐體系帶來了極大的探測(cè)頻率提升(因?yàn)槿サ袅藙?chuàng)建巡檢 pod 和清理數(shù)據(jù)的開銷)基本可以做到對(duì)集群的 7*24 小時(shí)無縫覆蓋，同時(shí)便于對(duì)外集成。

另外還有一個(gè)必須要提的非常重要的點(diǎn)，即平臺(tái)只是提供了一個(gè)平臺(tái)層的能力支持，真正這個(gè)東西要起作用，還是要看在這個(gè)平臺(tái)上構(gòu)建的用例是否豐富，能不能方便的讓更多人進(jìn)來寫各種巡檢和探測(cè)用例。就像測(cè)試平臺(tái)很重要，但測(cè)試用例比測(cè)試平臺(tái)更重要這個(gè)道理一樣。一些通用的 workload 探測(cè)，組件探測(cè)，固然能發(fā)現(xiàn)很多管控鏈路上的問題，但是更多的問題，甚至業(yè)務(wù)層的問題暴露，實(shí)際上依賴于基礎(chǔ)設(shè)施和業(yè)務(wù)層同學(xué)的共同努力。

從我們的實(shí)踐上來說，測(cè)試同學(xué)和業(yè)務(wù)同學(xué)貢獻(xiàn)了很多相關(guān)的檢查用例，比如測(cè)試同學(xué)貢獻(xiàn)的 ACK & ASK 的創(chuàng)建刪除全鏈路探測(cè)巡檢，金絲雀業(yè)務(wù)全鏈路擴(kuò)容用例，比如本地生活同學(xué)的 PaaS 平臺(tái)應(yīng)用檢查等等，也得到了很多穩(wěn)定性上的結(jié)果和收益。目前我們維護(hù)的巡檢/探測(cè)用例有數(shù)十個(gè)，明年有機(jī)會(huì)破百，巡檢/探測(cè)次數(shù)近 3000 萬次，明年可能會(huì)過億。目前可以提前發(fā)現(xiàn) 99%以上的集群管控問題和隱患，效果是非常好的。

04 發(fā)現(xiàn)問題之后：根因分析和事件處理

Cloud Native

接下來我們聊聊發(fā)現(xiàn)問題之后的事情，這里有一個(gè)類似于問診對(duì)話的例子，患者發(fā)現(xiàn) “哎呀我不舒服了！ ” 這就是發(fā)現(xiàn)問題。醫(yī)生參考各種化驗(yàn)單，同時(shí)做了信息聚合分析推斷，告訴患者“你已經(jīng) 24 小時(shí)沒睡覺了，你睡不著是因?yàn)槟愫芙箲]，你焦慮的根因是因?yàn)楹筇炀鸵谀┛荚嚵恕！边@便是定位問題根因，然后針對(duì)根因去解決這個(gè)問題，他告訴患者“不要擔(dān)心，我剛收到的消息，小學(xué)生已經(jīng)不需要期末考試了?！边@個(gè)過程一定要快！

來自探測(cè)鏈路的告警內(nèi)容往往是混沌的，和數(shù)據(jù)監(jiān)控告警是有所差異的。就像上文提到的，鏈路探測(cè)告警的告警很可能就是一句患者的我不舒服了，需要你作為醫(yī)生去判斷，為什么他不舒服了呢？根因是什么。而數(shù)據(jù)監(jiān)控很多時(shí)候本身就代表了原因，比如 Etcd OOM，用已有的 oncall 經(jīng)驗(yàn)可能得不到最好的效果。

另外快速定位問題和根因分析，是一個(gè)樹狀的搜索，經(jīng)驗(yàn)加工判斷的過程，也就是如何從一個(gè)混沌的表象推斷出根因，核心是邏輯。

這和健康體檢是不同的，健康體檢是列出檢查項(xiàng) 1，2，3，4，5......然后告訴你一堆數(shù)值。很多時(shí)候，即使存在體檢中心，我們?nèi)匀灰残枰t(yī)院的專業(yè)醫(yī)生來為您解讀和判斷病情，不是嗎？

同時(shí)，根因分析/問題自愈的關(guān)鍵在于專家經(jīng)驗(yàn)的下沉，也就是把專家經(jīng)驗(yàn)下沉到系統(tǒng)中去，專家經(jīng)驗(yàn)的下沉帶來的最大收益是可復(fù)用可輸出。你可以想一下，如果我們把一個(gè)最專業(yè)的醫(yī)生的能力放進(jìn)系統(tǒng)里，他是不是更方便的為每一個(gè)人分析病情呢？

這便是 KubeProbe 發(fā)現(xiàn)問題之后的全流程，我們首先會(huì)經(jīng)過一個(gè)我們自建的中心化根因分析系統(tǒng)，在這里我們會(huì)聚合分析所有和本次失敗相關(guān)的信息，包括事件/日志/變更/告警/組件升級(jí)等等，我們將這些信息進(jìn)行聚合分析，并對(duì)事件做關(guān)聯(lián)處理，最終通過一個(gè)樹狀的分析系統(tǒng)初步定位出某次探測(cè)失敗的原因，比如說 APIServer 超時(shí)或者 etcd 斷連等等。

此外我再補(bǔ)充一點(diǎn)，文本聯(lián)想也是一個(gè)很好的根因分析方式，我們可以通過機(jī)器學(xué)習(xí)訓(xùn)練文本識(shí)別的方式來聯(lián)想出和這種失敗 case 最關(guān)聯(lián)的根因，這種 AIOps 的工作我們只是略微涉及，還在持續(xù)的探索中，我們的數(shù)據(jù)量非常大，我認(rèn)為這一定是未來的方向之一。

KubeProbe 根因分析和后置處理全流程

上圖的左下方是某次我們失敗的告警，它經(jīng)過根因分析系統(tǒng)之后發(fā)現(xiàn)首先最核心，最關(guān)聯(lián)，最大的原因可能是 APIserver 的連接斷開并且當(dāng)前已經(jīng)恢復(fù)，所以可能只是偶發(fā)的網(wǎng)絡(luò)抖動(dòng)，我們暫時(shí)不用特別關(guān)注，但此時(shí)可以看到置信度為 90%。

另外還有一些可能的原因都會(huì)關(guān)聯(lián)起來。比如某個(gè)組件，這次探測(cè)它是由某一個(gè)組件發(fā)布出發(fā)的，它的發(fā)布人是 XXX，我們可以觀察這個(gè)發(fā)布對(duì) API server 會(huì)產(chǎn)生某些影響，是否多次 list watch 不符合預(yù)期，然后把 API server list watch 出問題了，置信度有 50%。

當(dāng)我們得到一個(gè)初步的原因之后，我們會(huì)進(jìn)入二次確認(rèn)系統(tǒng)做二次的原因確認(rèn)，比如我們判斷原因可能是 APIServer 超時(shí)/etcd 斷聯(lián)/節(jié)點(diǎn)超時(shí)等,我們就會(huì)自動(dòng)重新拉取一下 APIServer 接口，看一下此時(shí)是否仍然超時(shí)，是否恢復(fù)，如果恢復(fù)了，我們就普通告警，并且告訴用戶，現(xiàn)在沒事了，但是你得關(guān)注。如果沒恢復(fù)，那這就很嚴(yán)重了，屬于最高優(yōu)先級(jí)，直接電話告警。

就是這個(gè)思路，如果有系統(tǒng)無法定位的問題，并且持續(xù)無法定位，我們也會(huì)觸發(fā)高級(jí)別告警，并且會(huì)增加相關(guān)的根因分析識(shí)別樹邏輯。

過多的告警等于沒有告警，我是最討厭告警海的。從經(jīng)驗(yàn)上講，當(dāng)我們構(gòu)建了一套這樣的根因分析+二次確認(rèn)+后置檢查系統(tǒng)之后，我們的 Oncall 成本下降了 90% 以上，并且還能夠持續(xù)下降，終態(tài)可以說是無人值守，大家也可以試試類似的工作，可以說是投入小，見效大。自從這些系統(tǒng)建設(shè)起來以后，我們可以自豪的說，我們用很小的精力 Oncall 了每一個(gè)告警條目（對(duì)，是每一條告警，是數(shù)千個(gè)集群，數(shù)千萬次探測(cè)巡檢的每一條告警）并且不會(huì)有任何遺漏了。

最后是一些給 Oncall 人員的小甜品，Chat-ops。

基于 NLP 語義識(shí)別的 Chat-ops 系統(tǒng)

我們利用釘釘提供的 NLP 機(jī)器人，構(gòu)建了一套比較完善的 Chat-ops 系統(tǒng)，這樣之后我們的 Oncall 人員就可以很方便的在告警群里通過聊天的方式操作 KubeProbe 相關(guān)功能了，比如：重跑失敗探測(cè)，查詢集群狀態(tài)，拉取診斷信息，查詢探測(cè)日志，集群告警靜默。

上圖是我們操作 Chat-ops 系統(tǒng)的過程。這個(gè)過程非常方便。

比如晚上我已經(jīng)再被窩里了，這時(shí)候它給我了一個(gè)告警，比如某個(gè)集群之前出現(xiàn)了某次失敗但當(dāng)前已經(jīng)恢復(fù)了，需要我關(guān)注一下。

既然我關(guān)注了，我便希望某一個(gè)常用例再跑一次（它可能周期比較長(zhǎng)，例如一個(gè)鐘頭），由于短鏈路的用例可能隨時(shí)都在跑，此時(shí)我便告訴機(jī)器人再跑一次，機(jī)器人就會(huì)識(shí)別我的語義，將集群再跑一次。跑完之后，我再通過查詢狀態(tài)看一下這個(gè)集群當(dāng)前的狀態(tài)怎么樣了，這樣是非常方便的，有時(shí)候你晚上上班了，或者是在路上，或者是在被窩里，都也可以很舒服的去 on-call 一個(gè)系統(tǒng)了。

05 Demo 示例

Cloud Native

1、發(fā)布

2、探測(cè)列表

3、探測(cè) Pod 開始運(yùn)行

4、探測(cè)結(jié)果

5、根因分析&告警

6、Chat-ops