避免 CMS 灾难：如何防止网站停机

一个网站被认为是关闭实际上意味着什么？

这通常取决于你问谁。

对于一个网站被认为是关闭的，它可能意味着许多不同的事情：

• 该网站完全不可用。
• 该网站在线，但速度慢得无法使用。
• 该网站正在为某些用户或位置提供错误消息。
• 该网站适用于大多数访问者，但有些访问者根本无法登录到他们的 CMS，例如创建、编辑或发布内容。

无论原因或程度如何，网站停机的影响都可能很严重，从电子商务订单丢失和用户沮丧到客户信任度下降。

在我们避免 CMS 灾难系列的第三部分中，我们探讨了网站停机的经典根本原因以及持续监控和其他因素在避免这种情况中所起的作用。

一、持续监控的作用

我们监控网站的不同方面，因此我们可以判断构成我们完全托管的 WordPress VIP 平台的任何不同层何时出现问题。 这些层包括：

• 网络连接
• 负载均衡器
• 网络服务器
• 对象缓存 (Memcached)
• 数据库
• 弹性搜索
• 文件服务 (CDN)

我们尝试及早发现问题，以便我们可以预测可能影响网站稳定性的未来问题。 来自不同系统组件的交叉引用日志允许我们查看报告网站不稳定的时期。 因为可能是多种因素而不是单个问题导致停机，所以我们使用了许多工具来比较系统和应用程序之间的数据。

在大多数情况下，网站不稳定是由于应用程序代码，即自定义或第三方 WordPress 主题和插件代码造成的。 以下是我们在调查不稳定站点时需要注意的一些事项，以及如何缓解这些事项。

缓存不够

确保网站高性能和稳定的最重要的事情是确保任何可以缓存的完整页面都被缓存。 每次请求时都需要在服务器上构建未缓存的页面，这是一个较慢的过程，更容易出错。

WordPress VIP 答案：

WordPress VIP 平台通过边缘缓存服务器的全球网络提供强大的页面缓存，每个边缘缓存服务器都用于存储和提供最接近最终用户的内容。 边缘缓存服务器的响应时间几乎总是比绕过页面缓存并命中源服务器的任何东西快一个数量级。

缓存挑战

因为他们需要个性化、完全交互的体验，一些网站，尤其是电子商务网站，根本无法在页面缓存级别进行缓存。

通常可以找到一种折衷方案，即静态页面由边缘缓存提供服务，并通过 JavaScript 添加动态特征（例如，登录状态、购物车）。 然后可以使用来自 JavaScript 的异步请求与 WordPress REST API 端点进行通信，该端点的设计开销比整个页面加载低得多。

或者，这就是对象缓存发挥作用的地方。 页面可以保持动态，但页面的一部分和其中使用的任何数据都可以在对象缓存中存储和检索，以避免需要查询数据库。

WordPress VIP 答案：

每个 WordPress VIP 应用程序环境都有自己专用的 Memcached 集群，它将对象缓存数据存储在内存中，以便快速高效地检索。

未经测试的代码部署

这是网站停机的另一个常见罪魁祸首，而且很容易根据纯粹的因果关系进行诊断。

如果您的网站刚刚部署了未经测试的代码，从而导致了直接的网站问题，则可能是您的原因。 如果可以的话，尽快将可疑代码恢复到以前的版本。

避免这种情况的最好办法是什么？ 在发布到生产环境之前，在单独的开发或暂存环境中彻底测试每一段代码。

WordPress VIP 答案：

因为我们所有的站点部署都是通过 GitHub 进行的，所以 WordPress VIP 客户可以轻松地自行还原代码，而不会丢失任何新的代码更改，这些更改仍安全地存储在 GitHub 修订历史记录中。 或者，在紧急情况下，我们可以独立于 GitHub 代表客户将网站回滚到之前的部署。

关于环境，托管在我们完全托管的服务上的所有应用程序都可以具有单独的开发或登台环境。 从生产中同步数据很容易，让您可以针对与生产网站上相同数量和相同类型的数据测试代码。

PHP 错误

WordPress 在服务器上使用 PHP 代码。 PHP 错误可能是“致命的”，这意味着一旦发生错误，网页、脚本或命令将停止运行。 这些几乎总是以可见错误的形式出现在某个地方，并将记录在 PHP 日志中。

注意：PHP 7 中的一些 PHP 警告在 PHP 8 中会变成致命错误，因此认真对待这些错误很重要。

WordPress VIP 答案（加上有用的建议）：

我们的平台会自动记录所有 PHP 错误，让 WordPress VIP 客户在他们的仪表板中和我们的工程师都可以使用它们。

