您的故障排除规则、故障排除方法？

知道“固定”版本是什么样的。 最好是您可以运行的命令，该命令在运行时提供特定输出。例如：当我正确设置了密钥（或者我认为是这样）时，我试图弄清楚为什么 SSH 要求输入密码。所以我的测试是：“ssh servername uptime”，它应该可以在不询问密码的情况下工作。
在正确的级别描述问题。 抱怨他们无法 ping 服务器的用户不应该让您去运行和修复服务器。这个人的工作不是整天坐在那里敲打机器。他们想要完成某种任务，例如将机器用作他们的 DNS 服务器。示例：曾经有用户抱怨他们无法 ping 世界另一端的机器。我花了一天时间跟踪公司那部分的系统管理员，以找出那台机器出了什么问题。它已退役，他们感到恐慌，因为他们认为可能关闭了错误的机器。我联系了用户说“除了需要ping这台机器，你还想用它做什么？”。事实证明，他想在上面运行某个作业，如果他一直遵循正确的程序，他的任务将自动重定向到替换机器。我浪费了我一整天和本地系统管理员的时间。“我无法 ping”的另一个原因不适合测试：防火墙通常配置为丢弃 ping 数据包但允许其他数据包通过。测试你想经历什么。

两种策略：

添加剂： 继续添加组件，直到问题开始。您添加的最后一件事是问题。示例：Web 浏览器无法与服务器通信。服务器和用户之间是负载均衡器、防火墙、缓存和用户的本地 Web 代理。首先尝试直接向服务器发送查询，然后通过 LB 发送到服务器，然后通过防火墙发送到 LB 到服务器等等，每次添加一个组件。
减法：继续移除组件，直到问题消失。您删除的最后一件事是问题：示例：具有数十张卡的机器将无法启动。继续取出卡，直到机器启动。

两点愚蠢的运气：

忘记我说的一切。 问题是由上次对系统所做的更改引起的。 （这在 99% 的情况下都有效……问题在于，99% 的情况下您不知道最后一次更改实际上是什么）
当所有其他方法都失败时，检查是否有愚蠢的事情。 http://whatexit.org/tal/mywritings/dumb-things-to-check.html 示例：一个无法解释的疯狂问题。然后我们检查了配置文件：用户通过将其复制到 Windows 框，编辑它，然后将其复制回来来编辑它。它现在在每一行的末尾都有一个 ^M。我们从未注意到，因为我们的文本编辑器默默地隐藏了这一事实。可悲的是，读取配置文件的软件将这些 ^Ms 变成了一个不间断的空间，从而搞砸了大量其他程序。

Answer 5

K. *_*ley 6

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

写下我所做的一切。
一次只进行一项更改。
如果可能，请在尝试另一个更改之前撤消更改，除非正在取得明确进展。

在故障排除期间，这里定义了我的基本方法：

当系统启动并运行良好时，在出现问题之前，我会尝试了解它在做什么。乔·理查兹解释了为什么在这短短的篇幅里比我能做到的要好得多。
我从最简单的解决方案开始。例如，没有网络连接？检查物理层。我无法告诉您有多少次间歇性连接问题不是服务器问题，而是网络电缆半入或坏了。
在开始进行更改之前，我会尝试从所有可能的来源中捕获我可以看到的所有症状。
我进行初步诊断测试。例如，当我被告知服务器关闭时，我做的第一件事就是使用 ping 和 nbtstat (Windows) 来验证这一点。问题可能出在远处（借用空军技术控制的一句老话）。
我不怕做研究。Google、support.microsoft.com、eventid.net 和类似的网站是您的朋友。
我不怕向社区寻求帮助。不仅仅是像 serverfault.com 这样的网站，而且我在 Twitter 上有很多我信任和尊重的人，我一直与他们保持联系。
我用我所看到的来评估我找到的答案。我不认为任何一种解决方案都是正确的，直到我可以对解决方案中报告的内容进行足够的考虑。

Answer 6

Tes*_*ler 6

我尝试保持的态度：

绝对相信因果关系有效，没有什么是魔法。没有发生什么实际上很奇怪的事情，只有我不明白的事情。
绝对有信心，如果我继续推动它，我会解决它（这可能涉及将它带给知识渊博的人，学习，寻求帮助，努力工作等）。
抱怨设置、程序或场景设计不当或非常愚蠢无济于事，所以不要这样做。（我觉得这很难，抱怨很有趣）。

这些态度对我有帮助——它们阻止我将双臂举在空中，宣布某事“奇怪”然后放弃，或者因为感觉“无法解决”而变得不开心。

我认为故障排除的方法：

系统有很多部分，如果它们连接在一起或随机配置，那么它们将无法按预期工作。有一两个非常具体的配置可以工作——在数百万种堆砌砖块和金属的方法中，只有少数是桥梁，只有一两个是足够好的桥梁。原因可能是文本文件中的一个字符或服务器出现故障，但每个部分都必须正确才能使整个事情正确。如果需要，我需要愿意做到彻底和细致。系统不能做到“演出必须继续”。
你从像地图这样的整个系统开始，你想象在地图上漂浮的概率云代表“问题在哪里”，你的工作是利用经验并找到测试来将概率从某些区域推向其他区域，将其压缩为高概率问题位置的点，然后攻击这些点。这又回到了因果点——问题出在系统上，这不是魔法。这是一个存在的问题，所以它一定存在于某个地方。
任何人都可以以任何方式设置任何东西。我们可以将一种行为定义为“OK”而另一种行为定义为“问题”的唯一方法是因为某人得到的不是他们想要的。你必须清楚地了解他们想要什么，他们想要什么。

故障排除过程：

问题是什么。确保您看到它发生并且可以自己重现它，这样就不会出现误传。很多时候问题已经通过我们服务台的几个人来找我，但仍然没有人可以向我解释问题的真正含义。
这又是递归二分法——分而治之，二分搜索——你想出一个测试来证明问题是在测试的这一边还是那一边，并进行测试，使其尽可能多地消除。重复直到解决。
不要学习是否可以避免 - 最好锁定数据库帐户并证明在不涉及数据库的情况下问题仍然发生，而不是花费数小时学习数据库的使用方式。
发现自己在想“我不知道下一步该做什么”太容易了。请注意何时发生这种情况，然后返回进行定位问题的测试。

互联网不工作？检查问题，发现是他们无法访问的网站。快速测试涉及他们的互联网连接（工作），它是否为我加载（否）。快速测试表明它是该站点。通过看到问题发生在我身上，我迅速将概率从他们的 PC、浏览器、DNS、用户帐户办公室防火墙等处推开。

所以网站没有加载，现在怎么办？这还不能解决，所以找个地方把问题分解成更小的问题。服务器开了吗？能ping通吗？DNS 工作吗？是的。服务是否在端口 80 上应答？否。服务是否正在运行？不，它开始了吗？否。它会在事件日志/日志文件中给出错误吗？是的！他们说什么？

这是一种高效且快速的故障排除方法，因为它始终专注于缩小问题的范围。如果我接受了他们关于互联网无法正常工作的报告，我会误以为这是连接失败。如果我接受我第一次发现它不会为他们加载，我会在他们的计算机上浪费时间，认为这是有问题的。

尽可能大的“不可能的事情”。

了解系统。我对系统的一般知识越多，它就越容易。在我的理解薄弱的地方，问题更令人生畏、更困难、进展更慢，并且更有可能以变通方法而不是修复结束，或者比小型精确的外科修复更容易出现笨拙的缓慢修复（重新安装）。

归档时间：	16 年，4 月前
查看次数：	16905 次
最近记录：	4 年前