※この記事は「詳細設計で決めること」3部作の後編②です。前編・後編①はこちら、本編はnoteで公開しています。
前編では詳細設計の考え方を、後編①ではOS・Web/AP・DB・ジョブの設計観点を整理しました。
後編②では、監視、ログ、バックアップ・リストア、セキュリティ、運用スクリプトの5領域を扱います。これらは、システムを「作る」工程よりも「運用する」工程に深く関わる領域です。設計時点では正しく見えても、実際の業務データが入り、本番相当の運用サイクルが回り始めて初めて問題が見えてくる領域でもあります。
各章は独立して参照できますが、前編の品質保証ストーリーと後編①の設計観点を踏まえて読むと、各論点の背景が理解しやすくなります。
詳細設計で具体化する主な領域
5. 監視詳細設計
監視詳細設計では、システムの異常をどのように検知し、誰に通知し、どのように一次対応へつなげるかを具体化します。
監視対象、監視方式、監視間隔、閾値、重大度、通知先、通知方法、抑止条件、メンテナンス時の扱い、一次対応手順との対応などが対象です。
監視詳細設計では、監視項目を増やせばよいわけではありません。
本当に検知すべき異常を、運用で対応できる形で検知することが目的です。
この「本当に検知すべき異常を見極める」という点で、最も設計が難しい領域がログ監視です。
前編で、詳細設計は「どこを試験で確認し、どこを運用監視で検知するかを説明できる状態にする」工程だと整理しました。ログ監視は、その考え方が最も問われる領域の一つです。
なぜなら、監視条件の正しさは、設計時点では確認できないからです。
設計時点では、システム全体に本番相当の負荷がかかっているわけではありません。業務データも十分に入っていないことが多く、日次処理、月次処理、ピーク時のトランザクション、本番相当の運用操作もまだ十分に流れていません。
そのため、監視対象のエラーログに、本来検知すべきメッセージが設計時点で出ているとは限りません。
`error`、`fail`、`fatal`、`exception` といったキーワードをベンダー確認や製品マニュアルをもとに監視条件へ入れることはできます。しかし、そのキーワードを含むログが、本当にアラートとして通知すべき異常なのか、あるいは製品やミドルウェアが通常運転の中で出力する無視可能なメッセージなのかは、設計時点だけでは判断しきれないことがあります。
システムテスト以降、業務データが入り、日回し、月回し、本番に近いトランザクションが流れるようになると、初めて大量のログメッセージが出てきます。
その中には、確実に検知すべきエラーもあります。
一方で、エラーのように見えても運用上は無視してよい標準的な出力もあります。
この見極めをしないまま本番稼働すると、運用開始後に大量のアラートが発生します。
監視設計で怖いのは、アラートが出ないことだけではありません。アラートが出すぎて、運用者が判断できなくなることも同じくらい危険です。
コメント