システム運用監視とは？主な監視対象と障害対応フローを解説

システム運用監視では、監視ツールの導入だけでなく、異常検知後の対応体制を整えることが重要です。アラートが多すぎると重要な異常を見落とし、夜間・休日には初動対応が遅れるおそれがあります。本記事では、システム運用監視の目的、対象別の監視項目、異常検知後の対応手順、安定運用のための見直しポイントを解説します。

システム運用監視とは？

システム運用監視とは、サーバーやネットワーク、アプリケーションなどの状態を継続的に監視し、異常の検知から初動対応、復旧確認までを管理することで、障害による業務への影響を抑え、システムの安定稼働を支える取り組みです。

この取り組みの対応範囲を把握するには、システム運用監視の目的と、システム監視との違いを整理する必要があります。

• システム運用監視の目的
• システム監視と運用監視の違い

1. システム運用監視の目的

システム運用監視は、異常や障害の兆候を早期に検知し、システム停止と業務影響の拡大を抑えます。監視データとアラートを担当者へ速やかに共有することで、原因調査、一次対応、復旧作業の開始を早められます。

主な目的は、次のとおりです。

• 異常や障害の兆候を早期に検知する
• システム停止や影響範囲の拡大を抑える
• システムの安定稼働と可用性を維持する
• 障害発生時の確認や初動対応を迅速化する
• 運用状況を可視化し、継続的な改善につなげる

監視データと障害履歴は、異常が集中する時間帯、負荷の変化、構成上のボトルネックを特定する基礎情報になります。蓄積したメトリクス、ログ、対応記録を分析すると、しきい値、運用手順、システム構成の改善点を判断できます。

2. システム監視と運用監視の違い

システム監視と運用監視の違いは、異常を検知した後の対応まで対象に含めるかどうかにあります。システム監視は状態の収集や可視化、アラート通知を中心とする一方、運用監視は通知後の確認や対応、復旧、改善までを含みます。

表1: システム監視と運用監視の範囲・業務の違い

システム監視は、運用監視を構成する一部です。監視ツールがアラートを通知するだけでは、障害対応は完了しません。通知後の確認担当者、一次対応の範囲、エスカレーション条件を定義することで、監視情報を復旧作業へつなげられます。

システム運用監視によって防げる主なリスク

監視体制が不十分な場合、異常を検知できても適切な対応につながらず、障害の影響が拡大するおそれがあります。システム運用監視で低減すべき主なリスクは次のとおりです。

• 障害の発見が遅れ、停止時間が長期化するリスク
• 夜間・休日に初動対応が遅れるリスク
• 業務停止や売上機会の損失につながるリスク
• 対応の属人化と同じ障害が繰り返されるリスク

1. 障害の発見が遅れ、停止時間が長期化するリスク

継続的な監視がないと、利用者からの問い合わせで初めて障害に気づく場合があります。アラートと過去の監視データを活用すれば、発生時刻や状態変化を早く把握し、調査と復旧の開始を早められます。

2. 夜間・休日に初動対応が遅れるリスク

手作業の確認だけでは、夜間や休日の異常を見逃すおそれがあります。アラートの受信者、確認時間、一次対応の範囲、エスカレーション条件を決めることで、時間外でも対応を開始しやすくなります。

3. 業務停止や売上機会の損失につながるリスク

システム障害は、サービスへのアクセス不能、取引の中断、社内業務の停滞につながります。異常を早期に検知し、影響する機能や利用者を確認することで、業務への影響や機会損失を抑えやすくなります。

4. 対応の属人化と同じ障害が繰り返されるリスク

対応方法が一部の担当者の経験に依存すると、不在時に判断と復旧が遅れます。手順書、判断基準、障害履歴、再発防止策を共有し、属人的な判断を監視設定と対応フローへ置き換えます。

システム運用監視で確認すべき対象と監視項目

監視範囲としきい値は、システム構成、業務上の重要度、通常時の負荷に応じて設計します。サーバー、ネットワーク、データベース、アプリケーションなどの構成要素を洗い出し、各対象の正常・異常を判定できる監視項目を設定します。

主な監視対象は、次のとおりです。

• サーバー監視
• ネットワーク監視
• データベース監視
• アプリケーション監視
• クラウド・仮想環境監視
• コンテナ監視
• ジョブ監視
• バックアップ監視
• 証明書・各種有効期限の監視
• ログ・メトリクス・トレース

1. サーバー監視

