生产环境网站的13个灾难及其解决方案

引言

2005年，当我们首次上线Pageflakes 时，我们大多数人都没有运行互联网上大规模消费者高流量网络应用程序的经验。我们经历了网络应用程序在成长过程中可能面临的各种困难。软件、硬件和网络频繁出现问题是我们日常生活的一部分。在过去的2年里，我们克服了许多障碍，并成为全球顶级的Web 2.0应用程序之一。从一个拥有数千用户的网站，多年来我们已发展成为一个拥有数百万用户的网站。我们学会了如何构建一个能够承受每天超过200万次点击和单日高达700万次点击的突然高峰的产品。我们发现了ASP.NET 2.0的内部秘密，解决了许多可扩展性和可维护性问题。我们还在选择合适的硬件和互联网基础设施方面积累了足够的经验，这些对于高流量网络应用程序的成功或失败至关重要。本文中，您将了解到任何生产网站随时可能发生的13个灾难。这些真实的故事将帮助您做好充分准备，避免重蹈我们的覆辙。提前为这些灾难做好准备将为您节省大量时间和金钱，并与您的用户建立信誉。

13个灾难

多年来我们经历了许多灾难。其中一些包括：

1. 硬盘多次崩溃、烧毁、损坏
2. 控制器故障并损坏同一控制器中的所有磁盘
3. RAID故障
4. CPU过热烧毁
5. 防火墙宕机
6. 安装补丁后远程桌面停止工作
7. 远程桌面最大连接数超出。无法再登录服务器
8. 我们将生产数据库通过网络从一台服务器移动到另一台服务器时，数据库损坏
9. 一名开发人员在日常工作中意外删除了生产数据库
10. 托管服务支持人员格式化了我们正在运行的生产服务器，而不是我们要求格式化的损坏服务器
11. Windows损坏，直到我们重新安装才恢复正常
12. DNS宕机
13. 世界不同地区的互联网骨干网宕机

这些是专用托管中通常会发生的一些问题。让我们详细阐述其中一些问题并制定一个灾难计划

硬盘崩溃

我们经常遇到廉价托管服务提供商的硬盘崩溃问题。他们使用不可靠的廉价SATA硬盘。到目前为止，我们发现西部数据SATA硬盘最可靠。如果您有足够的预算，请选择SCSI硬盘。惠普有多种SCSI硬盘可供选择。最好始终在网络和数据库服务器上选择SCSI硬盘。它们虽然昂贵，但能为您省去频繁的灾难。

上图显示了良好硬盘的基准测试结果。您需要关注磁盘速度而不是CPU速度。通常处理器和总线是标准的，它们的性能变化不大。磁盘IO通常是生产系统的主要瓶颈。对于数据库服务器，您唯一应该关注的是磁盘速度。除非您有非常糟糕的查询，否则CPU永远不会太高。磁盘IO将始终是数据库服务器的瓶颈。因此，对于数据库，您需要选择最快的磁盘和控制器解决方案。

控制器故障

当服务器没有经过适当测试就匆忙交付给您时，就会发生这种情况。在接受任何服务器之前，请务必获得书面保证，证明它们已通过各种详尽的硬件测试。戴尔服务器的BIOS包含用于测试控制器、磁盘、CPU等的测试套件。您还可以使用www.Passmark.com的BurnInTest来测试服务器在高磁盘和CPU负载下的能力。只需运行基准测试4到8小时，看看您的服务器表现如何。密切关注CPU和硬盘的温度计，确保它们不会过热。

RAID故障

RAID通过使用专用硬件或软件将物理硬盘组合成一个逻辑单元。硬件解决方案通常旨在向所连接的系统呈现为一个单一的硬盘，并且操作系统不了解其技术工作原理。软件解决方案通常在操作系统中实现，同样也会将RAID驱动器呈现为应用程序的单一驱动器。

在我们的案例中，RAID发生故障，导致RAID控制器中的磁盘数据损坏。我们使用了Windows 2003内置的RAID控制器。我们吸取教训，不再依赖软件RAID，并额外支付了硬件RAID的费用。请确保您购买的服务器配有硬件RAID控制器。

