ヨドバシカメラ問題のゆくえ

前回記事『ヨドバシ事件　～CMSと表示速度～』で取り上げた「ヨドバシカメラ問題」が明るみに出るにつれて、方々で色々な指摘が出てきた。
その中で特に興味深かった、「なるほど」と思った指摘をピックアップしてみる。
まずは『ヨドバシドットコムのリニューアル失敗から学ぶべきたったひとつのこと』より。

教訓と野次

だから、ここまでの話はすべてどうでもいい。すべて外野席の酔っ払いによる野次にすぎないので本当にどうでもいい。前置き長くてすまんね。

広告

サイトの大小によらず、過去に集めたユーザーによるトラフィックがリニューアル後も継続して発生する前提において、Webシステムの基本的なアーキテクチャを変更してリニューアルする場合に、必ずやらなければならないたった一つのことそれは、性能試験である。負荷試験とも言う。

簡単なことだ。たとえばapache benchみたいな簡易ツールでも、トップページに集中アクセス浴びせたら平均何秒で帰ってくるか？なんてのは1分でできる。いろんなページに同時アクセスしたときにサーバのロードアベレージがどうなるか？なんてのも、たとえばそのへんのパソコン10台にapache入れてab.exeをいっせーのせで叩くといった原始的手法でもいい。少なくとも今回みたいな状況になることを事前に再現できただろう。そうすれば、リニューアルオープンを遅らせて既存システムを延命するなりしつつ落ち着いて対処できたはずだ。
（ヨドバシドットコムのリニューアル失敗から学ぶべきたったひとつのこと）

なるほど。性能テスト。このリニューアル会社が性能テストをしなかったということはさすがにないと思うんだけど、その手法が現実的でなかったか、もしくは本番環境がさらに想定外だったのだろう。

あとこの指摘では、「前置き」の部分がブラックで面白い。むしろこっちが言いたかったことなんじゃないか？というくらい。

…キーになる社員が限界に達して失踪したらしいねシステム構築プロジェクトではよくある話だよとか、 K社がかついでるパッケージソフトってFatwireじゃんこれCMS(コンテンツマネジメントシステム）であってECサイト構築パッケージとは似て非なるものでしょつまり油絵を書くプロジェクトに絵の具じゃなくてノミとトンカチ持ち出したみたいな？とか、 そもそもK社（とその関連会社）って90年代後半に雑誌関係から転進したWeb制作会社であってシステム屋じゃないんだからヨドバシクラスの巨大ECサイトのシステムを作らせたこと自体が間違ってね？とか、 httpのレスポンスヘッダを見るとSS_X_JSESSIONIDっていうクラスタ構成のWeblogicを使ってるときの独特のセッションIDクッキーが発行されているところを見ると本当にK社がかついだCMSパッケージでヨドバシのサイトを作ってるぽいね、とか、…
ヨドバシドットコムのリニューアル失敗から学ぶべきたったひとつのこと

ネットワーク側から

次は、ネットワークのプロから見た分析。

1. DNSは問題なし
2. icmp応答/MTUも大丈夫
3. 表玄関も生きてるっぽい
4. 近くのサーバも生きてるっぽい
やっぱりCMSの問題？
（ネットワーク側から見たヨドバシカメラ問題 – なぷさく）

この問題発見の視点、プロセスは参考になる。
ただ、技術的な問題以前に、この「もうひとつの失敗」こそが、単純なシステムエラーや機会損失よりも、もっと大きな、本質的な問題なのだろうと思った。

ヨドバシカメラの場合は障害発生イコールすなわち他のショッピングサイトへの乗り換えにつながる。

現状は重さのあまりに価格を比較することすらろくにできないわけで、ヨドバシは最初から購入検討の比較の土俵にすら上らない。「ヨドバシが安いみたいだけど、今つながりにくいから待つわ」とはならないのだ。これではサイトが最初から存在しないのと同じである。
（ヨドバシカメラのもうひとつの失敗 – なぷさく）

「サイトが最初から存在しないのと同じ」
確かにそうだ。今の時代、価格サイトで比較すれば、すぐに最安値が見つかる。そんな中、ヨドバシを選ぶ人というのは、かなりロイヤルティの高い顧客と言えるだろう。しかしいつまで待っても繋がらない、買えない。実店舗とポイントカードで果たしていつまでもつなぎ止めておけるかどうか。

飲食店でも、苦情をいってくれるお客さんというのは、ありがたい存在である。大抵の客は、「サービスが悪い」「まずい」と感じても、特に何も言わずに帰る。そして二度と来ない。こうして客がいなくなる。