资损是电商平台永远绕不开的话题，如果是平台（X宝、X东、X多多）的资损那会给平台减少收益，如果是店铺或者买家的资损（买家因为红包等权益失败导致多掏钱），那么这样会带来大量的舆情，甚至是合同上的纠纷，最后靠公关团队来安抚和赔付收场。所以说搞资损防控虽然是一个高收益的方向（目前国内关于资损的专家并不多），但是也是一个高风险的任务。简而言之，搞资损防控第一要对业务流程十分的理解，同时对玩法术语要明白，同时对技术（重试机制、锁机制、幂等性等等）也要有足够的沉淀。
本文主要就是我个人作为资损小白的一点关于资损防控的感悟，偏方法论，这里面并没有什么平台的介绍。
什么是资损
资损事件指的是导致“平台多出钱和少收钱”的事件。但是引起这个事件的原因有很多种，我粗略统计了一下，主要分为如下几个类型：
从上面可以看出，作为一个技术人员主要面对的资损场景有很多，但是可以解决的主要就四大类，不要小看这四大类。比如最后一个“商家人为差错”，曾经有真实的案例：平台的产品在策略的说明比较复杂（写代码的人还能写明白文档的一定要好好对待），商家因为理解错误，原本的机票88折设成了减88%，遭到客户疯抢刷单，损失惨重。自己有可能会彻底葬送了维持生计的成本…
说到这里，想起来其实有些商家宣传语也是很模糊的。比如“XXX活动，不花一分钱买云服务器建平台”，但是没说截止日期，也不主动让客户指定额度告警。一个月下来，客户收到账单一看数字吓死人！
如何梳理资损
一般来说如果是平台代销场景，商家跟平台在合约里是会有一个容忍buffer的条款，举个例子：某批货如果完美出售，可以卖1000万，那么设定buffer是10万，即990万以上就算平台成功完成任务。如果超出这个buffer，那么多出来的那部分就是商家资损了,可以去找平台赔偿。当然也有平台资损，比如平台多分钱给商家，或者优惠券红包设置成无门槛等等导致自己少收钱的行为。资损有两个数值，一个是理论资损一个是实际资损:理论资损指的是故障导致理论上的损失，比如X东去年的空调和烤箱被人薅羊毛事件，新闻标题是损失了几千万，其实这“几千万”是理论资损。实际资损是远远不会这么大的，因为会有售后介入，统一话术来安抚“薅羊毛”的用户，让他们放弃该订单，最后赔付红包了事。如果是ToB，那么也会有结算的同事去向多打款的商家追款，那么实际资损就是无法追回的那部分了。
虽然实际资损才是真实的损失，但是这绝不是代表“理论资损”不重要！相反理论资损非常重要，它才是衡量漏洞严重性的标准。
资损的防控主要还是“事前查—监控盯—快回血”这几part，这几个part的价值也是递减的。“事前查”这一块主要考验项目立项的时候，业务在prd文档里是否考虑周全。我曾经看过一个业务场景：“平台跟商家结算的时候会取单据的最新合同，但是这期间商家的合同是会发生变化的。原来可能是货入仓了就直接结算，但是后来变成了时销时算（可能商家资金比较紧张，不能接受每月结算，而是卖出后马上就跟平台分钱）。这样就会有的货物在入仓的时候平台就已经给商家结算过一次钱了，但是随着合同的变化，在商品卖出去的时候又重复结算一次。”这种产品问题其实是可以避免的，但是这种问题由于产品人员更迭，经常漏洞发现的时候已经漏水许久了，无论是找商家追债和内部追责都很不方便。
“快回血”这部分主要考验的是开发同学预案覆盖度和兜底逻辑是否合理，当发现了对账出现了异常，可以迅速止血，甚至不惜熔断的手法。“快回血”和“事前查”这个不是本文重点讨论的范围，因为这两个场景涉及到很多的“具体事情具体分析”。这里主要是说一下“监控盯”。
资损故障如果技术型问题，除了产品BUG之外那就是数据核对不一致。举个例子，某些产品由于仓覆盖的关系只能是在特定的某些区域可售的，比如说某些奢侈品只能在北上广深等一线城市才有货，那么这种货品肯定有一个商品标来体现它的特别性。在链路中，如果这个标丢失了，就成了“全国可售”，这样非可售区域的用户下了单，却拿不到货，就会出现超卖的问题。那么就会产生舆情，最后靠售后安抚了事，赔付不少的红包。
那么如何能比较全面的梳理全资损点呢？我觉得分两个方法，一个是通过以往的资损事故，让产品、开发和测试的同学枚举资损场景。还有一种方法，就是反推。
反推是什么意思？就是从结算的角度出发，因为结算才是钱出去的最后一环，为了钱不出差错，那么一切到结算这块的数字一定要是准确无误的。一般来说，结算都是自己有一套公式的，可以根据公式来逐级的拆解，这样落实到具体的各个部门。让对应的接口人来把监控补齐。如图：
这样是不是看起来清晰多了，也方便让各部门快速定位到自己负责的一part有哪些因素是下游强感知的，这样上游在修改他们的时候也要考虑到他们。
最后注意一种情况，那就是隐藏的资损，这种主要体现在“时效表达”上。比如“仓定位错误”，即顾客是杭州的，但是仓关系错误，定位商品需要在北京发货，到杭州是2天之后了。那么对于急需该产品的客户来说，他的心智就会去转投另外的电商APP购买同款商品了。这种情况虽然没有造成实际的金额往来，但是也要列入到整治的范围里。
至于如何整治，其实除了监控之外还需要一个强力的核对平台。通过两两核对或者什么手段，保证上游的数据在流到下游的时候不会发生丢失甚至是变化。
不过目前业界在监控的时候只能应对传入“值”类型错误、为空或者上下幅度较大这几个场景。而由于电商玩法很多，具体一些配置，比如优惠券或者加价购场景，可能就需要一些极低的价格。那么这种情况还是要人工去double-check，这一部分一直都没有一个好的解法。
工作安排的几条军规
这一part跟资损没直接关系，但是有些公司比较喜欢搞运动、搞集中战役。那么面对这种情况，恰巧老板又抓你来当战役的leader，你应该做到如下几点：
1.第一时间明确战役目标，制定战役的里程碑，将目标拆解到周维度。拿着这个目标和里程碑去找各位老板说明战役的重要性（公司高层非要搞，我也没办法），再要具体干活的人力。同时让老板对参与战役的同事减少当前的任务，让这些同事可以更充足的精力投入到战役里；
2.让具体干活的同事认同战役里程碑，同时让他们自己拿出来一份自己分内任务的具体可行性计划，大家一起评估；
3.制定一个日报/周报的模板，要求同事按期汇报工作进展。同时一定要注明有无风险，因为战役的第一负责人是你，如果战役没有达到预期效果，那么被问责的人也是你。所以一定要对风险了如指掌，出现了delay的风险要第一时间出面解决；
4.切忌中途改变目标和加入新目标！这必然会引起同事的反弹，不过难免会遇到“官大一级压死人”的场面，负责战役的领导突然脑抽风，要加XXX任务或者改变XXX的验收标准。那就要你顶住，哪怕是标准与现在实际情况偏离不多，实在顶不住就只能靠话术或者干脆升级到高一层，继续调人力过来支持了；
5.要对战役中的目标过程有一个比较清晰的认识，能合并的地方尽量合并。各部门在战役里有交集的地方需要拉齐时间线，统一确定产出的形式，同时这个形式也是领导所认可的；
6.如果有的team leader比较难搞怎么办？那你就拉一个跟他比较熟的人进入你的战役队伍，让他去搞定这个team leader…
