問題切り分けの技術について

( Update 2009-09-29: タイトルを変更しました）
ポルトガルのInformixブログに、興味深い記事を見つけました。

http://informix-technology.blogspot.com/2009/08/where-do-you-stop-as-dba-thoughts-about.html

運用環境でonbarがハングする、という現象が発生してから、その原因を突き止めるまでの長い道のりについての読み物です。お客様先にオンサイトで作業していたこのブログの著者は、ハング時のonbar_dプロセスの挙動をdbxやtrussなどのツールで調べ、このプロセスがsend()の結果を待っている状態になっていることに直ぐ気づき、ストレージマネージャのベンダーに報告し調査を依頼したそうです。ところが、ストレージマネージャ・ベンダーの担当者がデバッグツールについての知識に乏しく、onbar_dから見たときのストレージマネージャーの挙動について、直ぐには理解できなかったところから、数ヶ月にも及ぶ「無駄」な実験・議論の繰り返しに巻き込まれてしまったそうです。

実はこの時、ストレージマネージャー側はrecv()待ちでハングしていた、ということで、調査の対象がＯＳに移っていきました。

結局はＯＳが提供しているＡＰＩの問題だったそうです。

ここで出てくる、onbarは、XBSAインターフェースを使って、多様なサードパーティ製ストレージマネージャーとの組み合わせで高機能なバックアップ・復元が行えるツールです。ですが、その一方で、関連するコンポーネントの多さ故、ちょっとした設定の誤りによって、意図しない挙動、原因不明のハングアップなどに遭遇することが考えられます。こんな時、ちょっと落ち着いて設定を見直してみる、とか、上記の例にあるような、デバッグツールによる解析（場合によってはツールを使わないで、ＯＳのログ - /var/adm/messagesなどを参照してみる)を試みる、などにより、思わぬことに気づくことがあります。（もちろん、ソースコードを参照できるわけではないので、限度はありますが。）

でも、何より大事なのは、基本的な設定や利用方法に日頃から慣れておくことでしょうね。バックアップはともかく、特にリストアはふつうのユーザーが普段そんなに頻繁に使用するものではありません。避難訓練と同じで、緊急時に問題なくシステムの復元ができるよう、普段から手順に慣れておくことも、とても大事なことだと思います。