東証システム障害による、終日売買停止という決断
最終的に誰の決断であったか興味深い。
私の個人的実感では、「よく決断できたな」
大局的な決断とも思えるし、システム担当者の助言に基づいた泥をかぶる決意をもった東証トップマネージメント判断だと推察。
複雑かつ巨大なシステム全体を理解している専門家の存在と東証トップマネージメントとの信頼関係が無くては出来ない。
経緯
- 障害発生が、7時4分
- 売買停止をすることを証券会社の売買責任者に通知 8時36分
- 共有ディスクの2 号機への強制切り替えを完了 9時26分
- 終日売買停止することを証券会社の売買責任者に通知 11時57分
東証システム障害、外部への情報発信の経緯が明らかに
xtech.nikkei.com
https://xtech.nikkei.com/atcl/nxt/news/18/08875/
システムとしては、9時26分に切り替えを完了していたので、再開は可能だったにもかかわらず、それから2時間以上経てから、終日売買停止としている。
真因は「切り替え失敗」とは別にある、東証システム障害の深層
https://xtech.nikkei.com/atcl/nxt/column/18/00001/04680/
フェイルオーバーの失敗は珍しくない
ハードウエアの故障は一定の確率で発生する。そこで、信頼性が求められる場合、故障が発生してもシステムが稼働を続けられるよう、故障した機器の役割を待機系など別の機器に自動で切り替える「フェイルオーバー」機能を用意しておく。だがフェイルオーバー機能が作動しないトラブルも、実はよくある。IT業界に身を置く人なら実感としてよく分かる
ホストである、サーバーの障害よりも、共有ストレージ障害の場合が、難しい場合が多く、そのため装置全体をスタンバイにするのではなく、ストレージ内部のハード構成自体を多重化させてストレージ自体の停止を極小化させる。そのため、BCPなどのサイト障害は、複製などの手段でデータ保護する。
データ損失防止や整合性を重視し、あえて手動の切り替えにする設計は、金融などではそんなに違和感はない。
障害が発生した場合は、あえて、システムを停止し、実行中のトランザクションとデータの更新範囲を人間が確認する。
確認後、再開する。
数時間掛かることはあっても、全日停止することは、あまり聞いたことがない。
緊急対応と復旧への準備に問題があった
システム障害の原因は朝のうちに特定でき、共有ディスク装置を交換してシステムを再起動すれば売買を再開できた。だが再起動すると証券会社側で通常と異なる対応が必要になるため、対応が難しいと東証は判断、終日の売買停止を決めた。
もちろん証券会社の意見を聞いて混乱を避けるのは、公正な取引を担う観点から必要な処置だ。東証は非常時の対応についてコンティンジェンシープラン（緊急対応計画）を用意しており、それに基づいて決断を下した。ただ、停止の条件や対応策については決めてあったものの、取引を再開するための取り決めや準備が十分ではなかった。
東証の終日停止判断は正しかったのか、auカブコム証券斎藤社長が提言
https://xtech.nikkei.com/atcl/nxt/column/18/00677/100600062/
xtech.nikkei.com
東証は市場関係者との協議により「システムを再起動すると（証券会社などから送信済みの注文の扱いなどを巡り）投資家などに混乱が生じると想定され、終日売買停止した」と説明する。auカブコム証券の斎藤正勝社長は「短時間で復旧するためのシステム対応やBCP（事業継続計画）の策定を怠ってきた一部の証券会社に全体を合わせることが本当によいのか」と異を唱える。
…
そもそも再起動すれば復旧できると分かっていながら、一部証券会社との対話により見送ったのは理解できない。
結局、取引が複数の証券会社のシステムに関わっており、すべての取引先が、取引中断に対する対応が可能か判断できず、結果として当日すべての取引をキャンセルすることで市場としての整合性の担保としたのだろう。
今後は、業界全体としての障害時対応、特に処理中取引への対応を規定・標準化し足並みを揃えることが必要だろう。
復旧かリカバリか
言葉としては同じだが、ストレージ障害の場合は、次のケースに分けられる。
最近のストレージは大容量なので、リストアには長時間が掛かり、システムが再稼働するまでに長時間を要する。
その昔、私の担当顧客で、ERPのデータが格納された、統合ストレージが、RAID構成HDDの多重障害が発生した。ユーザの希望で障害HDD(RAID)自体を復旧し、リカバリしないで再稼働できないか試行が行われた。海外の開發部門のサポートを受けながら試みたが、当日内には復旧できず、結果としてリカバリすなわちバックアップ・リストアにて再稼働。結果として、翌日までにはERPは再稼働できず、生産計画から工場への生産指示が間に合わず、工場の稼働が1日できなかった。数百人の生産現場が仕事ができないことになった。
ハード障害とその対応不備をユーザ担当から指摘され、以後弊社のストレージは発注停止、ほぼ出禁状態になった。
問題の本質は、リカバリを決断する基準を運用者が持っていなかったことだ。リカバリに要する時間目安があれば、「復旧」をあきらめるタイムリミットが持てた。しかも、運用者はERPが停止する影響範囲を把握しておらず、工場停止を想定できなかった。
後日,SIerから聞いた話では、ERPはバックアップされていたが、一部開發途上のシステムデータのバックアップがされておらず、運用担当者は「復旧」に固執していたとのこと。バックアップしていなかったことを上にしられたくなかったようだ。
すべての責任は、ハード障害を起こしたメーカとなり、製品部門長がユーザーマネージメントに謝罪することで決着。
ただし、以後弊社のストレージは発注停止、ほぼ出禁状態、以後のビジネスは既存機の保守のみとなった。
