「監視」に疲れ切っていませんか？
業務のシステムを運用していると、しばしば遭遇するのが障害です。機器の故障や過剰な負荷など、原因は様々ですが、ある日突然に壊れるわけです。
運用業務のタスクとして「監視」がありますが、これは継続的、定期的にシステムの状態を観測することで、システムの価値を維持するための作業です。
「監視」業務では、メトリックス（ある時点でのシステムの状態）、ログ（発生したイベント）、トレース（トランザクションの処理の過程）に注目するわけですが、しばしば監視業務は疲弊すると言われています。
大きな理由としては
(1)無視していいアラートが多くある、
(2) トラブル対応が特定の人任せになっているケースが指摘されています。
ビッグデータブームの際にも指摘されていますが、メトリクスやログが多ければ多いほど良いという考えで、あれこれと設定を加えている場合です。データを増やして満足してしまうケースなのですが対応が必要が無いものまで受信をすることで、いわゆる「アラート疲れ」を起こします。重要なアラートの見逃し事故に繋がります。
(2)について、オンコール担当が決まっていなかったり、特定の人に依存している場合、その人が対応出来ない場合に、障害対応が進まないといったケースです。
「監視」業務の設計は経験が必要な所もありますが、意図の無い監視は関係者を疲弊させます。設計の段階では、少なくとも以下のような項目を決めます。
・モニタリングの目的
・モニター対象のリソース
・モニターの頻度
・問題発生時の通知を誰が受信し、どのように対応するか
また、監視データは分類し、対応要否や通知手段などを設定します。特に観点は無いが参考情報として記録しておきたいだけのものは、いちいち通知をしないようにします。また最近の監視ツールは同じ通知の送信を抑制する機能が付いたものも増えています。
「監視メッセージの受信がシンドイ」人は、まずは「対応が必要なものだけ送信する」という基準で設定見直しをお勧めします。
