拉卡拉开放平台

代码部署完成只是开始。上线后的头一段时间，是问题最集中暴露的窗口。盯什么、盯多长时间，需要有明确安排。

一、成功率

最直接的指标。关注点不是绝对值，而是与预期的偏差：

• 成功率明显低于测试环境：说明生产环境存在差异；
• 成功率随时间下降：可能存在资源泄漏或累积问题；
• 成功率波动剧烈：可能存在不稳定的依赖。

二、失败类型分布

只看成功率会掩盖结构变化：同样是成功率下降，集中一类与均匀分布，修法完全不同。

三、处理耗时

耗时变慢往往是故障的前兆。除了平均值，更应关注慢请求的比例。

1. 观察慢请求是否集中在特定时段；
2. 观察是否与请求量相关；
3. 观察是否随运行时间逐渐变长。

第三种情形提示可能存在资源未释放的问题。

四、通知到达情况

上线首日应当确认通知链路真的通了：

• 是否有通知到达；
• 到达后是否被正确确认；
• 通知与查询结果是否一致。

这三项都确认过，才能说通知链路是通的。

五、对账结果

上线首日应当做一次完整对账，而不是等到第二天例行对账。

观察期要多长时间

建议至少覆盖一个完整业务周期，并包含一次完整的对账流程。如果业务有明显的高峰低谷，还应当覆盖至少一个高峰时段。

谁来盯

观察不应该是「大家留意一下」，而应当指定具体的人，并明确观察的时间点与记录方式。

异常情况的处理顺序

1. 先判断是否影响资金正确性；
2. 涉及资金的立即评估是否需要暂停；
3. 不涉及资金的记录并继续观察；
4. 确认无法快速解决的，执行回滚。

为什么回滚选项要保留

上线首日保留回滚能力，不是为了认输，而是给自己留一个可控的退路。有退路的变更，才是真正可执行的变更。

观察记录怎么写

观察不是盯着屏幕看，而是留下可回溯的记录。建议每次观察记录三样东西：

有了这份记录，即使换人继续观察，也能快速接上。

首日之外的安排

上线首日之后，观察强度可以逐步降低，但不应当立刻取消。

1. 第一周：每日核对对账结果；
2. 第一个月：每周回顾一次异常分布；
3. 之后：纳入常规巡检即可。

一个容易被忽视的信号

除了技术指标，用户侧反馈同样重要：客服收到的咨询内容、用户描述的异常现象，往往能提供监控看不到的视角。上线后安排与一线沟通一次，常有意外收获。

上线后的观察，本质上是在为系统的稳定性购买保险。花在前几天的时间，通常会在此后几个月里持续产生回报。

观察期的长度可以与业务节奏匹配，但无论长短，都不应在确认稳定之前提前结束。