选择合适的磁盘后，下一步是选择正确的RAID配置。RAID意味着多个硬盘协同工作，充当一个逻辑驱动器。例如，RAID 1采用两个相同的物理磁盘，并将其作为单个磁盘呈现给操作系统。因此，每次磁盘写入都会同时写入这两个磁盘。如果一个磁盘发生故障，另一个磁盘可以接管并继续为逻辑磁盘提供服务。如今的服务器支持“热插拔”磁盘，您可以在服务器运行时将磁盘从服务器中取出。控制器会立即将所有请求转发到另一个磁盘。这样您就可以取出磁盘，进行维修或更换，然后再放回去。一旦新磁盘放入控制器，控制器就会同步两个磁盘。RAID 1适用于Web服务器。以下是RAID 1的优点和缺点

优点

• 镜像提供100%的数据复制
• 如果阵列控制器能够从镜像对的两个设备同时执行读取操作，则读取性能比单个磁盘更快。您应该确保您的RAID控制器具有此功能。否则，磁盘读取速度将比单个磁盘慢
• 在重建期间提供任何冗余阵列类型中最佳的性能。修复后一旦您重新插入替换磁盘，它会迅速与操作中的磁盘同步
• 无需数据重建。如果磁盘出现故障，只需按块复制到新磁盘即可
• 磁盘故障时不会影响性能；存储对外界来说似乎正常运行

缺点

• Raid 1写入两次信息，因此与写入单个磁盘相比，会产生轻微的性能损失
• 在混合读写环境中的I/O性能基本上不比单个磁盘存储系统的性能好
• 需要两个磁盘才能实现100%冗余；成本翻倍。然而，现在磁盘很便宜

对于数据库服务器，RAID 5是一个更好的选择，因为它比RAID 1更快。RAID 5比RAID 1更昂贵，因为它至少需要3个驱动器。但是，一个驱动器出现故障不会影响数据的可用性。在发生故障时，控制器会从其他幸存驱动器中重新生成故障驱动器丢失的数据。
通过在阵列成员磁盘之间分布奇偶校验，RAID 5级减少（但并未消除）了写入瓶颈。结果是性能不对称，读取性能显著优于写入性能。为了减少或消除这种固有的不对称性，RAID 5级通常会通过缓存和并行多处理器等技术进行增强。

优点

• 最适合重读应用程序，如数据库服务器，其中`SELECT`操作远高于`INSERT`/`UPDATE`/`DELETE`
• 可用空间量是虚拟驱动器中物理驱动器数量减去1

缺点

• 单个磁盘故障将阵列降级为RAID 0
• 重建时性能比RAID 1慢
• 写入性能慢于读取（写入惩罚）

CPU过热烧毁

我们只发生过一次服务器CPU因过热而烧毁的事件。我们对此负有部分责任，因为我们有一个糟糕的查询，导致SQL Server的CPU利用率达到100%。结果，那台可怜的服务器以100%的CPU利用率运行了大约4小时，然后就挂了。

服务器在高CPU使用率下绝不应该烧毁。通常，服务器会配备监控系统，当CPU即将烧毁时，服务器会自动关闭。这意味着有缺陷的服务器的监控系统没有正常工作。因此，您应该运行工具将服务器推至100% CPU长达8小时，并确保它们能够承受。在过热的情况下，监控系统应该关闭服务器并保护硬件。然而，如果服务器具有良好的散热系统，那么CPU在8小时内不会过热。

每当我们迁移到新的托管服务提供商时，我们都会运行压力测试工具，模拟所有服务器在8到12小时内达到100%的CPU负载。上图显示了我们7台服务器在100% CPU下运行数小时而没有任何问题。在我们的案例中，没有一台服务器过热并自行关闭，这说明我们也有一个良好的散热系统。

防火墙宕机

