ETCシステム障害、復旧までに38時間かかった理由は“見込み違い” 作業完了後に障害拡大

4月6日未明に発生したNEXCO中日本のETCシステム障害は、7日の午後2時にETCによる料金収受を再開するまでに約38時間を要した。同社が9日に開いた定例会見では、障害発生箇所の特定と復旧に手間取る様子が浮き彫りになった。 今回の応急復旧作業は、障害が発生した各料金所のシステムから優先して改修前の状態にもどす、いわゆるロールバック作業を行った。6日の午後6時にはそれが完了し、必要なデータを手動で試験配信して問題がないことも確認している。 ところが、7日の午前0時にETC課金に必要なデータの自動定時配信が行われると、再びシステム障害が発生。復旧作業前よりむしろ拡大する状況に陥ったという。なぜか。 NEXCO中日本は当初、新しい深夜割引に向けて5日に実施したサーバの追加がシステム障害の直接のトリガーになったとみていた（関連記事）。このため改修作業の対象だった地域管理システム以下の対応を優先し

[hobbiel55]

深夜割引関係の改修をした地域管理システム以下が原因と思ってロールバックしたが、実はより上位の広域管理システムの配信データが壊れていたと。タイミングが重なってなければもっと早くに復旧できてただろうに。

[hiroomi]

“同社が9日に開いた定例会見では”えー定例会見でする話なのか。サービスが提供できてないってのは、おまけの話なのかな。

[kuippa]

動いたことがない予備策は必要になったときに動かない。

[coinlocker]

直前の改修が障害の原因だろうとしてロールバックを掛け、手動のテストデータで通ることを確認したものの、原因は別で自動配信の本番データがアウトだったと。で、手動で正しいデータを入れて解消となった訳だ。

[me-tro]

一部のICのみで起きて、地域単位で全部ダメにならなかったのは何故なんだろ？もちろん一部で済んだのは不幸中の幸いなのだが…。わからぬ。

[defiant]

この記事をおすすめしました

[daybeforeyesterday]

うーむ

[sugimo2]

「料金所中心のマニュアルを作っていた。広域システム障害を想定したマニュアルはなかった。早急に取り組む」

[Kazumi007]

更新して不具合出たら、ロールバックするので、ソフト側の対応はベストだと思う。料金所側の対応は改善の余地ありという感じ。ETCが使えない時は無料で良い気がするけど。

[IGA-OS]

不具合箇所の特定。難しい構成だわね。しかしこれで渋滞起こして後払い請求するのは、運営部門の面の皮の厚さあるわね

[dogusare]

2025年04月09日縄田社長定例会見 https://www.c-nexco.co.jp/corporate/pressroom/interview/237.html 【説明資料】NEXCO中日本管内で発生したETCシステム障害について https://www.c-nexco.co.jp/images/press_conference/237/7276404767f64d9b45633.pdf

[lli]

目の前の障害に対応してたら後ろから刺された感じか

[letsspeak]

超速でパワポ作っててすごい（小並感）

[fai_fx]

宇宙線によるビット反転エラー。ということにしておけばよい。

[deep_one]

原因を完全に読み違えたのか…

[JULY]

トリガーは５日の作業だけど、その障害、および復旧作業がトリガーになって既存バグを踏んだ、と勝手に妄想してみた。

[wapa]

不具合発生時のロールバックが万能な策でない例だな。たまたま更新のタイミングで別の潜在不具合が露呈すると、発生要因と勘違いしてしまうという

[ledsun]

“自動配信されたデータが破損していたことを確認したのは7日の午前3時ごろ。データ配信を手動に切り替え、正しいデータの配信を実施したのが7日の正午” ロールバックでデータ破損が戻らなかったらしい