トラブル対応の基本プロセス（３） 情報収集と解析

さて、期日やビジネスインパクトが聞き出せたら、実際にトラブルを解決する作業に入る。その第一歩は情報収集である。採取漏れがないように、収集すべき情報をチェックリスト化しておくのがよい。どんな製品にも共通するのは次の５つだ。

１．環境

ハードウェア構成やネットワーク構成、OSやパッケージソフトのバージョンやサービスパック／パッチ適用状況などだ。それに、最近実施した環境変更。これは特に重要だ。いままで動作していたのに、ある日トラブルが起き始めたという場合、何らかの環境変更が引き金を引いている可能性が高い。問い合わせてきたユーザ担当者が把握していない環境変更も含め、徹底的に洗い出す必要がある。

２．発生頻度・タイミング

必ず発生するのか、一定のパターンがあるのか、それとも不定期に発生するのか。不定期に発生するものはやっかいだが、まずは発生日時を一覧表にしてみるのがいいだろう。そこから何かパターンが見えてくるかもしれない。他の処理との関連がないかという観点で一覧表を見ることも必要だ。たとえば、レスポンスが不安定だったり、突然悪化したりという性能問題の場合、他の処理との資源競合を疑うのが定石である。同じ観点での調査は、性能問題以外でも解決の手がかりになりうる。

３．再現手順

再現手順がわかっている場合は、それを聞き出す必要がある。このとき注意すべきことは、ユーザは、これはやっていて当たり前だろうという先入観がもとで、細かい手順を省いて知らせてくる場合があるということだ。手順がひとつ漏れただけで発生しなくなることは非常に多い。漏れなく聞き出す必要がある。

４．調査経緯

トラブルが発生した以降、ユーザ側でどんな対処をおこない、その結果はどうだったか、そして何が原因と推測しているかなどを聞き出す。ただし最初に述べたように、ユーザが思い違いをしている場合もあるので、あくまで参考情報として聞くにとどめる。

５．各種のログ

もっとも信頼できる情報源はログやトレースである。具体的なトラブル調査はログの解析から始まると言っても過言ではない。ログを解析するときに、正規表現による文字列検索・抽出というテクニックが役に立つ。高機能なテキストエディタ（たとえば秀丸エディタ）や、Perlなどのテキスト処理言語の使い方に習熟していると、調査の効率が格段に向上する。たまに、Windowsのメモ帳でログを見ているSEを見かけるが、あれでよく解析できるものだと感心する。プロは道具にこだわるべきだ。弘法は筆を選ぶのである。

収集した情報を解析して原因を突き止めるのが「トラブルシューティング」だ。トラブルシューティングの基本は「仮説と検証」である。ログなどを解析して、「この部分が問題ではないか」という仮説を立てる。そして、ハードやネットワークの構成を一時的に変えたり、ソフトやハードの設定を変えたり、操作手順を変えたり、デバッグログを採取したりして、その仮説が正しいかどうかを検証する。この地道な繰り返しだ。

仮説・検証を繰り返すと、新たな資料が必要になることがある。これをユーザに依頼すると、必要な資料はまとめて要求しろと叱責を受けることがある。資料を採取するのさえユーザにとっては負担であるというのは理解できるし、取り漏れがないような努力を欠かしてはいけない。しかし、どんなトラブルシューティングでも仮説・検証が基本であり、あとから追加資料を要求するのは避けられない。これを説明して納得していただくことも必要だ。 資料が必要な理由を全く説明せずに、資料送付だけを依頼することは、やってはならない。繰り返すが、人を動かすには理由が必要だ。

（続く）