一、日常問題
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 號的慢響應占比馬上就恢復了。
對資料的不敏感，以及無視告警，讓自己在國慶期間還要連夜改程式碼，都是自己作的，怨不得別人。
雖然是上游影響了下游，但是造成影響後，還是得下游來背鍋，所以未來的話，資料還是要盯緊些，不要只是當成一串數字。