工作總結(jié)
發(fā)表時(shí)間：2026-04-03孩子王轉(zhuǎn)正工作總結(jié)。
入職孩子王九十天，試用期最后一天下班前，我把促銷計(jì)算模塊的最后一個(gè)單測(cè)用例跑通，覆蓋率剛好卡在71.3%——離目標(biāo)還差一點(diǎn)，但至少核心的三重疊加場(chǎng)景全過(guò)了。這三個(gè)月，主要任務(wù)是接手交易鏈路里的“促銷計(jì)算”老模塊，把它從一碰就碎的瓷器改成能扛住雙十一的鋼筋水泥。下面把這期間拆過(guò)的雷、擰過(guò)的螺絲、跟同事吵過(guò)的架，老老實(shí)實(shí)捋一遍。
一、老代碼的債，新方案的路 ?
剛進(jìn)來(lái)第一周，leader扔給我一個(gè)故障單：某筆訂單用了“滿300減50”疊加“母嬰品類95折”，最終支付金額算出來(lái)是負(fù)數(shù)。我順著調(diào)用鏈找，點(diǎn)進(jìn)去七層——從OrderPriceCalculator到PromotionDiscountService再到CouponApplyServiceImpl，最后在MemberLevelUtil的一個(gè)靜態(tài)方法里發(fā)現(xiàn)，折扣金額被轉(zhuǎn)成了double，加減乘除丟精度了。改完那一行代碼，我把涉及金額計(jì)算的所有類搜了一遍，類似問(wèn)題還有五處。
老方法的坑不止精度。促銷規(guī)則全放在數(shù)據(jù)庫(kù)里，每個(gè)商品每類促銷都要單獨(dú)查表。一個(gè)訂單十件商品、五種促銷，就是五十次數(shù)據(jù)庫(kù)往返。我統(tǒng)計(jì)過(guò)，日常平均響應(yīng)280毫秒，大促預(yù)演時(shí)沖到600毫秒以上。更離譜的是，優(yōu)先級(jí)判斷的邏輯被復(fù)制粘貼在三個(gè)不同的Service里，修一個(gè)bug要改三處，改漏一處就出事。
新方案分三步落地。第一，把促銷規(guī)則全部預(yù)熱到本地Caffeine緩存，活動(dòng)規(guī)則十分鐘過(guò)期，商品快照半小時(shí)過(guò)期，緩存容量從默認(rèn)的5000條擴(kuò)大到50000條——這個(gè)數(shù)字是壓出來(lái)的，再大GC受不了，再小命中率不夠。第二，重寫優(yōu)先級(jí)引擎，把互斥、疊加、階梯三類邏輯抽成獨(dú)立的PromotionChain，每個(gè)促銷實(shí)現(xiàn)統(tǒng)一的calculate接口，新加活動(dòng)只需要加一個(gè)實(shí)現(xiàn)類，不用改老代碼。第三，引入訂單快照的預(yù)計(jì)算字段，下單前一次性把商品所屬品牌、類目、價(jià)格檔位加載到內(nèi)存，避免逐條查。
上線不是一把梭。我先在預(yù)發(fā)環(huán)境把新老引擎雙寫跑了三天，每天隨機(jī)抽一千個(gè)真實(shí)訂單號(hào)對(duì)比計(jì)算結(jié)果。第一天誤差率0.3%，全是精度問(wèn)題——新引擎用ROUND_HALF_EVEN，老引擎用ROUND_HALF_UP。統(tǒng)一改成ROUND_HALF_UP后，誤差率降到0.02%，剩下的是因?yàn)榫彺骖A(yù)熱時(shí)機(jī)不一致導(dǎo)致的瞬時(shí)不匹配。又調(diào)了兩天，把緩存加載改成應(yīng)用啟動(dòng)時(shí)強(qiáng)制預(yù)熱，然后放量1%的流量做灰度，觀察四小時(shí)無(wú)報(bào)錯(cuò)，逐步放大到5%、20%、50%、100%。最終上線后，同樣場(chǎng)景下平均響應(yīng)時(shí)間從280毫秒壓到了42毫秒，TP99從520毫秒降到了86毫秒。壓測(cè)報(bào)告出來(lái)那天，我對(duì)著數(shù)據(jù)愣了三秒，然后去泡了杯速溶咖啡——比中彩票實(shí)在。
二、一個(gè)真實(shí)的故障：晚高峰前的四十分鐘 ?
十月十七號(hào)，周四，下午五點(diǎn)四十。我剛準(zhǔn)備去接水，手機(jī)監(jiān)控彈窗——促銷計(jì)算模塊P99耗時(shí)飆升到1.2秒。打開(kāi)SkyWalking，calculateMemberExclusivePrice這個(gè)方法調(diào)用量暴增了二十倍，每筆訂單都在掃一張全表。
查日志發(fā)現(xiàn)，運(yùn)營(yíng)下午四點(diǎn)配了一張“育兒顧問(wèn)專享價(jià)”表，但配置邏輯出了問(wèn)題：不是按會(huì)員ID映射，而是用手機(jī)號(hào)明文做LIKE模糊查詢。當(dāng)時(shí)離晚高峰只剩不到二十分鐘，改代碼根本來(lái)不及。我直接在生產(chǎn)配置中心把member.exclusive.enable這個(gè)開(kāi)關(guān)設(shè)為false，強(qiáng)制走降級(jí)邏輯——統(tǒng)一按普通會(huì)員折扣處理。五分鐘后，耗時(shí)回落到正常水平。
然后我讓運(yùn)營(yíng)導(dǎo)出那張表，寫了臨時(shí)腳本把手機(jī)號(hào)轉(zhuǎn)成會(huì)員ID的哈希映射，存到Redis Set里，同時(shí)加了一層布隆過(guò)濾器防止緩存穿透。晚上九點(diǎn)半，重新打開(kāi)開(kāi)關(guān)，觀察了半小時(shí)，一切正常。那天晚上我走的時(shí)候，運(yùn)維同事跟我說(shuō)：“下次你直接打電話叫我就行，不用自己改配置。”我說(shuō)：“下次我提前把腳本寫好，你幫我跑。”
事后我補(bǔ)了兩件事：第一，在代碼里對(duì)所有外部數(shù)據(jù)源依賴加了熔斷和降級(jí)開(kāi)關(guān)的標(biāo)準(zhǔn)化注解，以后新加促銷類型必須默認(rèn)帶降級(jí)邏輯才能合并。第二，跟運(yùn)營(yíng)約定，任何新配置上線前必須先過(guò)一遍“手機(jī)號(hào)轉(zhuǎn)ID”的自動(dòng)化校驗(yàn)?zāi)_本，否則不接收。這兩件事算不上什么技術(shù)突破，但真到火燒眉毛的時(shí)候，就是命。
三、質(zhì)量驗(yàn)收和設(shè)備維護(hù)那些規(guī)矩 ?
我們每個(gè)迭代結(jié)束要過(guò)一次“故障演練清單”，不是走形式，是真摔。清單上列了十二條場(chǎng)景，比如：Redis集群全掛、會(huì)員服務(wù)超時(shí)、緩存擊穿、促銷規(guī)則配置為空……每一條都要驗(yàn)證系統(tǒng)能在規(guī)定時(shí)間內(nèi)降級(jí)或自愈。上個(gè)月演練“Redis掛掉”這一項(xiàng)時(shí)，我發(fā)現(xiàn)本地緩存的淘汰策略有問(wèn)題：maximumSize設(shè)得太小，高并發(fā)下頻繁觸發(fā)淘汰和重載，反而比直接查庫(kù)還慢。調(diào)整到50000條后，結(jié)合差異化過(guò)期時(shí)間——活動(dòng)規(guī)則十分鐘、商品快照半小時(shí)——才真正穩(wěn)住。
設(shè)備維護(hù)這塊，我接手時(shí)前輩們習(xí)慣手動(dòng)top、free看資源。我搭了一套Grafana看板，盯三個(gè)核心指標(biāo)：GC暫停時(shí)間、年輕代晉升速率、接口TP99同比曲線。有一回發(fā)現(xiàn)晉升速率異常飆高，順著查下去，是日志里不小心打出了完整的促銷規(guī)則JSON對(duì)象，一條規(guī)則能有兩百多行。刪掉那行日志，GC頻率從每分鐘12次降到3次，停頓總時(shí)長(zhǎng)從800毫秒降到120毫秒。
代碼審查也有規(guī)矩。我們要求所有金額計(jì)算必須用BigDecimal，所有外部調(diào)用必須設(shè)超時(shí)，所有配置變更必須走配置中心而不是硬編碼。有一次code review，一個(gè)同事把超時(shí)時(shí)間寫成了30秒，我說(shuō)“你見(jiàn)過(guò)哪個(gè)用戶等三十秒不關(guān)頁(yè)面？”改成3秒，配合重試兩次。后來(lái)線上真有一次會(huì)員服務(wù)抖動(dòng)，3秒超時(shí)觸發(fā)重試，第二次成功了，用戶沒(méi)感知。
四、跟測(cè)試同事的“友好交流” ?
第二周迭代，測(cè)試提了個(gè)bug，標(biāo)題寫著“促銷計(jì)算錯(cuò)誤，優(yōu)惠金額多減了0.01元”。我看了半天代碼，覺(jué)得自己邏輯沒(méi)問(wèn)題，就去找測(cè)試。她打開(kāi)訂單詳情給我看，我一眼就發(fā)現(xiàn)——她造的那個(gè)商品原價(jià)是9.99元，滿減規(guī)則是“滿10減1”，系統(tǒng)沒(méi)給優(yōu)惠，她覺(jué)得應(yīng)該給。我說(shuō)“滿10減1，9.99不滿10，當(dāng)然不減。”她說(shuō)“用戶會(huì)覺(jué)得就差一分錢，你們應(yīng)該四舍五入。”那天下午我們倆在會(huì)議室吵了十分鐘，最后產(chǎn)品經(jīng)理過(guò)來(lái)拍板：規(guī)則不改，但前端加提示“還差0.01元即可享受優(yōu)惠”。這事讓我學(xué)到一個(gè)教訓(xùn)——技術(shù)上的正確不等于用戶體驗(yàn)上的正確，有些邊界條件得跟產(chǎn)品對(duì)齊，不能光看需求文檔。
- 讀書筆記吧必讀推薦:
- 客服轉(zhuǎn)正工作總結(jié)?|?車間轉(zhuǎn)正工作總結(jié)?|?鋼廠轉(zhuǎn)正工作總結(jié)?|?會(huì)計(jì)轉(zhuǎn)正工作總結(jié)?|?孩子王轉(zhuǎn)正總結(jié)?|?孩子王轉(zhuǎn)正總結(jié)
后來(lái)我在代碼里加了一層“接近閾值”的預(yù)判斷，比如滿減差5%以內(nèi)就在日志里打一個(gè)WARN，運(yùn)營(yíng)可以據(jù)此調(diào)整活動(dòng)門檻。
五、文檔和回滾：沒(méi)出事不等于沒(méi)準(zhǔn)備 ?
重構(gòu)完促銷引擎，我寫了遷移指南，放在團(tuán)隊(duì)Wiki上，內(nèi)容包括：新舊數(shù)據(jù)結(jié)構(gòu)對(duì)照表、配置項(xiàng)說(shuō)明、灰度放量步驟、常見(jiàn)問(wèn)題排查。上周一個(gè)新來(lái)的同事接手了另一個(gè)模塊，照著我的文檔處理了類似的緩存問(wèn)題，在群里說(shuō)了句“還好有這篇”。我覺(jué)得這比任何表?yè)P(yáng)都實(shí)在。
回滾預(yù)案我單獨(dú)寫了一頁(yè)。核心就一句話：配置中心里有一個(gè)promotion.engine.version開(kāi)關(guān)，設(shè)為v1用老引擎，v2用新引擎。一旦新引擎大面積算錯(cuò)，十秒鐘內(nèi)切回v1，損失不超過(guò)一輪緩存刷新周期。這個(gè)開(kāi)關(guān)上線前演練過(guò)兩次，第一次切換耗時(shí)15秒（因?yàn)橛幸惶幰蕾嚊](méi)解耦），第二次優(yōu)化到4秒。
六、往后怎么干 ?
接下來(lái)兩件事。一是把促銷計(jì)算模塊的單測(cè)覆蓋率從71.3%提到85%以上，重點(diǎn)補(bǔ)“滿減+折扣+優(yōu)惠券”三重疊加場(chǎng)景下的尾差計(jì)算——目前這個(gè)場(chǎng)景只有3個(gè)用例，要補(bǔ)到30個(gè)以上，覆蓋所有可能的價(jià)格小數(shù)點(diǎn)組合。二是跟運(yùn)維一起把彈性伸縮策略從基于CPU改成基于TP99，規(guī)則是：當(dāng)TP99連續(xù)兩個(gè)采樣點(diǎn)超過(guò)100毫秒，自動(dòng)擴(kuò)容一臺(tái)實(shí)例；低于50毫秒且持續(xù)十分鐘，縮容一臺(tái)。這個(gè)閾值是拿雙十一預(yù)估流量的六倍壓測(cè)數(shù)據(jù)擬合出來(lái)的，不是拍腦袋。
轉(zhuǎn)正申請(qǐng)寫完了，但活兒沒(méi)完。明天早上還有個(gè)代碼審查會(huì)，要過(guò)一遍新來(lái)的同事寫的“拼團(tuán)促銷”邏輯。我打算在會(huì)上問(wèn)一個(gè)問(wèn)題：“拼團(tuán)失敗退款時(shí)，已經(jīng)分?jǐn)偟矫總€(gè)人頭上的優(yōu)惠怎么收回？”如果他答不上來(lái)，我會(huì)把方案寫清楚，貼到Wiki上。這才是轉(zhuǎn)正后的正常狀態(tài)——不是慶祝，是繼續(xù)干活。
- 推薦閱讀: 孩子王轉(zhuǎn)正工作總結(jié) 宣傳轉(zhuǎn)正工作總結(jié)（精辟） 投行轉(zhuǎn)正工作總結(jié) 結(jié)算崗位轉(zhuǎn)正工作總結(jié) 財(cái)務(wù)員的轉(zhuǎn)正工作總結(jié)
- 為了您方便瀏覽更多的工作總結(jié)網(wǎng)內(nèi)容，請(qǐng)?jiān)L問(wèn)工作總結(jié)
