ダウンタイムゼロのWCSアップグレード：ローリングアップグレードとロールバックのプレイブック

まず結論から言います。WCSは倉庫を止めずにアップグレードできます。ただし2つの条件が両方とも満たされた場合だけです——ゾーンごとにローリング順序でアップグレードすること、そして本番開始の前夜にロールバックを実際にリハーサルしていることです。私は3つのプロジェクトを見てきましたが、最初の条件は満たしても2つ目を飛ばしました。3つともダウンしました。誰もロールバックボタンを押したことがないのに、見事なアップグレード計画など何の意味もありません。

（以下のストーリーに出てくる時刻・場所・数字は、私が関わったプロジェクトの値です。）

なぜWCSのアップグレードは炎上するのか

WMSは文書を管理します。WCSは機械を管理します。WMSのアップグレードに失敗すると、オーダーの流れが止まり、数時間は現場が手作業に戻れます。WCSがダウンすると、コンベア、ソーター、クレーンが一斉に凍結し、建物は非常に高価な駐車場になります。WCSのアップグレードは、高速走行中の車のエンジンを交換するようなものです。

2023年後半、アメリカ中西部の3PL物流センターがピークシーズン前にWCSのアップグレードを希望しました。インテグレーターは週末のウィンドウを選び、サイト全体を一斉に切り替えました。切り替えは午前2時に完了。午前6時に最初の波が始まると、ソーターのシュートの半分で、アドレス割り当てが新しいプロトコルと一致しなくなっていました。パーセルが何百個も誤ったシュートに行きました。旧バージョンの復旧までに午後1時までかかり——11時間の現場停止——、バックログ解消に3日間の残業シフトが必要でした。私は片付けのために呼ばれました。事後検証は一文でした。ゾーンごとの検証なし、ロールバックパッケージなし、建物全体を一発切り替え。それはアップグレードではありません。賭けです。

8ステップで実現するローリングアップグレード

ダウンタイムゼロのロジックは一文です。旧バージョンと新バージョンが同時に同じ機器を制御しないこと。建物を独立した物理ゾーンに分割し、一度に1ゾーンずつアップグレードし、観察し、健全であることを確認してから次に進みます。

1. ベースラインを凍結する。アップグレードの72時間前に、すべての構成変更を凍結します。フル構成、アドレスマッピングテーブル、PLCポイントリストをエクスポートします。コピーは2つ保管。1つはアップグレードコンソールに、1つはオフラインに。
2. シャドウ環境を構築する。テスト環境で、本番構成に対してアップグレードパッケージを最初から最後まで実行します。デバイスプロトコルのハンドシェイクとアドレスマッピングに集中します。少なくとも1波分のフル実行を行います。
3. パイロットゾーンを選ぶ。失敗しても痛みの少ない場所から始めます——通常は返品エリアか低流量エリアです。本流のソートラインから始めないでください。
4. ゾーンを空にする。波と波の間の隙間で、パイロットゾーンから搬送中のすべてのカートンを出し切り、触る前にオープンタスクがゼロであることを確認します。時間を節約するためにこれを飛ばしたチームを見たことがあります。旧バージョンと新バージョンが同じカートンに矛盾するコマンドを出し、ライン全体が完全に固まりました。
5. ゾーンをアップグレードする。ゾーンの機器サービスを停止し、WCSノードをアップグレードし、再起動し、空運転の自己テストを行い、20～50個のテストカートンを全プロセスに通します。
6. 観察する。パイロットゾーンを2波分フルに動かし、3つの指標を凝視します。ソート精度、機器アラーム数、波の定時率。いずれか1つでもベースラインから5%以上ずれたら、止めて調査します。「様子を見よう」はなしです。
7. 前進する。ゾーンごとにステップ4～6を繰り返し、本流のソートラインは最後にします。各ゾーンの後にアップグレードログに署名します。
8. すべてを確認する。すべてのゾーンが終わったら、成功を宣言する前に24時間動かし、ロールバックパッケージはまだ熱い状態にしておきます。

