いなげやの臨時休業から学ぶサーバーダウンは「想定内」とする更新の心得

心得其の357

4月1日の臨時休業

税率が8％となった4月1日。臨時休業したのは、スーパーマーケットチェーンの「いなげや」でした。新税率に変更したところ、価格を更新ができないどころか、レジが起動しない店舗もあり、全136店舗中、44店舗が臨時休業に追い込まれたのです。その他、交通機関や通販サイトなどでもトラブルが発生しています。

通販サイトの価格だけではなく、CMSやサーバーの変更など、「更新」はWeb担当者にとってよくある業務。いなげやの一件は他人事ではなく、他山の石として参考にすべき事例です。今回は「更新」にともなう心得で、実務を外注しているケースでも通じます。

いなげやは、3月31日の営業終了後の夜半から翌朝にかけ、ホストサーバから新しいシステムと新価格のデータを各店に配信する予定でした。ところが配信の途中でサーバーがダウンし、先の事態が発生します。本件について、匿名掲示板で多くみかけた意見は「サーバーが古い」というもの。なかには関係者とおぼしき投稿もあり、全店舗に配信できなかったサーバーのスペックの低さを嘲笑します。

しかし、POS開発の経験者である私の見立ては違います。サーバーに目を向けるのは、処理能力の向上など、改善策としては有効ですが、根本原因は「更新プログラム」そのものにあると見るべきだからです。なぜなら、データ配信（通信）の中断はシステム開発において「想定内」だからです。

いなげやの失敗

本件のようにサーバーがダウンすることもあれば、通信回線がパンクする可能性、電源コードに足を引っかけ断線するリスクなど、通信が途絶する理由は数多く存在します。そこでシステムには、あらかじめ「中断」したときのことを想定し、設計に組み込んでおくものなのです。

通信回線を使った更新作業では、一般的に受信データが完全なものであるかがチェックされます。不完全なデータは保留もしくは破棄され、完全なモノだけが更新されます。ところが、レジが起動しない事態が発生していたということは、不完全なデータが「上書き」された可能性が高いということです。つまり「中断」が起こらないという前提で設計されており、これが私の考察する臨時休業の原因です。

いなげやの失敗から学ぶ心得の1つが「通信は中断する」です。

BCPと同じ発想

モバイル端末がブロードバンドを超える通信速度を実現する時代となり、通信が途絶えるというイメージを持ちにくくなりましたが、通信はいつなんどき「中断」しても不思議ではないのです。レンタルサーバーへのアクセスが中断されたときの対応策を、社内の関係部署への伝達なども含めて検討しておくということです。震災直後の3年前に話題となった「BCP（事業継続計画）」と発想は同じです。

しかし、防ぐことのできない通信の中断と異なり、いなげやの事例は回避できたトラブルです。消費増税にともなう価格変更だったので、このタイミングでしか実施できなかったとは言い訳に過ぎません。新価格の更新はこのタイミングだけだとしても、増税以前に従来価格を閉店後に配信することで、

正常に更新できるかどうかのテスト

はできたからです。更新を確認するために、一部の価格を変更しておくのもよいでしょう。とにかく、この過程でサーバーの容量限界はチェックできたのです。

ロードテストの重要性

従来価格を配信して更新することを「無駄」と思うかもしれません。しかし「問題が発生しない」ことを確認する作業は、システムを安定稼働させるための「コスト」です。Web担当者の実作業にも通じます。

たとえば、レンタルサーバーによっては、アップロードできるファイルの容量に制限をかけているものもあります。仕様書や契約書で機能をチェックするのは当然としても、実際の更新作業の前に、テストデータをアップロードすべきということです。そして元プログラマとして、小さな声で告白しますが、

仕様書通りに動く

とは理想に過ぎない……とは過言ですが、なにが起こるか分からないのがプログラムの世界です。また、実際に作業することは、本番に向けてのリハーサルとなります。つまり、テストまで想定されているべきなのです。

開発の3倍は必要

四半世紀前のシステム開発の現場では、

テスト期間は開発の3倍

といわれていたほど、従来価格を更新するような、無駄にも思えるテストが何度も繰り返されたものです。

たとえば、私がプログラマ時代のことですが、新機能を追加したレジシステムを8月末に納品しました。クライアントの社内評価、実店舗でのロードテストを経て、全国のレジに導入されたのは新年度の翌年4月から。バカバカしいと思えるほど、入念なテストが繰り返されていたのです。ちなみに開発期間はわずか2か月。日程をしっかりと記憶しているのは、私が初めて「工程表」を書いた案件だからです。

いまは、そんな余裕はない

とは、あるベテランプログラマの台詞です。クライアントからの値下げ要求も強く、コストを下げるために「テスト」を軽んじる風潮が散見し、いわば「ぶっつけ本番」のようなスケジュールが増えているといいます。

テストなしの更新作業とは、のるかそるかのギャンブル。いなげやはこの賭けに負けたということです。

遠回りだけど最短距離

さらにいなげやは、価格更新と同時にシステムの更新も行いました。これも大変危険な行為です。トラブルが発生しても、どちらか1つの更新なら原因は明らかです。一方、2つ以上を更新してのトラブルなら、原因特定が遅れるどころか、組み合わせによっては不可能になることもあります。Web担当者の実務に置き換えれば、ブログシステムのバージョンアップと、カスタマイズしたテンプレートの変更、さらに別バージョンのブログデータをインポートするようなものです。

システムの更新が正常になされるか

そのテストを事前にすべきだったのです。あるいは、1つずつ更新していくことが、結論的に最短距離になることは少なくありません。

消費税増税前日の3月31日、多くの通販サイトが「臨時休業」していました。賢明な選択です。消費増税への対応に触れた回で、更新作業のための「臨時休業」という方法を提示していたのは、更新作業におけるもっとも大切な「心得」が「時間の確保」だからです。

何度となくテストを繰り返しても、リスクをゼロにすることはできませんが、ゼロに近づけることはできます。ただし、「品質」「コスト」「時間」はトレードオフの関係にあり、リスク対策はタダではありません。ビジネスインパクトと天秤にかけて、「どこまでやるか」を考える必要があります。