本サイト上のコンテンツは、参照目的だけのために、英語の原本から翻訳されたものです。また、本サイト上のコンテンツの一部は機械翻訳されたものです。日本語版と英語版の間に何らかの齟齬がある場合には、英語版が優先されます。
当社は改善のためのあらゆる努力を行いますが、翻訳の正確性及び信頼性は保証せず、当社に故意または重大な過失がある場合を除き、不正確性又は遺漏により生じる損失又は損害に責任を負わないものとします。
トラブルシューティングは、IT プロフェッショナルにとって重要なスキルです。それを回避することはできません - 私たちの膨大な時間は、うまくいくはずのものがなぜうまくいかないのかを理解することに費やされています。コンピュータやネットワーク関連の問題を診断して解決する能力の多くは、経験から生まれています。ただし、必要な答えを見つけるためのガイドとなるフレームワークもあります。
これらのコンテンツはいずれも CompTIA に限定されるものではありませんが、事実上すべての CompTIA 認定にはトラブルシューティング方法論の目的が含まれていることを指摘したいと思います。このトラブルシューティング プロセスは、経験に基づいて長年にわたって構築されており、IT コミュニティの新しいメンバーが問題を解決する際のガイドとして機能します。
CompTIA のトラブルシューティング方法は次のとおりです。
- 問題を特定する
- 推定原因の理論を確立する
- 理論をテストして原因を特定する
- 問題を解決し、潜在的な影響を特定するための行動計画を確立します
- 必要に応じてソリューションを実装するか、エスカレーションします
- システム全体の機能を確認し、該当する場合は予防策を実装します
- 調査結果、アクション、成果、学んだ教訓を文書化する
これらの手順が何を意味するか見てみましょう。
1. 問題を特定する
多くの場合、この手順が最も簡単です。これは、ユーザーからの着信電話、ヘルプ デスク チケット、電子メール メッセージ、ログ ファイル エントリ、またはその他のソースを介して実行できます。ユーザーが問題や停止について警告することはまったく珍しくありません。
特定の問題の根本原因が必ずしも明らかであるとは限らないことを認識することが重要です。たとえば、ログイン試行の失敗は、ユーザー名またはパスワードの問題を示しているように見えるかもしれませんが、実際の問題は、リモート サーバーに対して認証情報がチェックされないネットワーク接続の欠如である可能性があります。
トラブルシューティング担当者として、変更を加える前に、エラー、設定ミス、またはサービスの中断の根本原因を特定していることを確認するように細心の注意を払う必要があります。
ここでの具体的な手順には次のものが含まれます。
- ログ・ファイルおよびエラー・メッセージからの情報の収集
- ユーザーに質問する
- 症状の特定
- 最近の変更の判別
- 問題の複製
- 一度に 1 つずつ複数の問題にアプローチする
- 問題の範囲を絞り込む
2. 推定原因理論を確立する
まず、このステップの言葉の不正確さを指摘したいと思います。理論 や 確率などの 言葉は 、たとえそれがデータに裏付けられた推測であっても、あなたの側の推測を示しています。このステップの書き方は、根本原因 (ステップ 1) が正確に特定されていない可能性があることを認めています。ただし、原因はトラブルシューティングを開始するのに十分なほど具体的です。
この段階では、あなたの側でかなりの調査が必要になるかもしれません。理論の基礎を提供するには、ベンダーのドキュメント、組織独自のドキュメント、および古き良き Google 検索がすべて必要になる場合があります。それは排除のプロセスです。
Cisco、Red Hat、Microsoft、Apple などの企業は、トラブルシューティング担当者がアイデアを交換し、他の IT 担当者が提供する一般的な原因、解決策、トラブルシューティング方法について読むドキュメントや発行リポジトリやフォーラムを維持しています。サイバーセキュリティの懸念についても同様の知識ベースが存在します。
このフェーズの手順は次のとおりです。
- 問題の原因を特定するために明白なことに疑問を投げかける
- 階層化されたテクノロジー (ネットワークなど) の上から下または下から上を含む複数のアプローチを検討する
私が新しいトラブルシューティング ツールで観察した主な問題の 1 つは、明白なことに疑問を抱いていないことです。私の授業では、これを「シンプルに始めて、複雑なものに向かって取り組む」と言い換えます。はい、オペレーティング システム、ネットワーク、クラウドの展開はすべて非常に複雑であることは承知しています。ただし、それは問題が複雑であるという意味ではありません。考えられる原因は、あなたが思っているよりもはるかに単純かもしれません。
長年にわたり、この時点では注意深くメモを取ることが重要であることに気づきました。メモには、Web サイトからコピーしたデータ、Web URL、チーム メンバーからの提案などを含めることができます。
3.理論をテストして原因を特定する
ステップ 1 と 2 で最も興味深いのは、構成を変更する必要があることです。それらは情報収集に関するものです。実装する準備ができているソリューションがあることを合理的に確信するまで、変更を加えないでください。
このステップは、「情報収集」フェーズの一部でもあります。
経験豊富な管理者が、ステップ 1、2、3 を非常に迅速かつ非公式に進めることは珍しくありません。問題や症状は一般的な問題に基づいていることが多いため、エラー メッセージやデバイスの故障の考えられる原因を簡単に推測できます。
この段階では、ステップ 1 の「問題を特定する」に戻っていることに気付くかもしれません。考えられる原因を発見するために理論をテストし、間違っていたことがわかった場合は、研究を最初からやり直す必要があるかもしれません。ユーザーにチェックインしたり、ログ ファイルを深く掘り下げたり、Google を使用したりすることができます。
一部のワークステーションのトラブルシューティングには、CPU、メモリ(RAM)、ストレージ(ソリッドステートドライブおよびハードディスクドライブ)などのハードウェアコンポーネントが含まれます。これらの部品を正常な部品と交換する必要がある場合があります。その他の問題は、オペレーティング システム (Windows、Linux、macOS など ) やアプリケーション (Word、Excel、Chrome、その他のプログラム) の問題など、ソフトウェア ベースのものである可能性があります。
ネットワークのトラブルシューティングプロセスは、スタンドアロンのワークステーションまたはサーバーでの問題解決とは異なります。ネットワーク問題に対する効果的なネットワークトラブルシューティング手法は、オープンシステム相互接続(OSI)モデルを しっかりと理解することから始まります。この 7 層モデルはネットワーク プロセスを定義し、基本的な概念と見なされます。
まず、システムの IP アドレス構成を確認します。次に、ルーターやスイッチなどのネットワーク コンポーネントの状態を確認します。サービスの可用性も確認します。ドメイン ネーム サービス (DNS)、動的ホスト構成プロトコル (DHCP)、ファイアウォールなどのネットワーク サービスはすべて、ネットワーク機能にとって重要です。Namp や Wireshark などのツールは、トラブルシューティングに役立ちます。
根本的な問題を見つけたと確信したら、次のステップはそれを解決するための準備をすることです。
4. 行動計画を策定し、ソリューションを実装する
トラブルシューティングの問題の根本原因がわかっていると思われる場合は、対処方法を計画できます。やみくもに特定の行動方針に飛び込む前に、事前に計画を立てる理由をいくつか紹介します。
- 一部の修正では、再起動またはその他のより重要な形式のダウンタイムが必要です
- 続行する前に、ソフトウェア、パッチ、ドライバー、またはオペレーティング システム ファイル全体をダウンロードする必要がある場合があります
- 変更管理手順では、本番環境で修正を実装する前に、ステージング環境でシステム構成の変更をテストする必要がある場合があります
- 一連の複雑な手順、コマンド、およびスクリプトを文書化する必要がある場合があります
- リカバリ中に危険にさらされる可能性のあるデータのバックアップが必要になる場合があります
- 変更を加える前に、他の IT スタッフの承認が必要な場合があります
この段階の後、システムの構成の変更を開始できます。
これで、問題を解決するためにやるべきことは何でもする準備が整いました。これらの手順には次のものが含まれます。
- スクリプトの実行
- システムまたはソフトウェアの更新
- 構成ファイルの編集
- ファイアウォール設定の変更
試みている修正で問題が解決しない場合に備えて、ロールバック計画を用意していることを確認してください。少なくとも開始した場所に戻るには、設定を元に戻すことができなければなりません。
場合によっては、提案された修正の実装が、それ以前の調査フェーズよりも速くなる可能性があります。ただし、これらの調査フェーズは、実際の問題に対処し、ダウンタイムを最小限に抑えるために不可欠です。
5. システム全体の機能を確認し、予防策を実施する
私はかつて、トラブルシューティングのまさにこの段階で障害を観察しました。ユーザーが問題のサポート担当者に電話して、動作していないプリンターを調査しました。到着すると、プリンターの電源コードが抜かれていることに気づきました。彼はそれを再び接続し、ユーザーがコンピューターを理解していないと不平を言い、立ち去りました。しかし、彼が気づかなかったのは、プリンターが詰まっており、ユーザーが詰まりを修復しようとしているときにプラグを抜いたということでした。技術者は機能を検証せずに立ち去りました。
可能であれば、システムに依存しているユーザーにテスト機能を提供してもらいます。彼らは、システムがどのように動作すべきかを本当に知っており、システムが特定の要件に確実に応答することを保証できる人です。
問題によっては、複数のサーバーまたはネットワークデバイスに修正を適用する必要がある場合があります。たとえば、サーバー上のデバイス ドライバーに問題が見つかった場合は、同じデバイスに依存する複数のサーバーでドライバーを更新する必要がある場合があります。
6. 調査結果の文書化
ドキュメンテーションは私の厄介な問題です。それは、ドキュメントがゼロの組織のネットワーク管理者として働いていることから生まれます。私は会社が5年間で雇った6人目の管理者でしたが、私以前の誰も何も書き留めていませんでした。悪夢でした。
トラブルシューティングの手順、変更、更新、理論、および調査を文書化することは、将来同様の問題が発生した場合 (または同じ問題が最終的に修正されていないことが判明した場合) に役立つ可能性があります。
方法論全体を進める際に優れたドキュメントを保管するもう 1 つの理由は、これまでに試したことを他の人に伝えることです。私は一度、障害が発生した Exchange サーバーについて Microsoft テクニカル サポートと電話をかけていました。技術者が最初に言ったのは、「これまで何を試しましたか?」でした。私は、もう一度試す必要のないことのリストを 3 ページ持っていました。この体系的なアプローチにより、時間を大幅に節約できました。
このようなドキュメントは、変更によって意図しない結果が生じた場合にも役立ちます。変更を元に戻したり、設定を変更したりすることは、何をしたかについての適切なドキュメントがあれば、より簡単に行うことができます。
7. シンプルにする
ただし、このトラブルシューティング方法は単なるガイドです。各ネットワーク環境は一意であり、その環境で経験を積むにつれて、問題の考えられる原因を予測し、正しいトラブルシューティング手法をより簡単に適用できるようになります。
将来のサポートスタッフに少しでも知恵を伝えることができるとすれば、それは単に潜在的な原因を特定することから始めることに関する上記のちょっとしたことです。私のコースで、私が提案した主なトラブルシューティングチェックリストの1つは、次のとおりです。
- 接続されていますか?
- オンになっていますか?
- 再起動しましたか?
これは派手で単純化されすぎているように思えるかもしれませんが、これらの手順は実際には価値があります (実際、これらの手順を再確認すると便利です)。しかし、本当の教訓は、この3つのステップではなく、単純から始めて、より複雑なものに向かって取り組むという、それらのタスクの精神です。
最後に、上記のトラブルシューティング方法では対処されていないことの 1 つは時間です。多くの場合、サービス・レベル・アグリーメント (SLA)、規制上の制限、またはセキュリティ要件の範囲内で作業することになります。そのような状況では、上記の手順を効率的に実行できる必要があります。
トラブルシューティング手法に慎重に従うことで、システムやネットワークの問題の発見と解決において、より一貫性があり、効率的になることができます。サポートスタッフのためにそのような方法論を正式にすることを強くお勧めします。
CompTIA CertMaster Learn で必要なトラブルシューティング スキルを学びましょう。 今すぐチェックしてください。