ニトリネットショップのリニューアルで大規模システムトラブル

システムトラブル

とりあえずメモ．

「6/23 10:00に復旧させる」と言ってたが，23:00時点でまだ復旧してない．*1「問題はCPU数不足」なんて発表してる時点で，上の人間が問題を全く把握してないと思われる．

リニューアル作業は17日午前0時から午前10時まで実施。リリース直後に一部プログラムエラーのためサーバが高負荷状態となり、表示エラーなどの不具合が発生した。

　リニューアルは、サイトのグローバル対応やレビュー機能の実装、店舗在庫の閲覧機能、配送との連携機能などを追加するものだったが、リニューアル作業を委託した外部企業のプログラムに問題があったほか、サーバのCPU不足が原因で不具合が発生。サーバを入れ替え、CPUを強化するなどの対策を行った。

　リニューアルに合わせ、伊藤忠テクノソリューションズ（CTC）のクラウドサービスを実装しているが、今回の不具合は同サービスの導入とは関係ないという。

　22日現在もサイトはメンテナンスが続いており、商品検索や購入、マイページの確認などが利用できない状態だ。ニトリ公式スマートフォンアプリでも、ニトリネットと連携して機能する商品検索や購入などの機能が利用できなくなっている。23日午前10時の復旧を目指し、作業を続けているという。

http://www.itmedia.co.jp/news/articles/1506/22/news104.html
  • ニトリは6月17日、通販サイト「ニトリネット」のリニューアルで一部のプログラムエラーが発生し、刷新が遅延していると発表した。6月23日午前6時現在もECサイトのトップページは「サイトリニューアル作業遅延のお知らせ」を掲載。6日間も本店サイトで商品購入ができな状態が続いており、代替策として「ニトリネット 楽天店」に誘導する対策を施している。
  • 「ニトリネット」のリニューアルの大きな刷新点は、輸配送のリソース状況に応じた配送時間枠の提示と配車計画の自動作成を可能とするクラウドサービスの採用など。
https://netshop.impress.co.jp/node/1817

「ニトリが6/17にECサイトをリニューアル、配送計画の自動化を実現へ」

MAMSは配送計画を注文時に自動的に作成するクラウドサービス。配送予定時間や配送状況などをウェブサイトやECサイトで追跡・確認することができる。受注と同時にシステムが効率的な配送ルートを自動で作成し、配送担当者などの関係者はパソコンやスマートフォンを使った情報共有が可能になる。

先行して2014年11月、全国のニトリ店舗にMAMSを導入。ニトリ店舗のサービスカウンター、接客用のタブレット端末で宅配依頼を受け付けると、システムが配送可能な日時を提示できるようにした。リニューアル後のECサイトでは店舗同様、時間指定での配送受付ができるようになる。

ニトリでは従来、システム上で効率的な配送ルートの自動作成を行っていたものの、状況にあわせた配送ルートのリアルタイム変更、配送日時の詳細な指定などが宅配サービス向上での課題になっていた。

ECサイトの刷新で、ネットや店頭で購入した商品の配送面の拡充を図っていく

http://netshop.impress.co.jp/node/1760


小規模なら動くけど大規模ならダメだったとか，PCでは動くけどWebでは動かなかったとか，色々考えられはする．オーダーがNの5乗や階乗でも，小規模だったら動いたりするしね．そしてそういうコードを書く人はし怖い物知らずだしテストもショボいので，「てすとしました．なにももんだいありません．」と自身満々で答えたりするのです．

http://b.hatena.ne.jp/entry/togetter.com/li/836269

  • id:yutaka_maruoka ＣＴＣさんのクラウド起因という文もあるが結局どこに原因かよくわからんね。同業者としては聞くだけで胃が痛くなる気持ちになる障害継続期間…。是非とも中の人の頑張りに期待したいところ。
  • id:cyuushi 以下見た感じだと既に稼働してるCTCのSCMと連携するECｻｲﾄで不具合&負荷見誤ってSCM道連れにしたのかな? https://netshop.impress.co.jp/node/1760 http://goo.gl/GCoK7f
  • id:jaguarsan 偶然メンテ終了予定時刻からヲチしてたけど、全く動いた形跡なかったので作業に失敗したんじゃないかな。パフォーマンスの問題なら多少なりとも開いたはず。
  • id:accent_32 バックアップで復元させたいけど、店舗システムと連係し過ぎてると店舗システム復元データの不整合で復旧出来なかったりもする。上役の人は移行完了した際には、対応スタッフに優しくしてしてあげて下さい。
  • id:denimn サイト停止5日とか心臓が止まりそう。きっと行軍中も死屍累々だったんだろうね…。生活が破綻した人もいるかもしれないし。お疲れ様。心身を大事に頑張って下さい。あとレポートも期待しています。
  • id:eax もう５日経過してるけど...担当者には土日も無かったのだろう睡眠は取れてるのか？、でも元に戻せないのはどうかと思う。

