大所帯のITチームに所属するメンバーは、部門間の責任のなすり合いに慣れている。ヘルプデスクがアプリケーションの動作速度の低下に関して報告を受け取ると、システム管理者はネットワークが原因だと責める。ネットワーク管理者はSAN（ストレージエリアネットワーク）が原因だと責める。ストレージ管理者はソフトウェア自体が原因だと責める。サーバで発生した障害のトラブルシューティングをする場合、データセンターインフラのどの領域が影響を受けているかを特定するとよい。アプリケーションの動作速度の低下といった、漠然とした問題を扱うような場合は特にそうだ。複数のサーバとアプリケーションに障害が発生している場合、一般には、サーバ本体が原因である可能性を排除し、ネットワークまたはストレージアレイを疑う。仮想化環境の場合、障害が発生している仮想マシン（VM）の物理ホストの設置場所を全てチェックする。それにより、問題のVMが同一ハードウェアで稼働していないかどうかを確認する。そのようなハードウェア自体に問題がある場合もある。

　大抵の場合、可能性排除のプロセスを踏めば明確に原因を特定できるが、常にそうとは限らない。問題の共通点を見つけ、さまざまな要因の組み合わせを試して、可能性を絞り込もう。あるファイル共有から別のファイル共有へのコピーに時間がかかり過ぎるという問題が発生したとしよう。同じ拠点で、あるサーバから別のサーバにコピーする場合も時間がかかるのであれば、原因はWAN（ワイドエリアネットワーク）ではない。サーバのローカルディスク間でコピーした場合も同様に時間がかかるのであれば、原因はSANでもLAN（ローカルエリアネットワーク）でもない。最後の手段としてパケットキャプチャーまたはI/O速度テストが必要な場合は、サーバのトラブルシューティングが長時間に及ぶ可能性がある。

3.サーバ設定と接続に関する詳細な記録を保管する

　ドキュメントの作成は非常に価値のあるトラブルシューティングの手段だ。環境構成が容易に入手でき、その上でどのようにアプリケーションが動作するのかを理解することで、サーバのトラブルシューティングにかかる時間を短縮できる。

　データセンターの運用について熟知するとよい。各アプリケーションに対して何台のサーバが関与しているのか。基本的なネットワーク設定は何か。どのインフラがどこに設置されているのか。こうしたことを知っておく必要がある。2台のアプリケーションサーバがあり、クライアントはラウンドロビンDNS（Domain Network System）を介してこれらのサーバに接続するという状況を考える。半分のユーザーが問題を報告したとする。この場合、ラウンドロビン方式なので、ユーザーの半分ずつが各サーバに接続していることが最初から分かっている。従って問題解決のために、不具合のある方のサーバを直した後にもう一台のサーバを確認して時間を無駄にする必要はない。

4.チームメンバーとコミュニケーションを取る

　コミュニケーションを取ることはサーバのトラブルシューティングをする上で重要だ。ある夜、同僚がサーバの設定を変更し、翌日何か不具合が発生したとしよう。システム担当者であるあなたはその変更について知る必要がある、なぜなら原因はその設定変更にある可能性があるからだ。大企業では変更手続き用の書式を導入し、全員が変更内容を共有できるようになっている。しかし全てのITチームがそのような書式を導入できる余裕があるとは限らないし、見方によっては余計な手間にもなり得る。

　良好なコミュニケーションを取ることは、新しいアプリケーションやその他の変更を本番環境に導入する際に、データセンターチームが動作環境を準備して、積極的に監視するのに役立つ。コミュニケーションが不足すると、エンドユーザーが機能低下について苦情を報告する段階になったとき、新しいアプリケーション、実装、およびリソース要求についてメンバーに逐一質問することになる。

5.サーバの状態を包括的に監視し、ログデータを確認する

　詳細かつ継続的に運用状況を概観することで、トラブルシューティングに費やす時間を節約しよう。

　昨今、データセンターの規模や構造に合わせて利用できる、さまざまな監視ツールが提供されている。適切に設定すれば、レイテンシやI/O速度などの重要な数値指標を監視できる。それによりストレージやネットワーク担当者が取り組むべき問題が分かる。監視ツールは、サーバ障害を引き起こす可能性がある「ディスクの空き容量がたった1％のドライブ」など、潜在的に有用な情報についても担当者に警告を提示する。

　このような監視ツールはサービス状況も監視していることがある。重要なサービスがクラッシュして停止した場合、ツールを使って、アラートを送信するか設定したルールに基づいて自動的に再起動を試みることが可能だ。

　驚くべきことに、サーバとそれに関連するログは見落とされる場合が少なくない。

　問題が発生したとき、技術者は問題の原因を知っていると考え、自分の理論を証明しようとして何時間も費やす。しかし数分でもログを確認すれば、問題の原因が正確に記載されていることを発見できるかもしれない。例としてアクセス許可に関する問題は、アクセスしようとしている者の正体とアカウントの2つが分かれば、解決は容易だ。

　Windowsのイベントビューアログ、またはUNIX／Linuxサーバのログを記録する機能「syslog」で記録される警告およびエラーを確認するとよい。アプリケーションログにも、根本的な原因につながるエラーデータが含まれていることがあるので、確認する価値がある。隔離された格納場所にログデータを保存し、長期的なサーバの状態と動作状況を追跡することが大切だ。

6.ベンダーとのSLAを理解する

　管理者の中には「ベンダーの助けを借りることは敗北である」と考える者もいるが、そんなことはない。基本的な項目を一通りチェックした後は、サーバがダウンするまで無為に数時間待つのではなく、数分でも通話記録を取るべきだ。

　IT環境が支障なく動作しているうちに、時間をかけてベンダーとの間で交わしたサービスレベル契約（SLA）上の関係する部分を詳細に確認するとよい。障害が発生したとき、翌営業日までベンダーから連絡が来ないような状態となった場合は、その障害の内容をできるだけ速やかに記録して、障害のストレスを一晩中ためこまないようにする。

　ベンダーは、サーバで発生する障害のトラブルシューティング方法について具体的な指示書を保有していることがしばしばある。指示の詳細は通常、オンラインで入手可能だ。ベンダーのナレッジベースおよびオンラインフォーラムからリソースを確認しておこう。

　サーバのトラブルシューティングと解決に5分以上かかる場合はイライラすることがあるが、助けを求めることにちゅうちょしてはいけない。準備、コミュニケーション、そして動作環境についての深い理解は、組織を窮地から救う「英雄」となるツールだ。