资损监控系统搭建-事故三大问:为什么会发生,影响面多大,以后如何避免

资损监控系统搭建-事故三大问:为什么会发生,影响面多大,以后如何避免

关于资损监控系统的思考。

每次看到同事换了新键盘,我都会跟他说一句,希望你这800块钱的键盘,别敲出800万美金的资损报告。 电商系统的程序员最不想面对的就是一份空白的资损报告。如果你是tob电商,说不定还能和供应商battle一下,毕竟你们是由合同的。 但是要是toc就完蛋了,扩散速度和损失增长都是指数增长的。

三大问

  • 为什么会发生?(是你的问题还是外部团队的问题,这锅能甩出去吗)
  • 影响面有多大?(如何统计数据?能不能拿N+1)
  • 以后如何避免? (是你的个人代码问还是团队流程问题?)

当有人上报issue的时候,你就应该开始准备这三个问题的答案了。 一来准备领导随时拉群问你情况:”谁能给我解释下目前情况?”。 二来如果想清了这三个问题,事故报告的思路也就清晰了。

为什么会发生?

如果能复现,那么问题就已经解决80%了。

如果不能复现,首先确认自己系统以及上下游最近的改动,如果48小时内有改动,那么99%是这个改动引入的, 不管这个改动看起来多么人畜无害,现实世界没有定义,只有现象。因为单靠程序员的想象力无法脑补出对方系统/APP/页面上隐含, 耦合了什么狗血逻辑。

如果你不信邪,就先在测试环境分布部署两个分支验证下。

影响面有多大?

千万不要有侥幸心理,发现事故的第一时间立即向上反馈,你只有调查权,没有更改权。

数据统计是个玄学,因为我们希望全方位的评估这个事故的重要性, 所以一般需要统计多份数据,每份数据都来自不同角度的分析视角。

如何保证数据正确性

在这个时刻,每一个数字都需要double check,任何一个数据都要符合你的逻辑, 因为你提供的数据会被外部团队或者领导拿去使用。 所以,每一项统计任务都需要派两个人同时进行,各自拿到结果后再校对。 这不光向下校对,还能发现之前是否有统计的错误,向上校对,发现隐藏的逻辑错误。

此外,要求上下游各自提供一份文件,如果你的逻辑正确的话,上下游和你们的文件应该是吻合的。

统计工作一般十分曲折,十分耗耐心,有些领导为了避免下属受不了统计工作而伪造数据。会将上下游的数据藏起来, 不让下属“走捷径”。

绝对资金损失的影响面评估因子

”绝对资金损失“是指被用户薅羊毛了,或者恶意套现了的场景。

  • APP 版本
  • 时间段
  • 是否需要伪造数据(正常用户下单会触发资损吗)
  • 支付渠道
  • 品类
  • 收费明细项
  • 损失总金额/总占比
  • 异常单数目/总占比

绝对资金损失的需要统计的数据

提供给安全部门,法务部门,运营部门使用。

  • 第一单数据:首次出现异常情况的时间
  • 修复时间点
  • 所有涉及资损的用户
  • 各个用户第一单时间
  • 各个用户下单量

相对资金损失的影响面评估因子

”绝对资金损失“是指被用户无法下单,或者降低了用户体验,提供下单成本的bug。 这类问题在统计数据时,需要考虑波动的因素。因为没有实际产生金额数据,所以一般是通过环比昨天/上一周的数据。 电商系统的下单数 受时间点影响还是比较多的,比如周末单量多一点但是付款率较低,因为用户有更多的时间货比三家。

以后如何避免?

测试角度

在软件工程中,dev和QA都是不可靠的,只有流程和自动化才是可信的。

对于电商系统,每多一个业务场景,逻辑分支都是几何级的增长,如果还依赖QA手动回归的话,那么迟早出bug,天天hotfix。

理想情况下,每个业务场景都应该有一套test cases沉淀在代码仓库内,dev 在测试环境push的时候会触发ci/cd自动运行 csaes。 或者QA维护一套cases,模拟用户下单来测试。总之就是能够重复执行的变量可控,结果确定的自动化测试。

流程角度

todo