benchみたいな簡易ツールでも、トップページに集中アクセス浴びせたら平均何秒で帰ってくるか?なんてのは1分でできる。いろんなページに同時アクセスしたときにサーバのロードアベレージがどうなるか?なんてのも、たとえばそのへんのパソコン10台にapache入れてab.exeをいっせーのせで叩くといった原始的手法でもいい。少なくとも今回みたいな状況になることを事前に再現できただろう。すれば、リニューアルオープンを遅らせて既存システムを延命するなりしつつ落ち着いて対処できたはずだ。(ヨドバシドットコムのリニューアル失敗から学ぶべきたったひとつのこと)なるほど。このリニューアル会社が性能テストをしなかったということはさすがにないと思うんだけど、その手法が現実的でなかったか、もしくは本番環境がさらに想定外だったのだろう。あとこの指摘では、「前置き」の部分がブラックで面白い。こっちが言いたかったことなんじゃないか?というくらい。httpのレスポンスヘッダを見るとSS_X_JSESSIONIDっていうクラスタ構成のWeblogicを使ってるときの独特のセッションIDクッキーが発行されているところを見ると本当にK社がかついだCMSパッケージでヨドバシのサイトを作ってるぽいね、とか、...ヨドバシドットコムのリニューアル失敗から学ぶべきたったひとつのことネットワーク側から次は、ネットワークのプロから見た分析。なぷさく)この問題発見の視点、プロセスは参考になる。技術的な問題以前に、この「もうひとつの失敗」こそが、単純なシステムエラーや機会損失よりも、もっと大きな、本質的な問題なのだろうと思った。ヨドバシカメラの場合は障害発生イコールすなわち他のショッピングサイトへの乗り換えにつながる。現状は重さのあまりに価格を比較することすらろくにできないわけで、ヨドバシは最初から購入検討の比較の土俵にすら上らない。「ヨドバシが安いみたいだけど、今つながりにくいから待つわ」とはならないのだ。これではサイトが最初から存在しないのと同じである。今の時代、価格サイトで比較すれば、すぐに最安値が見つかる。そんな中、ヨドバシを選ぶ人というのは、かなりロイヤルティの高い顧客と言えるだろう。いつまで待っても繋がらない、買えない。実店舗とポイントカードで果たしていつまでもつなぎ止めておけるかどうか。飲食店でも、苦情をいってくれるお客さんというのは、ありがたい存在である。客は、「サービスが悪い」「まずい」と感じても、特に何も言わずに帰る。