專業在線打字練習平臺-巧手打字通，只輸出有價值的知識。
一 前言
在本次巧手打字通課堂中，我們將深入探討研發人員在日常工作中遭遇的線上事故之根源，并系統闡述一系列有效的規避策略與預防措施，旨在提升團隊的整體作業安全與效率。
二 事故分析
以下統計了近30起線上事故的原因歸類：
巧手打字通（一起來打字）
經過對線上事故問題的細致分類與分析，我們識別出技術層面的問題占據了顯著比例，同時，個性化的運營環境挑戰與不健全的系統設計缺陷亦是不容小覷的兩大關鍵因素。進一步聚焦至事故的具體成因，可歸納為以下八大高危問題域。
- 技術編碼漏洞；
- 數據庫使用不當；
- 運營環境配置錯誤；
- 違反編碼規范；
- 測試覆蓋不全；
- 日志不規范輸出；
- 安全意識薄弱；
- 中間件使用不當；
盡管完全消除所有問題極具挑戰性，但規避過往已發生的錯誤與陷阱則相對可行。鑒于前人已對這些問題進行了詳盡的分析并提煉出有效的解決方案，我們僅需積極學習并恰當應用這些經驗，便能以更高的效率達成事半功倍的效果。
三 經典案例
下面將針對一系列具有代表性的典型案例進行簡單剖析與總結，旨在為大家提供前車之鑒，幫助規避潛在風險，減少在相似情境下可能遭遇的彎路。
| 類別 | 原因 | 事故描述 | 事故總結 |
|---|---|---|---|
| 設計 | MQ | 1.多個業務MQ公用一個topic主題，通過消息屬性來區分業務場景，這會導致其中一個業務場景的mq消費積就會壓嚴重影響了其它業務場景的消息消費； 2.MQ消費時長超過最大超時時間例如：120秒，這會導致后面所有消息積壓無法快速消費； | 1.核心業務mq的topic分開，不要復用；2.mq消息只做輕量級的通知功能，不處理復雜的業務邏輯，如果有復雜的邏輯處理，考慮將消息本地化存儲，通過分布式任務調度處理； |
| 運維 | 數據庫 | 數據庫主從集群切換導致兩集群數據不一致；（主從數據有延時的情況） | 1. 切換后要注意檢查新主庫的數據完整性； 2. 嚴禁主從來回頻繁切換，進而提高了數據不一致情況的發生； |
| 技術 | 數據庫 | 1.數據庫數據定期遷移歷史庫，突發的大量讀寫，導致主從延時嚴重； 2.應用層面實現了數據庫的讀寫分離，部分業務讀從庫數據無結果。 | 控制數據庫的數據量，比如：及時歸檔或分庫； |
| 技術 | 規范 | 數據在兩個之間通過應用進行同步，經過工具直接對一方的數據進行了更改但沒有觸發同步邏輯的機制，雙方業務數據狀態出現了不一致，造成業務損失； | 切記未經測試的功能直接上線； |
| 環境 | 配置 | 機器擴容忘記綁定host，導致擴容機器未生效； | 上線擴容自動化，避免存在人工干預的事項存在，減少運營心智負擔； |
| 環境 | 測試 | 線上傳參調用預發布環境，導致業務出現非預期的錯誤； 2.測試用例場景覆蓋不全； | 不同環境要做隔離； |
| 技術 | 規范 | switch分支條件未寫break語句，導致后續不應該執行的代碼邏輯執行了； | 1. 接入編碼規范掃描插件；2.核心邏輯做代碼review； |
| 技術 | 漏洞 | 計算邏輯復雜導致接口可用率下降； | 極限邊界思維，設置邊界上限值，做好降級，防止雪崩； |
| 技術 | 配置 | 1.預發布和線上jvm的堆內存大小配置不一致； 2.新擴容機器分組用了預發布配置，導致擴容分組機器無法支持線上正常流量出現不可用情況； | 機器擴容一定要做到0門檻式操作； |
| 技術 | 漏洞 | 兩個系統之間存在數據同步邏輯，發起方進行了數據創建動作后，立即又進行了取消動作，接收方只取消了部分已經同步； | 關注數據一致性設計； |
| 技術 | 配置 | 1.研發誤將短鏈域名在nginx刪除，導致前端result返回null； 2.前端未做code判斷，且未做判空處理，直接使用數據出現程序異常； | 遵循誰污染誰治理，誰開發誰負責的原則； |
| 技術 | 漏洞 | 某優惠券被黑產領取了1萬多張，導致對應緩存分片出現了大key，在優惠券使用的時候出現性能問題； | 極限邊界思維，設置邊界上限值，做好降級，防止雪崩； |
| 技術 | 漏洞 | 通過excel上傳文件批量取消優惠券，由于文件中的時間格式有問題，導致時間轉換出現異常，默認為當前系統時間，導致業務處理異常； | 異常處理是問題出現的高頻場景 |
| 技術 | 數據庫 | 代碼層面使用long類型，數據庫字段使用int類型，int溢出，導致數據庫異常出現，影響訂單生產； | 1. 設計要有長遠視角； 2. 技術實現要前后自洽，杜絕埋坑； |
| 環境 | 配置 | 服務器磁盤空間使用率高，刪除多余日志文件時，錯誤的刪除了數據所在目錄，導致數據丟失； | 服務器文件權限控制好，系統運營自動化，減少人工干預的情況 |
| 環境 | 規范 | 預發布引用了生產環境服務，導致向用戶推送了大量無效文案； | 1. 環境隔離； 2. 底線思維，即使發錯了，如何保證消息是能夠取得正向反饋的； |
| 設計 | 漏洞 | 部分業務可以幫助用戶自動領取最優券，結果誤將賠付券多次領取到用戶賬戶下面； | 產品設計也有可能存在問題； |
| 技術 | 漏洞 | 金額計算系統中存在十幾個版本的特殊邏輯分支判斷，其中某版本處理邏輯出現問題，導致為用戶多發了一次運費優惠。 | 完善自動化測試用例，進行自動化回歸測試 |
| 環境 | 安全 | 線上測試門店被人下單，多次拒絕客服解決方案，要求高額賠償。 | 測試門店和商品有專人來維護運營，個人禁止創建線上測試門店； |
| 技術 | 漏洞 | 預發布和線上配置不一致導致邏輯處理不一致，這種情況預發布還無法驗證出來； | 上線要進行小流量的灰度測試 |
| 設計 | 數據庫 | ES某場景出現復雜查詢影響到集群性能，導致其它相關核心業務也同步收到影響； | 1. 核心業務做好服務隔離； 2. 核心功能要有降級托底應急方案； |
| 環境 | 配置 | 將預發布環境的代碼錯誤的直接部署到線上了 | 1.自動化上線流程要做git分支檢測； 2.進行灰度驗證； |
| 技術 | 漏洞 | 第三方返回結果json化解析出現異常，導致服務不可用； | 異常處理建議有兜底的統一捕獲處理邏輯； |
| 技術 | 數據庫 | 多表關聯復雜查詢，出現慢SQL，導致系統定時備份失敗，數據庫不可用。 | 1.重要系統原則上禁止多表關聯查詢；2.考慮其它實現方案（比如ES）來實現數據查詢統計功能， |
| 技術 | 漏洞 | ExecutorCompletionService線程池使用不當導致OOM，只submit異步提交任務，沒有調用get獲取future結果，導致隊列數據不刪除，出現內存溢出； | 高并發場景，壓力測試不能省略； |
| 技術 | 數據庫 | 數據歸檔功能的慢sql導致核心功能不可用； | 1. 歸檔操作要在業務低峰期執行； 2. 讀寫分離，運用索引，運營端的like等操作盡量避免； 2. 做好降級，不影響主流程； |
| 技術 | 測試 | 獲取短信內容的緩存key拼裝邏輯錯誤，沒有取到真實的短信消息內容，短信push發送“null“ ； | 1.研發自測環節不可少； 2.測試回歸范圍覆蓋要全面； |
| 技術 | 數據庫 | 緩存過期時間進行了調整，但歷史數據沒有做日期的更新處理，導致歷史數據沒有按照現有規則過期； | 1.方案設計時，注意數據一致性處理；2.重要變更設計需要評審環節 |
| 技術 | 日志 | 1.日志打印過多，導致cpu飆升； 2.redis存在大key和熱key導致內存占用過高，最終導致服務可用率降低； | 1. 日志打印要收斂； 2. 線上日志級別調整開關要有變更通知預警機制； 3. 避免緩存大key和熱key的出現； |
四 總結
線上事故頻發的原因錯綜復雜，技術漏洞、運營環境挑戰及系統設計缺陷共同構成了主要威脅。通過細致分類與深入分析，我們歸納出八大高危問題域，為后續的防范工作指明了方向。
面對挑戰，我們應以前人經驗為鑒，積極學習并應用成熟的解決方案，不斷優化技術、提升管理、強化安全意識，從而有效規避潛在風險，確保線上環境的穩定與高效運行。
最后，希望本文對讀者有所啟發和幫助。
