我一直认为从别人的错误中学习比从自己的错误中学习更好。在本专栏中，Kyle Rankin 或 Bill Childers 将讲述他们作为系统管理员多年的故事，而另一位会不时插话。这是一个双赢的局面：您可以从我们的经验中学习，而我们可以互相发表尖刻的评论。Kyle 将讲述本系列中的第一个故事。

我对我第一次去伦敦数据中心感到非常兴奋。我之前去伦敦度假过，但这是我第一次因公访问我们的主机托管设施。更重要的是，这是我第一次独自进行的远程数据中心之旅。因为我当时仍然是公司的新人，也是资历最浅的系统管理员，所以这是一个证明我知道自己在做什么并且可以信任我未来旅行的绝佳机会。

维护工作相对简单。几台机器需要重新安装 Linux，另外我还要排除一台无响应的服务器故障，审核我们的串行控制台连接，并做一些其他的零碎工作。我们估计这是一项为期两天的工作，但为了以防万一，我们增加了一个额外的备用日。

[Bill：如果我没记错的话，我不得不争取为你争取到额外的一天。我们从过去的经验中了解到，那个地方的任何事情似乎都不像表面上看起来那么容易。]

即使有额外的一天，我也希望这次旅行顺利进行，所以我制定了一个全面的计划。每个任务都按优先级排序，并附有详细的命令和程序列表，我将使用这些命令和程序来完成每个任务。我甚至设置了一个详细的清单，列出了我需要随身携带的所有物品。

[Bill：我记得当时觉得你太认真了——毕竟，这只是启动几台新机器而已。可能会出什么问题呢？事后看来，我很高兴你做了所有这些清单。]

到达数据中心的第一天，我就清楚地知道自己需要做什么。一旦我拿到徽章，并在多层安全人员的护送下到达我们的主机托管机笼，我就会逐个启动我列表中的每台服务器，并执行它们所需的所有手动配置步骤。如果我有时间，我可以完成其余的维护工作；否则，我会把任何其他任务留到第二天。

现在，值得注意的是，当时我们没有完善的 kickstart 系统，也没有先进的带外管理——只有一个串行控制台和一个远程控制的电源系统。虽然我们的数据中心确实有一个带有软件包仓库的 kickstart 服务器，但我们仍然需要将每台服务器连接到监视器和键盘，从安装 CD 启动，并手动输入 kickstart 文件的 URL。

[Bill：我认为这次经历是我们开始研究带外管理解决方案的起点。我记得向高管们推销它时说的是“在巴哈马群岛进行管理”，而向他们讲述这个故事是这次推销取得成功的关键原因之一。]

将所有东西连接到第一台服务器后，我插入 CD，启动系统，并按照我的详细计划输入我的 kickstart URL。我立即看到内核加载，并且 kickstart 进程正在进行中。哇，如果一切都这样顺利进行下去，我甚至可能 提前 完成这项工作，我想。在我开始为我在伦敦的额外几天制定计划之前，我看到了 kickstart 红色死亡屏幕。kickstart 日志显示，由于某种原因，它无法从 kickstart 服务器检索到一些它需要的文件。

太棒了，现在我需要排除故障一个损坏的 kickstart 服务器。幸运的是，我随身携带了笔记本电脑，故障排除很简单。我将笔记本电脑连接到网络，最终获得了 DHCP 租约，将浏览器指向 kickstart 服务器，果然，我能够看到我的 kickstart 配置文件并浏览我的软件包仓库，没有任何问题。

我不太确定哪里出了问题，但我将其归咎于一时的故障，并决定再次尝试。这一次，kickstart 失败了，但在安装过程中的不同点。我尝试了第三次，它在安装过程中的原始点失败了。我重复了 kickstart 过程多次，试图看到某种模式，但我看到的只是 kickstart 在几个不同的时间点失败。

这个问题最令人恼火的地方是不一致性。更糟糕的是，即使我有更多的时间来处理这个问题，启动第一台服务器也是最重要且需要立即完成的任务。几个小时后，我将有一队人在等待服务器，以便他们可以将其设置为数据库系统。

我身处离家千里之外的地方，呼吸着机架上服务器排出的热气，试图让一台顽固的服务器恢复生机。我还没有完全没有选择。我预感问题与 DHCP 有关，所以我仔细查看了 DHCP 服务器上的日志，并确认，是的，我可以看到租约正在授予给服务器，而且，是的，有充足的备用租约可以分配。我甚至为了保险起见重启了 DHCP 服务。