サーバー監視では、OSやホストが正常に稼働し、必要な処理を継続できる状態かを確認します。

• 主な監視項目： CPU使用率、メモリ使用率、ディスク使用量、ロードアベレージ、プロセス・サービスの稼働状態、OS・ホストの死活状態
• 異常の例： CPUやメモリの高負荷が続く、ディスク容量が不足する、プロセスが停止する、サーバーから応答がない
• 一次確認の例： 異常が始まった時刻、負荷の高いプロセス、直前のリリースや設定変更を確認する

2. ネットワーク監視

ネットワーク監視では、サーバーや利用者、外部サービスの間で通信が正常に行われているかを確認します。

• 主な監視項目： 通信遅延、帯域使用率、パケットロス、接続状態、ネットワーク機器の稼働状態、ポートの状態
• 異常の例： 通信が切断される、応答が遅くなる、パケットロスが増える、帯域使用率が急増する
• 一次確認の例： 影響を受けている機器、回線、接続先と、問題が発生している範囲を確認する

3. データベース監視

データベース監視では、データへの接続や検索、更新処理が安定して行われているかを確認します。

• 主な監視項目： 接続数、クエリ応答時間、スロークエリ、ロック・デッドロック、CPU・メモリ・ストレージ、レプリケーション状態
• 異常の例： クエリの応答が遅くなる、接続数が急増する、デッドロックが発生する、レプリケーションが遅延する
• 一次確認の例： 遅延しているクエリ、接続状況、リソース使用量、発生前後の変更内容を確認する

4. アプリケーション監視

アプリケーション監視は、利用者がログイン、検索、決済などの主要機能を正常に実行できるかを確認します。サーバーの死活状態が正常でも、APIエラーや処理遅延によってアプリケーション機能が停止する場合があります。

• 主な監視項目： 応答時間、エラー率、HTTPステータス、API成功率、セッション数、主要機能の稼働状態
• 異常の例： 画面の表示が遅い、エラーが増加する、APIが失敗する、ログインや決済などの主要機能を利用できない
• 一次確認の例： 影響する画面や機能、エラーの発生時刻、関連するAPIや外部サービスの状態を確認する

合成監視（シンセティックモニタリング）は、利用者の操作を定期的に再現します。ログインや検索を自動実行し、画面遷移、応答時間、処理結果を利用者に近い視点で確認します。

5. クラウド・仮想環境監視

クラウド・仮想環境監視は、動的リソースと依存サービスを関連付けます。インスタンス、オートスケーリング、ロードバランサーの状態を構成単位で確認します。

• 主な監視項目： インスタンス・仮想マシンの状態、CPU・メモリ・ストレージ、オートスケーリング、ロードバランサー、サービス使用量、外部サービスとの接続状態
• 異常の例： インスタンスが停止する、スケール処理が実行されない、負荷が偏る、外部サービスとの接続に失敗する
• 一次確認の例： 影響するリソース、スケール状況、負荷分散の状態、依存サービスの稼働状況を確認する

6. コンテナ監視

コンテナ監視では、個々のコンテナやPodに加えて、それらを稼働させるクラスターやノードの状態も確認します。

• 主な監視項目： コンテナ・Podの稼働状態、再起動回数、CPU・メモリ使用量、デプロイ状態、ノードの状態、サービス間通信
• 異常の例： コンテナが繰り返し再起動する、Podが起動しない、リソース不足が発生する、サービス間の通信に失敗する
• 一次確認の例： 異常が発生しているコンテナ、Pod、ノードと、直近のデプロイ内容を確認する

コンテナ・Pod単位の監視

コンテナやPodは短時間で作成・削除される場合があるため、稼働状態、リソース使用量、再起動、エラー情報を継続的に収集します。

クラスター・ノード単位の監視

クラスターやノードでは、リソースの空き状況、ワークロードの配置状態、スケジューリング状況、ノード障害の有無を確認します。

7. ジョブ監視

ジョブ監視では、定期的に実行されるバッチ処理やデータ連携が、予定どおり完了しているかを確認します。

• 主な監視項目： ジョブの成功・失敗、実行開始・終了時刻、実行時間、遅延、未実行、異常終了
• 異常の例： ジョブが開始されない、予定時間を超えても完了しない、異常終了する
• 一次確認の例： 実行履歴、エラー内容、前後のジョブ、入力データや接続先の状態を確認する

ジョブの未実行はシステム停止に直結しない場合もありますが、データ不足や後続業務の遅延につながるおそれがあります。

8. バックアップ監視

