まず、イベントの重要度やセベリティ(緊急度)に基づくフィルタリングを行う。重要度が低く、緊急の対応が不要なものはフィルタをかけて通知されないようする。
次に、イベントの内容によるフィルタを適用する。検知されたイベントが誤検知である場合もあるため、運用されている環境に応じて、ソースとなる機器に基づいてフィルタリングを行う。
発生頻度の低いイベントが発生した場合にも、その都度フィルタを設定し、重要かつ危急な対応が必要なものだけが通知されるようにメンテナンスを行う。一方で、重要なイベントがフィルタリングされている可能性もあるため、定期的に全イベントの見直し、フィルタの確認を行うことも重要だ。
なお、フィルタリングの重要性は認識されていても、通知されたイベント内容と対になる「対応マニュアル」が用意されていない場合が多い。しかし、マニュアルが存在せず、「データベースのトラブルはAさん、ファイアウォールのトラブルはBさんしか対応できない」といった極端に属人性が高い状況では、初動対応が遅くなるばかりでなく、担当者が長期休暇や出張もできない状況になってしまう。したがって最低限、過去に発生したトラブルの対処方法や問題の切り分け方法をまとめたマニュアルや、対応履歴(運用記録)を用意するべきだろう。
今回の記事では「監視」と「検知」についていくつかポイントを紹介したが、検知後の「判断」「対応」も非常に重要である。事前にフローを作成することの重要性については言及したが、フローは、運用を行っている組織の実態と方針(ポリシー)に基づいて作成しなければならない。例えば、
は連動している必要がある(図3)。
レベル | 概要 | 例 |
---|---|---|
高 | 明らかに事業に支障が出る障害 | 致命的なアプリケーションの不具合が発生した |
二重化されたデバイスのフェイルオーバーに障害が発生した | ||
中 | 一部の事業や業務に支障が出る障害 | 二重化されたデバイスの片系に障害が発生した |
SLAに関連しないアプリケーションの不具合が生じた | ||
低 | 限定的で、事業に具体的な支障が発生しない障害 | 検証環境のハードウェア障害が発生した |
エスカレーション先 | 連絡者 | レベル高 | レベル中 | レベル低 |
---|---|---|---|---|
スーパーバイザー | 担当者より連絡 | 10分 | 2時間 | 8時間 |
マネージャ | スーパーバイザーより連絡 | 15分 | 4時間 | ― |
部長 | マネージャより連絡 | 15分 | ― | ― |
関連部署 | スーパーバイザーより連絡 | 15分 | ○ | ― |
サポートベンダー | 担当者より必要に応じて連絡 | △ | △ | △ |
また、人によって重要度の分類基準が異なっている場合もあるので、最低限、事前にチーム内で実例を交えて重要度分類の基準についてコンセンサスを取っておくようにする。そして可能であれば、本番を想定した訓練を実施するとよりだろう。
ここまで紹介した内容が、実際に運用を行っている方の役に立てば何よりである。運用担当者の中には、「何をいまさら当たり前のことを言っているんだ」と思われる方もおられると思うが、当たり前のことを長期にわたり継続して行うには、それなりの労力と創意工夫が必要である。運用において最も重要なことは、当たり前のことを継続して行うことに尽きるという点を強調し、まとめとしたい。
■佐藤功陛
Copyright © ITmedia, Inc. All Rights Reserved.