网站更新时可以保持正常访问吗？

许多更新可以在现有网站继续提供服务时发布。内容和设计调整、新页面，以及准备充分的软件版本，通常都可以这样处理。

但这并不意味着所有更改都能保证不中断。涉及实时订单、用户账户、不兼容的软件版本、基础设施或外部服务的更新，可能需要安排明确的维护时段。关键不只是网站是否在线，还要明确哪些功能会继续可用、如何检查变更，以及出现预期之外的问题时怎么办。

哪些网站更新可以在运行期间进行？

文字修订、图片替换、新文章和新页面，以及单独的视觉调整，通常可以先准备好再发布，而不必让整个网站下线。如果网站和发布流程支持，小型软件变更也可能以这种方式发布。

仅凭更新类型无法判断。普通的内容编辑在某个网站上可能影响菜单、搜索、缓存页面或生成文件，在另一个网站上却只改变一个页面。即使是熟悉的工作，也要结合承载它的系统来检查。

“在线”也需要有实际含义。首页能够正常打开，并不能证明咨询、付款、登录、搜索或管理操作仍然可用。对业务重要的网站功能需要分别检查。

测试网站能保护什么？

测试网站是一个独立环境，可以在更改面向访客之前准备并检查它。这样有助于避免未完成的版式、未写完的文字和明显的功能故障在工作期间出现在公开网站上。

测试环境能降低不确定性，但不能消除不确定性。测试副本的数据、流量、配置、凭据、连接的服务或服务器资源可能不同。测试成功是有用的依据，但不能保证生产环境的表现完全相同。

发布计划仍需明确：变更进入公开网站后要检查哪些内容。

如何在不出现空白页面的情况下用新版本替换旧版本？

一种方法是单独准备新版本，同时让现有版本继续服务访客。只有在新版本通过检查后，才切换流量。如果出现严重问题，也可以将流量切回旧版本。

这种方法通常称为蓝绿部署。AWS 将其描述为在运行不同应用版本的两个环境之间切换流量，目标是接近零停机，并能更快返回先前的环境。

蓝绿部署并非唯一的更新方式。有些系统会原子地替换文件、逐台更新服务器、只把一部分流量导向新版本，或等支持工作完成后再启用已完成的功能。适合的方法取决于网站、托管环境、数据，以及变更失败会带来的后果。

为什么数据库变更有所不同？

数据库可能保存当前订单、账户、预约、表单提交、库存、会员信息或已发布内容。发布过程中，网站的新旧版本可能都需要继续使用这些数据。

如果数据库结构变更后只有一个软件版本能够识别，回到旧版本可能就不再简单。耗时较长的变更也可能与网站的正常活动争用资源。因此，有些发布会把数据库准备与应用更新分开，暂时保持新旧结构兼容，或分批、受控地迁移数据。

GitLab 公开的数据库迁移指南展示了这类规划可能需要多细致。指南区分常规、部署后和后台迁移，并要求考虑时机、可逆性、事务和锁竞争。这些具体做法并不适合每个网站，但通用原则很有参考价值：实时数据变更需要单独的发布与恢复计划。

备份等同于回滚吗？

不等同。备份是保存下来、可以恢复的数据或文件副本。回滚则是预先准备好的流程，用于在发布失败后回到已知的正常状态。

恢复备份可能需要时间，也可能覆盖备份创建之后产生的有效订单、咨询、编辑或账户变更。网站代码或许能快速还原，但这未必能撤销数据库变更，也无法撤销外部支付、预约或邮件服务已经完成的操作。

负责任的计划会说明哪些内容可以撤回、哪些需要通过后续修复解决，以及变更期间产生的数据如何处理。AWS 关于未成功变更的指南建议在部署前准备恢复步骤，并通过监控判断变更是否成功。

为什么更新后有人仍会看到旧页面？

网站在整个更新期间都可以保持可用，但不同访客仍可能短暂看到不同版本的页面或文件。浏览器、内容分发网络、服务器缓存和生成页面可能保留旧内容，直到内容过期、重新验证或被主动清除。

这与网站停机不同。不过，如果更新涉及价格、条款、活动信息、库存或其他有时效性的内容，这种差异仍然重要。

清理缓存也应控制范围。Cloudflare 建议尽可能针对具体内容清理，因为清空整个缓存后，在缓存重新建立之前，后续请求都会回到源服务器。发布计划应指出具体变更了哪些页面和文件，不要把所有缓存都当成一个可以随意清空的整体。

何时安排维护时段才是负责任的选择？

如果在更新期间保持网站完全运行的风险大于短暂且提前告知的中断，维护时段可能是合适的选择。例如：

• 更新期间无法安全地修改实时数据；
• 新旧版本不能同时使用同一数据结构；
• 基础设施或网络路由必须在一个受控步骤中变更；
• 外部服务提供商要求中断，或没有并行测试途径；
• 我们还没有充分了解现有网站，无法安全地直接变更；
• 暂停一段明确的时间能让恢复过程更清楚、更快捷。

维护时段应说明原因、范围、预计时长、恢复决策和沟通计划。对于依赖咨询、订单、预约或会员访问的企业，只说“网站维护中，暂时无法访问”并不足够。

批准更新前应该问什么？

• 哪些页面和功能会发生变化？
• 工作期间访客和员工还能做什么？
• 变更会先在公开网站之外准备吗？
• 如何保护咨询、付款、预约、账户变更和其他实时数据？
• 通过哪些检查来确认发布成功？
• 如果某项检查失败，恢复计划是什么？
• 能否还原软件，同时保留有效的新数据？
• 托管、支付、邮件、身份验证、预约或其他外部服务是否会影响时间安排？
• 由谁决定继续、修复还是回滚？
• 如何以及何时通知受影响的用户？

回答不必列出每条技术命令，但应清楚说明对业务的影响。

LINK-V 如何处理网站更新？

在评估或维护网站时，我们会先检查网站、托管环境、CMS、数据库、集成、备份、访问权限和运营风险，再决定如何发布工作。合适的方法取决于变更内容和现有系统。

我们的目标是让常规更新平稳且适度；如果某项变更需要受控中断，我们也会坦诚说明。如果网站承载日常销售、咨询、预约、会员服务或内容发布，我们可以评估其维护安排和持续维护方案。