【失敗学】東証システム障害の原因から学ぶ

2020年10月1日に発生した東証証券取引所の株式売買システム「arrowhead」で発生した障害で株式売買は終日停止となる事件が発生しニュースやネットでも話題になっていましたね。そこから障害が発生した原因の分析が行われ、2020年10月19日に富士通から詳細な原因の発表がありました。

システム障害が起きた理由を簡単にまとめてしまうと、ヒューマンエラーが重なった結果です。今回は東証システム障害の原因から学んでいき自分や自分の会社で同じ失敗を起こさないようにするために、どのような行動をするべきか紹介します。

東証システム障害の原因
【失敗学】ヒューマンエラーによるミス
- マニュアルへの反映漏れ/デグレード

東証システム障害の原因

発生した事象を簡単にまとめると

１．共有ディスク装置のメモリ故障
２．故障した装置が切り替わるはずなのに切り替わらなかった

となっています。文章だと分かりづらいので、画像でイメージを書いてみました。

装置が壊れること自体は起きる可能性があるので、装置を二重化して一つの装置が壊れてしまっても、もう一つの装置に切り替わるような構成になっています。そのため、メモリ故障が起きたことに関しては大きな問題はありません。

問題は自動切替が起こらなかった点です。自動切替が起こらなかった理由については、富士通から発表されています。

（2）共有ディスク装置の自動切替が行われなかった原因
・当該共有ディスク装置のマニュアルには、メモリ故障等に起因する特定事象が発生した場合は、必ず自動切替が行われる旨の記載がありました。
・実際の製品では、設定によっては、メモリ故障等に起因する特定事象が発生した場合、自動切替が行われない仕様となっておりました。今回は特定事象発生時に自動切替が行われない設定になっておりました。
・マニュアルの記載と実際の仕様の齟齬が生じた原因は、当該共有ディスク装置のオペレーティングシステムのバージョンアップにより製品仕様が変更された際に、マニュアルの記載が変更されていなかったことによるものです。
・マニュアルの記載が変更されていなかったこと、およびその状況を製品出荷時等の試験で検出できなかったことは当社の試験・確認が不十分であったことによるものです。
・なお、メモリ部品自体が故障した原因については、当社およびOEMベンダーにて故障部品の診断を実施しており、ロット障害ではなく、偶発的な故障であったと確認できております。
FUJITSU 東京証券取引所様の株式売買システム「arrowhead」で発生した障害の原因と対策について

つまり、マニュアルと製品仕様が合っていなかったため自動切替が行われない設定になっていたということです。これに関しては、東証の資料を見ると何が想定と異なっていたかが分かりやすく記載されていました。

これらの内容から装置としての動作には何も問題は無く、マニュアルと製品仕様が不一致であったことが分かります。つまり人間によるミスが原因だったということです。

【失敗学】ヒューマンエラーによるミス

東証システム障害の原因には「マニュアル記載誤り」「不十分な試験・確認」と2つのミスがありましたが、どちらもヒューマンエラーの事例としてはよくある話です。もちろん色んなことに注意してやっていたと思いますが、それでも起きてしまうのがヒューマンエラーです。そこで身近に起きる可能性があるマニュアル誤りについて改めて考えてみました。

東証の資料によるとarroehead2代目のバージョンになった時点からマニュアルの記載が誤っていたことが分かります。つまり5年近くマニュアルの記載が誤ったまま運用を続けていたことになります。故障が起きない限り、マニュアルの記載が誤っていることに気付かないのはある意味仕方の無い部分かもしれないですね（笑）

しかし、サーバやルータではOSバージョンが変わることで、デフォルトの設定値のON/OFFや仕様の変更があることは考えられる部分ですよね。（arrowheadで使われている共有ディスク装置の製品について詳しいことは分かりませんが…）

原因を知ってしまうと「何だ、そんなことか」と簡単に終わらせてしまう気持ちも分かりますが、同じ失敗を繰り返さないためにも原因を深堀りする必要があります。

富士通で原因に対してどんな深堀りを行ったかについては把握できませんが、再発防止策については記載されていました。

（3）再発防止策
東京証券取引所様にて稼働中のOEM製品について、製品仕様とマニュアル記載内容の再レビューを実施します。また、製品仕様とマニュアル記述の一致、および仕様追加、仕様変更等の通知徹底等OEMベンダーと連携強化する
FUJITSU東京証券取引所様の株式売買システム「arrowhead」で発生した障害の原因と対策について

まずは現状のマニュアルで他の部分に誤りが無いか確認して、マニュアルの記載を修正するようですね。これで同じことが本当に起きないのか少し気になるところではあります。

まんぬ

水平展開として、他の装置でも同様の誤りが無いか確認はしないんですかね？これだけ大きなトラブルになったら「他の装置は大丈夫なのか！？」って偉い人が言ったりしそうですけど…今回の件では報告されていないけど、裏ではエンジニアが必死になってやっているのかと思うと恐ろしいですね。

マニュアルへの反映漏れ/デグレード

ここからは私の経験からマニュアル記載漏れが起きた原因について「こんな感じで起きたのかな」と想像して書いてみました。

私も業務で使用するマニュアルを作成することがありますが、「マニュアルへの反映漏れ」や「マニュアルのデグレード」は割とあるあるのミスだと思います。デグレードは同じファイルを更新し、更新内容が古い内容に上書きされてしまい更新内容が消えるという非常に残念な事態です。

これはマニュアルに限らず、その他の業務でも起きる可能性があるミスです。私が経験したものでは、こんなミスが実際に会社で起きていました。

どうですか？皆さんも同じような経験ありませんか？（笑）

「でも、ミスが起きたって大きな問題にならなければ良いじゃないか！」と思う方もいるかもしれませんが、そんな簡単な話ではありません。

それは、正しい情報に直すためには今までにかかった時間以上の労力がかかるためです。この内容は本当に正しい情報なのか・どの時点の内容から記載が変になってしまったか等を一つ一つ確認して直さないといけないため、肉体的にも精神的にも負担がかかります。更に、修正作業が遅れてしまうとその間にも新たな情報が追加される可能性があり、直している間に別のデグレードが生まれてしまうという悪循環にも繋がります。

こういったことが起きないようにするためには、以下の対策を取ることをオススメします。

オススメの対策

・ファイルの共有は必ず1箇所で行う
・ファイル編集中は他の人が編集できないようにする
・同一ファイルの別バージョンを複数保管しない

「こんなこと当たり前でしょ！」と思いますが、当たり前のことができない・できなかった時にミスは起こります。自分は大丈夫と考えずに取り組む必要がありますね。

ヒューマンエラーというのは一つ一つのミスを止めることができなくて、すり抜けてしまった時に起こります。これはスイスチーズで例えられることが多いですね。