この記事について この記事は、生成AIを活用した自動生成フローで作成しています。Google SREとMicrosoft Learnの公式資料をもとに、監視の観点を分ける考え方を架空の受注サービスで整理します。

検証ステータス：📘 公式資料・構成例を確認。実サービスの監視設定や障害再現は未実施

監視は正常なのに業務が使えない？死活監視と業務監視を分けて考える

監視画面はすべて緑色。それでも利用部門から「注文を確定できません」と連絡が来る。これは監視が無意味という話ではありません。何を確認して正常と判断したのかと、利用者が何を完了できるべきかが一致していないと起こる問題です。

たとえばHTTPの応答を監視している場合、Webサーバーが返事をしたことは確認できます。一方、画面から注文を入力し、在庫を引き当て、受付番号が確定するところまでは、それだけでは保証できません。この記事では、死活監視、利用者視点の監視、内部の原因調査という三つの視点を分け、少ない確認項目で実務に役立つ設計を考えます。

まず「正常」の主語をそろえる

架空の受注サービスを想定します。利用者はログイン後、商品と数量を入力し、「注文確定」を押します。注文は受注データベースに記録され、受付番号が画面に表示される仕組みです。管理者にはWebサーバー、アプリケーション、データベースの状態を示す監視画面が提供されています。

ここでWebサーバーが起動中、HTTPのヘルスチェックも200を返しているのに、データベースの書込みが失敗していたらどうでしょう。運用者からは「Webは正常」、利用者からは「注文は失敗」です。どちらかが嘘をついているのではなく、測定対象が違うのです。

この区別は、監視ツールの製品選びより先に決めておく必要があります。すべてのエンドポイントを高頻度で叩くのではなく、まず業務として最低限どこまで動けば利用可能かを定義します。

三つの確認を順番に考える

第一段階は死活監視です。サーバーが応答するか、HTTP要求が所定のステータスを返すかを確認します。対象を軽量な参照専用のエンドポイントにすれば、比較的安全に定期確認できます。ただし、ヘルスチェックの内部で依存先まで調べていなければ、依存先の故障を検出できないこともあります。

第二段階は利用者視点の確認です。例えば「ログイン画面を開ける」「テスト用の一覧を参照できる」「期待する表示内容がある」など、実際の利用と関係する結果を調べます。Microsoft Azure MonitorのApplication Insightsには、外部からWebエンドポイントへ要求して可用性と応答性を確かめる仕組みがあります。ただし、単発のHTTPテストだけで複数画面の業務手順すべてを検証したことにはなりません。

第三段階は内部状態の観測です。受注エラー率、処理時間、データベースへの接続失敗、キュー滞留、CPUや接続数の飽和などを確かめます。GoogleのSRE資料は、遅延、トラフィック、エラー、飽和を監視の重要な四つの信号として整理しています。これらは、利用者の症状を見つけた後でなぜ起きたかを追う手掛かりにもなります。

図で見る：「返事がある」と「目的を達成できる」の差

次の図では、HTTP応答を確認できた後にも、業務結果の確認が必要であることだけを示します。実際の監視製品の内部処理を図示したものではありません。

flowchart TD
    A[HTTPの応答を確認] --> B{業務の期待結果はあるか}
    B -- はい --> C[遅延と失敗率を確認]
    B -- いいえ --> D[依存先と記録を調査]
    C --> E[運用判断へ]
    D --> E

この図の要点は、HTTP応答が成功しても、その時点で判定を終えないことです。逆に、業務結果が正しければどんな内部警告も無視してよい、という意味ではありません。容量不足や異常な再試行のような予兆は、利用者への影響がまだ見えていなくても対処が必要です。

架空の障害を三つ比較する

ケースA：Webは200、注文だけ失敗。 ヘルスチェックは成功しますが、受注確定時にデータベースの書込みエラーが発生しています。この場合、利用者視点の業務確認は失敗し、受注エラー率やDBログが原因調査に役立ちます。「Webが正常だからサービス全体も正常」と報告すると、利用部門の業務影響を見落とします。

ケースB：注文は成功、完了画面の表示が非常に遅い。 業務データは登録されていても、利用者には処理が止まったように見えることがあります。ここでは「完了したか」と「何秒かかったか」を両方測る必要があります。再度確定ボタンを押して二重注文につながる可能性もあるため、受付番号と再送時の動作を含めて業務側で確認します。

ケースC：Webにアクセスできないが、既存の予約処理は裏側で動いている。 画面の障害を理由に全処理が停止したと即断してはいけません。バッチやキューに保留中の取引が残っていることもあります。復旧時には「画面が開く」だけでなく、処理待ち、重複、取りこぼしを確認する必要があります。

