缺陷分级：先定口径，再定等级

小程序上线之后，问题会从三个方向同时涌来：用户在小程序里截图反馈、业务方在群里转述客户投诉、运营在数据看板上发现某条链路转化率掉了。如果没有一套事先约定的分级口径，接下来发生的事几乎可以预测——谁喊得响，谁的问题先修；修完之后，P0 级的问题和「字体想调大一点」排在同一个队列里。

分级的关键不是分出 P0 到 P3 四个字母，而是把判定条件写成看得懂的事实描述。写「影响较大」等于没写，写「用户无法完成支付，且近 1 小时影响订单数超过 20 单」才是可执行的判定。

这张表落地时要补两个附加字段：发现来源（用户反馈 / 监控告警 / 内部走查 / 数据异常）和影响面估计（受影响用户数或订单数）。影响面这一列是分级的核心依据，没有它，所有讨论都会退化成「我觉得这个挺严重」。

还有一个容易被忽略的做法：把「谁有权升级等级」写清楚。建议是一线支持人员可以升级到 P1，P0 需要业务负责人或技术负责人任一方确认。升级门槛太低会天天救火，太高会漏掉真事故。

三个高频分级误区

误区一：按客户嗓门分级。大客户提的问题自动升一级，小客户的问题排队等。短期看是维护关系，长期看是把研发资源从「影响一万人的小毛病」调到「影响一个人的大情绪」。合理的做法是嗓门只影响沟通节奏（谁去回话、多久回一次），不影响修复优先级。

误区二：按修改成本分级。「这个改起来只要十分钟，先改这个」。这类改动最危险，因为它绕过了发版节奏，把一次计划内的版本拆成十次计划外的热修。每次热修都有回归风险，尤其是小程序这种前端代码全量下发的形态，改一个按钮样式也可能带上一个未测的分支。

误区三：所有问题都是 P0。当一个团队每周出三个 P0，说明等级定义失效了，实际效果等于没有分级。检验方法是看比例：健康的分级分布大致是 P0 占 5% 以内、P1 占 15% 左右、P2 与 P3 合计 80%。如果 P0 长期超过 15%，不是系统太差，是判定条件写得太松。

安徽好牛软件有限公司在交付小程序项目时，会把这三条误区直接写进运维交接文档，因为绝大多数上线后的混乱都源于此，而不是技术能力不足。

发版节奏：审核周期带来的硬约束

小程序和 App 最大的差别在于：你没法随时把新代码推给用户。每次发版要经历提审、审核、灰度发布（可选）、全量，这个链条决定了「修复时限」必须分成两类——能在服务端解决的，和必须发版的。

由此推出一条实用原则：凡是能做成服务端可控的，就不要写死在客户端。首页模块顺序、活动入口是否展示、某个按钮的跳转目标、限购数量、文案措辞，这些都应该由配置下发。做过这一层的项目，P0 事故的恢复时间能从「等审核」压缩到「改个配置」，差距是 24 小时和 20 分钟。

发版节奏建议固定成「双周常规 + 随时服务端」的组合：常规版本每两周一次，固定在周二或周三上午（留出工作日处理回滚），P0 走加急通道，P1 尽量并入最近一次常规版本。固定的好处是业务方知道什么时候提需求有意义，而不是每天催一次。

回滚不是万能：只能在服务端解决的六类问题

很多团队把「回滚」当作兜底手段，但小程序场景里回滚本身是有代价的：已经下载了新版本的用户不会自动退回旧版本，回滚只能让新用户拿到旧包，存量用户的异常仍然存在。所以真正的兜底应该是「服务端降级」，回滚只是最后一步。

最后一行值得单独强调。活动类配置错误是上线后最高频的 P0 之一，典型如满减门槛写错、优惠券可叠加、限购数量少一个零。如果这类参数写在代码里，修复就要走完整发版流程；如果走配置中心，改一行就恢复。这不是技术偏好问题，是止损速度问题。

灰度与监控：没有原生灰度怎么办

小程序没有 App 那种成熟的灰度通道，但可以拼出等效能力，四层组合基本够用：

