第4回は、前回と同様に、やはり解決するのが困難で再現性が低く、なかなか再現させられない障害をどのようにデバッグするかをテーマに解説します。


なかなか再現しない障害
障害や予期せぬ現象が起きた時、発生方法がわかり再現させやすい現象であれば、その原因を究明する事は比較的容易です。しかし、障害発生時の操作を繰り返し行なっても再現頻度が一定でない（同じ操作10回で発生する事もあれば100回以上繰り返しても発生しない）場合などは、その原因を究明するのは非常に困難です。また、そのような状況の中で、デバッグ文を追加したり、デバッグのためにソフトウェア構成を変更したら現象が再現しなくなってしまい、そのまま出荷したらフィールドで障害が発生してしまったと言う事例も多くあります。


障害が再現しないのはなぜ？
現象の再現を難しくしている要因の多くは、次のような事が原因になっています。
・プログラム/システムが複雑化で相互の干渉が把握しきれない
　　例) 特定のプログラムを同時に実行した時にのみ発生
・開発者が想定しきれていなかった実運用時の運用方法や操作
　　例) ボタンＡとボタンＢの同時押しなど、特定操作や特定環境下でのみ発生

・プログラムの実行タイミングによる再現性
　　例) デバッガを接続したり、デバッグ文を挿入すると再現しない



再現が難しい障害のデバッグ手法
このような再現が難しい障害が、開発現場や出荷後にフィールドで発生した場合には、一般的に次の様な手法をとります。

【開発現場では】
・現象発生時の状況や操作などの情報より、デバッガを接続した状態で何とか再現させ、スレッド情報、コールスタック情報、変数値等から原因を解析する
・繰り返し操作やアプリケーションの起動/終了を自動実行するようなツールを作成し、デバッグ文のログを取り続け解析する
・現象により問題がありそうなプログラムを絞り込み、コードを解析する

【フィールドでは】
・障害が起きた機器をそのままの状態で回収して解析する
・発生する現象により問題がありそうなプログラムを絞り込み、デバッグ文の出力ログを機器内部に収集する仕組みを埋め込み、現象発生時にログを回収する


現状の問題と課題
エンジニアは、少しでも早く問題を解決しようと何とかして現象が再現するよう努力しますが、そ

こには次のような問題と課題が残っています。
今後の開発環境では、これらの問題と課題を少しでもクリアしていく事が求められます。

【問題】
・デバッガを接続したり、デバッグ文を挿入すると現象が再現しなくなる
・機器内に大きなログ用バッファが確保できず、現象が起きた時にはバッファがオーバーフローしていたり、リングバッファを設定していてもログを回収した時には現象発生時の情報が上書きされて残っていなかった
・デバッグ文のログでは十分な情報が得られなかったり、パフォーマンスの低下を招いてしまう
・プログラムが複雑で、机上デバッグでタイミングまで追いきれない
・Exceptionの発生やハングアップ現象では、機器をリセットするしかない

【課題】
・デバッガの接続やデバッグ文の挿入により現象が再現しなくなる場合、通信接続をしないで情報を収集できる仕組み
・収集したログ情報がオーバーフローや上書きにより消えてしまわない仕組み
・Exceptionの場合、Exception直前までの情報を回収できる仕組み
・長期間の安定性を保証するために機器に埋め込み、常に情報を収集し続ける仕組み


次回のテーマ
最終回は、期待していたパフォーマンスが出ないときのデバッグ手法など、製品の品質を向上させるためのテクニックについて解説するとともに、これまでに課題として挙げてきたデバッグ手法における問題点や課題を解決するアプローチについてまとめます。