背景

隨著 Kubernetes 在企業(yè)中大規(guī)模使用和落地，逐漸形成了 "業(yè)務(wù) - 中臺(tái) - 基礎(chǔ)設(shè)施" 的分層技術(shù)體系；這種分層能夠屏蔽平臺(tái)和基礎(chǔ)設(shè)施層的復(fù)雜概念，讓應(yīng)用專注于業(yè)務(wù)層的研發(fā)，但同時(shí)也會(huì)導(dǎo)致上層應(yīng)用的穩(wěn)定性強(qiáng)依賴底層基礎(chǔ)設(shè)施的支持，從而對(duì)基礎(chǔ)設(shè)施在大規(guī)模集群下的穩(wěn)定性提出極大的挑戰(zhàn)：

• 由于集群規(guī)模龐大，任何單一不起眼的小問題都可能被無限放大，帶來系統(tǒng)性風(fēng)險(xiǎn)；
• 場(chǎng)景的復(fù)雜性和多樣性，也使得運(yùn)維操作出現(xiàn)不符合預(yù)期的行為難以徹底避免。

這就要求我們對(duì)于 Kubernetes 所管理的資源和對(duì)象進(jìn)行更有效的極端風(fēng)險(xiǎn)防護(hù)，盡可能緩解由于誤操作、組件版本與配置的錯(cuò)誤、或者管控代碼 bug 對(duì)業(yè)務(wù)造成不可挽回的影響。

盡管 Kubernetes 原生提供了一系列的防護(hù)機(jī)制，例如嚴(yán)格的 RBAC 校驗(yàn)機(jī)制、使用 PodDisruptionBudget（PDB）對(duì) Eviction API 執(zhí)行校驗(yàn)、較為豐富的 Admission Plugins 等，但是在實(shí)際生產(chǎn)實(shí)踐中，我們?nèi)匀话l(fā)現(xiàn)有很多無法覆蓋的場(chǎng)景。

在此背景下，字節(jié)跳動(dòng)內(nèi)部對(duì) Kubernetes 系統(tǒng)進(jìn)行了擴(kuò)展與改造，增加了一系列的防御性校驗(yàn)措施與操作約束，為運(yùn)行在 Kubernetes 上的業(yè)務(wù)提供更強(qiáng)有力的穩(wěn)定性支撐，降低極端風(fēng)險(xiǎn)。

防護(hù)加固

Kubernetes 是個(gè)相當(dāng)復(fù)雜的分布式系統(tǒng)，但其架構(gòu)設(shè)計(jì)上的核心思想還是非常簡單的。Kubernetes 通過 APIServer 提供統(tǒng)一的 API 接口實(shí)現(xiàn)對(duì)集群狀態(tài)的訪問與修改能力；各種自動(dòng)化組件能以標(biāo)準(zhǔn)化的方式與集群通信持續(xù)獲取數(shù)據(jù)，并通過本地計(jì)算當(dāng)前集群狀態(tài)與預(yù)期集群狀態(tài)之間的區(qū)別，派生出一系列的變更操作；最終通過 kubelet 在每個(gè)節(jié)點(diǎn)上執(zhí)行這些狀態(tài)變更，將集群朝著預(yù)期的狀態(tài)推進(jìn)。

由此可見，Kubernetes 組件間的交互和運(yùn)行狀態(tài)可以大致分成以下三層

• KV 存儲(chǔ)系統(tǒng)（如 etcd、Kine、Kubebrain）與 apiserver 間的交互，提供 key-value 級(jí)別的讀寫操作與事件監(jiān)聽；
• apiserver 與各種內(nèi)建或附加 controller/operator 間（以及 apiserver 與用戶間）通過 API 請(qǐng)求交互；
• apiserver 與單機(jī)節(jié)點(diǎn)組件間的交互。

根據(jù)上述分層，我們可以針對(duì)性梳理出一系列常見的系統(tǒng)性風(fēng)險(xiǎn)，并分別采取對(duì)應(yīng)的措施進(jìn)行加固以降低極端風(fēng)險(xiǎn)。

數(shù)據(jù)防護(hù)

存儲(chǔ)與 apiserver 之間的交互風(fēng)險(xiǎn)主要集中數(shù)據(jù)異常方面，例如數(shù)據(jù)的損壞與丟失等；存儲(chǔ)系統(tǒng)是 Kubernetes 的核心，是整個(gè)基于事件驅(qū)動(dòng)的分布式系統(tǒng)的基石，一旦出現(xiàn)數(shù)據(jù)異常可能直接或間接地派生出一系列的故障。具體來說可能包括但不限于以下的常見極端風(fēng)險(xiǎn)問題：

