近期頻繁收到上游系統介接連線異常的告警簡訊，今天早上 7 點不到，還在睡夢當中，又傳來 2 次告警，奇妙的是每次告警後約 2~3 分鐘，馬上緊接著又傳了個連線正常的簡訊來，很明顯地就是 false alarm，相同 case 從上星期六到今天，已經發生 4 次。
上班後，很客氣地寫了封 email 通知上游系統開發單位，說明近期頻繁發生 false alarm 的情形，也說明 false alarm 頻繁可能的缺點與造成的困擾，請他們「確認」。負責人也真如我所述「照辦」，查了 log 直接貼錯誤訊息，就回覆我說確認有 HTTP 503 錯誤發生，所以才會觸發告警，後面就沒了。
我的本意是想請他們改善流程，或調整觸發告警的 threshold，減少 false alarm 發生的頻率 (這不是看到我的 mail 就該意會過來的嗎？還是我要求太高？)，避免告警效果打折扣，也降低對我的不必要干擾。但不好意思侵犯外單位自主權，很客氣地只用「確認」作為我 mail 的請求文字。
因對方負責人「直來直往」，我只好又回信，稍稍「越俎代庖」地指導說當然是有錯誤才會觸發告警，但我的重點是這些都是 false alarm，能否「評估、調整」觸發的 threshold，並以早上例子分析，他們系統應是每 2~3 分鐘 check 一次連線狀態，但有時可能因網路連線品質不穩或我這邊 server 暫短 overloading，就會發生 check 失敗，實際上管道狀態是正常的 (下一次 check 又正常可證明)，建議是不是提高告警觸發標準，例如連續 check 錯誤達一定次數或 check 不到正常狀態達一定時間，才觸發告警。
我的本意是舉出一種可能作法，實際上如何修正還是請對方自己思考、評估，沒想到對方也不另作考量，負責人就直接回信說，如果要改成連續 check 失敗達幾次才觸發告警，他們系統要修改很多地方，他們內部要再討論看看再決定。
講太少、不直接，別人不會意識到存在他們該去解決問題，別人的主管也默不吭聲；講多了、太明白，別人當成這 solution 是你提的，屆時有問題、沒做好風險評估產生其它新問題，源頭也是你。
幫別人訓練新人，真難！
上班後，很客氣地寫了封 email 通知上游系統開發單位，說明近期頻繁發生 false alarm 的情形，也說明 false alarm 頻繁可能的缺點與造成的困擾，請他們「確認」。負責人也真如我所述「照辦」，查了 log 直接貼錯誤訊息，就回覆我說確認有 HTTP 503 錯誤發生，所以才會觸發告警，後面就沒了。
我的本意是想請他們改善流程，或調整觸發告警的 threshold，減少 false alarm 發生的頻率 (這不是看到我的 mail 就該意會過來的嗎？還是我要求太高？)，避免告警效果打折扣，也降低對我的不必要干擾。但不好意思侵犯外單位自主權，很客氣地只用「確認」作為我 mail 的請求文字。
因對方負責人「直來直往」，我只好又回信，稍稍「越俎代庖」地指導說當然是有錯誤才會觸發告警，但我的重點是這些都是 false alarm，能否「評估、調整」觸發的 threshold，並以早上例子分析，他們系統應是每 2~3 分鐘 check 一次連線狀態，但有時可能因網路連線品質不穩或我這邊 server 暫短 overloading，就會發生 check 失敗，實際上管道狀態是正常的 (下一次 check 又正常可證明)，建議是不是提高告警觸發標準，例如連續 check 錯誤達一定次數或 check 不到正常狀態達一定時間，才觸發告警。
我的本意是舉出一種可能作法，實際上如何修正還是請對方自己思考、評估，沒想到對方也不另作考量，負責人就直接回信說，如果要改成連續 check 失敗達幾次才觸發告警，他們系統要修改很多地方，他們內部要再討論看看再決定。
講太少、不直接，別人不會意識到存在他們該去解決問題，別人的主管也默不吭聲；講多了、太明白，別人當成這 solution 是你提的，屆時有問題、沒做好風險評估產生其它新問題，源頭也是你。
幫別人訓練新人，真難！
No comments:
Post a Comment