大谷イビサのIT業界物見遊山 第66回

「システム障害はなぜ起こるのか？」の対談の前日に得た体験と気づき

火災報知器が鳴り響くカレー屋での経験は、障害対応の大きな学びだった

　渋谷のカレー屋で会食の途中、突然の火災報知器！　その日の会食は5人だったが、経験豊富なマーケターと経営伴走者がいたことで、「これこそ正しい障害対応では？」という素晴らしい学びを得ることができた。当日の模様をレポートするとともに自身の気づきを書き連ねておきたい。

乾杯を終え、前菜を食べた終えたあとに店に異変が

突然の火災報知器！　あなたならどうする？

　その日のカレー会食は、前菜とワインを楽しみ、さあいよいよメインのカレーという段階で火災報知器が鳴り響いたことで、一気に様相が変わった。上の階で火災が発生したというアナウンスだ。1回目はともかく、2回目の館内アナウンスが出た段階で、店内は「これは訓練や誤放送ではなく、本当に火災では？」という空気が流れ始めた。

　会食の参加者は5人だったが、カレーのことしか頭にない私は「誤放送だから、店の人が確認してくれるに違いない」と思っていた。「どうせ悪いことは起こらないだろう」と予見してしまう絵に描いたような正常性バイアスだ。しかし、残りのメンバーは違う。「10階で火事とアナウンスしている」「ここって5階だから、飛び降りて逃げるのは無理」「これは早々に避難した方がいい」と、他のお客に先駆けて1階に降りることを決めた。

　迅速に店から出ることを判断できたのは、会食相手だった名うてのマーケターと経営伴走者が経験豊富だったからにほかならない。2人のベテランは、おそらく私のような正常性バイアスに取り憑かれた経営者やマネージャーを何人も見ており、そのデメリットを痛感したのだろう。「すぐに逃げた方がよい」と迅速に判断し、メンバーのコンセンサスをとって、従業員の指示に従い、階段から1階に降りた。過去の雑居ビルの火事のニュースを考えても、いったん火が回ってしまったら、確かにビル内はパニックになるはずだ。

　避難した人たちは雨空の中、ビルを見上げていたが、われわれは早急に別のカレー屋に移動した。実はここだけは普段カレーばかり食べている私の知見が生きており、会食できる近所のカレー屋にスムーズに移動。前菜とワインの次に出てくるはずだった会食の続きをそのまま別の店で楽しむことができた。もちろんメニューは違うが、座席ごと別の店に移動してしまった感じだった。

　その後、店から連絡があったが、火災報知器は誤報だった。結果から見れば、「そのまま店で会食を楽しめばOKだったのでは？」という意見も出るだろうが、私はそうは思わない。場所は移ったものの、迅速な判断の結果、忙しいメンバーの時間を無駄に消費することなく、会食を楽しむことができたからだ。

迅速な判断、RPO/RTOの考え方　システム障害はやはり人の問題

　もう1つよかったのは、イレギュラーな事態への対応そのものが大きな学びだったからだ。実は私の翌日の仕事は、システム障害について別媒体の編集長と対談すること。システム障害が会社や世の中に与えるインパクト、システム障害はなぜ起こるのか、どうやって防ぐのかを思考しながら、スライドを作ったあとの会食だったのだ。そのため、この日の出来事は実体験としてシステム障害を捉え直すいいきっかけとなった。

　われわれの生活を支えるシステムは、日々さまざまな形で障害を起こしている。その原因はハードウェアやソフトウェアの障害、自然災害、ヒューマンエラー、セキュリティ侵害など多岐に及ぶ。もちろん、バックアップ、クラスタリング、HA（High Availablity）、セキュリティ対策ソフトなど、こうした障害に対応したソリューションも数多く存在する。最近ではAIによる可視化や自動化、テストツールも増え、人手をかけずにシステム障害に対応できる可能性が出てきた。

　しかし、先ほどのカレー屋の騒動で学んだのは、やはりシステム障害への対応はどこまで行っても人の問題ということだ。前述した通り、現場では「店内で火災報知器が鳴り続ける」というアラートに対して、ベテランが「本当に火事かもしれない」というリスク、「普段なかなか会えないメンバーの会食で時間がもったいない」というビジネス的な妥当性から、いち早く避難の判断を下した。これはBCPやバックアップ計画で重要なRTO（Recovery Time Objective：目標復旧時間）やRPO（Recovery Point Objective：目標復旧時点）の考え方そのものだ。正しい情報収集とリーダーの迅速な判断の重要さをつくづく痛感する。

　また、私もいち早く別のカレー屋に他のメンバーを誘導できたわけだが、これもクラウド障害の対応に通じるモノがある。2021年夏に起こったAWSの東京リージョンの障害では、AZ内でのシステム冗長化が、そのままサービスダウンの有無につながった。今回の場合、たまたま私がカレー屋のマップを整備していたから他の店へのマイグレーションがスムーズだったが、やはり障害を前提としてシステムを設計する「Design For Failure」は、どの場面でも金言となりうるのだと感じられた。逆に私の課題は正常性バイアスからの脱却だ。

　今日この会食メンバーでなければ、この学びにはつながらなかった。実は、お店の好意でその日の食事代は払わなくてもよいことになったのだが、当然ながら申し訳なく感じる節もあり、会食を中断した残念感もある。今回は貴重な学びを体験したので、次回はしっかり本命だったカレーを楽しみたい。
 

大谷イビサ

ASCII.jpのクラウド・IT担当で、TECH.ASCII.jpの編集長。「インターネットASCII」や「アスキーNT」「NETWORK magazine」などの編集を担当し、2011年から現職。「ITだってエンタテインメント」をキーワードに、楽しく、ユーザー目線に立った情報発信を心がけている。2017年からは「ASCII TeamLeaders」を立ち上げ、SaaSの活用と働き方の理想像を追い続けている。