• 存儲(chǔ)集群運(yùn)維操作失誤導(dǎo)致存儲(chǔ)下線，導(dǎo)致整個(gè) Kubernetes 集群不可用；
• 管理員直接刪除 etcd 中的數(shù)據(jù)，未經(jīng)過 apiserver 做校驗(yàn)，可能導(dǎo)致一些非預(yù)期關(guān)鍵對(duì)象如 namespace、deployment、pod 等被直接刪除，并觸發(fā)對(duì)象的級(jí)聯(lián)刪除，導(dǎo)致業(yè)務(wù)大面積受損；
• 管理員因誤操作直接修改 etcd 中的數(shù)據(jù)，損壞了數(shù)據(jù)格式導(dǎo)致 apiserver 無法 decode 數(shù)據(jù)。

針對(duì)這些問題，我們?cè)谏a(chǎn)環(huán)境中采取了一系列措施——首先，盡可能標(biāo)準(zhǔn)化地約束對(duì)存儲(chǔ)集群的運(yùn)維和數(shù)據(jù)操作，在存儲(chǔ)系統(tǒng)側(cè)開啟 TLS 雙向認(rèn)證，盡量避免除了 Kubernetes 以外的用戶直接訪問存儲(chǔ)，降低數(shù)據(jù)損壞或丟失的風(fēng)險(xiǎn)；其次，對(duì)存儲(chǔ)進(jìn)行定時(shí)的備份，在極端情況下，當(dāng)發(fā)生不可逆的數(shù)據(jù)損失時(shí)，基于備份能快速恢復(fù)數(shù)據(jù)，降低損失的影響；此外，通過對(duì)其他組件進(jìn)行加固，盡可能降低數(shù)據(jù)異常派生的非預(yù)期事件對(duì)于業(yè)務(wù)的直接沖擊。

控制面防護(hù)

自動(dòng)化組件與 apiserver 之間的交互風(fēng)險(xiǎn)，主要集中在非預(yù)期操作方面。正常情況下，用戶或平臺(tái)將預(yù)期的狀態(tài)提交到 apiserver，而其他內(nèi)部組件將立即根據(jù)當(dāng)前狀態(tài)和預(yù)期狀態(tài)的區(qū)別派生出一系列的動(dòng)作，從而使集群產(chǎn)生變更；而一旦錯(cuò)誤的預(yù)期狀態(tài)被提交，集群將快速并且難以逆轉(zhuǎn)地朝著目標(biāo)狀態(tài)進(jìn)行變更。

針對(duì)這一類問題的主要防護(hù)思路，就是對(duì)關(guān)鍵對(duì)象的操作進(jìn)行一些額外的限制，例如要求在操作時(shí)額外添加一些冗余操作，形成 double check 機(jī)制，降低由于誤操作或者管控代碼 bug 引發(fā)風(fēng)險(xiǎn)的概率；具體來說，操作防護(hù)通過 Kubernetes 原生提供的擴(kuò)展機(jī)制 ValidatingAdmissionWebhook 來實(shí)現(xiàn)。我們通過 label 和 annotation 來標(biāo)記需要進(jìn)行操作防護(hù)的關(guān)鍵對(duì)象，并通過 selector 配置對(duì)這些關(guān)鍵對(duì)象以及對(duì)應(yīng)的操作進(jìn)行篩選，在 Webhook 中實(shí)現(xiàn)一系列的約束以達(dá)到防護(hù)的目的，其中包括但不限于以下這些策略：

