「単純なミス」が引き起こした半日の取引停止

システム屋として、また株をやっている者として、バグの怖さ、テスト漏れの怖さを感じる。

今朝、イートレードの取引画面で「JASDAQシステム停止」と表示されていて「またか…」と思ってたけど、前場の取引全体がストップしてたからけっこうクリティカルなのかなぁと思いきや。

「単純なミス」が引き起こした半日の取引停止(via ITmedia)

8月29日、ジャスダック証券取引所のシステムに障害が発生し、午前中の取引が全面停止日となる事態に陥った。同社が29日夕方に行った記者会見によると、原因は「比較的単純なミス」（同社代表取締役専務の菊一護氏）という。

どうも、JASDAQと証券会社のシステム接続の設定値の変更で誤った値が設定されたから、ということらしい。その設定値は日立が計算から出すらしいんだけど、なぜ計算を誤ったのか、なぜテストまでしているのにそれをすり抜けたかってことか。

クリティカルなシステムでは、事前のテストおよび障害発生時のバックアップシステムが不可欠だ。ジャスダックでも日立と協力し、設定変更に関するテストを 3回実施してきた。しかし、テスト自体の前提（設計値）が間違っていたことから、ミスを見つけ出すことができなかった。バックアップシステムにしても、同様に間違っていた前提に基づく設定がなされていたため、切り替えても用をなさなかったという。

要するにテストデータもミスっていたので、問題が発見されなかったと。このプロジェクトでのチェック体制はどうなってたんだろう。現場の担当者の作業をチェックする仕組みがちゃんと機能していなかったのかな。それとも、意外とありがちな「その担当者以外にその部分をチェックできる知識を持ったメンバがいない」とかかも。

担当者による分業はどこでもやっているはずだけど、システム規模が大きかったりすると各担当者以外にその部分をフォローできる人がいないなんて事が発生しやすいと思う。そうすると、仮にレビューをしても、肝心な部分がレビュー漏れになったりして、それが後々まで気づかないと、今回のような事になる…と。

こういうときは総合的にチェックできる立場のアーキテクトを置いてレビューに参加させるべきだとか、プロジェクト内で情報共有をきちんとすべきという話しが良く出てくるけど、実際にやって上手く回せているプロジェクトってほとんど無いんじゃないだろうか。たぶん、あったら「成功事例」としてどっかの記事になるくらいまだ希少な例じゃないかな。

うちの会社も東証のシステムやっている会社がグループにあるし、携帯電話とか規模の大きいプロジェクトがあるし、今回のトラブルは人ごとではない。

だいぶ昔になるけど、私のミスで地元の某大企業のシステムを３時間くらい止めてしまったことがある。たまたま基幹システムではなかったのと、システムの稼働時間が決まっていたので稼働時間外に先輩方に復旧作業をしてもらって、なんとか事なきを得た。

その時の原因は、追加したスクリプトに全角文字が混ざっていてその部分が実行されなかったからだったと記憶している。Lotus Notes R4.6のLotus ScriptというNotes専用のスクリプト言語で、スクリプトをフォームに記述してNotesのデータベースに置き、あるイベント時に実行するというものだったけど、そのスクリプトを編集するNotes上の専用のエディタがスクリプトの構文エラー（全角が不正に混ざっているなど）をチェックせず、書いた通りに保存してしまうものだった。

そして、テスト環境から本番環境に同じコードを数カ所埋め込む必要があり、そのコードを単純にコピペしていけば何事もなく動いていたはずだった。それが、私は何を思ったか、ある一カ所だけはコピペじゃなくて、手打ちでそのコードを入力してしまった。

コードも数行だったので、直接入力しても問題ないと思ったかどうかは覚えていないけど、その時に記号かアルファベットだかに全角文字を入力してしまった。そしてそれをそのまま保存してしまった結果、実際に処理が実行された時に、異常動作でデータの更新がおかしくなるというトラブルを引き起こしてしまった。

確か入社３年目のころで、かなり落ち込んだのを覚えている。起こしてしまったトラブルは私ではどうしようもできなかったから、先輩たちがデータセンターで夜遅くまで復旧作業をしているのを、プロジェクト室でじっと待つしかできなかったあの数時間は、胃も痛かったし、この場から逃げ出したかったほど辛かった。

…おそらく、今回のJASDAQのトラブルを引き起こした原因の担当者も辛いんじゃないだろうか。自分への教訓として大きいけど、その代償も大きい。

No related posts.