当您解决困难的networking/硬件/软件问题时,您是否有任何一般的规则?
例如:“我通过用第二台计算机testing外设来隔离问题的根源”或“我尽可能多地移除硬件以启动设备,然后逐个添加组件,直到我能重现问题”等等
只是我在为一个问题争取了一段时间后为自己写下的一些要点:
还有一个很好的debugging规则列表,它是一个PDF格式的实例和每个规则的解释。 我不能快速findPDF,但我认为这是列表的海报:
如果问题是与互联网相关的,则可能是DNS。
如果问题很难诊断,那可能是RAM。
如果问题出在Windows工作站上,重新映像可能是最快的。
如果问题在星期五,那可能是严重的。
我喜欢回到科学的方法 。
从( http://en.wikipedia.org/wiki/Scientific_method )
- 定义这个问题
- 收集信息和资源(观察)
- forms假设
- 进行实验并收集数据
- 分析数据
- 解释数据并得出结论作为新假设的起点
- 文档结果
作为一般的规则,我总是喜欢尝试和检查我的基本假设。 它是否有电力,是否插入,是否接线良好。 当你有一个松散的电缆,试图看看一个软件问题花费几个小时是非常烦人的。
在假设创造阶段,我发现它非常重要,可以尽可能多地提出问题的原因。 然后,我尝试select想法,首先根据testing的容易程度以及想法的可能性来进行testing。
获得帮助也很重要。 如果可以的话,请咨询你的同事,供应商,或谁是最有关系统知识的人。 如果有人可以帮助您解决问题,请不要花太多时间来解决问题。
O'Reilly有一本很好的networking故障排除工具书,它有一套很好的步骤,跟科学方法非常相似。 我发现这本书非常有用,并强烈推荐它。 这本书进入了更多的细节,并提出了许多有用的工具。
从networking故障排除工具
- 陈述你的目标
- 定义系统
- 确定可能的结果
- 确定并select您要测量的内容
- 如果合适的话确定testing参数和因素
- select工具
- build立测量约束
- 审查实验devise
- 收集数据
- 分析数据
也可以看看:
(这些要点从“ 系统和networkingpipe理实践 ”的“debugging”一章中解释)
有两件事要知道:
知道“固定”版本是什么样子。 最好是一个可以运行的命令,在事情发生时给出一定的输出。 例如:我想弄清楚为什么SSH正确设置密钥(或者我认为)时要求input密码。 所以我的testing是:“ssh服务器名正常运行时间”,它应该没有问密码工作。
请在适当的级别描述问题。 用户抱怨他们无法ping通服务器,不应该让您运行并修复服务器。 这个人的工作就是不要整天坐在一台机器上。 他们想要完成一些任务,比如使用机器作为他们的DNS服务器。 例如:一旦用户抱怨说他们无法在世界的一半地方ping机器。 我花了一天的时间追踪公司那个部门的系统pipe理员,找出那台机器出了什么问题。 它已经退役了,他们陷入了恐慌,因为他们认为他们已经closures了错误的机器。 我联系了用户,并说“除了需要ping这台机器之外,你还想用它来做什么?”。 事实certificate,他想要在其上执行某项工作,如果他一直遵循正确的程序,他的任务将被自动redirect到replace机器。 我浪费了我整天的时间和当地的系统pipe理员的时间。 “我不能ping通”的另一个原因是不正确的testing:通常防火墙被configuration为丢弃ping数据包,但允许其他数据包通过。 testing你想要通过什么。
两个策略:
添加剂:保持添加组件,直到问题开始。 你添加的最后一件事是问题。 示例:Web浏览器无法与服务器通信。 服务器和用户之间是一个负载均衡器,一个防火墙,一个caching以及用户的本地Web代理。 首先尝试直接向服务器发送查询,然后通过LB到服务器,然后通过防火墙到LB到服务器等等,每次添加一个组件。
减法:继续移除组件,直到问题消失。 您删除的最后一件事是问题:例如:有几十个卡的机器将无法启动。 保持取出卡,直到机器启动。
两位愚蠢的运气:
忘记我所说的一切。 问题是由系统的最后更改造成的。 (这是99%的时间…问题是99%的时间你不知道最后的变化是什么)
当一切都失败时, 检查愚蠢的东西。 http://whatexit.org/tal/mywritings/dumb-things-to-check.html示例:一个疯狂的问题无法解释。 然后,我们检查了configuration文件:用户通过将其复制到Windows盒子进行编辑,然后将其复制回来。 现在在每一行的末尾都有一个^ M。 我们从未注意到,因为我们的文本编辑器默默地隐藏了这个事实 可悲的是,读取configuration文件的软件将这些^ Ms变成了一个无休止的空间,这个空间已经搞砸了大量的其他程序。
我在整个过程中记得的一般做法:
在故障排除过程中定义了我的基本方法:
我尝试和保持的态度:
这些态度对我来说是有帮助的 – 他们阻止我把手放在空中,宣布一些“怪异的”,然后放弃,或者因为感觉“无法解决”而感到不快。
我想解决问题的方法:
排除故障的过程:
互联网不工作? 检查问题,发现它是一个他们无法访问的网站。 快速testing涉及到他们的互联网连接(工作),是否加载我(不)。 快速testing指出它是该网站。 通过看到问题发生在我身上,我已经迅速将它的概率从他们的PC,浏览器,DNS,用户帐户办公室防火墙等方面推出去了。
所以网站不加载,现在是什么? 那还不是可以解决的,所以找个地方把问题刻成小一点。 服务器在吗? 它平吗? DNS工作? 是。 服务是否在端口80上回答? 不。服务正在运行吗? 不,它是否开始? 不。它是否在事件日志/日志文件中发生错误? 是! 他们说什么?
这是高效和快速的故障排除,因为它无情地专注于缩小问题的范围。 如果我接受他们的报告,说互联网不工作,我会被误导成连接失败。 如果我接受了我的第一个目标,那就是没有为他们加载,我会浪费时间在他们的计算机上认为这是错误的。
划出大块“不可能的东西”尽可能大。
了解系统。 我对系统的一般知识越容易获得。 如果我的理解力不足,那么问题就会更加棘手,更困难,更慢,而且更有可能最终采取一种解决方法而不是解决scheme,或者比一个小而精确的手术解决scheme更麻烦的慢速修复(重新安装)。
一般来说,我问“可能导致这个问题的原因是什么”? 大部分问题是由已知良好configuration的变化引起的。 如果你能隔离谁做了改变,那么你通常会得到你的答案。
我认为这是一种技巧,而不是科学。 有时你走错了路,但大部分是:
有一次,我的老板打电话给我的是一位“高级”工程师,他告诉我说,他有一台服务器无法连接,他试图切换电缆,但仍然没有喜悦。 我可以在背景中听到像电池UPS一样的哔哔声。 我问他是否可以看到交换机上的活动,他说不。 我问他,UPS是否发出了哔哔声,他说是的,我问他是否可以看到任何灯在他的机架上,他说不…看看你的鼻子 – 这有助于!
我从检查明显开始。 是否有错误信息说明问题是什么? 一切正常吗? 我不想浪费几个小时来解决几分钟内就能解决的问题。 我认为可能太有条不紊。 尽pipe事实上我已经告诉了他们究竟是什么问题,但我已经看到人们浪费了整整一天的时间来重现问题。 那不是我付的钱。
如果答案不明显,先列出一些嫌疑人并进行testing。 只有在对可能的嫌疑人进行检测之后,才能检验不太可能的嫌疑犯。 那么你可以像你想要的那样科学。