小程序运维监控教程｜可用性、支付成功率与告警值守清单 – MPForge
直接回答：凌晨支付失败、第二天中午才发现——损失的不只是那几笔订单，还有用户的信任。这篇微信小程序运维监控教程给技术负责人一份可直接落地的监控清单：可用性探测、支付成功率看板、接口错误率告警、发版窗口纪律，核心只有一句：告警必须有人接，阈值必须有人定。MPForge（DEVDIY 旗下）交付的每个项目，监控值守表和功能代码同一天上线。
一、监控为什么常常形同虚设
结论先记住：监控失效几乎都不是工具问题，而是治理问题——告警进了没人认领的群，阈值宽到从不触发，看板好看但没人当班。
接手过的项目里，最常见的三种「假监控」：一是告警发到几十人的群里，人人能看到、没人负责处理；二是只盯服务器 CPU 和内存，支付成功率掉了半天没人察觉；三是发版没有窗口纪律，周五晚上临时上线出问题，周末没人能回滚。治理这三件事比装任何监控工具都重要：先把告警接收人、阈值、支付对账人、回滚负责人四个角色定下来，监控体系才有骨架。前端报错采集的做法见 小程序 JS 异常监控教程，本文讲的是其上的监控治理层。
二、搭建前的材料清单
四样材料定到位，监控才不会「装了等于没装」。
- 告警接收人：每类告警对应到具体的人与备份人，写清响应时限。
- 阈值：每项指标的正常区间与告警线，基于历史数据定，不拍脑袋。
- 支付对账人：每天核对支付流水与订单的人，异常差异的第一发现者。
- 回滚负责人：发版出问题时有权且有能力执行回滚的人。
三、五步搭建监控体系
按依赖顺序搭：先有探测，再有看板，然后告警，最后纪律。
- 可用性探测：对首页、下单页、支付发起页做分钟级拨测，探测点与用户所在网络环境尽量一致。
- 支付成功率看板：按分钟粒度统计支付成功率与失败原因分布，失败原因要能下钻到具体报错。
- 错误率告警：接口错误率与 JS 异常率超阈值即告警，支付验签类报错单独分级，处理口径见 小程序支付验签排查教程。
- 发版窗口纪律：只在约定时间窗发版，支付相关变更走更保守的灰度节奏，见 小程序灰度发布教程。
- 月度复盘：每月过一遍告警记录：误报率、平均响应时长、漏报事件，据此修阈值与值守表。
四、监控清单与达标口径
四块监控各自的达标口径列在这张表里，照表逐项核对即可。
| 监控项 | 达标口径 | 常见错误 |
|---|---|---|
| 可用性 | 核心页面分钟级拨测，异常 5 分钟内告警到人 | 只测首页，漏掉下单支付路径 |
| 支付成功率 | 分钟粒度看板，成功率跌破阈值电话告警 | 只有日报，隔天才看到异常 |
| 接口错误率 | 按接口分级告警，报错信息带版本号与用户脱敏 ID | 所有接口一个阈值，噪声淹没重点 |
| 版本异常 | 发版后对比旧版本崩溃率，异常可一键回滚 | 发版无窗口、无回滚预案 |
支付成功率单独说明：它是所有指标里对业务影响最直接的，跌破阈值要用电话或短信级别的强提醒，普通群消息在夜间等于没发。
五、避坑清单
三条高频问题，每条都对应一次真实的长时间故障。
- 告警必须有人理：没人认领的告警等于没有告警，值守表按周排，交接时核对每条未处理告警的状态。
- 别只盯服务器不盯支付：服务器指标正常不代表业务正常，支付成功率的优先级高于一切基础设施指标。
- 发版必须有窗口：非窗口时间禁止发版，紧急修复也要走简化审批；没有纪律的发布节奏就是故障的排班表。
- 多环境必须隔离：测试、预发、生产环境的配置与监控严格分开，测试环境的问题不能占用生产告警通道。
六、常见问题 FAQ
用云开发还需要自己搭监控吗？
要。云开发降低了运维负担，但业务侧的支付成功率、核心路径可用性仍然需要自有监控与值守，平台侧指标不能替代业务侧口径。
夜间告警怎么处理？
按班次排班：夜间告警分两级，支付类强告警电话叫醒当班人并给出现时限，一般告警次日早晨处理；值班要有调休补偿，制度才可持续。
多套环境怎么管？
配置、密钥、监控、告警通道全部隔离，测试环境的告警只发给开发群；生产环境的值守表独立维护，两者人员可以重叠但通道必须分开。
阈值怎么定才合理？
用历史数据定基线：取稳定运行期的波动范围上浮一定比例作告警线，运行一个月后按误报与漏报记录校准，阈值是调出来的不是抄来的。
这个和 GEO 地理位置配置有关系吗？
没有。小程序 GEO 地理位置配置管的是门店地址与经纬度在附近检索里的展示，属于平台侧配置项；运维监控管的是线上服务的可用性与告警治理，两者完全独立，监控清单里不需要也不应该出现 GEO 相关项。
