最初に結論を書いておくと、
“図書館のシステムがダウンしたら利用者が逮捕される”なんて、「風が吹けば桶屋が儲かる」の理屈だと思うけれども、実際に起きてしまった。
システムを作るって、怖いね><
自分の能力不足からそんなシステムになってしまう可能性もあるから、色々勉強して、少なくとも同じ問題は起こさないようにしないと。
システム作成側の立場から見ると、この事件は具体的な教訓にも富んでいる。
・DB接続(コネクション)の管理、特に異常時の処理はきちんと考慮しなければならない
・負荷試験を行っていれば、この程度のバグは発見できたのではないか?
・ソースコードが公開された場所に置かれているとはなにごと?
・robots.txtの使い方
具体的な内容については高木浩光さんのウェブページが詳しい。
三菱図書館システムMELIL旧型の欠陥、アニメ化 - 岡崎図書館事件(7)
Anonymous FTPで公開されていたGlobal.asaが示すもの 岡崎図書館事件(6)
自分もシステムを作る側の人間でもあるので擁護してみたいが、
システムを作っていてバグが入り込んでしまうこと自体は仕方が無い。絶対に起こることだ。
しかしそれをなるべく減らす為にもテストというものを行う。
特にウェブシステムを作っていて大量アクセスした場合にどうなるかなんて、テストしないはずが無い。
今回の様にあからさまな問題が内包したままになっていたというのは、自分が作ったシステムだったらとても恥ずかしいorz
で、MDISの新システムでは、この接続の問題は解消されていた。
保守契約や瑕疵担保期間がどうなっていたか知らないので、旧システムについても無償で即時に直すべきだとは言わないが、旧システムを使っている図書館に注意するとか出来なかったのかなぁ。…しないんだろうなぁ。
(てか、そもそも新システムでこの点が改善されていたことを知らなかった可能性もあるかな。使っていたフリーソフトの中核部分が知らぬ間に改良されていたとすれば)
ソースが公開されていたなんて話もびっくり。なんてお粗末な話なんだ^^;
まぁサーバー管理者が新人だったりすると、そういう事にもなっても不思議は無いけど…。
システムを作った三菱電機インフォメーションシステムズ(MDIS)は、この件についてはあくまで「大量アクセス」が問題であると発表しているが、有志によって色々調査され、この図書館システムに問題があることははっきりしている。
障害が発生してサービス停止に陥ったmixiの場合、その分析内容(memchachedのバグ)をソースまで含めて開示しており、同業の人たちから高く評価されている。
トラブル時の対応(発表の仕方)って大企業の方が学んでいるはずなのに、変だねぇ(苦笑)
いずれにしてもシステムの担当者個人は(普段以上に)怒られているだろうし、つらいだろうな;;