知識星球作者：田逸（sery）
來自：http://blog.51cto.com/sery/2162642
系統出了故障，第一個挨板子的就是運維人員。不管任何原因，先找運維，給他一口好鍋。運維好苦啊！穩定執行時，似乎是多餘的存在；有問題時，要替人背鍋。與其被動，不如主動一點，不做背鍋俠！
怎麼做呢？先看幾個例子，親身經歷。
砸鍋例一
一支付系統，前端負載均衡，中間tomcat應用，後端memcached加oracle 11G rac兩節點叢集。遇上好的時機，公司的業務增長很快，但人手有限，跟不上業務的發展，只好盡可能的先上線，發現問題再修正。
某天，在西四環幫人排查賓館wifi故障，樓裡手機訊號極差。還沒查出什麼原因，技術就打電話來質問：“你配的oracle最大連線數，真有3000個麼？怎麼到300就卡死了？”。趕緊跑到室外，坐在地上用手機開啟wifi熱點，用筆記本連資料庫，load確實很高。還沒查出什麼原因，那邊老闆也來電話催促，說業務無法交易。我想，反正無法交易，不如把tomcat停一下，看資料庫負載是不是會降下來。在徵得同意以後，關掉killall -9 java 關閉tomcat，片刻orace負載下降明顯；再啟動時，負載狂飆，最高可到600多。
對oracle的一些配置進行了檢查，效能未能得到任何改善。於是跟開發人員進行溝通，問他們近期是否做了專案更新？答覆是肯定的，但無法確定是哪裡的問題引起效能上的問題。我建議在應用伺服器上安裝某效能監控探針，獲得許可，很快就部署完畢。等待10來分鐘，資料就出來了。
說明：本圖不是事發時擷取的，僅僅是為了方便讀者瞭解。
一幫人緊急召集到一塊，從效能探針的管理頁面找出最耗資源的sql陳述句進行程式碼還原（程式員來查這個程式碼是什麼功能）。一番動作之後，告知是後臺管理操作–運營人員及代理商查詢當日交易資料，由於產品設計上的缺陷，只要數十人同時進行此項操作，資料庫就會直接掛起。
這個後臺設計上的缺陷主要有一下幾點：
1、管理後臺登陸時，會查詢所有代理商的資料，代理商會查詢下級代理商的資料。而不管是哪一級的登陸，都會順帶查詢其下終端使用者的資料。如此疊加，產生巨大的資料查詢量。
2、資料的統計，不是欄位值做數學運算，而是以 select count() 的方式進行。這比單獨做一個表，把欄位值做數學運算要耗資源。
3、不管有無需要，都抓取終端使用者的交易詳情。總使用者數有300多萬，運營人員一開啟統計，就會去查詢這些記錄；代理商也是這樣，只不過記錄數會少一些，但多人操作，就會重覆查詢，給資料庫造成巨大的壓力。
負責技術的老總坦承，其實大部分管理，最關心的是總額，很少去挨個檢視詳情。如果需要檢視，再按一定條件去執行這個操作。
弄清了問題，程式員馬上去落實，更新程式碼以後，問題得以徹底的解決。
砸鍋例二
夏初的時候，上線了一個區塊鏈媒體專案。預估到流量會比較可觀，不僅採購的雲主機配置高，而且還是多臺，並且購買了負載均衡服務。
可萬萬沒想到，專案一上線，還沒做任何宣傳，叢集中所有伺服器的負載都飈得老高，load接近1000，還好沒宕機，還能遠端ssh登陸。
這步，一有問題，一口鍋就飛來了，非說是系統配置上的問題。好吧，先把鍋背上，忍辱負重檢查各種配置。
1、查php配置php-fpm.conf，各種引數都改一下。
2、查資料庫狀態，mysql > show full processlist； 好多連線呢，不懂業務，不知道這些sql是啥用途，不管了，先保留下來吧。
3、查web訪問日誌，滾得飛快，似乎有馬達在拉著轉。看來問題在這裡了，心裡想，這麼頻繁的請求，會不會是受到了×××？從日誌與網路層面分析，又不像是這種情況。
問題得不到有效的緩解，只好跟相關人員進行溝通，要了app的下載地址，然後在手機上進行安裝。安裝好以後，開啟app，底部三個選單項“快訊、行情、我的”。“快訊”選單有四個欄目。
我試著拿手指往上滑，資訊一直能顯示出來，而且看不到那種正在載入的轉圈存在。結合web訪問日誌，我大致可以判斷，應該是一次性把所有的資訊都從資料庫裡進行抓取，不管這樣是否合理（一般只看前1-2屏）；另外，也可推斷其它選單或者欄目的內容，也很可能是一下子全抓取出來，管它需不要要展示。
有了這個發現，立即聯絡開發人員，詢問是不是資料抓取一抓到底，而且是一秒鐘抓好多次（好多個板塊一起抓）?答覆：“確實如此，因為急著上線，沒做太多考慮”。這中間，我也曾對nginx的併發數做限制，每秒限制5次；負載是降低了不少，但app卻基本不能訪問。結合訪問日誌及這次限制，可以肯定同一個app同一秒鐘要抓二十幾次，邏輯上肯定不合理。
終於可以把這口鍋扔給開發，讓他們改進，問題得以最終解決。
砸鍋例三
昨天夜裡，天氣涼爽，想著能睡個好覺。10點左右，有哥們呼叫，說某個專案又罷工了。這個專案是一個線上租賃服務，由nginx + tomcat 構成，運行了兩個tomcat實體。一直以來，經常出現502故障，公司花了錢做推廣，老出問題影響不好。登上系統，做瞭如下處理：
1、修改tomcat記憶體限定；
2、修改tomcat啟動賬號為www（以前是root啟動）；
3、設定crontab計劃任務，讓tomcat每天凌晨4點重啟一次；
4、監控網站url。
做了這些處理以後，穩定了好一陣。聽到專案又罷工，心裡一驚。趕緊登上去，手工重啟tomcat，行程是存在了，但系統日誌catalina.out卻丟擲異常，用瀏覽器訪問，仍然是502錯誤。
執行w指令，發現還有別的人登陸到系統，就在微信群問是不是有人幹活。有人回答：“正在發新版”。你發版提前打個招呼啊！出問題了，不吱聲，讓我在那裡白費勁。
懷疑新發的包有問題，重覆傳了幾次，問題依然存在。於是開發扔一句話：“可能tomcat壞了”！這判斷有點武斷，tomcat沒人亂動，一般不會壞的。
我耐著性子，進入到專案的目錄 webapps,下邊有三個目錄，程式員說它上傳的檔案在ROOT下：
既然如此，我試著把除ROOT外的兩個目錄移走，萬一有問題，再恢復回來。重啟tomcat，恢復正常，tomcat日誌也不丟擲異常。
我仔細檢查目錄ROOT及 yzuqin-m目錄裡邊的配置，特別是應用連線資料庫的字串。兩個專案連線的資料庫各不相同，詢問程式員哪個是正確的。得到答案之後，再分析日誌，可知每次啟動，關聯的專案卻不是ROOT目錄下的。
經驗總結
乾運維不僅要對系統、應用有較好的把控，而且還需要瞭解業務。曾經很長一段時間，自己也是不喜歡關註業務，連伺服器上執行的是什麼都不知道（最多知道是網站而已，具體是什麼性質的，一概不關心）。如果花時間瞭解一下業務邏輯，再結合系統，幾個方面進行排查，處理故障的效率要高很多，而且很多情況下，把那口不屬於自己的鍋給砸碎，變成咱們去幫助其它技術人員解決問題，且不快哉！
●編號202，輸入編號直達本文
●輸入m獲取文章目錄
Python程式設計
更多推薦《18個技術類微信公眾號》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