三つのケースに共通するのは、監視信号が示す範囲と、利用者の業務影響を別々に記録することです。障害の重大度はCPU使用率だけでは決まりません。締切がある取引を処理できない状態なら、技術的な異常が小さくても利用部門の影響は大きくなり得ます。

小さく試す：本番取引を作らない確認手順

学習用の架空サービスを使えるなら、まず確認対象を紙に書き出します。例として「HTTP応答」「注文一覧の参照」「受付番号の表示」の三つを選び、それぞれの期待結果、失敗したときの連絡先、利用者に与える影響を表にします。いきなり本番の注文確定APIを定期実行する必要はありません。

次に、テスト環境で「一覧取得は正常だが、注文確定に失敗する」という模擬ケースを用意します。ヘルスチェックの結果と業務確認の結果が食い違うことを確かめ、どの監視が検出でき、どの監視が検出できなかったかを記録します。テスト環境がない場合は、机上の表だけでも判定の抜けを洗い出せます。

運用設計の記録例は次のとおりです。

期待値が単に「HTTP 200」だけだと、エラー画面を200で返す実装や、古いキャッシュが正常画面を返す状況を見落とすおそれがあります。必要に応じて応答本文の識別子やデータの更新時刻も確認します。ただし、表示データを丸ごとログへ保存すると個人情報が混入する可能性があるため、監視記録は件数や匿名の結果コードなど必要最小限にします。

条件を一つ変える：データベースが遅くなったら

同じテストシナリオで、依存先の応答が遅い場合を考えます。HTTPステータスは成功のままでも、ログイン後の一覧表示が普段より長くなることがあります。これを単なる「成功」と記録すると、利用者の待ち時間や締切への影響が数値に現れません。

成功率とは別に、処理時間の分布やタイムアウトを観測します。平均値だけでなく、遅い一部の要求がどれほどあるかにも注意します。利用者に「遅くても結局終わる」ことをどこまで許容するのかは、業務と合意して決める問題です。技術部門だけで勝手にしきい値を決めてしまうと、監視上は正常なのに苦情が増える状況が続きます。

ここまでで、監視の答えは一つではないと分かります。「サーバーが返答するか」「利用者の目的が達成できるか」「内部で異常が進んでいないか」は、それぞれ異なる質問です。すべてを一つの正常・異常ランプへ押し込まず、少なくとも重大な業務機能については別々に示す方が判断しやすくなります。

監視を増やすときの失敗と安全策

監視の強化がそのまま安全とは限りません。テストを頻繁に実行し過ぎると、負荷が増えたり、監視そのものがダミー注文やメール送信を生み出したりします。認証が必要な場合には、テスト用アカウントの権限と秘密情報の保護も必要です。料金が発生するクラウド監視機能は、設定前に契約と単価を確認します。

実際の業務処理を模倣する場合、実顧客の情報を使わない、外部への通知を送らない、結果を取り消せる専用環境を使う、という順番が安全です。取り消しが難しい決済や出荷指示は、原則として本番監視の実行対象にしません。参照だけで確かめられる監視と、書込みを含む複雑な確認を分離して設計します。

もう一つの失敗は、アラートをすべて同じ重大度で通知することです。処理が遅くなった兆候と、当日締切の注文が処理できない事象は、対応の緊急度が違います。まず利用者への影響を確認し、次に原因調査のメトリクスへ進むようにすれば、担当者が通知の数に埋もれることを減らせます。

運用チームが一枚にまとめるなら

最初から監視基盤を作り替える必要はありません。既存のチェック項目を「起動・通信」「利用者操作」「内部の原因調査」に分け、重大なサービスを一つ選んで空欄を埋めます。監視にない業務確認が見つかったら、まずテスト環境での手順と期待値を記録し、必要性・負荷・権限を確認したうえで自動化を検討します。

障害報告書にも「死活監視の結果」「業務影響の範囲」「復旧の判定方法」の三つを分けて残します。例えば、Web応答の復旧だけをもって業務復旧とせず、滞留していた取引の処理が確認できた時点を記録します。こうすれば、同じ障害が起きたときに、技術部門と利用部門の認識を合わせやすくなります。

監視の最終目的は、ランプを緑にすることではなく、利用者が仕事を続けられるかを把握すること。 まず一つの重要な業務について、どの確認で何が保証でき、何が保証できないかを明確にするところから始めるのが現実的です。

公式資料と確認範囲

• Google SRE Book: Monitoring Distributed Systems：ブラックボックス／ホワイトボックス監視、症状と原因、四つの重要な監視信号

• Microsoft Learn: Application Insights availability tests：Webエンドポイントの定期的な可用性確認の例

両資料は監視の考え方と機能の参考です。本文の受注サービス、ケースA～C、期待値の表は説明用に構成した架空例であり、特定企業の障害実績やAzureでの監視設定完了を意味しません。