なれる！SE7 目からウロコの？客先常駐術 (電撃文庫)

なれる！SE7 目からウロコの？客先常駐術 (電撃文庫)

http://d.hatena.ne.jp/JavaBlack/20120815/p1

「まずエンドユーザーですが……カウルドットコムってサイトご存じですか？」
「カウル……あのネットショッピングサイトのカウルですか？」
「ええ．」
（中略)
「年度内いっぱいかけて業務システムを再構築する予定です．それこそ表のサイトからウラのデータベースまで．インフラもほぼ全面入れ替えですね，ルータ，スイッチ，ファイアウォール，あとロードバランサとかも．」
すごい，まさかのビッグプロジェクト．．ちょっと意表を突かれた．へぇ，あのカウルのサイトリニューアルに関われるのかぁ，知り合いに自慢できそうだ．

「ほんっとバンバン人が潰れてくんですよね，ここの現場．プロジェクト開始から三分の一くらい入れ替わってるんじゃないですかね？かくいうわたしも実は三人目のデータベース担当なんですよ．」
「え，そうなんですか？」
「ええ，前任は三週間でダウンしたらしいですよ．」

今こそ分かった．この現場は異常だ．人が人として扱われない空間．コストダウンのためにありとあらゆる蛮行が許容される場所．努力も誠意も何一つ通用しない．プロパーの指示が全てにおき優先される空間．

逃げなければならない．全ての手段を使って，たとえそれが自分の悪評に繋がろうと，この現場から脱出しないといけない．他でもない室見を救うため．目の前のお人好しな上司を守るために．

だがどうしたらいい？

自分達の身柄は契約で拘束され何一つコントロールできない．仕事は山積み，納期・仕様を調整する権限さえ与えられていない．こんな状況で一体どんな手が打てるのか．逃げ出す絵図を描けるのか．

どうすればーー

工兵は喘いだ．

見上げた天井は牢獄のように低く薄汚れていた．

などと言うことになってないことを祈る．

  • id:chikunai 切り戻しのない前提のリニューアルプロジェクトだったのかな。

切り戻しのつもりだけど，何かポカやらかしたとか？

復元しようと思って初めてDBのバックアップが取れてなかったことに気付いたとか，戻そうとしてバックアップ先のHDDも壊してしまったとか．バックアップをとってませんでしたとか．．．

  • id:tittea こういう失敗、事故の事例がノウハウとして蓄積されず教訓として生かされないのが問題だと思う。航空機事故や医療事故のように業界で共有できるような枠組みがほしい。それで助かる命はあるはず。

過労死で失われる開発者の命は，紙切れよりも軽いので，日本企業的にはどうでもいいんじゃないかなあ．

  • id:btoy ニトリ社長の生い立ち記事読んで知っているだけにシステム担当者の安否が心配でならない。

こんなのかな？

  • id:onsenblog 4日間ダウンってすごい壮絶。かわいそうだけど私の胃が痛いのはただのストレスです。

NTTデータのDoblogに比べればどうってことは．ある意味で伝説．

  1. http://d.hatena.ne.jp/JavaBlack/20090215/p3
  2. http://d.hatena.ne.jp/JavaBlack/20090217/p1
  3. http://d.hatena.ne.jp/JavaBlack/20090424/p1
  4. http://d.hatena.ne.jp/JavaBlack/20090601/p2

「閉鎖状態の「ニトリネット」が6/23にサイト運営を再開、不具合の主因はCPU不足」

https://netshop.impress.co.jp/node/1818
追記

主な原因はCPUの不足という。将来に向けたグローバル対応など機能を追加したが、公開前にサーバーの容量不足が発覚。サーバーの入れ替えなどを行った。また、委託先によるプログラムの不具合も影響したという。

こうしたことが原因で、ニトリ公式通販 ニトリネット全般（商品情報検索、購入、マイページのご確認など）、ニトリ公式スマートフォンアプリ（商品情報検索、購入、メンバーズ会員証表示など）で商品が購入できない状況が続いていた。

じわじわ来ますねえ．．．

