业务防资损，质量保障的第一要务！
Posted 老_张
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了业务防资损，质量保障的第一要务！相关的知识，希望对你有一定的参考价值。
前几天知识星球有同学向我咨询了这样一个问题：生产业务发生故障，涉及金额非常大，可能要被干掉，该怎么应对？
问题背景是这样：银行证券交易业务，未对输入金额乘以10000（单位万元），该模块上线大半年了，之前由外包同学负责测试，当时只检查了页面和流程，业务和监管平台也验收通过了。
在我看来，这是一个比较低级的问题。跨度大半年的周期，应该有很多人的工作涉及到核心交易模块，但生产还是出了这种问题，只能证明日常的测试验证和风险管控环节有很大不足。我给这位同学的建议有如下三点：
- 承认错误，交付质量不足带来的原因（而不单单是测试的问题）；
- 拿出复盘结果，说明过程，指出不足（流程、交接、校验、监控）；
- 后续行动方案，优化流程，系统强制校验，风险评估，业务防资损；
这篇文章，我想聊聊生产环境的业务防资损相关的内容。
如何理解防资损？
我们都知道质量保障的核心目标是交付质量和交付效率，我在文章中也一直在表达一个观点：技术本身不具备任何直接价值，而是通过支撑业务目标达成而体现自己的价值。
业务目标的达成，除了通过直接向用户提供服务来获取收益之外，本身的业务逻辑也需要具备自洽的能力，即具备不会被外界主观或客观因素导致自身业务出问题，无法提供服务而带来自身损失。
比如上述的银行证券交易业务，比如时不时听到的某APP被薅羊毛，比如自身的服务需要具备持续为用户提供正常访问和服务的能力（而不是经常宕机），这些其实都是资损的范畴，即资产损失。那什么是资损呢？
定义：由于设计缺陷、服务故障、误操作等导致公司或者用户蒙受直接或间接资金损失的场景；
根因：资损的根因，按照我的经验和工作实践，绝大部分资损的原因都是数值一致性问题导致；
处理策略：设计和编码时尽量评估规避风险，线上发布后尽快发现实时校验，资损发生后尽快处理解决；
防资损的四大策略
要做好防资损，以我的经验，结合具体的工作实践，我建议从如下几点开展。
事前：梳理/预防
从定义可以看出，资损是由于设计缺陷、服务故障、误操作等导致的。
因此在前期产品设计时，就应该尽可能的梳理出可能导致资损的场景；在编码实现时考虑到对应的风险，有相应的冗余手段（比如输入时的强逻辑校验）；在测试阶段测试用例尽可能覆盖各种异常和边界场景，并通过自动化的手段在后续迭代中持续校验。
事中：巡检/校验
产品线上发布后，要做的事情其实就是巡检+校验。
任务巡检：通过各种自动化或者定时任务的方式去不断巡检和资损有关的场景。
规则校验：比如交易金额相关的，可以制定规则库，所有的巡检任务必须符合防资损业务规则。
人工盯盘：通过轮值的方式不定时的去观察相关的业务监控，比如交易量、优惠券使用量等同比环比数据。
监控告警：对相关的资损场景定制专门的防资损监控，并且做到出现异常时及时告警和实时响应处理机制。
优先止血：当线上发生资损时，优先做到业务止血，就防止资损的范围和影响进一步扩大，在考虑从根本上解决问题。
事后：复盘/运营
资损事件发生后，及时组织相关人员参与复盘，分析资损事件的前因后果和根因，找到在设计、研发、测试、验收等环节存在的不足之处，制定对应的优化改进措施，并实时跟进改进项的落地和验证其有效性。这是一个长期的持续的过程，需要持续的运营这种机制。
资损大部分问题出现在数据不一致方面，因此日常的数据治理是必不可少的。当然，以文章开头的案例为例，其实也可以看作是一个技术债务的问题，即没有对输入进行强制的规则校验。因此定期的清除技术债务，也是需要考虑的。
组织：目标/责任
无论是事前的场景梳理和预防措施的制定，还是事中的线上巡检校验和监控告警响应处理，或者事后的故障复盘和改进落地，都需要有组织有体系的去跟进。
从团队或组织层面来说，对齐业务防资损目标，明确各角色岗位职责，有效组织开展防资损工作也是很重要的一点。
线上业务防资损体系
线上业务防资损，我们当时做了一套线上的防资损平台，大致构成如下：
场景管理：资损业务场景、资损数据场景、研发规范场景、历史故障场景，进行平台化管理。
巡检方式：以支付和财务对账为例，通过实时对账和离线对账解决数据一致性问题，通过监控告警和自动化测试巡检方式，做到资损的及时发现和及时处理。
技术组件：实时对账主要使用Flink，离线对账则是通过阿里云的dataworks，监控告警采用prometheus的监控体系，线上的自动化测试巡检则是通过专门的定制化改造来进行。
应急措施：主要包括故障应急响应机制、资损的应急预案、业务入口限流降级和针对应用服务的故障自愈。
虚拟团队：防资损需要有组织有体系的开展，而虚拟团队就是将防资损职责明确定义到各团队不同角色。
比如：有专门的NOC团队负责人工盯盘和故障发生时的信息分发和启动应急响应机制；运维和研发同学从技术的角度进行快速响应和问题处理，保障优先业务止血，而轮值leader更多的是进行重大问题决策。
其实业务防资损本身就是质量保障很重要的一环，甚至说是第一要务。资损问题不发生还好，发生了几乎都是生产P0/P1故障。
文章开头的案例从侧面也证明了质量内建和防资损的重要性，测试需要持续验证来保障高质量的生产交付。
技术管理进阶——技术总监的第一要务
之前完成了一个基础生存指南系列：
上述是偏中层管理软实力方面的要求，（个人认为）是基本的生存必要技能，能“活下去”，但是想“活得好”甚至“发家致富”还是远远不足的，因为还完全没涉及到业务呢！
一般情况下，技术管理想要出色，必须贴近业务，用技术的手段解决业务的问题。技术是工具，业务才是核心（有些场景可能不是），只想搞管理或者只想研究技术皆有风险
一、技术总监该做什么
前面的章节简单探讨过leader由于安全感（焦虑感）抢下面小伙伴活干的问题，这是一种卡位、上下锁死，是对信息量的不负责，也是对下面下伙伴的不负责，属于偏内卷的做法。
于是一个问题，技术总监到底该做什么呢？这里以一个故事展开。
之前一个产品同学跑来跟我们说需要采购一套供应链系统，以满足某方面的需求，而他十分迫切，希望我们尽快进行评估。
产研是天生的“敌人”，这类采购行为，当然是直接叫停（玩笑罢了），取而代之的是几个问题：
1）供应链系统是我们产品矩阵（框架）中的什么角色；
2）供应链系统是不是我们的核心依赖项；
3）其他类似的公司，供应链系统是否采购，是什么样的状态；
4）更成熟的公司是如何做的；
于是产品同学便去调研了......
这里大概得出了技术总监的一个重要差异化：要有大局观。
大leader需要跳出技术框架，部分进入产品（业务）框架，对每一部分要有自己足够的认知，也要知道这个部分对于全局是什么角色。
因为一般来说，各个小leader只会关注到自己的模块，大leader才有这个信息量以及时间（毕竟不写代码，不跟太多细碎的项目）将这些模块串联，如果没有关注全局的人，就会出现灰色地带区域无人管理的情况。
对于成本，大家都会避免负责，趋利避害是天性嘛。
二、全局角度下的模块重要度
之前有幸完整的见证了一块产品的诞生，甚至第一版的需求是我写的：
首先这是一个软硬件结合的项目，其次其中有一个尿检试纸光学检测问题，单从研发阶段可以划分为：
技术层面这里做三个工作：
1）设计基础的交互模型，采用Hybrid模式，andriod硬件；
2）业务模块是常规需求分下去做就行；
3）试纸检测一块实现难度非常高便需要亲自切入了；
首先，这里涉及了试纸盒如何设计才能侧面帮助准确率提高，还要设计通用的产品盒，以帮助后续硬件能售卖其他产品，这里需要解除很多“专家”，也需要解除很多模具厂商，来回拉扯，加之这里涉及到专利和有效性，关乎成败，还只能技术负责人切入了。
在这个基础上：
1）产品同学如果想把业务模块外包，你会认为后续迭代较多，并且需要和我们的产品矩阵结合拒绝；
2）产品如果建议直接在机器上使用原生开发，这样体验更好，但是你可以以机器投放出去基本完蛋为由拒绝；
3）产品如果想把光学检测部分外包出去，这里反而是值得思考的，一般的技术是不具备这个专业性的，但是这里无论从专利还是壁垒来说都是对公司极其重要的模块，这个时候可以建议最好招人做或者合作的模式；
4）其他部分，比如机器外形设计、广告商页面等，其实都可以外包，因为不涉及主干路径；
这里还仅仅是初期某一条业务线研发时期技术模块的思考，如果这类业务线开展10条以上，模块复用、数据流转，什么业务线重要，哪条业务线不重要，技术要有更多的判断，如果判断失准，就很可能耗时费力了，所以：
技术大leader需要给出什么该自己做，什么可以不做（外包）的判断，并且有理有据，需要尽可能的站在全局考虑某一模块的投入度。
那么什么重要，什么不重要的依据到底是什么？
三、建立主线
技术总监的第一要务是建立产品（业务）主线，不管你以什么方式，以你认为自洽的逻辑将产品线串起来，最好有完善的数据流向支撑串联逻辑，比如比较流行的人货场：
PS：图都是知乎上截的
先拆分业务（产品）模块，再思考技术模块，做到一定映射关系，而我这边也喜欢采用三层框架做分解。之前看了刘润的一篇文章，里面大概有几句话：
企业的唯一目标是创造顾客，创造（独特、品质）价值+（尽量）传递价值；
创造价值=做产品（服务）；
传递价值=做营销+做渠道=提高触达；
于是可以把产品分为三层框架：
之前我问了老板一个问题：如果微信九宫格给我们开放入口，我们是不是就成功了？
这里的问题的本质其实是，是不是产品流量足够大就算成功。
老板想了想说了下，流量这么大，你也承接不了啊。
这里的逻辑相当于你在村里开了一个小餐馆，突然给你挪到火车站，就算流量大，你这个小餐馆也服务不了，这里除了菜品好不好吃，还涉及到整个后厨的供应链管理，整个餐馆的服务（人员服务，菜品服务），整个销售揽客策略等......
所以初期，基础服务非常重要，其次流量很重要，再次营销策略很重要。
PS：这不废话吗，肯定都重要啊！
以世面上的直播平台为例，可能是这样的：
不论是人货场还是三大框架，或者其他什么模式，只要能用一条线一个数据流将现有的产品主线串起来都可以，然后再以你的逻辑判断其中每个产品模块在产品大蓝图中是什么角色，未来产品蓝图演化过程中应该是什么位置。
四、简单打样：营收线分解
PS：这部分完全是个人认知，大家读读就好。
形成系统性的思维后，需要对某条线建立足够的认知，比如我们深入营收模块，便至少需要回答以下问题：
1）公司的营收基本盘是什么；
2）既然营收活动可以刺激消费，那么他是怎么做到的，具体到一个周期几个营收活动可以利益最大化；
3）某些对营收有关系的模块要下线，这些模块属于哪部分，为什么下线为什么做不起来；
4）什么是货币体系，他是如何崩毁的；
......
首先回答一个问题，什么是营收框架？
营收框架其实是平台各个产品的市场集，是【所有消费产品或者服务】的【提供方】（卖方）和【消费方】（买方）组成的群体
消费方决定了产品的需求（量），提供方决定了一种产品的供给（量）；营收框架中有许多角色参与其中，核心就是买卖方。
第二个问题是营收框架如何运行？
事实上平台一般不提供内容服务，比如直播平台的服务是主播提供的，教育平台的服务是“教师”提供的，这些角色提供内容服务的时候，用户消费平台提供的产品对服务提供者进行奖励（现金、流量、荣誉），平台通过消费模块使用的“权益”（特效、身份感）对用户进行奖励。
简单来说就是，平台与卖方提供服务、用户消费服务，三方都获得奖励，这个就是营收框架运行的方式（花钱大家都开心）。
作为平台方，非常关心整个营收的规模，所以平台需要使用各种方法，让这个“营收盘子”越做越大，需求量变大或者效率变高（卖方产出变高）都是可行的方向。
第三个问题是，平台如何影响规模？
流量不是这里考虑的范畴，关于营收框架运行效率如何提高，这里首先要思考另一个问题：
单一产品营收规模=产品价格*产品销量
所以无论什么公司，做活动（撒币）变向降低产品价格，就是最好的手段，通过提高服务”有效价值“的手段来增加消费量，从而增加总体消费额（另外，平台提供了”营销事件“，也可以触发需求量提升，比如传统节日、520节点是一致的）。
在这种一步步发问中，将产品的所有收入手段做分类，比如会员、折扣、游戏折扣......
如此一来，便对这个模块有了较为清晰的认知了。
理想情况下，产品（业务）认知建立结束，便可以同步执行技术相关的建设，设计基本盘，设计营销活动，什么服务需要组合，折扣怎么设计，全局货币体系如何设计，便可以娓娓道来。
然后实际情况可能稍显复杂......
五、结语
技术总监生存指南是中层管理的门槛，是入场券的标准；了解业务、深入业务、融合技术与业务才是进阶之道。
全面的了解业务，也是中层管理的第一要务！后续文章，我们来探讨技术如何切入业务，一起奔小康，希望此文对大家有帮助。
以上是关于业务防资损，质量保障的第一要务！的主要内容，如果未能解决你的问题，请参考以下文章