障害対応に困っている会社の開発担当に読んでもらいたい話

こんにちは、他人のシステム障害は笑っているけど、自分担当の障害は死んでも起こしたくない、ユゲタです。 そりゃあ、誰もシステム障害なんて、好き好んで発生させるわけが無いですよね。 確かに、障害が発生したら生き生きとするエンジニアはこれまで何人か見たことがありますが、 我が身の障害は誰かに迷惑をかけることに繋がるので、普通の人は心が痛みます。 そんな障害を発生させない為に何をどうすれば良いかという事を、今回はまとめてみました。

障害対策は事前準備が9割

当たり前ですが、何か不具合が起きそうだなと、感じたら、何かしらの手を打つ事は、すると思いますが、この黄色信号を、赤信号では無いから、停止せずに青信号と勘違いしてしまう、無謀ドライバーのようなエンジニア、結構いるようです。 システム障害は、この黄色信号をいかに早く察知できるかにかかっているんですからね。 少しでも、気になる箇所があれば、徹底的に、調べ込むと言うのは、エンジニアにとっては、重要な要素とも言えると思います。 そして、分かっている黄色信号であれば、分かりやすいんですが、実際に障害が発生するのは、大体が見えていない黄色信号である事の方が多いです。 そして、それを体験したエンジニアは、決まってこう言います。 「想定外の事象が発生しました」 確かに、すごく稀な事象による障害もたくさんありますが、 「それ、想定できたやろ！」 という想定外も沢山あります。 要するに自分から黄色信号を見つけに行かなかった結果なんですね。 というわけで、黄色信号を重箱の隅を突っついてでも、見つけるという、エンジニアの姿勢が、システム障害にとっては、１番の効果があると言う事を、前提に考えましょう。

障害は発生してから調べるんじゃ遅い！

実際に障害が発生した時に、多くのエンジニアが、障害の原因を調査します。 この時、原因が分からない段階で、同じチーム（会社）のエンジニアでは無い人などから、 「どんな障害？」とか、「何が原因？」 と、聞かれると、それを今調べているから、多くの人がイラッとしてしまいがちです。 が、これって、事前にある程度分かるものなんですよ。 システム障害は、どんなシステムであっても、必ずと言って良いレベルで発生します。 もちろん、障害規模に大小ありますが、どんなに小さくても、障害は障害です。 そして、障害が発生した時に、優秀なエンジニアであれば、アラートや、直前のサーバー状態で、ほぼ原因を特定できてしまいます。 ここで、気がついた人もいるかもしれませんが、理想的な障害検知は、障害が発生してから、原因を探しに行くのではなく、 どんな障害がしたかで、ほぼ原因が特定できてしまうんですよね。 システムのどのエリアかと言うざっくりした原因ではなく、どの箇所の、どの部分で、どのコードや、モジュールに影響しているかと言うレベルです。 それも、さらに優秀なエンジニアであれば、障害が発生する前に、「もうじきこんな障害が起きる」と予言する事も可能になります。 こらは、ユゲタの提唱する、ストーリー検知法を、実施する事で、誰でも可能になるんですね。 そんな、魔法のような、ストーリー検知法って、知りたい人は、次の章を読んでみてください。

システム障害の検知法いろいろ

では、実際にどういう風にやるかというと、 まず、その前に、こうした検知には、次のような種類があります。

・理論検知法 ・経験値検知法 ・組み合わせ検知法 ・あり得ない検知

理論検知法は、システム構成をネットワーク、ハードウエア（サーバー）、ソフトウエア、と事前に作って、そのあらゆる場所に、バツ（いわゆる障害）が起きた時に、どんなアラートが鳴るかと言うのを検知する方法で、細かな障害を見つけて、サービス停止する事を防ぐことができます。 経験値障害は、過去に発生した障害を、理論検知の図に追加する様な方法で、運営を続けていくと、どんどん強固になるし、同じ障害を二度起こさない為の対策です。 そして、組み合わせ検知というのが、あまり誰も実践していない、「ストーリー検知」の領域になります。 そもそも、障害の原因で、原因が分かると、些細な1箇所である事の方が大半ですが、ごく稀に、2箇所での原因で障害を起こす場合があります。 でも、その二つは、全く関係がない事柄かというと、そうではなく、遠からず近からずといった、関係性がある場合が多かったりもします。 それって、システムの全ての組み合わせを考えていくのって、膨大な数になりかねないので、それをやるのは、コストメリット的にオススメできません。 では、どうするかというと、システムや、サービスの、ユーザーが使用する流れをストーリーとして書き出しておいて、それぞれのタイミングで障害が起きる可能性があるポイントを、チェックしていくことで、あり得る障害をリストアップしていく方法で、実際にやってみると、過去に起きた障害などと照らし合わせると、「なぜこの事を事前に気が付かなかったのか」と、開発時の思考よりも深くサービス品質を高めることができる思考に自分が成長できる感覚を保つことができます。 あり得ない検知というのは、上記の3つができている人だけが、やる事を許される、 「もしも、の世界で、こんなことが起きたら、こんな障害につながるだろう」 ということをリストアップしていく手法で、障害検知において、これをやるのは、上位者と考えて良いでしょう。 なので、まずは、ストーリー検知まで出来ていないチームは、これを目指しましょう。

障害のない世界

サービスを最初に作る時に、障害についてのことを考えることができれば、プロ中のプロです。 そして、実際に障害を発症しないサービス運用ができていれば、プロの中でも上級プロです。 お金をもらって、システム開発をしている人は、みんなプロなのかというと、そうは思えない人も、沢山いるのも事実です。 最後に、障害が起きにくいシステムが、どんなモノなのかと言うのを、簡単に説明すると、

・複雑ではなく、出来るだけ簡易なシステム ・想定外の動きをしないシステム ・ブラックポックスが、限りなく少ないシステム

エンジニアならこのぐらい当たり前と思われていますが、現状はブラックポックスだらけのシステムを、一生懸命、障害と闘っているエンジニアもまだまだ沢山いるようです。 障害に強くなりたければ、改めてシステムの見直し、検知の思考を改善する事をお勧めしたくて、このブログを書いてみました。 色々なシステムで、どういう検知をすれば良いか、聞きたい、知りたい、仕事で使いたい、コンサルティングを受けたい、という方は、お気軽に、ユゲタまで、お声がけくださいませ。