幾年前，我半途接手負責了一個開發團隊，當時這個團隊做的業務系統屬於金融行業。系統的開發、測試都快結束了，這個系統的功能還是挺復雜的，子系統三、四個，定時任務也不少，依賴的第三方系統也好幾個。
和這個團隊熟悉之后，我和大家說，我們需要對這個系統做監控報警（監控報警的名字叫法很多），監控報警是業務系統的金鍾罩，對業務系統非常重要。當時有些人對監控報警沒有概念，更感覺不到重要性，估計可能還有一些人認為我是新官上任三把火，一時說說而已。大部分人還是認為，產品的需求我都實現了，而且也有測試人員把關，開發何必給自己找額外的活兒。
的確，在我們做一個軟件系統的時候，經常會遇到上面類似的現象：從接到需求開始，開發人員普遍會認為設計的功能都做完了，各種測試也通過了，最后也部署上線了，就算交差了，就萬事大吉了。包括我自己，在我參加工作的頭幾年也是這么認為，而且是覺得這是理所當然的。其實呢，這種認識是很片面的，上線之后仍然要對系統負責任。為什么這么說呢？
因為，不存在不出問題、沒有Bug 的系統。系統上線之后，就免不了出現故障，出故障是或早或晚的事，是或多或少的事。
我們能做的是，出現故障之后，第一時間知道，趕緊處理，防止影響擴大。再理想點，如果故障出現之前，剛有苗頭的時候，我們就能發現，提前解決就更好了。業務系統的監控報警，就是干這個用的。
繼續說接手的那個金融業務系統，系統上線之后，果然各種問題沒少出，開發人員忙的焦頭爛額，非常被動。我一邊給大家繼續灌輸監控報警的重要性，一邊開始搭建監控報警。一點點的把大家從被動變主動，問題越來越少。給你們說幾個印象深刻的經歷、體會。
1. 最常見的就是用戶碰到Bug
無論你測試的多么充分，都不敢保證系統沒有Bug，只是 Bug 還沒出現。雖然 Bug 避免不了，但是作為開發人員，需要從運營或者客服人員那里知道出現 Bug，這就有問題了。用戶碰到 Bug，用戶找客服，客服再找開發，你想想這個過程有多慢，效率有多低。如果用戶都懶得找客服反映，開發也不知道，那這個 Bug 會影響多少用戶？
后來通過代碼埋點、響應碼、異常處理等等，基本做到了：開發人員能第一時間知道Bug。知道之后快速解決，該上線就上線。
2. 有些問題可以在出現之前就發現
當時出過這么一個問題，我們一個功能需要調用一個第三方的接口，當時第三方說 1、2 秒之內能返回結果，聯調的時候也確實是很快能返回結果，於是我們把超時時間設置成了5 秒，也就是說超過 5 秒還沒有返回，就認為調用第三方接口失敗。這已經在 2 秒的基礎上，又多留了 3 秒余地。上線之初一直沒有問題，但是過了幾個月之后，經常出現調用第三方接口失敗的問題。經過查原因，發現都是因為接口超時引起的，原來是第三方的響應比以前變慢了很多，經常會超過 5 秒。
知道原因之后就很好解決了。解決問題之后，我們查歷史，發現響應時間也不是突然變慢的，從 1 秒、2 秒、3 秒……慢慢漲上去的。如果當初，我們對響應時間進行監控，在接近 5 秒的時候就主動預警，主動聯系第三方進行調整，那么這個問題就不會出現了。
3. 要依賴第三方，但是不要過分信賴第三方
除了上面那段提到的之外，我們這個業務系統依賴的第三方系統還好幾個。第三方系統也是人做的，也會出問題，它們出問題，我們也跟着受影響，影響到我們的用戶，用戶就認為是我們系統的問題，解釋也沒啥用。
怎么讓第三方對我們的影響最小呢？一是，同一個服務，盡量多接幾家第三方，然后我們自己做個路由。就算是其中一家掉鏈子了，我們能快速切換到另外一家。另外，我們自己主動檢測第三方的服務，在用戶使用高峰到來之前，自己主動發起幾筆業務，測測第三方的服務是否正常。對我們系統來說，越是重要的第三方服務（例如支付），越應該做好預防工作。
4. 我們開發的系統，用戶用着卡不卡
系統出現Bug、故障，還有一個因素也容易讓用戶崩潰：“系統太卡”，例如點一個按鈕半天沒反應，刷新一個頁面需要很長時間。造成系統卡的原因有很多，有的可以通過提高服務器配置解決，有的可以通過優化數據庫和SQL 解決，有的可以通過優化代碼來解決。只要能發現系統慢，能大概定位到原因，基本就有辦法進行優化。
我們系統上線后沒多久就把這塊納入了監控范圍。先是搞清楚了系統高峰時段，再就是，從用戶角度出發，記錄每個功能服務的響應時間，發現慢的及時優化。注意，一定是按照用戶角度去觀測，不要只看單個服務的響應時間，或者單條SQL 的執行時間，因為有的功能包含了多個服務，或者多個 SQL 執行。單獨看服務或者SQL 都不慢，但是合在一起，總時間可能就很長。
5. 報警的方式靈活多樣
監控到問題之后，怎么報警給開發人員呢？我們做監控報警的時候，很多人說做個系統，可以在系統上看，解決之后做好記錄。我說我們的目的是要讓開發人員及時看到，如果沒登錄系統不就看不到了嗎。做事情一定要牢記做事的目的，不要只關注做事的方式。郵件、短信、微信、QQ 都可以通知開發人員出問題了，而且短信、微信、QQ 的實時性比做的系統更好。
后來我們的做法是，重要的問題使用短信、微信進行通知，不太重要的問題用郵件通知。為了防止有人看不到，一般同時多通知幾個人，可以互相提醒。到最后，我們也沒有做個系統，就靠着郵件、短信、微信這些，運轉的也還可以。
除了上面說的，監控報警還包括很多內容，比如監控服務器的存儲、內存、CPU這些最最最基礎，最最最重要的，這些一般都有專業的人來做這塊（我不專業就沒多寫）；還比如監控定時任務有沒有執行；還比如有沒有人故意搞系統的下發短信，等等。監控報警的叫法、實現方式也有很多種，不用太糾結，“黑貓白貓，抓到老鼠就是好貓”。
工作年頭越長，我越感覺到監控報警的重要（也可能是越老越慫），因為業務系統出現故障的代價太大了。如果這個系統是給互聯網用戶用的，那么出現Bug，哪怕是用戶感覺很卡，都可能造成用戶流失。這年頭獲取一個用戶越來越貴，就這么輕而易舉的把客戶送走，實在是太可惜了。當然不是說，不是面向互聯網用戶的系統，就可以出問題，不管是給誰用的系統出了問題，做為開發人員你的臉上都不光彩吧。
業務系統的監控報警不出彩，是幕后英雄。監控報警不僅僅是個系統，更重要的是，能體現我們做事的態度和責任心。
以上的內容希望你們看了之后能夠認可。