ピークシーズン前のWCS負荷テスト：過去の波動をフル負荷で回す現場チェックリスト

ピークシーズンの1か月前は、1年で最も忙しい時期だ——設備の設置ではなく、倉庫を回って聞くのだ：WCSの負荷テストはやりましたか？10人中8人のマネージャーが「やった」と答える。次にどうやったか聞く。「通常の波動を回しました。問題なしでした」。そのたびにヘルメットを脱ぎたくなる。通常の波動はピーク負荷のほんの一部だ——朝のジョギングで短距離走を評価するようなものだ。

WCSの負荷テストは難しくないが、10倉庫中9倉庫が間違ったやり方をしている。チェックリストはこれだ。

まず明確に：WCS負荷テストが実際に負荷をかけるもの

自動化に詳しくない読者のために一文で：WCS（Warehouse Control System）は全自動化設備の司令官だ。WMSが「これらの注文を出荷せよ」と言い、WCSがそれを機械語に翻訳する——どのコンベヤを動かすか、どのシュートにカートンを送るか、どのリフトをどの階に行かせるか。PLCは分隊長、WCSは司令部だ。

負荷テストがWCSサーバーのCPUに負荷をかけることはまずない——通常日は20％～30％でアイドルしており、それを最大にするのは何も証明しない。体重を測るだけの健康診断だ。実際に重要なのは3つのラインだ：

1つ目、WCS–WMSメッセージ経路。ピーク時、WMSは毎秒数百のタスクをWCSに投げつける。キューが消化できなければ、設備がアイドルで待つなかタスクが積み上がる——司令部の電話がパンクし、最前線が待つ。

2つ目、PLCスキャンサイクル——信号読み取り、ロジック実行、コマンド送信の固定ループで、通常は数ミリ秒～十数ミリ秒。フル負荷では信号量が爆発し、サイクルが伸び、設備の動きが「半拍遅れ」になり、カートン間隔が狂う：詰まりはこうして生まれる。

3つ目、ネットワークジッター。WCS、PLC、スキャナ、HMIパネルはすべて1つの産業ネットワークにぶら下がる。ピーク時にデータの洪水が来ると、スイッチポートが満杯になる：パケットロス、再送、遅延。腹立たしいのは、この障害が静かな日には決して現れないことだ——十分に追い込まない負荷テストでは見つからない。

3つのうちどれが最初に壊れても症状は同じだ：全部詰まる。だが根本原因と対策は異なる。だから「うまく回ったか」だけを聞くな——各ラインのデータを別々に取れ。

昨年の波動を試験問題に使う：チェックリスト

どのデータを使うか？私の答えは変わらない：昨年のピークの実際の過去波動を、無編集で再生する。合成データは無意識に「もっともらしく」なる——そして実際のピークデータは決してもっともらしくない。1つのシュートに詰め込まれた3つの売れ筋SKU、返品波動と出荷波動の衝突、1つのゾーンの欠品によるタスク再計画。実際の波動データのグレムリンは、考えつかないようなものばかりだ。

手順：

ステップ1、目標を設定する：昨年のピークの1時間あたり最大波動ボリューム×1.2。事業側はいつも「今年は20％成長する」と言う——余裕を持たせろ。1.2倍に耐えられないシステムは、ピークの夜に爆発する。

ステップ2、テスト環境を構築する：本番から隔離するが、WCS、PLCプログラム、ネットワークトポロジは同一にする。「注文がないとき」に本番でテストするのは大罪だ——本番をフル負荷で回す勇気などないだろう。

ステップ3、波動を再生する：圧縮したタイムラインでWMS履歴インターフェースを使う。元の指紋を残す——山と谷、SKU集中度、例外比率。1つも「きれいに」するな。

ステップ4、3組の数字を監視する——WCSのキュー深度とディスパッチ遅延、PLCの最大スキャンサイクル、ネットワークポート使用率とパケットロス。「詰まったか」だけを見るのは、体重を測るだけの健康診断だ。

ステップ5、十分長く回す：フル負荷で4時間連続。多くの障害は慢性的だ——メモリリーク、モーターの熱保護、ベルトのずれ——2時間目や3時間目まで見えない。30分はリハーサルであってテストではない。

2024年11月、中国東部のアパレルEC倉庫。彼らの「負荷テスト」は通常負荷の70％で1時間、立派なレポートだった。ダブルイレブンの午前1時、メインコンベヤの幹線が詰まった：PLCスキャンサイクルが伸び、仕分け信号が半拍遅れて届き、カートンが玉突きした。40人以上が午前6時まで手作業に切り替えた。彼ら自身のポストモーテム：その夜の損失で、まともな負荷テスト20回分の費用がまかなえた。

