救火隊員的那些事(1)

　　「預防勝於救火」，道理都懂，可是當面臨成本、時間等壓力時，最易被放棄的就是質量，在HW作過不少次這樣的事情，雖然每次壓力山大，可是收穫頗多。

　　分享的第一個案例是咱們的產品在08年因爲中標了印度某運營商， 中標之後，這個項目就由印度的同事交付以及維護，這個項目每月可以給運營商帶來幾百萬美刀的收入，加上項目是合營的，利潤仍是不錯的。因爲印度同事對產品的理解不夠深刻，以及產品自己代碼質量並不高，因此在08年年末交付之後，網上問題一直不斷，可是由於利潤還不錯，因爲印度人本身和本身人打交道，因此質量問題一直沒有成爲Top 1的問題。

　　可是09年的時候這個項目的甲方的高層領層換了人，換個領導之後就會把這個事情擺上檯面，甚至提出這些質量問題若是不解決的話，後續的合同不續簽。

　　印度的同事由於對產品接觸的時間才一年多，我雖然接觸也才2年，可是由於我在國內接觸的資料會比他們多一些，加上我在當時的團隊裏技能稍微好一些，因而領導就把這個「僞專家」給拋出去了。萬事開頭難，和印度的同事除了語言他們那很是重的口語我常常聽不懂之外，還有他們作了近2年的定製開發，不少功能已經和最先的產品已經不同了，怎樣在短時間內快速的解決明顯的問題，我內心真是沒有底，不知道本身能不能完成這個任務。

　　接到任務之後，和他們郵件、電話作了充分溝通之後，瞭解到他們最突出的問題：網上運行不穩定，以致於他們天天晚上安排一個兄弟把集羣裏每一個機器挨個重啓一遍，這樣大部分狀況下可以確保能跑一天，可是天天這麼重啓也不是辦法。在和他們商量之後，計劃分2步走:

　　一、止血: 先確保不用天天手工的重啓

　　二、在實驗室環境搭建一樣的環境，將主要流程在實驗室進行壓測，重現問題。

　　第一針止血，他們的要求很簡單，就是不要天天半夜起來人工重啓。這個要求簡單，用perl寫了一個watchdog的腳本，這個腳本原理很簡單，可是發揮了很重要的做用。由於它不只可以發現服務掛掉，它還能收集大量的信息快照並打包，這樣天天把重啓的記錄進行分析，可以更加準確快速的分析問題。watchdog判斷重啓有2個條件，一個是cpu的使用率若是持續100%,在判斷cpu的使用率的時候，並不能直接用vmstat或者top,而是讀取/proc/stat,由於這裏能讀取到每個cpu的使用率，有時即便一個cpu一直是100%也是有問題的，另外還有一個條件就是判斷心跳的頁面了。重啓前會收集gc、內存、日誌、磁盤io等全部可能的信息。這個perl腳本總共應該不超過80行代碼，可是後來我在不少地方都用到了。其實咱們的系統也有watchdog的，可是發現這個watchdog有時本身也會被hang住，因此用這個腳本單獨的進程更加穩定一些，後面咱們的產品也的按個人這個想法從新設計了watchdog.

　　有了watchdog之後，發現致使重啓的不少時候緣由是由於數據庫鏈接不夠了，而致使鏈接不夠了，要麼是慢sql,要麼是一些查詢語句太過頻繁，性能比較差，一點點的優化，發現watchdog重啓的頻率愈來愈低了。

　　第二就是在實驗室中作性能測試了，咱們收集了典型的場景作了壓測，主要發現的問題是一些流程性能比較低，好比像頁面展現的動態廣告，每次實時查詢數據庫，而每一個頁面不論是否展現廣告都會進行一些複雜的邏輯計算以及數據庫的查詢。通常的方式都是可以異步的操做，異步操做。好比廣告的點擊量數據，其實沒那麼高實時性，咱們改爲天天晚上後臺統計算一次，展現的時候直接查詢，而不是每次渲染頁面實時的進行查詢。

　　有了第一針的止血，加上第二招的實驗室測試，前先後後大概一個月左右的時間，逐漸的穩定下來，本身在這過程當中學習瞭如何看awr報告，如何用linux命令定位性能問題，如何用LoadRunner性能測試。穩定之後，寫了一篇總結給印度的同事，這個事情基本算告一段落了，對了，09年的國慶節我沒有休息，全陪印度的同事在搞這個了。