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