专业提示：解决并修复所有 PHP 错误——即使网站看起来运行良好。 通常，我们会在看起来稳定的站点上看到充满 PHP 错误的日志，甚至是致命错误。 但是，这并不一定意味着该站点运行正常。 通过解决小错误和警告来保持 PHP 日志清晰，可以在调试过程中更容易地发现更严重的错误。

缓慢的 MySQL 数据库查询

每个 WordPress 网站都使用数据库来存储网站内容和配置数据。 数据库查询获取网页的内容数据，但有时这些查询的编写效率很低。 它们可能适用于只有几百页的网站，但在处理大量数据时会停止（我们平台上的一些网站存储了数百万条记录）。

缓慢的查询会占用数据库资源，可能会影响站点的稳定性——不仅仅是页面、脚本或运行 SQL 的命令，而是整个应用程序。 站点经常遇到困难，因为单个或多个数据库查询速度很慢，例如，任何执行时间超过 0.75 秒的查询。

WordPress VIP 答案：

WordPress VIP 通过为每个应用程序提供一个专用的数据库集群来帮助缓解数据库瓶颈，该集群具有一个主数据库，所有数据库写入查询都在其中发生，以及一个或多个只读副本数据库。 这增加了可以同时进行的数据库查询的数量，从而在站点处于压力之下时分散了资源负载。 也就是说，缓慢的数据库查询并不总是通过添加额外的数据库资源来解决。 这就是为什么我们建议客户使用 Query Monitor 和 New Relic（由我们的平台提供）来监控慢速数据库查询。 这些突出显示查询源自数据库的位置，因此您的开发团队可以重构它们以优化性能。

最后，我们的应用支持和高级工程师还可以帮助您的团队查找和分析这些查询，并提出改进它们以提高速度和效率的方法。

数据库写入过多

有时，诸如自定义日志记录或跟踪代码之类的功能会在每次请求时更新数据库。 这可能导致不稳定，原因有两个：

• Foregoing database replicas ：所有写查询都指向主库； 在同一页面请求中对同一表（或多个表）的后续数据库查询也将被定向到那里。 由于不利用数据库副本，这限制了站点的可扩展性。
• 绕过页面缓存：为了在每个页面请求上发生数据库写入，必须绕过页面缓存。 但这样做意味着第一道（也是最好的）防线已被攻破。

WordPress VIP 答案：

在这些情况下，我们建议重构该功能。 例如，内容分析通常最好委托给在页面中使用 JavaScript 片段的外部服务，而不是服务器端代码，后者不能很好地用于缓存，并可能导致过多的数据库写入。

其他已知的停机原因以及如何避免它们

插件

WordPress 生态系统中有数千个流行的、有用的第三方插件，它们提供了出色的特性和功能。 但是，有些人在扩展方面面临挑战，当添加到具有大量内容和流量的网站时，可能会导致停机问题。

WordPress VIP 答案：

作为优秀的生态系统管家，我们会定期向供应商提供建议，以使他们的插件在高流量环境中表现更好。 我们还可以建议已在我们的平台上大规模尝试和测试的替代插件。

自定义日志记录

自定义日志记录是一种强大的调试工具，通常是追踪似乎仅在生产站点上发生的错误或问题的唯一可行方法。 然而，在许多情况下，我们已经看到在高流量站点上用 PHP 构建的自定义日志记录会减慢速度，或者由于过多的数据库写入而使站点处于停机危险之中。

WordPress VIP 答案：

对于客户，我们在 WordPress VIP 应用程序仪表板的运行状况面板中提供对标准 PHP 日志的访问。 他们可以在那里记录自定义错误（也可以记录到 New Relic），这不会对数据库产生负面影响。

远程 API 调用

一些网站利用对其他应用程序或服务的服务器端 REST API 调用。 这些在正常情况下非常快，但有时底层应用程序代码会导致响应缓慢、超时或抛出错误。

WordPress VIP 答案：

为了尽量减少这些问题，我们建议“防御性编码”。 这取决于远程调用的目的，但通常当远程请求失败时，可能会退回到先前请求的缓存响应——或者至少“优雅地处理错误”，以便页面的其余部分可以仍然加载。 我们提供了许多帮助函数来处理这些场景。 保持低超时还意味着如果远程 API 没有响应，PHP 资源可以更快地释放。

在我们的避免 CMS 灾难系列中了解更多信息

当您的业务上线时，您无法负担将新业务发送到其他地方并通过让您的内容管理系统 (CMS) 提供糟糕的数字体验来玷污您的品牌。 在如何提高网站性能中，我们诊断出五个常见的减速罪魁祸首，以及如何使用敏捷的 CMS 加速事情。

高流量的日子应该值得庆祝，而不是让工程师们集体退后一步，努力保持网站和应用程序正常运行并嗡嗡作响以处理负载——以及你的声誉完好无损。 在为高流量扩展 WordPress 中，我们探讨了四种使 WordPress 网站能够处理这些流量潮汐的方法。