バックアップ監視では、処理の成否だけでなく、必要なデータを復元できる状態かを確認します。

• 主な監視項目： バックアップの成否、実行日時、保存先、データ容量、世代管理、リストア可否
• 異常の例： バックアップが失敗する、保存容量が不足する、必要な世代が残っていない
• 一次確認の例： 失敗した処理、対象データ、保存先の容量、直近の正常なバックアップを確認する

バックアップが成功と表示されていても、復元できるとは限りません。定期的にリストアテストを行い、復旧に利用できることを確認します。

9. 証明書・各種有効期限の監視

有効期限切れは、サービス停止や認証エラーを引き起こします。監視対象には、SSL/TLS証明書、ドメイン、ライセンス、APIトークンが含まれます。

• 主な監視項目： SSL/TLS証明書、ドメイン、ライセンス、APIキー・トークン、契約サービスの有効期限
• 異常の例： 証明書やトークンの期限が近づく、契約更新が未完了になる
• 一次確認の例： 対象、期限日、更新担当者、更新に必要な手続きや作業期間を確認する

有効期限監視は、更新に要する期間を逆算して通知します。更新手続き、承認、証明書の切り替えを考慮し、期限日前に複数回アラートを発生させます。

10. ログ・メトリクス・トレース

オブザーバビリティでは、メトリクスで状態変化を捉え、ログで事象の詳細を確認し、トレースで処理経路を追跡します。

メトリクス

メトリクスは、CPU使用率、応答時間、エラー率などの数値を時系列で確認するために使用します。状態の変化や通常時との差を把握するのに適しています。

ログ

ログは、エラーメッセージ、操作履歴、ジョブの実行結果など、発生した事象の詳細を確認するために使用します。

トレース

トレースは、一つのリクエストが複数のサービスをどのように通過したかを追跡するために使用します。処理が遅い箇所やサービス間の依存関係を確認する際に役立ちます。

表2: メトリクス・ログ・トレースの役割比較

異常を検知した後の基本的な対応フロー

デジタル庁『デジタル・ガバメント推進標準ガイドライン』（2025年）は、運用中のインシデント対応と記録・改善を運用管理の対象としています。障害対応フローでは、この考え方に沿って、検知から原因分析までを一連のプロセスとして管理します。具体的には、異常検知、アラート通知、影響範囲の把握、一次切り分け、エスカレーション、復旧確認を連続して実行します。

基本的な対応は、次の段階に分けられます。

• 異常検知とアラート通知
• アラート内容の確認と影響範囲の把握
• 一次切り分けと暫定対応
• エスカレーションと復旧確認
• 原因分析と再発防止

異常検知 → アラート通知 → 内容確認 → 一次切り分け → エスカレーション → 暫定対応 → 復旧確認 → 原因分析 → 再発防止

1. 異常検知とアラート通知

監視対象の状態が設定した条件に該当すると、アラートが発生します。主な検知条件には、しきい値の超過、死活状態の変化、エラーの発生、ジョブの失敗、通常とは異なる傾向などがあります。

担当者が通知を受け取った時点で状況を判断できるように、アラートには少なくとも次の情報を含めます。

• 監視対象
• 発生時刻
• 検知した指標や事象
• アラートの重要度
• 関連するダッシュボードやログ
• 初期確認を行うための手順

監視対象や発生事象が分からないアラートは、一次確認の開始を遅らせます。通知文には対象、発生時刻、重要度、関連ログ、初期手順を含め、受信者が次の行動を判断できる状態にします。

2. アラート内容の確認と影響範囲の把握

アラート受信後は、メトリクス、ログ、死活状態を照合し、実際の障害か誤検知かを判定します。一時的な負荷上昇や監視経路の通信エラーも通知されるため、アラートタイトルだけでは影響度を判断できません。

主に確認する内容は、次のとおりです。

• どのシステムや機能で異常が発生しているか
• 利用者や業務に影響が出ているか
• 問題が一つの構成要素に限られているか
• 複数のシステムやサービスへ影響が広がっているか
• 発生前にリリースや設定変更が行われていないか
• 関連するアラートが同時に発生していないか

影響範囲を整理することで、対応の優先度や連絡すべき担当者を判断しやすくなります。

3. 一次切り分けと暫定対応

一次切り分けでは、ログ、メトリクス、変更履歴などを確認し、問題が発生している領域を絞り込みます。

主な分類例は、次のとおりです。

• インフラ
• ネットワーク
• データベース
• アプリケーション
• 外部サービス

