トラブルシューティングのルール、トラブルシューティングへのアプローチは？
難しいネットワーク/ハードウェア/ソフトウェアの問題をトラブルシューティングするときに頼る一般的なルールはありますか？
例：「2台目のコンピュータで周辺機器をテストして問題の原因を特定します」または「デバイスに電源を投入するために可能な限り多くのハードウェアを取り外し、コンポーネントを1つ追加します問題が再現できるまで1つずつ」など
しばらく問題と戦った後、自分のために書き留めたポイントのリストです。
- 主な目標は何ですか？明確かつ簡潔に述べる必要があります。目標は非常に具体的でなければなりません。一般的ではありません。できれば1文。
- あなたの問題は何ですか ？
- 1つまたは複数の問題だけですか？数が多い場合は、一度に1つずつ解決してください。
- 異なる条件で問題を再現してみてください。あらゆる条件で再現できますか？問題の性質について何か言いますか？
- それが緊急の問題である場合、回避策がありますか？できるだけ多くの回避策を見つけてください。
- 問題の原因をできるだけ多くの推測にするようにしてください。
- システムでexperimentで推測を証明してみてください。
- 一貫性を保つ何をしようとしているのか。一度に1つのことを行います。
- 追跡する何をしているか、すでに試したことを記録します。
- 逸脱しないことあなたの第一の目標から。あなたがまだ主な問題を解決しているかどうかを常にチェックしてください。
- fixateではないも実行します。
デバッグルールの優れたリストもあり、PDFフォームにあり、各ルールの例と説明が記載されていました。PDFをすぐに見つけることができませんでしたが、これはリストのポスター：
問題がインターネットに関連している場合、それはおそらくDNSです。
問題の診断が難しい場合、それはおそらくRAMです。
問題がWindowsワークステーションにある場合は、おそらくイメージを再作成するのが最も早いでしょう。
問題が金曜日にある場合、それはおそらく深刻な問題です。
科学的方法 にフォールバックしたい。
（ http://en.wikipedia.org/wiki/Scientific_method ）から
- 質問を定義する
- 情報とリソースの収集（観察）
- フォーム仮説
- 実験を行い、データを収集する
- データを分析する
- データを解釈し、新しい仮説の出発点となる結論を導き出す
- ドキュメントの結果
一般的なルールとして、私は常に自分の基本的な仮定を再確認するようにしています。電源は入っていますか、差し込まれていますか、配線は良好です。ケーブルが緩んでいるときに、ソフトウェアの問題を確認するのに何時間も費やすのは非常に不愉快です。
仮説の作成フェーズでは、問題の考えられる原因をできるだけ多く見つけることが非常に重要だと思います。次に、テストするのがいかに簡単であり、アイデアがどの程度の確率であるかに基づいて、最初にテストするアイデアを選択します。
助けを求めることも重要です。可能であれば、同僚、ベンダー、または問題のシステムについて最も詳しい人に相談してください。問題の解決に役立つ担当者がいる場合は、問題の解決に多くの時間を費やさないでください。
O'Reillyには優れた本があります ネットワークトラブルシューティングツール 科学的方法と非常によく似た一連の優れた手順があります。その本はとても役に立ったので、強くお勧めします。本はより多くの詳細に入り、多くの有用なツールを提案します。
- あなたの目標を述べる
- システムを定義する
- 考えられる結果を特定する
- 測定対象を特定して選択する
- 必要に応じて、テストパラメータと要因を特定します
- ツールを選択
- 測定の制約を確立する
- 実験計画をレビューする
- データを収集します
- データを分析する
関連項目：
- 3COMには トラブルシューティングガイド があります。
- マーフィーの法則 -うまくいかない可能性のあることなら何でもします。
- Occam's_razor -他のすべてが等しい場合、最も簡単な解決策が最適です。
（これらのハイライトは "The Practice of System and Network Administration" の「Debugging」の章から言い換えられています）
知っておくべき2つのこと：
「修正された」バージョンがどのように見えるかを知ってください。できれば、正常に機能したときに特定の出力が得られるコマンドを実行できます。例：キーを適切に設定したときにSSHがパスワードを要求する理由を理解しようとしています（またはそう思っていました）。したがって、私のテストは「ssh servername uptime」であり、パスワードを要求せずに機能するはずです。
適切なレベルで問題を説明してください。サーバーにpingを送信できないとユーザーが不平を言って、サーバーを実行して修正することはできません。その人の仕事は、一日中座ってマシンにpingすることではありません。彼らは、マシンをDNSサーバーとして使用するなど、何らかのタスクを実行したいと考えています。例：あるユーザーが世界中のマシンにpingを送信できないと不平を言った場合。私は1日を費やして、会社のその部分のシステム管理者を追跡し、そのマシンの何が問題であったかを見つけました。それは廃止され、おそらく間違ったマシンの電源を切ったのではないかと考えてパニックになりました。ユーザーに連絡を取り、「このマシンにpingする必要があるだけでなく、何をしたいですか？」と言いました。彼はその上で特定のジョブを実行したいと考え、適切な手順に従っていた場合、彼のタスクは自動的に交換用マシンにリダイレクトされたことが判明しました。私は一日中、そしてローカルのシステム管理者の時間を無駄にしていました。 「pingできない」という別の理由は、テストするのに適切ではありません。多くの場合、ファイアウォールはpingパケットをドロップするように構成されていますが、他のパケットは通過できます。やりたいことをテストします。
2つの戦略：
Additive：問題が発生するまでコンポーネントを追加し続けます。あなたが追加した最後のものは問題です。例：Webブラウザーはサーバーと通信できません。サーバーとユーザーの間には、ロードバランサー、ファイアウォール、キャッシュ、ユーザーのローカルWebプロキシがあります。まず1つのコンポーネントを追加するたびに、クエリをサーバーに直接送信してから、LBを介してサーバーに送信し、次にファイアウォールを介してLBからサーバーに送信するなどを試みます。
Subtractive：問題がなくなるまでコンポーネントを削除し続けます。あなたが最後に取り除いたのは問題でした：例：何十枚ものカードがあるマシンは起動しません。マシンが起動するまでカードを取り外し続けます。
2つのばかげた運：
私が言ったすべてを忘れてください。 問題はシステムに加えられた最後の変更によって引き起こされています。（これは99％の確率で動作します...問題は99％の最後の変更が実際に何であったかわからないとき）
他のすべてが失敗したら、愚かなことを確認します。http://whatexit.org/tal/mywritings/dumb-things-to- check.html 例：クレイジーな問題は説明できませんでした。次に、構成ファイルを確認しました。ユーザーがそれをWindowsボックスにコピーして編集し、編集してから元に戻しました。すべての行の終わりに^ Mが追加されました。テキストエディターがこの事実を黙って隠していたので、私たちは気づきませんでした。悲しいことに、構成ファイルを読み取るソフトウェアは、これらの^ Mを非ブレークスペースに変え、他の多くの手順を台無しにしました。
私が試してみた態度：
- 原因と結果が機能し、何も魔法ではないという絶対的な自信。実際に奇妙なことは何も起こっていません。私が理解できないことだけです。
- 私がそれを押し続ければ、私はそれを解決するだろうという絶対的な自信（これは、より知識のある人にそれを持ち、学び、助けを求めること、ハードワークなどを含むかもしれません）。
- セットアップ、プログラム、シナリオの設計がうまくいかなかったり、本当に愚かであるかどうかについて不平を言ったりしても役に立たないので、やめてください。 （私はこれを難しいと感じ、不平を言うのは楽しいです）。
これらは私が握るのに役立つ態度です-彼らは私が空中に腕を投げ、「奇妙な」何かを宣言してからあきらめる、または「解決できない」と感じて不幸になるのを止めます。
トラブルシューティングについて私が考える方法：
- システムには多くのパーツがあり、それらが一緒に接続されているか、ランダムに構成されていると、期待どおりに機能しません。機能する非常に特殊な構成が1つまたは2つあります。レンガや金属を積み上げる何百万もの方法のうち、ブリッジはわずかで、ブリッジは1つまたは2つで十分です。原因は、テキストファイル内の文字またはサーバーの障害である可能性がありますが、全体が正しくなるためには、すべての部分が正しくなければなりません。必要に応じて、徹底して細心の注意を払う必要があります。システムは「ショーを続けなければならない」ことはできません。
- マップのようなシステム全体から始めて、「問題の場所」を表すマップ上に浮かぶ確率の雲を想像します。あなたの仕事は、経験を使ってテストを見つけ、確率を特定の領域から他の領域に押し出し、それを確率の高い問題の場所であるポイントに凝縮し、それらを攻撃します。これは原因と結果のポイントに戻ります-問題はシステムにあり、魔法ではありません。それは存在する問題なので、どこかに存在しなければなりません。
- 誰でも好きなように設定できます。ある動作を「正常」と定義し、別の動作を「問題」と定義する唯一の方法は、誰かが得ているものは彼らが望んでいるものではないためです。あなたは彼らが何を望んでいるのか、彼らが明確かつ具体的に何を得ているのかを理解しなければなりません。
トラブルシューティングのプロセス：
- 何が問題ですか。それが起こっていることを確認し、誤解がないように自分で再現できることを確認してください。そのため、ヘルプデスクの担当者が私に連絡するまでに何度も問題が発生し、問題が何であるかを誰にも説明できませんでした。
- それは繰り返し再帰的な二等分です-分割統治、二分探索-問題がテストのこちら側かそれともその側かを証明するテストを思いつき、可能な限り排除するようにテストを作成します。解決するまで繰り返します。
- 回避できるかどうかは知らないでください。データベースのアカウントをロックして、データベースが使用されていない状態でも問題が発生することを証明するほうが、データベースの使用方法を何時間も学ぶよりも良いでしょう。
- 「次に何をしたらいいのかわからない」と思うのは、あまりにも簡単です。それがいつ発生するかを確認し、問題を特定するテストを考え出すことに戻ります。
インターネットが機能していませんか？問題を確認し、アクセスできないWebサイトであることを確認します。クイックテストにはインターネット接続（動作中）が含まれますが、ロードされます（いいえ）。簡単なテストはそれがサイトであることを示しています。私に問題が発生するのを確認することで、PC、ブラウザー、DNS、ユーザーアカウントのオフィスのファイアウォールなどから確率をすぐに引き離しました。
それで、サイトはロードされません、今何ですか？それはまだ修正可能ではないので、問題をより小さなものに切り分ける場所を探します。サーバーはオンですか？ pingしますか？ DNSは機能しますか？はい。サービスはポート80で応答しますか？いいえ。サービスは実行されていますか？いいえ、始まりますか？いいえ。イベントログやログファイルでエラーが発生しますか？はい！彼らは何と言いますか？
これは、問題の範囲を絞り込むことに集中しているため、効率的で迅速なトラブルシューティングです。インターネットが機能していないという彼らの報告を受け入れた場合、私はそれが接続の失敗だと誤解するでしょう。彼らにとってロードされないという私の最初の目撃を受け入れた場合、私はそれが故障していると思って彼らのコンピュータで時間を浪費するでしょう。
「あり得ないもの」のかたまりをできるだけ大きく切り分けます。
システムを理解する。システムに関する一般的な知識が多ければ多いほど、システムはより簡単になります。私の理解が弱い場合、問題はより威圧的で、困難で、進行が遅く、最終的には修正よりも回避策、または小さな正確な外科的修正よりも大規模な遅い修正（再インストール）になる可能性が高くなります。
プロセス全体で覚えている一般的な方法：
- 私が行うすべてのことを書きなさい。
- 一度に1つだけ変更してください。
- 可能であれば、明確な進展がない限り、変更を元に戻してから、別の変更を試みてください。
トラブルシューティング中に、ここで私の基本的な方法を定義します。
- システムが正常に稼働している場合は、問題が発生する前に、システムの動作を確認するようにしています。 ジョーリチャーズは、なぜこの短いスペースで私ができるよりもずっと良いのかを説明しています .
- 私は最も簡単なソリューションから始めます。たとえば、ネットワーク接続がありませんか？物理層を確認します。断続的な接続の問題がサーバーの問題ではなく、ハーフインまたは不良のネットワークケーブルであった回数はわかりません。
- 変更を始める前に、考えられるすべてのソースから確認できるすべての症状をキャプチャしようとしています。
- 予備診断テストを実行します。たとえば、サーバーがダウンしていると通知された場合、最初に行うことは、pingおよびnbtstat（Windows）を使用してそれを確認することです。問題は遠いところにある可能性があります（古い空軍の技術統制を借りて）。
- 私は研究をすることを恐れていません。 Google、support.Microsoft.com、eventid.netなどのサイトはあなたの友達です。
- 私はコミュニティに助けを求めることを恐れていません。 serverfault.comのようなサイトだけでなく、私が信頼し、連絡を取り合っているTwitterで尊敬している人々はたくさんいます。
- 私は私が見ているもので私が見つけている答えを評価します。ソリューションで報告されている内容について確認している証拠を十分に検討できるようになるまで、1つのソリューションが適切であるとは思いません。
通常、「この問題の原因となった可能性のある変更点」を尋ねます。ほとんどの問題は、既知の適切な構成への変更が原因です。誰が変更を行ったかを特定できれば、通常は答えが得られます。
科学ではなくスキルだと思います。あなたが間違った道を行く時がありますが、大部分は：
- 関連するすべてのテクノロジー（ネットワーク、ハードウェア、OS、ソフトウェア、開発など）の基本をよく理解していると、これらの「間違ったパス」の一部を排除するのに役立ちます
- 基本的に考える-頭の中にあるので、最も複雑なscenraioにジャンプしないでください。基本的なトラブルシューティングを実行し、それがあなたを導きます。
私はかつて、上司に電話で「上級」エンジニアを呼んでもらいました-彼はoneサーバーが接続できず、ケーブルを切り替えようとしたがまだ喜びがないと言っていました。 UPSのバッテリーのように、バックグラウンドでビープ音が聞こえました。私は彼にスイッチでのアクティビティを見ることができるかどうか尋ねました、彼はノーと言いました。 UPSからビープ音が鳴っているかどうかを尋ねたところ、「はい」と答えた。「ラックのライトがまったく点灯していないか」と尋ねたところ、鼻が見えなくなった。
私は明白なものをチェックすることから始めます。問題が何であるかを説明するエラーメッセージはありますか？すべてが正しく接続されていますか？数分で解決できる問題のトラブルシューティングを数時間無駄にしたくありません。あまりにも整然とすることは可能だと思います。私が問題を正確に言ったにもかかわらず、人々が問題を再現するのに丸一日費やすのを見てきました。それは私が彼らに支払うものではありません。
答えが明らかでない場合は、容疑者を並べて、最初にそれらをテストします。可能性のある容疑者をテストした後にのみ、可能性の低い容疑者をテストする必要があります。そうすれば、好きなだけ科学的になることができます。