从别人的错误中学习总是比从自己的错误中学习要好。在本专栏中，Kyle Rankin 或 Bill Childers 将讲述他作为系统管理员多年来的一个故事，另一个人会不时地插话。这是一个双赢的局面：您可以从他们的经验中学习，他们可以互相 snide 评论。今天的剧集由 Bill 讲述。

我当时非常痛苦。我们刚刚完成了一整夜在我们生产存储区域网络上的交换机迁移，而我正在与行走性肺炎作斗争，咳得要死。即使我在家完成了我那份通宵工作，我还是精疲力尽。所以当我的寻呼机在早上 9 点响起时，只给了我四个小时的睡眠，我已经危险地接近僵尸状态了。

我看了看寻呼机，看到有人按下了可怕的“紧急按钮”，这是一个我们制作的基于 Web 的工具，可以提醒更大的 IT 团队注意一个未知的高优先级问题。我坐起身来，摇摇晃晃，让我的妻子开始给我输注咖啡因静脉滴注液，这将让我醒来，而我慢慢开始将神经突触敲击在一起，希望能擦出火花。根据报告，我们的 DNS 基础设施在大量请求上超时，导致网站整体速度减慢。我不得不反复阅读那封电子邮件好几次，才让它沉入我缺氧和睡眠不足的大脑。DNS 怎么会超时，为什么我们的内部监控没有捕捉到？我们内部监控了 DNS 服务器和服务级别，如果性能不佳，我应该是第一个知道的。有些事情闻起来真的很奇怪，而且不是我，尽管有肺炎引起的发烧。

[Kyle：我会假装没看到“有些事情闻起来很奇怪”的评论，因为它太容易了。有趣的是，我们有一个长期以来的传统，即每当出现任何网络问题时，都会责怪 DNS。我之前说过，人们倾向于责怪他们最不了解的技术。这次是第一次看起来（至少从表面上看）确实是 DNS 问题。]

当我拨通关于此问题的电话会议时，我开始检查情况。我们的监控系统说一切正常，DNS 的响应时间也很正常。我通过 DNS 服务器运行了一些 nslookup，它以通常的速度和预期的结果回复。我也翻阅了日志，它们也没有显示任何异常。到底是怎么回事？

在这一点上，我可能应该描述一下公司 DNS 基础设施是如何设置的。它有两个主要的数据中心：A 和 B。每个数据中心都有一对负载均衡的 DNS 服务器设置为活动-被动模式，并且每个数据中心的公共虚拟 IP 地址都发布为我们服务的每个域的 NS 记录。这将导致每个数据中心为任何一组请求服务一半的 DNS 负载，并且由于每个数据中心都有一对负载均衡的 DNS 服务器，我们可以容忍一台 DNS 服务器的故障，而不会降低面向客户的服务。

[Kyle：这种系统的优点在于，即使 DNS 在您有多个 NS 记录时具有自动故障转移功能，但如果 DNS 服务器宕机，您通常必须等待 30 秒才能超时。30 秒的延迟对于我们的需求来说太长了，因此通过这种设计，我们可以关闭任何一台 DNS 服务器，负载均衡器只会将请求转发到数据中心中剩余的服务器。]

无论如何，我继续进行故障排除。凭直觉，我开始从我家对几个域名运行 nslookup——也许问题只能从外部看到。奇怪的是，nslookup 在大多数情况下都成功了，除了那些指向我们最活跃的站点之一的域名，该站点使用 Akamai 作为内容分发网络 (CDN)。Akamai 要求您使用 CNAME 或别名记录配置 DNS，以便其 CDN 可以抓取和缓存您的内容。CNAME 记录看起来像这样

• 一个 CNAME 将 www.ourdomain.com 指向 ourdomain.com.edgesuite.net。

• 一个 CNAME 将 origin-www.ourdomain.com 指向 ourdomain.com。

果不其然，命中数据中心 A 的外部请求会超时并最终故障转移到数据中心 B。典型的 DNS 超时会将其置于 30 秒左右，这对于任何类型的商业网站来说都是不可接受的。由于 Akamai 参与其中，并且我发现受影响的主要站点正在使用 Akamai，因此我致电 Akamai 支持寻求帮助。

[Kyle：我已经数不清多少次使用位于公司网络外部的个人服务器来排除故障了。从完全脱离公司网络的角度来看待网络服务的健康状况，可能非常宝贵。可以将其视为保持您的家用服务器 24/7 全天候运行的另一个理由。]

