どっちにせよ恐ろしい事だ…。
SEたるもの性能問題と排他制御ミス(これは今日ではPG的か)と電文消失事件にだけは関わり合いになりたく無いものである。死ねるし。あ、あと複数パッケージ間で何故かシングルサインオンできねーよケロちゃんチェック問題も相当嫌だな。恐怖のメモリリークJava様普及のお陰で随分減ったというか判り易くなった(突然core吐いて落ちる、じゃなくてフルGC頻発/OOMで何か変、と判る)。
私の信頼厚い*1WebLogicともあろうものが、いくら有名店とは言え、高々家電のお買い物サイト程度でへこたれるとは思えないけど、まー性能問題の原因なんて、外野が考え付く程度の定石は当事者はとっくに検証済みのはずだから情報無いのに無責任な事を公言するのは如何なものかなので何とも言えない。WLS上のCMSがイカンという推測もあるにはあるが…。ちょっと前のJava使いの間のジョークに「DBデータの一覧表作成にもエンティティBean使うOO馬鹿」というのがあったが今時なぁ。
しかしこの、“ヨドバシドットコムのリニューアル失敗から学ぶべきたったひとつのこと”の人もそれに感心したり突っ込み入れたりしてる人々の大半も、もっとずっと大切な事が全然眼中に無いのがいやはや何とも。負荷やロングランテストなんて当然やってるに決まってるじゃんJK。それでも検出できない問題がしばしば顕在化するのが本番の恐ろしさで、現に検出できなかった(検出できなかった理由への突っ込みはそりゃ色々あるかも知れない。通販サイトにWebLogic使う位なら負荷ツールもApachebenchだのJMeterだのWASTだのショボい事言ってないでドーン!とLoadRunner使うだろ、とか、いやさすがにそれは無いか。だったら外注するよな)。
学ぶべき事はシステム移行時の移行作業計画の重要性ですよ。
移行期間を設けて、新システムで致命的に拙い事が起きたら慌てず騒がず直ぐに旧システムに確実に切り戻せるよう、手順書を作って事前に検証しておいて、何日の夜の何時頃に切り戻しの判断を行うかスケジュールまで決めておくのが常道。これはシステム切り替えみたいな超大イベントばかりではなく、AP置換やOSやミドルへのパッチ適用でも同じ。しっかりしてる所だと何も無くとも定期的にリブートする日を月一とかで予め入れておいてパッチ適用等はそれに合わせて行ったり。SEさんも慣れてるから他の理由で再起動でも慌てないし自動化してたり。
ちなみにWebLogicじゃなくて実はTomcatだそうな。実際にWebLogic使って今は亡きBEAのコンサルを最初だけでも入れておけばこんな凄い事には多分ならなかったな。
他人事ながら早く収まるといいな。でもまぁ、たかが通販WEBサイト、基幹系じゃないしそんなに大騒ぎするほどのダメージじゃ無いのではなかろうか?
11/1に解決した模様

*1:でも9.0〜のワークマネージャは何かまだ信用出来ない…