您的故障排除规则，解决方法？

只是我在为一个问题争取了一段时间后为自己写下的一些要点：

1. 你的主要目标是什么？ 应该清楚而简洁地陈述。 目标应该是非常特别的。 这不应该是一般的。 最好一个句子 。
2. 你有什么问题 ？
3. 只有一个问题还是很多 ？ 如果有很多，一次解决一个。
4. 尝试用不同的条件重现问题。 它可以在所有可能的条件下复制吗？ 它是否提到了这个问题的性质？
5. 如果是紧急问题，是否有解决方法 ？ 尽量find尽可能多的解决方法。
6. 试着尽可能多的猜测你的问题的原因是什么。
7. 尝试certificate你的猜测， 试验系统。
8. 要坚持你想要做的事情。 一次做一件事。
9. 跟踪你在做什么，你已经尝试了什么。
10. 不要偏离你的主要目标。 不断检查你是否还在解决你的主要问题，而不是一个不同的问题。
11. 不要固定 。

还有一个很好的debugging规则列表，它是一个PDF格式的实例和每个规则的解释。 我不能快速findPDF，但我认为这是列表的海报：

• 如果问题是与互联网相关的，则可能是DNS。

• 如果问题很难诊断，那可能是RAM。

• 如果问题出在Windows工作站上，重新映像可能是最快的。

• 如果问题在星期五，那可能是严重的。

我喜欢回到科学的方法 。

从（ http://en.wikipedia.org/wiki/Scientific_method ）

1. 定义这个问题
2. 收集信息和资源（观察）
3. forms假设
4. 进行实验并收集数据
5. 分析数据
6. 解释数据并得出结论作为新假设的起点
7. 文档结果

作为一般的规则，我总是喜欢尝试和检查我的基本假设。 它是否有电力，是否插入，是否接线良好。 当你有一个松散的电缆，试图看看一个软件问题花费几个小时是非常烦人的。

在假设创造阶段，我发现它非常重要，可以尽可能多地提出问题的原因。 然后，我尝试select想法，首先根据testing的容易程度以及想法的可能性来进行testing。

获得帮助也很重要。 如果可以的话，请咨询你的同事，供应商，或谁是最有关系统知识的人。 如果有人可以帮助您解决问题，请不要花太多时间来解决问题。

O'Reilly有一本很好的networking故障排除工具书，它有一套很好的步骤，跟科学方法非常相似。 我发现这本书非常有用，并强烈推荐它。 这本书进入了更多的细节，并提出了许多有用的工具。

从networking故障排除工具

1. 陈述你的目标
2. 定义系统
3. 确定可能的结果
4. 确定并select您要测量的内容
5. 如果合适的话确定testing参数和因素
6. select工具
7. build立测量约束
8. 审查实验devise
9. 收集数据
10. 分析数据

也可以看看：

• 3COM有一个故障排除指南
• 墨菲定律 – 任何可能会出错的东西都会。
• Occam's_razor – 所有其他的事情是平等的，最简单的解决scheme是最好的。

（这些要点从“ 系统和networkingpipe理实践 ”的“debugging”一章中解释）

有两件事要知道：

1. 知道“固定”版本是什么样子。 最好是一个可以运行的命令，在事情发生时给出一定的输出。 例如：我想弄清楚为什么SSH正确设置密钥（或者我认为）时要求input密码。 所以我的testing是：“ssh服务器名正常运行时间”，它应该没有问密码工作。

2. 请在适当的级别描述问题。 用户抱怨他们无法ping通服务器，不应该让您运行并修复服务器。 这个人的工作就是不要整天坐在一台机器上。 他们想要完成一些任务，比如使用机器作为他们的DNS服务器。 例如：一旦用户抱怨说他们无法在世界的一半地方ping机器。 我花了一天的时间追踪公司那个部门的系统pipe理员，找出那台机器出了什么问题。 它已经退役了，他们陷入了恐慌，因为他们认为他们已经closures了错误的机器。 我联系了用户，并说“除了需要ping这台机器之外，你还想用它来做什么？”。 事实certificate，他想要在其上执行某项工作，如果他一直遵循正确的程序，他的任务将被自动redirect到replace机器。 我浪费了我整天的时间和当地的系统pipe理员的时间。 “我不能ping通”的另一个原因是不正确的testing：通常防火墙被configuration为丢弃ping数据包，但允许其他数据包通过。 testing你想要通过什么。

