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

前回は、システム運用の現場で陥りがちな3つの状況について説明しました。今回はその一つ「増えるアラート」について、どのように対処していくべきかを考えていきます。

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

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

システム監視の目的は、システムの健全性をチェックすること。設計思想は安全に倒すことを念頭に、想定しうる全てのリスクを検知できるように監視設定は行われます。しかし、実際の監視設定を見てみると、本当に必要なのだろうか?と疑問に感じることはありませんか?

例えば、ログ監視であれば、システムエラーログをすべて検知条件にしていたり、WEBアプリケーションのアクセスログを監視していたりすることでしょう。これでは、早期検出したところで確認作業に追われてしまい、復旧作業が後手に回ってしまいます。とはいえ、条件を絞りすぎると、検知漏れからシステム停止を招くリスクを抱えてしまうのも事実。こういった事情から、監視設定の数を減らすように見直したとしても、その数には限界があります。

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

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

アラートの削減と、想定しうるリスクを全てカバーすること。これら相反する状況をどう打開していくべきでしょうか。本来ならば、アラートの検出条件を適正化する事が望ましいと感じるかもしれません。しかし、これには多大な労力が必要となります。発生しうる事象をすべて把握し、検出条件を見直す作業が必要となりますが、多くの場合、運用部門ではシステム構築やアプリケーションを実装しているわけではありませんので、リバースエンジニアリングをする必要が出てしまいます。日々の業務で逼迫している運用現場において、この作業を行う時間の捻出は難しいことでしょう。

ところで、発生したアラートに対して、皆さんは何をしていますか?(そもそも見ていない、なんて場合も?!)

おそらく多くの方々は、アラートの内容から、システムのどこでどのような異常が出ているかを確認することでしょう。同時に「きっとこれは作業影響だろうな…」とか「これは○○の復旧アラートだな…」、あるいは「ネットワーク障害か、同じアラートが大量に出ている…」なんて見当をするかもしれません。そして、その読みはたいていの場合、当たっているのではないでしょうか。はたして、そのような「分かりきったアラートを見る作業」は本当に必要なのでしょうか?

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

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

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

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

「要否判定」は、事前に設定した許可リスト(allowlist)に基づいて、不要なアラート通知を機械的に除外します。もし、これまで人手でアラート仕分けしていたのであれば、機械的に除外することで、日々の業務で多忙な運用現場の方々のちょっとしたアシストになるのではないでしょうか。

許可リストには、対応が必要となるアラート通知を登録しておきます。一般的なシステム運用設計では、全てのアラートを受けるという考え方をしますが、この考え方は受けるアラートのみを明示的に指定する、といったファイアウォールのポリシー設定と同等のものです。

また、事前に登録したアラート通知において、メンテナンスなど予めアラート発生が予測されるものの、対応が不要なものについては、該当する条件(監視対象、時間帯)を指定することで、アラート通知を行わない仕組みも設けています。これを、UOMでは「対応停止申請」と呼称しています。対応停止申請により、普段は通知されるアラートを一時的に止めておく、といった操作も可能です。

そして「重複排除」は、同じ時間帯に同様のアラート通知が発生した場合には、一通のアラート通知にまとめてしまう、といった働きをします。例えば、ネットワークやデータベースなどの障害は、その特性として同じ時間帯に同様のアラートが多数発生することがあります。このようなアラートに対しては、5分単位で重複するアラートを排除する機能を提供します。

 

今回は「増えるアラート」にどう対処していくかを考えてみました。監視設定の見直しまでは時間がさけないため、発生するアラートを振り分けてみるのはどうでしょうか?発生アラートに対して、いかに対応が必要なアラート通知のみに絞るか。この考え方をシステムで実現した、UOMのフィルタリング機能。要否判定や重複排除の利用により、多忙な現場でも日々の業務の改善に手を入れてみませんか?

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

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

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

 

関連記事

∞∞∞∞∞∞∞ おすすめ記事 ∞∞∞∞∞∞

  1. システム運用のコスト削減(1)- コストが掛かる理由はコレ

    開発と違い、組織にとっての利益を生み出さず、費用を使うだけの「コストセンター」だと誤解されるシステム…
  2. コレって我が社だけ!?システム「運用」と「保守」ってどう違う?

    現代のビジネスで欠かせないITシステム。システム「運用」や「保守」は、企業の安定した組織運営の重要な…
  3. 正解がない運用設計という「思想」:現場のプロが語ってみる(2)

    IIJの福原です。まずは運用設計の概要だけでもお分かりいただけたでしょうか? 【前回記事】運用設計…
  4. アジャイル開発のメリットとは?システム運用にどう関係する?

    アジャイル開発のメリットとは?システム運用にどう関係する?

    ITシステムの開発スタイル(モデル)は、業界ごとに異なるだけでなく、時代のニーズでも変化し続けていま…
  5. 学びもハックのひとつだ!業務のスキマで少しでも英語力をアップしよう!

    学びもハックのひとつだ!業務のスキマで少しでも英語力をアップしよう!

    業界外の人たちからなかなか理解されない、「毎日、カタカナの専門用語を使っている、英語が苦手なITエン…
ページ上部へ戻る