不要なアラートを回避する2つのフィルタ：もう一度システム運用を考える（2）

前回は、システム運用の現場が陥りがちな３つの状況―増えるアラート、手順、クラウドについて説明しました。今回はその最初、障害発生で「増えるアラート」について、どのように対処していくべきかを考えてみます。

現場が疲弊する3つの脅威：もう一度システム運用を考える（1）
https://un4navi.com/automation/20088/

なぜアラートが増えるのか？

そもそも、システムを監視する目的は、システムの健全性をチェックすること。監視は、『やむを得ず停止しなければならない場合も、安全に止める』ことを設計思想として、想定されるすべてのリスクを検知できるように設定されます。
しかし、実際の監視設定を見てみると、本当に必要か疑問に感じる内容はありませんか？例えば、ログ監視であれば、システムエラーログをすべて検知条件にしたり、Webアプリケーションのアクセスログを全部監視していないでしょうか。
これでは、早期検出したところで確認作業に追われてしまい、肝心の復旧作業が後手に回ってしまいます。とはいえ、逆に条件を絞りすぎると、検知漏れが起きてシステム停止を招くリスクを抱えてしまうのも事実。こういったジレンマを抱えている以上、監視設定の数を減らしたとしても、限界があります。

システム運用の一部である監視とは？具体的に何を監視すべきか？
https://un4navi.com/management/19045/

アラート削減にも限界があるなら

アラートは削減したいものの、想定されるリスクはすべてカバーしなければならない。この相反するニーズを、どうしたら満たせるか？
本来なら、アラートの検出条件を適正化するのが理想ですが、これには多大な労力が掛かります。その理由は、発生する可能性がある事象をすべて把握した上で、検出条件を見直す作業が発生するから。大抵の場合、システム運用部門がシステム構築やアプリケーションを実装しているわけではないので、リバースエンジニアリングが必要になります。しかし、日々の業務で逼迫している運用現場で、そんな時間はとてもありません。
ところで、発生したアラートに対して、皆さんは何をしていますか？そもそも見ていない、なんて場合も！？恐らく多くの方々は、アラートの内容から、システムのどこでどのような異常が出ているかを確認しているはずです。優秀なエンジニアなら同時に、『きっとこれは作業影響だろうな』とか『これは○○の復旧アラートだな』、『同じアラートが大量に出ているのは、ネットワーク障害か』といったように、原因を推測しているでしょう。ある程度、運用に慣れているシステムなら、その読みは大抵、当たっていませんか？もしそうなら、そんな「分かりきったアラートを見る作業」は本当に必要なんでしょうか？

繰り返しますが、異常をもれなく検知するためにシステムの監視は必要です。しかし、対象機器や時間帯などの条件に基づいたアラートの仕分け、内容の確認作業が不要なものは、事前に判定できるはず。このように、不要な確認作業を工夫することが、運用現場の負担を軽減する糸口となります。

＜PR＞監視設定やシステムの見直しは厳しくても、統合運用管理サービス「UOM」ならすぐに結果に表れます！
SaaS型だから、ビジネススケールに合った機能で選んで、導入の手間やコストも最適化。詳しくはこちらへ

2つのフィルタ、要否判定と重複排除

では、具体的に実現する方法の一つとして、UOM（IIJ 統合運用管理サービス）のフィルタリング機能を例に説明しましょう。このフィルタリング機能は、UOMの標準機能として提供されていて、「要否判定」と「重複排除」から構成されます。

UOMでは二つのフィルタを通して、チケット生成によるアラート通知を行います。

まず要否判定は、事前に設定した許可リスト（allowlist）に基づいて、不要なアラート通知を機械的に除外します。アラートを機械的に自動仕分けできるので、人手による負担を大幅に減らせます。許可リストには、対応が必要なアラート通知を登録しておきます。一般的なシステム運用設計では、全てのアラートを受けるという考え方ですが、UOMの考え方は、受けるアラートのみを明示的に指定するといった、ファイアウォールのポリシー設定と同等の思想です。また、UOMには、アラート通知を一時的にOFFにする機能があります。事前に登録したアラート通知において、メンテナンスなど予めアラート発生が予測されるものの、対応が不要なアラートについては、該当する条件（監視対象、時間帯）を指定することで、アラートを通知しない仕組みです。これを、UOMでは「対応停止申請」と呼んでいますが、普段は通知されるアラートを一時的に止めておく、柔軟な操作が可能です。重複排除は、同じ時間帯に同様のアラート通知が発生した場合には、一通のアラート通知にまとめてしまう機能です。例えば、ネットワークやデータベースなどの障害は、その特性として同じ時間帯に同様のアラートが多数発生することがあります。このような場合は、5分単位で重複するアラートを排除できます。

無駄な通知を整理して、重要なアラートにのみ集中

人材も限られていて毎日忙しい現場では、監視設定の見直しが重要だとわかっていても、その時間がなかなか割けません。だったら、発生するアラートを振り分ける基本から着手するのはどうでしょうか？発生アラートすべてを処理するのではなく、対応が必要なアラート通知のみにどうやって絞るか。この考え方をシステムで実現したのが、現場のニーズに基づいてエンジニアが開発したUOMのフィルタリング機能です。要否判定や重複排除を上手く使えば、多忙な現場でも、できるところから業務改善をスタートできます。

次回は、「増える手順」についてお話しします。手順書は運用の要ともいえる要素ですが、これをどう改善していくか。更新にご期待ください。

UOM（IIJ統合運用管理サービス）
https://www.iij.ad.jp/biz/uom/

現場が疲弊する３つの脅威 ｜ もう一度システム運用を考える（１）
https://un4navi.com/automation/20088/

＜PR＞要否判定と重複排除を使えば、アラート通知もシンプルかつ確実になって、エンジニアの負担も減らせます。
今すぐ、SaaS型の統合運用管理サービス「UOM」で、システム運用を自動化・効率化！詳しくはこちらへ