こんにちは、エンジニアの森です。

自己紹介

担当業務
現在はasoviewのバックエンド/フロントエンドのどちらも携わっています。
経歴
1. 2013年新卒で派遣会社に入社、7年間派遣業務（業務系/組み込み系開発）に従事
2. 7年目に退職を考え、会社と話し合った結果、社内で請負部門を立ち上げ
3. 3年間受託開発（Web系/Androidアプリ開発）に従事し、2023年2月にアソビューに転職

はじめに

本番障害はエンジニアにとって避けたいものですが、現実には発生することもあります。
しかし、障害の発生を恐れる必要はなく、適切な対応手順を知っていれば、迅速に解決し、貴重な経験を積むことができます。
今回は、私の経験をもとに障害調査のステップと、その際の心構えについて共有したいと思います。

本番障害調査のステップ

前提として障害を解析する際には下記の様な視野を持って取り組むとより解析の速度が上がります。

発生する原因は何か？
発生しない場合はあるのか？
発生した場合どういった害が生じるのか

これらを解析の初期に考えることで、調査対象の範囲を絞り込み、全体的な調査工数を削減できます。

具体的な調査ステップ

コードを見ずに事象を把握する
調査の始めはそもそも現在どういった事象が発生しているかを確認します。
ここでしっかり不具合の内容を理解出来ていないと後工程の調査にも余計に時間がかかるのでしっかり自分の言葉で不具合の内容を説明出来る様になるまで把握しましょう。

具体例: ユーザーが特定のボタンをクリックするとアプリがクラッシュする場合、まずそのボタンをクリックして実際にクラッシュ時に何が発生しているかを確認します。
ログを確認する
実際の事象を確認出来たら次は事象が発生した際にログが出ていないかを確認します。
ここで事象発生時のログが確認出来たら後工程がとても楽になります。

具体例: ボタンをクリックして実際にクラッシュ時に実行されたイベントのログを確認し、実行時パラメータの値を確認する。
事象が発生した手順を考える
事象の内容を把握できたら次は事象が起こる手順を考えましょう。
事象を最短で再現する方法を把握すれば、後の修正が非常にスムーズになります。

具体例: アプリがクラッシュするのは、特定の設定が有効になっている場合だけかもしれません。その設定を確認し、再現手順を特定します。
一連の流れを把握できたらコードを見る
最短の手順を見つけ出せたらあとは該当するコードの流れを追いましょう。
ここまで来たらあとは流れの初めから終わりまで追うだけのはず!

具体例: クラッシュが発生するボタンのクリックイベントハンドラーを特定し、その中で何が起こっているのかをコードベースで確認します。

未知な事に取り組んで行くことの重要性

障害調査は地道な経験の積み重ねでできることや理解できる範囲が広がっていきます。
下記の様な段階ごとにそれぞれ現在取り組むべき内容はちがってくるので現在自分はどの段階にあるのか、次は何に取り組んでいけば良いのかを地道に考えていけば、いずれ障害調査に積極的になっていくことができると思います！

正常な仕様がわからない
仕様はわかるがコードが読めない
コードは読めるが他アプリケーションとの関係が把握できない

本番障害に立ち向かうことによるメリット

凄く個人的な感想になりますが、障害を解決するまでの間はとても苦しい戦いになります。
しかし、解決した際の気持ちよさは実装などとはまた別の達成感が得られると考えています。
特に調査を終えて振り返った時に、今までわからなかった事がわかる様になっている感覚は、10年以上エンジニアをしていても新鮮に感じられるので、キャリアを重ねていても良い影響があると思います。

また技術的な面からは外れますが、障害調査をしっかりこなすことで社内関係者の信頼も得られ、次の調査時により協力を得やすくなるなど良い循環に入ることが出来ると思います。