我们的托管服务提供商的防火墙曾经发生故障，导致我们的网络服务器暴露在公共互联网上，没有任何保护。我们很快发现它们被感染了，并开始自动关机。因此，我们不得不格式化它们，打补丁并开启Windows防火墙。如今，作为最佳实践，我们始终在连接到硬件防火墙的外部网卡上开启Windows防火墙。事实上，我们购买了冗余防火墙以确保安全。

您应该关闭外部网卡上的文件共享。除非您有冗余防火墙，否则您也应该开启Windows防火墙。有些人可能会争辩说这会影响性能。我们已经看到Windows防火墙对性能几乎没有影响。

您还应该禁用NetBIOS协议，因为外部网络应该永远不需要它。除了开放端口80和端口3389（用于远程桌面）之外，您的服务器应该对公共网络完全不可见。

安装补丁后远程桌面停止工作

这种情况发生了好几次，即在安装Windows Update的最新补丁后，远程桌面停止工作。有时重启服务器可以解决问题，有时我们不得不卸载补丁。在这种情况下，您进入服务器的唯一方法是

1. 使用KVM over IP，或
2. 呼叫支持技术员

KVM over IP（通过IP的键盘、视频、鼠标）是一种特殊的硬件，它连接到服务器并将其屏幕输出传输给您。它还接收您的键盘和鼠标输入，并在服务器上模拟。KVM的工作方式就像显示器、键盘和鼠标直接连接到服务器一样。您可以使用常规远程桌面连接到KVM，并在服务器上工作，就像您身临其境一样。KVM的优点

• 访问所有服务器平台和所有服务器类型
• “直接连接实时”解决方案，由于信号转换不会导致鼠标延迟。软件必须转换信号，这会导致延迟
• 充分利用图形用户界面（GUI）
• 即使网络中断，也能完全访问BIOS级别
• 能够访问命令行并远程重建服务器
• 服务器启动错误的可见性以及采取行动的能力，例如“非系统盘错误，请更换系统盘并按任意键继续”或“电源故障请按F1继续”
• 完全杜绝“黑客攻击”——访问系统需要物理连接

如果远程桌面无法工作，或者您的防火墙已关闭，或者服务器的外部网卡无法工作，您可以使用KVM轻松进入服务器。请确保您的托管服务提供商支持KVM。

远程桌面最大连接数超出。无法再登录服务器

当用户通过关闭远程桌面客户端未能正确注销远程桌面时，就会发生这种情况。断开的会话超出最大活动会话数，从而阻止新的会话。因此，没有人可以再进入服务器。如果发生这种情况，请转到运行并发出“`mstsc /console`”命令。这将启动您每天使用的相同的旧远程桌面客户端。但是当您连接到远程桌面时，它将以控制台模式连接您。控制台模式意味着连接到服务器，就像您正坐在服务器前并使用服务器的键盘和鼠标一样。一次只能有一个人以控制台模式连接。一旦您进入控制台模式，它会显示常规的Windows GUI。没有什么不同。您可以启动“终端服务管理器”并查看断开的会话并将其踢出。

我们将生产数据库通过网络从一台服务器移动到另一台服务器时，数据库损坏

通过网络复制大文件是不安全的。任何时候都可能发生数据损坏，尤其是在互联网上。因此，始终使用WinRAR的正常压缩模式来压缩大文件。然后通过网络复制RAR文件。RAR文件在解压缩时会维护CRC并检查原始文件的准确性。如果WinRAR能够正确解压缩文件，您可以确定原始文件没有损坏。关于WinRAR压缩模式的一点注意事项：不要使用最佳压缩模式。始终使用正常压缩模式。我们曾发现大文件在最佳压缩模式下被损坏。

一名开发人员在日常工作中意外删除了生产数据库

在早期阶段，我们没有专业的系统管理员来管理我们的服务器。我们开发人员自己负责服务器。这并不理想。当一名开发人员误以为是备份数据库而意外删除了生产数据库时，灾难就发生了。当时轮到他负责清理备份服务器上的空间。于是，他使用远程桌面登录到备份服务器，并使用“sa”用户名和密码登录到SQL Server。他需要释放一些空间。所以，他删除了大型的“Pageflakes”数据库。SQL Server确实警告他该数据库正在使用中。但他从不阅读任何带有“确定”按钮的警报，于是他点击了“确定”按钮。我们完了。

