エンジニアにとって、突発的な障害対応や不具合の解消 は避けて通れない業務のひとつです。
この記事では、トラブルシューティングのセオリーとして意識したい 7つのステップ をご紹介します。これらのステップを意識することで、問題解決の効率を上げ、より迅速かつ確実にトラブル対処することができるでしょう。
7ステップの全体像
- 事象を把握する
- 問題発生箇所を特定する
- 暫定対処を実施する
- 事象を再現し、発生条件を特定する
- 原因仮説を立てる
- 仮説を検証し、原因を特定する
- 恒久対処を実施する
ステップ1：事象を把握する
最初のステップは、問題の全体像を正確に把握することです。
いつ、どこで、どのような影響が出ているのかを把握し、障害規模や対処の優先度を判断することが目的です。
次の３つの要素と収集し、時系列で整理しましょう。
-
技術データ
-
対象
- ログ
- メトリクス
-
ポイント
- ErrorやWarningレベルログ、およびその前後のInfoレベルログを抽出する
- 突発的な変化や右肩上がりを続けているメトリクスを抽出する
-
対象
-
操作内容
-
対象
- 問題が発生した操作内容
- 画面に出力されたエラーメッセージ
-
ポイント
- 期待する動作と実際の動作の両方を書き出す
- 問題発生直前に行った操作も含めて収集する
- エラーメッセージはテキストや（Web画面の場合は）HTMLファイルなど、可能な限り詳細な情報を保持できる形式と、スクリーンショットで収集する
- 一連の操作が絡む場合はスクリーンレコードも活用する
-
対象
-
ユーザー報告
-
対象
- ユーザーから寄せられた具体的な不具合報告内容
-
ポイント
- 複数のユーザーから寄せられた報告を比較し、共通点と差異に着目し整理する
-
対象
ステップ2：問題発生箇所を特定する
ステップ1で収集した情報を基に、問題が起きている箇所を特定します。
注意すべきは、エラー発生箇所と根本原因がある箇所は必ずしも一致しないことです。
例えば、ユーザーインターフェースでエラーが表示されていても、実際の問題はバックエンドのデータベースにあるかもしれません。システム構成や依存関係を考慮しながら、被疑箇所を見極めることが重要です。
ステップ3：暫定対処を実施する
問題発生箇所を特定したら、暫定対処を実施します。
暫定対処の目的は、サービスへの影響を最小化しながら、恒久対策を行うための時間を稼ぐことです。
暫定対処の例:
- 問題のある機能を一時的に停止する
- 障害箇所を切り離す
- リソースを一時的に増強する
- ワークアラウンドをユーザーに案内する
暫定とはいえ、本番環境に変更を加える場合は検証環境で最低限の動作確認を行い、プロジェクトの管理規程に従い変更諮問委員会（CAB：Change Advisory Board） または 緊急変更諮問委員会（ECAB：Emergency Change Advisory Board） 等で責任者の承認も得た上で実施しましょう。
復旧を優先しない場合
復旧より確実な原因特定が優先される場合もあります。例えば、試験工程や検証環境でのトラブル、サービス影響のないトラブルなどです。
そのような場合は、暫定対処はスキップもしくはステップ6（原因特定）の後に実施します。
ステップ4：事象を再現し、発生条件を特定する
問題箇所が特定できたら、本番環境とできるだけ近い環境で問題を再現します。
ただし、本番環境で直接問題を再現することは避けましょう。 本番環境で原因が未知の事象を再現すると、サービスのダウンやデータの破壊、利用者への影響などを引き起こすリスクがあるため、できる限り検証環境で検証します。
また、複数の条件が重なったときにだけ発生する問題もあるので、根気強く調査しましょう。
例えば、ユーザーが特定の時間帯に大量アクセスを行い、データベース負荷が急激に高まったうえでキャッシュが破棄されるなどの条件が同時発生すると、はじめてエラーが発生するケースもあります。
ステップ5：原因仮説を立てる
問題の発生条件が判明したら、原因仮説を立てます。
仮説を立てるためのヒントとして次のようなものを活用し、チームメンバーとブレインストーミングを行うと効率的です。
仮説立案のヒント:
- 問題箇所の製品サポート窓口への問い合わせ
- システム構成図やシーケンス図の洗い出し
- 過去の類似事例の参照
- 検索系の生成AIサービス(Copilotなど)を活用
上記のうち、「製品サポート窓口への問い合わせ」は回答に時間を要すことが多いため、最初に行いましょう。
また、仮説が複数ある場合、発生可能性・検証の容易さの観点で優先度をつけましょう。
ステップ6：仮説を検証し、原因を特定する
優先度の高い仮説から順に検証し、原因を特定していきます。
次のポイントを意識しましょう。
-
ステップ4で事象再現が確認できている環境で検証を行う
本番環境での直接検証はリスクが高いので避けましょう。
-
検証する要素は一つずつ切り分ける
パラメータの修正や変更を行う際には、対象項目を明確にして、一度に多くの操作を加えないようにしましょう。複数の要素を同時に変更すると、どの要素が影響したのか判別しづらくなります。
-
検証内容と結果を体系的に整理・記録する
どの条件で何を試したか、何が起きたかを表やリストなどでまとめ、後から検証漏れや重複を防げるようにします。
-
否定された仮説も記録する
一度否定された仮説を再び立てないようにするために、どのように検証したか、なぜ否定されたかを残しましょう。
-
新しい仮説を思いついた場合は柔軟に検証・優先度を調整する
検証の途中で新たな情報やアイデアが得られることもあります。適宜、検証計画を見直して効率的に原因特定を進めましょう。
ここで横着をすると、原因を見誤り解決が遠ざかるため、慎重かつ着実に進めましょう。
ステップ7：恒久対処を実施する
暫定対処を実施したまま放置すると、問題が再発する恐れがあります。
最終的にはきちんと恒久対処を行い、再発を防ぐことが重要です。
恒久対処の例:
- コードやパラメータの修正
- 新規バッチの実装
- 作業手順書のフォーマット変更
- プロジェクト内の管理規程の改善
- 組織構成の変更
どのような恒久対処を行うかを判断するには、まず再発防止の観点でなぜなぜ分析を行い、根本原因にたどり着くことが必要です。
具体的には、次の手法進めましょう。
- 行動の時系列やシステム構成要素を軸に、網羅的に問題の有無を洗い出す
- 問題があると判断される要素について、なぜなぜ分析を実施し、根本要因を追究する。ここで人為的なミスだけでなく、組織やプロセスの問題も視野に入れることが重要です
- 根本原因に対する対処案をリストアップする
- 対処案をコスト・期待効果・即効性・リスクなど多角的に評価し、その中から実施策を選定する
- 選定した実施策を導出過程とともに責任者へ報告し、承認を得る
- 対処実施に取り掛かる
まとめ
本記事では、トラブルシューティングを7ステップで整理しました。問題の大小やシステムの業務内容に左右されない汎用的な流れとして、日頃の障害対応にぜひ活用してください。
こうしたプロセスを積み重ねていくことで、問題を一つ一つ着実に潰し、システムを安定運用に近づけることができます。