有个大户投流没有提前报备，直接把服务器 QPS 搞上限了，跟上次情形一样。

提醒了几个大户，下次大促前要提前报备。

把下单提醒通知人员数量从 100 调成 20。

今天爬楼泡汤。

这功能去年就有店铺在喊，一直拖到今天才上线。

最近有个 KA 几乎每天都要催一下，实在招架不住，先暂停别的开发，把这个员工等级搞上去。

实际上也就花了三天时间，不过虽然之前一直没开工，但是经常会去构思。这次是在构思很成熟的情况下完成的，所以开发用时不算多。

这两天的状态，半天处理投诉，半天开发。

花在消费者投诉处理上的时间快赶上春节了。

对于投诉多的店铺，暂时关停在线支付功能。

一直没明白微信是怎么通知商户去进行“确认注销”操作的。今天重新回去看文档，原来之前没看仔细，注销状态查询接口会返回一个 confirm_cancel_url（在文档的最末尾），服务商要把这个 url 转为二维码，让商户去扫码确认注销。

终于闭环了。

之前商户退出机制不完善，年限长了，就会有一些不再开店、不再使用商户号的商家，商户号出现“涉嫌资料异常”，例如身份证过期等。风险商户多了，对服务商不是好事。

傍晚爬楼，刚爬了一趟 28 楼，客户报线上故障。

紧急回房间处理，刚坐下来，已经自动恢复了。也就几分钟时间，自动好了。

继续再爬两趟。

后面看流量图，估计是几个大户集中在这个点投流。

问腾讯云的人，说是遇到这种突然发生的大流量，服务器会自动扩容，但是会有部分用户感知到“卡顿”。

平台收付通的“商户号注销”，代码是很快写好了，但是商户一直收不到确认通知。很奇怪，不知道微信通知是怎么触达商户的。

好久没看平台收付通文档，今天瞄一眼，发现有变化。

商户注销终于不用上传纸质材料了。

协助一个客户对账，对了一星期，今天总算理清了。

总结一下，账对不清的原因，主要是概念没搞清。

不过话说回来，被客户这么逼一下，一周内发了三个小版本，系统对账功能完善了不少。

有个客户用了两个月系统，突然想对一下账，发现对不上。

从下午折腾到晚上，还是没对上。发现好几个地方需要完善优化。

折腾了两天，最后关头发现痛点的关键：有个概念没分清。

一直把关注点放在云函数上，忽略了“数据库超时”这个问题。

数据量大时，要注意分页，单次请求数据库不能超过 5 秒，整个云函数执行过程不能超过 60 秒。

最后的最后，Jason 看报表时还发现一个 bug，手续费计算错了，少了一对括号。

两个人到底还是比一个人给力。