どの戦略を選ぶか:

私の結論です。1つのWCSがすべての機器を制御できるほどサイトが小さくない限り、ローリングアップグレードを選んでください。一斉切り替えで節約できる時間は、計画外の停止1回分の代償を払うには決して足りません。

ロールバック計画：アップグレード以上にリハーサルする価値がある

逆説的な見解を言います。アップグレードの失敗は怖い部分ではありません。怖いのは、ロールバックがアップグレードよりはるかにリハーサルされていないことです。私のプロジェクトでは、誰もがアップグレードパッケージを3回テストするのに、ロールバック手順は文書の中にしか存在しないことがよくあります——実際に炎上している午前3時には、誰もその文書を見つけられません。

2024年半ば、中国で私が支援していたeコマース倉庫で、アップグレード中にコンベアのアドレスマッピング障害が発生しました。チームは15分でロールバックを発動しました。旧WCSバージョンに戻し、アップグレード前に凍結した構成ベースラインを復旧し、チェックリストに従ってゾーンごとに機器を再起動しました。その夜遅れたのは1波だけ。午前6時にはすべて正常でした。なぜ彼らはそんなに決断できたのか。本番開始の前夜にロールバックをリハーサルしており、ボタンを押してから完全復旧までの計測時間が22分だったからです。その数字が全員に自信を与えました。

本番開始夜のロールバックチェックリスト——各項目を確認:

• ロールバックパッケージと旧バージョンメディアを用意、ハッシュ検証済み、「たぶんあるはず」はなし
• アップグレード前の構成ベースライン、アドレスマップ、データベーススナップショットをそれぞれ2カ所に保管、1つはオフライン
• ロールバックの発動条件を文書化。どの指標で、どの閾値で、誰が発動権限を持つか——その夜に議論はなし
• ロールバック手順を紙に印刷してコンソールに貼る、電源もネットワークもなしで読める
• 機器の再起動順序をゾーンごとに1ページに——順序が間違うとラインが二度固まる
• シャドウ環境でロールバックを最初から最後までリハーサル、実測時間を記録
• ベンダーサポートラインに人がいることを確認、留守番電話は不可

計算してみましょう。ロールバックのリハーサルは、半夜分の人件費とシャドウ環境の2時間分です。ロールバック計画なしの計画外停止は、私のプロジェクト経験では、中規模の自動倉庫に直接損失として1時間あたり数万ドルかかります——顧客からのクレームや評判の損害はその前の話です。残りの計算はご自分でどうぞ。

本番開始夜のチェックリスト：印刷してチェックを入れる

これは、すべての本番開始の前夜に私が配るリストで、ウォールームの壁に貼っています。

1. 構成ベースラインは72時間凍結、変更ログはゼロ
2. シャドウ環境でアップグレードパッケージとロールバックパッケージを実行済み、それぞれ1回フルパス
3. パイロットゾーン選定済み、空にする計画を確認済み
4. ゾーンごとのアップグレード順序と責任者が承認済み
5. ベースライン値を記録済み。ソート精度、アラーム数、波の定時率
6. ロールバックの発動条件と決定権者が文書で確認済み
7. 紙のロールバック手順をコンソールに貼付済み
8. ベンダーサポートラインをテスト済み、担当者が勤務中であることを確認済み
9. アップグレードコンソールと現場の通信をテスト済み
10. 各ゾーンの短い停止をオペレーションに周知——驚かせない

明日できること1つ。WCSベンダーに、ロールバックパッケージが最後に更新されたのはいつか聞いてみてください。答えが「長い間誰も触っていない」だったら、次のアップグレードの最大のリスクはアップグレードパッケージの中にはありません——誰も押したことのないロールバックボタンの中にあります。次の変更ウィンドウにロールバックのリハーサルを入れてください。新機能を学ぶより10倍大事です。

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

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