原因をすぐに特定できない場合でも、影響を抑えるための暫定対応が必要になることがあります。たとえば、通信経路の切り替え、承認済み手順に基づく再起動、問題のあるジョブの一時停止、待機系システムへの切り替えなどです。

暫定対応は、事前に承認した権限と手順書の範囲内で実行します。担当者は、再起動、切り替え、ジョブ停止などの操作内容、実施時刻、結果を対応履歴へ記録します。

4. エスカレーションと復旧確認

一次対応で解決できない場合や、影響が大きい場合は、専門部門や責任者へエスカレーションします。

主な判断条件は、次のとおりです。

• 規定時間内に原因を特定できない
• 業務や利用者への影響が大きい
• 高度な専門知識や追加の権限が必要である
• 複数のシステムに問題が発生している
• 情報漏えいやデータ不整合など別のリスクが疑われる

エスカレーション時には、発生時刻、影響範囲、確認済みの内容、実施した対応、現在の状態を共有します。

復旧確認は、アラートの解消だけで正常化を判定しません。主要機能へのアクセス、処理結果、エラー率、データ整合性、関連ジョブ、外部連携まで確認します。監視値と業務機能の両方が基準内へ戻った時点で復旧を判定します。

5. 原因分析と再発防止

復旧後は、障害の経緯と対応内容を整理し、再発防止につなげます。

記録する主な内容は、次のとおりです。

• 異常を検知した時刻
• 対応開始から復旧までの経過
• 直接的な原因と背景要因
• 影響を受けたシステムや業務
• 実施した暫定対応
• 恒久的に必要な対策
• 対応中に判明した手順や体制の問題

原因分析の結果は、監視項目、しきい値、アラート内容、対応手順、エスカレーション条件へ反映します。再発防止では個人の責任ではなく、障害を生んだ構成、手順、権限、連絡体制を修正します。

システム運用監視を運用する手順

システム運用監視は、ツール選定前に運用要件を定義します。運用要件には、監視目的、対象範囲、しきい値、通知先、一次対応、エスカレーション体制を含めます。要件を先に固定すると、監視ツールに収集させるデータと自動化する処理を選定しやすくなります。

導入・運用は、次の手順で進めます。

• 監視の目的と対象範囲を整理する
• 重要度に応じて監視項目としきい値を設計する
• 通知・一次対応・エスカレーション体制を決める
• 手順書と連絡網を整備する
• テスト運用を行い、継続的に見直す

1. 監視の目的と対象範囲を整理する

最初に、システム運用監視によって何を実現したいのかを明確にします。目的が曖昧なまま監視項目を増やすと、必要性の低いアラートが多くなり、重要な異常を判断しにくくなります。

主な目的の例は、次のとおりです。

• 障害や性能劣化を早期に検知する
• 業務停止や利用者への影響を抑える
• 夜間・休日にも異常を把握できるようにする
• 障害発生時の初動対応を迅速化する
• システムの状態や運用実績を可視化する

監視目的を定義した後は、対象システムを構成要素単位で洗い出します。対象には、サーバー、ネットワーク、アプリケーション、データベース、外部サービス、バッチ処理を含めます。各対象に監視項目、管理担当者、依存関係を紐づけることで、監視漏れを防げます。

監視対象ごとに、管理担当者、業務影響、依存関係を記録します。利用部門と停止時の影響を紐づけることで、監視の優先順位を判断できます。

2. 重要度に応じて監視項目としきい値を設計する

監視項目としきい値は、業務上の重要度と通常負荷に応じて設計します。すべてのシステムへ同じ基準を適用すると、不要アラートや見逃しが発生します。

しきい値は、通常時、繁忙時、夜間バッチ時のCPU使用率、アクセス数、応答時間を分けて設定します。基準が厳しすぎると不要アラートが増え、緩すぎると性能劣化や障害の兆候を検知できません。

設計時には、次の情報を確認します。

• 通常時と繁忙時のリソース使用状況
• システム停止が業務に与える影響
• 利用者や処理件数の変動
• 過去に発生した障害や性能低下
• 異常を検知してから対応できるまでの時間

システム監視ツールは、メトリクスとログの収集、ダッシュボード表示、しきい値判定、アラート通知を自動化します。初期設定を固定せず、通常時の負荷、不要アラート、障害履歴を分析して監視項目と通知条件を調整します。

3. 通知・一次対応・エスカレーション体制を決める

