障害対応！について

こんにちは、おもです。
今日はできればみんなが避けたい「障害対応」について書いてみます。

読んで暗くなる内容じゃないので安心してください(笑)

障害
文字だけ見ても怖いですよね。。。
でもエンジニアをやっていれば避けて通れないものだし、昔の様に完成して販売したらもうどうしようもない世界ではなく、ほとんどのサービス・商品がオンラインアップデートを続けていく現代では、むしろ障害対応をどれだけ素早く、丁寧にやるかで評価が変わると言えます。

今回はサービスインしているものではなく、開発、構築段階での障害についてとなりますが、この段階であれば素早さよりも正確さが大切になってきます。
仮にA、B、C、Dという工程を通したところ、思っていた結果ではなかったという場合、
まず、どの部分で想定通りいってないかを切り分ける必要があります。
はっきりいってこの切り分けが一番重要だと思います。

この時やりがちなのが、A、BはそのままでC、D両方をいっぺんに変更してしまう方法です。
切り分けをするためには1つずつやっていくのが基本です。
これは科学実験でも基本となっていて、
そのままの要素を”不変要素（コンスタント）”、手を加える要素を”変化要素（バリアブル）”と言います。（変化要素には二つあり、実際に他の数値を変えるなど直接いじる要素を、独立変化要素といい、独立変化要素から影響を受ける要素を従属変化要素といいます）

調査方法
まずはAだけ変えてみる、次はBだけ変えてみる、そしてCだけ変えてみる、最後にDだけ変えてみる。
このすベてを試して、どの要素が結果に影響を当てえているか見る必要があります。
これでCを変えたら結果が変わったとして、「原因はCでした」とせずに、次はAとCを変えてみる、BとCを変えてみる、CとDを変えてみる、次はAとBとCを変えてみる、、、としつこいくらいにやってホントにCだけが原因なのかを切り分ける必要があります。Cが原因ぽくても、実はCとAが複合的に問題を起こしていた。とか、実は実はCだけがまともで、AもBもDもおかしかった。なんてこともあります。

完全に原因を突き止めたら、あとはその要素だけを徹底的に調査して原因を究明してください。

昨今のシステムは多岐にわたり、たくさんの人が関わっています。
他チームに原因と思われる個所を調べてもらう必要がある場合、なぜ？と言われのは普通のことです。
その際に、ちゃんと上記のような切り分けをしたうえでの依頼であることを伝えれば納得して動いてくれるでしょう。

これは頭が良いとか悪いとかではなく、思い込みを捨て、すべてを疑い、論理的に考えられるかというはなしです。

エンジニアをやっていると、自然とこの能力が磨かれていきます。

障害対応はイヤなものですが、「将来役に立つ勉強」と思って取り組んでみてください。