[[389984]]

對于節假日，難得的假期，尤其是外出的時候碰上幾個數據庫報警，那些報警又屬于不得不處理的時候，真是讓人上火，所以也想了一些辦法來盡可能杜絕和避免這種情況。

一般來說是這樣的幾種策略：

1)提前在節假日的時候把報警的閾值調低，然后提前處理一波

2)在假期中期，主動進行巡檢分析，至少在可控的時間里碰到問題提前處理比臨時出現問題緊急解決要好得多。

3)多人互備，通常這種情況比較苦逼，得背著電腦到處跑，還得注意電腦電源，網絡

當然也有一些機制可以借鑒，大體也是兩類：

1)對于一些通常可控的處理問題，可以設定周期性任務進行提前處理，比如數據庫的binlog增長較快，可以設置周期性任務來清理，通常定制化，本地化程度較高

2)對于一些可以預見的問題，可以設置處理動作腳本，然后周期性掃描，一旦發現問題就觸發處理機制，所以這種模式通常是會碰到報警/報警恢復的周期性交替。

當然這些策略還不是上策，畢竟不夠通用，有的時候問題還具有差異性，需要差異化處理。

舉個例子來說，磁盤報警，如果磁盤報警在80%，那么問題其實緊急度還沒那么高，處理機制優先處理磁盤空間能搞定最好，如果達到了90%，磁盤空間的清理改進空間就很有限了，就需要清理數據庫日志等，如果繼續增長問題的緊急度就會逐步升級，就需要接入業務邏輯，從一些日志表的數據來入手了。

大多數情況下的問題，通常通過系統空間清理和binlog的清理能夠減緩問題的進一步升級，所以能夠緩沖幾個小時的時間也是很難得的。

和移動端的接入，也是和開發同事進行了深入溝通后集成起來的，這是一套已經穩定運行許久的功能模塊，這方面我們還算是接入相對晚了。

移動端對于磁盤報警的處理，我定義的處理流程如下：

在觸發報警后，在移動端可以對每個處理動作進行處理，后端會有相應的API和腳本進行調用，返回相應的數據參數。

整個流程中，對于報警類別的定義和處理流程的編排是相對核心的步驟。

拆分下來，最細粒度的是每一個處理動作的定義。

后續基本能夠放心的外出，在收到臨時的報警后，心里也會波瀾不驚了。

無論如何，這都是故障自愈的一個好的開始。

本文轉載自微信公眾號「楊建榮的學習筆記」，可以通過以下二維碼關注。轉載本文請聯系楊建榮的學習筆記公眾號。