前天使用 updown.io 架設了 status page，並且讓它可以在服務無法連上的時候，自動發通知到 slack 頻道。這便算是一種警報，告訴相關人員說，有一些警急狀況需要處理。

然而僅僅這樣是不夠的，畢竟在實際的環境中，可能會遇到各種狀況導致服務出問題，所以若是在意外發生之前，就能提供我們一些資訊的話，就有機會可以更快的解決問題（或是找出潛在的 bug，在他們實際影響到使用者之前就著手進行修復）。

舉個例子來說，以前 NOJ 曾經遇過一個挺蠢的問題，我們沙盒的 log 把硬碟撐爆了，因為當初 log 寫了太多沒用的資訊（像是這個案例就是把題目的 IO 都記錄下來），最終產生了好幾 GB 的 log 檔，加上沒有做 logrotate，導致整台機器掛掉。然而若是有在硬碟快被塞爆之前，就有發出警報的話，或許就可以避免這次悲劇了。

幾個原則

那麼究竟該怎麼判斷什麼時候該發出警報，這就是一個困難的議題，對於每個不同的專案，可能都會有些不同，但還是有些大方向是可以遵守的。

簡化

在實際運行的服務中，我們可能會監控各式各樣的數值，寫了各種規則去表示「某件事情發生了，需要人力介入處理」。然而若是規則太過於複雜的話，可能會造成它難以維護，複雜的規則通常代表著複雜的邏輯，而複雜的邏輯通常也是難以理解的，當服務本身的需求有變更以至於警報的規則要修改時，可能會是一場辛苦的戰鬥。

應當避免誤報

警報的出現意味著需要人力的處理，然而若是警報常常誤報，便會造成類似童話「狼來了」裡面的放羊的小孩一樣，形成警報疲勞，導致真正的問題發生的時候，被忽略掉而沒有處理造成損失。

所以當一個警報它並不需要立即的處理，或是說僅需要一些機械化的操作便可以解決，那麼我們就不應該浪費寶貴的人力去做這些事情，應該要嘗試使用自動化的方法解決它。

明確的處理流程

當一個警報是需要人工處理的，那麼它應當要有明確的處理流程，確保收到通知的當下，我們知道要如何應對。所以在這部分應當留下良好的文件，避免只有少數人清楚流程，而是讓團隊裡的每個人都知道怎麼做。

小結

這個章節我寫一寫才發現...好像應該先討論監控的，畢竟警報是基於監控得到的數值來設立規則的嘛，所以希望明天我有辦法寫一些有關監控系統的架設與設計指標 (metrics) 的討論。

不過這些主題對我來說就算是非常陌生的議題了，若是有不小心寫錯的地方還請各位多多包涵。