以下是我们做错的地方，您应该确保永远不要这样做

系统管理员对服务器太过随意了。在使用远程桌面工作时缺乏严肃性。对他来说，这成了一项例行公事、单调乏味、心不在焉的工作。这是系统管理员面临的一个真正问题。第一个月，你会看到他非常认真对待自己的角色。每次他登录生产或维护服务器的远程桌面时，额头上都会皱起明显的眉头。但日复一日，注意力开始下滑，他开始在生产服务器上工作，就好像在自己的笔记本电脑上工作一样。在某个时候，需要有人让他意识到他的行为有多么严重。他应该在坐在远程桌面前洗手，然后祈祷：“主啊！我要在远程桌面工作了。赐予我平静和专注，并保护我免受引诱我给生产服务器造成巨大损害的魔鬼。”

所有数据库都使用相同的“sa”密码。如果密码不同，至少在输入密码时，系统管理员可以意识到他正在连接到哪里。虽然他确实连接到维护服务器的远程桌面，但从SQL Server Management Studio，他像上次一样连接到主数据库服务器。SQL Server Management Studio记住了上次的机器名和用户名。所以，他所做的就是输入密码并回车，然后删除了数据库。现在我们已经吸取了教训，我们将服务器名称放在密码中。所以，在输入密码时，我们会自觉地知道我们要连接到哪个服务器。

不要像在本地机器上那样忽略远程桌面上的确认对话框。现在，我们都认为自己是所有方面的超级专家，从不认真阅读确认对话框。我自己都不记得上次认真阅读确认对话框是什么时候了。这种态度在服务器上工作时肯定必须改变。当系统管理员尝试删除数据库时，有一个确认提示数据库存在活动连接。SQL Server尽力通知他这是一个正在使用的数据库，请不要删除它。但他像每天在笔记本电脑上做一百次一样，在没有阅读确认对话框的情况下点击了“确定”。

不要在所有服务器上设置相同的管理员密码。这虽然方便了文件在服务器之间复制，但请不要这样做。否则，您会像我们以前经常做的那样，意外删除另一个服务器上的文件。

不要使用管理员用户帐户进行日常工作。我们开始使用 Power User 帐户进行日常操作，该帐户仅对几个文件夹具有有限的访问权限。在远程桌面上使用管理员帐户意味着您为所有可能的事故敞开了大门。如果您使用受限帐户，则发生此类事故的可能性会很小。

在生产服务器上进行重要操作（例如清理空间、运行脚本、恢复数据库等）时，请务必让某人陪同。确保另一个人没有在您旁边的椅子上打盹。

托管服务支持人员格式化了我们正在运行的生产服务器

我们告诉支持技术员格式化服务器A，他却格式化了服务器B。不幸的是，服务器B是我们的生产数据库服务器，整个网站都运行在这台服务器上。

幸运的是，我们有日志传送，并且有一个备用数据库服务器。我们立即将其上线，更改了所有 *web.config* 中的连接字符串，并在10分钟内恢复了运行。由于最后一次从生产数据库到备用数据库的日志传送没有发生，我们损失了大约10分钟的数据。

Windows损坏，直到我们重新安装才恢复正常

Web服务器的Windows 2003 64位多次损坏。有趣的是，数据库服务器从未损坏。损坏主要发生在没有防火墙设备而只使用Windows防火墙的服务器上。因此，这一定与外部攻击有关。损坏也发生在我们没有定期安装补丁的时候。您看到微软时不时发布的那些安全补丁非常重要。如果您不及时安装它们，您的操作系统肯定会损坏。现在，没有SP2我们无法运行Windows 2003 64位。

当操作系统损坏时，它会表现异常。您有时会发现它不再接受入站连接。有时您会看到“套接字上的操作无法执行，因为系统缺乏足够的缓冲区空间或因为队列已满”的错误。有时您会发现登录和注销需要很长时间。有时远程桌面会随机停止工作。有时您会看到`Explorer.exe`和IIS进程`w3wp.exe`频繁崩溃。所有这些都是操作系统损坏和需要安装补丁的好迹象。

