isc5素人の勝手な想像と素人なのにしたり顔で書いてるだけなのでこんなのありえない、適当すぎると思った人はそのままブラウザを閉じてください。主な原因はCPUの不足という。将来に向けたグローバル対応など機能を追加したが、公開前にサーバーの容量不足が発覚。サーバーの入れ替えなどを行った。委託先によるプログラムの不具合も影響したという。ネットショップ担当者フォーラム単純なCPU不足じゃないとは思うけど、それ関係だとは個人的には思います。ニトリネットのシステム開発が、業界標準レベル?のやり方でテストをちゃんとしているのなら、プログラムよりも、環境要因じゃないかなぁと思います。デスマーチ?になりながらでも、ちゃんとやっているという前提なので、やってない場合はネットの一部で言われてることもありえるのかなぁと思うけど、そこまでこの業界ひどくないと僕は思ってる。ひどくなくても作業する人は、ひどい目にあってるという事実は同じだとは思いますがね。実用上支障がないシステムは出来上がるが、作業員は心身ボロボロって言うだけの話。Server」を使用しているのではないか?と思う。Serverに統合されました。富士通あと、CTCって昔からOracleと関係深かった記憶がある。2.重大度1(システム停止など)の障害につきましては、現状回復までを24時間対応にてサポートいたします。17:47WebSphereも、たしか癖が強かった気がする・・。Oracleの製品はサポート契約込みでないと使い物にならないかも小さいところでOracleを使えないのもそのあたりにあると思うけど、実際のところは分からない。金さえはらえば、製品のバグらしいものを発見した時にきちんと調査して、対策用のパッチなどを提供してくれる。いうサポート契約してないと、大規模システムでまともに使えないと思った方がよいとは思う。今は知らないが、社風(ビジネスモデル)ってそんなにかわらないと思うので現状もそうだと思うOracleという名前が出てきたので、今回の障害とは関係ないけどまあ参考まで。不特定多数の客を扱うWebシステムは、運用開始時にトラブルに巻き込まれやすい負荷テストをきちんとしていても負荷テストをきちんとしていても、特定のケースだけ過負荷になってしまうということもありえます。アプリケーションサーバーが特定のクッキー文字列を受け付けると、メモリーリークして結果としてCPUが過負荷になり、アプリケーションサーバー自体を再起動しないと治らないとかそういう不具合(バグ)を持っていたケースも見かけた気はします。アプリケーションサーバー側のバグですね。上記のようなケースだとアプリケーションサーバー側は問題ないとおもって、プログラムだけの見直しをした場合においてなかなか原因が分からないんですね。クッキーの特定の文字列に関してそんな不具合が存在するなんて想像できる人はいないので、頭でっかちな人たちには分からないんですね。いうケースは、ログから地道に解析していくしかないんですが、それって時間がかかるんですね。時間がかかるので、その方向以外からも並行して原因解析をすることがほとんどだと思います。上記のケースは、レアケースだけど、起こってしまうと致命的になるケースでかつ、テスト段階ではほとんど発見できないという感じになります。Webシステムが、クライアント(PC)に依存して、それもクッキーの内容に依存して変な動作をおこすなんて想定して、テストケースなんて作れないわけですからね。WindowsUpdateでも、特定のケースだけ致命的な動作をしてしまうというのがあったかと思います。いうのと似たようなものですね。再起動できなくなるとか・・・。本番環境とテスト環境は、条件を同じにすべきなんだけど、完璧に同じにできることはあまりないかと思います。本番環境では、テスト環境と同じバージョンをつかうか、それとも新しいバージョンをつかうかとかそういうのもあります。原理原則としテストで用いたバージョンを使うべきなんだけど、実際には、それで不幸になったケースもあるのが現実です。新しいバージョンをつかえばよかったというケースですね。新しいバージョンといってもマイナーバージョンですね。した不具合を治したとかそういうので少しずつバージョンがあげてくる奴の話。予期せぬデータによるバグに気づきやすい前述したようなテストデータはあくまで開発者が予期したデータにすぎません。実際のデータはもっと複雑で、想定していないデータが存在してバグの原因になったりします。開発の時点で本番データで開発を行っていれば、そういった環境間の差異による問題に気づきやすくなります。今回の場合は、戻さずに、原因を特定して解決して乗り切るというのをしないと仕方がないんじゃないかなぁと思う。->原因解明しない限り、一生システム移行できないたぶん、上記のような図式になるので、とりあえずもとに戻してというのは、普通はやらないんじゃないかなぁと思う。あと、新システムからどうも、出荷まで絡めたシステムになってるようなので、たんなるリニューアルでないという部分ももとに戻すことができない理由にはなるとは思う。ニトリから、損害賠償請求されるのでは?逆に、僕も知りたい。請求して、ちゃんと受け取ってほしいとは個人的には思う。・その際に、自分の懇意にしているシステム営業を連れてきて提案させる(CTC)・CTCのMAMSを導入することを決定し、基幹システム等のつなぎ込みプロジェクトが開始CTCでの受注額はおそらく数億〜十数億レベル(3年保守契約含む)→コンサルには5%キックバック・この時点で、以前にニトリネットを依頼してた会社(0社)の足切りを決定。・0社は引き継ぎは1ヶ月しか行いませんと明言、ニトリ担当者了解する。・CTC下請けへ開発を投げる。中堅規模の開発会社(A社)が5000万で受注。・A社、いつも仕事を投げているB社へ800万で発注。・B社、コンペで募った会社(C社、D社、E社)の中から、一番デザインが良さそうだったD社に300万で発注。・D社、デザインはできるがシステム開発ができないので、よく外注依頼しているF君に100万で依頼。・F君必死にJavaでシステムをシコシコ作る。・D社が上に上げたデザインが、ニトリ側で何度もリジェクトがかかり、作り直しを余儀なくされる。・それに伴い、F君の作業もいきつ戻りつ、リニューアル1ヶ月前の状態でトップページもまで完成していない状況に。・不眠不休の1ヶ月を過ごし、ベータ版を完成させるが、ニトリ本社でのレビューで、これではリニューアルができないという決断になり、リニューアルを延期させる(この時点で5月)・6月1日リニューアルということになり、さらなる不眠不休の作業が続くF君。・しかも遅れたんだからということで、追加仕様がバンバン舞い込む。・6月1日も間に合わず、泣く泣く、2週間さらに延期とする。・なんとか見せれる形のものになったので、これ以上伸ばせないという決断になり、リニューアルを向かえる。・リニューアルは、新インフラ環境で行われたため、前の環境は残っていない。(会員データも登録しなおし)・リニューアルを行うが、高負荷対策が全く行われていないため、すぐにサイトがみれないようになりサーバーCPUは振り切る状態に。数億〜十数億レベルの受注で、ここまでひどい感じにはなりえないと僕は思うけど。商社系のシステム会社?が受注した場合は良くわからないので、何とも言えないけど。Wikipediaまあ、同じ系列でも、会社によってもちがうけどね。:コメントは、まだありません。関連記事(一部広告含む)ブログや記事に関する質問・感想などご意見やお問い合わせは、お問い合わせ窓口から受け付けています。記事に関する質問・感想などは、この記事のコメントをご利用ください。コメントをキャンセルメールアドレスは公開されません。コメント欄には、必ず日本語を含めてください(スパム対策)。isc5.com閉じる。