• 防止級(jí)聯(lián)刪除針對(duì) Namespace、CRD 等根對(duì)象，一旦被刪除會(huì)導(dǎo)致級(jí)聯(lián)地觸發(fā)派生出的其他對(duì)象的刪除操作。因此我們?cè)?Webhook 中對(duì)這些類型的關(guān)鍵對(duì)象的刪除進(jìn)行攔截，避免誤操作引發(fā)級(jí)聯(lián)刪除操作引發(fā)災(zāi)難性后果。
• 顯式副本修改當(dāng)需要調(diào)整關(guān)鍵 workload 資源副本數(shù)量時(shí)，為了避免意外地將副本數(shù)量縮減至 0，我們要求在通過 UPDATE 或者 PATCH 請(qǐng)求調(diào)整副本數(shù)的同時(shí)，還需要顯式地給對(duì)象添加特定 annotation 寫入預(yù)期調(diào)整的數(shù)值作為 double check；在 Webhook 中校驗(yàn)關(guān)鍵 workload 對(duì)象進(jìn)行變更時(shí) .spec.replicas 字段中的值是否與 annotation 中提供的值保持一致，確保任何對(duì)于關(guān)鍵 workload 副本數(shù)的修改都是有意且明確的。
• 顯式資源刪除當(dāng)需要?jiǎng)h除關(guān)鍵 workload 對(duì)象時(shí)，要求在刪除對(duì)象之前先通過修改操作將 workload 的副本數(shù)降至 0；通過這種約束，我們得以避免一些誤操作，例如某些關(guān)鍵的 workload 對(duì)象未經(jīng)確認(rèn)直接，可能會(huì)觸發(fā)更多級(jí)聯(lián)的刪除操作，導(dǎo)致業(yè)務(wù)受損。
• 操作程序約束對(duì)于一些特定的業(yè)務(wù)，對(duì)于業(yè)務(wù)規(guī)格的變更有著嚴(yán)格的變更事件窗口限制，例如業(yè)務(wù)只接受在非繁忙時(shí)段對(duì)鏡像、環(huán)境變量等配置進(jìn)行變更，這樣可以降低因?yàn)橐?guī)格更改引起的潛在問題，以及相應(yīng)的業(yè)務(wù)中斷風(fēng)險(xiǎn)。我們通過 CRD 定義了可變更窗口、可變更字段等約束并暴露給用戶，在 Webhook 中根據(jù)用戶配置進(jìn)行相應(yīng)的校驗(yàn)，這樣可以確保在出現(xiàn)故障時(shí)，影響盡量少的終端用戶，確保有相對(duì)充分的故障處理時(shí)間，最大程度的減少潛在損失，降低系統(tǒng)風(fēng)險(xiǎn)。

此外，線上生產(chǎn)環(huán)境中經(jīng)常會(huì)遇到一些客戶端的異常，例如 OOM、大量緩存穿透等問題，這些異常往往會(huì)引發(fā)大量的開銷極大的讀請(qǐng)求，引發(fā)控制面異常甚至雪崩。針對(duì)線上異常流量的防護(hù)問題，我們對(duì)用戶行為進(jìn)行了一定限制，禁止了一些開銷極大的讀穿透行為。其次，我們?cè)诳刂泼媲爸昧酸槍?duì) kube-apiserver 流量特征專門定制的七層網(wǎng)關(guān) KubeGateway，它解決了 kube-apiserver 負(fù)載不均衡的問題，同時(shí)實(shí)現(xiàn)了對(duì) kube-apiserver 請(qǐng)求的完整治理，包括請(qǐng)求路由、分流、限流、降級(jí)等，顯著提高了 Kubernetes 集群的可用性。另外，我們對(duì) Kubernetes 的審計(jì)日志進(jìn)行擴(kuò)展，將一些流量相關(guān)的信息附加到審計(jì)日志上，在此基礎(chǔ)上進(jìn)行分析得到用戶畫像。在異常的場(chǎng)景下，將用戶畫像、流量監(jiān)控指標(biāo)與控制面前置的七層網(wǎng)關(guān) KubeGateway 的限流能力相結(jié)合，對(duì)給控制面提供巨大壓力的 Client 進(jìn)行流量控制，盡可能降低雪崩風(fēng)險(xiǎn)。

節(jié)點(diǎn)防護(hù)

在大多數(shù)場(chǎng)景下，pod 的刪除應(yīng)該分成兩個(gè)階段執(zhí)行：首先由中心化的 Controller 或者用戶通過發(fā)起 Delete 請(qǐng)求將 pod 標(biāo)記為刪除狀態(tài)（即添加 DeletionTimestamp），然后應(yīng)該由 kubelet 負(fù)責(zé)對(duì)業(yè)務(wù)發(fā)起優(yōu)雅退出，等待業(yè)務(wù)終止且資源釋放之后，由 kubelet 來通過 APIServer 提供的接口將 pod 徹底移除。但在生產(chǎn)實(shí)踐中，我們遇到諸多了問題，可能導(dǎo)致 kubelet 因?yàn)楫惓６穷A(yù)期地終止業(yè)務(wù) pod，例如：

