1. 內(nèi)容整體設(shè)計(jì)與思路拆解1.1 高效運(yùn)維的本質(zhì)把“救火”變成“防火”干了這么多年運(yùn)維我一直覺(jué)得“高效運(yùn)維”這四個(gè)字被很多人誤解了。有人覺(jué)得運(yùn)維效率高就是腳本寫(xiě)得溜、工單處理得快、半夜報(bào)警響應(yīng)及時(shí)這套說(shuō)法聽(tīng)起來(lái)熱血但本質(zhì)上還是在“救火”。真正的運(yùn)維效率是把功夫下在“防火”上——讓系統(tǒng)壓根就不出故障或者出了故障能自動(dòng)恢復(fù)、能快速定位而不是靠人肉盯著屏幕輪番值班?！案呖捎孟到y(tǒng)”這個(gè)話題每個(gè)團(tuán)隊(duì)都在喊但真正落地的少。原因在于高可用不是一個(gè)開(kāi)關(guān)打開(kāi)就有了它是一整套工程體系的組合拳監(jiān)控、容量、架構(gòu)、發(fā)布、數(shù)據(jù)、故障演練、復(fù)盤(pán)改進(jìn)缺一環(huán)都不行。我這篇文章把這套體系收斂成七大核心策略不是拍腦袋想的而是這些年團(tuán)隊(duì)踩坑、復(fù)盤(pán)、優(yōu)化后沉淀下來(lái)的有效做法。寫(xiě)這篇文章之前我先把讀者對(duì)象梳理了一遍既有剛?cè)胄袃扇?、想把系統(tǒng)穩(wěn)定性做扎實(shí)的初中級(jí)運(yùn)維工程師也有帶團(tuán)隊(duì)、需要從體系層面搭建高可用方案的Tech Lead。這兩類(lèi)人的訴求不一樣前者需要“具體怎么做”后者需要“為什么這么做、整體怎么串起來(lái)”。我盡量在每一節(jié)里把實(shí)操和思路都覆蓋到方便不同基礎(chǔ)的讀者各取所需。1.2 七大策略的定位與整體協(xié)同關(guān)系在正式展開(kāi)每一節(jié)之前我先把七大策略的整體邏輯擺出來(lái)方便大家有一個(gè)鳥(niǎo)瞰圖。策略模塊核心作用解決的核心問(wèn)題章節(jié)號(hào)監(jiān)控與可觀測(cè)性系統(tǒng)狀態(tài)的“眼睛”故障發(fā)生時(shí)能否第一時(shí)間發(fā)現(xiàn)并定位2容量規(guī)劃與彈性伸縮系統(tǒng)的“呼吸能力”突發(fā)流量下能否扛住而不被打掛3冗余架構(gòu)與故障切換系統(tǒng)的“備用心臟”單點(diǎn)故障時(shí)服務(wù)能否繼續(xù)工作4自動(dòng)化發(fā)布與變更管理系統(tǒng)的“穩(wěn)定方向盤(pán)”變更和發(fā)布能否不引入新的故障5數(shù)據(jù)可靠性與備份恢復(fù)系統(tǒng)的“記憶保險(xiǎn)柜”數(shù)據(jù)損壞或丟失時(shí)能否恢復(fù)6故障演練與混沌工程系統(tǒng)的“壓力測(cè)試儀”預(yù)案在真實(shí)故障面前是否有效7復(fù)盤(pán)機(jī)制與持續(xù)改進(jìn)系統(tǒng)的“進(jìn)化引擎”每一個(gè)故障能否轉(zhuǎn)化為系統(tǒng)能力的提升8這個(gè)結(jié)構(gòu)不是隨便排的。你可以把它理解成一個(gè)人體的健康體系監(jiān)控是感官神經(jīng)容量是心肺功能冗余是免疫系統(tǒng)備份自動(dòng)化是肌肉記憶數(shù)據(jù)是大腦記憶演練是疫苗復(fù)盤(pán)是新陳代謝。任何一個(gè)器官出問(wèn)題整個(gè)人都會(huì)垮。高可用系統(tǒng)的建設(shè)也是同理別指望靠某一項(xiàng)“神操作”一勞永逸。2. 高效運(yùn)維的生命線監(jiān)控體系與可觀測(cè)性建設(shè)2.1 從“看指標(biāo)”到“看故事”監(jiān)控的三個(gè)層級(jí)監(jiān)控這個(gè)話題老生常談但我發(fā)現(xiàn)很多團(tuán)隊(duì)的監(jiān)控還停留在“紅燈亮了才知道出事了”的階段。我自己的理解是監(jiān)控體系要分三個(gè)層級(jí)往上搭。第一層是基礎(chǔ)監(jiān)控CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)這一層解決的是“機(jī)器死了沒(méi)有”的問(wèn)題工具用Zabbix、Prometheus node_exporter都行。第二層是應(yīng)用監(jiān)控接口QPS、RT、錯(cuò)誤率、JVM指標(biāo)、慢SQL等這一層解決的是“服務(wù)活著但是否健康”的問(wèn)題通常需要接入SkyWalking、Micrometer或者通過(guò)日志埋點(diǎn)實(shí)現(xiàn)。第三層是業(yè)務(wù)監(jiān)控訂單量、支付成功率、用戶登錄失敗率等這一層解決的是“用戶體驗(yàn)是否受損”的問(wèn)題往往需要研發(fā)和運(yùn)維一起定義關(guān)鍵業(yè)務(wù)指標(biāo)。我見(jiàn)過(guò)太多團(tuán)隊(duì)在第二層和第三層基本是裸奔的。機(jī)器指標(biāo)一切正常但用戶已經(jīng)在報(bào)障說(shuō)頁(yè)面打不開(kāi)了為什么因?yàn)閼?yīng)用線程池被打滿了或者數(shù)據(jù)庫(kù)連接池耗盡這些是基礎(chǔ)監(jiān)控看不出來(lái)的。所以監(jiān)控建設(shè)一定要從“看機(jī)器”向“看應(yīng)用”“看業(yè)務(wù)”演進(jìn)。2.2 指標(biāo)采集到底該怎么做黃金四信號(hào)實(shí)戰(zhàn)Google SRE圈子里有個(gè)經(jīng)典說(shuō)法叫“黃金四信號(hào)”延遲、流量、錯(cuò)誤、飽和度。這四個(gè)信號(hào)覆蓋了用戶可感知的絕大部分問(wèn)題我強(qiáng)烈建議每個(gè)團(tuán)隊(duì)在搭建應(yīng)用監(jiān)控時(shí)優(yōu)先把這幾類(lèi)指標(biāo)做全。以我這邊一個(gè)典型訂單服務(wù)的指標(biāo)定義為例延遲接口P50、P95、P99響應(yīng)時(shí)間其中P99最敏感尾延遲往往是系統(tǒng)劣化的先兆流量每秒請(qǐng)求數(shù)QPS、活躍連接數(shù)、網(wǎng)絡(luò)吞吐量錯(cuò)誤HTTP 5xx比例、業(yè)務(wù)錯(cuò)誤碼比例、RPC調(diào)用失敗率飽和度CPU使用率、內(nèi)存使用率、線程池活躍線程數(shù)、數(shù)據(jù)庫(kù)連接池使用率有些人會(huì)問(wèn)為什么P99比平均值重要一個(gè)很形象的類(lèi)比平均值是“全班平均水平”但只要有尖刺就會(huì)有一批用戶是“不及格”的。平均RT 100ms看著很健康但P99可能已經(jīng)到了2秒意味著1%的用戶正在忍受卡頓。在互聯(lián)網(wǎng)系統(tǒng)里這部分用戶很可能就是流失的那批人。采集和存儲(chǔ)選型上現(xiàn)在Prometheus Grafana Alertmanager基本是事實(shí)標(biāo)準(zhǔn)。如果你維護(hù)的是Kubernetes環(huán)境Prometheus Operator更是標(biāo)配。指標(biāo)保留策略通常是原始數(shù)據(jù)保留15天降精度數(shù)據(jù)保留6個(gè)月以上。別把所有數(shù)據(jù)都無(wú)限期存著成本扛不住也沒(méi)那個(gè)必要。2.3 日志與鏈路追蹤排障時(shí)的第二雙眼睛光有指標(biāo)還不夠指標(biāo)能告訴你“哪里出了問(wèn)題”但很難告訴你“為什么出問(wèn)題”。這時(shí)候就要靠日志和鏈路追蹤。日志這塊我強(qiáng)烈建議走ELK或者Loki這套路徑。ELKElasticsearch Logstash Kibana功能全、查詢能力強(qiáng)但資源消耗也大Loki是Grafana出品的輕量方案與Prometheus天然集成學(xué)習(xí)成本低。選哪個(gè)不重要重要的是必須集中采集別等到故障時(shí)逐臺(tái)登錄服務(wù)器看日志。鏈路追蹤方面SkyWalking是國(guó)內(nèi)用得比較多的一套開(kāi)源免費(fèi)支持Java、Go、Python等多語(yǔ)言探針能清晰展示一次請(qǐng)求在網(wǎng)關(guān)、服務(wù)A、服務(wù)B、數(shù)據(jù)庫(kù)之間的耗時(shí)分布。接入鏈路追蹤的價(jià)值在排查跨服務(wù)故障時(shí)體現(xiàn)得最明顯用戶反饋一個(gè)功能很慢你通過(guò)Trace ID可以立刻定位到慢在哪一環(huán)——是下游接口慢了還是數(shù)據(jù)庫(kù)查詢慢了一次就能定位不用再像以前那樣靠猜。3. 容量規(guī)劃與彈性伸縮讓系統(tǒng)學(xué)會(huì)呼吸3.1 容量規(guī)劃不是“算命”是有方法論的成本控制很多團(tuán)隊(duì)的容量規(guī)劃只有三個(gè)字——“加機(jī)器”。流量漲了加機(jī)器雙十一了加機(jī)器加完發(fā)現(xiàn)沒(méi)流量了再下線。這樣做不能說(shuō)錯(cuò)但效率極低成本也沒(méi)譜。真正高效的容量規(guī)劃得從“被動(dòng)響應(yīng)”轉(zhuǎn)向“主動(dòng)預(yù)測(cè)”。我推薦的做法是從三個(gè)維度做容量評(píng)估歷史基線過(guò)去30天/90天的業(yè)務(wù)峰值、增長(zhǎng)趨勢(shì)、同比環(huán)比數(shù)據(jù)業(yè)務(wù)預(yù)測(cè)運(yùn)營(yíng)活動(dòng)排期、新功能上線計(jì)劃、市場(chǎng)投放節(jié)奏鏈路傳導(dǎo)單核心接口QPS變化會(huì)傳導(dǎo)到下游數(shù)據(jù)庫(kù)、緩存、MQ的調(diào)用量變化具體計(jì)算上有一個(gè)樸素但實(shí)用的公式預(yù)估峰值QPS 歷史日均QPS × 突發(fā)系數(shù)建議2~4視業(yè)務(wù)而定 × 預(yù)留冗余系數(shù)1.5左右如果你們系統(tǒng)歷史日均QPS是5000突發(fā)系數(shù)取3冗余系數(shù)取1.5那預(yù)估峰值就是22500 QPS。然后根據(jù)單機(jī)壓測(cè)數(shù)據(jù)——比如單機(jī)能扛1000 QPS——就能粗略算出至少需要23臺(tái)實(shí)例。這只是入口QPS下游DB和緩存還要單獨(dú)算。3.2 彈性伸縮的具體落地HPA與定時(shí)伸縮有了容量預(yù)估下一步就是“怎么把資源用起來(lái)又不會(huì)浪費(fèi)”。彈性伸縮是解決這個(gè)問(wèn)題的核心手段。在Kubernetes環(huán)境里HPAHorizontal Pod Autoscaler是最常用的方案。配置其實(shí)不復(fù)雜核心是指標(biāo)選擇與閾值設(shè)定。我以一個(gè)Web服務(wù)為例給個(gè)參考配置apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 3 maxReplicas: 30 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 65 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 75注意幾個(gè)關(guān)鍵點(diǎn)第一個(gè)是目標(biāo)利用率不要設(shè)得太低比如50%以下會(huì)導(dǎo)致擴(kuò)容過(guò)于靈敏流量一抖就瘋狂擴(kuò)成本飆升第二個(gè)是minReplicas必須保證大于等于2這是高可用的底線第三個(gè)是HPA生效有延遲從指標(biāo)采集到擴(kuò)容完成通常需要3~5分鐘所以對(duì)突發(fā)行流量HPA往往是來(lái)不及的。對(duì)于可預(yù)期的流量高峰——比如電商大促、秒殺活動(dòng)、每周一早晨的集中訪問(wèn)——我建議直接用定時(shí)伸縮方案。KEDA這個(gè)開(kāi)源項(xiàng)目支持Cron觸發(fā)器可以設(shè)定每天10:00自動(dòng)擴(kuò)容到20個(gè)Pod22:00再縮回來(lái)這種“預(yù)知未來(lái)”的擴(kuò)容方式比HPA更主動(dòng)也更省錢(qián)。3.3 別忽略容量陷阱那些“看不見(jiàn)”的瓶頸容量規(guī)劃最常見(jiàn)的坑是只盯著應(yīng)用實(shí)例忽視了鏈路上下游的容量瓶頸。真實(shí)案例是這樣的某團(tuán)隊(duì)給前端應(yīng)用加了20個(gè)Pod結(jié)果數(shù)據(jù)庫(kù)連接池被打滿數(shù)據(jù)庫(kù)CPU飆到100%整個(gè)服務(wù)直接雪崩。容量規(guī)劃必須“端到端”地做入口網(wǎng)關(guān)、應(yīng)用層、緩存層、消息隊(duì)列、數(shù)據(jù)庫(kù)每一層的容量和限流閾值都要評(píng)估。數(shù)據(jù)庫(kù)這塊我建議壓測(cè)時(shí)重點(diǎn)關(guān)注連接數(shù)和慢查詢數(shù)量。連接數(shù)一旦打滿應(yīng)用層會(huì)拿不到連接表現(xiàn)為接口RT飆升、報(bào)獲取連接超時(shí)。而慢查詢的殺傷力更隱蔽一條慢SQL能把CPU打滿把整個(gè)庫(kù)拖垮。所以容量規(guī)劃不僅要看流量峰值還要同步推動(dòng)研發(fā)把慢SQL治理掉這是“降本增效”的一個(gè)暗招。4. 冗余架構(gòu)與故障切換讓單點(diǎn)不再是單點(diǎn)4.1 單點(diǎn)故障的高可用設(shè)計(jì)原則高可用架構(gòu)的核心原則就一句話任何一臺(tái)機(jī)器、任何一個(gè)組件掛掉系統(tǒng)都要能繼續(xù)運(yùn)行。反過(guò)來(lái)說(shuō)凡是存在單點(diǎn)的地方就是系統(tǒng)的命門(mén)。以常規(guī)的微服務(wù)部署為例至少要做到這套底線應(yīng)用層至少2個(gè)副本分布在不同的物理機(jī)/可用區(qū)負(fù)載均衡至少2個(gè)節(jié)點(diǎn)前面用VIP或DNS輪詢數(shù)據(jù)庫(kù)主從復(fù)制至少1個(gè)從庫(kù)主庫(kù)故障時(shí)可切換緩存采用集群模式如Redis Sentinel或Redis Cluster消息隊(duì)列集群部署至少3個(gè)節(jié)點(diǎn)可能有人覺(jué)得“我們系統(tǒng)沒(méi)那么重要掛了也沒(méi)什么”但我想說(shuō)一個(gè)殘酷的事實(shí)高可用不是大廠的專利任何線上系統(tǒng)對(duì)用戶來(lái)說(shuō)都是“100%或0%”的體驗(yàn)差距。你半夜掛了一個(gè)小時(shí)可能白天就有一批用戶流失了。寧可平時(shí)多花點(diǎn)成本維護(hù)冗余也不要在關(guān)鍵時(shí)刻賭運(yùn)氣。4.2 數(shù)據(jù)庫(kù)高可用的主流選型與切換機(jī)制數(shù)據(jù)庫(kù)是整個(gè)系統(tǒng)里最脆弱也最重要的一環(huán)。我以MySQL為例講講幾種高可用方案。最簡(jiǎn)單的是主從復(fù)制 MHAMaster High Availability自動(dòng)切換。MHA能在主庫(kù)故障后30秒內(nèi)完成從庫(kù)提升和VIP漂移成本低、部署簡(jiǎn)單適合中小團(tuán)隊(duì)。缺點(diǎn)是切換過(guò)程中可能會(huì)有少量數(shù)據(jù)丟失取決于半同步復(fù)制是否開(kāi)啟同時(shí)從庫(kù)要承擔(dān)讀流量的話切主后需要重新評(píng)估負(fù)載。再進(jìn)階一點(diǎn)是MySQL InnoDB Cluster基于Group Replication內(nèi)置了故障檢測(cè)和自動(dòng)切換能力配合MySQL Router可以實(shí)現(xiàn)應(yīng)用無(wú)感知的主從切換。這個(gè)方案的優(yōu)點(diǎn)是官方支持、運(yùn)維相對(duì)省心缺點(diǎn)是對(duì)版本和配置有要求需要一定的學(xué)習(xí)成本。如果是金融級(jí)場(chǎng)景數(shù)據(jù)零丟失是硬指標(biāo)那就要上“兩地三中心”這類(lèi)容災(zāi)架構(gòu)了。這種方案比較復(fù)雜需要結(jié)合業(yè)務(wù)重要性和預(yù)算來(lái)權(quán)衡但至少你要理解數(shù)據(jù)一致性要求越高高可用的實(shí)現(xiàn)成本就越高這是繞不開(kāi)的。4.3 故障切換的常見(jiàn)誤區(qū)和切換后的“二次災(zāi)害”故障切換做得好不好不是看切換多快而是看切換后系統(tǒng)是否穩(wěn)定。我見(jiàn)過(guò)不少團(tuán)隊(duì)主庫(kù)一掛腳本自動(dòng)切到從庫(kù)以為萬(wàn)事大吉結(jié)果發(fā)現(xiàn)從庫(kù)只有一半的數(shù)據(jù)業(yè)務(wù)邏輯大面積報(bào)錯(cuò)。為什么因?yàn)閺膸?kù)并不一定追上主庫(kù)的最新日志強(qiáng)制切換之后丟數(shù)據(jù)是難免的。這類(lèi)問(wèn)題的解法一是開(kāi)啟半同步復(fù)制降低主從切換時(shí)的數(shù)據(jù)丟失概率二是在切換前由腳本自動(dòng)檢查從庫(kù)的Seconds_Behind_Master如果延遲過(guò)大寧可報(bào)警等人工決策也不要自動(dòng)切換。自動(dòng)化不是目的自動(dòng)化之后依然安全才是目的。另外還要提防故障切換引發(fā)的“二次災(zāi)害”主庫(kù)掛了流量全部打到從庫(kù)從庫(kù)瞬間被讀流量壓垮或者切完后應(yīng)用連接池還持有舊主庫(kù)的連接導(dǎo)致大量報(bào)錯(cuò)。針對(duì)前者切換前一定要評(píng)估從庫(kù)容量必要時(shí)先限流針對(duì)后者應(yīng)用側(cè)連接池要配置自動(dòng)重連或者切換腳本里先重啟應(yīng)用實(shí)例讓連接池重建。5. 自動(dòng)化發(fā)布與變更管理變更是故障的最大源頭5.1 為什么發(fā)布和變更最危險(xiǎn)根據(jù)我自己的統(tǒng)計(jì)線上故障中有相當(dāng)高的比例是由變更觸發(fā)的——發(fā)版本、改配置、擴(kuò)縮容、數(shù)據(jù)庫(kù)變更每一樣都可能在瞬間把系統(tǒng)搞掛。不是代碼寫(xiě)得爛而是“變更”這個(gè)動(dòng)作本身就意味著系統(tǒng)在從一種狀態(tài)向另一種狀態(tài)遷移遷移的中間態(tài)是最脆弱的。所以高可用體系里變更管理不是流程負(fù)擔(dān)而是保命環(huán)節(jié)。你把發(fā)布控制好了系統(tǒng)穩(wěn)定性就贏了一半。5.2 一套可落地的灰度發(fā)布方案我推薦在團(tuán)隊(duì)里推動(dòng)“灰度發(fā)布 快速回滾”的發(fā)布模式這是效率和風(fēng)險(xiǎn)的平衡點(diǎn)。具體分三步第一步小流量驗(yàn)證把新版本部署到1%的實(shí)例上讓少量真實(shí)流量過(guò)一遍觀察核心指標(biāo)是否有異常。如果異常指標(biāo)超過(guò)閾值立即觸發(fā)自動(dòng)回滾。第二步逐步放量5%→20%→50%→100%每一檔停留一段時(shí)間觀察錯(cuò)誤率和延遲曲線沒(méi)有異常再繼續(xù)。第三步全量發(fā)布后觀察至少再盯30分鐘黃金指標(biāo)確保沒(méi)有延遲性問(wèn)題。這里給一個(gè)很實(shí)用的下沉部署方案——在Kubernetes里通過(guò)Service的標(biāo)簽選擇器控制流量權(quán)重。假設(shè)你有兩個(gè)Deployment一個(gè)穩(wěn)定版一個(gè)金絲雀版可以通過(guò)如下方式逐步調(diào)整Service后端的Pod數(shù)量比例# 穩(wěn)定版 99 個(gè)副本金絲雀版 1 個(gè)副本即 1% 流量打到新版本 kubectl scale deployment order-service-stable --replicas99 kubectl scale deployment order-service-canary --replicas1 # 觀察無(wú)異常后調(diào)整比例 kubectl scale deployment order-service-canary --replicas20這種方式不需要額外引入Istio這類(lèi)服務(wù)網(wǎng)格純粹利用Kubernetes原生能力清爽直接。如果你的團(tuán)隊(duì)用Spring Cloud那可以借助Nacos或Eureka的權(quán)重配置來(lái)調(diào)節(jié)流量比例原理相似。5.3 發(fā)布過(guò)程中的“人的因素”自動(dòng)化發(fā)布推進(jìn)過(guò)程中最大的障礙往往不是技術(shù)而是人的習(xí)慣。有些老工程師習(xí)慣于“登錄服務(wù)器、拉代碼、重啟服務(wù)”覺(jué)得這樣最快。但從高可用的角度這種方式極度危險(xiǎn)人為操作容易漏步驟、難審計(jì)、不可回滾一旦出問(wèn)題連操作記錄都很難還原。我建議團(tuán)隊(duì)用Jenkins或GitLab CI/CD把發(fā)布流程做成模板所有發(fā)布必須走流水線。流水線里強(qiáng)制包含編譯構(gòu)建→單元測(cè)試→鏡像構(gòu)建與掃描→部署到測(cè)試環(huán)境→自動(dòng)化冒煙測(cè)試→灰度環(huán)境部署→生產(chǎn)發(fā)布。每一步失敗都會(huì)中止后續(xù)步驟發(fā)布結(jié)果有據(jù)可查。推行初期會(huì)有人抵觸但堅(jiān)持兩三個(gè)月后大家會(huì)發(fā)現(xiàn)“標(biāo)準(zhǔn)化的發(fā)布”反而更省事因?yàn)槌鲥e(cuò)概率大幅下降了。6. 數(shù)據(jù)可靠性與備份恢復(fù)高可用的最后防線6.1 備份的本質(zhì)是“可恢復(fù)”而不是“有備份”很多團(tuán)隊(duì)有一個(gè)致命誤區(qū)以為做了備份就等于數(shù)據(jù)安全了。但備份不經(jīng)過(guò)恢復(fù)演練約等于沒(méi)有備份。我見(jiàn)過(guò)一個(gè)典型案例某團(tuán)隊(duì)每天自動(dòng)備份數(shù)據(jù)庫(kù)文件都完整地存在對(duì)象存儲(chǔ)里大家都覺(jué)得萬(wàn)無(wú)一失。后來(lái)機(jī)房斷電導(dǎo)致磁盤(pán)損壞恢復(fù)時(shí)才發(fā)現(xiàn)的備份文件從某天起因?yàn)闄?quán)限變更不再更新而恢復(fù)流程也因?yàn)槿鄙傥臋n沒(méi)人會(huì)操作。最后只能依賴遠(yuǎn)程異地副本多花了十幾個(gè)小時(shí)才恢復(fù)業(yè)務(wù)損失嚴(yán)重。把這句話刻在腦子里備份的驗(yàn)收標(biāo)準(zhǔn)不是“備份任務(wù)成功”而是“能從備份中成功恢復(fù)出完整數(shù)據(jù)”。6.2 MySQL的備份恢復(fù)實(shí)操指南以MySQL為例我推薦“全量備份 binlog增量”的組合策略。全量備份每天一次使用物理備份工具如Percona XtraBackup因?yàn)槲锢韨浞荼萴ysqldump邏輯備份快得多尤其適合上GB級(jí)的數(shù)據(jù)量。binlog增量則通過(guò)開(kāi)啟MySQL的binlog并設(shè)置合適的保留天數(shù)通常至少7天來(lái)實(shí)現(xiàn)。每次備份后我強(qiáng)烈建議做一次“備份有效性檢查”自動(dòng)將備份文件恢復(fù)到一臺(tái)臨時(shí)實(shí)例上執(zhí)行幾個(gè)關(guān)鍵表的COUNT(*)校驗(yàn)對(duì)比源庫(kù)的行數(shù)是否一致。這個(gè)檢查要寫(xiě)進(jìn)腳本每天自動(dòng)跑失敗就報(bào)警。這算是運(yùn)維里性價(jià)比最高的一道保險(xiǎn)了?；謴?fù)演練至少一個(gè)季度做一次。我這邊幾個(gè)關(guān)鍵數(shù)據(jù)庫(kù)的恢復(fù)時(shí)長(zhǎng)參考單實(shí)例500GB數(shù)據(jù)量從備份和binlog恢復(fù)到故障前時(shí)間點(diǎn)目標(biāo)RTO控制在4小時(shí)內(nèi)。如果你們團(tuán)隊(duì)還沒(méi)做過(guò)一次真正的恢復(fù)演練我建議從這個(gè)季度開(kāi)始補(bǔ)上。6.3 數(shù)據(jù)變更的安全底線先備份再操作除了日常備份還有一類(lèi)高危操作需要單獨(dú)防護(hù)開(kāi)發(fā)或DBA直接在線上執(zhí)行DELETE、UPDATE、ALTER TABLE等變更。這類(lèi)操作一旦寫(xiě)錯(cuò)條件比如忘加WHERE那幾條SQL就能把整張表清空而且很難閃回。我的經(jīng)驗(yàn)是給這類(lèi)操作加三道鎖第一道操作前必須對(duì)目標(biāo)表做一次快速備份比如用mysqldump只導(dǎo)出該表的數(shù)據(jù)保存到安全位置第二道操作必須在自動(dòng)化平臺(tái)上執(zhí)行平臺(tái)會(huì)做語(yǔ)法檢查、影響行數(shù)預(yù)估、超時(shí)機(jī)制第三道高危語(yǔ)句如無(wú)WHERE的DELETE/UPDATE必須經(jīng)過(guò)雙人審批才能執(zhí)行第三道這道防線尤其重要。有一次我們團(tuán)隊(duì)來(lái)了個(gè)實(shí)習(xí)生在測(cè)試環(huán)境模擬數(shù)據(jù)清理寫(xiě)了一條沒(méi)有WHERE的DELETE如果不是平臺(tái)攔截他差點(diǎn)在測(cè)試庫(kù)把整個(gè)用戶表清空。測(cè)試環(huán)境也就罷了生產(chǎn)環(huán)境一旦發(fā)生可能就得靠備份來(lái)“擦屁股”了。7. 故障演練與混沌工程在平時(shí)準(zhǔn)備好戰(zhàn)時(shí)的預(yù)案7.1 故障演練為什么不可或缺有一個(gè)很扎心的規(guī)律沒(méi)演練過(guò)的故障預(yù)案在真實(shí)故障發(fā)生時(shí)大概率是不好用的。原因很簡(jiǎn)單預(yù)案是“寫(xiě)出來(lái)的想象”而真實(shí)故障充滿了意外——網(wǎng)絡(luò)分區(qū)、磁盤(pán)慢IO、內(nèi)存泄漏、證書(shū)過(guò)期——每一種故障都不會(huì)按照你寫(xiě)的預(yù)案發(fā)生。所以高可用體系的第七大策略就是“平時(shí)多流汗戰(zhàn)時(shí)少流血”。通過(guò)主動(dòng)制造故障、演練整個(gè)團(tuán)隊(duì)的處理流程你會(huì)發(fā)現(xiàn)很多平時(shí)根本注意不到的坑。7.2 混沌工程實(shí)操?gòu)摹皻⒁粋€(gè)Pod”開(kāi)始混沌工程聽(tīng)起來(lái)高大上實(shí)際可以從小處著手。我建議剛接觸混沌工程的團(tuán)隊(duì)從Kubernetes環(huán)境里的基礎(chǔ)故障注入開(kāi)始。最基礎(chǔ)的一步手動(dòng)殺一個(gè)Pod驗(yàn)證自愈能力。# 刪除一個(gè)業(yè)務(wù)Pod觀察Kubernetes是否自動(dòng)重建 kubectl delete pod order-service-xxxxx正常情況下Deployment控制器會(huì)在幾秒內(nèi)拉起一個(gè)新Pod。在這個(gè)演練中你需要觀察的第一件事是整個(gè)過(guò)程中服務(wù)是否持續(xù)可用如果服務(wù)有多個(gè)副本且負(fù)載均衡工作正常用戶應(yīng)該無(wú)感知。如果發(fā)現(xiàn)某個(gè)副本被殺后開(kāi)始出現(xiàn)請(qǐng)求失敗說(shuō)明你的負(fù)載均衡配置或者Pod優(yōu)雅終止設(shè)置有問(wèn)題需要立刻修復(fù)。再進(jìn)一步引入Chaos Mesh或者Litmus這類(lèi)工具做自動(dòng)化故障注入。Chaos Mesh是CNCF項(xiàng)目支持Pod故障、網(wǎng)絡(luò)延遲、網(wǎng)絡(luò)丟包、磁盤(pán)故障等多種注入場(chǎng)景。配置一個(gè)網(wǎng)絡(luò)延遲的例子apiVersion: chaos-mesh.org/v1alpha1 kind: NetworkChaos metadata: name: delay-order-service spec: action: delay mode: one selector: namespaces: - production labelSelectors: app: order-service delay: latency: 2000ms jitter: 500ms duration: 5m這個(gè)配置會(huì)讓order-service的請(qǐng)求延遲2秒持續(xù)5分鐘模擬網(wǎng)絡(luò)抖動(dòng)的場(chǎng)景。注入之后重點(diǎn)觀察下游調(diào)用方是否觸發(fā)了超時(shí)重試、熔斷降級(jí)以及系統(tǒng)從故障中恢復(fù)的速度。7.3 故障演練的“度”與實(shí)施節(jié)奏混沌工程要講分寸別一上來(lái)就把生產(chǎn)環(huán)境搞崩。我建議節(jié)奏是這樣的先在測(cè)試環(huán)境驗(yàn)證所有故障注入工具和用例先在低峰期做演練確認(rèn)無(wú)誤后再嘗試高峰期演練從影響面小的場(chǎng)景開(kāi)始如殺一個(gè)Pod逐步升級(jí)到網(wǎng)絡(luò)隔離、節(jié)點(diǎn)宕機(jī)等大故障每次演練前必須有明確的回滾方案演練過(guò)程中如果發(fā)現(xiàn)無(wú)法控制立即終止有人會(huì)擔(dān)心混沌工程會(huì)不會(huì)“沒(méi)病找病”我的理解是如果你不主動(dòng)找病病就會(huì)在你最忙的時(shí)候找上你。與其在業(yè)務(wù)大促當(dāng)天被動(dòng)遭遇故障不如在一個(gè)可控的時(shí)間點(diǎn)主動(dòng)暴露問(wèn)題、修復(fù)問(wèn)題。8. 復(fù)盤(pán)機(jī)制與持續(xù)改進(jìn)讓每一次故障都成為系統(tǒng)進(jìn)化的契機(jī)8.1 復(fù)盤(pán)的目的是“改進(jìn)系統(tǒng)”不是“追責(zé)個(gè)人”故障復(fù)盤(pán)在很多團(tuán)隊(duì)里變了味變成了“誰(shuí)的問(wèn)題、誰(shuí)背鍋、誰(shuí)寫(xiě)檢查”。這種文化下沒(méi)有人愿意如實(shí)上報(bào)故障細(xì)節(jié)隱藏的問(wèn)題越來(lái)越多系統(tǒng)就越發(fā)脆。高效的運(yùn)維團(tuán)隊(duì)復(fù)盤(pán)文化一定是“對(duì)事不對(duì)人”的。我在團(tuán)隊(duì)里推行復(fù)盤(pán)時(shí)會(huì)強(qiáng)調(diào)一個(gè)原則如果一個(gè)故障是因?yàn)槿说氖韬鰧?dǎo)致的那一定是流程或工具讓人覺(jué)得“疏忽也沒(méi)關(guān)系”。所以復(fù)盤(pán)的關(guān)注點(diǎn)不是某個(gè)人做錯(cuò)了什么而是系統(tǒng)在哪一環(huán)缺失了防護(hù)流程在哪一步缺了檢查。8.2 一份實(shí)用的復(fù)盤(pán)報(bào)告模板復(fù)盤(pán)報(bào)告不用寫(xiě)得很長(zhǎng)但要覆蓋核心要素。我常用的模板結(jié)構(gòu)是這樣的模塊關(guān)鍵內(nèi)容故障時(shí)間線從故障發(fā)生到恢復(fù)的完整時(shí)間線精確到分鐘影響范圍哪些服務(wù)、哪些用戶、持續(xù)多久、有沒(méi)有數(shù)據(jù)丟失根因分析用5Why法或FTA法找出真正的根因不止停留在直接原因觸發(fā)條件什么條件下會(huì)觸發(fā)是否有前兆信號(hào)修復(fù)動(dòng)作短期止血措施和長(zhǎng)期修復(fù)措施分開(kāi)列行動(dòng)清單每項(xiàng)措施指定責(zé)任人、截止日期、驗(yàn)收標(biāo)準(zhǔn)這里尤其想講講5Why法。比如故障表面原因是“磁盤(pán)滿了”繼續(xù)問(wèn)為什么磁盤(pán)滿了——因?yàn)槿罩疚募鬄槭裁慈罩疚募蟆驗(yàn)闆](méi)有日志輪轉(zhuǎn)策略為什么沒(méi)有日志輪轉(zhuǎn)策略——因?yàn)椴渴饡r(shí)沒(méi)有把日志輪轉(zhuǎn)納入標(biāo)準(zhǔn)化配置。這樣追問(wèn)五層才能真正觸及需要改的根子。8.3 復(fù)盤(pán)后的“閉環(huán)動(dòng)作”復(fù)盤(pán)的最終價(jià)值體現(xiàn)在行動(dòng)上。每一次復(fù)盤(pán)結(jié)束后我會(huì)要求團(tuán)隊(duì)輸出一個(gè)“穩(wěn)定性改進(jìn)項(xiàng)清單”并且把它納入下一迭代的開(kāi)發(fā)計(jì)劃。沒(méi)有行動(dòng)的復(fù)盤(pán)等于白做。舉一個(gè)我們自己的例子某次故障是因?yàn)橐粋€(gè)Redis實(shí)例內(nèi)存滿了導(dǎo)致緩存失效流量全部打到數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)負(fù)載過(guò)高。復(fù)盤(pán)后我們落地了三個(gè)改進(jìn)項(xiàng)一是給Redis加告警內(nèi)存使用率超過(guò)80%就觸發(fā)二是給數(shù)據(jù)庫(kù)連接池配置了最大等待時(shí)間和快速失敗機(jī)制三是為緩存增加多級(jí)降級(jí)方案Redis不可用時(shí)可以降級(jí)到本地緩存。三個(gè)改進(jìn)項(xiàng)在一周內(nèi)完成開(kāi)發(fā)上線之后同類(lèi)故障再也沒(méi)有復(fù)發(fā)過(guò)。9. 最后分享一點(diǎn)個(gè)人體會(huì)高可用系統(tǒng)的建設(shè)不是“項(xiàng)目制”不能指望等架構(gòu)師畫(huà)完圖、運(yùn)維部署完工具系統(tǒng)就自動(dòng)高可用了。它更像是一種持續(xù)運(yùn)作的機(jī)制監(jiān)控發(fā)現(xiàn)薄弱點(diǎn)→容量和架構(gòu)補(bǔ)強(qiáng)→發(fā)布流程防患→數(shù)據(jù)備份兜底→演練驗(yàn)證效果→復(fù)盤(pán)沉淀經(jīng)驗(yàn)→再發(fā)現(xiàn)新的薄弱點(diǎn)。這七個(gè)策略不是獨(dú)立的銀彈而是互相咬合的齒輪只有一起轉(zhuǎn)起來(lái)系統(tǒng)的穩(wěn)定性才會(huì)穩(wěn)步提升。在這個(gè)行業(yè)里待得越久我越覺(jué)得運(yùn)維的成就感不是“處理了多少故障”而是“系統(tǒng)平靜得有點(diǎn)無(wú)聊”——一切自動(dòng)化在穩(wěn)穩(wěn)運(yùn)行監(jiān)控大屏一片綠色用戶無(wú)感、業(yè)務(wù)正常。這種“無(wú)聊”才是高效運(yùn)維真正該追求的狀態(tài)。希望這篇文章對(duì)你有所啟發(fā)也歡迎在評(píng)論區(qū)聊聊你在高可用建設(shè)中踩過(guò)的坑。