トップページは200を返しています。稼働監視も期待した応答を受け取っています。それでも購入者は決済画面から注文を完了できません。この三つは同時に起こりえます。
役に立つ監視には明確な確認範囲があります。何をリクエストし、何を検証し、結果から何を判断できるのか。「ページが応答した」が、いつの間にか「顧客が購入できる」に置き換わると問題になります。
緑の表示が何を確認したのかを明らかにする
HTTPの成功は特定のリクエストに対するものです。GETに対する200は、対象リソースの表現を正常に取得したことを示します。そのリクエストが実行していない後続操作の結果を報告するものではありません。この区別はRFC 9110のHTTPセマンティクスに基づいています。
トップページへのリクエストは決済フォームを送信しません。ブラウザーが決済モジュールを読み込めたこと、顧客が認証できたこと、注文が正式な記録を管理するシステムに届いたことも確認しません。
検証の種類ごとに、得られる根拠は異なります。
| 信号 | 確認できること | 別に確認する必要があること |
|---|---|---|
| HTTPの可用性 | 検証の制約内で、対象URLが設定したステータスを返した | ユーザーの操作が完了するか |
| 応答内容 | 返された本文に期待したマーカーが含まれる | スクリプトや操作が成功するか |
| ブラウザーの操作経路 | テストした環境で、定義した結果に到達する | 実際の本番環境の結果と一致するか |
| 本番環境の結果 | 結果を正式に管理するシステムが実際の完了を記録した | 他の利用者も同じ操作を完了できるか |
Zenovayの稼働監視設定では、期待するHTTPステータスと、応答本文内の任意のキーワードを指定できます。キーワードはリクエストの検証に内容の確認を加えます。ページのJavaScriptを実行したり、ブラウザーで一連の操作を完了したりするものではありません。
決済が使えなくてもステータスとキーワードは一致する
一般的なキーワードはエラーページにも含まれます。「Checkout」は見出しやメニュー、利用できないことを知らせる文にも現れます。その単語があっても、決済の準備ができているとは限りません。
以下は意図的に単純化したローカルの例です。自分のマシン上の一時サーバーに一度だけリクエストし、実際の注文や決済サービスには接続しません。
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Thread
from urllib.request import urlopen
PAGE = b"<h1>Checkout</h1><p>Payment service unavailable</p>"
class Demo(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(200)
self.send_header("Content-Type", "text/html; charset=utf-8")
self.send_header("Content-Length", str(len(PAGE)))
self.end_headers()
self.wfile.write(PAGE)
def log_message(self, *_args):
pass
with HTTPServer(("127.0.0.1", 0), Demo) as server:
server.timeout = 2
worker = Thread(target=server.handle_request, daemon=True)
worker.start()
url = f"http://127.0.0.1:{server.server_port}/checkout"
with urlopen(url, timeout=2) as response:
body = response.read()
print("status:", response.status)
print("keyword_found:", b"Checkout" in body)
print("blocked_message:", b"Payment service unavailable" in body)
worker.join(timeout=2)
出力は次のとおりです。
status: 200
keyword_found: True
blocked_message: True
ステータスの検証は通ります。「Checkout」という単語の検証も通ります。それでも本文は決済サービスが利用できないと伝えています。これは検証条件の範囲を示す例であり、アプリケーションの失敗をこの形で表すことを勧めるものではありません。
意図した状態でだけ現れる、安定したマーカーを選んでください。通常ページと代替ページに共通する文は避けます。ステータスと本文はエンドポイントの契約に沿う必要があります。適切な内容検証でも、確認できるのはその応答についてです。
意味のある結果までブラウザーで検証する
重要な操作について、役に立つ最小限の手順を決めます。ページを開き、必要な選択をし、フォームを送信し、意味のある結果を確認します。
ボタンが有効なことやクリックイベントは、通常は早すぎる確認地点です。処理が非同期に完了する場合、成功表示さえ早すぎることがあります。必要に応じて、その注文やインストールなどの状態を、正式に管理するシステムで確認します。
合成の購入テストには分離したテストアカウントとサンドボックスを使います。実際の請求、顧客指標への混入、限られた在庫の消費を起こさないよう、再現可能な入力と後処理を設計してください。サンドボックスの結果はその環境についてのもので、本番の決済経路すべてを保証するものではありません。
別途用意したブラウザーテストは、リクエスト監視を補完します。専用の環境、検証条件、保守が必要な別の確認です。稼働状況の表示に含まれるかのように受け取らせるべきではありません。
合成の確認と本番の結果を並べて見る
合成の確認は、選んだ経路をたどります。実際の利用者は別の端末、アカウント、ネットワーク、入力を使います。本番の結果も独自の観測範囲を持つ別の根拠として見てください。
決済では「purchase」というイベントの意味を明確にします。支払うボタンを押したことと、支払いが確定したことは別の段階です。ブラウザーのイベントだけで完了したと考えず、正式な注文や決済の状態と照合します。
完了した注文が急に減れば調査すべきですが、それだけで障害と診断はできません。対象となる訪問、観察期間、計測のカバー範囲、完了までの時間を確認します。対象者の構成で変わるコンバージョン率にも同じ注意が必要です。
可用性、ブラウザーの動作、完了した結果は、どれかが作り話でなくても食い違うことがあります。それぞれが何を観測しているのか、その違いを調べることが役に立ちます。
行動につながるアラートを書く
アラートでは失敗した検証条件を示します。「トップページが想定外のステータスを返した」と「サンドボックスの決済が確認画面に到達しなかった」では、担当者が調べる場所は異なります。
対象URLや操作経路、環境、失敗したステップ、観測時刻、再現に必要なリクエストやブラウザーの情報を含めます。認証情報や顧客データはアラートやスクリーンショットに含めないでください。
検出したい障害に合わせて、実行頻度と再試行のルールを選びます。定期確認が見るのは特定の時点です。緑の結果が、その間のすべてのリクエストを説明するわけではありません。連続した失敗を条件にするとノイズを抑えられますが、検出も遅れます。この選択を明示します。
復旧と判断する前に、失敗した検証を繰り返します。トップページの応答が戻っても、決済の問題が解消した証明にはなりません。該当する確認が再び成功し、本番の結果でより広い状況を確かめる必要があります。
何を確認して緑になったかを全員が理解していれば、その表示は役に立ちます。根拠を正確に示すことで、監視を信頼しやすくなり、結果に応じて動きやすくなります。
