はじめに
障害対応のフローについて書かれた書籍や記事は多くありますが、障害調査の具体的な取り組み方について書かれたものはあまり多くはありません。（※個人の感想です。）
本記事では、初めて障害調査をすることになったエンジニアがまず何を考え、何から取り組むべきなのか、なるべく具体的に書き出していきたいと思います。なお、対象となるシステムは（特に断りがなければ）クラウドサービス上に構築されたWEBサーバを想定しています。
この記事で書くこと✍
・障害が起こったときに、その調査をするエンジニアが具体的に何を考えて何をするのか
この記事で書かないこと🚮
・調査するログのフォーマットやファイルパス（環境によって差異が大きいので）
・ログを調査する際の具体的なコマンド
STEP0 周辺情報の整理🗂
まず初めにあなたが行うべきことは、障害調査をあなたが行うべきかどうかを明確にすることです。
あなたが障害調査を専門とする部署に所属しており、対応するシステム、報告先の関係者など全て予め運用設計済みであることがわかっているのであればこのSTEPは飛ばしてください。
障害の調査を行うためには、サーバへのログイン、クラウドサービスのコンソールへのログインなどが必要になることが往々にしてあります。
また、調査の過程でログなどに記録された個人情報やセンシティブな情報に触れる機会もあるかも知れません。そういった諸々を考慮せずに調査を行い、後々何か問題になるような事態を避けるために、まずは周辺情報を確認していきます。
確認すべきこと✅
- 調査に必要な権限、認証情報は与えられているか
- 調査対象システムの構成は把握しているか（していなければドキュメントは参照できるか）
- 調査結果の報告先はどこか
- 調査に要する工数は確保されているか（保守契約などを確認）
- いつまでに調査結果を出す必要があるか
- 復旧と調査、どちらを優先するべきなのか
- そもそも何のために調査をするのか
あなたの置かれた環境によっては、他にも確認するべきことはあるかも知れません。
状況に応じて、調査に着手するために必要な情報を確認してください。
STEP1 事象の確認🧐
障害調査に着手したら、まずは"何が起こっているか"を把握します。
障害が発生したことを報せてくるのは主に”ユーザーからの報告”か”システムからのアラート”です。（"ユーザーからの報告を受けた営業担当"や"アプリケーションチーム"という場合もあります。）
どこから報されたにせよ、まずは起こっていることを把握するために次のことを確認して整理します。
確認すべきこと✅
- いつ（障害がいつから発生して、今も継続しているのか。時分秒までわかると良い）
- だれが（エンドユーザーなのか管理者なのかなど）
- なにに（アクセスしようとしたページのURLや開こうとしたアプリ内の画面など）
- どこから（インターネットからか、社内ネットワーク内からかなど）
- なにをしようとして（実際に行った操作の詳細）
- どうなった（"障害"と認識された事象。エラー画面が表示された、ページが開けないなど）
- それは再現可能か（同じ手順を辿ると同じ事象が発生するか）
初報の時点で上記の情報が揃っていることはまずあり得ません。地道にヒアリングするなどして可能な限り情報を集めましょう。
STEP2 切り分け🍴
なにが起こっているかが把握できたら、次は切り分けを行います。ここからが正念場です。
切り分けの基本は、低いレイヤーから考えていくことです。昨今のシステムはクラウド上に構築されることも多いため"物理層"を意識することはほとんどないかも知れませんが、"クラウドサービス側の障害"が最も低いレイヤーの障害と言えるでしょう。
1. クラウドサービス基盤の障害
↓
2. ネットワークの問題
↓
3. サーバの問題
↓
4. アプリケーションの問題
大まかに言えば上記のような順序で問題が起こっていないかを確認していきます。
1.クラウドサービス基盤の障害
ゾーン障害、リージョン障害のような大規模なものであればクラウドサービスの提供事業者からアナウンスがあることがあります。しかし、すぐにアナウンスがされるかはそのときによるのでSNSなどで他のクラウド利用者が同じ様な障害の話をしていないかなど確認してみると良いでしょう。
小規模な障害や不具合（データセンターにある個々の筐体など）の場合、特にアナウンスがされないということもあります。その場合はクラウド基盤の障害と断定することは難しいですが、サポートに問合せをすることで回答を得られるケースもあります。（あまり期待はしない）
2.ネットワークの問題
ネットワークの問題は、経路上のどの地点の問題かで大まかに以下の様に分類できます。
- ユーザーの端末が接続しているネットワーク（社内、家庭内などのLAN）
- ネットワーク事業者の通信基盤
- サーバが所属しているネットワーク
ネットワーク事業者のインフラの問題であった場合、あなたができることはありません。経路の冗長化をしていなかったことを悔やみながら復旧を祈りましょう。
ユーザー側のLANの問題である場合、対象のシステムだけでなく他の通信にも影響が出ている可能性が高いです。サーバ側の問題であれば、直近でネットワークに関して設定変更作業があったかどうかを調べることで原因が特定できることがあります。
どの地点での問題かは置いておいて、"ネットワークの問題であるかどうか"を切り分けるためには、
- traceroute コマンドなどを駆使して通信がどこまで到達しているかを確認する
- CDN、LB、サーバのアクセスログが出力されているかどうかを確認する
- CloudWatch,AzureMonitorなどでアクセス数の推移を確認する
といった方法が考えられます。
3.サーバの問題
ネットワークに問題がなければ、次に考えるのは"アクセスはサーバまで到達しているが、正常に応答を返せていない"という可能性です。この"正常に応答が返せない"状況のうち、
- サーバのスペックが負荷に耐えきれずCPUやメモリの使用率が上がりすぎて応答できない（またはとても遅い）
- 応答を返すべきプロセスが何らかの理由で死んでしまっていて応答できない
- サーバのディスク容量が枯渇したため応答できない
- サーバが停止しているため応答できない
といった状況であればサーバの問題であると言えます。
これを切り分けるためには以下の様な観点で確認を行います。
- パフォーマンスモニターなどにより、CPU使用率、メモリ使用率、ディスク使用率、ロードアベレージなどの値を確認する
- クラウドサービスのコンソールから対象サービスが起動状態であることを確認する
- 対象サーバへログインができるかどうかを確認する
- 対象サーバ上で必要なプロセスが稼働しているかどうかを確認する
- アクセス時にどんな挙動をするかを確認する（ブラウザに何か表示されるか、表示されるとしたらどの様な画面か）
サーバの問題は、スペックが足りていなければスケールアップする、プロセスを再起動する、不要なファイルを削除してディスクを空ける、サーバを再起動するといった対処で解決する場合があります。原因の特定よりも迅速な復旧が優先される場合はこれらの対処も検討してみてください。
4.アプリケーションの問題
ここまでの切り分けに該当しなかった場合、アプリケーションの問題である可能性が高くなります。
アプリケーションがエラー時にどの様なレスポンスを返すのかは状況により全く異なるため一概には言えませんが、たとえば"そのWEBサイトのロゴは表示されているが、画面内にエラーを示す文言が表示される"といった様な状況であれば一目でアプリケーションの問題かなとあたりをつけることができるでしょう。
STEP3 ログの調査🔍
切り分けを行い、どこで問題が起こっているかのあたりをつけたら次はログの調査を行なっていきます。問題箇所によって見るべきログは変わってきますが、基本的には障害が発生した日時分あたりで何かおかしなログが無いかを調査することになります。
ここで前提となってくるのは、"ログが保存されていること"です。ネットワーク機器のログ、サーバのログ、アプリケーションログといったログが一番の手掛かりになりますので、これらが一切保存されていないとしたら原因調査はほぼ不可能です。諦めて復旧対応をし、再発しないことを天に祈りましょう。
ログの調査を始めたら、
- どのログを見るか
- ログのどの部分を見るか
を考える必要があります。まず切り分けによってあたりをつけた問題箇所に応じてどのログから見始めるかを考えていきましょう。
1.クラウドサービス基盤の障害の場合
ログはありません。AWS Health Dashboardのようなサービスの正常性を確認できるページの履歴を見てみてください。
2.ネットワークの問題の場合
ネットワーク機器（ネットワーク系のサービス）のログを確認することになります。例えばAWSであればCloudFront,AWS WAF,ALB,VPCフローログなどが該当します。
これらのログはデフォルトでは保存されていないことが多いため、事前に出力するよう設定しておくことが大切です。
また、数分毎に一つのファイルとして保存されていく場合が多いため、生のログファイルを都度ダウンロードしてテキストエディタで開いて中身を読む……というのは現実的ではありません。ログから必要な情報を効率よく探す手段を予め考えておくと良いでしょう。（SIEMに連携する、AWS Athenaなどでクエリするなど）
3.サーバの問題の場合
サーバ上のシステムログやミドルウェアのログを確認します。
Windowsであればイベントログ、Linuxであれば /var/log/messages などが代表的ですが、そのほかにもWEBサーバ（Apache、nginx、IISなど）のアクセスログやエラーログ、cronログなど多岐に渡ります。
これらのログは設定によってファイルが出力されるパスが変更されている場合があります。デフォルトではどこに出力されるのか、変更されているとすればそれは設定ファイルのどこで制御されるのかといったことは覚えておくとスムーズに調査が進みます。
4.アプリケーションの問題の場合
アプリケーションのログがどこにどのように出力されるかは対象のアプリケーションの作り次第なので一概に言うことはできません。可能であれば事前にログの出力先を確認しておきましょう。
ログ調査の具体的な方法🔦
確認するログファイルを特定したら、その内容について調査していきます。ファイルを開くためのツールはなんでも構いませんのでお好きなエディタをご用意ください。
ログは闇雲に全体を読んでいっても必要な情報には辿り着けません。効率的に調査をするためにいくつか意識しておくべきことがあります。
◆ログフォーマットを確認する
そもそもログにどんな情報が記録されているかを確認しておきましょう。クラウドサービスのログであればドキュメントに記載されていますし、WEBサーバのアクセスログなど一般的なものはある程度覚えておいても良いと思います。
◆時系列に沿って確認する
障害が発生した時刻を事前に確認しておき、当該時刻に出力されたログを重点的に確認します。
それだけでは障害と関連のあるログかどうか判断ができないことも多いですので、ログの内容の傾向を
- 同日の別の時間帯のログと比較する
- 前日や翌日の同時間帯のログと比較する
- 他の週の同じ曜日のログと比較する
といった観点で何か異常がないかを調べてみましょう。
◆特定の文字列で検索する
"ERROR"や"ERR"などの文字列で絞り込んでログを検索するのも有効です。また、ここまでの調査で得られた関連のありそうな文字列で絞り込んでみたり、何度も繰り返し記録されているログがあればその出現頻度をカウントしてみるなどでも手掛かりが得られる可能性があります。
怪しいログを見つけたら💣
ここまでの調査で障害の原因となりそうなログを見つけることが出来たでしょうか。これが原因だ、という確信がなかったとしても疑わしいと思うエラーメッセージがあればとりあえずその文字列をコピーして検索してみましょう。
それがどのようなエラーかがわかれば、障害に関連があるかどうか判断できる場合もあります。可能であれば、ChatGPTなどのAIアシスタントにエラーメッセージを投げつけるだけでもヒントが得られることがあります。
本記事で具体的なエラーの内容や障害の実例に触れることまではしませんが、これだというログが特定できるまで繰り返し調べることが重要です。
おわりに
長くなってしまいましたが、最後に障害調査の心構えとして覚えておいて欲しいことがあります。
調査を進めていると、手掛かりを見つけるたびに"原因はこれなのではないか"という仮説を立てることになります。立てた仮説に対して、その真偽をはっきりさせるために仮説に関係のある情報をどんどん探していくというのも一つの方法です。
ただし、"自分の立てた仮説に固執しない"という意識は常に持っていてください。人は自分にとって都合のいい情報、そうであって欲しいと望んでいる情報ばかり集めてしまいがちです。そういったバイアスに囚われずに、広い視野を持って"これが違うとしたらこっちかもしれない"をひたすら繰り返すことで見えてくるものもあります。
障害が発生しているときというのは緊急事態ですから、心に余裕を持ってというのは難しいかもしれません。それでも、焦ることで得られるものは何もありませんので、いつまでに結果を出せば良いのかを意識しつつも落ち着いて調査に当たってください。
本記事ではなるべく具体的に障害調査の手法を記載したつもりですが、あくまで基礎的な内容となります。さらに詳細な調査手法、例えば調査に使用するツールの使い方やログを整形・集計するためのコマンドなどといった話にまでは触れられていません。
いつかそういった応用的な内容も記事にするかもしれませんが、たまたま本記事を見かけた障害調査のプロフェッショナルの方がいらっしゃれば、是非ともそのテクニックを公開していただけると多くの悩めるエンジニアが幸せになれるかと思います。