您的故障排除规则,解决方法?

当您解决困难的networking/硬件/软件问题时,您是否有任何一般的规则?

例如:“我通过用第二台计算机testing外设来隔离问题的根源”或“我尽可能多地移除硬件以启动设备,然后逐个添加组件,直到我能重现问题”等等

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

    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。 只有在对可能的嫌疑人进行检测之后,才能检验不太可能的嫌疑犯。 那么你可以像你想要的那样科学。