系統出了故障，第一個挨板子的就是運維人員。不管任何原因，先找運維，給他一口好鍋。運維好苦啊！穩定運行時，似乎是多余的存在；有問題時，要替人背鍋。與其被動，不如主動一點，不做背鍋俠！

怎么做呢？先看幾個例子，親身經歷。

砸鍋例一

一支付系統，前端負載均衡，中間tomcat應用，后端memcached加oracle 11G rac兩節點集群。遇上好的時機，公司的業務增長很快，但人手有限，跟不上業務的發展，只好盡可能的先上線，發現問題再修正。

某天，在西四環幫人排查賓館wifi故障，樓里手機信號極差。還沒查出什么原因，技術就打電話來質問：“你配的oracle最大連接數，真有3000個么？怎么到300就卡死了？”。趕緊跑到室外，坐在地上用手機打開wifi熱點，用筆記本連數據庫，load確實很高。還沒查出什么原因，那邊老板也來電話催促，說業務無法交易。我想，反正無法交易，不如把tomcat停一下，看數據庫負載是不是會降下來。在征得同意以后，關掉killall -9 java 關閉tomcat，片刻orace負載下降明顯；再啟動時，負載狂飆，最高可到600多。

對oracle的一些配置進行了檢查，性能未能得到任何改善。于是跟開發人員進行溝通，問他們近期是否做了項目更新？答復是肯定的，但無法確定是哪里的問題引起性能上的問題。我建議在應用服務器上安裝某性能監控探針，獲得許可，很快就部署完畢。等待10來分鐘，數據就出來了。

說明：本圖不是事發時截取的，僅僅是為了方便讀者了解。
一幫人緊急召集到一塊，從性能探針的管理頁面找出最耗資源的sql語句進行代碼還原（程序員來查這個代碼是什么功能）。一番動作之后，告知是后臺管理操作--運營人員及代理商查詢當日交易數據，由于產品設計上的缺陷，只要數十人同時進行此項操作，數據庫就會直接掛起。

這個后臺設計上的缺陷主要有一下幾點：

管理后臺登陸時，會查詢所有代理商的數據，代理商會查詢下級代理商的數據。而不管是哪一級的登陸，都會順帶查詢其下最終用戶的數據。如此疊加，產生巨大的數據查詢量。

數據的統計，不是字段值做數學運算，而是以 select count() 的方式進行。這比單獨做一個表，把字段值做數學運算要耗資源。

不管有無需要，都抓取最終用戶的交易詳情。總用戶數有300多萬，運營人員一打開統計，就會去查詢這些記錄；代理商也是這樣，只不過記錄數會少一些，但多人操作，就會重復查詢，給數據庫造成巨大的壓力。

負責技術的老總坦承，其實大部分管理，最關心的是總額，很少去挨個查看詳情。如果需要查看，再按一定條件去執行這個操作。

弄清了問題，程序員馬上去落實，更新代碼以后，問題得以徹底的解決。

砸鍋例二

夏初的時候，上線了一個區塊鏈媒體項目。預估到流量會比較可觀，不僅采購的云主機配置高，而且還是多臺，并且購買了負載均衡服務。

可萬萬沒想到，項目一上線，還沒做任何宣傳，集群中所有服務器的負載都飚得老高，load接近1000，還好沒死機，還能遠程ssh登陸。

這步，一有問題，一口鍋就飛來了，非說是系統配置上的問題。好吧，先把鍋背上，忍辱負重檢查各種配置。

查php配置php-fpm.conf，各種參數都改一下。

查數據庫狀態，mysql > show full processlist； 好多連接呢，不懂業務，不知道這些sql是啥用途，不管了，先保留下來吧。

查web訪問日志，滾得飛快，似乎有馬達在拉著轉。看來問題在這里了，心里想，這么頻繁的請求，會不會是受到了×××？從日志與網絡層面分析，又不像是這種情況。

