NW屋的新幹線通勤日記(3ヶ月限定名称)

ネットワークを専門にする元社内SEの日常とITネタ諸々を綴って行きます。

東証でシステム障害発生

 こんばんは。10日に医療情報技師合格発表がありましたので、昨日は関連記事を書きました。(続きは後日書いてみる予定です)

 今回は大きく取り上げられていた東京証券取引所でのシステム障害について書いてみます。こちらはNHKの記事からです。

www3.nhk.or.jp

 こちらの記事では、三菱UFJモルガンスタンレー証券やSMBC日興証券みずほ証券等の大手証券会社での障害発生と、その対応について書かれています。この記事では障害に関する原因については言及しておらず(調査中となってます)、「4系統中のうちの障害を起こした1系統を除く3系統で対応する」としかありませんでした。

 原因はどのあたりにあるのかについて、もう少し調べてみました。こちらは共同通信の記事からです。

this.kiji.is

 原因はメリルリンチ日本証券だという記述だけ書かれていました。もう少し詳しい情報がないかと調べてみました。こちらは日経の記事ですが、11日付の日経朝刊に詳細が載っていました。

www.nikkei.com

 「4系統中正常稼働している3系統に移行させる」という指示でどうにか復旧したようです。「なぜ正常系統に即座に切り替わらなかったのか?」という点が解説されていました。要点は以下の通りです。

  1. 売買注文要求ではなく、ログイン失敗による試行の繰り返しだった
  2. 売買注文以外の大量アクセスを想定してなくて、拒否しなかった
  3. 大手は回線切替手順が煩雑だった
  4. 大手は障害対応時の手順や対応等をシステムベンダに丸投げしていた
  5. 東証が「障害時は自動で即座に正常系統の回線に切り替わる」と信じていた

 上記各項目が理由のようです。1.に関しては、メリルリンチ日本証券の顧客に超高速取引業者がいて、大量のログイン試行を引き起こしたとのことです。これだけであれば証券会社システム内で留まる話なのでしょうが、DMAという取引形態の関係で、そのまま東証システム側にログイン試行に関するデータが流れたということのようです。

 となると、東証システム側・証券会社システム側で大量の(不自然な)通信を拒否するプログラムが必要になってくるのでしょうね。

 3.に関しては、様々なケースがあり、ケースごとによって切替手順が異なることが影響しているのだそうです。そのため、回線障害が発生しても、どうやって切り替えるのかが即座に判断出来なかったのではないかと推測されます。

 4.と5.は根っこが共通してますね。自組織に自ら手を動かして対応出来るエンジニアを抱えていなかったことに起因するんでしょうね。仮に自力で出来なくとも、的確に判断して常駐しているエンジニアに適切に指示出来るエンジニアがいなかったということになりそうです。丸投げ・無関心が呼んでしまった悲劇なのでしょうか…。