幾回印象深入的網上事故

　　在華爲的時候本身帶過幾年的團隊，團隊的規模從一開始10多我的，到後來40多我的，負責的產品也從一個到多個產品，我本身的性格特色只能作一個小主管，作不了大領導，由於在遇到事情的時候，我總但願本身可以衝在最前面，也就是噹噹班長之類吧，因此我本身處理過不少次的網上事故的處理，當時和我一塊兒處理事故的同窗有的換了部門，有的離職，可是當時一幕幕經歷就像剛發生過，在這裏列舉2~3個吧。

　　華爲對於網上事故很是的重視，基本上若是我的的話致使網上事故的話，一年基本就白乾了，二年內不少調薪、股票這些基本和你無關了，因此任什麼時候候只要出現網上問題你們的精神都是高度緊張，而像我這樣一我的負責幾個產品，每一個產品在網上都有不少局點的小主管，手機24小時開機，常常懷疑手機響了本身沒聽見。

　　我來華爲第1次三級事故大概是在2011年左右，有一天晚上大概10點左右，有一個海外M國打來的電話說P系統手機首頁有時會打不開，這時M國正好是下午，正處在業務的高峯期。我讓一線的維護同窗先用三板斧的重啓，發現剛重啓的好的幾分鐘是好的，可是一會就不行了。我聯繫了此項目的開發&PM W同窗，我和W同窗約好了一塊兒找一個網吧。爲何會去網吧呢？由於在那個時候辦公網絡經過一層一層跳板機訪問國外的網絡不只不方便，並且很是的慢，反而外面的網吧訪問這些地方速度更快。到了網吧之後，很快的就登到遠程的服務器，發現此次遇到的問題和咱們之前的問題都不同，以往最多的就是CPU太高、內存耗盡或者數據庫鏈接過多，機器一旦重啓之後幾分鐘就像整個世界忽然變慢同樣，爲何會忽然變慢？這時已經到了晚上12點左右，從報問題已經近2個小時了，咱們2我的在煙霧繚繞的網吧裏已經江郎才盡。個人手機由於一直開着免提電用完了，W同窗的手機接着上，電話會議裏面研發、一線行銷、運維、機關領導、RL等，這時我最擔憂的事情仍是發生了，一線報事故了，報完事故之後，個人手機剛充完電，個人領導的領導給我打了幾個電話，要求務必儘快解決問題。網吧裏的人愈來愈少，而我和W同窗仍然毫無頭緒，電話會議上找了網絡、存儲、操做系統的專家，可是由於別人不瞭解咱們的業務，也由於不是他的產品，每每給幾句建議就下了，沒有別人能夠幫你，只有你本身。

　　因而我和W同窗又從新整理思路，分析每個異常的點，終於在凌晨1點左右，發現一個日誌打印的量超過正常，咱們前面其實找到了磁盤IO Wait明顯不正常，可是沒有找到爲何不正常？總想着是否是業務量太大，磁盤IO到了瓶頸了，而沒有想到有一個日誌文件打印的量太大。因而咱們在網上找了一些命令，發現大部分的IO等待都是寫這個日誌致使的，爲何這樣日誌的量這麼大呢？原來是跟蹤日誌的開關被調成了debug級別，先調回到error級別再找緣由，終於在近凌晨2點左右將血止住了。接下來咱們又花了10個小時左右分析爲何會致使這個問題，次日中午12點左右咱們離開了網吧，W同窗回去休息，而我要回公司開始接受挨批，由於在個人產品出事故了。緣由的分析咱們花了10個小時，是由於要搞清楚什麼開關會被調成debug,咱們查詢了最近全部發布的版本都出廠的開關都是error,怎麼也不可能，直到早上6點多，一個一線的運維同窗告訴我，他昨天作了一個操做，而這個操做正是無心中打這個開關打開，而他打開的目的是想收集一個數據，這個數據收集是由於一個外包的同窗告訴他這是最快的方式。至此整個事故產生的鏈路很清晰了:

　　一線運維的A同窗接到用戶的投訴說某號碼沒法訪問  --> A同窗想本身解決，因而找了開發此版本的合做方的S同窗 --> S同窗指導其打開跟蹤日誌根據號碼查詢 --> A同窗在線上業務高峯期間打開了此開關且忘記關掉此開關 --> 業務高峯期間跟蹤日誌量太大，阻塞了寫日誌的線程，而寫日誌是同步操做 --> 全部http請求的線程阻塞在IO操做上 --> 全部線程都耗盡業務中斷。

　　以後一個月的時間個人時間都在回溯這個事故，暫且不分析爲運維同窗人爲的錯誤，至少2點咱們是沒有作好的。

　　一、防呆設計： 並非說運維的同窗本身呆，而是避免使用的人犯錯誤。咱們本身把日誌調級別的功能放在控制檯上，跟蹤日誌一打開全打開。

　　二、可定位能力差: 運維同窗原本想本身定位解決，可是沒有人告訴他怎麼定位，開發同窗告訴他怎麼看，可是開發同窗並不知道他會在生產環境定位。當系統中某個功能失效的時候，除了開發人員之外，基本沒有人能定位。

　　從華爲來到阿里之後，發現若是再從新設計這塊的話，又會有不一樣的思路。對於可定位能力，咱們能夠全息日誌採集，將每一個用戶在整個系統的走向異步的抓取下來，再同步到專門的日誌分析系統，在這個系統中能夠根據用戶號碼、訂單號進行過濾分析。其次是防呆設計，這個在實際中很難徹底避免，可是仍是能夠作一些工做，好比將開關和配置分級別，一些開關定義爲P1,一些不重要的開關定義爲P3,重要的開關只有個別人才能打開等等。

　　第二起事故大概是在2012年，海外某國反饋登陸系統時會很是的慢，一樣是在深夜去了網吧，此次算是比較順利，很快的發現是某個慢SQL拖慢了， 這個SQL相似於select count(0) from user,通過分析發現是因爲Oracle判斷這個表是否是大表，若是判斷大表，有一堆邏輯，感興趣的同窗能夠自行在網上搜索。巧的是這張表大概幾百萬的數據，正好在Oracle判斷大表的條件的外點，若是不是大表，Oracle會全表掃描，這一全表掃描速度就降低很厲害，加上咱們的業務訪問量很大，表現出來就是新用戶登陸很慢。

     當時想着先解決問題，若是按華爲的流程咱們確定是違規的，可是在巨大的壓力下，解決掉問題是首要的。咱們分析發現這個功能實際上是判斷當前已經註冊多少用戶，可是實現的方案很傻，每次登陸的時候都去select count(0)。想到快速解決的方法，就是把這個sql幹掉，因而咱們不遠萬里把這個jar拖到本地，把這個sql改掉，再讓一線運維的同窗上傳上去，重啓解決。這個路子很野，可是當你面臨棘手問題時，能解決問題就是很辦法。

　　後面還有不少，後續我會慢慢的說來...