• 由于配置錯(cuò)誤或者代碼 bug，導(dǎo)致 kubelet 重啟后 reject 正在運(yùn)行的業(yè)務(wù) pod，導(dǎo)致業(yè)務(wù)受損；
• 由于控制面存儲(chǔ)出現(xiàn)的數(shù)據(jù)損壞或其他異常，導(dǎo)致 kubelet 發(fā)現(xiàn)本地實(shí)際運(yùn)行的 pod 與控制面提供的本地應(yīng)該運(yùn)行的 pod 不一致，進(jìn)而引起非預(yù)期的業(yè)務(wù)退出。

針對(duì)這類問題，我們對(duì) kubelet 進(jìn)行了一系列的改造，涵蓋 admit、housekeeping 等環(huán)節(jié)。通過改造給 kubelet 刪除 pod 的操作加入前置約束：在嘗試刪除關(guān)鍵 pod 時(shí)，首先檢查 pod 是否被顯式地進(jìn)行標(biāo)記刪除，如果 pod 未被標(biāo)記刪除，則不允許 kubelet 觸發(fā) pod 的刪除操作。基于這種顯式刪除的約束，我們得以大幅度降低因?yàn)楦鞣N Kubernetes 組件異常而引發(fā)的節(jié)點(diǎn)層面的業(yè)務(wù)運(yùn)行風(fēng)險(xiǎn)。

小結(jié)

在生產(chǎn)環(huán)境中，我們主要根據(jù) Kubernetes 組件之間的交互過程識(shí)別和梳理出關(guān)鍵風(fēng)險(xiǎn)，通過特定的 label 與 annotation 對(duì)關(guān)鍵的對(duì)象進(jìn)行標(biāo)記，分別采取措施進(jìn)行一定的加固：

• 數(shù)據(jù)防護(hù)主要是約束運(yùn)維操作，收斂數(shù)據(jù)訪問入口，標(biāo)準(zhǔn)化存儲(chǔ)操作的各種行為以減小風(fēng)險(xiǎn)；
• 控制面防護(hù)主要是通過定制 ValidatingAdmissionWebhook 進(jìn)行擴(kuò)展，在對(duì)于一些關(guān)鍵對(duì)象的變更過程中，要求主動(dòng)引入一些冗余的操作與校驗(yàn)，降低誤操作風(fēng)險(xiǎn)；
• 節(jié)點(diǎn)防護(hù)主要是通過對(duì) kubelet 的進(jìn)行改造，嚴(yán)格約束關(guān)鍵 pod 必須顯式刪除，降低極端情況下的系統(tǒng)性風(fēng)險(xiǎn)。

應(yīng)用案例

字節(jié)基于原生 Kubernetes 生態(tài)定制了較多的功能以支持個(gè)性化的場(chǎng)景，整體的研發(fā)、迭代和交付的效率都非常高，對(duì)集群穩(wěn)定性造成更大的挑戰(zhàn)，即使在交付流程規(guī)范上嚴(yán)格把控，也不能完全杜絕異常情況下的極端異常風(fēng)險(xiǎn)；結(jié)合實(shí)踐過程出現(xiàn)過的故障案例和場(chǎng)景訴求，字節(jié)云原生團(tuán)隊(duì)從元集群、控制面、數(shù)據(jù)面、業(yè)務(wù)定制等多個(gè)角度，構(gòu)建了較為全面的防御體系，有效避免線上大規(guī)模事故的發(fā)生。

數(shù)據(jù)防護(hù)：元集群級(jí)聯(lián)刪除

字節(jié)內(nèi)部的集群數(shù)量眾多，為實(shí)現(xiàn)自動(dòng)化運(yùn)維和集群管理，需要構(gòu)建元集群描述業(yè)務(wù)集群的狀態(tài)；在這種情況下，元集群自身的異?？赡軙?huì)觸發(fā)更大范圍的故障。在字節(jié)早期，集群缺乏防護(hù)能力，SRE 在運(yùn)維過程中使用過高權(quán)限，誤刪除了某個(gè) region 元集群中用于描述 Node 狀態(tài)的 CRD，因?yàn)闆]有防御系統(tǒng)攔截，CRD 被刪除后會(huì)引發(fā)全量 CR 的級(jí)聯(lián)刪除，導(dǎo)致元集群控制器認(rèn)為幾乎所有的節(jié)點(diǎn)都需要下線，引發(fā)全量 pod 物理停服。該次故障最終引發(fā)單 region 生產(chǎn)集群在 30 分鐘內(nèi)持續(xù)標(biāo)記刪 3W+ 節(jié)點(diǎn)，實(shí)際刪除 9K 節(jié)點(diǎn)后及時(shí)止損，影響面巨大且手動(dòng)止損窗口很短。在該案例中，接入防御體系能夠?qū)崿F(xiàn)在多個(gè)點(diǎn)位實(shí)現(xiàn)防御能力

