連携が壊れたとき最初に気づくのは誰か：WMSの監視とアラート設定

結論から先に述べる。WMS連携の監視には、ただ一つの基準しかない。連携が壊れたとき、監視はビジネスより先に気づかなければならない。顧客サービスが顧客から先に聞いたり、倉庫が新規注文が届かないことで気づいたりするようでは、ダッシュボードがどれほど緑色に見えても、監視の設定は失敗している。私はこれまで、美しいインターフェース文書と、サーバーが生きていることだけを示す緑色のランプ一つで本番開始を迎えた現場を何度も見てきた。それは注文が実際に流れたかどうかについては何も語らない。

2024年11月、中国東部のアパレル企業が、マーケットプレイスと宅配業者に接続した新しいWMSを本番開始した。3日目の朝、倉庫マネージャーから電話があった。なぜ朝から新規注文が一件も届かないのか、と。マーケットプレイスの注文インターフェースは午前2時に死んでいた。ミドルウェアは再試行を続け、再試行キューは膨らみ続け、午前8時までに600件を超える注文が滞留した。アラートは一件も発火しなかった。ヘルスチェックがプローブしていたのはゲートウェイで、ゲートウェイは生きていたが、注文インターフェース自体は死んでいたからだ。その顧客の言葉が忘れられない。故障を発見するために倉庫に注文を数えさせるシステムに金を払った、と。

連携が死ぬ4つのパターンだから、アラートも4種類

連携は4つのパターンで死ぬ。そしてそれぞれのパターンに、それ専用のアラートが必要だ。一種類でも欠ければ、死角が一つ残る。

第一の種類は死活監視で、インターフェースが応答するかどうかを見る。ただし死活監視は、ゲートウェイのトップページではなく、実際の業務インターフェースをプローブしなければならない。あのアパレル企業の教訓は、間違ったエンドポイントをプローブしていたことだ。各重要インターフェースを個別に、1分から3分ごとにプローブし、3回ではなく2回連続で失敗したらアラートを出すこと。プローブは軽く保つこと。状態だけを返すもので、ヘルスチェックの中で重いクエリを決して実行しないこと。

第二の種類はキューの滞留で、データが詰まっているかどうかを見る。注文取込、在庫同期、出荷確定には、それぞれ独自のキュー上限値を設ける。しきい値は勘ではなく負荷テストのデータから決めること。あのアパレル倉庫の数値では、通常量は1時間あたり約400件の注文だったので、200件を超える滞留が15分続けば、コンシューマーがすでに遅れ始めていることを意味した。しきい値は、開始後の勘による調整ではなく、本番開始前のチェックリストに含めるべきものだ。

第三の種類は再試行の失敗で、データが失われているかどうかを見る。3回の再試行に失敗したメッセージはすべてデッドレターキューに入れ、直ちに人間にアラートを出さなければならない。最も危険な設計は、無言の再試行に無言の破棄を組み合わせたものだ。メッセージがログの中を数回巡って、誰も責任を持たない。デッドレターキューには、名前の決まった担当者と、毎日のクリア時刻が必要で、チェックリストに明記すること。暗黙の了解にしないこと。

第四の種類はリコンシリエーションで、両者が一致しているかどうかを見る。固定の毎日スケジュールで実行すること。WMSの出荷に対するマーケットプレイスの出荷、WMSの在庫に対するマーケットプレイスの在庫だ。差分が合意した値を超えたらアラートを出すこと。リコンシリエーションは最後の網だ。最初の3種類がすべて故障を見逃しても、リコンシリエーションはその日のうちにそれを捉える。リコンシリエーションのない連携は、裸で走っているのと同じだ。

私が見てきた3件の障害、それぞれ異なる死角から

私はこの落とし穴を3回見てきたが、それぞれの故障は異なる死に方をした。第一は上記のアパレル企業だ。死活監視が間違った場所をプローブし、注文インターフェースが倉庫に気づかれるまで6時間死んだままだった。プローブを注文インターフェースに移すことに加えた修正は、業務量アラートだった。1時間あたりの新規注文が通常平均の30%を下回れば、直ちにアラートを出す。健全な機械でも業務量が崩れていれば、それ自体が故障のシグナルだ。

第二は、2025年3月の中国南部の3PL企業で、3社の宅配業者に接続していた。ある業者の追跡コールバックが断続的に失敗し、追跡番号が戻ってこず、顧客からの苦情が1週間で3倍になった。失敗したコールバックは担当者もなくログに残った。デッドレターキューがなかったからだ。復旧では、デッドレターキューと毎日のリコンシリエーションを構築し、欠落したコールバックを追跡番号ごとに再送した。そのプロジェクトの後、私は厳格なルールを作った。デッドレターキューなしにインターフェースを本番開始させない、と。

