一、日常問題

1）臨時小需求

　　在日常研發過程中，難免會臨時加些小需求，例如增加個標識、字體換個顏色、間距增加等。

　　這類需求雖然不復雜，但是很多時候都會打亂自己的開發節奏。

　　最近我收到個修改需求，來來回回改了四次。因為只是和我口述了下需求，我按照口述修改。

　　后面測試就發現了些場景需要過濾，再馬上修復。上線后，由于沒有設計稿，我所設計的界面效果，與產品所想的不一致。

　　再做了兩次修改，雖然花的時間不多，但是著實費勁。歸根到底，還是因為需求不明確導致的。

　　下次遇到此類問題，需要和產品將需求描述清楚，有必要的話，還可以叫上測試，從場景到呈現，都要一一詢問，以免遺漏。

2）服務調用錯誤

　　周二晚上有人上報某個排行榜數據不更新，排查后發現是 Node 調用服務端的服務沒成功（服務調用錯誤 getaddrinfo ENOTFOUND xxx）。

　　從而讓 Node 報錯引起 Pod 重啟，接口就訪問不到數據了。

　　其實調用服務端接口都已經做錯誤捕獲（try-catch），但是在 catch 分支中沒有返回對象。

　　最直接的辦法就是先給一個默認的返回值，不出現 undefined 的錯誤，也能讓 pod 不再重啟。

　　改完代碼上線后也到了晚上 23 點，pod 是不再重啟了，服務端接口大部分能成功調用，但也有比較少的失敗。

　　第二天來公司，運維和我說，后端的 Pod，當 CPU 過高時就會自動重啟，而這種情況在訪問量比較大的時間段會比較頻繁。

　　這個騷操作也是無奈之舉，他們現在也沒資源去做代碼優化，只能通過重啟的辦法來緩解線上過慢的請求。

　　那么運維給我們部署了一套單獨的服務，專門就由我們來調用，不會重啟，調用的域名更新后，果然不再有請求失敗的錯誤了。

　　其實還有一種叫做熔斷的模式，就是如果發現上游服務調用慢，或者有大量超時的時候，直接中止對于該服務的調用，直接返回信息，快速釋放資源。

　　這里就需要再做代碼優化了，后續可以優化優化。

3）數據庫CPU異常

　　從 10 月 8 號開始，每天凌晨 3 點數據庫都會推送異常告警，CPU 的使用率超過了 60%。

　　一開始以為是偶發現象，因為之前也有這種突然增長的情況，但每天都會告警就有問題了。

　　找運維排查，說了一張表，將表名推給相關組排查，發現并不是他們的服務引起了。

　　這說明運維的推斷有誤，因為每天都是定時的，所以感覺是在跑一個定時任務。

　　運維再次鎖定到一條 delete 語句，用于刪除七天前的監控日志，執行時間長達 10 分鐘，在這段時間，CPU 飆升。

DELETE FROM `web_monitor` WHERE `ctime` <= '2024-10-08 00:00'

　　很有可能與最近的日志量上漲有關，之前每日的數據在 70W 條左右，而現在達到了 100W 條左右。

　　運維說他那邊也可以配置數據庫的定時操作，然后在語句中會加 limit 限制，這樣就不會占用太長時間。

　　不過，我最終還是沒有讓他配置，主要是因為如果定時操作出現異常，還得找運維修復，并且沒有告警，異常了也不會知道。

　　這個服務對于我比較重要，所以還是決定自己優化，方式也簡單，同樣是加 limit 限制，只不過多幾次循環。

　　最近，服務端的接口也老報 500 錯誤，有幾天報的比較厲害，都影響了我監控的性能指標，也反饋了兩次。

二、工作優化

1）協作依賴

　　最近在做組內 1V1 時，發現了協作依賴的問題。

　　就是在多組協作時，會存在依賴關系，但這是個單向依賴，并且被依賴對象并不知道有人在依賴他。那么當修改或遺漏邏輯時，也不會去通知依賴人，就有可能出現問題。

　　就是你的代碼邏輯有個前置條件存在于其他組，當其他組更新代碼時，并不知道會影響你，那你的這段代碼就會無法執行，導致用戶上報。

　　這個雙月遇到了兩次這個問題，一次是我們依賴別人，另一次是別人依賴我們。

　　有個審核的功能，服務端會將一條記錄插入一張表中，我們會從這張表中去查是否有這條記錄。

　　但這次服務端換了個人做更新業務，他沒有將記錄插入，從而導致我們組的邏輯異常。

　　這個問題我更傾向于覺得他們組對常規功能沒有保留詳盡的技術文檔，出現了邏輯遺漏。

　　另一次是數據組在做數據統計時，會依賴操作記錄的一個字段，我們會寫入這個字段，這次產品修改了這個字段的格式，從而導致統計異常。

　　這個問題我更傾向于若有數據相關的需求，盡量提前告知數據組，避免無法統計結果。

　　其實最簡單直接的解決方案是提前通知依賴人，但是難點就是不知道有這么一個人存在，所以在實際項目中就會出現遺漏。

　　而且我感覺這種協作問題應該還蠻多的。

2）告警不是一串數字

　　國慶假期前，偶爾收到了幾個 500 的錯誤，沒有當回事兒，以為就是偶發現象。

　　沒想到國慶假期期間突然出現了大量的 500 警告，一查原來是網關轉發的時候報 502、503、504 錯誤。

　　這就導致收到了非標準的 JSON 格式，調用 response.data.xxx 就會報 undefined 的錯誤。

　　知道原因后，馬上修改，將網關轉發改成內部的接口調用，并且給代碼加了些 undefined 的判斷。

　　3 號 23 點多的時候發布代碼，4 號的指標就正常了。

　　期間還發現了大量的慢響應，是之前正常的 20 多倍，查看接口日志，最后鎖定是依賴的服務端接口出現了異常。

　　聯系了運維和服務端的人，后者沒有回應，前者去查了下，說是其他接口影響了整個服務，而這些接口并不是我們調用的。

　　最后給我們單獨配了 POD，只有我們訪問的接口才會請求這個 POD，5 號的慢響應占比馬上就恢復了。

　　對數據的不敏感，以及無視告警，讓自己在國慶期間還要連夜改代碼，都是自己作的，怨不得別人。

　　雖然是上游影響了下游，但是造成影響后，還是得下游來背鍋，所以未來的話，數據還是要盯緊些，不要只是當成一串數字。