此时，我让 Akamai 的人员从他们的角度查看问题，经过几个小时来回的故障排除，他们宣布问题不是出在他们的设置上，而肯定是我们 DNS 服务器中的问题。但是，我在数据中心内做的所有测试都正确且立即返回。只有来自外部的测试超时并故障转移到数据中心 B，即使这些也是零星的。到这个时候，已经过了中午，即使是咖啡因静脉滴注液也开始失效了。我感到疲倦、生病，并且我的大脑没有全速运转。

大约在这个时候，我开始收到我那位尖酸刻薄的老板发来的电子邮件，内容是关于我“什么都没做”来解决问题，并且他希望每半小时更新一次事情的进展情况。我回复说，我可以每半小时向他更新一次，或者像我一直在做的那样解决问题。

那封电子邮件立即让我的手机响了。我的老板在电话里，要求我重启 DNS 服务器，试图“解决”问题。但是，除了失败的查询之外，DNS 服务器上没有任何错误的迹象，我不太愿意只是重启服务器，因为如果错误情况消失了，我们将无法进一步收集有关问题的信息。

Kyle 最终在旧版本的 BIND 中发现了一个奇怪的错误，其中计数器溢出导致了奇怪的事情发生。据说该错误在我们运行的版本中已得到修复，但这仍然是一个线索，所以我勉强决定重启主 DNS 服务器上的 DNS 服务。令我惊讶的是，一旦我们这样做，超时就停止发生了。突然之间，我们的 DNS 基础设施恢复到 100%，网站性能恢复到正常水平。

[Kyle：值得注意的是，此系统上的 DNS 进程已经运行并稳定了一年多。尽管从技术上讲，内部正常运行时间计数器溢出（例如旧版 Linux 内核上的 498 天正常运行时间溢出）可能会导致奇怪的行为，但这真的像是病急乱投医，当它似乎解决了问题时，我感到很惊讶。当然，这也引出了其他问题——我们是否每年都要重启我们的 DNS 服务？]

在网站性能恢复后，我的老板给我打了电话。直到今天，我也不知道这个电话是为了炫耀他的“解决方案”是正确的，还是为了责备我等待太久才重启 DNS 服务器。我解释说，虽然问题不再发生，但我们对问题的根本原因一无所知，而且问题并没有“解决”。随机重启东西是 Windows 管理员在出现问题时所做的事情。UNIX 系统管理员倾向于尝试触及问题的核心。在通话结束时，很明显他不在乎修复。他只是希望网站恢复到正常性能。我最终昏了过去，筋疲力尽，但仍然担心我们还没有看到这个问题的最后一次出现。

快进几周后。我感觉好多了，肺炎被打败了，我又回到了工作岗位。正如我的直觉所料，问题再次自发地重新出现。办公室周围的人们开始恐慌，责怪 DNS 基础设施，并且普遍手足无措。Kyle 和我立即再次开始进行故障排除，但就像上次一样，我们找不到 DNS 服务器有任何问题。不过这次，我更加警觉，我记得 DNS 服务器前面有一个负载均衡器。凭直觉，我问网络工程师他是否注意到负载均衡器有任何问题。他调查了一下，发现该设备的日志文件中存在异常。在与他进行了一些进一步的交谈后，他同意主负载均衡器存在问题，并决定故障转移到备份负载均衡器。一旦发生故障转移，我们看到的 DNS 问题再次消失了。一直以来，我们都在与一个不稳定的负载均衡器作斗争，而不是 DNS 服务器上的问题。

从这个问题中吸取了几个教训。最大的教训是，很容易忽视现代数据中心中发挥作用的所有技术。我的团队负责 UNIX 系统，因此我们自然而然地测试和排除服务器故障，但最初并没有想到网络可能是一个问题。始终确保查看您职责范围之外的领域，因为问题可能在那里。

[Kyle：这很有趣，因为我认识一些人在出现问题时默认会查看他们职责范围之外的领域。当我们注意到内部 DNS 请求始终有效，而外部请求（通过负载均衡器的请求）不稳定时，我们就应该已经得到提示了。但就像 Bill 说的那样，一旦我们重启了服务，问题就消失了，就没有什么故障排除可做了。]

另一个教训是我已经知道的，但那天被强调了。重启行为不正常的服务器是绝对的最后手段，因为您最终会首先丢失问题，并且永远不会弄清楚根本原因是什么。

总而言之，尽管这个问题确实给公司造成了当天的经济损失，因为网站性能不佳，但这是一次很好的学习经历。在设计新的基础设施或在面对新的和未知的问题时，我经常会想到这件事。它提醒我在进行故障排除时要彻底，要查看每一种可能性，不要想当然。