前言
最近碰到乙個生產問題，整個處理過程讓我不禁想起幾年前碰到的乙個類似情景，但是結果卻完全不一樣。兩次問題說大不大，說小不小。這次由於我們處理及時，大事化小小事化了而已，然而幾年前的那次事件，卻由於多方原因，鬧得挺大，驚動了某會。由此引發的一些思考和總結吧。
問題回顧
排查思路
生產出現這種效能問題要求運維人員首先就要有個可能的原因分析，由於以前正常，近期突然出現的故障，原因可以從以下方面著手
1.是否存在網路延遲
2.是否近期有變更
3.傳送端延遲還是接收端延遲
4.檢視傳送記錄資料是否未建立索引
前三點如果查詢問題原因，耗時一般比較長，因為網路問題一般比較難追蹤，而且如果近期有變更的還涉及開發人員的排查**邏輯，延遲源頭和網路問題差不多，而生產問題的第一要務是要快速止血。當然也要相關團隊引起足夠重視，否則會耽誤救命的時間。
問題分析
所以我們團隊首先從資料入手，既然是發簡訊驗證碼慢，那麼就找到驗證碼的記錄表，找到這個客戶的資料，直接通過plsql查詢都很慢，而且是有索引的，一看錶的資料量快上億了，所以很明顯是量變引起了質變，再仔細分析裡面資料發現有大量的異常資料，此塊後期找開發人員去排查和優化此處不提。
問題解決
找到問題原因，並經評估此表僅記錄傳送結果資料，重要性不是很高，所以在備份完資料後，直接刪除表資料，就解決了客訴問題。清資料有個小細節這裡用的是truncate而不是delete，注意要降低表的水位。
整個過程從得知問題到生產問題解決不到5分鐘。然而幾年前的那次問題止血用了30分鐘，並且驚動了監管，現在看來主要原因還是處理問題的環節太多導致。
就像生活中有的時候小朋友出血了第一步就是要想辦法去止血，事後家長再去問醫生或者小朋友為什麼出血或者**，才是最好的求醫問道的方法。
作為金融系統的穩定是每乙個金融企業的重中之重，否則不是被銀監會約談就是被證監會發函。咱們拋開流程管理和技術不談，遇到生產問題，一定要先止血，而且一定要快！而問題原因應該都是事後去分析了，所以生產問題運維人員應該首當其衝，因為他們掌握生產執行程式的一手資源，日誌、資料還有awr報告等，並且應該具備分析和處理的能力，而不是作為開發人員的取數工具。而開發人員在事後問題分析要考慮優化策略，無外乎資料的增刪改查，怎麼才能做到更優？
總而言之，乙個團隊要有向心力，不能開發碰到問題就是讓運維取日誌，要對自己**邏輯做到心中有數，運維人員碰到問題就是讓開發查**也不行，要了解系統架構和表結構，這樣碰到問題才能做的有的放矢，心中不慌！
由乙個typedef問題引發的思考
同樣，可以像下面這樣隱藏指標語法 typedef char pstr intmystrcmp const pstr p1,const pstr p3 用gnu的gcc和g 編譯器，是會出現警告的，按照順序，const pstr 被解釋為 char const 乙個指向char的指標常量 而事實上，c...
乙個事故引發的思考
今天線上服務出現了乙個事故，思考下這個事故，覺得有好幾個地方需要思考。1 對於前端而言，回滾的功能是必須的。前端介面出現了問題，第乙個應該想到的是將 回滾到乙個穩定版本。2 快取和資料庫的使用，需要注意乙個問題，當快取失效的時候，可能會有大併發的請求去訪問資料庫，這個時候資料庫會不會崩潰？如果這個時...
由乙個經典布局問題引發的思考
相信每個前端玩家在初學css的時候都遇到過這麼乙個問題 如何實現乙個三欄布局。假設高度已知，左欄右欄寬度各300px 中間自適應。看似很簡單的乙個問題，但這麼簡單的乙個問題，可以體現出乙個前端玩家的段位水平。初級玩家的回答 1.浮動 2.絕對定位。中級玩家的回答 1.浮動 2.絕對定位 3.flex...