我们发现，一旦操作系统损坏，就无法安装最新的补丁并使其恢复正常。至少对我们来说，很少有安装补丁能解决问题的情况。80% 的时间我们不得不格式化并重新安装 Windows，然后立即安装最新的 Service Pack 和补丁。这总是能解决此类操作系统级别的问题。

补丁管理是一个您不会优先考虑的事情，除非您开始频繁地遭受这些问题。首先，您永远不能在生产服务器上开启自动更新和安装。如果您这样做，Windows 将下载补丁，安装它们，然后重新启动自身。这意味着您的网站将意外宕机。因此，您将始终需要手动安装补丁，并将服务器从负载均衡器中取出，重新启动它，然后再将其放回负载均衡器。

DNS宕机

DNS提供商有时没有可靠的DNS服务器。我们从GoDaddy.com获得托管和DNS服务。他们的托管服务还行，但DNS托管服务很糟糕。到目前为止，它已经宕机7次了。当DNS宕机时，您的网站也会对所有新用户和大多数老用户宕机。当访问者输入www.pageflakes.com时，请求首先会发送到DNS服务器以获取域名的IP地址。因此，当DNS服务器宕机时，IP地址不可用，网站也无法访问。

有一些专业的DNS托管公司只提供DNS托管。例如，UltraDNS (www.ultradns.com)、DNSPark (www.dnspark.com)、Rackspace (www.rackspace.com)。您应该选择商业DNS托管，而不是依赖域名注册公司为您提供完整套餐。然而，UltraDNS在DNSStuff.com的测试中结果为负面。它报告说他们的DNS托管存在单点故障，这意味着主DNS和辅助DNS实际上是同一台服务器。如果这是真的，那么风险非常大。因此，当您选择DNS托管服务时，请使用DNSStuff.com测试他们的DNS服务器，并确保在所有方面都获得正面报告。需要确保的一些事项包括

• 解析主DNS和辅助DNS服务器的IP。确保您得到不同的IP
• 确保这些不同的IP实际上是不同的物理计算机。我相信唯一的方法是与服务提供商核实
• 确保DNS解析时间少于300毫秒。您可以使用DNSStuff.com等外部工具进行测试

世界不同地区的互联网骨干网宕机

互联网骨干网连接着不同国家的互联网。它们是横跨海洋连接各大洲和国家的“信息高速公路”。例如，UUNet就是一条覆盖美国并连接其他国家的互联网骨干网。

还有一些其他的互联网骨干网公司，如英国电信、AT&T、Sprint Nextel、法国电信、Reliance Communications、VSNL、BSNL、Teleglobe（现为VSNL International的一个部门）、Flag Telecom（现为Reliance Communications的一个部门）、TeliaSonera、Qwest、Level 3 Communications、AOL和SAVVIS。

世界上所有的托管公司都直接或间接连接到某个互联网骨干网。一些托管服务提供商与多个互联网骨干网有连接。

早期，我们使用了一家廉价的托管服务提供商，它只连接了一个互联网骨干网。有一天，骨干网的一部分连接美国和伦敦的线路中断了。伦敦是通往整个欧洲的入口点。因此，整个欧洲和亚洲部分地区无法访问我们在美国的服务器。这真是罕见的坏运气。我们的托管服务提供商恰好位于该骨干网的故障部分。结果，所有由该托管服务提供商托管的网站对欧洲和亚洲部分地区来说都有一天无法访问。

因此，当您选择托管服务提供商时，请确保他们连接到多个骨干网，不与电信公司共享带宽，也不托管在线游戏服务器。

Tracert可以揭示有关托管服务提供商互联网骨干网的重要信息。下图显示了托管服务提供商和互联网骨干网之间非常好的连接性。

该 tracert 是从孟加拉国连接到美国华盛顿特区一台服务器的。此 tracert 的一些良好特点是

