FA18# 中間件穩(wěn)定性治理內(nèi)容提點(diǎn)

引言

以業(yè)界一公司的故障舉例，由于強(qiáng)依賴缺少降級(jí)方案造成比較大的故障。

在早上8點(diǎn)到10點(diǎn)、下午5點(diǎn)到8點(diǎn)為業(yè)務(wù)高峰，也就是上下班高峰期。

容器團(tuán)隊(duì)通過(guò)彈性調(diào)度在低峰區(qū)縮容、高峰期擴(kuò)容。

容器pod的重建依賴一個(gè)摘流系統(tǒng)。

摘流負(fù)責(zé)發(fā)布前流量的拉出、發(fā)布后流量的拉入。

摘流系統(tǒng)依賴CMDB去檢查應(yīng)用的合法性。

故障發(fā)生在CMDB系統(tǒng)出現(xiàn)假死、整個(gè)CMDB無(wú)法訪問(wèn)。

?摘流系統(tǒng)無(wú)法訪問(wèn)CMDB、流量的拉入拉出失效。

在高峰期容器彈性擴(kuò)容后、無(wú)法引入流量、導(dǎo)致大量服務(wù)不可用。

反思改進(jìn)，  容器彈性擴(kuò)縮容強(qiáng)依賴摘流系統(tǒng)、缺少摘流系統(tǒng)異常的降級(jí)應(yīng)對(duì)方案。

反思改進(jìn)，  摘流系統(tǒng)強(qiáng)依賴CMDB系統(tǒng)、缺少CMBD異常后的降級(jí)措施。

反思改進(jìn)，容器彈性擴(kuò)縮容是后來(lái)新增能力，未對(duì)依賴的上下游方案通盤走查，是否存在強(qiáng)依賴以及應(yīng)對(duì)措施。

當(dāng)故障出現(xiàn)時(shí)，5分鐘發(fā)現(xiàn)、5分鐘定位、10分鐘恢復(fù)，5-5-10。

架構(gòu)設(shè)計(jì)上避免故障發(fā)生對(duì)業(yè)務(wù)的影響。

例如：RocketMQ主從跨可用區(qū)交叉部署。

例如：Kafka核心服務(wù)3個(gè)副本。

例如：注冊(cè)中心/配置中心等本地磁盤/緩存容災(zāi)設(shè)計(jì)。

提供容災(zāi)遷移能力，當(dāng)故障發(fā)生時(shí)遷移到災(zāi)備集群。

常備低水位容災(zāi)集群、一鍵/自動(dòng)遷移到災(zāi)備集群。

完善SOP應(yīng)急手冊(cè)、人員互備實(shí)時(shí)Oncall。

應(yīng)急恢復(fù)演練達(dá)到或不斷逼近10分鐘。

為什么需要重視故障演練？

提高容錯(cuò)性、可恢復(fù)性、驗(yàn)證高可用能力。

驗(yàn)證關(guān)鍵指標(biāo)等告警的時(shí)效性。

應(yīng)急操作恢復(fù)的時(shí)效演練。

場(chǎng)景：磁盤IO、CPU飆高、磁盤損壞、節(jié)點(diǎn)宕機(jī)、主從切換、網(wǎng)絡(luò)分區(qū)等。

符合預(yù)期，心里有數(shù)。

不符預(yù)期，強(qiáng)化改進(jìn)。

不同等級(jí)中間件需符合停留期要求。

變更范圍由小到大驗(yàn)證。

變更從非核心服務(wù)到核心服務(wù)驗(yàn)證。

中間件變更需要整理文檔，變更文檔需要織評(píng)審。

滿足可監(jiān)控、可應(yīng)急、可灰度基本要求。

變更單需要審批流程。

每個(gè)組件梳理完善關(guān)鍵指標(biāo)。

吞吐QPS、連接數(shù)、節(jié)點(diǎn)數(shù)量、響應(yīng)時(shí)間、節(jié)點(diǎn)可用性、硬件指標(biāo)水位。

確保指標(biāo)監(jiān)控告警暢通有效。

每周定期巡檢確保水位正常。

定期復(fù)盤線上涉及中間件的案例。

業(yè)界的典型案例分析并沉淀文檔。

舉一反三其他組件和場(chǎng)景。

把別人的經(jīng)驗(yàn)變成自己的。

反思自身組件需要提高的點(diǎn)。

變更須組織CR并落實(shí)記錄。

記錄CR文檔，例如：需求、分支、代辦改進(jìn)項(xiàng)。

強(qiáng)化代碼評(píng)論，注意評(píng)論與代碼對(duì)應(yīng)。

使用CR工具，例如：GitLab Merge Requests

先講解代碼結(jié)構(gòu)與主流程。

靜默閱讀對(duì)代碼做出評(píng)論。

互備同學(xué)主評(píng)/其他人參評(píng)。

講解人對(duì)評(píng)論解釋和答疑。

總之，不斷嘗試更為有效的CR方式。