两个策略：

1. 添加剂：保持添加组件，直到问题开始。 你添加的最后一件事是问题。 示例：Web浏览器无法与服务器通信。 服务器和用户之间是一个负载均衡器，一个防火墙，一个caching以及用户的本地Web代理。 首先尝试直接向服务器发送查询，然后通过LB到服务器，然后通过防火墙到LB到服务器等等，每次添加一个组件。

2. 减法：继续移除组件，直到问题消失。 您删除的最后一件事是问题：例如：有几十个卡的机器将无法启动。 保持取出卡，直到机器启动。

两位愚蠢的运气：

1. 忘记我所说的一切。 问题是由系统的最后更改造成的。 （这是99％的时间…问题是99％的时间你不知道最后的变化是什么）

2. 当一切都失败时， 检查愚蠢的东西。 http://whatexit.org/tal/mywritings/dumb-things-to-check.html示例：一个疯狂的问题无法解释。 然后，我们检查了configuration文件：用户通过将其复制到Windows盒子进行编辑，然后将其复制回来。 现在在每一行的末尾都有一个^ M。 我们从未注意到，因为我们的文本编辑器默默地隐藏了这个事实 可悲的是，读取configuration文件的软件将这些^ Ms变成了一个无休止的空间，这个空间已经搞砸了大量的其他程序。

我在整个过程中记得的一般做法：

1. 写下我所做的一切。
2. 一次只做一次更改。
3. 如果可能的话，除非有明确的进展，否则在尝试另一种方法之前应该改变它。

在故障排除过程中定义了我的基本方法：

• 当系统运行良好时，在出现问题之前，我试着学习看看它在做什么。 乔·理查兹（Joe Richards）解释了为什么在这个短暂的空间里比我能做得更好 。
• 我从最简单的解决scheme开始。 例如，没有networking连接？ 检查物理层。 我不能告诉你有多less次间歇性连接问题不是服务器问题，而是networking电缆是一半或一个坏了。
• 我尝试捕捉所有可能的来源所见到的所有症状，然后再开始进行更改。
• 我运行初步的诊断testing。 例如，当我被告知服务器closures时，我所做的第一件事就是使用ping和nbtstat（Windows）来validation。 问题可能在远端（借用一个老的空军技术控制说）。
• 我不害怕做研究。 谷歌，support.microsoft.com，eventid.net和这样的网站是你的朋友。
• 我不害怕向社会求助。 不只是像serverfault.com网站，但我有一个很好的分类，我信任和尊重我的Twitter保持联系。
• 我评估我所看到的答案。 我不认为任何一种解决scheme都是正确的，直到我能够充分考虑解决scheme中报告的证据。

我尝试和保持的态度：

• 绝对的信心，因果作品，没有什么是魔法。 什么都没有发生，实际上是奇怪的，只有我不明白的东西。
• 绝对的自信，如果我继续推动它，我会解决它（这可能涉及到更多的知识，学习，求助，辛勤工作等）。
• 抱怨一个设置，程序或场景devise得不好或者真的很愚蠢只是没有帮助，所以不要这样做。 （我觉得这很难，抱怨很有趣）。

这些态度对我来说是有帮助的 – 他们阻止我把手放在空中，宣布一些“怪异的”，然后放弃，或者因为感觉“无法解决”而感到不快。

我想解决问题的方法：

