2007年10月28日
| わからないなら専門家に聞け | （日常非日常） |
社保庁のシステムと云い、日本信号の自動改札機と云い、バグ内容についてわけのわからぬ報道が続いている。
まず社保庁だけど、
年金記録の持ち主を特定する手がかりの一つである生年月日のうち、日付がまるめられてコンピューターに記録された期間があり、社会保険庁が全国的に調査を始めたことが、２５日午前の参院厚生労働委員会で明らかになった。
(中略)
問題の日付は、１?９日が１日、１０?１９日が１０日、２０?２９日が２０日、３０、３１日は３０日として記録されている。
(中略)
原因について、蓮舫議員が「問題の時期にコンピューターを切り替えており、（正しく入力されたデータをまるめて変換する）プログラムミスがあったのではないか」と指摘したのに対し、石井部長は「その可能性を含めて調査している」と答えた。
asahi.com：生年月日まるめて記録、数十万人影響も 宙に浮いた年金
この記事（元の質疑応答でも？）では、どの時点で「丸められた」のかに言及していないので、なんとも云いがたいのだが、それならなぜ「プログラムミス」などと言う言葉が安易に語られるのだろう？
しかし、それよりもまず「生年月日をまるめて記録」と云う表現に違和感がある。
まるめると云うと、ふつうは金額等の数値に使うもので、日付や時間には使わないと思うのだが・・・それはともかく、ざっと考えただけでも可能性として
１．最初の入力時点からそのように入力された（マニュアルがあるはず）。
２．入力時点で、ソフトが下一桁を無視した。
３．システム移行時の変換ミス（プログラムでやったとは限らない）。
４．変換後のデータを新しいシステムが読み込む時点で切り捨てた。
５．そもそも日付は入力されていなかった（変換時か別システムが補った）。
６．。。。
ともかく、「６３?６６年度の４年間に就職や転職をしたり国民年金に加入したりした人のほとんどの生年月日が、そうした形で記録されていた」と言うのだが、「ほとんど」で全部ではない？のかとか、４年間だけなぜ？と謎だらけ。
次は先日の自動改札機が止まった問題の原因について、日本信号は具体的なバグの内容を発表したというのだが、これが発生当時に報道された内容に輪をかけた意味不明な内容。ほんとうにバグ内容を把握しているのだろうか？
障害の引き金になったのが、２バイト（２進法で１６けた）のデータだった。例えば改札機の場合、ネガデータは５４５１件分（６万５５１８バイト）を一区切りとして処理される。処理は４バイトずつ進めるため、最後に２バイト余る。全角ひらがなや漢字１文字分のデータ量だ。
半端な２バイトも、件数がこの一区切りまでなら正常に処理されていた。だが、５４５２件以上になると「８５件増すごとに５件の割合で、余った２バイトの処理を忘れる」（同社）というプログラムの欠陥があった。
asahi.com：１文字分のミスで大トラブルに 首都圏改札機トラブル
この内容・・・そもそも数字のつじつまが合わない。
5,451件分のデータでなぜ65,518バイトになるのか？
一件が12バイトの固定長だとすれば、5,451件で65,412バイトである。固定長でないとすれば、そもそも5,451件で65,518バイトなどと決め打ち出来ないわけで・・・
これはやはり、一部の情報にあるように、件数ではなく、データ内容に関係なくパケットでの区切りと考えた方が明快だ。2進数として区切りのいい65,536バイトには18バイト足りないけれど、ヘッダーとして18バイトを使うとすれば、これも明快につじつまが合う。
さらに「処理は４バイトずつ進めるため、最後に２バイト余る」に至っては、もうこれ自体がバグを暗示しているとしか云い様がない。
そもそもバイトデータと思われる元データ（パケット処理の話ならさらに・・・）を、4バイト区切り（int32かlongで扱ってるってことだろ？）で処理すること自体がバグの温床だ。正気のプログラムとは思えない。
あるいはデータとしては4バイト数値（int32またはlongが三つで12バイト・・・）だとしても、「最後に２バイト余る」わけで、パケットに分解された生データを扱っていると言う自覚なしのプログラムであることは明確だろう。
それにしても、２バイトの差を、全角一文字に喩えた記者は、よほど自分の（中途半端な）知識をひけらかしかったに違いない。が、あまりに中途半端すぎて、専門家の失笑を買うことしか出来なかったわけだが（笑
それはともかく、さらに謎なのは「８５件増すごとに５件の割合で、余った２バイトの処理を忘れる」と言うクダリだ。
この数字のつじつま合わせ・・・85件や5件の意味を誰か説明してくださ??い(-_-;)
なお、もし12バイト固定長だと仮定した場合は、85件で1020バイト。バッファーを1024バイト（2の10乗・・・）か1025バイト（1024+1）取っていれば、4バイト(か5バイト)が漏れる可能性まではわかった。が・・・まさかそれを５件と？
だとすると、当初の「特定のバイト数の時」と言うのが嘘になる。
それとも単に5,451件以降のネガデータは一見正常に処理されていたように見えて、実は単に「無視されてしまってた」だけの話だったのだろうか？
謎が謎を呼びすぎる報道の連続だ、今回の事件は。
投稿者 shoda T. : 2007年10月28日 20:21
トラックバック
このエントリーのトラックバックURL:
http://shoda.tk/MT/mt-tb.cgi/541
コメント
>説明してくださ??い(-_-;)
あー、わたしも前半の部分はあれこれ想像していたんですけど、この5/85が意味不明で、日記に書いてshoda T.さんに説明してもらいたいなあ、なんて考えてたんですね。うーむ、やはり意味不明ですかあ。
最近読んだ記事ではもっとも「難解」でありました :-p
投稿者 rcsakai : 2007年10月29日 10:57
たぶん誰もわかってないんだと思いますね。
想像ですが・・・
実際にプログラムした人間も良くわかってない。ただ、このあたりがバグってそうだという見当は付いてて、それを上司にテキトーに報告。たぶん少しは脚色も入っているんでしょう。
それが何段階のバッファーがあるのかは知りませんが、日本信号なんたらと言うシステム子会社の担当が書類にまとめて日本信号に報告。
その報告を読みながら、当然プログラムなどには何の知識もない広報担当か取締役秘書か誰かそういう立場の人間が広報資料を作成・・・そんなところでしょう :-)
これも想像ですが・・・
可能性としてありうるな、と思ったのは、パケットに分解された生データをそのまま1024バイトくらいのバッファーにコピーしては処理、と言うサイクルを繰り返しているプログラム構造ですね。
それで８５件までは正しく処理出来てるのですが、バッファーの切れ目に来ると正しいデータではないものを処理するようになり、それが５件くらい続いた段階で、再び元データに同期することがある。それでまた・・・
ただ、パケット区切りに来た時に、件数によっては続きのパケットデータがわずかなため、バッファーにコピーする段階か、それを処理する段階で、ありえないデータ領域に被さってアボートしてるのではないかと。
件数がさらに増えた場合は、一見するとちゃんとコピーは出来るので・・・
と言うわけで、実は正常に見えてる場合でも、ネガデータのかなりなものは取りこぼしてしまってたのではないか、と想像してます。
なんせネガデータですから、ミスって無視してしまっても、ほとんど問題ないわけですよ。
不正カードが正常なものとして処理されたとしても、誰も文句言いませんから（笑
逆に、読み間違ってたまたま正しいカードデータに「化け」てしまったデータもあったんじゃないか、とも思います。その場合、問題のカードは拒否されたわけですが・・・理由がわからないけれど、拒否されたカードと言うのも、考えてみれば結構あるわけですが、その一部には、この手のバグに引っかかったものもあったかも知れませんからね。
投稿者 shoda T. : 2007年10月29日 11:46
友人が立て続けにSuicaを「壊れたから交換」したことがありました。読めなくなって交換したカードが、またしばらくすると読めなくなる、というやつです。
どう考えても不思議だったんですが、今度の件を知ってみれば「なるほど」かもしれません。カード側に読めなくなる不具合が出たんじゃなくて、システム側にそもそも問題があった、と。
投稿者 rcsakai : 2007年11月01日 01:02
コメントしてください
名前とメールアドレスは必須です。メールアドレスはブログ上には表示されません。私に届くだけです。 TypeKey ID のサイン・インも必須ではありません。持ってる方だけサイン・インすればいいです。
