午前2時を少し回った頃、電話が鳴った。相手はある3PL顧客の保全リーダーで、声はかすれていた。WCSのアップグレードを終えたばかりなのに、コンベヤは止まり、スタッカークレーン2台が通路の真ん中で凍り付き、出庫タスクが画面に溜まっていく。ベルトの周りには20人ほどが何もすることなく立ち尽くし、夜明け前にはトラック2波が来る予定だった。1波でも逃せば、顧客のドックSLAポイントが失われる。
彼らはフルストップ・アップグレードを選んでいた。すべてを止め、一気に全部入れ替え、さっさと済ませるやり方だ。ところが新WCSビルドは旧PLCドライバとハンドシェイクの不整合を起こした。テスト環境には一度も現れなかった小さなバージョン差で、データ量が小さすぎたせいだ。本番では通信が即座に破綻した。彼らはロールバックし、朝まで消火活動に追われた。トラックは列をなし、ペナルティが下った。
あの夜以降、私はすべての顧客にこう約束した。本番WCSのアップグレードは必ずローリングで行う。ビッグバン切り替えはもうやらない。以下が完全なプレイブックだ。
なぜ誰もラインを止めたがらないのか、数字が説明する。業界の試算では、750,000平方フィートの倉庫で計画外停止のコストは1時間あたり約$10,000。しかもアメリカの倉庫は古い。CBREのデータによると、築10年超の建物が米国倉庫在庫の89%を占め、平均築年数は34年。古い建物は古いシステムで動き、WCSアップグレードは避けられない。問いはただ一つ、事業を止めずにやれるかどうかだ。
前夜：スナップショットとバックアップこそ本当のアップグレード
ローリングアップグレードの第一歩は、アップグレードではない。自分への出口を作ることだ。
前夜には3つのことを行う。第一に、WCSの完全なスナップショットを取得する。システム設定、タスクスケジュールルール、インターフェースマッピング、PLCプログラムのバージョン、すべてだ。WCSはすべての真ん中にいて、上はWMSやERPと、下はPLCやコンベヤやクレーンと話している。このチェーンのどこかでバージョンが1つでもズレれば、アップグレードは幽霊を生む。スナップショットは手術前のシステムの家族写真だ。何かが壊れたら、これと比較する。
第二に、復元ポイントを定めたデータベースのフルバックアップ。バックアップだけでは足りない。テスト環境で一度復元し、動作することを証明する。バックアップは存在したのに復元ができなかったという悲劇を、私はあまりにも多く見てきた。半日の復元ドリルがあなたのオペレーションを救う。
第三に、2つのパッケージを用意する。アップグレードとロールバックだ。ロールバックパッケージは旧インストーラではない。逆方向のデータ移行ロジックを含む完全な反転計画だ。新バージョンがデータベーススキーマを変更するなら、ロールバックはスキーマとデータの両方をアップグレード前の状態に戻さなければならない。ほとんどのチームが初回にこれを忘れる。
もう一つ。アップグレード計画は事前に倉庫のオペレーションマネージャーに送り、各段階で事業側が何を感じるかを説明しておく。世界一エレガントな技術計画でも、オペレーションが何をしているか知らなければ救えない。一晩中電話が鳴りやまなくなる。
アップグレードの夜：まずスタンバイ、そしてトラフィックを少しずつ移す
私のアップグレードの夜は、毎回同じタイムラインで進む。
午後10時頃、ボリュームが下がってきたら、スタンバイをアップグレードする。ほとんどのWCS構成はアクティブ-スタンバイで動いている。スタンバイノードを新バージョンに上げ、スモークテストを行う。実際の入庫タスクを1件、出庫を1件、サイクルカウントを1件だ。チェーン全体を見る。タスク配分、機器応答、確認コールバック。この段階では本番トラフィックに一切触れないので、失敗は安い。
午前11時頃、スモークテストがグリーンになったら、トラフィックの一部を流す。重要でないコンベヤラインを1本か、通路を1本選び、そのタスクを新WCSに流す。観察ウィンドウは少なくとも出庫ウェーブ1回分は確保する。1ウェーブで、注文リリース、タスク割当、機器実行、例外処理という完全なループが回る。クリーンな1ウェーブは、新ビルドの基礎が健全だという意味だ。旧バージョンが引き続き事業の大部分を担い、新バージョンはパイロットにすぎない。
午前0時を過ぎたら、ノードごとに拡大していく。1つのノードを終え、観察期間を置き、タスク成功率と機器応答時間が劣化していないことを確認してから次へ進む。時間節約のために複数ノードを並行でアップグレードしてはならない。新ビルドに地雷があれば、並行アップグレードは全ノードにそれを埋め込み、戻りようがなくなる。
ボリュームが底を打つ深夜に、最後にコアに触れる。スケジューリングコア、データベースのプライマリノードだ。切り替えの前に、ロールバックパッケージがステージング済みで、意思決定者が部屋にいることをもう一度確認する。
一晩中、誰かが監視ウォールを見守る。数字は3つ。タスクの滞留、機器の通信状態、例外タスク比率だ。どれかがおかしくなった瞬間に止める。まず診断し、それから継続かロールバックかを決める。
ロールバックのラインは始める前に引く
あまりにも多くのチームが、ロールバックをアップグレード失敗後の即興対応として扱う。そうではない。ロールバックはアップグレード計画の一部であり、始める前に書いておくものだ。
トリガーを定量化し、全員の合意を得る。例えば、例外タスク比率が通常ベースラインの数倍に跳ね上がる、滞留が1ウェーブの処理能力を超える、重要機器の通信断が合意した分数を超える、などだ。いずれか1つでも到達したらロールバック。会議も議論もなし。アップグレードで最も危険なセリフは「あと10分だけ様子を見よう」だ。10分後には問題は大きくなっている。
ロールバックの意思決定者は1人だけ指名する。通常は保全リーダーか、当直の夜勤マネージャーだ。彼がロールバックと言ったらロールバックする。議論は午前3時ではなく事後レビューでやる。
ロールバックはテスト環境で少なくとも1回はエンドツーエンドでリハーサルし、時間を測る。その数字がメンテナンスウィンドウを決める。アップグレード時間＋観察＋ロールバック時間＋バッファだ。ほとんどのチームはアップグレードだけに合わせてウィンドウを組み、ロールバックに何も残さない。事が起きたときに行き詰まる。
忘れられがちなこと。新バージョン稼働中に作られたタスクや在庫移動は、旧バージョンにきれいに戻るか、旧バージョンが拾い上げる必要がある。WCSはリアルタイムシステムだ。データの隙間は停止時間より痛い。
だから、WCSのアップグレード方法を聞かれたら、私の答えはいつも同じだ。まずスナップショットとバックアップ、まずスタンバイ、トラフィックは少しずつ移し、ロールバックのラインは事前に引く。
ロールバック計画は5つのチェックに集約される。アップグレードの夜の前にすべてチェックする。意思決定者が1人、現場にいる。定量化されたトリガーが計画に書かれている。ロールバックとアップグレードのパッケージが用意され、一緒にテストされている。テスト環境での時間計測リハーサルが1回。データ突き合わせの手順が文書化されている。5つすべてにチェックが入れば、その夜は本当に眠れる。
成功したアップグレードを覚えている人はいない。でもクリーンなロールバックは、倉庫中が覚えている。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
