翻看去年處理的乙個案例，發現處理時間挺長的，而且這個案例也有點意思，就再看多兩眼，做個簡單總結。
1. 首先是應用伺服器效能不穩定，排查之後，伺服器是vm，要求加資源，並且所有資源都reserved.
2. 接著就是應用伺服器連線資料庫時很不穩定，資料庫經常報「recovery mode」。好像是資料庫莫名被關閉，導致非常關閉，然後再重啟時處理「recovery mode"。排查之後，發現是資料庫伺服器那邊，會經常把資料庫程序給殺掉。linux有個oom-killer這東西，不看系統日誌，還不好確認它就是根源。
3. 接著就是協助客戶改進資料庫伺服器效能，調整資料庫引數。
4. 之後，處理資料庫空間增大的問題。
現在看來，好像也就寥寥幾句而已。當時環境比較複雜，又不是現場排錯，處理起來比較耗時耗力。還好，客戶很配合，也理解遇到的問題，需要調整的地方都盡量調整。整個過程還算比較順利。
乙個案例引發的思考
今天下午，團隊開了乙個簡短的版本總結會。會上測試經理分析了乙個案例 某子程式在轉測試後發現不能被平台排程，原因是子程式的排程入口跟不符合平台規範。很明顯開發在轉測試前沒有充分自驗證，測試經理提出，後續對跟平台對接的子程式轉測試必須要有將子程式接入平台跑通後的驗證報告和相關checklist，否則不予...
Refactoring 筆記 第乙個案例總結
重構保障 1 建立測試環境 比如單元測試 確保重構後的 不會帶來新的 bugs。重構前提 1 當乙個函式或類履行了太多的職責。2 當乙個變更存在多個相同的修改點。3 當需要為程式新增乙個特性，而 結構使你無法很方便地那麼做。重構原則 1 盡量以最小的步伐修改程式。如果你犯下錯誤，很容易發現它。2 使...
關於溝通問題的乙個案例
我們需要測試乙個安裝包，安裝包中包含了資料庫公升級指令碼，這是測試的乙個重點。我們以前能訪問客戶的一台伺服器，並且在5.2號對資料庫進行了備份，但是在5.3號手動對資料庫進行了一點修改，這些修改是不包含的備份中的。而我們現在不能遠端桌面連線到客戶的伺服器了，這樣我們就沒有乙個真實的資料庫來測試公升級...