第三の故障は最も静かだった。在庫同期の遅延だ。WMSの在庫が変わり、マーケットプレイスの在庫が2時間後に更新され、その間に40件を超える注文が過剰販売された。インターフェースは生きており、キューは空き、再試行はすべて成功し、最初の3種類のアラートは緑のままだった。捉えられるのはリコンシリエーションだけだった。コアSKUの同期遅延には独自のしきい値が必要だ。翌日のリコンシリエーションではなく、遅延が30分を超えたらアラートを出すこと。取り消された過剰販売注文、謝罪、悪いレビューは、アラート1件の中断よりもはるかに高くつく。

ここであえて逆説を述べる。アラートが多ければ多いほど良いわけではない。アラートに溺れたチームは、すべてのアラートをノイズとして扱うようになり、やがて本物のアラートも読まなくなる。アラートは重要度で分けること。死活障害、デッドレターへの到着、リコンシリエーションの逸脱は、夜中に人を起こす。キューの滞留と同期遅延は、日中の対応として作業チャネルへ送る。重要度の段階分けのない監視は、監視がないのと同じだ。

アラート自体と同じくらい重要なのは、誰がアラートを受け取るか

チェーンの最後のリンクが最も見過ごされがちだ。アラートは出たが、受信者はそれに対処できるのか。私は、20人のプロジェクトグループにアラートが届き、顧客から電話が来るまで誰も動かなかった現場を見たことがある。すべてのアラートには、名前の決まった主担当者と、名前の決まったバックアップが必要だ。主担当者が30分以内に応答しなければ、アラートは自動的にバックアップへ、次にプロジェクトマネージャーへエスカレーションされる。エスカレーションはチャットグループで叫ぶのではなく、システムに設定しなければならない。

アラートの文面は、ステータスコードではなく指示のように読めなければならない。どのインターフェースか、いつか、影響を受けた注文は何件か、最初に何を確認すべきか。これらはすべてアラート本文に入れるべきだ。「インターフェースエラー」とだけ書かれたアラートは、午前3時に当直エンジニアを、どのインターフェースが壊れたかも分からないままログ漁りに送り出す。良いアラートはこう読める。注文インターフェースの死活監視に失敗、2分以内に2回のプローブが無応答、滞留は約180件、まずミドルウェアのログを確認し、次にマーケットプレイスのステータスページを確認すること。その文面があれば5分で、問題が自社側か相手側かが分かる。

もう一つの罠。アラートのチャネル自体が、監視対象のシステムに依存してはならない。SMSと別のチャットボットのように、少なくとも2つの独立したチャネルを維持し、一方のチャネルの障害がアラートを沈黙させないようにすること。チャネルは毎月テストすること。実際のインシデントを待って期限切れのボットトークンを発見するのではなく、チャネル自体をテストするのだ。

本番前夜のチェックリスト

本番前夜のチェックリストは、私がすべてのプロジェクトで実施する儀式だ。すべての項目に署名が入る。口頭の「だいたい準備できた」は認められない。

• すべての重要インターフェースに死活プローブを設定し、ゲートウェイのトップページではなく実際の業務エンドポイントを指すこと
• 注文、在庫、確定のキューの上限値を負荷テストのデータから設定し、チェックリストに明記すること
• デッドレターキューを構築し、3回の再試行失敗で自動的にそこへ振り分け、到着時に担当者へアラートを出すこと
• 毎日のリコンシリエーションをスケジュールし、差分のしきい値とアラート受信者を確認すること
• 業務量のベースラインを設定すること。1時間あたりの注文が通常平均の30%を下回れば直ちにアラートを出す
• バックアップ付きでアラート受信者を確認すること。主担当者が不在または連絡不能の場合、バックアップがアラートを受け取る
• 訓練を完了すること。意図的に1つのインターフェースを壊し、5分以内にアラートが人間に届くことを確認する
• ロールバック計画を文書化すること。インターフェースがダウンし続けた場合、誰が手動の注文取込を実行し、どのように行うか

訓練は最もよく省略される項目であり、最も重要だ。一度も試されたことのないアラートチェーンは、最初の本物の呼び出しで、間違った人、間違ったグループ、あるいはどこにも届かない。30分の訓練で、本番開始の夜の6時間の消火活動を節約できる。基準はシンプルなままにしておく。次に連携が壊れたとき、最初に知るべきなのは、当直エンジニアであって、倉庫マネージャーでも顧客でもない。

Lin Xiao（WMS導入コンサルタント）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。