• 前置攔截：通過標(biāo)記 CRD 為 critial 避免全量誤刪除引發(fā)級(jí)聯(lián)問題；
• 集群下線限流：集群大范圍下線通常并不是常見的運(yùn)維操作，控制節(jié)點(diǎn)下線的頻率和安全水位，保證即使出現(xiàn)異常的級(jí)聯(lián)刪除行為，也能夠盡量控制故障域；
• 數(shù)據(jù)備份和恢復(fù)：當(dāng)發(fā)生物理對(duì)象刪除行為后，能夠通過備份數(shù)據(jù)實(shí)現(xiàn)快速的恢復(fù)。

控制面防護(hù)：異常流量識(shí)別與限流

控制面異常通常源自于不合理的客戶端行為和不夠準(zhǔn)確的服務(wù)端資源預(yù)估，由于場(chǎng)景過于復(fù)雜，在缺乏精細(xì)治理的情況下，最終因各種原因?qū)е路?wù)端過載；通常從現(xiàn)象上，會(huì)伴隨著客戶端大量的 List 請(qǐng)求和 APIServer OOM，進(jìn)一步引發(fā)全量客戶端 Relist，惡性循環(huán)直至集群出現(xiàn)雪崩。對(duì)于控制面的極端異常，字節(jié)內(nèi)部通過接入 7 層的 gateway ，配合全鏈路的自動(dòng)化流量 tracing，實(shí)現(xiàn)靈活智能的 API 請(qǐng)求防護(hù)

• 常態(tài)限流：針對(duì)客戶端和資源對(duì)象的組合和常態(tài)流量分析，定制限流規(guī)則，避免瞬時(shí)大量請(qǐng)求對(duì)服務(wù)端的壓力
• 容災(zāi)場(chǎng)景熔斷：當(dāng)集群出現(xiàn)明顯異常或者雪崩時(shí)，通過手動(dòng)熔斷止損，并逐步放開限流以恢復(fù)集群正常

節(jié)點(diǎn)防護(hù)：異常版本升級(jí)觸發(fā)大面積驅(qū)逐

相對(duì)于控制面，數(shù)據(jù)面的版本和配置通常更加復(fù)雜多樣，迭代通常會(huì)更加頻繁，更容易因?yàn)椴划?dāng)?shù)慕M件運(yùn)維操作引發(fā)不可預(yù)期的極端風(fēng)險(xiǎn)。某次 SRE 在升級(jí) Kubelet 版本的過程中，應(yīng)用了不符合預(yù)期的混部資源配置，在 Kubelet 重啟后，大量 Running 中的 pod 因?yàn)橘Y源歸屬識(shí)別錯(cuò)誤，導(dǎo)致 admit 失敗而被 delete，同時(shí)，原生的 delete API 不過 PDB 攔截，預(yù)期會(huì)引發(fā)大量業(yè)務(wù)容量的損失；但由于已經(jīng)上線防護(hù)能力，最終沒有引發(fā)嚴(yán)重的線上問題。在該案例中，接入防御體系能夠同時(shí)在單機(jī)和中心上提供防御能力

• 單機(jī)攔截：對(duì)于已經(jīng)處于 Running 狀態(tài)的核心服務(wù)，默認(rèn)補(bǔ)充 explict-deletion 標(biāo)簽，確保只有顯式地通過 API 標(biāo)記刪除 （設(shè)置 deletionTimestamp），能夠保證因?yàn)閿?shù)據(jù)面異常發(fā)版后，不影響業(yè)務(wù)實(shí)例的運(yùn)行，給人為介入處理提供足夠的時(shí)間
• 中心攔截：對(duì)于核心服務(wù)補(bǔ)充 Delete 與 DeleteCollection 兩種 API 進(jìn)行校驗(yàn)，避免類似非預(yù)期的刪除 pod 行為對(duì)業(yè)務(wù)造成影響

后續(xù)規(guī)劃