最后，我决定在 kickstart 期间查看 DHCP 日志。我将启动 kickstart 进程，看到机器获得租约，第一次或当我告诉它重试时，然后在安装过程中稍后失败。我有一个日志文件，其中充满了成功的 DHCP 请求，但没有解释它为什么不起作用。然后我得到了我的第一个真正的线索：在一次 kickstart 期间，我注意到服务器实际上多次请求 DHCP 租约。

即使有了这个线索，我也开始用尽解释。DHCP 服务器似乎运行良好。毕竟，我的笔记本电脑能够正常使用它，而且我有一个日志文件，其中充满了成功的 DHCP 请求。在这里，我转向了故障排除的下一个阶段：猜测游戏。我更换了电缆，更改了连接的网卡，甚至更换了交换机端口。在所有这些之后，我仍然遇到同样的问题。我现在已经启动机器太多次了，我已经记住了整个参数列表。我快要用完选择、耐心，最重要的是，时间了。

[Bill：我记得收到过一两封关于此事的电子邮件。我当时舒适地待在加利福尼亚州的公司总部，而你正在处理这件事，当时我正在睡觉。如果我醒着，我相信我本可以提供更多帮助。但我很高兴你在处理这件事。]

我现在处于故障排除的下一个阶段：祈祷。大约在这个时候，我有了重大突破。当我在更换所有电缆时，我注意到交换机上的一些有趣的事情——当我第一次插入电缆时，我正在使用的端口的 LED 灯变成了琥珀色，并且需要相当长的时间才能变成绿色。我注意到当我启动我的机器以及稍后在安装过程中再次发生同样的事情。看起来好像每次服务器启动其网络接口时，都会导致交换机重置端口。当我仔细观察时，我看到在一次安装过程中，当端口仍然是琥珀色并且就在它变成绿色之前，服务器退出了安装！

这一切意味着什么？虽然 DHCP 服务器确实运行正常，但 DHCP 请求本身通常有 30 秒的超时时间，然后才会给出错误。事实证明，这个交换机只是在 30 秒的限制边缘徘徊，以启动一个端口。当它低于 30 秒时，我会获得租约；当它不是时，我就不会获得租约。即使我找到了问题的原因，它对我也没有多大好处。因为安装程序似乎至少重置了它的端口三次，所以我几乎不可能幸运地获得三次连续的亚 30 秒端口重置。我必须想出另一种方法，但我并不管理网络设备，而且管理网络设备的人要几个小时后才会醒来（参见侧边栏）。

[Bill：我刚从大学毕业时一起工作的一个人总是告诉我“从布线开始进行故障排除。” 当排除网络问题时，很容易忘记可能影响链路层的事情，所以我现在将这些作为布线的一部分进行检查。这不会花费很长时间，并且可以节省大量时间。]

我开始回顾我的选择。我需要某种方法将交换机排除在等式之外。在我为这次旅行做的所有计划中，我碰巧带了一个相当多的 MacGyver 系统管理员工具包，包括一根短的手工交叉电缆和一个耦合器。我需要保持原始的 kickstart 服务器在网络上，但我意识到如果我可以将所有 kickstart 配置、DHCP 设置和软件包仓库克隆到我的笔记本电脑上，我可以用交叉电缆连接到机器并以这种方式完成 kickstart。

经过几次 apt-get、rsyncs 以及在服务器机房地板上进行的一些调整和优化，我的 Frankenstein kickstart 服务器准备就绪。正如我所希望的那样，kickstart 顺利完成。然后我能够在其他两台服务器上重复相同的任务，并且如释重负地向团队的其他成员发送电子邮件，说他们的所有服务器都已准备就绪，并且按计划进行。在旅行的第二天，我能够提前完成所有任务，以便我可以将最后的备用日用于在伦敦观光。这一切都表明，虽然一个好的计划很重要，但当事情不可避免地超出你的计划时，你也应该灵活应对。

[Bill：我很高兴你像你计划的那样做了计划，但这也突出了观察力和良好的故障排除方法的重要性。虽然你能够用你的笔记本电脑临时搭建一个新的 kickstart 服务器，但你可能会花费无限长的时间来追查这个问题。知道何时停止追查问题并放置一个创可贴与首先解决问题同样重要。]