逆の例：2025年8月、ブラックフライデーに備える米国西海岸の3PLは、昨年の波動を1.2倍で6時間連続再生した。4時間目に本物の問題が出た：ソーターのシュート割当アルゴリズムがフル負荷で劣化したのだ。通常日はSKUが分散してアルゴリズムが持ちこたえるが、ピークの売れ筋が集中すると同じシュートにカートンが積み上がり、満杯になって初めてアラームが鳴る。これは70％負荷では絶対に見つからない——転換点は90％前後にある。重み付けを2週間かけて書き直し、ブラックフライデーの夜はクリーンに回った。マネージャーはそれをその年で最も価値ある2週間と呼んだ。

合否ライン：超えてはならないレッドライン

クライアントに渡す「生死」の表——レッドラインを1つでも超えたら、その夜は眠れない：

「1回の詰まりは普通だ、手で直すよ」と言われる。ピークの夜の人員配置は通常波動用に組まれている。フル負荷で詰まり除去に人を送るのは、火事場に到着してからホースを探す消防士のようなものだ。

負荷テストがよく失敗するポイント

落とし穴その1：テスト環境が「ほぼ同じ」。ファームウェアのバージョンが1つ違う、スイッチが1つ足りないだけで、すべての結果はプラセボだ。私が見た最悪の例：テスト環境は3か月前のWCSバックアップで回っていた。テストはクリーン、大祝賀——そして新バージョンのパッチがメッセージキューのタイムアウトを変え、本番の夜にすべて崩れた。負荷テストの前に：本番のバージョン番号をすべて書き写し、1つずつ突き合わせろ。

落とし穴その2：設備はテストするが人はテストしない。WCSのアラーム、HMIのポップアップ、例外手順——ピークの夜、人間がそれらを全部クリックする。テスト中に障害を注入せよ——スキャナを抜く、シュート満杯をシミュレートする——そして当番の人が5分以内に手順書通りに動けるか見ろ。設備は鉄だが、人は固まる。午前3時の当番は入社2か月の若者かもしれない。

落とし穴その3、最も直感に反するもの：最も負荷がかかるリンクが最初に壊れるとは限らない。WCSはソフトウェアだ——圧力下では「正直」で、遅くなるかエラーを吐く。曲者は「信頼できる」隣人たちだ：PLC、スキャナ、スイッチ。スキャナの読み取り率が99.9％から97％に落ちるのは速度上は3ポイントに見えるが、ピークボリュームでは大惨事だ。スイッチポートの使用率90％は静かな日には問題ないが、バーストトラフィックでは即座にパケットを落とし始める。私のトレードオフのアドバイス：火力の70％をインターフェースと境界に、30％をWCS自体に向けろ。WCSのベンチマーク合戦にするな——ベンダーの営業はそれが大好きだが、ピークの夜には何の役にも立たない。

もう1つのトレードオフ：設備の物理限界まで追い込むか？事業ピークの1.2倍で止めろ。持続フル負荷のモーターはMTBF（平均故障間隔）に打撃を受ける——極端な1回のために設備寿命を燃やすのは安物買いの銭失いだ。ピークの本当の敵は、絶対ピークの数分間ではなかった。長時間続く高負荷だ。負荷テストは持久戦であって短距離走ではない。

お金に見合ったかは1つの数字に帰着する

どの会話も同じ結末だ：環境、人、ダウンタイム——見合うのか？下の数字は仮定だ——自分の数字を入れろ。本物なのは式の方だ：

ピークが1時間あたり10,000注文、1時間あたり60,000ドルのマージンだとしよう。2時間の詰まりで手作業仕分けを強いられ、効率は3分の1——14,000注文が出荷時刻を逃す。返金、悪いレビュー、プラットフォームのペナルティ、40人分の残業代：1回のインシデントで瞬く間に数十万元が燃える。

まともな負荷テストは？隔離環境（多くのインテグレーターはおまけで付ける）に2～3人の1週間の時間——数万元だ。だから1つの数字に帰着する：昨年のピークの1時間あたり最大ボリュームを取り、1.2を掛けて、システムがそれを飲み込めるか問え。イエスなら、建物で最も安い保険だ。ノーなら、「節約した」1元1元がピークの夜の事故へのクラウドファンディングだ。

ピークの1か月前、「負荷テストすべきか」と聞くのはやめろ。過去の波動は準備できたか？1.2倍の目標をレポートに書く勇気はあるか？イエスなら、追い込みに行け。ノーなら、まだ時間はある。

Da Liu（自動化エンジニア）著

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