在華為的時候自己帶過幾年的團隊，團隊的規模從一開始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點我們是沒有做好的。
1、防呆設計： 並不是說運維的同學自己呆，而是避免使用的人犯錯誤。我們自己把日志調級別的功能放在控制台上，跟蹤日志一打開全打開。
2、可定位能力差: 運維同學本來想自己定位解決，但是沒有人告訴他怎么定位，開發同學告訴他怎么看，但是開發同學並不知道他會在生產環境定位。當系統中某個功能失效的時候，除了開發人員以外，基本沒有人能定位。
從華為來到阿里以后，發現如果再重新設計這塊的話，又會有不同的思路。對於可定位能力，我們可以全息日志采集，將每個用戶在整個系統的走向異步的抓取下來，再同步到專門的日志分析系統，在這個系統中可以根據用戶號碼、訂單號進行過濾分析。其次是防呆設計，這個在實際中很難完全避免，但是還是可以做一些工作，比如將開關和配置分級別，一些開關定義為P1,一些不重要的開關定義為P3,重要的開關只有個別人才能打開等等。
第二起事故大概是在2012年，海外某國反饋登錄系統時會非常的慢，同樣是在深夜去了網吧，這次算是比較順利，很快的發現是某個慢SQL拖慢了， 這個SQL類似於select count(0) from user,經過分析發現是由於Oracle判斷這個表是不是大表，如果判斷大表，有一堆邏輯，感興趣的同學可以自行在網上搜索。巧的是這張表大概幾百萬的數據，正好在Oracle判斷大表的條件的外點，如果不是大表，Oracle會全表掃描，這一全表掃描速度就下降很厲害，加上我們的業務訪問量很大，表現出來就是新用戶登錄很慢。
當時想着先解決問題，如果按華為的流程我們肯定是違規的，但是在巨大的壓力下，解決掉問題是首要的。我們分析發現這個功能其實是判斷當前已經注冊多少用戶，但是實現的方案很傻，每次登錄的時候都去select count(0)。想到快速解決的方法，就是把這個sql干掉，於是我們不遠萬里把這個jar拖到本地，把這個sql改掉，再讓一線運維的同學上傳上去，重啟解決。這個路子很野，但是當你面臨棘手問題時，能解決問題就是很辦法。
后面還有很多，后續我會慢慢的說來...