字節(jié)防護(hù)實(shí)踐未來會(huì)逐漸集成火山引擎 VKE 產(chǎn)品中，為云上的服務(wù)提供更加可靠的穩(wěn)定性保證；除此之外，我們也會(huì)持續(xù)增強(qiáng)云原生防護(hù)的功能特性，收斂并解決更多可能對(duì)云上服務(wù)造成穩(wěn)定性風(fēng)險(xiǎn)的場(chǎng)景，包括如下內(nèi)容

• 控制面 Delete pod API 防護(hù)內(nèi)建的 PDB 防護(hù)機(jī)制僅作用于 Evict pod API，校驗(yàn)性能不佳。當(dāng)存在大量 PDB 對(duì)象時(shí)，Evict pod API 耗時(shí)會(huì)大幅度劣化，請(qǐng)求時(shí)延遠(yuǎn)超 Delete pod，因此有很多組件刻意不使用 Evict pod 而直接 Delete pod，例如調(diào)度器發(fā)起搶占等。由于控制面 Delete pod 的內(nèi)置校驗(yàn)較少，直接使用該接口容易導(dǎo)致業(yè)務(wù) pod 的健康比例低于預(yù)期，影響業(yè)務(wù)正常運(yùn)行。為避免這類風(fēng)險(xiǎn)，我們一方面需要優(yōu)化 Evict pod 的性能，另一方面需要通過擴(kuò)展對(duì) Delete pod 操作進(jìn)行更嚴(yán)格的校驗(yàn)，以保證業(yè)務(wù)運(yùn)行的 pod 健康比例不低于預(yù)期。
• 收斂靜態(tài)校驗(yàn)策略當(dāng)前我們?cè)诳刂泼孀龅姆雷o(hù)工作主要依托于對(duì) Validating Admission Webhook 機(jī)制，這一方面會(huì) apiserver 在處理請(qǐng)求過程中引入額外的外部過程，提高延遲與出錯(cuò)概率，另一方面也會(huì)一定程度提高集群運(yùn)維的復(fù)雜度。在 Kubernetes 1.26 版本中，引入了新的 Admission Plugin，支持使用 CEL （Common Expression Language）對(duì)請(qǐng)求進(jìn)行一些靜態(tài)校驗(yàn)。后續(xù)我們會(huì)將控制面防護(hù)的一些冗余操作校驗(yàn)遷移到 CEL，對(duì)上述問題進(jìn)行改善。
• 場(chǎng)景定制防護(hù)策略對(duì)于 Redis 和分布式訓(xùn)練等帶存儲(chǔ)狀態(tài)的業(yè)務(wù)來說，其編排模型和運(yùn)維方案上有比較多的定制需求，為此，防御體系需要針對(duì)其業(yè)務(wù)特點(diǎn) （如存儲(chǔ)分片、縱向資源調(diào)整、原地重啟等），補(bǔ)充完善更多精細(xì)化的策略以匹配特有的極端異常風(fēng)險(xiǎn)。

總結(jié)

本文主要介紹了字節(jié)跳動(dòng)內(nèi)部生產(chǎn)環(huán)境中 Kubernetes 應(yīng)用過程中發(fā)現(xiàn)的主要系統(tǒng)風(fēng)險(xiǎn)與提出一系列防護(hù)措施。具體來說，我們從 Kubernetes 組件的交互過程的角度出發(fā)，劃分為數(shù)據(jù)、控制面、節(jié)點(diǎn)三個(gè)層面，并通過具體示例說明了常見問題，包括誤操作和管控組件版本錯(cuò)誤等等，并且針對(duì)這些常見問題，簡單介紹了我們構(gòu)建的一系列防御性措施，包括但不限于，約束組件訪問權(quán)限、主動(dòng)添加冗余操作與相關(guān)校驗(yàn)等等。通過這些防御性措施，我們能夠降低已知問題給業(yè)務(wù)帶來的風(fēng)險(xiǎn)，為業(yè)務(wù)提供穩(wěn)定的基礎(chǔ)服務(wù)。

除了必要的防御性加固措施，日常維護(hù)集群時(shí)的標(biāo)準(zhǔn)化變更流程也至關(guān)重要。通過控制集群規(guī)模并充分進(jìn)行灰度驗(yàn)證，可以降低故障的影響范圍。在生產(chǎn)環(huán)境中，只有綜合利用系統(tǒng)自我防御性措施和標(biāo)準(zhǔn)化運(yùn)維等多種手段，才能最大程度地降低風(fēng)險(xiǎn)和故障損失。