「CPU数の不足」は原因ではなく結果では？

  • 当初の問題規模の見積もりの甘さ
  • 開発に携わったプログラマーのスキル不足．*2 *3
  • 開発期間，費用，人数の不足．
  • パフォーマンステストが不十分．
    • そもそもパフォーマンステストをしてなかった．
    • テストに使用した環境が本番と異なっていた．
    • テストに使用したサンプルデータが，十分に本番のものを反映していなかった．
    • テストに使用したアクセス数やユーザー入力が本番のものと異なっていた．
  • 利用しているクラウドサービスの完成度が低い
  • またイザという時の切り戻し手順を用意してなかった．（障害の原因ではないが，長引いている原因ではある．）

などなど、理由はいろいろ考えられるけど，CPU数の不足が「原因」というのは，それは違うだろう．

それはまるで患者は「交通事故で内臓破裂，頭蓋骨陥没，出血多量，全身複雑骨折」だけど，「死因は心臓の機能不全」と言ってるような気分だ．そんな発表しちゃったら，医者失格じゃね？

今回の刷新では、輸配送のリソース状況に応じた配送時間枠の提示と配車計画の自動作成を可能とするクラウドサービスを採用。ニトリホールディングス子会社で、ニトリの物流業務を手がけるホームロジスティクスが、伊藤忠テクノソリューションズが提供しているクラウドサービス「Mobile Asset Management Service（MAMS）」を宅配サービスの基盤として導入した。今回のリニューアルでの不具合とは関係ないとしている。

原因も特定できず，復旧の目処も全くたってない段階から，［クラウドには問題なかった］って断言しちゃっていいもんですかね．

http://b.hatena.ne.jp/entry/s/netshop.impress.co.jp/node/1818

http://d.hatena.ne.jp/napsucks/20081029/1225292613

  • id:anepan 主原因が逆な気がする。バグが多すぎて性能検証やってる余裕がなかったのでは（死
  • id:hsenyo 理由がわかってるなら、ここまで遅延？しないでしょ。。。
  • id:triggerhappysundaymorning また落ちてる?(11:52現在).CPUリソース不足って設計が糞だったのか,予算ケチり過ぎたのか...
  • id:Mu_KuP CPU能力不足とは、このご時世に珍しい。つか、純粋に演算能力が不足するとはなかなか納得しがたいなぁ。プログラムの出来不出来ってのは有りそうだが。
  • id:heroheroheroppi CPU不足は単なる現象であって無駄食いが潰せないのが原因だよね？時間かかるなら旧内容に巻き戻せばまだましな気が
  • id:MARQUE 17時に見に行ったけど、「現状復旧の目処がたっておりません。」に変わってた。これ、絶対CPU不足じゃないよ…
  • id:zanac-ai 6/23 18:15時点で見れないことはないが糞重いのはアクセスが集中してるからって事だと思いたい。
  • id:fujiyama3 よかった…失われたデータはなかったんや…。最悪、ファーストサーバみたいな悲劇になるかと思ったよ。
  • id:umisama 復旧めでたい、でも本当に要求性能の確認不足というシンプルな話だけなのかなぁ。/なんとなく「CPU不足」という語感がじわじわ来てる。
  • id:chikunai 原因はCPUじゃないに一票w これだけの期間があるなら、チューニングや部分改修で解決できるのでは。機能を縮小してオープンという手も
  • id:sankaseki 現時点(06/23 11:57)で17:00オープンにずれ込んだ模様/ところでCPUの不足ってなんだ？セッションを処理しきれなかった/サーバサイドの処理で使用率100%/組んだサーバにCPUが無かった どうととでも捉えられるよね
  • id:ssig33 負荷テストしてたけど本番環境にしかない考慮漏れがいくつもあって実は全然リソース足りてなかった を分かりやすく言ったつもりの言葉が「CPU の不足」なんじゃないですか
  • id:e-chikuwa CPU不足ってプログラマー人員不足の隠語なんだよ！！！ΩΩΩ
  • id:sin20xx ずいぶん胡散臭い。CPUネックなんて昨今のシステムでは結構レア。仮想サーバ使ってホストのバグ（HP-UX系）で当たる程度で根本的な問題はプログラムなんじゃねーのと思うのは勘ぐりすぎなんだろうか…
  • id:linus_peanuts 対外的な理由なんだろうけど嘘くさいよね。ニトリが契約時に無茶苦茶いうて買い叩いたんちゃうか……(そして泣くのは実働部隊)
  • id:hiromo2 性能は後回しでいいから→データ量で級数的に処理量が増えるクソロジックだらけ。みたいなのを想像。
  • id:toaruR カートとかパーソナライズ系をサーバ側で一括レンダリングする仕組みだとキャッシュ効率が落ちてリソースを食う。N+1やリアルタイムランキングや強力リコメンドなんてきっときっと
  • id:masatomo-m 単純なSQLで出せないN+1問題不可避なわがまま要件があって、それが2?3重に重なったりするとあっさり計算量は溢れるからなー。ボトルネックがわかりやすいと直す所探すのは楽な方だけど、影響範囲とか検証はつらそう
  • id:aodifaud09 そんなことより担当した会社と担当者の生死状態を報告して欲しい
  • id:tagomoris 「CPU不足」に違和感ある人がけっこういるみたいだけどアプリケーションサーバのライセンスがCPUコア数課金だったりすると追加発注にも時間かかるしやべー、みたいなのは普通にありそう