通知先と対応方法が未定義のアラートは、初動対応を遅らせます。監視対象と重要度ごとに、通知先、確認期限、一次対応、エスカレーション先、最終判断者を割り当てます。

決めておく主な内容は、次のとおりです。

表3: 通知・一次対応・エスカレーション体制で決める項目

一次対応の範囲は、担当者が実行できる確認、再起動、切り替えと、実行してはいけない操作を分けて定義します。権限と禁止事項を手順書へ記載すると、判断待ちと未承認操作の両方を抑えられます。

4. 手順書と連絡網を整備する

運用手順書は、アラート受信後の判断と作業を標準化します。担当者がログ確認、影響範囲の判定、一次切り分け、暫定対応、エスカレーションへ進める内容にします。システム構築者以外でも同じ判断ができるように、確認画面、コマンド、判断基準、禁止事項を具体化します。

手順書に含める主な項目は、次のとおりです。

• 対象システムの構成と役割
• アラートごとの確認項目
• 関連するログやダッシュボード
• 一次切り分けの手順
• 実施可能な暫定対応
• エスカレーション先と判断条件
• 復旧を確認する方法
• 実施してはいけない作業

連絡網には、担当者名だけでなく、所属部門、役割、連絡手段、対応可能な時間帯を記載します。担当者の異動や組織変更があった場合に備え、更新責任者と見直し時期も決めておきます。

5. テスト運用を行い、継続的に見直す

本番運用を開始する前に、アラートが想定どおり発生し、担当者へ届き、定めた手順で対応できるかを確認します。

テストでは、次の内容を確認します。

• 設定した条件でアラートが発生するか
• 正しい担当者へ通知されるか
• 夜間・休日の通知経路が機能するか
• 手順書を見ながら一次確認を行えるか
• 必要なタイミングでエスカレーションできるか
• 復旧後に正常化を確認できるか

テスト運用後は、通知されなかった異常、対応に時間がかかった工程、判断しにくかった手順などを整理します。また、対応不要だったアラートが多い場合は、しきい値や通知条件を調整します。

システム運用監視を安定させるための注意点

システム運用監視を安定させるには、監視設定、対応手順、担当体制を実際の障害履歴とシステム変更に合わせて更新します。見直す項目は次のとおりです。

• 監視項目やしきい値を増やしすぎない
• アラートの重要度と通知ルールを整理する
• 手順書・構成情報・連絡先を最新に保つ
• 夜間・休日を含む対応体制を確認する
• システム運用監視の効果を定期的に確認する

1. 監視項目やしきい値を増やしすぎない

監視項目が多いほど、運用の品質が高まるとは限りません。対応につながらない指標や過度に厳しいしきい値を設定すると、不要なアラートが増え、重要な異常を見分けにくくなります。

監視項目を選ぶ際は、次の観点で優先度を判断します。

• サービスや業務へ直接影響するか
• 異常を検知した後に具体的な対応ができるか
• 原因の切り分けに役立つか
• ほかの監視項目と内容が重複していないか
• 通常時と繁忙時の変動を考慮できているか

利用量と負荷は、時間帯、曜日、季節、キャンペーンによって変化します。固定しきい値を長期間使わず、通常時の基準値、繁忙時のピーク、過去の障害履歴をもとに警告値と緊急値を調整します。

2. アラートの重要度と通知ルールを整理する

すべてのアラートを同じ方法で通知すると、担当者が優先順位を判断しにくくなります。影響度と緊急度に応じて重要度を分類し、通知先や対応時間を設定します。

表4: アラート重要度別の通知・対応例

対応不要の通知や同じ原因から発生する重複アラートが多いと、アラート疲れによって重要な通知が見落とされるおそれがあります。通知を残す場合は、受信者がどのような行動を取るべきかを明確にします。

3. 手順書・構成情報・連絡先を最新に保つ

手順書や連絡先が古いままでは、アラートを検知しても正しい確認やエスカレーションを行えません。

次のような変更があった場合は、関連する運用情報を更新します。

• システムのリリースや設定変更
• サーバー、サービス、監視対象の追加・削除
• クラウド移行や構成変更
• 外部サービスや委託先の変更
• 担当者の異動や組織変更
• 障害対応による手順や判断基準の見直し

構成図、運用手順書、連絡網ごとに更新責任者と確認周期を定め、リリースや構成変更の完了条件へ文書更新を組み込みます。

4. 夜間・休日を含む対応体制を確認する

