网站回归问题应急 Runbook：上线后支持团队怎么处理

网站回归问题，是指发布、内容更新、插件更新、主题调整、应用变更、缓存清理、迁移步骤或第三方脚本更新之后，线上网站出现了不该出现的变化。它可能很明显，比如结账按钮失效；也可能很隐蔽，比如某个模板的 canonical 标签消失。

这份 Runbook 适合 Shopify、WordPress、Headless Commerce、B2B 网站和多语言网站的上线后支持。它帮助团队从慌乱切换到诊断：先分类、留证据、决定是否回滚、保护 SEO 和分析追踪，再把问题变成可预防的维护项。

先判断严重级别，而不是先猜原因。一个小的间距问题和支付流程阻塞都需要处理，但它们不应该使用同样的响应强度。分级能避免团队对小问题过度反应，也避免低估收入、索引和线索获取相关的问题。

请指定一个负责人、一个沟通频道和一个决策时间。即使决策时间只有 20 分钟也有价值，因为它会迫使团队在观察、热修、回滚和深入排查之间做选择。

• 一级：结账、购物车、登录、线索表单、预约、支付或关键导航被阻塞。
• 二级：SEO、索引、重定向、hreflang、结构化数据、分析追踪或主要内容模板受影响。
• 三级：重要页面内容、活动模块、筛选、站内搜索、本地化内容或编辑流程降级。
• 四级：视觉细节、非关键布局偏移、小文案错误或单一浏览器问题，可见但范围有限。

改动前，先收集足够证据，让另一位开发或市场同事之后也能复现问题。很多回归问题会在缓存刷新、应用重试、部署回滚或内容重新发布后消失。如果没有证据，团队可能只修好了表面现象，却找不到真正原因。

在事件线程里使用一份简短模板。内容保持客观：受影响 URL、预期结果、实际结果、首次发现时间、设备、浏览器、市场或语言、登录状态、复现步骤、截图、控制台错误、网络错误，以及最近一次发布或内容变更。

• 如果问题和视觉或交互有关，至少保存桌面和移动端各一份截图或录屏。
• 记录完整 URL，包括查询参数、语言路径、集合筛选、商品变体或预览 token。
• 确认问题只出现在生产、预览、某个市场、某个浏览器、某种账号状态，还是影响所有用户。
• 保存相关发布记录：部署 SHA、主题版本、插件更新、应用变更、CMS 发布、重定向导入或缓存清理。

回归问题通常不只影响一个页面。一个坏掉的商品模块可能影响所有商品模板。一次错误的重定向导入可能影响旧活动 URL。一个缺失的 noindex 规则可能让测试页面暴露。下一步是找到最小但真实的影响范围，再决定修复方式。

对电商和 B2B 网站，先测试能产生业务价值的路径。对 SEO 敏感的变化，要检查源码输出和渲染后的输出，而不只是浏览器里看起来是否正常。很多危险回归在视觉上是看不出来的。

• 收入路径：商品选择、加入购物车、购物车抽屉、结账、支付方式、线索表单、预约或询价。
• SEO 路径：标题、meta description、canonical、robots、hreflang、状态码、重定向、结构化数据、内链和 sitemap。
• 内容路径：首屏模块、价格表、案例、集合描述、本地化文案、下载资源和政策页面。
• 追踪路径：页面浏览、表单提交、结账步骤、购买、合格线索、Consent Mode、UTM 保留和服务端事件。

最好的应急响应不一定是最快改代码。当问题严重、刚出现、并且能对应到某次明确发布时，回滚通常更安全。当问题很小、范围清楚、容易验证时，热修更合适。只有在问题级别低、且有明确下一次检查时，观察才是可以接受的选择。

把决定写清楚。在事件线程里留一句话：我们回滚，因为结账被阻塞；或我们热修，因为问题只来自一个 Section 设置；或我们观察，因为第三方 API 已恢复，目前没有用户路径继续失败。

• 当结账、线索获取、登录、重定向、索引或全局模板在一次已知发布后出问题时，优先回滚。
• 当变化只涉及一个模板、一个配置、一个内容字段、一条 CSS 规则或一个集成映射时，可以热修。
• 当问题是间歇性的、第三方引起的、已经恢复，并且有告警和负责人时，可以观察。
• 不要在同一次应急处理中混入无关清理。恢复改动要尽量小。

回滚或热修后，验证原本失败的路径和少量相邻路径。除非影响范围还不清楚，否则不要在事件中重新跑完整上线检查清单。目标是获得足够信心，让网站安全恢复，然后再安排后续深度清理。

聚焦矩阵应该覆盖受影响模板、一个相关模板、移动端、桌面端、一个未登录状态，以及必要时一个已登录或客户状态。多语言网站还要检查主语言和一个次要语言。对 Shopify 和 WordPress，如果问题来自内容或主题设置，也要检查编辑器预览。

• 确认原始复现步骤已经通过，然后保存新的截图或录屏。
• 检查一个相邻页面类型：商品页加集合页、服务页加案例页、落地页加表单感谢状态。
• 必要时清理或绕过缓存：CDN、Headless 前端、Shopify 主题预览、WordPress object cache、浏览器缓存或应用缓存。
• 确认没有引入新的控制台错误、网络请求失败、分析事件缺失或 SEO 元数据变化。

事件处理中，利益相关方不需要每个技术细节，但需要知道团队正在控制局面。请用简短更新说明时间、影响、动作、下一次检查和负责人。尤其当问题是销售、客服、市场或管理层先发现时，这一点更重要。

避免只说我们正在查看。更有用的更新应该说明什么受影响、什么没有受影响、刚刚做了什么、下一条消息什么时候发。这样维护支持才是一套运营流程，而不是一串猜测。

• 初始更新：问题已确认、受影响路径、严重级别、负责人和下一次更新时间。
• 恢复更新：已回滚或热修、正在验证、剩余检查项和已知限制。
• 解决更新：用户路径已恢复、证据已保存、预防任务已创建、后续复盘时间。
• 客户侧说明：保持简短、客观，聚焦影响、恢复和预防。

事件不是在页面看起来正常时就结束。它要在团队知道问题为什么漏掉、下次靠什么发现时才结束。不是每个小问题都需要正式复盘，但每个问题都需要一条预防记录。

在 backlog 或维护计划里添加一条具体预防任务。它可能是一个回归测试、发布检查项、监控告警、内容规则、插件更新策略、CMS 字段限制，或者 Runbook 里的回滚说明。

• 根因：发布 bug、缺少 QA 状态、内容模型缺口、插件更新、应用变更、缓存问题、数据问题或职责不清。
• 发现缺口：为什么团队是从用户、客户、爬虫或数据下跌中发现，而不是从告警或清单中发现？
• 预防任务：添加一个最小但耐用的防护，能抓住这次具体问题。
• 负责人和截止时间：在关闭事件线程前就分配好。