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

编辑导语：对于SaaS产品来说，系统的稳定性是产品可用性原则的体现，为保证系统的稳定性，则必须做好系统的监控与日志功能。本篇作者就以订单中心这一实际的产品，分享了自己对异常监控功能设计的一些理解，一起来看看吧。

文章插图
对于SaaS产品来说，系统的稳定性是产品可用性原则的体现，为保证系统的稳定性，则必须做好系统的监控与日志功能。日志功能已在之前的文章中进行描述《小功能大思考：订单轨迹日志功能设计思考》而监控功能从以下方面保证了系统的稳定性：

及时感知异常
方便排查异常
高效处理异常
降低异常影响
有效分析异常

笔者目前在负责一个O2O订单中心产品，产品的主要功能为：聚合分发订单以实现订单的履约。
所谓聚合，是获取了美团外卖、饿百、有赞等公域和私域的O2O订单，进行了订单数据的一致化标准化。
所谓分发，是将数据一致化后的订单分发至门店作业系统，聚合物流系统，ERP系统，统一进行标准化拣货作业、标准化配送、标准化记账与库存管理。
在实际业务开展过程中，系统不稳定，由于涉及的系统众多，一个完整业务流程的节点也众多，造成运维工作量量较大。
今天笔者就以订单中心这一实际的产品，分享我对异常监控功能设计的一些理解。
一、监控什么有同学肯定要问，运维不是有自己的自动化运维工具，可以对诸如接口请求异常、数据库异常等做自动化的监控吗，为什么我们还要设计监控管理功能，原因有两个：
1. 工具的使用对象不同运维自动化工具面向的是运维部门，如kibana日志分析平台等工具需要掌握一定的语法和在海量数据中抓住异常的技巧，而系统的技术支持人员如运营或客户的IT部门，掌握这种工具或技能的成本较高，无疑使用这种工具是增加了系统整体运营成本的。
2. 工具的使用场景不同如果将产品分为接口层、表现层、业务层、存储层，那运维自动化工具是对接口层和存储层进行的监控，运维工程师进行监控时也不会尝试理解当前异常对实际业务有没有造成影响，造成了什么影响，数据是否要修正，是否需要安抚客户等等问题。
如让运营同学对接运维工程师来进行判断，运维工程师使用技术语言告知运营又经常鸡同鸭讲，同事大量不影响实际的业务的异常没有过滤直接交给运营，也大大增加了运营同学的判断工作量。
故我们需要对系统各个层级的异常进行梳理、过滤、转义，以让运营同学聚焦影响业务的异常，那么我们一般监控下面两个方面：

业务监控：遵循一定的系统规则，判断系统中的数据或指标异常，如：订单中门店信息缺失、门店营业时长畸低、门店长时间未拣货、多系统库存差异等。
系统监控：系统故障造成正常业务无法继续进行的异常，如：如接口调用异常，导致数据没有正常流转到下游系统。

二、如何感知在《THINK IN UML》一书中，表述了现实运行的机制：人驱动系统、事体现过程、物记录结果、规则控制运行。那么其实我们在感知异常时，也是对事和物进行监控。
1. 物——对结果进行监控一般用于监控逻辑隐藏在系统底层，业务节点比较复杂的业务。
以库存同步举例：商品运营经历在订单中心发起库存校准任务，ERP识别到此消息后根据任务任务加工同步数据，接着同步至订单中心，然后由订单中心根据库存策略加工出不同的数量分发至各个平台。
在这个业务中，我们经常会发现，由于系统累积性的差异，如ERP中库存扣减凭证未及时生成或服务短时波动造成数据同步丢失等等原因（异步系统不可避免出现的问题），造成多方系统数据不一致，往往可以通过对多个系统的数据限定范围进行盘点来发现异常。此种对异常的监控一般是由监控系统的使用者主动发起的。