![バグ バグ](https://srad.jp/static/topics/bug_64.png)
甲賀市の水道使用量、新元号対応のシステム改修ミスの修正中にデータ消失トラブル 32
ストーリー by hylom
無駄な作業で消失 部門より
無駄な作業で消失 部門より
滋賀県甲賀市で、新元号対応のためのシステム修正におけるミスによって水道の検針データを消失するトラブルが発生した(中日新聞)。
甲賀市では2月下旬に水道関連のシステム改修作業が行われ、これによって検針票に記載された口座振替予定日が「1年5月7日」「1年5月31日」などと記載されるようになったという。この日付は間違ってはいないものの、新元号になる前に発行される検針票は改元が行われる5月以降の日付を「31年」と表記するルールで、これを修正作業を行なっていた際に1655件の検針データが消失したという。
なにやらかしたのかさっぱりわからん (スコア:1)
仕様で新元号になっても年度表記をそのままにすることにしていたのを
間違えて元年として入れた、ってのはわかるけど
その修正で何でデータが消失するんだ。
SQLで持っててオペミス?
Re:なにやらかしたのかさっぱりわからん (スコア:1)
検針票の印刷が、検針直後でないとできないシステムだと仮定すると、
検針票の印刷し直し、となった場合、現在の検針データを削除して検針しなおすことになりますが、
その過程で指針を間違って入力してしまった、しかも前の検針データも残ってなかった、
なんてことになったのではないかと想像。
Re: (スコア:0)
トランザクション処理せず一発入力したっぽいですかね
・データを削除→挿入で挿入がエラーになっているのに気づかなかった
・すぐに気が付いてコマンドが完了する前に中止した結果どこまで終了したかわからなくなってロールバックできなくなった
・もちろんレコード単位のリストアは非対応
だめじゃん (スコア:0)
表記をミスっただけでデータ自体は生きているんじゃないの?
>データのバックアップなどを徹底し
とあるけどバックアップも機能していない感じ?
だめだめじゃん
Re:だめじゃん (スコア:2, 参考になる)
残念ながら、特に公共系はベンダーに丸投げ状態なので、
はっきり言ってバックアップなど取っているほうが珍しいレベルですよ。
あとはバックアップを取っているつもりになっているだけ
(例: 差分バックアップ "だけ" をテープに書いてる)とか、
現場が回っていなさすぎてバックアップジョブのエラーが無視されてるとか、
いろいろありますが、いずれにしてもまともに書き戻せるバックアップを持ってるところは少数派です。
Re:だめじゃん (スコア:1)
>はっきり言ってバックアップなど取っているほうが珍しいレベルですよ。
システム構築時の要件定義に、蓄積しておくべきデータ類のバックアップ要項が入ってない・・・
というのは考えにくいけど、お役所仕事的にはあるあるなんかな
>いろいろありますが、いずれにしてもまともに書き戻せるバックアップを持ってるところは少数派です。
あるあるなんですね。
これは酷い (スコア:0, 興味深い)
市によると、二月下旬にシステム業者が改修作業を実施。この時に誤って設定された検針器があり、検針受託事業者の作業員が今月十五~十八日に行った検針で、日野町の一部を含む一万二千九百七十九戸で、検針票に口座振替予定日が「1年5月7日」「1年5月31日」と表記されたが、そのまま投函(とうかん)した。五月に新元号の元年になるため実質的には「1年」で間違いないが、新元号になる前に発行される検針票には、五月以降のことでも「31年」と表記する決まりだった。
五月に新元号の元年になるため実質的には「1年」で間違いないとか言ってるのが凄い。
平成31年とか昭和64年とか大正15年が存在しなくなる一番まずい元号改修。素人にやらせたのかよ。
これだけでも十分酷いニュースなのに、この上さらに
十八日に市が誤りに気付き、システム業者の指示で検針事業者が修正作業中、千六百五十五件のデータが消えてしまったという。
この有様。
新元号対応に失敗していることと、検針済みのデータ1655件を消失したことは全くの別問題なのに、どちらの件に対しても全く反省していない。
滋賀県民でなくて本当に良かった。
Re:これは酷い (スコア:2)
滋賀は巨大な水瓶だからね。
水道のトラブルなんかトラブルと思ってないのでは?
Re: (スコア:0)
いや、新元号に切り替わった5月以降の日付についてなので、「1年」で間違いではない。
ただし、元号切り替え前に発行される通知では、5月以降の日付でも「31年」と表記する仕様だったようだ。
その不具合を修正しようと作業中にやらかした
マジレスすると、 (スコア:0)
マイクロソフトが音頭を取った新元号対応ミーティングでも予測されていなかったケースなので、3月くらいから結構騒ぎになっているのです。
データ消失は全く別の問題なのですが、運悪く実害が出てしまい、その結果この「改元前の予告通知は改元前の元号を使う」問題が
公開されてしまいした。
4月に正式に元号が公開され、(Windows だと) レジストリの更新が起きてしまうと、より大規模な問題になるので、水面下で対応していたのに。
なんで、データ消すんだ...
まぁ、2019/4 中の、5月以降の日付をどう表記するか、って問題は、人によって感じ方が異なりますが、
「エリザベス一世の墓には一世とは書かれない」ってネタと同じ問題でありますな。
Re:マジレスすると、 (スコア:1)
https://qiita.com/KMKZ/items/7a530a127a438a13f333#%E3%81%9D%E3%82%82%E... [qiita.com]
「元号を改める政令」が施行されるまでは、たとえ5月1日以降の日付であっても平成を使わなければならない可能性があることを、1月にはすでに指摘していた人がいたようだ。
Re: (スコア:0)
> まぁ、2019/4 中の、5月以降の日付をどう表記するか、って問題は、人によって感じ方が異なりますが、
ひとにもよるだろうが、自分なら「2019年5月」「2019/05」などがいいなあ。
Re: (スコア:0)
>「1年」で間違いではない。
間違いではないのかもしれないが、元号表記するっていうなら「㋿元年」じゃないの?
Re: (スコア:0)
正しくはもちろんそうだけど、だから「実質的には」間違いではない、としてるんでしょう。
ちなみに、市のお知らせには「誤りがありました」と書いてあるだけなので、「実質的に間違いではない」を市が取材に対して言ったのか、記者が思って書いたことなのかはわからない。
http://www.city.koka.lg.jp/12698.htm [koka.lg.jp]
Re: (スコア:0)
表示/印刷の問題でしょ。存在しなくなるってどゆこと?元号で日付持ってるとか思ってる?
Re: (スコア:0)
2月のWindows Update [srad.jp]で、元号を含む日付をパースしていなければありえない不具合が続出したので、そんなのは夢物語に過ぎないことがすでに証明されている
あなたも酷い (スコア:0)
最後の一行いらないでしょ。
甲賀市の話ですよ。
次の検針で4ヶ月分請求にするのかな。 (スコア:0)
直近の検針データがなくなっただけなら前々回の検針データがあるはずなので次回の検針で4ヶ月分請求するのかな。
前々回の検針データもなくなってたらしらんけど。
そういう面倒くさいことはしない (スコア:0)
今回は、過去の水量を元にした水量(例えば直近半年分の平均水量とか)で請求して、
次の検針で帳尻合わせるんじゃないですかね。
お知らせ票の金額と請求額が合わない件はお詫び文書で凌ぐとして。
今回請求止めて次回まとめて請求、というのは、自治体にも住民にも業者にとってもうれしくないです。
Re:そういう面倒くさいことはしない (スコア:1)
雪国では、メーターが積雪で埋まっている期間は使用水量を推定して請求となっています
http://www.city.sapporo.jp/suido/riyosya/ryokin/meter.html [sapporo.jp]
使用者としてもこの運用が有利かと
Re: (スコア:0)
そっちのほうがよっぽど面倒でしょう。
もし推定値が大きすぎて、次の検針で払い戻しが必要になるレベルになったらどうなるのか?とか、考えなきゃいけないことが増えるし、リスクがありすぎる。下手をすると、メーターが一周回ったと判定されて超多額請求になりかねない。
それよりは、今回の検針は前回と同一値(使用料ゼロ)にするだけのほうが、トラブルが起きにくい。
Re: (スコア:0)
それよりは、今回の検針は前回と同一値(使用料ゼロ)にするだけのほうが、トラブルが起きにくい。
20㎥/2か月までは基本料金だけみたいだけど、超過料金が累進従量制だから、ゼロにした次の検針時に割高になるような。
http://www.city.koka.lg.jp/4113.htm [koka.lg.jp]
http://www.city.koka.lg.jp/secure/9094/jogesuidohayamihyo_8.pdf [koka.lg.jp]
Re:そういう面倒くさいことはしない (スコア:2)
20 ㎥分マイナスすればいいのでは
Re: (スコア:0)
最低料金ということだけでなく累進性があるんだから、次回分に全部乗せちゃだめでしょ。
データがない期間は平均的に使ったとして仮定してそれぞれ計算しないと。
Re: (スコア:0)
おのれ伊賀者 (スコア:0)
きたないな
さすがイガ=サン、きたない
# 時節柄、CherryBlossomの下でハイクを詠まざるを得ない
プレースホルダー (スコア:0)
次の元号のデータがおそらく空文字だからよかったな
Re: (スコア:0)
よく見るけどEmpty Stringを空文字って訳すのってどこの流派なの?
Re:プレースホルダー (スコア:1)
よく見るなら主流派なんじゃないの
Re: (スコア:0)
主流派というのか、それ以外の派閥があるかもって発想も持ちづらいレベルで浸透してるな。
最初に翻訳語として割り当てたのが何だったかわからんけど、時期的には形式記述のあたりかなぁ。
empty set が空集合なのは、コンピュータ以前の時代から、ほぼ固定の訳語だし、概念レベルでも empty set = emtyp string なわけで、string を文字列にしたら自ずと空文字列になっちゃうだろうな。
DBやプログラム言語側が、それと違う語句にする意味もないしな。
Re:プレースホルダー (スコア:1, 興味深い)
甲賀市は、ぜひともご検討を・・・ (スコア:0)
実害も出ていることですお寿司。
元号制定を違憲として国を訴える裁判が起こされる
https://srad.jp/story/19/03/28/0924235/ [srad.jp]