• 体验版先行：业务方与超级用户在体验版上走一遍真实流程，重点验收支付、退款、核销这类不可逆操作。
• 分渠道码：不同渠道码进入不同配置，先让一个渠道或一个门店使用新逻辑，观察 24 小时的错误率与转化率。
• 白名单账号：内部账号与少量真实用户先进新逻辑，出问题影响面可控。
• 服务端流量比例：同一版本内，按用户维度做 10%→50%→100% 的规则切换，注意按用户维度而不是按请求维度，否则同一用户会看到两种结果。

监控侧至少要盯四个数：前端错误率、白屏率、首屏加载时间（P75 与 P95 分开看）、核心转化漏斗的每一步转化率。前三个用于发现技术问题，第四个用于发现业务问题。很多时候代码没报错，但某个按钮点击后没反应，错误率不会涨，转化率会掉——只看错误率会漏掉这类问题。

发版后的观察窗口建议定成「2 小时 + 次日同一时段」。2 小时内看技术指标，次日同一时段看业务指标，因为小程序的访问有明显的时间分布，上午发版看不出晚上的高峰表现。

值班与复盘：把节奏固定下来

上线后半年内的混乱，八成来自「没人负责」。三件事定下来，混乱会少很多：

• 发版日历：提前两周公布，包含版本号、需求清单、影响模块、回滚方案、值守人。日历公开的意义是让业务方知道什么时候提需求有效。
• 值班表：按周轮值，明确一线支持、技术值守、业务决策三个岗位。P0 事故里最耗时间的不是修，而是找人拍板。
• 复盘三问：这次问题为什么没在测试阶段发现？发现后为什么用了这么久？下次靠什么机制提前发现？只问这三问，不问「谁的责任」——问责任，下次就没人敢报问题。

复盘产出要落成一个具体动作，而不是一份文档。比如「支付回调漏单」的复盘，动作应该是「增加每日对账任务，差异超过 3 单触发告警」，而不是「加强测试」。没有落到机制上的复盘，同一个问题三个月后会再来一次。

安徽好牛软件有限公司在项目交付后的前三个月，通常会与客户一起过一遍发版日历与值班安排，把「上线即结束」的心态改成「上线才开始」。

常见问题解答

Q1：小团队没有专职运维，分级制度还有意义吗？

有，而且更需要。人少的时候，最大的浪费是「所有人都同时在处理最吵的那个问题」。分级制度的核心作用不是流程合规，而是让三五个人知道此刻该干什么、什么可以等。小团队的简化版可以只保留三档：阻断、影响使用、不影响使用；响应时限照旧，责任人写名字不写岗位。

Q2：用户报的问题复现不了，怎么定级？

先按影响面定级，不按可复现性定级。可复现只是修复前提，不是紧急程度。做法是：记录用户标识、机型、基础库版本、操作路径、发生时间，能拿到日志的先查日志。如果同一描述在 24 小时内出现 3 次以上，直接升到 P1，即使一次都没复现——重复出现的不可复现问题，通常是环境或数据相关，影响面往往比看起来大。

Q3：发版越频繁越好，还是越少越好？

都不是，稳定节奏最好。发版太频繁，回归测试被压缩，事故率上升；发版太少，需求积压，一次发版带的改动多，出问题时定位困难。双周一次是多数中型项目的平衡点，改动量控制在 15-25 个需求项以内。超过 30 项就该拆版本，因为一次发版的风险大致与改动项数的平方相关，不是线性。

Q4：审核被驳回，原定的上线时间怎么办？

第一原则是不要在驳回后急着改一版重新提，先看清驳回原因属于哪类：资质与类目问题需要补材料，通常 1-3 天；功能与内容问题需要改代码；体验与规范问题多为文案和交互。只有第三类能在当天改完重提。更稳的做法是提前一周提审，把审核周期当成本算进排期，而不是当意外。

Q5：怎么判断一个缺陷该热修还是等下个版本？

三个条件同时满足才热修：影响核心链路或有资金、数据风险；服务端与开关都无法绕过；影响面在持续扩大。只满足其中一两条的，一律排进下个版本。热修的成本不只是这一次的工时，还有回归测试的遗漏风险，以及团队对发版节奏的信任——节奏一旦被随意打断，后面每次发版都会有人要求「顺便把这个也改了」。