1. rea 是什么從一次擴(kuò)容翻車聊起如果你刷到標(biāo)題里孤零零的 rea 一頭霧水太正常了。它不是某個(gè)熱門開源框架的名字也不是大廠產(chǎn)品線的代號(hào)而是我給自己折騰的一套內(nèi)部小工具起的代號(hào)。要講清楚 rea 到底解決了什么問題得從一次讓我印象深刻的擴(kuò)容翻車說起。當(dāng)時(shí)團(tuán)隊(duì)有個(gè)核心服務(wù)大促前按老規(guī)矩做容量評(píng)估拉一下監(jiān)控面板的峰值 CPU再乘以一個(gè)業(yè)務(wù)側(cè)的預(yù)估流量增長倍數(shù)就這么把擴(kuò)容申請(qǐng)交上去了。結(jié)果大促當(dāng)天服務(wù) CPU 一路沖到 95%接口超時(shí)一片用戶側(cè)體驗(yàn)直接崩了。事后復(fù)盤發(fā)現(xiàn)估算值和真實(shí)需求差了快一倍。問題不是哪個(gè)人不細(xì)心而是整個(gè)評(píng)估鏈條全憑手工拍腦袋資源數(shù)據(jù)散落在不同的監(jiān)控面板里業(yè)務(wù)預(yù)估、歷史趨勢(shì)、安全余量各算各的根本沒有一套統(tǒng)一口徑。那次復(fù)盤之后我沒有急著去申請(qǐng)更多機(jī)器而是決定做個(gè)工具把資源到底夠不夠、什么時(shí)候會(huì)不夠、要提前多久擴(kuò)容這三件事用數(shù)據(jù)而不是感覺來回答。這就是 rea 的起點(diǎn)。rea 的全稱是 Resource Estimation Assistant資源估算助手定位非常聚焦輸入服務(wù)的歷史監(jiān)控?cái)?shù)據(jù)輸出未來一段時(shí)間的內(nèi)存、CPU、磁盤水位預(yù)測(cè)并給出擴(kuò)容建議。誰適合參考這套東西后端、運(yùn)維、全棧以及任何被容量評(píng)估折磨過的開發(fā)。我后面會(huì)把我踩過的坑、手寫的估算邏輯、還有上線半年才悟出來的那些細(xì)節(jié)全部攤開講你可以直接把這套思路搬回自己的團(tuán)隊(duì)。1.1 那次復(fù)盤里暴露的四個(gè)真問題先說痛點(diǎn)否則你看后面的方案會(huì)不明白我為什么要這么設(shè)計(jì)。那次復(fù)盤整理下來團(tuán)隊(duì)容量評(píng)估的毛病集中在四個(gè)方面數(shù)據(jù)割裂。CPU、內(nèi)存、磁盤分別在三個(gè)不同的監(jiān)控系統(tǒng)里導(dǎo)出格式還不一樣合并全靠人工復(fù)制粘貼到 Excel?？趶讲唤y(tǒng)一。業(yè)務(wù)側(cè)說的流量翻倍和運(yùn)維側(cè)理解的流量翻倍根本不是一回事前者是 QPS 翻倍后者以為帶寬翻倍算出來的資源需求能差出兩三倍。經(jīng)驗(yàn)留不住。團(tuán)隊(duì)里能估算得比較準(zhǔn)的只有一兩個(gè)老同學(xué)他們的判斷依據(jù)是長期感覺沒有文檔、沒有公式、沒有沉淀人一休假評(píng)估就癱瘓。沒有回看機(jī)制。每次擴(kuò)容完了就算完了沒有人把預(yù)測(cè)值和實(shí)際值做對(duì)比錯(cuò)了也不知道錯(cuò)在哪下次接著錯(cuò)。這四條任何一條單拎出來都不致命但湊在一起容量評(píng)估就成了一個(gè)靠運(yùn)氣撐著的環(huán)節(jié)。rea 的設(shè)計(jì)目標(biāo)很簡單把估算這件事從經(jīng)驗(yàn)驅(qū)動(dòng)變成數(shù)據(jù)驅(qū)動(dòng)哪怕一個(gè)剛?cè)肼毜男峦瑢W(xué)只要會(huì)看圖表也能在五分鐘內(nèi)判斷某個(gè)服務(wù)是否需要擴(kuò)容。1.2 rea 的定位與能力邊界做工具最容易犯的毛病是貪大。我一開始也想過要不要把監(jiān)控采集、告警、自動(dòng)擴(kuò)縮容全做進(jìn)去做一個(gè)容量管理全家桶。后來我強(qiáng)行給自己畫了條邊界rea 只做預(yù)測(cè)和輔助決策不做自動(dòng)化執(zhí)行。為什么不碰自動(dòng)擴(kuò)縮容因?yàn)橘Y源伸縮牽涉到審批、預(yù)算、服務(wù)規(guī)格、流量切換一堆事情自動(dòng)化擴(kuò)錯(cuò)了容比不擴(kuò)還可怕。rea 的價(jià)值是當(dāng)那個(gè)提前預(yù)警的參謀告訴你哪臺(tái)服務(wù)在什么時(shí)間點(diǎn)會(huì)碰到水位線需要提前準(zhǔn)備什么規(guī)格的資源。真正的擴(kuò)容動(dòng)作依然保留人工審批環(huán)節(jié)。這個(gè)邊界劃清楚之后整個(gè)項(xiàng)目的復(fù)雜度降了一半都不止。rea 的輸入輸出也因此在第一天就定死了輸入是服務(wù)的歷史指標(biāo)序列輸出是未來 7/30/90 天的水位預(yù)測(cè)、風(fēng)險(xiǎn)標(biāo)記和擴(kuò)容建議。不做實(shí)時(shí)告警因?yàn)閷?shí)時(shí)告警是監(jiān)控系統(tǒng)的事不做自動(dòng)擴(kuò)縮容因?yàn)槟鞘菆?zhí)行系統(tǒng)的事只負(fù)責(zé)把什么時(shí)候會(huì)不夠這件事算準(zhǔn)這就夠了。1.3 技術(shù)選型為什么是 React Node 輕量存儲(chǔ)技術(shù)棧選擇上我?guī)缀鯖]有猶豫。前端選了 React 加 ECharts因?yàn)閳F(tuán)隊(duì)現(xiàn)有后臺(tái)基本都是這個(gè)組合新成員上手成本最低后端用 Node.js 加 Express原因是采集腳本要復(fù)用公司現(xiàn)有的 Node 工具鏈存儲(chǔ)用的是 SQLite加上定時(shí)聚合邏輯。這里可能有同學(xué)會(huì)問資源預(yù)測(cè)按理說數(shù)據(jù)量不小用 SQLite 夠嗎我的答案是分階段看。rea 初期只管理幾十個(gè)服務(wù)每個(gè)服務(wù)每 5 分鐘一個(gè)采樣點(diǎn)一天也就幾千條記錄SQLite 完全扛得住。等真到了每天幾百萬條數(shù)據(jù)的規(guī)模再遷移到時(shí)序數(shù)據(jù)庫也不遲。為了一個(gè)還沒影的規(guī)模提前引入一套重量級(jí)時(shí)序存儲(chǔ)只會(huì)讓項(xiàng)目在第一周就死在部署復(fù)雜度上。存儲(chǔ)方案優(yōu)勢(shì)代價(jià)完整時(shí)序數(shù)據(jù)庫查詢能力強(qiáng)生態(tài)完善多維護(hù)一套組件部署復(fù)雜SQLite 定時(shí)聚合零新增依賴隨項(xiàng)目走數(shù)據(jù)量大后需要定期清理純內(nèi)存數(shù)組實(shí)現(xiàn)最簡單重啟丟數(shù)據(jù)不適合長期積累最終選了 SQLite。后面的事實(shí)證明這個(gè)決定很務(wù)實(shí)項(xiàng)目三天下地一周接入第一批服務(wù)沒有一次因?yàn)榇鎯?chǔ)出過問題。2. 資源估算的核心指標(biāo)、公式與數(shù)據(jù)準(zhǔn)備很多類似的工具做到最后效果不好問題往往不出在模型上而出在最基礎(chǔ)的兩件事指標(biāo)沒選對(duì)數(shù)據(jù)是臟的。所以我把這一章放在模型前面先把這些基礎(chǔ)講透。2.1 先分清楚直接指標(biāo)和派生指標(biāo)資源估算要先明確一個(gè)問題你預(yù)測(cè)的到底是什么。我習(xí)慣把指標(biāo)分成兩類。直接指標(biāo)就是資源本身的使用量比如 CPU 使用率、內(nèi)存使用率、磁盤已用空間、網(wǎng)絡(luò)流量。這類指標(biāo)直接從系統(tǒng)層拿到是所有預(yù)測(cè)的基礎(chǔ)。派生指標(biāo)則是業(yè)務(wù)層面的信號(hào)比如 QPS每秒請(qǐng)求數(shù)、平均響應(yīng)時(shí)間、GC 頻率、連接數(shù)。這類指標(biāo)不直接對(duì)應(yīng)資源消耗但它能幫你解釋資源曲線為什么長這樣。比如某服務(wù)的 CPU 在每天下午三點(diǎn)準(zhǔn)時(shí)爬升只看資源曲線可能以為是異常結(jié)合 QPS 一看才發(fā)現(xiàn)是那個(gè)時(shí)段業(yè)務(wù)集中請(qǐng)求導(dǎo)致一切正常。rea 在采集層兩類指標(biāo)都收但估算模型只用直接指標(biāo)派生指標(biāo)只用來做變化歸因。這樣做的好處是模型簡單可靠不會(huì)被業(yè)務(wù)邏輯的復(fù)雜性拖垮。采集頻率統(tǒng)一設(shè)成 5 分鐘一個(gè)點(diǎn)這個(gè)粒度對(duì)容量預(yù)測(cè)來說足夠了再密除了浪費(fèi)存儲(chǔ)沒有太多意義。2.2 估算公式趨勢(shì) 季節(jié) 安全系數(shù)容量預(yù)測(cè)的模型沒有你想的那么玄。rea 用的核心公式是預(yù)測(cè)值 趨勢(shì)基準(zhǔn)值 × 季節(jié)性系數(shù) × 安全系數(shù)為什么不能只做一條簡單的線性回歸因?yàn)榉?wù)資源使用有非常明顯的周期性。同一個(gè)服務(wù)工作日白天和凌晨的 CPU 能差出一倍周一往往比周三高月底還有例行任務(wù)疊加。如果不把這些季節(jié)性因素拆出來預(yù)測(cè)值要么在高峰期不夠用要么在低峰期過度分配。趨勢(shì)基準(zhǔn)值我用的是最小二乘法擬合出的線性趨勢(shì)。這里有個(gè)很直觀的處理方式把過去 90 天的指標(biāo)按時(shí)間順序排好算出每天的日均值然后擬合一條直線延長到未來。舉個(gè)例子某服務(wù)過去 30 天的 CPU 日均值是 45%通過擬合發(fā)現(xiàn)每 7 天大約上漲 3%那 30 天后的趨勢(shì)基準(zhǔn)值就是 45% 乘以 1.03 的 4 次方約等于 50.6%。季節(jié)性系數(shù)怎么算把歷史數(shù)據(jù)按星期幾 小時(shí)分桶比如周一 15:00這個(gè)桶把過去所有這個(gè)時(shí)間點(diǎn)的 CPU 值取中位數(shù)再除以全局中位數(shù)得到一個(gè)系數(shù)。高峰期這個(gè)系數(shù)可能是 1.3凌晨低谷可能是 0.6。預(yù)測(cè)時(shí)先算趨勢(shì)值再乘上對(duì)應(yīng)時(shí)間桶的季節(jié)性系數(shù)就能得到跟隨業(yè)務(wù)節(jié)奏起伏的預(yù)測(cè)曲線。最后乘安全系數(shù)。我默認(rèn)設(shè) 1.2也就是在預(yù)測(cè)值上再留 20% 的余量。這樣算下來剛才那個(gè)例子30 天后 CPU 預(yù)測(cè)值大約 60.7%仍然低于 80% 的警戒水位線結(jié)論是暫不需要擴(kuò)容但需要持續(xù)觀察。磁盤的估算方法和 CPU 不太一樣。磁盤關(guān)注的是什么時(shí)候會(huì)滿我直接算兩個(gè)數(shù)當(dāng)前可用量除以日均增長量得到預(yù)計(jì)耗盡天數(shù)再算未來 N 天后的剩余空間。舉個(gè)例子某服務(wù)磁盤可用量 150GB過去 30 天的日均增長是 2GB那預(yù)計(jì)耗盡天數(shù)就是 75 天。如果這個(gè)數(shù)字小于 45 天rea 就會(huì)標(biāo)記風(fēng)險(xiǎn)提醒準(zhǔn)備加盤。45 天這個(gè)閾值是基于擴(kuò)容準(zhǔn)備周期反推的從申請(qǐng)資源到審批、采購、切換上線一般需要 7 到 10 天我留出至少五倍的時(shí)間余量應(yīng)對(duì)突發(fā)增長。2.3 數(shù)據(jù)清洗決定模型上限的關(guān)鍵模型再強(qiáng)喂進(jìn)來的數(shù)據(jù)是臟的輸出就是垃圾。這是 rea 開發(fā)過程中我感受最深的一句話。容量預(yù)測(cè)的數(shù)據(jù)清洗我總結(jié)了三條經(jīng)驗(yàn)。第一條發(fā)布和重啟造成的空洞不能隨便填值。服務(wù)發(fā)布期間會(huì)有一段時(shí)間沒有采集數(shù)據(jù)或者 CPU 短暫飆高然后回落到新水平。這種數(shù)據(jù)如果直接參與擬合會(huì)把趨勢(shì)線帶偏。rea 的做法是標(biāo)記空窗期訓(xùn)練時(shí)直接跳過不插值。第二條聚合統(tǒng)計(jì)用 P95 而不是平均值更不是最大值。平均值會(huì)被每天凌晨的低谷拖低算出來的容量永遠(yuǎn)不夠用最大值又會(huì)被偶發(fā)的瞬時(shí)抖動(dòng)拉高導(dǎo)致過度分配。P95 的意思是95% 的時(shí)間都不超過這個(gè)值這對(duì)容量規(guī)劃來說是最貼合實(shí)際的度量。用生活化的話說你不是關(guān)心全班平均分而是關(guān)心大多數(shù)同學(xué)是不是都能及格P95 就是那個(gè)大多數(shù)同學(xué)的真實(shí)水平。第三條固定的批處理窗口要單獨(dú)處理。很多服務(wù)有每天零點(diǎn)跑批的習(xí)慣那一個(gè)小時(shí)的 CPU 會(huì)異常地高但它不代表常態(tài)。rea 在數(shù)據(jù)采集階段會(huì)打業(yè)務(wù)標(biāo)簽凡是落在固定批處理窗口內(nèi)的數(shù)據(jù)要么排除要么單獨(dú)建一個(gè)批處理畫像模型。剛開始我沒做這一步結(jié)果 0 點(diǎn)整的 CPU 尖峰每次都把預(yù)測(cè)值抬高一大截后來才通過這個(gè)辦法解決。2.4 訓(xùn)練窗口怎么選訓(xùn)練窗口長短直接影響預(yù)測(cè)的穩(wěn)定性和及時(shí)性。窗口太短模型對(duì)近期波動(dòng)過于敏感預(yù)測(cè)值忽高忽低窗口太長模型又跟不上業(yè)務(wù)變化上次發(fā)版優(yōu)化了性能舊數(shù)據(jù)還在拖后腿。rea 的默認(rèn)配置是 90 天訓(xùn)練窗口。90 天能覆蓋完整的星期周期性也能提供足夠的數(shù)據(jù)量做季節(jié)系數(shù)。如果某個(gè)服務(wù)版本迭代特別快一周發(fā)兩三次版我會(huì)手動(dòng)把它降到 30 天如果有年度周期性的業(yè)務(wù)比如電商大促就用 365 天窗口做專項(xiàng)分析。這個(gè)配置寫在一個(gè)配置文件里不用改代碼。3. 從零實(shí)現(xiàn) rea架構(gòu)、代碼與接入這里我把 rea 在實(shí)現(xiàn)層面的核心細(xì)節(jié)展開講。項(xiàng)目規(guī)模不大但每一塊都有值得說一說的地方。3.1 項(xiàng)目結(jié)構(gòu)設(shè)計(jì)整套代碼分服務(wù)端、前端、部署三塊。目錄結(jié)構(gòu)是這樣的rea/ ├── server/ │ ├── index.js # Express 入口 │ ├── collector.js # 數(shù)據(jù)采集調(diào)度 │ ├── estimators/ │ │ ├── trend.js # 趨勢(shì)擬合 │ │ ├── seasonal.js # 季節(jié)性系數(shù) │ │ └── disk.js # 磁盤耗盡預(yù)測(cè) │ └── db/ │ ├── schema.sql # 表結(jié)構(gòu) │ └── index.js # SQLite 封裝 ├── web/ │ ├── src/ │ │ ├── pages/Dashboard.jsx │ │ └── components/CapacityChart.jsx │ └── package.json ├── collector.conf.json # 采集任務(wù)配置 └── docker-compose.yml模塊拆分的邏輯很簡單collector 負(fù)責(zé)把指標(biāo)寫進(jìn) SQLiteestimators 負(fù)責(zé)算web 負(fù)責(zé)展示。三個(gè)模塊之間只通過數(shù)據(jù)庫和 HTTP 接口通信互不依賴后面哪塊要重寫都不影響其他兩塊。3.2 后端估算核心實(shí)現(xiàn)趨勢(shì)擬合我選擇了手寫最小二乘法。為什么不用統(tǒng)計(jì)庫因?yàn)檫@套計(jì)算只有一個(gè)公式為此引入一個(gè)幾 MB 的依賴庫完全不劃算手寫 20 行代碼人人都看得懂、改得動(dòng)。核心實(shí)現(xiàn)是這樣的// estimators/trend.js function leastSquares(points) { const n points.length; if (n 2) return null; let sumX 0, sumY 0, sumXY 0, sumXX 0; for (let i 0; i n; i) { sumX points[i].x; sumY points[i].y; sumXY points[i].x * points[i].y; sumXX points[i].x * points[i].x; } const slope (n * sumXY - sumX * sumY) / (n * sumXX - sumX * sumX); const intercept (sumY - slope * sumX) / n; return { slope, intercept }; }這個(gè)函數(shù)輸入是[{ x: 天數(shù)序號(hào), y: 日均值 }]輸出是斜率和截距。有了這兩個(gè)值任意一天的趨勢(shì)基準(zhǔn)值就是y slope * x intercept。季節(jié)性系數(shù)的實(shí)現(xiàn)也不復(fù)雜。按星期幾 小時(shí)做分桶每個(gè)桶取中位數(shù)// estimators/seasonal.js function computeSeasonalFactors(history) { const buckets new Map(); for (const point of history) { const key ${point.weekday}:${point.hour}; if (!buckets.has(key)) buckets.set(key, []); buckets.get(key).push(point.value); } const globalMedian median(history.map(p p.value)); const factors {}; for (const [key, values] of buckets) { factors[key] median(values) / globalMedian; } return factors; }預(yù)測(cè)主流程就是把這兩塊串起來再乘上安全系數(shù)。需要注意的細(xì)節(jié)是歷史序列和未來預(yù)測(cè)之間隔著訓(xùn)練窗口的長度趨勢(shì)線要延展這段距離不能直接從最后一天起跳。這個(gè)小坑我在第一版就踩過預(yù)測(cè)曲線整體比實(shí)際低了一截。3.3 前端儀表盤一張圖說清楚現(xiàn)狀與未來前端我只做了一個(gè)頁面核心是一個(gè)趨勢(shì)圖。用 ECharts 渲染三條信息歷史水位線、預(yù)測(cè)水位線、80% 閾值線。用戶通過下拉框選服務(wù)通過按鈕切換 7/30/90 天預(yù)測(cè)周期。// web/src/components/CapacityChart.jsx import React, { useEffect, useState } from react; import ReactECharts from echarts-for-react; export default function CapacityChart({ service, range }) { const [data, setData] useState(null); useEffect(() { fetch(/api/forecast/${service}?days${range}) .then(res res.json()) .then(setData); }, [service, range]); const option { xAxis: { type: time }, yAxis: { type: value, min: 0, max: 120 }, series: [ { name: 歷史水位, type: line, data: data?.history, smooth: true }, { name: 預(yù)測(cè)水位, type: line, data: data?.forecast, lineStyle: { type: dashed } }, { name: 閾值, type: line, markLine: { data: [{ yAxis: 80 }] } } ] }; return ReactECharts option{option} style{{ height: 360 }} /; }這個(gè)組件有一個(gè)容易忽略的優(yōu)化點(diǎn)切換服務(wù)和周期時(shí)如果每次都重新拉數(shù)據(jù)并重繪整個(gè)圖表會(huì)有明顯的閃爍感。我在實(shí)際項(xiàng)目里加了一個(gè)很簡單的緩存預(yù)測(cè)結(jié)果按服務(wù) 周期存進(jìn)內(nèi)存 Map切換回來時(shí)直接讀緩存體驗(yàn)立刻順滑了很多。圖表上還要把風(fēng)險(xiǎn)狀態(tài)用顏色區(qū)分出來。我的做法是預(yù)測(cè)曲線在某個(gè)時(shí)間點(diǎn)超過 80% 閾值的部分用紅色顯示低于閾值的部分保持綠色。這樣一張圖掃過去哪些服務(wù)在未來一個(gè)月會(huì)亮紅燈一目了然。3.4 接入一個(gè)新服務(wù)的四步走工具做得再好接入流程太麻煩就沒人愿意用。rea 針對(duì)新服務(wù)接入設(shè)計(jì)了一套標(biāo)準(zhǔn)化流程全程不需要寫代碼只改配置。第一步創(chuàng)建服務(wù)檔案。在配置表里登記服務(wù)名、所屬團(tuán)隊(duì)、負(fù)責(zé)人、當(dāng)前資源規(guī)格。服務(wù)名必須和監(jiān)控系統(tǒng)里的名字完全一致這一條看似簡單實(shí)際是個(gè)大坑后面我會(huì)專門講。第二步配置指標(biāo)來源。rea 的采集器支持兩種模式拉取模式是從公司已有的監(jiān)控平臺(tái)按 API 拉數(shù)據(jù)推送模式是服務(wù)側(cè)腳本主動(dòng)把指標(biāo) POST 到 rea 的采集接口。對(duì)大多數(shù)服務(wù)直接用拉取模式就行。第三步校準(zhǔn)基線。新服務(wù)接入后先跑 7 天這期間 rea 只記錄數(shù)據(jù)、不輸出預(yù)測(cè)結(jié)論。7 天后人工把 rea 的預(yù)測(cè)和實(shí)際情況做一次對(duì)比確認(rèn)沒有明顯偏差再放行。第四步回測(cè)驗(yàn)證。我用 MAPE也就是平均絕對(duì)百分比誤差來衡量預(yù)測(cè)準(zhǔn)不準(zhǔn)。公式是MAPE (1 / n) × Σ |實(shí)際值 - 預(yù)測(cè)值| / 實(shí)際值舉個(gè)例子某服務(wù)過去 7 天的實(shí)際 CPU 是 50、52、51、55、60、58、62預(yù)測(cè)值是 47、50、54、53、58、61、60。逐點(diǎn)算絕對(duì)誤差再除以實(shí)際值最后平均得到 MAPE 約 4.4%。rea 的驗(yàn)收標(biāo)準(zhǔn)是 MAPE 小于 15%超過這個(gè)值就說明數(shù)據(jù)或模型哪里有問題需要排查。3.5 部署與日常運(yùn)行部署我用了 Docker Compose一條命令起來整個(gè)服務(wù)。采集器通過 node-cron 每 5 分鐘觸發(fā)一次每次拉取所有服務(wù)最近 5 分鐘的指標(biāo)寫入 SQLite。version: 3 services: rea-server: build: ./server ports: - 8080:8080 volumes: - ./data:/app/data restart: unless-stopped rea-web: build: ./web ports: - 3000:3000 environment: - API_BASEhttp://rea-server:8080 depends_on: - rea-server運(yùn)行期間自動(dòng)維護(hù)就這么幾件事每天凌晨清理超過 400 天的歷史明細(xì)數(shù)據(jù)只保留聚合結(jié)果每周一自動(dòng)生成一份下周水位周報(bào)推送到工作群每次預(yù)測(cè)任務(wù)結(jié)束后把結(jié)果寫入預(yù)測(cè)記錄表方便以后回看。整套系統(tǒng)跑起來之后日常需要人工介入的頻率基本降到了每周一次看周報(bào)。4. 上線半年踩過的坑與排查實(shí)錄工具上線只是開始真正讓人成長的是上線之后的那些故障和誤報(bào)。這一章我把實(shí)際運(yùn)維中踩過的典型坑整理出來每一個(gè)都配有現(xiàn)象、原因和解決辦法。4.1 幽靈峰值模型被假數(shù)據(jù)帶偏rea 上線第二周就有個(gè)服務(wù)連續(xù)三天被標(biāo)記為高風(fēng)險(xiǎn)但運(yùn)維同學(xué)去查發(fā)現(xiàn)服務(wù)實(shí)際毫無壓力。排查后發(fā)現(xiàn)那三天每天零點(diǎn)到一點(diǎn)CPU 都會(huì)有一個(gè)很高的尖峰拉高了一整天的均值。原因是一個(gè)定時(shí)清理腳本每天零點(diǎn)準(zhǔn)時(shí)啟動(dòng)雖然是批處理卻短時(shí)間吃掉了大量 CPU。這類數(shù)據(jù)我稱之為幽靈峰值真實(shí)存在、但不是常態(tài)、卻會(huì)污染趨勢(shì)計(jì)算。處理辦法有兩種要么在采集時(shí)打批處理標(biāo)簽然后排除要么把這些周期性任務(wù)單獨(dú)建檔用它們自己的歷史數(shù)據(jù)做預(yù)測(cè)不混進(jìn)業(yè)務(wù)主指標(biāo)。我之前說的批處理畫像模型就是給這類場(chǎng)景留的口子。同樣的道理也適用于探針重啟和發(fā)布造成的空洞。這些數(shù)據(jù)點(diǎn)有一個(gè)共同特點(diǎn)它們代表的不是服務(wù)的正常運(yùn)行狀態(tài)。rea 在數(shù)據(jù)入庫前加了一道校驗(yàn)凡是被標(biāo)記為空窗、批處理、發(fā)布窗口內(nèi)的記錄都默認(rèn)不參與模型訓(xùn)練只有業(yè)務(wù)常態(tài)數(shù)據(jù)才進(jìn)訓(xùn)練集。4.2 發(fā)版導(dǎo)致趨勢(shì)突變舊數(shù)據(jù)一夜之間過時(shí)這是容量預(yù)測(cè)最大的敵人沒有之一。某服務(wù)做了一次代碼優(yōu)化平均 CPU 從 70% 直接降到 35%。按 rea 原來的邏輯訓(xùn)練窗口是 90 天那 90 天里有大半的數(shù)據(jù)是優(yōu)化前的預(yù)測(cè)值會(huì)明顯偏高導(dǎo)致系統(tǒng)持續(xù)誤報(bào)需要擴(kuò)容。解決這個(gè)問題不能靠手工刪數(shù)據(jù)因?yàn)榘l(fā)版太頻繁每次都手動(dòng)處理根本維護(hù)不過來。我在 rea 里加了一個(gè)突變檢測(cè)計(jì)算最近 7 天日均值和前 30 天日均值如果變化幅度超過 30%就判定發(fā)生了趨勢(shì)突變。一旦判定突變訓(xùn)練窗口自動(dòng)縮短到 7 天并在服務(wù)檔案里打上數(shù)據(jù)已重置的標(biāo)記提醒使用者在下次大促評(píng)估時(shí)手動(dòng)確認(rèn)一次業(yè)務(wù)基線。這個(gè)邏輯我用的是一個(gè)簡化版的閾值法沒有用復(fù)雜的 CUSUM 算法。對(duì)內(nèi)部工具來說可解釋性比算法復(fù)雜度重要得多。運(yùn)營的同學(xué)能看懂因?yàn)樽罱?7 天變化超過 30%所以窗口重置了這樣的邏輯但對(duì)CUSUM 檢測(cè)到均值漂移這種說法大概率只能點(diǎn)頭表示聽不懂。4.3 誤報(bào)與告警疲勞水位超過 80% 就告警這個(gè)規(guī)則看上去沒問題上線后卻發(fā)現(xiàn)告警頻率高到大家直接無視。為什么因?yàn)檎鎸?shí)世界里短時(shí)間沖高 80% 這種情況太多了大促流量波峰、定時(shí)任務(wù)并發(fā)、其他服務(wù)搶占資源都會(huì)造成瞬時(shí)超線。我現(xiàn)在把告警邏輯改成了兩條更嚴(yán)格的規(guī)則連續(xù)三個(gè)采樣點(diǎn)超過 80% 才告警或者預(yù)測(cè)未來 7 天內(nèi)任意時(shí)段超過 85% 才告警。這兩條規(guī)則一改誤報(bào)率降了八成大家對(duì)告警的信任度也回來了。這里有個(gè)經(jīng)驗(yàn)想提醒你做容量工具寧可漏報(bào)也不要錯(cuò)報(bào)。錯(cuò)報(bào)一次用戶就不再相信工具漏報(bào)一次最多被吐槽一句后面用更長窗口的數(shù)據(jù)補(bǔ)回來就行。工具的可信度建立起來很難毀掉只需要一次。4.4 常見問題速查表現(xiàn)象可能原因處理辦法預(yù)測(cè)值忽高忽低訓(xùn)練窗口太短、異常數(shù)據(jù)多窗口調(diào)到 90 天聚合改用 P95磁盤預(yù)測(cè)總是偏大日志清理任務(wù)被計(jì)入增長量排除清理類任務(wù)的數(shù)據(jù)按周平滑前端圖表空白服務(wù)名不一致或數(shù)據(jù)未入庫檢查采集日志、核對(duì)服務(wù)檔案字典告警天天刷屏閾值設(shè)置過低規(guī)則太敏感改為連續(xù) 3 點(diǎn)超限才觸發(fā)或只看預(yù)測(cè)超線回測(cè) MAPE 過高歷史窗口內(nèi)發(fā)生過發(fā)版或配置變更啟用突變檢測(cè)重置訓(xùn)練窗口預(yù)測(cè)曲線比實(shí)際整體偏低趨勢(shì)線沒有延展訓(xùn)練窗口跨度把訓(xùn)練窗口長度計(jì)入預(yù)測(cè)起點(diǎn)的 x 坐標(biāo)這張表是我每次給別人介紹 rea 時(shí)一定會(huì)展示的內(nèi)容因?yàn)檫@些問題幾乎每個(gè)做類似工具的人都會(huì)遇到提前避坑比事后排查省心得多。5. 從算出來到用起來rea 的下一步預(yù)測(cè)模型做好之后我花在怎么讓建議更容易被執(zhí)行上的精力比繼續(xù)調(diào)模型的精力還多。因?yàn)橐粋€(gè)工具如果輸出只是一堆曲線決策者還是不知道怎么動(dòng)手價(jià)值就折半了。5.1 把數(shù)字翻譯成擴(kuò)容建議rea 的預(yù)測(cè)結(jié)果最終要落到一句話上某個(gè)服務(wù)建議從 4C8G 升級(jí)到 8C16G。這個(gè)翻譯規(guī)則我做了非常簡單直接的映射CPU 預(yù)測(cè)超過 70% 且持續(xù)一周以上建議增加 CPU 核數(shù)。內(nèi)存水位預(yù)測(cè)超過 75%建議增加內(nèi)存。磁盤預(yù)計(jì)耗盡天數(shù)小于 45建議增加磁盤容量或清理歷史數(shù)據(jù)。為什么不建議給出精確的數(shù)字因?yàn)樵茝S商的規(guī)格是離散的4C8G 下一步是 8C16G不存在 5.3C12.7G 這種規(guī)格。既然最終都要調(diào)到規(guī)格檔位工具直接把建議映射到規(guī)格省去決策者二次換算。每條建議后面都附了依據(jù)摘要預(yù)測(cè)曲線、超線時(shí)間點(diǎn)、近 30 天增長率。這樣負(fù)責(zé)審批的同事能快速判斷這個(gè)建議是否合理。我記得有個(gè)服務(wù)的擴(kuò)容申請(qǐng)以前要走兩輪解釋現(xiàn)在把 rea 生成的報(bào)告附上一輪就過了。5.2 小團(tuán)隊(duì)也能維護(hù)的工作流rea 的運(yùn)維成本被壓縮到了最低。每周一早上定時(shí)任務(wù)會(huì)跑一遍全部服務(wù)的 7 天預(yù)測(cè)生成一張匯總表推送到工作群。匯總表里只有三類狀態(tài)綠燈未來 7 天安全、黃燈未來 30 天內(nèi)可能超線、紅燈未來 7 天內(nèi)預(yù)計(jì)超線。大促前兩周團(tuán)隊(duì)會(huì)額外執(zhí)行一次全量評(píng)估。所謂全量評(píng)估就是把所有服務(wù)的 90 天預(yù)測(cè)都跑一遍篩選出紅燈和黃燈項(xiàng)逐個(gè)確認(rèn)擴(kuò)容計(jì)劃。整個(gè)過程從以前的兩三個(gè)人忙一天變成了現(xiàn)在一個(gè)人花一小時(shí)看報(bào)表、兩小時(shí)確認(rèn)清單。5.3 后續(xù)擴(kuò)展方向按優(yōu)先級(jí)排第一個(gè)方向是多指標(biāo)關(guān)聯(lián)分析。現(xiàn)在 rea 對(duì) CPU 和內(nèi)存是分開預(yù)測(cè)的但實(shí)際情況是 QPS 先漲CPU 跟著漲內(nèi)存可能滯后。如果把 QPS 作為前置指標(biāo)做回歸預(yù)測(cè)的提前量能更大。第二個(gè)方向是接入業(yè)務(wù)預(yù)估流量。有些業(yè)務(wù)會(huì)提前給出下一階段的流量預(yù)判這些信息如果能作為輸入?yún)⑴c估算模型的準(zhǔn)確度會(huì)明顯提升。前提是業(yè)務(wù)給的數(shù)字要靠譜否則模型會(huì)被帶偏。第三個(gè)方向是安全系數(shù)的動(dòng)態(tài)調(diào)整。目前固定乘 1.2但不同服務(wù)的預(yù)測(cè)穩(wěn)定度差很多。有些服務(wù) MAPE 常年 5%乘 1.2 就顯得過于保守有些服務(wù) MAPE 徘徊在 14%乘 1.2 可能還不夠。后續(xù)可以按每個(gè)服務(wù)的歷史預(yù)測(cè)準(zhǔn)確度自動(dòng)在 1.1 到 1.4 之間調(diào)整系數(shù)。第四個(gè)方向才是長期來看最誘人的聯(lián)動(dòng)自動(dòng)擴(kuò)縮容。rea 的預(yù)測(cè)可以作為擴(kuò)縮容的輸入信號(hào)但要加上嚴(yán)格的熔斷機(jī)制——比如實(shí)際水位與預(yù)測(cè)偏差超過 30% 時(shí)自動(dòng)關(guān)閉自動(dòng)擴(kuò)縮。這個(gè)方向我不會(huì)急著做先把預(yù)測(cè)做準(zhǔn)再談執(zhí)行。6. 使用半年后的個(gè)人體會(huì)rea 從立項(xiàng)到現(xiàn)在跑了小半年我最有感觸的一點(diǎn)是這個(gè)項(xiàng)目最值錢的地方從來不是那套估算公式而是讓容量評(píng)估從一種個(gè)人經(jīng)驗(yàn)變成了一項(xiàng)團(tuán)隊(duì)能力。以前評(píng)估只存在于幾個(gè)老同學(xué)腦子里現(xiàn)在它沉淀成了數(shù)據(jù)、模型、報(bào)表和一套可以隨時(shí)被任何人復(fù)核的流程。最后分享一個(gè)我自己堅(jiān)持的小做法每次擴(kuò)容請(qǐng)求通過后我會(huì)把 rea 的預(yù)測(cè)報(bào)告存檔等下一次同類評(píng)估時(shí)翻出來對(duì)比。對(duì)比得多了你會(huì)發(fā)現(xiàn)模型的偏差模式是有規(guī)律的——某個(gè)服務(wù)長期偏保守、某個(gè)服務(wù)總在版本發(fā)布后被高估。掌握這些規(guī)律之后你在查看 rea 輸出時(shí)就能自動(dòng)在心里留出修正空間。這種工具加人的協(xié)作方式比任何單一模型都可靠。如果你也想在自己團(tuán)隊(duì)搞一套類似的工具我的建議是別一上來就追求算法多高級(jí)、模型多復(fù)雜。先把數(shù)據(jù)采集和清洗做好把最簡單的趨勢(shì)預(yù)測(cè)跑通再逐步疊加季節(jié)性和突變檢測(cè)。你會(huì)發(fā)現(xiàn)把那些臟數(shù)據(jù)和口徑問題處理完之后最簡單的模型已經(jīng)能解決大部分問題了。