原因が特定できていない
ロールバックにリソース取られて、配信データの問題気づけなかったか、優先度としてロールバックするのはわからなくもないが、気づいてた人は居るのだろうな。
こういうことあるから有人窓口なくしたらだめだったのにな
また起こるよ、巻き込まれた方は怒るよ。
上位システムからの配信データの破損で、一部のICに鍵って障害になったんだろう？ メーカーによって若干動作が違うとかあったのだろうか？謎だなー
対応マニュアル整備
ETCカード使えなくても撮影したナンバープレートを元に料金請求できるなら、わざわざ高いETCの機材など搭載せずに、車両ナンバーにクレジットカード紐付けするだけで高速道路使えるようにすれば良いのに
データ破損は検算で検出できるし送信データと受信データを比較すればどこで壊れたか分かるのだがまだ分からないということは送信データを生成するプログラムにバグがあったか送信データの元データが壊れていたかかな
バイクだったら乗り放題だったって事？
利用者は大渋滞に遭い精算処理も求められて酷い騒動だった。
ナンバーから事後請求できて、「だったらETC存在価値無くない？」となったら面白い。
カード未挿入などと同じフローで後日の個別精算させてるのかな。不手際で手間をかけさせておいて、不正通行どうのこうの言うのはちょっとなあ
配信データの破損というマスコミ向けに丸められた表現にイラっとするよね。専門用語を普通に書いて解説すればいいだけなのに。
また起きそうだな...GWに再発したらタイヘンダナーコワイナー
広末の事故はこのトラブルと関係ないの？
ETC端末で車両を特定し、ETCカードで運転者(利用料支払いの主体)を特定するので、車両ナンバープレートだけだと請求先を特定出来ない。と言うのがETCシステムの建て付けなのでは？
公共インフラの障害はヤバイ
障害が発生してしまったのは仕方ないとして、せめて知識の共有のため詳細を公表してほしいな。
いまから高速のるとどうなるんだ？
データ破損というと全銀の障害を思い出しますね。あれはメモリ領域不足が原因だったっけ
ナンバーでの精算だと事前登録が必要で、登録した情報をセンター側で管理する必要がある。各料金所で車が通行するときセンター照会が必要になるから今の速度で追加できなくなる気がする。
車両ナンバー連動請求システムにしたら、偽造ナンバーで走り回る人が出るからやらないよ。走行車両数が多い路線会社とか、営業マンに納品させてる販社とかの車両ナンバーでやられたら、請求時点で気付けないから
ナンバーでＯＫとか言ってる人には雪⛄というものがあるのだと小学生の教科書を贈りたい
車両ナンバープレートだけだと請求先を特定出来ないけど駐禁は運転者不明なとき所有者に請求するんだから同じことできるよね別に
ナンバーは車に紐付けであって、レンタカーや知人の車だったら、持ち主が払うわけじゃないもんね。
ナンバーから請求するの新しめの駐車場だとよく見かける。偽装方法とかあるだろうから対策は必要そうだけど
4月5日：システム改修作業→4月6日：改修前にロールバック / どう考えても怪しい作業にしか聞こえない。DBに新規オブジェクトを追加後、ロールバックした際に旧マスタとの不整合が考慮されてなかった的な？
ナンバープレートオンリーだと請求が車自体に紐付くから、例えばレンタカーだと利用者への請求できないとかタイミングが合わないとか出そう。
やっぱりデータ破損か。さっさと解放したら逆に評価されたのに。
原因は中性子線だろうか｜広域管理システム側で配信用のデータを（別の場所の）原本と突き合わせていないのだろうか？……原本から配信用にデータ作成する段階で署名したりもしない？
NEXCO中日本管内で発生したETCの広域システム障害についてまとめてみた - piyolog
原因が特定できていない
ロールバックにリソース取られて、配信データの問題気づけなかったか、優先度としてロールバックするのはわからなくもないが、気づいてた人は居るのだろうな。
こういうことあるから有人窓口なくしたらだめだったのにな
また起こるよ、巻き込まれた方は怒るよ。
上位システムからの配信データの破損で、一部のICに鍵って障害になったんだろう？ メーカーによって若干動作が違うとかあったのだろうか？謎だなー
対応マニュアル整備
ETCカード使えなくても撮影したナンバープレートを元に料金請求できるなら、わざわざ高いETCの機材など搭載せずに、車両ナンバーにクレジットカード紐付けするだけで高速道路使えるようにすれば良いのに
データ破損は検算で検出できるし送信データと受信データを比較すればどこで壊れたか分かるのだがまだ分からないということは送信データを生成するプログラムにバグがあったか送信データの元データが壊れていたかかな
バイクだったら乗り放題だったって事？
利用者は大渋滞に遭い精算処理も求められて酷い騒動だった。
ナンバーから事後請求できて、「だったらETC存在価値無くない？」となったら面白い。
カード未挿入などと同じフローで後日の個別精算させてるのかな。不手際で手間をかけさせておいて、不正通行どうのこうの言うのはちょっとなあ
配信データの破損というマスコミ向けに丸められた表現にイラっとするよね。専門用語を普通に書いて解説すればいいだけなのに。
また起きそうだな...GWに再発したらタイヘンダナーコワイナー
広末の事故はこのトラブルと関係ないの？
ETC端末で車両を特定し、ETCカードで運転者(利用料支払いの主体)を特定するので、車両ナンバープレートだけだと請求先を特定出来ない。と言うのがETCシステムの建て付けなのでは？
公共インフラの障害はヤバイ
障害が発生してしまったのは仕方ないとして、せめて知識の共有のため詳細を公表してほしいな。
いまから高速のるとどうなるんだ？
データ破損というと全銀の障害を思い出しますね。あれはメモリ領域不足が原因だったっけ
ナンバーでの精算だと事前登録が必要で、登録した情報をセンター側で管理する必要がある。各料金所で車が通行するときセンター照会が必要になるから今の速度で追加できなくなる気がする。
車両ナンバー連動請求システムにしたら、偽造ナンバーで走り回る人が出るからやらないよ。走行車両数が多い路線会社とか、営業マンに納品させてる販社とかの車両ナンバーでやられたら、請求時点で気付けないから
ナンバーでＯＫとか言ってる人には雪⛄というものがあるのだと小学生の教科書を贈りたい
車両ナンバープレートだけだと請求先を特定出来ないけど駐禁は運転者不明なとき所有者に請求するんだから同じことできるよね別に
ナンバーは車に紐付けであって、レンタカーや知人の車だったら、持ち主が払うわけじゃないもんね。
ナンバーから請求するの新しめの駐車場だとよく見かける。偽装方法とかあるだろうから対策は必要そうだけど
4月5日：システム改修作業→4月6日：改修前にロールバック / どう考えても怪しい作業にしか聞こえない。DBに新規オブジェクトを追加後、ロールバックした際に旧マスタとの不整合が考慮されてなかった的な？
ナンバープレートオンリーだと請求が車自体に紐付くから、例えばレンタカーだと利用者への請求できないとかタイミングが合わないとか出そう。
やっぱりデータ破損か。さっさと解放したら逆に評価されたのに。
原因は中性子線だろうか｜広域管理システム側で配信用のデータを（別の場所の）原本と突き合わせていないのだろうか？……原本から配信用にデータ作成する段階で署名したりもしない？