アカウント名:
パスワード:
なぜ二日間の合計で制限に引っかかるのかもわからないけれど...
通常、1400 で、最大 1600 で制限かけてしまうのは、見積もりが甘いとしか思えない。しかも、そんな制限があるのなら、設定時にエラーメッセージを出すべき。最大値を超えたからだまって落ちるって、どんなプログラムなのかと。
なさけないなぁ。
このクラスのシステムがそんないい加減なわけないだろ。要件定義書に最大運行数が定義されてるに決まってる。
#最大数を超えた場合のエラー処理の定義はなかったんですかね…。
要件以上のデータ突っ込まれても1600個分は正常とみなして動く仕様というのも危険だから(そもそも入力データがバグってるのかもしれない)上限に達してますエラー返して、処理しないのが正しい動きなのでは?
すぐに改修できるかは別にして、要因は比較的すぐに見つかったのでちゃんとエラーは返していたのかも。
一日単位でテーブルを書き換えるとして、深夜便で日付跨ぎがあるなら二日分のテーブルを用意して半分ずつ更新していく...というしくみじゃないかな?
正確には最大値が見積もれない場合って配列の大きさや容量ってどう決めることが多いですかね?請負物やクリティカルなところはきちんと要件定義されるでしょうが、それ以外の自分が使うツールとかそういう類のもので。私の場合は、過去の最大値の2倍を越える2の冪とすることが多いですね。#でも、/bootはこの原則通りだけど、/は4倍くらい取っているな。
>私の場合は、過去の最大値の2倍を越える2の冪とすることが多いですね。
と思いきや、ツールの仕様で、256*1024*1024*1024 じゃなく、256*1000*1000*1000 になってたりすることががが。
何でもかんでも仮想化して論理的にはほぼ無限に使えるようにしておいて、ソフト側は二度と触らない。ハードウェアリソースだけモニタリングして、限界が近づいたらリソースの追加投入で全てを解決できるようにする。
のが理想だと思うけど、まぁ、言うは易しだな。組み込みなんかだとそもそもリソースの追加が難しいし。
仮想化のオーバーヘッドでハードウェアへの要求仕様が跳ね上がっていくんですよね。#なんでこの測定に数分も掛かるの?っていう質問にCPUが遅いからって回答をみた時にはもう...
きっとあれだ最大値越えの試験なんてやってないんだよ
if ( unko == 1601 ) error();
とかいうオチだったり
エラーメッセージ無しで落ちたなんてどこにも書かれてないけど。それとも、電光掲示板にエラーを表示しろって話?
エラー発生時にエラーを出せなんて誰も書いてませんが。登録データ数が上限に引っかかる時にエラーメッセージを出してないから、今回の問題が発生したって言ってるだけでしょ。
仮にエラーメッセージ出してても、それを無視して処理を続行出来るようになってるのなら、それは処理を続行した運用担当者の責任だろう。
使っちゃダメって誰も言わなかったんだもん
REM 例外処理って奥が深いですね
出していないと言う断定も気が早いかと。「登録できずエラーが出ている」と分かったからって、即直せるもんでもないし。「あー、今日は電光掲示板無しで運行するっきゃないなぁ」と早い段階でシステムの使用は諦めて対処するしかなかったのかも。
そこはBSoDで。
あと数年すると一瞬QRコードが出るかもしれない :)
結構あるな [google.com]オイ。
システム導入時には現在までの運行数の増大を予期していなかったんでしょ。よくある話じゃん。後からなら何でも言えるわ。
こういうのはシステム落ちというより、表示内容に問題があってシステム止めるタイプじゃないですかね。データの不整合が発生しているのは分かっていたが、問題の規模把握や発生点の特定ができなかった、とか。障害の影響範囲を正確に判断できる技術者が休暇中だった、とか。
まあ批判を免れうるものじゃないけどね。
> しかも、そんな制限があるのなら、設定時にエラーメッセージを出すべき。
想像だけど。
入力するプログラムと、電光掲示板の表示を受け持つプログラムは別で、入力プログラムのほうは1600本以上でも問題なく扱えるようにできていた。
だから人間が入力するときにはなんのエラーメッセージも表示されなかった。でも電光掲示板を制御するプログラムが1600本より多い件数が登録されたデータベースを正しく扱えなくて落ちた、という状況かもしれぬ。
現行の電光掲示板の表示プログラムが、列車運行データーベースとは同時に開発されずに、予算の関係で、今年はデータベース管理のソフトウェア更新、来年は電光掲示板のソフト更新という風に、順次大量の本数に対応していくはずだったとかで、ソフトウェア間で扱える最大件数に食い違いがある時期が存在してしまうというのはありそう。
COSMOSのシステム概要図 [ipa.go.jp]がありましたのでおいておきますね(リンクのP8)。お察しの通り運行管理系は正常に動いていたので、情報表示系の旅客案内制御装置のトラブルでしょうね。
現行のCOSMOSは2015年の北陸新幹線開業による機能拡張、2016年の北海道新幹線開業によるCYGNUSとの連携 [hitachihyoron.com]と近年、機能拡張が相次いていたので北海道新幹線開業後の初の大型連休による臨時便増発が今回のトラブルの引き金になったのだとエスパーします。
ただ風のうわさだと、上限値問題は過去に何度も痛い目にあっているので、北陸新幹線開業時に北海道新幹線開業も見越した処理上限値への見直しを実施したと聞いたのですが、情報表示系だけ漏れてたのか?
瑕疵はJR東日本情報システムと日立製作所、どっちになるのでしょうねぇ。
出たときには もうどうにならないんだよ
ここらへん [mynavi.jp]が参考になるのかな?
関連リンクにある、JR東の新幹線運行トラブル、管理システムの仕様を超えるダイヤ変更が原因2011年のヤツだけど、上限値で問題起こしたら関連するシステムで使ってる上限値を調べ直したり、見直したりするのじゃないのか?
それやってても見落としたって事なのかな
「俺、今回のその問題関係ないのになんで1-2日でそんな仕様そう洗いなんてしなきゃいけないんだよ。問題ないよ。ない」ということってありませんかね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
設計値.... 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: (スコア:0)
きっとあれだ
最大値越えの試験なんてやってないんだよ
Re:設計値.... orz (スコア:1)
if ( unko == 1601 ) error();
とかいうオチだったり
Re: (スコア:0)
エラーメッセージ無しで落ちたなんてどこにも書かれてないけど。
それとも、電光掲示板にエラーを表示しろって話?
Re: (スコア:0)
エラー発生時にエラーを出せなんて誰も書いてませんが。
登録データ数が上限に引っかかる時にエラーメッセージを出してないから、今回の問題が発生したって言ってるだけでしょ。
仮にエラーメッセージ出してても、それを無視して処理を続行出来るようになってるのなら、それは処理を続行した運用担当者の責任だろう。
On Error Resume Next (スコア:1)
使っちゃダメって誰も言わなかったんだもん
REM 例外処理って奥が深いですね
Re: (スコア:0)
出していないと言う断定も気が早いかと。
「登録できずエラーが出ている」と分かったからって、即直せるもんでもないし。
「あー、今日は電光掲示板無しで運行するっきゃないなぁ」と早い段階でシステムの使用は諦めて対処するしかなかったのかも。
Re: (スコア:0)
ダイヤ変えたりはいまさらできないので、表示できないのは仕方なしとして強行したんじゃないのかなあ
「JRの対応が早かった」的なこと言ってる客が居たので、承知の上運行開始したのだと思っている。
Re: (スコア:0)
そこはBSoDで。
あと数年すると一瞬QRコードが出るかもしれない :)
Re: (スコア:0)
結構あるな [google.com]オイ。
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日でそんな仕様そう洗いなんてしなきゃいけないんだよ。問題ないよ。ない」
ということってありませんかね