最悪の事故が起こるまで人は何をしていたか

フラッシュ・ボーイズを読んでいて、取引所を事故なく運営するのがどれだけ難しいかをエンジニアが語る場面がある。

原因はたった一つのことではないことがわかるだろう。消しては行けない表を消してしまったプログラム作成者ではないのだ。問題は原因の多さにある。原因は数が多いほど衝突しやすくなり、個人の問題というより、もっと大きな組織の問題になる可能性が高まる

エンジニアをやっているので、上記には大いに同意する。絶対にバグは起こり、バグの起こる可能性を下げるにはシステムを構成することの１０倍は労力がかかる。そして、起こってしまったバグを復旧にするには、１００倍の労力がかかるのだ。

現代における最も危険な場所の一つが巨大システムの制御室である。
原子力発電所、ジャンボ機、爆薬工場、化学プラント、核ミサイル基地……　技術発展に伴い、システムはより大きく高エネルギーになり、人員はより少なくて済むよう設計されたが、事故が起これば被害は甚大になる。巨大システムが暴走を始めたとき、制御室で人びとは何をするのか、何ができるのか。
最悪の事故を起こすシステムと、その手前で押さえ込むシステムとの違いは何か。
50余りの事例を紹介しつつ、巨大事故のメカニズムと人的・組織的原因に迫る。

この本に描かれる事故は、１９７０年代までのものが多く、ソフトウェアエンジニアリングの話は少ない。だが、その詳細は記述は参考になる部分が多く、ただの教訓ではなく、実践の場で応用できるレベルのものもある。

例えば、

極限のテストを控える控える事がある。極限状態でのテストが危険を与えるものであるとすれば、より安全な方法を取るようになるだろう。こうした態度が、ボーイング７６７号の墜落につながった

という記述がある。ソフトウェアのエンジニアリングにおいては、テスト環境の構築にかかる労力を別にすれば、危険が伴うものは多くないのだから、出きる限りすべてのことをやるべきであって、わかりやすい機能にばかり目を向けて進んではいけない。

aws東京リージョンでも障害があり、今回は大事には至らなかったが、その影響を見ると、もはやawsは原子力発電所と同程度のエンジニアリングで管理されるべきものになっていると感じた。
その障害も複雑であり、防げた可能性は当然あるが、すべてのケースを想定することの難しさは想像できる。

日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一定の割合の EC2 サーバの停止が発生しました。この結果、当該アベイラビリティゾーンの EC2 インスタンスへの影響及び EBS ボリュームのパフォーマンスの劣化が発生しました。このオーバーヒートは、影響を受けたアベイラビリティゾーン中の一部の冗長化された空調設備の管理システム障害が原因です。