仮にもクラウドと名乗ってるならCPU数の変更は瞬時に可能でしょ．そうでないにしても，これだけ原因究明と対策に時間がかかり，再開の見込みさえ発表できてなかったのは別の理由と考えた方が筋が通る．

「ニトリのコードを見てニヨニヨする会」

http://hevohevo.hatenablog.com/entry/2015/06/24/010340
メモ．

なぜか数百行の空改行が何箇所もある。全部削れば1000行くらい圧縮できそう

jspの中で数百回ループさせてるとか，なんかそんなのじゃないかなあ．他も見ていて不安になる場所多数．


技術的負債が溜まりに溜まると，こんな感じになるんだろうなあ．だから技術的負債は貯めちゃいかんとあれほど．「後で返すつもりだった」なんて言ってても，実際に返せる人なら最初から貯め込んだりはしないんだ．

はてな匿名ダイアリー「俺の考えるニトリネットの顛末」

http://anond.hatelabo.jp/20150624204147
メモ．

基本的には怪文書の類なのだが，大本営発表が「CPU数が少ないのが原因（きり）」という謎文書だったため，その信用度はこの怪文書に劣るとも勝らない．

  • ニトリのシステムコンサル（経歴だけやたらすごいことを主張し横文字ばかり使う）がGoogleのパンダアップデートを機にニトリネットのリニューアルを提案
  • その際に、自分の懇意にしているシステム営業を連れてきて提案させる（CTC)
  • CTCのMAMSを導入することを決定し、基幹システム等のつなぎ込みプロジェクトが開始。
    CTCでの受注額はおそらく数億?十数億レベル（３年保守契約含む）→コンサルには５％キックバック
  • この時点で、以前にニトリネットを依頼してた会社（０社）の足切りを決定。
  • ０社は引き継ぎは１ヶ月しか行いませんと明言、ニトリ担当者了解する。
  • CTC下請けへ開発を投げる。そこそこ中堅規模の開発会社（A社）が５０００万で受注。
  • A社、いつも仕事を投げているB社へ８００万で発注。
  • B社、コンペで募った会社（C社、D社、E社）の中から、一番デザインが良さそうだったD社に３００万で発注。
  • D社、デザインはできるがシステム開発ができないので、よく外注依頼しているF君に１００万で依頼。
  • F君必死にJavaでシステムをシコシコ作る。
  • D社が上に上げたデザインが、ニトリ側で何度もリジェクトがかかり、作り直しを余儀なくされる。
  • それに伴い、F君の作業もいきつ戻りつ、リニューアル１ヶ月前の状態でトップページもまで完成していない状況に。
  • 不眠不休の１ヶ月を過ごし、ベータ版を完成させるが、ニトリ本社でのレビューで、これではリニューアルができないという決断になり、リニューアルを延期させる（この時点で５月）
  • ６月１日リニューアルということになり、さらなる不眠不休の作業が続くF君。
  • しかも遅れたんだからということで、追加仕様がバンバン舞い込む。
  • ６月１日も間に合わず、泣く泣く、２週間さらに延期とする。
  • なんとか見せれる形のものになったので、これ以上伸ばせないという決断になり、リニューアルを向かえる。
  • リニューアルは、新インフラ環境で行われたため、前の環境は残っていない。（会員データも登録しなおし）
  • リニューアルを行うが、高負荷対策が全く行われていないため、すぐにサイトがみれないようになりサーバーCPUは振り切る状態に。

怪文書なんだが，あってもふしぎじゃ無いと思わせるところが，SIerのすごいところだ．

*1:一応動いているが，画面ひとつ開くのに20秒も30秒もかかるようでは「復旧した」とは言わないだろ．この時間で，仮にもクラウドでこれでは先が思いやられる．

*2:とりあえずJavaScriptの書き方がおかしくね？他にも（拡張子）jspファイルの使い方がおかしくなってそう．見えないバックエンドの部分も同程度の問題を抱えているのでは．

*3:これも「スキル不足」は結果であって，真の原因は費用や期間の不足だったかもね．