システムで問題が起きたときの対処方法

PHR事業開発部の橋本です。今回はNOBORI入社前に起きた話をもとに、エンジニアとしての対処方法、思考方法というところで。

私、NOBORIに入社したのは2年前でして。それまでは十数年、さまざまなシステムの受託開発・保守を担当していました。
某システムの受託開発・保守を担当していた頃に障害が発生して、とにかく皆で調査にあたったのですが、ふと後輩から「どうやって、素早く原因を見つけているのですか？」と聞かれたことがありました。
感覚で作業している部分もあるので、その時は分かんない、って答えた気もしますが。
今回改めて、自分の思考とか実際の作業って何してるのかを見つめ直してみました。

実装中・単体テスト中の問題なら、デバッグとかすれば、すぐに分かるので皆がんばれ！としか言えませんが。
本当に困るのが本番環境や、お客様のテスト環境下（ほぼ本番）での問題発生時、デバッグとかできない場合ですよね。
（しかも早くしろのプレッシャーもすごいし）

常に正しいわけではないですが、皆さんの参考になればと思います。

とにかく、ログを眺める

どんなに上司や、周囲のプレッシャーがすごくても焦らずに。
とにかくログを眺めましょう。辿りましょう。
何かあったときの近道は、とにかくログです。

そのためにも、普段からシステムが出すログを把握すべきですし、
自分で作るシステムに関しては丁寧なログ出力を心がけましょう。
「システムエラー」しか出ないログ。最悪です。

ログと言っても、いっぱいあります。Web/APサーバーのアクセスログ、スマホ端末のOSログ、アプリログ、OSログ、ネットワークログ、メモリ状況やCPU状況もある意味ログ。
とにかくシステム全体から出るものは全部ヒントです。眺めて、普段との違い・異変を検知、総合的に判断するのです。

８割は、自分が悪い。たまに外的要因。

たいていは自分（たち）が悪いです。
すぐに外的要因を探し始める人いますが、８割は自分たちが直近行った修正等で起こしていることが多いです。
（もちろん、直前にOSアップデート等があった場合、その可能性は非常に高いですが）

ある意味、人のした事を信じていないのです。
とにかく自分含めて、疑っています。イヤなやつです。

ひたすら仮設を立てる

とにかくログを眺めて、自分が悪いんだろうなと自覚したら、あとはひたすら仮設を立てるのみです。

一つの仮説で突き進む人もいますが、ひたすら立てます。もう数十個くらい空想します。とにかく仮設を当ててみて、違ったら捨てて、別の仮設検証をします。

たまにしがちなのは、その仮設は違うねって事実が一つ出てるのに、いや絶対これが悪いはずだって、事実の方を疑っちゃう人。もちろん「事実」が間違ってることもありますが、仮設はあくまで仮設なので、まずは「事実」い重きを置きましょう。

最後に１人で悩まない

これは何事もそうですが、１人で悩まないのも大事。問題が起きたシステム担当はもしかしたら自分独りのときもあるかもしれません。でも上司や同僚、後輩、何ならお客さん？に相談して、自分の仮設が正しいかを見てもらうのも非常に大事です。

おかげさまでNOBORIでは、何かあったときでも、嫌な顔せず一緒に対処してくれる仲間や上司、お客様が大変多いです。（ホントに！）

もちろん、何も問題が起きないシステムを目指して開発することは大事なのですが、何か問題が起きたときに素早く正確に対処できることもエンジニアとして、とても大事なスキルだと思います。