24時間稼働するシステムは、夜間・休日にもアラート受信、一次確認、エスカレーションを実行できる体制を整えます。社内担当者だけで当番を維持すると、対応負荷の集中、引き継ぎ不足、人員不足が発生しやすくなります。

社内で夜間要員を確保できない場合、システム監視外注が一次対応を補完します。委託範囲には、アラート受付、一次切り分け、エスカレーションを設定できます。

外部の運用体制を利用する場合は、次の内容を事前に明確にします。

• 監視する対象と時間帯
• アラートを確認するまでの時間
• 外部担当者が実施できる一次対応
• 社内担当者へ連絡する条件
• 障害時の責任分界点
• システムへのアクセス権限
• ログや機密情報の取り扱い
• 対応履歴や報告内容

外部委託では、委託先の対応範囲とともに、社内の最終判断者、専門調査の引き継ぎ先、復旧承認者を定義します。

5. システム運用監視の効果を定期的に確認する

監視効果は、障害件数だけで判断しません。異常検知時間、一次対応開始時間、復旧時間、不要アラート件数、見逃し件数を評価指標にします。デジタル庁『デジタル・ガバメント推進標準ガイドライン』（2025年）が示す運用管理でも、インシデント対応の記録と継続的な改善が管理対象に含まれます。

表5: システム運用監視の効果を確認する評価指標

評価結果は、監視項目、しきい値、通知ルール、手順書、担当体制へ反映します。改善の目的は、障害件数の削減に加え、異常検知、初動対応、復旧の短縮と、同一原因による再発の防止です。

まとめ

システム運用監視では、サーバーやネットワーク、アプリケーションなどの監視対象としきい値を定め、異常検知から一次対応、エスカレーション、復旧確認、再発防止までの運用フローを整備します。

安定した運用を続けるには、アラートの重要度や通知先、夜間・休日の対応体制を明確にし、不要なアラート、対応時間、障害の再発状況を確認しながら、システム構成や業務への影響に応じて継続的に見直すことが重要です。

よくある質問（FAQ）

Q1. システム運用監視は24時間365日行う必要がありますか？

24時間365日監視は、時間外停止の影響が大きいシステムに適しています。対象例は、営業時間外も利用されるサービス、基幹システム、海外拠点向けシステムです。すべてのシステムを同じ時間帯で監視する必要はありません。

利用時間が限定され、停止しても翌営業日の復旧で業務影響を抑えられるシステムは、監視時間を限定できます。監視時間は、サービス提供時間、許容停止時間、目標とする初動時間を基準に決定します。

Q2. システム運用監視を開始するまでに、どのような準備が必要ですか？

監視開始前には、対象システムの構成、管理担当者、業務上の重要度、通常時の負荷、障害時の連絡先を整理します。さらに、通知条件、一次対応の範囲、エスカレーション先、復旧判定の基準を定義します。

構成図や運用手順書が不足している場合、監視対象と責任範囲を確定できません。ツール設定と並行して、構成情報、連絡網、一次対応、復旧手順を整備します。

Q3. 自社運用と外部委託は、どのように判断すればよいですか？

自社運用は、監視要員、インフラ・アプリケーションの専門知識、夜間・休日の当番体制を社内で確保できる場合に適しています。外部委託は、時間外対応の維持が難しい場合や、複数の技術領域を継続監視する場合に適しています。

自社運用と外部委託は、運用条件を揃えて比較します。比較項目は、費用、監視時間、初動速度、一次対応、エスカレーション条件、アクセス権限、報告方法です。

Q4. 障害が発生していなくても、監視設定を見直す必要がありますか？

障害が発生していなくても、監視設定は定期的に見直します。利用量、システム構成、担当者、外部サービスとの依存関係が変わると、既存のしきい値や通知先が実態と合わなくなるためです。

見直し時期は、リリース、クラウド移行、利用者増加、繁忙期の前後に設定します。定期レビューにより、現在の負荷に合わないしきい値や通知ルールを発見できます。

Q5. クラウドサービス側の障害もシステム運用監視で把握できますか？

クラウドサービス側の障害は、外形監視で間接的に把握できます。自社システムからの接続状態、API応答時間、HTTPステータス、処理成功率を確認します。クラウド事業者のステータスページと障害通知も、外部依存サービスの監視対象に含めます。

自社側の監視だけでは、クラウドサービス内部の障害原因を特定できません。外部サービス障害に備え、代替経路、問い合わせ先、利用部門への連絡方法、復旧後の再処理手順を事前に定義します。