步骤 3：再现问题

　　按照科学的方法，任何假想和试验的关键一点是，能够重建过程并产生相同的结果。如果做不到，结论至少是不确定的。在最糟糕的情况下，这会颠覆科学家的理论并损害他们的名誉，就像在上世纪 90 年代宣称实现了室温冷聚变的物理学家一样。

　　或者，按我的说法：如果一开始不成功，那么在其他地方试试是否可以造成同样的问题。

　　在管理 AIX 服务器时，如果某些东西出了问题，而您有再现问题所需的资源，那么在另一个相似类型的 LPAR 上执行相同的操作，看看是否会产生相同的结果。如果在另一个服务器上修改相同的属性会造成相同的结果，就可以推论这个操作就是问题的根源。但是，如果产生了完全相反的结果，那么要研究服务器之间的细微差别，尝试推测造成问题的原因。

　　对于第一个示例问题涉及的 LPAR，我发现当把 SAN 磁盘交换回老的 p670 服务器并启动它时，问题没有出现。用户能够访问他们的应用程序，CPU 承受正常的负载，CPU 利用率为 80% 多（10% 内核 + 70% 用户）。因此，我能够断定是 p570 服务器上特有的某些东西导致了问题，而不是迁移过程中引入的某些东西。

　　步骤 4：研究问题

　　在信息时代，只需敲几下键盘，点几次鼠标，就能够获得大量信息。更好的是，系统管理员往往是大型社区的成员，社区记录了很多人多年的经验。

　　首先应该查阅生产商和销售商自己的资料。IBM 这样的公司在网上公开他们的所有手册、Redbook、技术文件甚至 man 页面以供研究。只需在主站点的搜索栏中输入简单的关键字，就可以找到大量可能有帮助的建议和信息。

　　我推荐的其他信息源包括其他系统管理员经常访问的各个新闻组、论坛和站点。成天与服务器打交道的人往往会经常访问技术站点，并对在工作过程中看到的东西发表评论。对于公开的求助，大多数系统管理员乐于提供指点，或通过电子邮件往来提供帮助。另外，常常可以找到与操作系统和软件的其他版本相关的旧信息，可以通过它们找到更多信息。

　　对于这些信息源，主要的使用技巧是使用适当的关键字集。如果我使用 Google 这样一般性的网站研究 AIX 问题，那么会确保搜索字符串以 AIX 开头，以便排除与其他风格的 UNIX 相关的信息。然后，可能会包含命令的输出或 errpt 产生的标签等内容。我还会确保在特定的短语前后加上双引号 （“”），以便把搜索限制在这些特定的问题，避免无关的信息，对于常用的单词（比如 Logical Volume Manager）尤其应该这么做。

　　对于磁盘坏块重定位失败的问题，在 Google 上使用短语 AIX “bad block relocation” failure 进行搜索产生了几百个结果，但是看起来没有与我的情况相符的。

　　步骤 5：取消所有更改

　　有时候，解决问题最明智的做法是取消已经做的所有更改，回到原来的状态。这个步骤并非总是可行的。有时候，过分热心的 C 级执行官强迫您回退他们的服务器。或者，由于时间紧迫，有必要这么做。无论如何，回退是可供选择的最好的战术之一。

　　我把这个步骤放在故障排除步骤列表的中间位置，这是因为有时候必须早点儿这么做，有时候要晚一些。但是根据我的经验，我觉得最好先完成前四个步骤，然后再考虑取消所有更改。如果在故障排除过程开始时马上取消更改，问题很可能没有解决，下一次尝试相同的工作时还会遇到相同的麻烦。如果在过程中过晚回退，会影响正常运行时间，或者让问题复杂化，到了不可能回退的程度。

　　对于第一个示例，由于时间的原因，我实际上不得不回退了服务器迁移操作。如果这个生产服务器停运更长时间，用户和公司就会损失金钱。重新安排这项工作花了一周时间，这让我能够多做一些研究，但是当我再次尝试迁移时，问题又出现了。对于第二个示例，无法对硬件问题执行回退。无法告诉服务器，“回到发生坏块重定位错误之前的状态！” 我不得不继续努力克服磁盘的故障。

　　步骤 6：每次只更改一处规则

　　如果上面的所有步骤都不奏效，您决定开始更改主要组件或者对服务器做更激进的操作，那么要记住一条最重要的规则：每次只更改一处。

　　多处更改会导致两种情况之一。首先，如果这些更改解决了问题，那么您不知道哪个更改是有效的操作。如果您不关心究竟是什么解决了问题，这可能没什么大不了的，但是出色的系统管理员都希望掌握更多知识，因为他们知道问题往往会在同一地方多次出现。第二，如果问题没有解决，这可能会引入更多复杂性。继续这样做，您会不知道要取消哪个更改。如果走得足够远，系统会乱成一锅粥而您被弄得一头雾水。（xkcd 上有一个关于这种情况的笑话。）

　　如果做一处更改之后问题没有解决，通常希望取消它并尝试其他措施。在第一个示例中就是这种情况：当我对比两个服务器的 Hardware Management Console 概要文件时，看到它们不一样。我注意到老的 POWER4 硬件使用专用的 CPU，而新的 POWER6 硬件使用不封顶的共享 CPU 池。我想知道这一差异如何影响 CPU 性能，所以修改了 POWER6 硬件上的概要文件以使用专用的 CPU。奇怪的是，根据用户的反馈，服务器 “正常” 了，我在处理器上看到了负载。因此，我知道问题肯定与 CPU 资源有关，但是需要查明为什么会这样。