做不背鍋的運維
怎麽做呢？先看幾個例子，親身經歷。
砸鍋例一
一支付系統，前端負載均衡，中間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登陸。
做不背鍋的運維