orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

システム障害の表と裏を語る

f:id:orangeitems:20201215103345j:plain

 

昨日、Googleの障害がありまして・・。

 

www.itmedia.co.jp

米Googleの「Workspace」を含む同社の多くのサービスが12月14日の午後9時ごろから約45分間使えなくなっていた障害の原因は、各種サービスにログインするための認証ツールのストレージクォータの問題だったと、Googleが同日、英Guardianなどのメディアに声明文を送った。

 

もう地球は一部の国を除いてGoogleに依存しているので、こんなことが起こると世の中わちゃわちゃするのですが、皆発生中は何が原因だ?影響は?と大騒ぎになります。

先日の東証のシステム障害でもそうですが、すごく原因、発生メカニズムを知りたがることに興味を持っています。

そもそも、本来の原因があるとして、その原因をありのまま発表する確率自体が私は怪しいと思っています。本当の原因があまりにも稚拙でどうしようもない理由であったときに、そのまま報告すると信頼が失われてしまう。

そのときに、どうストーリーを作って「ああ、それならしようがないね」と利用者に思わせるような作文が役に立つことがあります。これはいたって不誠実なプロセスで、真実を公開しろよと言う声はごもっともです。完全なるウソは後で自分を苦しめることになります。ウソを重ねると、そのウソを今後真実として扱わないといけないので、ユーザーとコミュニケーションをするときに頭に入れておかなければいけないからです。

二重帳簿、みたいなものですね。表に出す事実と裏に出す事実を分けて管理しなければいけない。後々、はじめからちゃんとしておけばよかったと後悔するのがオチです。

ただし、こんな明らかなウソをつくのではなく、もっと汎用的な方法があります。ぼかす、のです。事実を事細かに明らかにせず、概要だけ話す。しかも根本原因はほかにあることを知りながら表面的な理由だけ話す。これはウソではありません。しかし誠実ではありません。事実をぼかすことで根本原因に踏み込まれないようにするのです。

例えば、設定ミスの場合、設定した担当者に悪意があるかもしれません。組織上の統制不備があったのかもしれません。前日飲み会があって、集中力が散漫なまま作業をしたのかもしれません。しかし、「設定の不備」という言葉だけを出し報告とする。これを受け取ったユーザーは、「それなら、次回は気を付けるように」と言って話は終わります。もし真実をありのままに伝えたらユーザーも困ってしまうかもしれません。そんなこと聞きたくなかった、そう言うニュアンスのことを聞いたことがあります。言わなければ追求しなくていいのに、と。つまりすべての情報を切り張りして、新しい世界観を作ることをすれば、後々ウソに苦しめられることは無くなります。

一方で、情報統制が必要になります。報告したことが全てでそれ以外のことは口外無用となります。有名ないくつかの障害も、実は裏でいろいろな要因があり、結果として現象が発生しただけです。もし、社内で根本原因を探り再発防止をしたいのであれば、それこそどんどん深掘りをしていくのですが、対外的にはその情報を出すことはありません。

こうやって、会社の外と中で全然様子が違うのがシステム障害の事実だと思います。外に対しては「ユーザーが納得しやすいストーリーを作る」。内に対しては「根本原因まで深掘りし再発防止に役立てる」。この2つは実はあまりかみ合ってないので、毎回原因が報じられるたびに、「どうせ本当は違うんでしょ?」と思って読んでいます。しかも、ユーザーは、理解しやすいストーリーを聴くとすぐ忘れてくれます。でも、何も提示しないと「いつになったら原因をお聞かせいただけるの?」とイライラし始めます。

芸能人の不祥事でも思うのですが、とりあえず事が起きたらすぐに公に出て、わかりやすいストーリーを提示してあげると世間はものの数日で忘れていきます。しかしずっとダンマリを決め込んでいると、ありもない話がああだこうだ膨らんで、一個一個否定するのが大変になっていきます。

私もシステム障害の報告書を何度か書いたときに、小説家になった気分になったことがありました。同じ事実でも表現の仕方、切り取り方、そして出すタイミングによって随分意味が変わってくるものです。表と裏の差が激しい、大人の世界です。