談談業務系統的監控報警

幾年前，我半途接手負責了一個開發團隊，當時這個團隊作的業務系統屬於金融行業。系統的開發、測試都快結束了，這個系統的功能仍是挺複雜的，子系統3、四個，定時任務也很多，依賴的第三方系統也好幾個。

和這個團隊熟悉以後，我和你們說，咱們須要對這個系統作監控報警（監控報警的名字叫法不少），監控報警是業務系統的金鐘罩，對業務系統很是重要。當時有些人對監控報警沒有概念，更感受不到重要性，估計可能還有一些人認爲我是新官上任三把火，一時說說而已。大部分人仍是認爲，產品的需求我都實現了，並且也有測試人員把關，開發何須給本身找額外的活兒。

的確，在咱們作一個軟件系統的時候，常常會遇到上面相似的現象：從接到需求開始，開發人員廣泛會認爲設計的功能都作完了，各類測試也經過了，最後也部署上線了，就算交差了，就萬事大吉了。包括我本身，在我參加工做的頭幾年也是這麼認爲，並且是以爲這是理所固然的。其實呢，這種認識是很片面的，上線以後仍然要對系統負責任。爲何這麼說呢？

由於，不存在不出問題、沒有Bug 的系統。系統上線以後，就免不了出現故障，出故障是或早或晚的事，是或多或少的事。

咱們能作的是，出現故障以後，第一時間知道，趕忙處理，防止影響擴大。再理想點，若是故障出現以前，剛有苗頭的時候，咱們就能發現，提早解決就更好了。業務系統的監控報警，就是幹這個用的。

繼續說接手的那個金融業務系統，系統上線以後，果真各類問題沒少出，開發人員忙的焦頭爛額，很是被動。我一邊給你們繼續灌輸監控報警的重要性，一邊開始搭建監控報警。一點點的把你們從被動變主動，問題愈來愈少。給大家說幾個印象深入的經歷、體會。

1. 最多見的就是用戶碰到Bug

不管你測試的多麼充分，都不敢保證系統沒有Bug，只是 Bug 還沒出現。雖然 Bug 避免不了，可是做爲開發人員，須要從運營或者客服人員那裏知道出現 Bug，這就有問題了。用戶碰到 Bug，用戶找客服，客服再找開發，你想一想這個過程有多慢，效率有多低。若是用戶都懶得找客服反映，開發也不知道，那這個 Bug 會影響多少用戶？

後來經過代碼埋點、響應碼、異常處理等等，基本作到了：開發人員能第一時間知道Bug。知道以後快速解決，該上線就上線。

2. 有些問題能夠在出現以前就發現

當時出過這麼一個問題，咱們一個功能須要調用一個第三方的接口，當時第三方說 一、2 秒以內能返回結果，聯調的時候也確實是很快能返回結果，因而咱們把超時時間設置成了5 秒，也就是說超過 5 秒尚未返回，就認爲調用第三方接口失敗。這已經在 2 秒的基礎上，又多留了 3 秒餘地。上線之初一直沒有問題，可是過了幾個月以後，常常出現調用第三方接口失敗的問題。通過查緣由，發現都是由於接口超時引發的，原來是第三方的響應比之前變慢了不少，常常會超過 5 秒。

知道緣由以後就很好解決了。解決問題以後，咱們查歷史，發現響應時間也不是忽然變慢的，從 1 秒、2 秒、3 秒……慢慢漲上去的。若是當初，咱們對響應時間進行監控，在接近 5 秒的時候就主動預警，主動聯繫第三方進行調整，那麼這個問題就不會出現了。

3. 要依賴第三方，可是不要過度信賴第三方

除了上面那段提到的以外，咱們這個業務系統依賴的第三方系統還好幾個。第三方系統也是人作的，也會出問題，它們出問題，咱們也跟着受影響，影響到咱們的用戶，用戶就認爲是咱們系統的問題，解釋也沒啥用。

怎麼讓第三方對咱們的影響最小呢？一是，同一個服務，儘可能多接幾家第三方，而後咱們本身作個路由。就算是其中一家掉鏈子了，咱們能快速切換到另一家。另外，咱們本身主動檢測第三方的服務，在用戶使用高峯到來以前，本身主動發起幾筆業務，測測第三方的服務是否正常。對咱們系統來講，越是重要的第三方服務（例如支付），越應該作好預防工做。

4. 咱們開發的系統，用戶用着卡不卡

系統出現Bug、故障，還有一個因素也容易讓用戶崩潰：「系統太卡」，例如點一個按鈕半天沒反應，刷新一個頁面須要很長時間。形成系統卡的緣由有不少，有的能夠經過提升服務器配置解決，有的能夠經過優化數據庫和SQL 解決，有的能夠經過優化代碼來解決。只要能發現系統慢，能大概定位到緣由，基本就有辦法進行優化。

咱們系統上線後沒多久就把這塊歸入了監控範圍。先是搞清楚了系統高峯時段，再就是，從用戶角度出發，記錄每一個功能服務的響應時間，發現慢的及時優化。注意，必定是按照用戶角度去觀測，不要只看單個服務的響應時間，或者單條SQL 的執行時間，由於有的功能包含了多個服務，或者多個 SQL 執行。單獨看服務或者SQL 都不慢，可是合在一塊兒，總時間可能就很長。

5. 報警的方式靈活多樣

監控到問題以後，怎麼報警給開發人員呢？咱們作監控報警的時候，不少人說作個系統，能夠在系統上看，解決以後作好記錄。我說咱們的目的是要讓開發人員及時看到，若是沒登陸系統不就看不到了嗎。作事情必定要牢記作事的目的，不要只關注作事的方式。郵件、短信、微信、QQ 均可以通知開發人員出問題了，並且短信、微信、QQ 的實時性比作的系統更好。

後來咱們的作法是，重要的問題使用短信、微信進行通知，不過重要的問題用郵件通知。爲了防止有人看不到，通常同時多通知幾我的，能夠互相提醒。到最後，咱們也沒有作個系統，就靠着郵件、短信、微信這些，運轉的也還能夠。

除了上面說的，監控報警還包括不少內容，好比監控服務器的存儲、內存、CPU這些最最最基礎，最最最重要的，這些通常都有專業的人來作這塊（我不專業就沒多寫）；還好比監控定時任務有沒有執行；還好比有沒有人故意搞系統的下發短信，等等。監控報警的叫法、實現方式也有不少種，不用太糾結，「黑貓白貓，抓到老鼠就是好貓」。

工做年頭越長，我越感受到監控報警的重要（也多是越老越慫），由於業務系統出現故障的代價太大了。若是這個系統是給互聯網用戶用的，那麼出現Bug，哪怕是用戶感受很卡，均可能形成用戶流失。這年頭獲取一個用戶愈來愈貴，就這麼垂手可得的把客戶送走，實在是太惋惜了。固然不是說，不是面向互聯網用戶的系統，就能夠出問題，無論是給誰用的系統出了問題，作爲開發人員你的臉上都不光彩吧。

業務系統的監控報警不出彩，是幕後英雄。監控報警不只僅是個系統，更重要的是，能體現咱們作事的態度和責任心。

以上的內容但願大家看了以後可以承認。