技術とか戦略とか

IT技術者が技術や戦略について書くブログです。

事例から見るシステム利用者に向けた理想的な障害報告

少し古い事例ですが、2020年10月01日の東証ArrowHead障害の会見から、システム利用者に向けた理想的な障害報告を見て行きたいと思います。
https://www.youtube.com/watch?v=Sokp32qOvyE
 
この会見は、障害報告のお手本と言える会見だと思います。
 
ビジネスを理解している者とシステムを理解している者を会見に同席させ、様々な観点の質問に的確に回答している点も素晴らしいですが、システム利用者に説明するべきことを冒頭で簡潔に報告していることも素晴らしいです。
この会見では以下の1~4のことが報告されており、これらのことは東証ArrowHead以外のシステムの障害発生時にも報告するべきことです。
 
システム利用者からすれば、1と2は現状を把握する上で必要な情報です。
また、今後の対応を行う上で、3も必要な情報です。
4は、サービス品質を保つ努力を示すために報告するべき情報です(もし障害対策に落ち度があれば、品質強化策や再発防止策を策定し、後日報告するのが望ましいです)。
 
----
 
【報告事項の概要】
1.障害の発生日時の報告
・2020/10/01の9時前(取引開始前)に、東証ArrowHeadの相場情報システムで障害発生。
 
2.意思決定も含めた障害対応の経緯と、利用者への影響
・原因は機器のハード障害である。
・障害により、株価等の相場情報を正常に配信することができなくなった。
・システム全体の整合性を保つことを優先し、当日中の障害復旧は行わなかった。
 (復旧による二次障害を防ぐことを優先した)
・主要プレイヤー(証券会社等)からヒアリングを行った上で上記の決定となった。
・障害復旧を行わなかったことで、終日売買停止となった。
・障害発生当日は、市場は開いていたが全銘柄注文が付かなかった、という扱いとした。
 
3.今後の対応予定
・ハードウェア交換作業を行い、翌日より通常通り取引可能な状態とすることとした。
・翌日の早朝(恐らく7時頃)、ホームページや広報を通してシステム状況を通知する。
 
4.障害対策を行ったのにも関わらずにユーザー影響に至った理由
・機器は多重化されており、フェールオーバー(機器切り替え)も想定されていた。
・フェールオーバーのテストも事前に行っていた。
・ハード障害は、自動でフェールオーバーすることができないという現象も起こした。
・手動でのフェールオーバーは可能であり、手順も用意されていた。
 (ただし、2にて前述した理由により、当日中のフェールオーバーは行わなかった)