网站维护前备份与恢复 QA 检查清单

网站备份与恢复 QA 决定了维护窗口是可控操作，还是长时间故障。文件备份、数据库导出或平台快照本身不够，团队必须验证它能恢复到正确的网站状态。

WordPress 插件更新、Shopify 主题修改、Headless CMS 迁移、网站改版上线、DNS 切换、批量内容调整，或任何可能影响营收、线索、SEO 和编辑流程的维护工作，都应该先跑这份检查清单。

先列出构成网站体验的所有系统。回滚不一定只是主题文件，还可能包括数据库记录、媒体资产、重定向、环境变量、表单、搜索索引、支付设置、App 配置、DNS 记录和 analytics tags。

每个系统都要定义恢复目标。展示型网站也许能接受当天恢复；电商网站可能需要订单、客户、库存和 checkout 数据在几分钟内保住。多语言网站则要确保每个 locale、canonical URL 和 hreflang 一起恢复。

• 列出代码仓库、托管项目、数据库、CMS、媒体库、对象存储、搜索索引、DNS、CDN、表单、电商平台和第三方 App 设置。
• 标记每个系统的恢复点目标：维护开始前、每小时、每天，还是接近实时。
• 标记恢复时间目标：业务能承受 homepage、checkout、lead form 或内容页坏多久。
• 识别维护窗口中仍会变化的数据，例如订单、账号、表单提交、评论、评价和编辑内容。
• 为每个系统指定能导出、恢复、验证和批准的人。

任何人改 production 之前，都要先创建恢复点。WordPress 通常要包含数据库、uploads、theme、plugins 和配置。Shopify 可能需要复制当前主题、导出主题文件、导出商品或 metafields、保存 App 设置证据，并明确如何回到当前 live theme。

Headless 和 B2B 网站还要包括托管部署、CMS entries、媒体、重定向、环境变量、edge configuration、webhooks 和 API credentials。保留一份简短证据，证明哪份备份在什么时候完成。

• 记录 timestamp、owner、source system、backup location、retention period 和 restore method。
• 把 theme 或 code rollback 与 database rollback 分开，避免回滚代码时误删客户实时数据。
• SEO 敏感迁移前导出 redirect map、robots rules、canonical overrides 和多语言路由规则。
• 对没有可靠 API 备份的第三方设置，保存截图或导出文件。
• 如果备份包含客户、订单、线索或账号数据，确认文件已加密或受到访问控制。

从未恢复过的备份只是一个假设。高风险维护前，要把备份恢复到 staging 或临时环境，并确认恢复后的网站像 production 一样工作，同时不影响 production 数据。

staging 恢复要足够接近真实情况。检查数据库兼容性、媒体路径、插件或 App 版本、环境变量、重定向、用户权限、后台任务，以及依赖域名回调的集成。

• 把数据库和文件恢复到 staging，然后确认 homepage、关键 landing pages、PDP、forms、checkout path 和 admin login 能加载。
• 验证媒体文件、下载文件、图片优化和 CDN 路径恢复后没有断。
• 检查 redirects、canonical tags、sitemap generation、robots rules 和 hreflang 输出。
• 确认 staging 不会发送真实客户邮件、支付请求、广告事件、webhook call 或 CRM 更新。
• 在 live 维护窗口前写下恢复耗时、失败步骤、手动修复点和 blocker。

最难处理的恢复问题通常不是旧代码，而是备份之后新增的 production 数据。订单、线索、账号、内容编辑、评价、订阅变化、库存调整和支持消息，都可能在盲目恢复数据库时丢失。

维护开始前先定义实时数据策略。低流量内容站也许只需要短暂 content freeze；电商网站要优先保护 checkout 和订单系统，能回滚代码或主题时，不要轻易整库回滚。

• 决定是否需要 content freeze、order freeze、partial maintenance mode，或正常营业。
• 如果可能需要重新应用，单独记录 forms、orders、customers、inventory changes、reviews 和 CMS edits。
• 电商场景不要轻易 database rollback，除非已经有订单和客户记录的对账方案。
• 记录谁可以批准丢失或手动重放维护窗口中产生的数据。
• 回滚后把 orders、form submissions、accounts、CMS entries 和 media uploads 的数量与回滚前记录对比。

恢复操作可能悄悄伤害 SEO，例如带回旧重定向、旧 metadata、缺失 canonical、过期 robots rules 或旧的多语言路由。备份 QA 应该包括保护现有排名的技术 SEO 资产。

上线或维护前，导出当前 URL 资产，并在恢复后抽样验证。重点关注带来营收、合格线索、自然流量、广告流量和多语言入口的页面。

• 保存 redirect rules、canonical rules、sitemap output、robots.txt、noindex settings、hreflang rules、structured data 和重点 metadata。
• 验证恢复后的 URL 返回预期状态码：200、301、404，或按计划 noindex。
• 检查 canonical tags 不要指向 staging、preview、temporary 或旧域名 URL。
• 确认 XML sitemap 和 internal links 没有暴露旧路径或缺失 locale 版本。
• 准备一个短 crawl sample，覆盖 homepage、service pages、blog posts、product pages、collection pages 和重点活动 URL。

回滚规则应该在团队还没有压力时写好。先决定哪些问题必须立即恢复，哪些可以向前修复，谁有权做决定。否则团队常常在维护窗口里争论风险，而网站继续坏着。

触发条件要客观。Checkout failure、lead form failure、admin lockout、大面积 500 errors、商品页消失、多语言路由错误或重大 SEO regression，都应该有清楚的负责人和升级路径。

• 维护开始前定义 blocker、warning 和 acceptable-risk 三类。
• 设置决策截止时间，避免一直修补到恢复窗口消失。
• 指定 rollback owner、technical operator、business approver 和 communications owner。
• 整个发布过程中都要让旧 deployment、theme、database snapshot 和 configuration exports 可访问。
• 回滚后验证 customer path、admin path、analytics path 和 SEO path，再宣布网站恢复。

恢复成功不代表工作结束。团队还需要证明网站可用、可追踪、可抓取，并且可以安全编辑。回滚或恢复后马上跑一轮聚焦的 smoke test。

这轮测试要短到在压力下也能执行。目标不是重跑完整改版 QA，而是证明业务关键路径已经回来。

• 打开 homepage、重点 service pages、重点 blog posts、重点 products 或 collections、contact page、search、cart、checkout 和 admin login。
• 提交一个测试表单；如果合适，再跑一个测试订单或 checkout simulation。
• 检查 uptime、server errors、console errors、broken images、broken scripts 和明显 layout shifts。
• 验证 analytics、consent、CRM、email delivery 和 webhook destinations 没有重复或陈旧事件。
• 记录最终状态、剩余风险、owner 和下一段监控窗口。