ローソンチケットのWebが42日ぶりに復旧 84
ストーリー by kazekiri
中の人も大変ですね 部門より
中の人も大変ですね 部門より
Anonymous Coward曰く、" ITProの記事によれば、 ローソンチケット・ドットコム のWebが何と10月24日に閉鎖してから、実に 42日ぶりに本日復旧した とのこと。原因はNECの MobilenetServer/WEBという製品のバグで NECからもお詫びがでている。このNECの製品は、クライアントに合わせて 携帯やPC向けのページに変換するフィルタのようなものらしいが、 MobilenetServer/WEBに高負荷がかかると稀に本来ユーザーに返信するべき Webページとは別のページを返すということがあり、それで ローソンチケットの顧客がアクセスしている最中に、本人以外の氏名、 電話番号、メールアドレス等が画面に表示されるという現象が起きて しまったらしい。それにしても一ヶ月以上この手の調査とバグ修整に 時間がかかるのはいただけませんね。"
がんばってください (スコア:3, 興味深い)
結構値段がするはずなので
致命的な欠陥があったら担当者は大変だろうな・・・
いやＮＥＣ製の携帯電話用交換機の仕様を
見たときちょっとびっくりした記憶があるので
ＮＥＣさんはもっと慎重にがんばるべきです
高負荷時の検証作業 (スコア:2, 興味深い)
トラフィック生成して高負荷状態作るだけでも面倒そうだし、
単純負荷じゃ駄目っぽいし。
Re:高負荷時の検証作業 (スコア:5, 参考になる)
トラフィック生成して高負荷状態作るだけでも面倒そうだし
そうでもないですよ。負荷テストツールならロードバランサの性能検証装置として数多くの製品があります。googleで見つかった順ですが、 diversifEye [empirix.co.jp] とか WebLoad [quality-net.co.jp] とか Web Capacity Analysis Tool [microsoft.com] とか。
あと、この手の高負荷時のソフトウエアバグはOSに問題がある場合を除けばファイルや共有メモリなどの競合(race condition)に原因があるものなので、テンポラリファイルや名前付きイベントの名前の生成方法など、時間をキーにしている部分を重点的にチェックしていくとよいです。
Re:高負荷時の検証作業 (スコア:2, すばらしい洞察)
>ファイルや共有メモリなどの競合(race condition)に原因があるものなので、
>テンポラリファイルや名前付きイベントの名前の生成方法など、
>時間をキーにしている部分を重点的にチェックしていくとよいです。
そういった類の「思い込み」が、解決に１ヶ月以上もかかった遠因では？
Re:高負荷時の検証作業 (スコア:1, 興味深い)
画面表示まではちゃんと行くんだが、そこから印刷に行かせると、時々別ユーザの紙が出てくる…ログとかとっておいてもそれなりに動いているように見えるし…
ライブラリが怪しいから調査してくれと依頼しても、そんなことはないと突っぱねられるし…
Re:高負荷時の検証作業 (スコア:4, 参考になる)
が、顧客の稼働中のシステムはそのバージョンアップまでなんて到底待てないので…
当該のライブラリ（顧客が「これを使ってくれ」と指定してきた製品だった）がおかしい事を上記検証用コードと、ライブラリメーカーからの「対処します」覚書で理解してもらったうえで、印刷時のみ、という状況から、印刷時に当該のライブラリの処理をする場合だけシリアライズするように処理を変更することをご提案。処理がぶつかった場合、多少余計に時間がかかりますが、まぁ印刷処理（画面表示に比べるとはるかに長い時間がかかる）なのでということで、確実に処理できるようにコードを修正。また、ライブラリのバージョンアップがあった後には、それを入れるかどうか＆この修正を戻すかどうかについては別途ご相談（費用が発生します）、ってことで最終的にはおちつきました。
…余談…
どうも、挙動を見た感じからすると、PDF作成時にライブラリの中で作るっぽい中間ファイルが、複数同時に走ると同じファイル名になってしまうケースがあったようで…これが一時ファイルで処理後にさくっと消されてしまうため証拠が残らず…かといって、ライブラリの中をリバースエンジニアリングして調べるわけにもいかず…現象を再現できる検証用コードを作るのに非常に苦慮しました…あのときはほんとに大変だったなぁ…
Re:高負荷時の検証作業 (スコア:1)
Re:高負荷時の検証作業 (スコア:1, 興味深い)
1.現象の再現 (要、高トラフィック環境)
2.不良と思われる箇所のソースチェック (ブラックボックス部(ライブラリ等)含まず)
3.ソースでは無さそうなのでブラックボックス部のメーカー調査依頼
4.メーカーから回答来るもはっきりせず、1.or 2.へ戻る
5.1～4の繰り返しで、やっとこさ該当箇所発見
6.メーカー提供の修正仮パッチ当てて再現テスト
7.修正できたと思われるのでメーカーと今後の対応打ち合わせ
8.修正を本パッチとしてメーカーリリース・サイト本修正
9.最終ランニングテスト
10.一般広報
まず1.の段階で時間がかなり掛かりそう。
下手すりゃ再現テストがWindowsではなく、再現しないLinuxで
メーカーがテストしていたとかの可能性も。(初歩的なミスの場合)
ただ、メーカーが絡んでも高負荷テストだと「調べてよ」と言っても
そう簡単にチェックが進むとは思いにくい。デバッガ使えそうに無いし。(←これ大きい)
Re:高負荷時の検証作業 (スコア:2, すばらしい洞察)
・顧客への報告書類作成
・再発防止策の策定と承認
・顧客立会いの下、再現及び同条件での修正後デモンストレーション
場合によってはシステムの総点検による別バグ出し＆潰し
安全性・安定性の確保とサービスの早期再開とはトレードオフの関係になりますので、修正そのものよりも顧客承認（を得るに足る試験工数と報告書の作成）に時間がかかるものだと思います。
Re:高負荷時の検証作業 (スコア:2, 参考になる)
個人的には (スコア:2, すばらしい洞察)
評価できると思います。
翌日復活して再発するよりははるかにマシ
Re:個人的には (スコア:1, すばらしい洞察)
大真面目に。
社内処分 (スコア:1)
>【社内処分】
>今回のシステム不具合によるサイト閉鎖に関し、
>皆様にご迷惑をおかけする事態を招いたことを踏まえ、
>代表取締役2名を減給10%3ヶ月の処分と致しました。
えぇと、そのシステムの担当者ではなく…？
代表取締役というのがピンとこないのですが、
世の中こういうものなんですか？
/*そういえばロッピー動かしてるのってWindows95
だったっけ。起動画面、見てみたい*/
Re:社内処分 (スコア:2, すばらしい洞察)
Re:社内処分 (スコア:1, 参考になる)
前の会社では責任者が一切責任をとりませんでした。
その代わりに辞める人が続出したけど。
Loppiのアレ (スコア:2, 興味深い)
> だったっけ。起動画面、見てみたい*/
数年前のことですが、偶然にもLoppiを再起動後の画面を店頭で見たことがあります。
例のWindows95のBMPを表示後、（多分640x480の）デスクトップ画面を表示してました。
当然なのでしょうけど、この状態で既にタッチパネルは認識してるらしく、
タスクバーの[スタート]メニューが押せて、スタートメニューの縦に
Windows95って書いてあったところまでは確認しました。
その後、Loppiが起動したのだろうと思うけど（なんかタスクバーに出てきてたから）
すぐに通常のLoppi画面に戻っちゃっいましたけど、客の身分でなかなかおもしろい経験ができました。
＃当然翌日は同僚に自慢。でも誰もWin95って信じてくれなかった･･･
Re:Loppiのアレ (スコア:4, 興味深い)
もっというと任天堂Power（ゲーム書き換えシステム）の営業停止時期ですね。同時に店内にサーバがついて、回線が強化されてレスポンスが大きく改善されました。今はさらにかわってたりするのかな？
Re:Loppiのアレ (スコア:2, 興味深い)
Re:Loppiのアレ (スコア:2, 興味深い)
そんなに負荷がかかるものでも入れ替えが必要なものでもないですし。
四隅をある順番で押すとOS画面に切り替わるパターンのが多いので
_自己責任で_お試しください。
Re:Loppiのアレ (スコア:1)
EZ2DJ なる ビートマニアのパチモノが入ってきたのですが
こいつの初代と二作目はWin98で動いてたと記憶してます。
FONTがハングルしてました。
そういや SEGAかどっかの タッチパネル式の
メダル預かり/引き出しの端末がWin98（95?）でした。
あの端っこに置かれたマウスカーソルと 時たま出てくる砂時計は間違いない
#結構いろんなところにWindowsってあるんだなぁと
#あ、オフトピで
Re:Loppiのアレ (スコア:1)
こういう装置にWindowsを使うもんなのかと驚いたもんです。
Re:Loppiのアレ (スコア:2, 興味深い)
ATMもかなり前からWin系ですね。
この分野はWindowsにとって大得意分野ですし、
（だからEmbeded Editionがある）
キオスク端末自体が非常に壊れやすいものなので、
わざわざ組み込みで作りこむより、
再起動or適当にリプレイスでなんとでもなるWin系の方が安価で便利です。
組み込み系だと、修理しようにもハードがもうない！とかありますし。
Re:Loppiのアレ (スコア:1, 参考になる)
Delphiかなにかのコンポーネントエラー吐いてWindows画面に落ちました。
その後すぐにウォッチドッグが動いて再起動。
買い物に行くたびに挨拶代わりに落として近所のローソンの店員には迷惑をかけました。
(おふとぴ)Re:Loppiのアレ (スコア:1)
「不当プラスモデ」をつけようとしたM1erがいました。
その上、その人は間違えて「不当マイナスモデ」にして
しまったみたいです(苦笑)
こんなM1erばっかりだったらヤだな～
＃これはオフトピなのでM1よろしく
Re:社内処分 (スコア:2, 参考になる)
それから、↓を読むとクライアントはW2kに代わっているようです。
http://premium.nikkeibp.co.jp/linux/case/case02/index.shtml [nikkeibp.co.jp]
#ライセンス的にまた更新するのかしら。。。
Re:社内処分 (スコア:4, おもしろおかしい)
Windows95からWindows2000に移行した裏ってやっぱり49.7日問題 [ascii24.com]でしょうかね？
24時間年中無休のコンビニでこんなの出たら使い物になりませんし。
＃Windows2000で497日 [nifty.com]にグレードアップして戻ってきた時にはモニターの前で茶吹いた
Re:社内処分 (スコア:2, すばらしい洞察)
NEC 側では社内処分ってないのかしら…? (ﾎﾞｿｯ)
むらちより/あい/をこめて。
Re:社内処分 (スコア:1, 興味深い)
少なくとも担当部門では, 事前に半期の業務目標としてNEC責任による障害発生N件とかを立てているはずなので, タイミングとしては夏の賞与の額が減るはずです.
まあ流通・製造といった民需部門のWEB系サポート部隊は, ここ数年の不況で官庁や金融サポート部門に人材を引っこ抜かれるわ, 中堅クラス以上のSE・営業が他社に行っちゃうわで大変みたいですけどね.
Re:社内処分 (スコア:1, すばらしい洞察)
42日間もサイト閉鎖したら、その分の振り替え業務はコールセンター等の他部門にも回ってくるし、業績にも影響が出るから株主への説明責任も生じる。代表取締役の責任は不可避でしょ。
Re:社内処分 (スコア:1)
当該システム導入を決定した事に対する責任、という訳です。
そういうのは書類に判押していったエライ人から順に責任が追及される
のは普通の事でしょう（そうでないとなんのために居るのかわからない
ですし）
重大なバグを内包した商品を納品した事により取引先に莫大な損失を
被らせた格好なるので損害賠償請求とかされそう。
（きっとNECの担当チームは上から下まで皆真っ青になってる事でしょう）
NECの方の担当者は減給程度で済むかどうか（汗）
Re:社内処分 (スコア:0)
>代表取締役というのがピンとこないのですが、世の中こういうものなんですか？
直接の担当者ではなく、上のものが責任を取るというのがアタリマエではないですか?
そのための管理職であり、代表取締役でしょう。
#担当者はすでに、減給対象にできない立場になっていたりして B-P
具体的に、 (スコア:1, 興味深い)
何がいただけないのでしょうか？
Re:具体的に、 (スコア:5, おもしろおかしい)
チケットが42日間いただけませんでした。
Re:具体的に、 (スコア:1)
サービスを止めてしまったことに対して「いただけない」んでしょ？
＃どういう意図の質問なのか、まるでお母さんが
＃優しく語りかけるように教えてください。
Re:具体的に、 (スコア:1)
「営業停止42日間」って、会社によっては倒産する場合もありますよね。
Re:具体的に、 (スコア:1)
＃そんなことも判らないからACのまま漢字も解らず噛み付きたくなるんだ！
と、混同した一例:-)
今回は時間の経過が「いただけない」という評価なのであって、
彼らのビジネスに対する取組み全体を見て言っている訳ではないでしょう。
そんなものの評価は、誰かやりたい人がやれば良い事です。
(大概は関係者のマスターベーションですがね)
大体、他人の評価に後から口出すこと自体が「いただけない」。
反論は十分な論拠を示してからにしてほしいものです。
Re:具体的に、 (スコア:1)
どうやって運用してゆくとか、手直しや機能追加する時とか、バグが見付かった時などの事は考えていられないのかもしれません。
不具合の要因切り分けを容易にするような設計手法って、どのようなものがあるのでしょうか？
そもそも (スコア:1, 興味深い)
この手の製品に限らず、広告とかを見てると、
・フィルタをかましてクライアントにより動的に適切なコンテンツを表示する
よりは、
・最初からクライアント毎に適切なコンテンツを見るように促す(携帯用は http://www.webiseite.dom/mibile/ みたいな感じ)
方が、システム的な初期導入/運用維持費用が安く済みそうなのは、素人考えなのでしょうか。
確かに同一URLにアクセスさせれば広告的な見栄えはするんでしょうけど、一度アクセスしてしまえばブックマークなり履歴から辿ることが多いんだよなぁ、とか考えると接続先のドメイン(URL)が多少長くても関係なかったりする訳で。
さらに言ってしまえば、QRコードで掲載してくれるともっとうれしい訳で。
Re:そもそも (スコア:4, すばらしい洞察)
重要なのは、コンテンツ製作者が複数クライアント向けに同じ内容のページを複数作らなくて済むことなんだと思います。
Re:そもそも (スコア:1)
気になって製品概要を確認してみて納得しました。
なんか考え方が違ってましたorz
http://www.sw.nec.co.jp/cced/mobilenet/intro.html
元の情報を、クライアント毎に適した形に修正するんですね。
てっきり、クライアントに適したコンテンツを振り分けるだけかと思ってました。
Re:そもそも (スコア:1)
図が気になるんですが、
携帯電話・PHS
・ iモード
・ Vodafone Live!
・ EZweb
・ ブラウザフォン
・ ドットi
・ H"
UAが「WILLCOM」だと知らんブラウザ扱いでパソコン用ページが返りそうな予感！！
# 今さらH"-Linkの人居るの？
UA定義 (スコア:3, 参考になる)
UserAgent定義ファイルがNECの登録ユーザー専用サイトにアップされており、
それをDLして読み込ませていました。
「○○（キャリア）の××（機種）でうまく表示されない」
「□□□の△△△で全部表示されず、次へボタンが出ない」
などと言われる度に、定義ファイルがアップされてないか専用サイトをチェックし、
切羽詰まると同キャリア同メーカーの、画面解像度の近い機種用の定義をカスタマイズしたものです。
NECに問い合わせるのもしょっちゅうでした。
それでもページの開発に比べれば工数が少ないので、重宝でした。
モデレート したいときには 権利なし
かつかれー
うまく表示されない (スコア:1)
Mobilenetとは無関係と思うけど、先月末に以下のようなことがありまして、
・ WILLCOMのWX310Kに機種変更
・ 追加機能をレジスト（FlashやらQRリーダやら）
・ 自販機に貼ってあった歌ジャケのQRコードを撮ってみる。
・ 解析されたURLに飛ぶ
・ Flashムービーが読み込まれる。データサイズが相当あるのか、かなり待たされる。
・ WX310Kの説明書にあるようにフォーカス当てたら操作には問題なし。
・ どう見てもPC用ページです。ありがとうございました。
うまく表示されてしまいました。文句が言えません。
Re:そもそも (スコア:0)
そうすれば動的に処理する必要がないので，負荷云々の問題は発生しない．
Re:そもそも (スコア:2, 興味深い)
ＰＣ用のブラウザのコンポーネント単位では種類が限られますが、
携帯端末は新機種の交代も早く、ブラウザの種類を追っていられないので
場合によってはフィルタ任せにしてしまったほうが
コストが低くなる場合もあると聞いたこともあります。
もちろんローソンがどうなのかは知りませんよ。
Re:そもそも (スコア:0)
・クライアント毎に適切なコンテンツに飛ばす
のは難しいんでしょうか。
自分じゃ静的 web ページすらろくに書けないので外してるかもしれませんけれど。
Re:そもそも (スコア:4, 参考になる)
たとえば、あらかじめ静的なコンテンツがクライアントの種類ごとに用意されているのであれば、同一のURLから適切なコンテンツへリダイレクトしたりするのは簡単です。
ブラウザやi-mode端末などのユーザーエージェントは、Webサーバへのアクセスの際に、「User-Agent」ヘッダで自らが何かを名乗るので（ブラウザによっては偽装できますが）、それを元に振り分けます。
Apacheなら、mod_rewrite [apache.org]が使われることが多いんじゃないでしょうか？
ただ、i-modeなどで端末の世代／対応機能／画像の解像度・色数・表示特性などに応じて、個々にコンテンツを用意しようと思うと、端末の発売ごとに、新しく静的に作るべきコンテンツが増えたり、振り分けのための設定をするといった対応が必要なので、こうした『箱』が求められるということはあるでしょうね。特に、動作検証ということになると、たとえばi-modeだけでも端末の種類は大量ですから大変な作業になりますから。
理想をいえば、携帯電話とPCでは、ページ間のナビゲーションやUIなども違ったものが求められるので、最低限、「携帯向け」と「PC向け」の2種類を用意しておいて、細かい違いを端末ごとに調整したいということになるんでしょうが、どうやらNECの問題の製品はその辺も考慮されているっぽいので、サイト運営側としては魅力に感じるんだろうな、と思います。
おそらく今回のようなチケット販売サイトは、コンテンツが動的に生成されている部分が多い（ほとんど？）と思われますので、振り分けるという発想ではなくて、アプリ側で対応することも不可能じゃないわけですが、新しい端末への対応を考えると、細かい端末ごとの対応は、こうした製品を使いたいところかもしれません。
現実問題としてこういうソリューションが必要なのはいたしかたありませんが、ほんらいなら、XHTML+CSSやHTTP/1.1のコンテントネゴシエーションなどのアプローチで対応できるほうが美しいとは思いますけど。
どっかに失敗事例のデータベースってのが有ったが (スコア:1, 興味深い)
Re:失敗知識データベース (スコア:3, 参考になる)
失敗知識データベース [jst.go.jp]
あぁ，あれだ． (スコア:1)
Web 4.2
意味不明だけど ID