• 孟加拉国和美国分属世界的两个区域。尽管如此，只有9跳，这非常好。这意味着托管服务提供商选择了非常好的互联网骨干网，并具有智能路由能力来决定不同国家之间最佳的跳数。
• 从pccwbtn.net到防火墙只有三跳。而且这些跳之间的延迟为1毫秒或更短。这确保了它们与互联网骨干网有非常好的连接性。
• 只有一个骨干网公司，即pccwbtn.net。这意味着他们与骨干网直接连接，没有中间连接。

下图显示了一个具有糟糕互联网连接的糟糕托管公司的示例。

此 tracert 的一些不良特征是

• 总共有16跳，而良好情况是9跳。延迟也达到了305毫秒，而良好情况是266毫秒。因此，该托管服务提供商的网络连接很差。
• 有两个提供商：pccwbtn.net 和 cogentco.com。这意味着托管服务提供商没有连接到 pccwbtn.net 这样的顶级提供商。他们通过另一个提供商来节省成本。因此，他们引入了额外的延迟和故障点。
• Cogentco.com曾多次给我们带来麻烦。我们使用了连接到cogentco.com的两家托管服务提供商，它们都存在延迟和间歇性连接问题。
• 从骨干网到Web服务器有四跳。这意味着存在多个网关或防火墙。两者都是网络设计不佳的标志。
• cogentco.com本身存在过多的跳数，这表明骨干网连接状况不佳。这意味着流量在多个网络之间传输才能到达目标web服务器。
• 流量经过5个不同的网络段 63.218.x.x、130.117.x.x、154.54.x.x、38.20.x.x 才到达最终目标网络 XX.41.191.x。这表明骨干网内部路由能力差。

选择正确的托管服务提供商

我们与几家糟糕的托管公司打交道的经验，为我们选择了合适的托管公司提供了宝贵的教训。我们最初选择了非常便宜的托管服务提供商，并逐渐转向美国最昂贵的托管服务提供商之一——Rackspace。Rackspace在成本和服务质量方面令人难以置信。他们的技术人员训练有素，他们的托管计划提供现场系统管理员和DBA来ดูแล您的服务器和数据库。他们可以解决我们经常需要自己解决的SQL Server 2005问题以及IIS相关问题。因此，当您选择托管服务提供商时，请确保他们拥有Windows 2003和IIS 6.0专家以及SQL Server 2005专家。在运行生产系统时，总有可能遇到超出您能力范围的问题。拥有现场技术娴熟的技术人员是您在这种灾难中生存的唯一途径。

我根据我的经验，建立了一个选择合适托管服务提供商的检查清单

• 测试您将获得服务器的同一数据中心内一台服务器的ping时间。在美国境内ping时间小于40毫秒，从伦敦、新加坡、巴西和德国等其他几个国家平均约为250毫秒。
• 确保多骨干网连接和智能路由能力，能够从不同国家选择最佳跳数。从不同国家进行 tracert 测试，确保服务器在全球任何地方都能在10到14跳内访问。如果您的托管服务提供商在美国，那么从美国任何地方，服务器都应该在5到8跳内访问。
• 确保从互联网骨干网到您的服务器只有3跳。您可以通过检查 tracert 的最后3个条目来验证这一点。最后一个条目应该是您的服务器 IP，前面两个条目应该是互联网骨干网提供商。这确保了您的服务器和互联网骨干网之间只有一个网关。如果跳数更多，则意味着他们网络复杂，您将在托管服务提供商的内部网络中浪费延迟。
• 24x7电话支持专业技术人员。在周末晚上打电话给他们，给他们一个复杂的技术问题。如果工作人员说他/她只是替补，直到真正的专家周一回到办公室，请立即淘汰他们。一个好的托管服务提供商会在周六晚上凌晨3点提供专家技术人员。您主要会在周六和周日深夜需要技术人员进行维护和升级。
• 在线聊天支持。当您出差在外无法打电话时，这非常有帮助。
• 您可以根据需要定制您的专用服务器。他们不会将您限制在预定义的套餐中。这表明他们拥有内部技术人员，可以构建和定制服务器。
• 他们必须能够为您提供各种软件，包括SQL Server企业版、Microsoft Exchange 2007、Windows 2003 R2、Windows Longhorn Server等。如果他们不能，则说明他们没有好的软件供应商。不要把您的未来押在他们身上。
• 他们必须能够为您提供15K RPM SCSI硬盘和SAN（存储区域网络）。如果不能，请不要考虑他们。如果他们不具备这些能力，您将无法与该提供商一起发展您的业务。
• 在与托管服务提供商建立整个数据中心之前，请务必从他们那里获取一台服务器。在订购服务器时，订购您未来两年内需要的设备。查看他们能以多快的速度和多可靠的方式将这样的服务器交付给您。这将是一项昂贵的实验。但如果您在没有进行此实验的情况下选择了糟糕的托管服务提供商，那么您为摆脱他们而损失的时间和金钱将远超实验成本。

