アップタイムのダッシュボードは、あなたに嘘をついています。サイトはオンラインであると表示されています。ホームページは読み込まれ、SSL証明書は有効で、すべてのピクセルが正しい場所に描画されています。しかしその一方で、あなたのショップでは6時間もの間、実際の注文が一つも処理されていません。そして、その事実に最初に気づかせてくれるのは、日次売上レポートが横ばいになっている理由を尋ねてくるクライアントなのです。
これは、Eコマースプラットフォームを単なる会社案内サイトのように扱うことの根本的な欠陥です。標準的なアップタイム監視が行う質問は、たった一つだけです。「サーバーは200 OKステータスを返したか？」 WooCommerceのストアにとって、その質問は的外れです。サーバーは順調に稼働し、チェックアウトページも完璧に見えても、お金の流れが止まってしまうことがあるのです。それは「サイレントな失敗」であり、派手なサーバーダウンよりもはるかに大きな損失をもたらします。
「オンライン」が何の意味も持たないとき
200レスポンスは、PHPの実行が完了し、HTMLがブラウザに返されたことしか証明しません。StripeのJavaScriptが読み込まれたことの証明にはなりません。注文ボタンが正常に動作するエンドポイントに送信されることも、Webhookが実行されたことも、在庫が調整されたことも、確認メールが送信されたことも、これだけでは証明できないのです。訪問者は完全に読み込まれたチェックアウト画面を見て、カード番号を入力し、「購入」をクリックしますが、何も起こりません。あるいはさらに悪いことに、支払いは完了しているのに、注文は「失敗」として記録されることもあります。
もしあなたの監視戦略が、ホームページへのPing送信だけで完結しているなら、あなたは間違ったステージを見ていることになります。テーマのクラッシュによってヘッダーが表示されなくなることには気づけるでしょう。しかし、決済ゲートウェイがテストモードのまま止まっていることには気づけません。売上グラフを確認したときや、怒った顧客からの電話を受けたときに、初めてその事実に気づくことになるのです。
サイトがダウンすることなく、ショップが「死ぬ」5つのパターン
コンバージョン率がゼロに落ち込んでいるにもかかわらず、WooCommerceストアのアップタイムが100%を維持してしまう、具体的な失敗例を以下に挙げます。
- 決済ゲートウェイがテストモードのままになる。 開発者がバグを再現するためにStripeやPayPalをサンドボックスに切り替え、問題を解決したものの、元の設定に戻し忘れるケースです。実際の顧客が本物のカード番号を入力しても、テストモードの壁に突き当たります。エラーが明白な場合もあれば、そうでない場合もあり、その際はトランザクションが単に停止してしまいます。
- プラグインのアップデートにより、チェックアウトのテンプレートが壊れる。 WooCommerceのアップデートやページビルダーの変更により、チェックアウトフォームが正しく表示されなくなることがあります。ページ自体は読み込まれますが、請求フィールドが消えたり、注文ボタンをクリックした際にJavaScriptエラーが発生したりします。サーバーは正常ですが、ユーザーエクスペリエンスが壊れている状態です。
- ゲートウェイのエラーにより、注文失敗が急増する。 APIキーの期限切れ、通貨の不一致、3D Secure要件の変更などが原因です。これらのエラーはWooCommerceの管理画面上では「注文失敗」として表示されますが、アップタイムログの「サーバーエラー」としては表示されません。間違った画面を監視していると、じわじわと進行する収益の流出を見逃してしまいます。
- サーバー側の注文パイプラインが停止する。 顧客が「購入」をクリックした後、サードパーティのERP連携、カスタムの在庫同期機能、あるいは配送料計算ツールがタイムアウトしてしまうケースです。注文は「保留中」のまま無期限に留まります。顧客はページを更新し、混乱して離脱します。しかし、ホスティングのメトリクスは依然として「正常（グリーン）」を示したままです。
- 明らかな理由もなく、注文フローが停止する。 致命的なエラーも、プラグインの競合もありません。単にキャッシュが古いチェックアウト用のJavaScriptを配信し始めたり、同意管理バナーが決済用のiframeをブロックしたり、CDNのエッジノードが古いバージョンのスクリプトを配信したりしている状態です。サイトはオンラインですが、チェックアウトは機能していません。
本当に重要なものを監視する
これらの失敗を捉えるには、インフラストラクチャの監視をやめ、ビジネスロジックの監視を始める必要があります。実際のトランザクションフローの複雑さに対応した監視戦略を構築する方法は以下の通りです。
アップタイムだけでなく、注文フローを監視する。 商品をカートに追加できるか、チェックアウトのエンドポイントが有効なJSONを返すか、決済成功後にサンクスページが正しく表示されるかを追跡してください。外部のPingツールを使用している場合は、ドメインのルートだけでなく、クリティカルパス（重要な経路）を叩くように設定してください。
注文失敗数を7日間のベースラインと比較する。絶対数を使用しないこと。 プロモーション後の月曜日の朝であれば、1時間に5件の注文失敗は正常かもしれません。しかし、静かな水曜日の午後に1時間に5件の注文失敗が発生していれば、それは警告信号です。任意のしきい値ではなく、自身のローリングベースラインからの逸脱を確認してください。
ライブゲートウェイがサンドボックスモードになっていないか確認してください。 これをデプロイメントチェックリストおよび自動テストの一部に組み込んでください。アクティブなゲートウェイ設定を検査するか、公開APIキーを解析して、それらが本番環境の認証情報であることを確認してください。ストアがテスト環境を指したまま本番稼働すること（ライブ化すること）は、決してあってはなりません。
毎日、サーバーサイドでスモークテストを実行してください。 これは、人間の目に触れる前に決済機能の停止を検知するための、最も効果的なセーフティネットです。
日次スモークテストの構築
適切なスモークテストとは、データベースに混乱を残すことなく、現実的な注文を作成することです。プロセスは以下の通りです。非表示の仮想製品を生成し、WooCommerce APIを通じてテスト注文を実行し、合計金額が正しく計算されることを検証し、注文ステータスを順次遷移させ、最後にすべてのアーティファクト（生成物）を削除します。
実装の詳細は重要です。クリーンアップを慎重に行わないと、レポートが偽の注文や幽霊製品で埋め尽くされてしまいます。
テスト中はWooCommerceのメール送信を抑制してください。 最悪の事態は、cronジョブが日次チェックを実行したために、ストアオーナーや実際の管理者が午前3時に「新規注文」メールを受け取ることです。スクリプトの実行中は送信通知を無効にするか、フィルターを使用してテスト注文IDに関連付けられたメールをブロックしてください。
スクリプトがクラッシュした場合に備え、データをクリーンアップするためのシャットダウン関数を使用してください。 PHPでは、致命的なエラーによってプロセスが終了した場合でも実行されるシャットダウン関数を登録できます。税金の計算中や注文ステータスの遷移中にスモークテストが停止した場合でも、そのクリーンアップルーチンは必ず実行されなければなりません。そうしないと、孤立した注文や製品が残ってしまいます。
孤立したデータを避けるため、作成後すぐにIDを記録してください。 仮想製品が作成された瞬間にそのIDを取得し、テスト注文が作成された瞬間にそのIDを取得します。これらをすぐに変数に格納してください。スクリプトの終了時まで、自分が何を作成したかをデータベースに問い合わせるのを待たないでください。スクリプトが実行途中で失敗した場合、シャットダウンハンドラーが何を削除すべきかを正確に把握できるように、それらのIDをあらかじめ手元に持っておく必要があります。
このテストはユーザーインターフェースをバイパスし、アプリケーション層と直接通信します。これは重要です。フロントエンドはキャッシュされていたり、ミニファイされていたり、あるいは多数のブラウザ拡張機能によって操作されていたりする可能性があります。APIは「核心的な真実」を表します。つまり、WooCommerceは依然として注文を作成、計算、および遷移させることができるのか、ということです。
2つの保護レイヤー
外部監視と内部監視の両方が必要であり、それぞれのレイヤーが実際に何を伝えているのかを理解する必要があります。
外部監視は「ユーザーがサイトにアクセスできるか？」という問いに答えます。DNSの問題、SSLの期限切れ、サーバーのダウン、ネットワークの分断を検知するために使用してください。これはインフラ障害に対する第一防衛線です。
内部監視は「ユーザーが何かを購入できるか？」という問いに答えます。これはアプリケーション内部に存在します。注文の失敗率、ゲートウェイモード、チェックアウト中のデータベースパフォーマンス、および日次スモークテストの結果を監視します。外部のpingサービスでは決して検知できないビジネスロジックの失敗を捉えます。
サイトの停止（アウトレージ）は「騒がしい」ものです。サイトが落ちればアラートが鳴り、修正が行われます。顧客は不満を漏らすかもしれませんが、多くの場合戻ってきます。一方、決済機能の故障は「静か」です。広告は走り続け、顧客獲得予算は燃え続け、顧客は何も言わずに去っていきます。その間、アップタイムのダッシュボードは安心させるような緑色のままです。
ホームページを見るのはやめましょう。売上を見守り始めましょう。