監視・ログ・バックアップ・セキュリティの詳細設計｜全3回・第3部

この記事は「詳細設計で決めること」全3回シリーズの第3部です。

本シリーズでは、詳細設計を「構築・テスト・運用できる形」に落とし込む工程として、全3回に分けて整理しています。

【第1部】詳細設計とは何を決める工程か
詳細設計とは何を決める工程か／パラメータ表で終わらせないための設計の考え方
【第2部】OS・Web/APサーバ・DB・ジョブの詳細設計
OS／Web・APサーバ／DB／ジョブの4領域
【第3部】この記事
監視／ログ／バックアップ・リストア／セキュリティ／運用スクリプトの5領域

第2部・第3部では、各記事の後半にあたる詳細解説をnote（有料）で公開しています。

第1部では、詳細設計を単なるパラメータ表ではなく、基本設計で決めた方式を構築・テスト・運用・保守へ接続する工程として整理しました。

第2部では、その考え方をOS、Web/APサーバ、DB、ジョブの4領域に展開しました。

第3部にあたるこの記事では、監視、ログ、バックアップ・リストア、セキュリティ、運用スクリプトの5領域を扱います。

これらは、システムを「作る」工程よりも、「運用する」工程に深く関わる領域です。設計時点では正しく見えても、実際の業務データが入り、本番相当の運用サイクルが回り始めて初めて問題が見えてくる領域でもあります。

各章は独立して参照できます。ただし、第1部の品質保証ストーリーと第2部の設計観点を踏まえて読むと、各論点の背景が理解しやすくなります。

詳細設計で具体化する主な領域
1. 5. 監視詳細設計

詳細設計で具体化する主な領域

5. 監視詳細設計

監視詳細設計では、システムの異常をどのように検知し、誰に通知し、どのように一次対応へつなげるかを具体化します。

監視対象、監視方式、監視間隔、閾値、重大度、通知先、通知方法、抑止条件、メンテナンス時の扱い、一次対応手順との対応などが対象です。

監視詳細設計では、監視項目を増やせばよいわけではありません。

本当に検知すべき異常を、運用で対応できる形で検知することが目的です。

この「本当に検知すべき異常を見極める」という点で、最も設計が難しい領域がログ監視です。

前編で、詳細設計は「どこを試験で確認し、どこを運用監視で検知するかを説明できる状態にする」工程だと整理しました。ログ監視は、その考え方が最も問われる領域の一つです。

なぜなら、監視条件の正しさは、設計時点では確認できないからです。

設計時点では、システム全体に本番相当の負荷がかかっているわけではありません。業務データも十分に入っていないことが多く、日次処理、月次処理、ピーク時のトランザクション、本番相当の運用操作もまだ十分に流れていません。

そのため、監視対象のエラーログに、本来検知すべきメッセージが設計時点で出ているとは限りません。

`error`、`fail`、`fatal`、`exception` といったキーワードをベンダー確認や製品マニュアルをもとに監視条件へ入れることはできます。しかし、そのキーワードを含むログが、本当にアラートとして通知すべき異常なのか、あるいは製品やミドルウェアが通常運転の中で出力する無視可能なメッセージなのかは、設計時点だけでは判断しきれないことがあります。

システムテスト以降、業務データが入り、日回し、月回し、本番に近いトランザクションが流れるようになると、初めて大量のログメッセージが出てきます。

その中には、確実に検知すべきエラーもあります。
一方で、エラーのように見えても運用上は無視してよい標準的な出力もあります。

この見極めをしないまま本番稼働すると、運用開始後に大量のアラートが発生します。