東証の障害報告書を読んだ

東証の障害報告書(調査報告書)が最近公開されました。今日は報告書を読んで自分が感じたことを整理します。

障害内容

東証システム障害、新社長は「責任の一端はわれわれに」 富士通には「システム開発に全力を挙げて」 - ITmedia NEWS

報告書

https://www.jpx.co.jp/corporate/news/news-releases/0020/nlsgeu00000553vh-att/nlsgeu00000553yv.pdf

報告書を読もうと思った経緯

システムの運用・保守サポートも実施している自分は、これまでに複数回の障害に出くわし、対応した経験があります。*1

ただ、報告書についてはまだ作成経験がないので、東証の報告書を通し、来たるべき時に備えて勉強しておこうと考えました。(来たるべき時が一生来ないのが一番幸せなのは間違いないですが)
なお、東証の報告書を題材としたのは、障害後の東証の会見が素晴らしかったので、報告書のクオリティにも期待が持てたからです。
以下、編ごとに報告書を読んで感じたことを記載していきます。

第1編～当委員会及び本調査の概要～

調査委員会を立ち上げるというのは、障害の規模を表していますね...
費用が記載されているのは新鮮でしたが、いまひとつ記載意図が分かりませんでした。

第2編～現物株式売買システム(arrowhead)の概要～

全体的に説明の粒度が綺麗にまとまっていて分かりやすいです。(専門用語が過度に使用されていたり、抽象度が高すぎて誤解を招くような表現がないように感じました)
なお、運開分離が明確に記載されている以下の一節には闇を感じました...(運用部門の方々は特に大変そうです...)

開発部門と運用部門によって、システムの運用・維持を行っており、日々の運行については運用部門と運用ベンダが 24 時間 365 日体制で実施している。

第3編～本障害に関する事実経過～

この辺りから障害報告書感が強くなっています。
3編では、時系列で細かく事象が記載されているのは参考になりました。
障害が発生すると、基本的に混乱状態に陥ります。混乱の結果、個々がばらばらの粒度で報告をし出して、後で振り返った時に事実確認が上手くできないことが容易に想像されます。
障害発生時、障害報告書に記載する粒度に落として情報整理する人の重要性を改めて実感すると共に、情報整理する立場になった時は、東証の報告書の粒度を参考にして、足りない情報を補っていきたいと思いました。

第4編～本障害発生の原因～
第5編～障害発生当日中の取引再開ができなかった原因 ～

動かない状態での品質担保の難しさを以下の文章で痛感しました。

1 つ目の原因は、故障時の切替え設計等、重要な設定を決める局面においても、製品マニュアルのみを拠り所としていたことである。非互換調査も実施したが、マニュアル確認のみでは「オンパニック」の機能の変化に気付くことはできなかった

また、コミュニケーションミスについても詳細に記載されていて、好印象を持ちました。

富士通システムエンジニアから富士通製品担当に対して、「オンパニック」を含む arrowhead の各種設定値の内容は連携されているが、その際
に東証の要件は伝えられておらず、富士通製品担当はシステム内での機器の動作というより製品仕様に照らして機器全体の設定項目間で矛盾がないかという確認を行うにとどまっていた旨、富士通から報告を受けている

激昂した顧客に対しても、曖昧な表現で誤魔化すのではなく、原因を包み隠さず話す姿勢が結果的に信頼を生むことも改めて認知できました。(障害が起こる原因って冷静に振り返ると初歩的なミスが多いので猶更隠したい気持ちが強くなってしまうので...)
調査委員会を置いていることもあると思いますが、客観的かつ論理的な表現が多く、読みやすかったです。

第6編～再発防止措置～

第4編, 第5編の原因との結びつきがされており、複数の角度から対応案が記載されていました。
また、NAS の設定値の総点検をはじめとした横展開策についても、利用者からの信頼性を向上させるためには必要不可欠なものだと実感しました。

第7編～将来に向けた提言～

スローガンとか行動指針に引っ張られて、本当にあるべき姿を見失うものの怖さと、100点を常に目指すフォースが働くことの怖さを以下の文章で実感しました。

また、現物株式売買システムにおいて「Never Stop」というスローガンを目指すべきことは当然であるが、当該スローガンを強調しすぎるあまりに、システム障害が発生した際にも、8 時からの注文受付、9 時からの取引開始という対応を絶対的なものと捉え、それを前提として対処することにより、結果として障害回復後の取引再開をスムーズに行うことができないということとなったのは本末転倒である。

また、最後のまとめは最もだと思いつつも、いきなり努力とか抜本的なIT体制改革とか定性的な話が出てきて、少し違和感を持ちました。

我が国証券市場におけるセントラル・マーケットを運営しているという東証及びその親会社であるJPXが担う役割の重要性及びその影響の大きさを十分に自覚し、社内対応体制の強化に向けた不断の努力が求められる。

金融商品取引所はシステム、ITの装置産業と言っても過言ではない。JPX及び東証の市場における重要性に鑑みれば、独自のシステム開発能力、設計監理力、保守運用力をさらに高めるための検討も必要ではないだろうか。そこで、中長期的には、JPX グループ内におけるシステム設計・監理機能の向上、IT・システム研究部門の創設、IT部門の能力増強・人員強化に向けた計画的な投資増大等、抜本的なIT体制改革も選択肢の一つとして検討することが望まれる。

参考資料

最後に、東証の報告書を読む前に、報告書のあるべき姿をインプットするために参考にした記事を残しておきます。

エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita

失敗を学びに変える「障害報告書」の書き方 ─ RettyのCTOがGoogleで学んだ「問題を隠さない文化」 - エンジニアHub｜若手Webエンジニアのキャリアを考える！

障害報告書を書くときに気を付けるポイント - orangeitems’s diary

*1:
具体的な対応経験としては、

• 障害発生の原因調査
• 業務復旧作業のサポート
• 温度感の高い顧客と対峙し、期待値や原因の説明
• メールにて障害報告を実施
  があります