确保其服务级别协议（SLA）保障以下事项

• 99.99%的网络正常运行时间。如果按小时和出现次数单位计算中断，则月租金会有折扣。
• 有缺陷的硬盘、网卡、主板设备、控制器和其他输入设备的硬件更换延迟最多2小时
• 如果您想退出他们的服务并转向其他地方，他们将给予充分合作。确保他们不会让您终身受困。
• 如果取消服务，您将可以删除存储在任何存储和备份存储中的所有数据
• 支持工单响应延迟最多2小时

这并非详尽无遗的清单。还有许多其他情况可能导致托管服务提供商出现问题。但这些是一些您必须努力预防的常见致命问题。

网站监控工具

有许多在线网站监控工具，它们从不同位置ping您的服务器，确保服务器和网络运行良好。这些监控解决方案在全球各地和美国许多不同的城市都有服务器。它们会扫描您的网站或进行一些事务处理，以确保网站全面运行且关键功能正常。

我们使用了www.websitepulse.com，它完美地满足了我们的需求。我们设置了一个监控系统，它每5分钟完成一次Pageflakes的欢迎向导，并模拟一个全新用户访问。它使用正确的参数调用Web服务，并确保返回的内容有效。通过这种方式，我们可以确保我们的网站运行良好。我们还在监控系统中放置了一个非常昂贵的Web服务调用，以确保网站性能良好。这也可以为我们提供网站是否变慢的指示。

这张图显示了网站一整天的响应时间。您可以看到大约下午2点网站宕机了。它超时了。此外，从上午11点到下午3点，响应时间很高，这意味着网站受到了很大的访问量。所有这些都为您提供了宝贵的指示

• 下午2点可能正在运行某个作业，导致响应时间非常高。可能的嫌疑：数据库完整备份。
• 上午11:30可能正在运行某个作业，导致高响应时间，或者可能存在流量激增，导致全站速度变慢。

详细视图显示了每次测试的总响应时间、下载字节数和检查的链接数。此监视器配置为访问主页，查找其中所有链接并访问这些链接。因此，它基本上在每次测试中都会对网站的大部分页面进行一次访问，并确保最重要的页面正常运行。

测试单个页面性能对于找出资源消耗大的页面很重要。图8-22显示了一些性能缓慢的页面。“First”列显示了建立连接到获取第一个响应字节之间的延迟。这意味着您看到的时间是服务器执行ASP.NET页面的时间。因此，当您看到3.38秒时，意味着服务器花了3.38秒在服务器上执行该页面，这是非常糟糕的性能。每次访问此页面都会使服务器CPU和磁盘IO飙升。因此，此页面需要立即改进。

使用此类监控工具，您不仅可以24x7全天候监控您的网站，还可以了解您的网站在不同时间的性能，并查看哪些页面性能不佳。

结论

开发一个大众消费网站乐趣无穷。当它大规模上线，并且您开始遇到从未梦想过的生产挑战时，乐趣更是倍增。与我们的开发环境相比，生产系统是一个完全不同的世界。因此，为这些生产挑战做好准备有助于公司预防常见灾难，并长期保持用户信心。