订单|我对异常监控功能设计的一些理解( 二 ) 虚拟加密货币|gpu|rog|nvidia|raj

或是对于系统中描述性的数据进行监控，也是一种对结果的监控，这些描述性的数据由于它达到了预设的标准，满足了预设的规则，它的数据才视为有意义的异常，数据本身在累加计算的过程中是没有意义的。比如此门店的本日营业额畸低等等。
需要说明的是，对结果的监控一般不会独立使用，它应作为对事的监控的补充兜底。
那什么是对事的监控呢？
2. 事——对过程中的节点进行监控以订单业务为例，涉及到订单中商品的翻译、库存寻源确定发货门店、门店拣货、ERP生成凭证等节点，门店拣货从系统实现层面上又可以分为通知门店前台作业系统，门店前台系统作业提醒，门店确认拣货完成等节点。
由于各种业务节点是清楚的明确的（借用UML的的观点简单阐述一下为什么业务节点一定是清楚的明确的：系统设计是对现实世界的抽象，现实世界抽象成一个个用例，用例驱动概念设计，并最终进行编码，每一个用例都有明确的执行者，前置条件，可选流程与输出物）。
当我们按照MECE原则拆分到一个可供监控且有意义的颗粒度，如对订单中心推送新订单消息至门店前台系统失败，此业务只是订单履约中的一个节点，当此异常出现时，系统即自动标记异常，不用等待系统定时的比对发现异常。
当然，从另一个角度来说，我们也可以将异常感知的方式区分为这么两种：

业务进行中出现异常，系统自动标记。
监控系统使用者主动发起异常校验或系统根据预设的规则定时比对发现异常。

三、如何处理当系统识别到异常时，应当如何处理呢，我们一般有两种方式：
1. 系统自动处理如从外卖平台拉取订单时，数据缺失，系统可以做自动重试机制。
使用系统自动处理机制一般比较慎重，仅使用在可以依靠重新尝试拉取可以解除异常的场景下，一般不做复杂的异常解除逻辑的自动化，如订单长时间未备货，此时如果系统自动备货，可能会造成系统无法反映真实作业情况的问题，具体可以看这篇文章，来理解为什么要慎用系统自动逻辑《1-2年产品经理：教你接盘与重构的姿势》。
2. 人工介入处理仍以外卖平台拉取订单时数据异常的例子来说，当系统自动重试次数达到上线后，为减轻系统压力，不影响其他正常单据的处理，往往会停止自动重试，此时应允许人工介入处理。在设计人工处理异常数据时，应注意：

在对应异常单据中标注异常原因并提示解除异常的方法。
人工处理异常后，由于可能涉及到单据中数据的修改，必须提供日志功能，记录修改前的数据，修改后的数据以及修改的时间，修改人。
严格控制权限，因为可能要进行业务数据的修改，一般仅允许总部或区域运营进行修改。

当然还要注意一点，有一种非常特殊的异常，即系统根据预设的规则对订单进行加工，但是由于规则预设错误，导致实际加工后的订单数据也错误，如在系统中预设规则，购买A商品1份，实际应发货B商品12份，但是客户运营在设置规则时，设置成：买A商品1份，实际应发货B商品120份。
此时系统不会对此单据标记异常，但是确实不符合实际，此时人工介入处理时，应允许人工标记订单异常后再进行数据修正。
仍然是上面的例子，由于预设规则的错误，导致拣货商品数量错误，进而导致拣货商品的单价等都计算错误。此时应只允许修改拣货商品的数量，而不应允许修改拣货商品的单价，拣货商品的单价应由系统进行计算。即规则是：只改异常直接导致错误的字段值，而不改间接导致错误的字段值。