パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

JR東日本の新幹線の電光掲示板が終日ダウン」記事へのコメント

  • by jizou (5538) on 2016年05月05日 9時52分 (#3007494) 日記

    なぜ二日間の合計で制限に引っかかるのかもわからないけれど...

    通常、1400 で、最大 1600 で制限かけてしまうのは、見積もりが甘いとしか思えない。
    しかも、そんな制限があるのなら、設定時にエラーメッセージを出すべき。
    最大値を超えたからだまって落ちるって、どんなプログラムなのかと。

    なさけないなぁ。

    • by NOBAX (21937) on 2016年05月05日 14時47分 (#3007567)
      メーカー「JRさん、新幹線は一日何本くらい出るもんですかね?」
      JR「そうですね。まあ、1600本ってところですかね。今はその半分もないし」
      メーカー「そうですか。じゃあ、それで設計しておきますね」
      担当者は皆去り、予想だにしなかった、北陸新幹線が開業し・・・・・・
      親コメント
      • by Anonymous Coward on 2016年05月05日 15時32分 (#3007591)

        このクラスのシステムがそんないい加減なわけないだろ。要件定義書に最大運行数が定義されてるに決まってる。

        #最大数を超えた場合のエラー処理の定義はなかったんですかね…。

        親コメント
        • by Anonymous Coward

          要件以上のデータ突っ込まれても1600個分は正常とみなして動く仕様というのも危険だから(そもそも入力データがバグってるのかもしれない)
          上限に達してますエラー返して、処理しないのが正しい動きなのでは?

          すぐに改修できるかは別にして、要因は比較的すぐに見つかったのでちゃんとエラーは返していたのかも。

        • by Anonymous Coward
          要件定義書は客にヒアリングしてメーカーが書くんだよ
    • by Technobose (6861) on 2016年05月05日 10時24分 (#3007497) 日記
      >最大値を超えたからだまって落ちるって

       仕事が多すぎて突然死したんじゃ?
      親コメント
    • by Anonymous Coward on 2016年05月05日 13時19分 (#3007544)

      なぜ二日間の合計で制限に引っかかるのかもわからないけれど...

      一日単位でテーブルを書き換えるとして、深夜便で日付跨ぎがあるなら二日分のテーブルを用意して半分ずつ更新していく...というしくみじゃないかな?

      正確には最大値が見積もれない場合って配列の大きさや容量ってどう決めることが多いですかね?
      請負物やクリティカルなところはきちんと要件定義されるでしょうが、それ以外の自分が使うツールとかそういう類のもので。
      私の場合は、過去の最大値の2倍を越える2の冪とすることが多いですね。
      #でも、/bootはこの原則通りだけど、/は4倍くらい取っているな。

      親コメント
      • by nim (10479) on 2016年05月06日 8時01分 (#3007809)

        >私の場合は、過去の最大値の2倍を越える2の冪とすることが多いですね。

        と思いきや、ツールの仕様で、256*1024*1024*1024 じゃなく、256*1000*1000*1000 になってたりすることががが。

        親コメント
      • by Anonymous Coward

        何でもかんでも仮想化して論理的にはほぼ無限に使えるようにしておいて、ソフト側は二度と触らない。
        ハードウェアリソースだけモニタリングして、限界が近づいたらリソースの追加投入で全てを解決できるようにする。

        のが理想だと思うけど、まぁ、言うは易しだな。
        組み込みなんかだとそもそもリソースの追加が難しいし。

        • by Anonymous Coward

          仮想化のオーバーヘッドでハードウェアへの要求仕様が跳ね上がっていくんですよね。
          #なんでこの測定に数分も掛かるの?っていう質問にCPUが遅いからって回答をみた時にはもう...

          • by Anonymous Coward
            CPU・メモリにばかり目を奪われて物理ネットワークI/Fが細すぎなホストにコンテンツ配信サービスや大規模認証サーバー等ネットワークI/O使用率の高いゲストを詰め込みまくる→アクセス数がピークに達した時にネットワークI/Oの段階でリクエストをさばききれなくなってタイムアウト連発や物理I/Fダウンとかね。アホかと。
    • by Anonymous Coward

      きっとあれだ
      最大値越えの試験なんてやってないんだよ

    • by Anonymous Coward

      エラーメッセージ無しで落ちたなんてどこにも書かれてないけど。
      それとも、電光掲示板にエラーを表示しろって話?

      • by Anonymous Coward

        エラー発生時にエラーを出せなんて誰も書いてませんが。
        登録データ数が上限に引っかかる時にエラーメッセージを出してないから、今回の問題が発生したって言ってるだけでしょ。

        仮にエラーメッセージ出してても、それを無視して処理を続行出来るようになってるのなら、それは処理を続行した運用担当者の責任だろう。

        • by Anonymous Coward on 2016年05月05日 14時52分 (#3007569)

          使っちゃダメって誰も言わなかったんだもん

          REM 例外処理って奥が深いですね

          親コメント
        • by Anonymous Coward

          出していないと言う断定も気が早いかと。
          「登録できずエラーが出ている」と分かったからって、即直せるもんでもないし。
          「あー、今日は電光掲示板無しで運行するっきゃないなぁ」と早い段階でシステムの使用は諦めて対処するしかなかったのかも。

        • by Anonymous Coward
          電光表示のシステムでエラーが出るからって、運行のシステムを使わなかったり
          ダイヤ変えたりはいまさらできないので、表示できないのは仕方なしとして強行したんじゃないのかなあ

          「JRの対応が早かった」的なこと言ってる客が居たので、承知の上運行開始したのだと思っている。
      • by Anonymous Coward

        そこはBSoDで。

        あと数年すると一瞬QRコードが出るかもしれない :)

    • by Anonymous Coward

      システム導入時には現在までの運行数の増大を予期していなかったんでしょ。よくある話じゃん。
      後からなら何でも言えるわ。

    • by Anonymous Coward

      こういうのはシステム落ちというより、表示内容に問題があってシステム止めるタイプじゃないですかね。
      データの不整合が発生しているのは分かっていたが、問題の規模把握や発生点の特定ができなかった、とか。
      障害の影響範囲を正確に判断できる技術者が休暇中だった、とか。

      まあ批判を免れうるものじゃないけどね。

    • by Anonymous Coward

      > しかも、そんな制限があるのなら、設定時にエラーメッセージを出すべき。

      想像だけど。

      入力するプログラムと、電光掲示板の表示を受け持つプログラムは別で、
      入力プログラムのほうは1600本以上でも問題なく扱えるようにできていた。

      だから人間が入力するときにはなんのエラーメッセージも表示されなかった。
      でも電光掲示板を制御するプログラムが1600本より多い件数が登録されたデータベースを
      正しく扱えなくて落ちた、という状況かもしれぬ。

      現行の電光掲示板の表示プログラムが、列車運行データーベースとは同時に開発されずに、
      予算の関係で、今年はデータベース管理のソフトウェア更新、来年は電光掲示板のソフト更新という風に、
      順次大量の本数に対応していくはずだったとかで、ソフトウェア間で扱える最大件数に食い違いがある
      時期が存在してしまうというのはありそう。

      • Re:設計値.... orz (スコア:4, 参考になる)

        by Anonymous Coward on 2016年05月05日 16時59分 (#3007622)

        COSMOSのシステム概要図 [ipa.go.jp]がありましたのでおいておきますね(リンクのP8)。
        お察しの通り運行管理系は正常に動いていたので、情報表示系の旅客案内制御装置のトラブルでしょうね。

        現行のCOSMOSは2015年の北陸新幹線開業による機能拡張、2016年の北海道新幹線開業によるCYGNUSとの連携 [hitachihyoron.com]と近年、機能拡張が相次いていたので北海道新幹線開業後の初の大型連休による臨時便増発が今回のトラブルの引き金になったのだとエスパーします。

        ただ風のうわさだと、上限値問題は過去に何度も痛い目にあっているので、北陸新幹線開業時に北海道新幹線開業も見越した処理上限値への見直しを実施したと聞いたのですが、情報表示系だけ漏れてたのか?

        瑕疵はJR東日本情報システムと日立製作所、どっちになるのでしょうねぇ。

        親コメント
    • by Anonymous Coward

      出たときには もうどうにならないんだよ

    • by Anonymous Coward

      ここらへん [mynavi.jp]が参考になるのかな?

    • by Anonymous Coward

      関連リンクにある、JR東の新幹線運行トラブル、管理システムの仕様を超えるダイヤ変更が原因
      2011年のヤツだけど、上限値で問題起こしたら関連するシステムで使ってる上限値を調べ直したり、見直したりするのじゃないのか?

      それやってても見落としたって事なのかな

      • by Anonymous Coward

        「俺、今回のその問題関係ないのになんで1-2日でそんな仕様そう洗いなんてしなきゃいけないんだよ。問題ないよ。ない」
        ということってありませんかね

ソースを見ろ -- ある4桁UID

処理中...