一、日常問題
1）頁面卡死
QA 將一個頁面放在客戶端中訪問，進行功能測試的時候，發現運行在 iOS 16.7 系統中時，網頁會卡死。
將頁面地址複製到 Safari 瀏覽器中，訪問也會卡死。而據 QA 描述，測試環境沒有問題，其他 iOS 版本的系統以及安卓手機也沒有問題。
有問題的手機，其測試和線上的客戶端版本都是相同的，初步斷定和 iOS 系統有關。
搖上 iOS 的人，讓他們幫忙調試，發現卡在接口通信，接口通信中的響應一直在 loading，沒有顯示。
讓客戶端排查，他們什麼頭緒也沒有，說可能頁面渲染被阻塞了。
將接口換個路徑，響應內容相同，但依然會被卡死。以爲是接口請求時機的問題，那就加個延遲，依然有問題。
將接口響應置空，這時，頁面不會卡死，看來與響應內容有關。
接下來將響應內容中的數組只返回一個，頁面仍然不會卡死，嘗試二分查找的思路，再返回 10 個，依舊正常，返回 15 個，出現卡死。
那看來問題出在這 5 條記錄中，一個一個排查，發現一個 emoji 的蘑菇表情會讓頁面異常，過濾後就正常了。
又去搖客戶端的人，他們排查半天也沒發現問題，因爲不是所有的 emoji 表情都異常，目前就一個，也找不出規律。
此時，一名客戶端的人說用相同系統的手機訪問管理後臺，可以正常顯示這個表情，活動頁面和後臺的區別就是用了不同的框架。
前者是 React 後者是 Vue，既然如此，那就查一下這個表情在 Vue 中輸出的寫法。
使用的是模板語法，將其替換成 v-html 的寫法後，一切恢復了正常，特地查了這個屬性的原理。
它會將變量內容賦給元素的 innerHTML 屬性，而模板語法會經過很多複雜步驟，可能是某一步操作發生了死循環導致了卡死。
遇到此類難以馬上解決的問題，需要抽絲剝繭的分析自己獲取到的線索，然後一步一步推導，最後得出結論，這有點像探案推理。
總結上述這套過程就是尋線索，找差異，縮範圍，給結論，如此遞歸反覆，直到解決問題爲止。
2）協作問題
我們組的重點是活動和管理後臺，版本涉及的都是比較邊緣的需求，有時候都沒有直接需求。
最近就遇到，QA 在測版本需求時，臨時找我們修改 BUG，這讓我們很被動，安排的計劃也被打亂了。
剖析了下這個問題，發現來源於兩個方面。第一是產品在設計文檔時，缺失了我們要修改的那部分業務。
但是人總歸有盲區，漏掉點需求很正常。第二是技術評審不夠詳細，現在的評審流於形式，其他組我也控制不了。
目前就是比較粗的過，然後經常在開發時，遇到問題再和產品測試等人討論，這個流程目前破不了。
想來想去，想到了 QA，是他們告訴我們有 BUG，那隻需要求他們在設計測試用例時，涉及到我們這塊的，就提前通知。
即使在版本中，我們沒有要修改的需求，也要同步給我們，這樣就不至於在測試過程中那麼被動，被趕着改 BUG。
最近在做一個 Electron 客戶端的項目，也遇到了兩個協作問題。第一個就是協作團隊的文檔缺失，讓我們吃了不少苦頭。
我們的任務是將客戶端的一個功能，搬到 Electron 項目中，但是在開發過程中，沒有技術文檔，遇到問題只能口頭討論，很費時間。
第二個就是第三方服務文檔缺失，雖然他們會提供示例，但是每次都要過一點時間才能給到，無法第一時間拿到。
這就會延緩我們的開發進度，很多時候只能乾等。總結下來，就是不同團隊的技術文檔缺失影響了我們的開發。
這也提醒我們自己組，技術文檔要補充完善，以免影響他人。
二、工作優化
1）缺失的性能測試
最近上了一個大活動，其中會調用服務端的一個內部接口，這個接口是這次活動新寫的。
剛上線的時候，發現了少量的慢響應，當時並沒在意。正好趕上雙休日，這兩天慢響應一下子就上升了。
週末在家排查，發現是服務端的那個新接口問題，但想到頁面還能打開，只是響應慢點，也就沒有組織人力去修復了。
畢竟週末時間找人也比較困難，就這麼拖到週一，他埋了日誌，週二才做了一版修復，上線。
結果週三零點，整個活動頁面的接口都超時，被電話打醒，趕緊排查，馬上搖人服務端。
他說有個服務一直在告警，那你們居然沒點反應，我真是醉了，運維我也搖了，過了半小時纔來。
他說那個服務的 CPU 一直居高不下，服務端也沒找出問題，還是我點醒他重啓下服務，才恢復，額。
這麼一折騰，運營都要跳起來了，在羣裏狂抱怨，我也很無奈。
其實我這邊的日誌顯示從週二的 21 點開始，慢響應持續上升，我也大意了。
改了接口居然沒關注，以爲一切順利，其實不然，今晚的日誌一定要仔細關注了。
服務器的配置也會讓運維升級，其實這個接口也是讓 QA 測試過的，並沒有功能問題。
但是卻存在嚴重的性能問題，QA 之前自己也說以後得增加這塊，這次的問題是三方都有責任，既有客觀也有主觀原因。
公司在經歷裁員之後，服務端有經驗的員工都離職了，這個留下的小夥來了才 1 年，模塊也剛接手，開發經驗也缺乏。
以後得完善測試流程，以及自己要多留心眼，就好像常說的不要完全信任用戶的輸入，協作時也有這點意思。
2）OKR
公司要求我們每個雙月要制訂自己的 OKR，然後還要對齊上級的 OKR。
我對齊了上級的雙月高等級業務需求，不過我總覺得這個並不算 OKR，因爲這些都是我們本月排進日程的任務。
第二個 O 是質量相關，將線上因代碼問題導致的高等級 BUG 或事故降低至 0，之前寫的 KR 不夠具體，無法明確 KR 與 O 之間的聯繫。
那麼這次又修改了一下，分析以往發生重大線上事故的原因，發現很多時候是因爲慢 SQL 和數據庫表太大撐滿了整個數據庫的容量。
由此就馬上將其作爲一個 KR，組織排查與優化，保持數據庫健康。還真找到不少潛在問題，例如已沒有記錄的一張表，還佔用 29.12GB 容量，立刻釋放掉。
然後通過下面的 SQL 語句找到排名靠前的數據庫表，清理不再需要的數據庫表。
select table_schema as '數據庫', table_name as '表名', table_rows as '記錄數', truncate(data_length/1024/1024, 2) as '數據容量(MB)', truncate(index_length/1024/1024, 2) as '索引容量(MB)' from information_schema.tables where table_schema='backend' order by data_length desc, index_length desc;
另一個在使用的數據庫是 MongoDB，用代碼列出容量佔用比較高的集合，發現可以釋放掉 100G，每個月能減少 50 元的費用。
第二個 KR 是定期 Code Review，包含細節、安全、邊界等內容，保障代碼健壯性。Code Review 在執行時，安全性往往會被忽略，僅僅是複查邏輯的合理性是不夠的。
還有些細節也應該放上臺面，隔壁組服務端前段時間出現了非常嚴重的線上緊急 BUG，發生在 2 月 29 日那天，他們有段計算年齡的代碼。
會將當天推算到 18 年前的當天，但是 18 年前的 2 月沒有 29 號，導致計算異常發生了 BUG。但其實算年齡，完全不必如此計算，若在 Code Review 中就將此問題拋出。
那麼就不會發生此類線上問題，關鍵發生在凌晨，都很難及時修正。
對三個 KR 分析飛書告警，修復會對業務造成影響的潛在問題。我們會將線上的頁面錯誤和接口錯誤實時通過飛書發出告警。
這些告警可能不是最爲緊急嚴重的，可能就是偶爾發生的，但是將它們修復，有助於避免潛在的風險。