• 系统有很多零件，如果它们连接在一起或随机configuration，那么它们将不能按需要工作。 有一个或两个非常具体的configuration将工作 – 所有的数以百万计的方式堆积砖和金属，只有less数是桥梁，只有一两个是足够好的桥梁。 原因可能是文本文件中的字符或服务器失败，但是每个部分都必须是正确的。 如果需要，我需要愿意彻底和细致。 系统不能做“演出必须继续”。
• 你从一个像地图这样的整个系统开始，你会想象在地图上浮现出一个代表“问题出在哪里”的概率云，而你的工作就是使用经验并findtesting把概率从某些地方推向另一个地方，把它压缩成高概率问题位置的点，然后攻击这些点。 这回到了因果关系 – 问题在于系统，这不是魔术。 这是一个存在的问题，所以它必须存在某个地方。
• 任何事情都可以以任何人想要的方式设置。 我们可以将一种行为定义为“好”，另一种定义为“一个问题”的唯一方法是因为某人得到的不是他们想要的东西。 你必须明白他们想要什么，他们正在清楚明确地得到什么。

排除故障的过程：

• 问题是什么。 确保你看到它发生，可以自己重现，所以没有沟通不畅。 所以，经常遇到问题的时候，我们的帮助台里面有好几个人还没有人向我解释问题到底是什么。
• 它是recursion的二分法 – 分而治之，二分search – 你提出一个testing，certificate问题是testing的这一边还是那边，并且使testing尽可能的消除。 重复，直到解决。
• 不要学习，如果你可以避免它 – 最好是locking数据库帐户，并certificate问题仍然发生时，数据库不涉及比花了几个小时学习如何使用数据库。
• 发现自己在想“我不知道下一步该怎么做”太容易了。 注意什么时候发生，然后回到提出testing找出问题。

互联网不工作？ 检查问题，发现它是一个他们无法访问的网站。 快速testing涉及到他们的互联网连接（工作），是否加载我（不）。 快速testing指出它是该网站。 通过看到问题发生在我身上，我已经迅速将它的概率从他们的PC，浏览器，DNS，用户帐户办公室防火墙等方面推出去了。

所以网站不加载，现在是什么？ 那还不是可以解决的，所以找个地方把问题刻成小一点。 服务器在吗？ 它平吗？ DNS工作？ 是。 服务是否在端口80上回答？ 不。服务正在运行吗？ 不，它是否开始？ 不。它是否在事件日志/日志文件中发生错误？ 是! 他们说什么？

这是高效和快速的故障排除，因为它无情地专注于缩小问题的范围。 如果我接受他们的报告，说互联网不工作，我会被误导成连接失败。 如果我接受了我的第一个目标，那就是没有为他们加载，我会浪费时间在他们的计算机上认为这是错误的。

划出大块“不可能的东西”尽可能大。

了解系统。 我对系统的一般知识越容易获得。 如果我的理解力不足，那么问题就会更加棘手，更困难，更慢，而且更有可能最终采取一种解决方法而不是解决scheme，或者比一个小而精确的手术解决scheme更麻烦的慢速修复（重新安装）。

一般来说，我问“可能导致这个问题的原因是什么”？ 大部分问题是由已知良好configuration的变化引起的。 如果你能隔离谁做了改变，那么你通常会得到你的答案。

我认为这是一种技巧，而不是科学。 有时你走错了路，但大部分是：

• 对所有相关技术（networking，硬件，操作系统，软件，开发等）有一个很好的基本了解，将帮助你消除一些“错误的path”
• 认为基本 – 不要跳到最复杂的情​​景，因为它在你的脑海中，执行你的基本故障排除，让它引导你。

有一次，我的老板打电话给我的是一位“高级”工程师，他告诉我说，他有一台服务器无法连接，他试图切换电缆，但仍然没有喜悦。 我可以在背景中听到像电池UPS一样的哔哔声。 我问他是否可以看到交换机上的活动，他说不。 我问他，UPS是否发出了哔哔声，他说是的，我问他是否可以看到任何灯在他的机架上，他说不…看看你的鼻子 – 这有助于！

我从检查明显开始。 是否有错误信息说明问题是什么？ 一切正常吗？ 我不想浪费几个小时来解决几分钟内就能解决的问题。 我认为可能太有条不紊。 尽pipe事实上我已经告诉了他们究竟是什么问题，但我已经看到人们浪费了整整一天的时间来重现问题。 那不是我付的钱。

如果答案不明显，先列出一些嫌疑人并进行testing。 只有在对可能的嫌疑人进行检测之后，才能检验不太可能的嫌疑犯。 那么你可以像你想要的那样科学。