歡迎光臨
每天分享高質量文章

要做一個不背鍋的運維~~

作者:田逸(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、資料庫、運維等。

赞(0)

分享創造快樂