問題得不到有效的緩解，只好跟相關人員進行溝通，要了app的下載地址，然后在手機上進行安裝。安裝好以后，打開app，底部三個菜單項“快訊、行情、我的”。“快訊”菜單有四個欄目。

我試著拿手指往上滑，信息一直能顯示出來，而且看不到那種正在加載的轉圈存在。結合web訪問日志，我大致可以判斷，應該是一次性把所有的信息都從數據庫里進行抓取，不管這樣是否合理（一般只看前1-2屏）；另外，也可推斷其它菜單或者欄目的內容，也很可能是一下子全抓取出來，管它需不要要展示。

有了這個發現，立即聯系開發人員，詢問是不是數據抓取一抓到底，而且是一秒鐘抓好多次（好多個板塊一起抓）?答復：“確實如此，因為急著上線，沒做太多考慮”。這中間，我也曾對nginx的并發數做限制，每秒限制5次；負載是降低了不少，但app卻基本不能訪問。結合訪問日志及這次限制，可以肯定同一個app同一秒鐘要抓二十幾次，邏輯上肯定不合理。

終于可以把這口鍋扔給開發，讓他們改進，問題得以最終解決。

砸鍋例三

昨天夜里，天氣涼爽，想著能睡個好覺。10點左右，有哥們呼叫，說某個項目又罷工了。這個項目是一個在線租賃服務，由nginx + tomcat 構成，運行了兩個tomcat實例。一直以來，經常出現502故障，公司花了錢做推廣，老出問題影響不好。登上系統，做了如下處理：

修改tomcat內存限定；

修改tomcat啟動賬號為www（以前是root啟動）；

設置crontab計劃任務，讓tomcat每天凌晨4點重啟一次；

監控網站url。
做了這些處理以后，穩定了好一陣。聽到項目又罷工，心里一驚。趕緊登上去，手工重啟tomcat，進程是存在了，但系統日志catalina.out卻拋出異常，用瀏覽器訪問，仍然是502錯誤。

執行w指令，發現還有別的人登陸到系統，就在微信群問是不是有人干活。有人回答：“正在發新版”。你發版提前打個招呼啊！出問題了，不吱聲，讓我在那里白費勁。

懷疑新發的包有問題，重復傳了幾次，問題依然存在。于是開發扔一句話：“可能tomcat壞了”！這判斷有點武斷，tomcat沒人亂動，一般不會壞的。

我耐著性子，進入到項目的目錄 webapps,下邊有三個目錄，程序員說它上傳的文件在ROOT下：

既然如此，我試著把除ROOT外的兩個目錄移走，萬一有問題，再恢復回來。重啟tomcat，恢復正常，tomcat日志也不拋出異常。

我仔細檢查目錄ROOT及 yzuqin-m目錄里邊的配置，特別是應用連接數據庫的字串。兩個項目連接的數據庫各不相同，詢問程序員哪個是正確的。得到答案之后，再分析日志，可知每次啟動，關聯的項目卻不是ROOT目錄下的。

經驗總結

干運維不僅要對系統、應用有較好的把控，而且還需要了解業務。曾經很長一段時間，自己也是不喜歡關注業務，連服務器上運行的是什么都不知道（最多知道是網站而已，具體是什么性質的，一概不關心）。如果花時間了解一下業務邏輯，再結合系統，幾個方面進行排查，處理故障的效率要高很多，而且很多情況下，把那口不屬于自己的鍋給砸碎，變成咱們去幫助其它技術人員解決問題，且不快哉！

技術專欄《負載均衡高手煉成記》已經全部完工，獨具慧眼的您，將會發現這是經驗之談、實踐出真知。這里邊有我的想法、思路、觀點。也許這些觀點不那么準確，甚至可能有些不正確，但也許對您是有幫助的。

總結

以上是生活随笔為你收集整理的做不背锅的运维（文末有彩蛋！）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。