社のサポートケースについて紹介しました。システムに問題が発生した時に、ログファイルや設定ファイルなどシステムの状態を把握するための情報を一括して取得するためのツールです。ファイルの内容を確認することで状況を把握し、次の行動を考えます。取得する上での注意点としては、以下の点が挙げられます。コマンドを実行すると、内部で様々なコマンドが実行されます。その中には、カーネルモジュールを自動的にロードしてしまうものもあります。コマンドの実行結果を比較しましょう。コマンドの実行中はCPU使用率の上昇と大量のディスクI/Oが観測されます。コマンドによる負荷を軽減するために、以下の方法を組み合わせることができます。コマンドを用いることで、CPUの優先度を下げることができます。コマンドを用いることで、CPUの優先度を下げることができます。関連プロセスを特定のCPU上でのみ動作させるように制限できます。コマンドを用いることで、ディスクI/Oの優先度を下げることができます。コマンドが実行される)ようになっています。いうオプションを指定することにより、一部のパッケージの整合性検査だけを行うように指定することができます。いうオプションを指定すると良いでしょう。取得するタイミング問題事象が発生したらすぐに取得することが大切です。問題事象の発生から1週間以上経過してから故障解析を依頼してくるお客様が見受けられるのですが、その頃には事象発生時のシステムのログやリソース使用状況などの履歴が既に消滅してしまっていて、状況を確認できないということがあります。トラブルシューティングには、平常時の状態と問題発生時の状態とを見比べて、不審な点を見つけていくという側面があります。取得しておきましょう。コマンドを実行した場合の影響の有無や程度を予め確認しておくという狙いもあります。ファイルには、全ての情報が含まれている訳ではありません。sosreportファイルと一緒に収集しておきましょう。ファイルを解析したものの手掛かりを見つけられず「原因不明です」という残念な回答をする可能性を低減できます。前回の記事では、サポートセンターへの依頼の際には調整が起こらないようにすべきということを書きました。調整は、主に依頼元の注文(特別なリクエスト)がきっかけとなり始まりますから、「依頼の際には、できるだけ注文をつけないほうが良い」ということです。「本トラブルのために商用サービスが止まっているので、一刻も早く対処しなければならない。現場に技術者をよこして欲しい」です。これらの注文を見て、あなたはどう思われますか?「うん、いかにもありそうだ。サポートセンターは困っている人を助けるべきで、もちろん対応すべきだ」でしょうか。依頼する側から見ると、そうなると思います。これらの注文をサポートセンターの中から見ると、話は少し変わってきます。「依頼の内容を見てみないと対応時間はわからない。この件の対応時間が見えたとしても、対応中の他の案件や作業もあるから、調整してみないと約束はできない」です。「現場に行ってしまうと、サポートセンターの過去の対応履歴や技術情報が使えないからできることが限られてしまう。「第一報の内容だけでは何が起こっているかよくわからない。「(真に必要な状況のようなので)誰か行かせたいが、今日が期限の問い合わせの状況を確認してみないとなんとも言えない」のように考えます。これらサポートセンターの中の人の考え方について、私は「科学的であり合理的」だと思いますが、いかがでしょうか。同意いただけない方もあるかもしれませんが、こうした考え方が「あくまで問題解決を優先している」こと、および「サポートセンターは全体の依頼を意識して動いている」ことは強調しておきたいと思います。え?「サポートセンターの中の人の考え方はわかったけれど、結局、会議の報告はどうすれば良いのか?」ですって?それについては次回説明します(それまであなたのシステムが平和でありますように!)。Corporation。