同事：『你知道我們的服務其實一直沒有很好的監控嗎？』
我：「我知道呀！我們現在有什麼監控？」
同事：『現在只有紀錄排程執行完畢的時間，有 API 可以看，你有在看嗎？』
我：「當然沒有呀（燦笑）」
同事：『我也不會（燦笑）』
然後兩個人就被主管抓去埋起來了...

這是今天下午剛發生的對話，要是被主管聽到應該會被狠 K 一頓吧！其實我們主管也沒有那麼不盡人情啦，他也知道我們的系統當初是因為緊急而生，所以有點缺漏是正常的，但重要的是要記得補上，對吧！?於是我們便繼續討論要怎麼補...

同事：『那你覺得該怎麼補？』
我：「嗯...」
同事：『做個服務狀態頁面如何？』
我：「好像也可以」
我：「阿～不然跳 telegram 好了，telegram 我都會開著，有訊息馬上就知道了」
同事：『也可以』
我：「不過我有個要求，有問題的再跳就好了，不要送那些幾點幾分什麼背景執行完畢的」
我：「訊息太多一下子就麻痹不想看了，我們可以做哪種偵測上次執行距離現在已經超過太久的，再跳通知就好」

其實我覺得透過通訊軟體接收監控是很不錯的一個選擇，但其實在人生就是在不斷的被拒絕後，找到希望（1/5）這篇裡面，有說到維運工程師認為不喜歡通訊軟體來通知，比較喜歡網頁可以自動出現告警聲音。咦？那篇說要用網頁，但這篇有說要跳通訊軟體，你搞得我好亂呀 > <

會有差異是因為部門不同，維運同仁本身對外窗口多，訊息也多，透過通訊軟體比較容易因為洗頻而不見，所以喜歡有網頁，可以開在公用螢幕上，當出現異常時，直接告警提示，他們抬頭就可以看到狀況，比較方便實用。但我跟同事都是開發團隊的人，訊息量比較少，也沒有可常駐開啟的公用螢幕，所以選擇使用通訊軟體。

今日文章最想傳遞了，除了開發跟維運部門間會選擇不同的方式來達到監控的目的，更重要的是如果選擇使用通訊軟體來做監控訊息傳遞的話，那傳送訊息的設計就很重要，如果像我說的是當訊息是設計成「Ｏ分Ｏ秒執行完成」，訊息看久了，很容易就痲痹，然後下一個會做的動作就是關閉通知...

所以為了避免造成這樣的無效通知，訊息應該被設計成，當真的有異常的時候，才發送訊息，這樣才不會因為訊息太頻繁，看到最後就變成無用的通知了。