障害調査で最初に見るのは、ログではない。「再現するか」を確認する理由
どの条件で起きるのかを確かめ、読むべきログと設定を絞る障害対応
利用者から、次のような問い合わせが届いたとします。
保存ボタンを押したら、エラーになりました。
障害対応を始めたばかりの頃は、すぐにアプリケーションログを開きたくなるかもしれません。
エラーを示す行はないか。直前に例外が出ていないか。サーバーやデータベースに異常はないか。
ログを確認すること自体は、間違いではありません。
ただ、この時点では、探す範囲がまだ広すぎます。
何時ごろ、どの利用者に起きたのでしょうか。どの端末から、どのデータを保存しようとしたのでしょうか。同じ操作をすれば毎回起きるのか、ほかの利用者にも起きているのかも分かりません。
これらの条件が曖昧なまま大量のログを読み始めても、どの時刻、利用者、処理を追えばよいのか決められません。
まず必要なのは、問い合わせの言葉を、観察できる事実へ分けることです。
その上で、安全に確認できる場合は、同じ条件で同じ事象が再び起きるかを確かめます。
ディーシステムの社内ナレッジでも、障害調査では、早い段階で再現性の有無を確認する考え方が共有されています。
再現性とは、同じ操作や条件を用意したときに、同じ事象が再び起きるかどうかです。
ただし、再現したからといって、原因が分かるわけではありません。
再現性は、次にどの利用者、端末、データ、設定、時間帯、依存サービスを優先して調べるかを決める材料です。
再現性が、次に調べる方向を分ける
障害の起き方は、「再現する」「再現しない」の二つだけではありません。
発生の仕方によって、優先して確認する条件が変わります。
毎回再現する
同じ条件で試すと、ほぼ毎回事象が起きる状態です。
特定のデータを保存すると必ずエラーになる。ある権限の利用者だけ、毎回同じ画面で処理が止まる。特定バージョンのアプリケーションでは、同じ操作が必ず失敗する。
この場合は、入力データ、権限、設定、処理ロジック、バージョン、依存サービスなど、継続的に存在する条件を優先して調べやすくなります。
ただ、毎回再現するからといって、必ずプログラムや設定が原因とは限りません。
同じ利用者が、毎回同じ操作手順を誤っている可能性も残ります。
特定条件で再現する
ある条件では発生し、別の条件では発生しない状態です。
特定の利用者や端末、データ、時間帯、ネットワークでだけ起きる場合が該当します。
この状態では、「何を変えると再現しなくなるか」が重要です。
異常が起きる条件と正常に動く条件との差が、原因候補を減らしてくれます。
断続的に再現する
同じように操作しても、発生したり、しなかったりする状態です。
10回試して2回だけ発生する。朝の時間帯に起きやすい。処理量が多いときだけ遅くなり、同時利用者が増えるとタイムアウトする。
この場合は、処理のタイミング、負荷、同時実行、ネットワーク、外部サービス、リソース不足など、一時的に変化する条件を優先して確認します。
一度起きたかどうかだけでなく、何回試し、何回発生したのかを残すことも欠かせません。
再現しない
調査担当者が同じ操作を試しても、事象が起きない状態です。
ただし、再現しなかったからといって、問題が存在しなかったとは言えません。
調査を始めた時点では、一時的な負荷が解消しているかもしれません。外部サービスが復旧し、セッションやキャッシュ、対象データの状態が変わっている可能性もあります。
再現性は、原因を答えるものではありません。
次にどこを見るかを決めるための分岐です。
「同じ操作」だけでは、同じ条件にならない
保存ボタンをもう一度押した。同じ画面を開き、同じメニューを選んだ。
それだけで、同じ条件を再現したことになるのでしょうか。
同じ操作を繰り返すことと、同じ条件をそろえることは別です。
結果へ影響する条件には、さまざまなものがあります。
すべての条件を完全に同じにできるとは限りません。
だからこそ、何をそろえ、何が異なっているのかを記録します。
条件を変えて切り分けるときは、可能な範囲で一つずつ変えます。
利用者も端末もデータも一度に変えて正常になった場合、どの違いが結果へ影響したのか分からないからです。
再現確認は、エラーをもう一度表示することではありません。
発生する条件と、発生しない条件の差を見つける作業です。
同じ端末で、利用者だけを変える
条件を一つだけ変える例として、利用者固有の不具合を考えてみます。
ある端末で、一人の利用者だけがアプリケーションを利用できない。
このとき、同じ端末へ別の利用者でサインインし、同じ操作を試します。
固定するのは、端末、アプリケーション、ネットワークです。
変更するのは、利用者だけです。
別の利用者でも同じ事象が起きた場合は、端末設定、アプリケーション、OS、ネットワークなど、端末に共通する条件の優先度が上がります。
反対に、別の利用者では正常に動いた場合は、個人設定、権限、ライセンス、認証状態、ユーザー固有のキャッシュやデータなどを優先して調べられます。
ここで気をつけたいのは、別の利用者で正常だったからといって、ユーザープロファイルが原因だと確定したわけではないことです。
分かったのは、利用者を変えると結果が変わったという事実です。
その事実をもとに、利用者にひもづく条件の優先順位を上げます。
一つの条件だけを変え、結果がどう変わったかを見る。
これが、切り分けの基本です。
再現を試す前に、最初のエラーを残す
再現確認を急ぐあまり、最初に起きた事象を消してはいけません。
エラー画面をすぐに閉じる。再読み込みする。アプリケーションを再起動し、同じ操作をもう一度試す。
こうした操作によって、最初の状態が変わることがあります。
失われる可能性があるのは、エラー画面だけではありません。
エラーコードや表示された文言、発生時刻、入力していたデータ、操作中の画面、リクエストIDやセッション情報、発生直前の状態も変わることがあります。
再現を試す前に、すでに起きた事象を失わないことが先です。
少なくとも、次の情報を残します。
エラー画面と表示文言
エラーコード
発生日時
利用者
使用した端末と環境
実施した操作
対象データ
直前の操作や変更
業務への影響
現在も継続しているか
スクリーンショットは有効ですが、それだけですべてを説明できるわけではありません。
必要に応じて、ログや監視情報、操作履歴、リクエストIDなども確認します。
状態を変える操作の前に、元の状態を記録する。
再現確認は、その後です。
発生時点のログや証跡を残す意味については、別記事「本番作業でログを残さなかったら、何が証明できなくなるのか」で詳しく扱っています。
再現した場合は、観測しながら原因候補を絞る
同じ事象を再現できた。
ここで、調査が終わるわけではありません。
分かったのは、その条件で同じ事象を観察できることです。
次は、再現している最中に何が起きているのかを確認します。
発生時刻、利用者と権限、入力データ、処理された機能、リクエストIDを押さえる。その上で、アプリケーションログやOS・認証ログ、データベースやAPIの応答、CPUやメモリなどのリソース使用量、依存サービスの状態を確認します。
再現時刻と対象が分かれば、読むべきログの範囲を絞れます。
大量のログ全体を眺めるのではなく、該当する時刻、利用者、処理、リクエストへ近づけるのです。
また、異常時の情報だけを見ても、何が違うのか分からないことがあります。
正常に動く利用者やデータ、問題のない端末、正常な時間帯と比較することで、異常条件にだけ存在する差が見つかることがあります。
必要に応じて、詳細ログやトレースを有効にする場合もあります。
ただし、本番環境では注意が必要です。
ログ量が増えれば、システムへ負荷をかけることがあります。個人情報や機密情報が含まれる可能性もあり、保存容量や閲覧権限も考えなければなりません。
必要な承認と影響確認を行った上で、観測方法を決めます。
再現できた事象は、ただ繰り返すのではありません。
正常時と比較できるデータへ変えていきます。
再現しない障害を、どう調べるか
同じ操作を試しても、エラーが起きなかった。
この場合、「問題なし」としてよいのでしょうか。
一度の確認だけでは、そう判断できません。
問い合わせが届いた時点と、調査した時点では、条件が変わっている可能性があります。
一時的な負荷が下がり、ネットワークや外部サービスが回復しているかもしれません。利用者が再ログインしたことでセッションが変わり、対象データの更新や再試行によって途中状態が解消されている場合もあります。
再現しない場合は、自分で観察した再現情報の代わりに、発生時点に残された情報を重視します。
正確な発生時刻と、その前後のログ、監視メトリクス、ネットワークや外部サービスの状態を確認する。利用者の画面や入力データ、直前の変更、セッションやリクエストID、同じ時間帯のほかの利用者への影響も調べます。
利用者へ追加確認する場合も、「もう一度やってください」だけでは足りません。
どの操作を、どの順番で行い、何を入力したのか。何回発生し、再試行後はどうなったのか。別の端末や利用者でも起きたのか。
発生条件を組み立てられる形で確認します。
再現しない場合は、調査できないのではありません。
調査者が作った再現情報ではなく、発生時点に残された情報から条件を考えます。
本番環境で、何でも再現してよいわけではない
再現性を確認することは大切です。
ただし、再現すること自体が、新しい障害や業務影響を生んでは意味がありません。
本番環境で安易に繰り返してはいけない操作があります。
データの削除や重複登録、メールや通知の再送、課金や決済、外部システムへの再送信、バッチ処理の二重実行、権限変更、サービス停止、大量データの処理などです。
たとえば、メール送信時にエラーが出たとしても、同じ操作をそのまま繰り返せば、相手へ重複してメールが届くかもしれません。
課金処理であれば、金銭的な影響が出る可能性があります。
再現を試す前に、データが変わらないか、取り消し可能か、外部や業務へ影響しないかを確認します。
最初の証拠を失わないか、関係者の承認が必要ではないかも判断しなければなりません。
本番で安全に確認できない場合は、検証環境やサンドボックス、複製データ、読み取り専用の確認、ログ調査などへ切り替えます。
再現できるかどうかより、安全に再現してよいかを先に判断します。
なお、セキュリティインシデントが疑われる場合は、通常の不具合確認とは異なる手順が必要です。自己判断で再実行せず、所定のインシデント対応へ切り替えます。
再現しなかったことも、調査結果として残す
「再現しませんでした」
この一文だけでは、次の担当者は何を確認したのか分かりません。
どの利用者で、どの端末を使い、どのデータを対象にしたのでしょうか。何回試し、どの条件をそろえたのでしょうか。
一つでも条件が異なれば、結果の意味は変わります。
再現確認では、少なくとも次の内容を記録します。
確認日時
確認した担当者
対象環境
利用者
端末
使用したデータ
操作手順
権限
ネットワーク
試行回数
発生回数
変更した条件
発生した条件
発生しなかった条件
次に確認する内容
1回試して発生しなかったのか。10回試して2回発生したのか。特定データでは毎回発生し、別の利用者では一度も起きなかったのか。
同じ「再現しなかった」でも、意味は違いますよね。
発生した条件だけでなく、発生しなかった条件にも価値があります。
原因候補を減らし、次の担当者が同じ確認を繰り返すことを防げるからです。
障害調査を個人の記憶や勘に閉じないためにも、試した条件と結果を残します。
障害調査は、答えを探す前に問いを絞る
ログには、多くの情報があります。
ただ、何を探しているのかが定まっていなければ、調査範囲は広がるばかりです。
障害の連絡を受けたら、まず事象と業務への影響を確認します。
すでに起きた状態を記録し、再現による影響を考え、安全に試してよいかを判断する。
安全であれば、可能な範囲で同じ条件をそろえます。条件を変える場合は一つずつ変え、発生する条件と発生しない条件の差を見ます。
その差から、確認すべきログ、設定、端末、データ、権限、依存サービスを絞ります。
再現しない場合は、問題を否定するのではなく、発生時点の画面や時刻、ログ、監視情報から条件を組み立てます。
再現性を確認することは、原因をすぐに当てる方法ではありません。
調査の問いを小さくするための作業です。
障害調査は、答えを探す前に、どの条件で起きた問題なのかを確かめるところから始まります。
障害調査の実務チェックリスト
問い合わせを受けたとき
何が起きたか
いつ起きたか
誰に起きたか
どの端末・環境で起きたか
どの操作で起きたか
どのデータを使用したか
毎回起きるか
ほかの利用者でも起きるか
現在も継続しているか
業務への影響は何か
直前に変更があったか
エラー画面やログは残っているか
再現確認の前
最初の状態を記録したか
エラーコードと発生時刻を残したか
再実行による影響を確認したか
本番で試してよい操作か
同じ条件を整理したか
一度に複数の条件を変えていないか
検証環境で代替できないか
関係者の承認が必要ではないか
再現確認の後
再現したか
何回試したか
何回発生したか
どの条件で起きたか
どの条件では起きなかったか
正常な条件と何が違うか
次に見るログや設定を絞れたか
結果をチケットへ記録したか
次の担当者が調査を続けられる内容か
再現性から、調査する範囲を絞る
ディーシステムでは、障害対応を、ログの中からエラーらしい行を探すだけの仕事とは考えていません。
事象と業務影響を確認し、最初の状態を残す。安全に再現できるかを判断し、条件をそろえながら、発生する場合と発生しない場合の差を確かめる。
その結果をもとに、読むべきログや確認する設定、データ、端末、依存サービスを絞ります。
障害を早く解決するためにも、最初からすべてを見るのではなく、まず調査すべき問いを小さくする。
それが、再現性を確認する理由です。
