東北・上越・北陸新幹線の全44駅で電光掲示板が終日ダウン(復旧済み) 71
ストーリー by headless
足りねー 部門より
足りねー 部門より
東北・上越・北陸新幹線の全44駅で4日、行先や発車番線などを案内する電光掲示板「新幹線旅客案内装置」でシステムトラブルが発生し、終日案内情報が表示されない状態になったそうだ。運行自体は問題なく、各駅では手書きの案内や駅員の増員で対応したとのこと(NHKニュースの記事、
毎日新聞の記事、
日本経済新聞の記事、
YOMIURI ONLINEの記事)。
maia 曰く、
maia 曰く、
原因は、システムで設定された運行本数の上限が2日間の合計で1,600本のところ、5月3日～4日は臨時列車を含めて計1,606本あったためだという。駅員を増やしたりアナログな案内を強化したおかげで、大きな混乱はなかったとのこと。
なお、案内装置のトラブルは5日朝までに解消しており、5日は始発から正常に動作しているそうだ(毎日新聞の記事)。
設計値.... orz (スコア:2)
なぜ二日間の合計で制限に引っかかるのかもわからないけれど...
通常、1400 で、最大 1600 で制限かけてしまうのは、見積もりが甘いとしか思えない。
しかも、そんな制限があるのなら、設定時にエラーメッセージを出すべき。
最大値を超えたからだまって落ちるって、どんなプログラムなのかと。
なさけないなぁ。
Re:設計値.... orz (スコア:2)
JR「そうですね。まあ、1600本ってところですかね。今はその半分もないし」
メーカー「そうですか。じゃあ、それで設計しておきますね」
担当者は皆去り、予想だにしなかった、北陸新幹線が開業し・・・・・・
Re:設計値.... orz (スコア:1)
このクラスのシステムがそんないい加減なわけないだろ。要件定義書に最大運行数が定義されてるに決まってる。
#最大数を超えた場合のエラー処理の定義はなかったんですかね…。
Re: (スコア:0)
要件以上のデータ突っ込まれても1600個分は正常とみなして動く仕様というのも危険だから（そもそも入力データがバグってるのかもしれない）
上限に達してますエラー返して、処理しないのが正しい動きなのでは？
すぐに改修できるかは別にして、要因は比較的すぐに見つかったのでちゃんとエラーは返していたのかも。
Re: (スコア:0)
Re:設計値.... orz (スコア:1)
仕事が多すぎて突然死したんじゃ？
Re:設計値.... orz (スコア:1)
なぜ二日間の合計で制限に引っかかるのかもわからないけれど...
一日単位でテーブルを書き換えるとして、深夜便で日付跨ぎがあるなら二日分のテーブルを用意して半分ずつ更新していく...というしくみじゃないかな？
正確には最大値が見積もれない場合って配列の大きさや容量ってどう決めることが多いですかね？
請負物やクリティカルなところはきちんと要件定義されるでしょうが、それ以外の自分が使うツールとかそういう類のもので。
私の場合は、過去の最大値の2倍を越える2の冪とすることが多いですね。
#でも、/bootはこの原則通りだけど、/は4倍くらい取っているな。
Re:設計値.... orz (スコア:1)
＞私の場合は、過去の最大値の2倍を越える2の冪とすることが多いですね。
と思いきや、ツールの仕様で、256*1024*1024*1024 じゃなく、256*1000*1000*1000 になってたりすることががが。
Re: (スコア:0)
何でもかんでも仮想化して論理的にはほぼ無限に使えるようにしておいて、ソフト側は二度と触らない。
ハードウェアリソースだけモニタリングして、限界が近づいたらリソースの追加投入で全てを解決できるようにする。
のが理想だと思うけど、まぁ、言うは易しだな。
組み込みなんかだとそもそもリソースの追加が難しいし。
Re: (スコア:0)
仮想化のオーバーヘッドでハードウェアへの要求仕様が跳ね上がっていくんですよね。
#なんでこの測定に数分も掛かるの？っていう質問にCPUが遅いからって回答をみた時にはもう...
Re: (スコア:0)
きっとあれだ
最大値越えの試験なんてやってないんだよ
Re:設計値.... orz (スコア:1)
if ( unko == 1601 ) error();
とかいうオチだったり
Re: (スコア:0)
エラーメッセージ無しで落ちたなんてどこにも書かれてないけど。
それとも、電光掲示板にエラーを表示しろって話？
Re: (スコア:0)
エラー発生時にエラーを出せなんて誰も書いてませんが。
登録データ数が上限に引っかかる時にエラーメッセージを出してないから、今回の問題が発生したって言ってるだけでしょ。
仮にエラーメッセージ出してても、それを無視して処理を続行出来るようになってるのなら、それは処理を続行した運用担当者の責任だろう。
On Error Resume Next (スコア:1)
使っちゃダメって誰も言わなかったんだもん
REM 例外処理って奥が深いですね
Re: (スコア:0)
出していないと言う断定も気が早いかと。
「登録できずエラーが出ている」と分かったからって、即直せるもんでもないし。
「あー、今日は電光掲示板無しで運行するっきゃないなぁ」と早い段階でシステムの使用は諦めて対処するしかなかったのかも。
Re: (スコア:0)
そこはBSoDで。
あと数年すると一瞬QRコードが出るかもしれない :)
Re: (スコア:0)
システム導入時には現在までの運行数の増大を予期していなかったんでしょ。よくある話じゃん。
後からなら何でも言えるわ。
Re: (スコア:0)
こういうのはシステム落ちというより、表示内容に問題があってシステム止めるタイプじゃないですかね。
データの不整合が発生しているのは分かっていたが、問題の規模把握や発生点の特定ができなかった、とか。
障害の影響範囲を正確に判断できる技術者が休暇中だった、とか。
まあ批判を免れうるものじゃないけどね。
Re: (スコア:0)
> しかも、そんな制限があるのなら、設定時にエラーメッセージを出すべき。
想像だけど。
入力するプログラムと、電光掲示板の表示を受け持つプログラムは別で、
入力プログラムのほうは1600本以上でも問題なく扱えるようにできていた。
だから人間が入力するときにはなんのエラーメッセージも表示されなかった。
でも電光掲示板を制御するプログラムが1600本より多い件数が登録されたデータベースを
正しく扱えなくて落ちた、という状況かもしれぬ。
現行の電光掲示板の表示プログラムが、列車運行データーベースとは同時に開発されずに、
予算の関係で、今年はデータベース管理のソフトウェア更新、来年は電光掲示板のソフト更新という風に、
順次大量の本数に対応していくはずだったとかで、ソフトウェア間で扱える最大件数に食い違いがある
時期が存在してしまうというのはありそう。
Re:設計値.... orz (スコア:4, 参考になる)
COSMOSのシステム概要図 [ipa.go.jp]がありましたのでおいておきますね（リンクのP8）。
お察しの通り運行管理系は正常に動いていたので、情報表示系の旅客案内制御装置のトラブルでしょうね。
現行のCOSMOSは2015年の北陸新幹線開業による機能拡張、2016年の北海道新幹線開業によるCYGNUSとの連携 [hitachihyoron.com]と近年、機能拡張が相次いていたので北海道新幹線開業後の初の大型連休による臨時便増発が今回のトラブルの引き金になったのだとエスパーします。
ただ風のうわさだと、上限値問題は過去に何度も痛い目にあっているので、北陸新幹線開業時に北海道新幹線開業も見越した処理上限値への見直しを実施したと聞いたのですが、情報表示系だけ漏れてたのか？
瑕疵はJR東日本情報システムと日立製作所、どっちになるのでしょうねぇ。
Re: (スコア:0)
出たときには もうどうにならないんだよ
Re: (スコア:0)
ここらへん [mynavi.jp]が参考になるのかな？
Re: (スコア:0)
関連リンクにある、JR東の新幹線運行トラブル、管理システムの仕様を超えるダイヤ変更が原因
2011年のヤツだけど、上限値で問題起こしたら関連するシステムで使ってる上限値を調べ直したり、見直したりするのじゃないのか？
それやってても見落としたって事なのかな
Re: (スコア:0)
「俺、今回のその問題関係ないのになんで1-2日でそんな仕様そう洗いなんてしなきゃいけないんだよ。問題ないよ。ない」
ということってありませんかね
ソフトウェア更新 (スコア:2)
日テレ [yahoo.co.jp]
どう直したんだろう。
Re:ソフトウェア更新 (スコア:2)
unko unkoArray[1600] → unko unkoArray[1606]
じゃね？
Re:ソフトウェア更新 (スコア:2, 参考になる)
1800だそうです。
＜ＧＷ＞Ｕターンラッシュ ピーク 新幹線掲示板間に合った
http://headlines.yahoo.co.jp/hl?a=20160505-00000018-mai-soci [yahoo.co.jp]
Re: (スコア:0)
3200ぐらいにしちゃえばいいのに。
Re: (スコア:0)
ウンコにもほどがある
Re:ソフトウェア更新 (スコア:1)
運行だけに
Re: (スコア:0)
[○] 1606件のunkoデータ投入で正常動作すること
[○] 1607件のunkoデータ投入で正常動作しないこと
テスター「おっけー、境界値もバッチリ仕様どおりっ」
#あるある
Re: (スコア:0)
それで正しいのでは？
１６００の仕様で設計合意してその通り実装して、例えば実は１６０００までOKならオーバースペックだからJR側は嬉しいかもしれないがソフト屋は仕事なくすよ？
Re: (スコア:0)
そういう馬鹿な考えしてると普通は結局競争相手に仕事取られてなくなるけどSI案件だからまあ
Re: (スコア:0)
いいえ、逆に10倍の仕様にするなら要求通りの設計なら10分の1の価格でできたということで訴えられるよ？
Re: (スコア:0)
いいえ、逆に10倍の仕様にするなら要求通りの設計なら10分の1の価格でできたということで訴えられるよ？
それはない。
Re: (スコア:0)
いえ、実際にそういう問題になったことあるので
Re: (スコア:0)
その結果ハード側が過熱して数億円の被害が生じた…なんて結果になりかねないので、
仕様は守っておくことに越したことはないっす
Re: (スコア:0)
暫定システムやプロトタイプじゃ有るまいし、そんなお粗末な作りやるか？
サイズ上限や拡大縮小単位を設定値あたりに持たせてるのではないのかな？
上限設定変更をソフトウェア更新と言ってるも思う。
Re:ソフトウェア更新 (スコア:2)
5日以降は、登録本数を 1600本以下に抑えるようにした... だけだったりして。 :p
# 通過する貨物列車とかの登録をやめれば 6本ぐらいなんとかなるでしょう。
## だから余計な列車は登録するなとあれほど。
Re: (スコア:0)
非実用的な特殊な列車も結構きっちり登録されてますな。
ちょっと遠出しようといつも使っている時刻表検索で検索したら、
臨時列車扱いで、年に何回かしか運行されていないSLがヒットしたことがあります。
乗れたら乗りたいけど、数ヶ月前からチケット売り切れだろ、それ、と。
Re: (スコア:0)
そういえば美術館列車とか追加されてましたね。
Re: (スコア:0)
＞どう直したんだろう。
WindowsXP HomeeditionからWindows XP 64-Bit Editionに変更して枠エリアのメモリを64GBまでふやした
Re: (スコア:0)
わざわざIA-64にしたのか…(AMD64ならx64 Edition)
Re: (スコア:0)
IA-64 Itanium じゃなくて、IA-32(x64)かな？
Re: (スコア:0)
5日になったら1600本以内に収まったので自然に直った、とかじゃないか？
5/6(金)は一応平日だから臨時列車が少なくても不思議ではないし
システムはそのまま
以後は1600本を越えないように気を付けて運用する
（で、土曜にまた動かなくなったりして）
Re: (スコア:0)
電光掲示板の仕様を超える分はミステリートレインに変更したんでしょう
足下の乗車口シールが役立ちました (スコア:2)
４日に大宮駅からはくたかに乗りました。
ホームに上がったときは、ホーム頭上の電光掲示板式の乗車口案内は消灯していたため、自分の指定された号車の乗り口がどこか分からないかと思ったのですが、足下に号車入りの乗車口シールが貼ってあったので助かりました。
アナログな案内も有用だと感じました。
関連ストーリー (スコア:0)
東証、注文殺到で売買の全面停止
http://srad.jp/story/06/01/18/066231/ [srad.jp]
行き先は車両の種類でわからなくはない (スコア:0)
行き先ごとに車種が違うから、乗る電車を間違えて北海道で海鮮親子丼を食べてる筈が富山で鱒寿司食べてた何て事は少ないでしょう。
数年ぶりに使うと車両と編成の名称が変わっててわけわかんないことになるかもしれないけど、帰省なら並んでるおばちゃんに話しかけて言葉が通じればそこが正解。
観光や初めての出張だと金沢に行く筈が新潟にいたなんて事はあるかもしれない。
駅員さんが誘導してたんならまあ大丈夫でしょうけど。