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

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

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

笔者目前在负责一个O2O订单中心产品，产品的主要功能为：聚合分发订单以实现订单的履约。

所谓聚合，是获取了美团外卖、饿百、有赞等公域和私域的O2O订单，进行了订单数据的一致化标准化。

所谓分发，是将数据一致化后的订单分发至门店作业系统，聚合物流系统，ERP系统，统一进行标准化拣货作业、标准化配送、标准化记账与库存管理。

在实际业务开展过程中，系统不稳定，由于涉及的系统众多，一个完整业务流程的节点也众多，造成运维工作量量较大。

今天笔者就以订单中心这一实际的产品，分享我对异常监控功能设计的一些理解。

一、监控什么

有同学肯定要问，运维不是有自己的自动化运维工具，可以对诸如接口请求异常、数据库异常等做自动化的监控吗，为什么我们还要设计监控管理功能，原因有两个：

1. 工具的使用对象不同

运维自动化工具面向的是运维部门，如kibana日志分析平台等工具需要掌握一定的语法和在海量数据中抓住异常的技巧，而系统的技术支持人员如运营或客户的IT部门，掌握这种工具或技能的成本较高，无疑使用这种工具是增加了系统整体运营成本的。

2. 工具的使用场景不同

如果将产品分为接口层、表现层、业务层、存储层，那运维自动化工具是对接口层和存储层进行的监控，运维工程师进行监控时也不会尝试理解当前异常对实际业务有没有造成影响，造成了什么影响，数据是否要修正，是否需要安抚客户等等问题。

如让运营同学对接运维工程师来进行判断，运维工程师使用技术语言告知运营又经常鸡同鸭讲，同事大量不影响实际的业务的异常没有过滤直接交给运营，也大大增加了运营同学的判断工作量。

故我们需要对系统各个层级的异常进行梳理、过滤、转义，以让运营同学聚焦影响业务的异常，那么我们一般监控下面两个方面：

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

二、如何感知

在《THINK IN UML》一书中，表述了现实运行的机制：人驱动系统、事体现过程、物记录结果、规则控制运行。那么其实我们在感知异常时，也是对事和物进行监控。

1. 物——对结果进行监控

一般用于监控逻辑隐藏在系统底层，业务节点比较复杂的业务。

以库存同步举例：商品运营经历在订单中心发起库存校准任务，ERP识别到此消息后根据任务任务加工同步数据，接着同步至订单中心，然后由订单中心根据库存策略加工出不同的数量分发至各个平台。

在这个业务中，我们经常会发现，由于系统累积性的差异，如ERP中库存扣减凭证未及时生成或服务短时波动造成数据同步丢失等等原因（异步系统不可避免出现的问题），造成多方系统数据不一致，往往可以通过对多个系统的数据限定范围进行盘点来发现异常。此种对异常的监控一般是由监控系统的使用者主动发起的。

或是对于系统中描述性的数据进行监控，也是一种对结果的监控，这些描述性的数据由于它达到了预设的标准，满足了预设的规则，它的数据才视为有意义的异常，数据本身在累加计算的过程中是没有意义的。比如此门店的本日营业额畸低等等。

需要说明的是，对结果的监控一般不会独立使用，它应作为对事的监控的补充兜底。

那什么是对事的监控呢？

2. 事——对过程中的节点进行监控

以订单业务为例，涉及到订单中商品的翻译、库存寻源确定发货门店、门店拣货、ERP生成凭证等节点，门店拣货从系统实现层面上又可以分为通知门店前台作业系统，门店前台系统作业提醒，门店确认拣货完成等节点。

由于各种业务节点是清楚的明确的（借用UML的的观点简单阐述一下为什么业务节点一定是清楚的明确的：系统设计是对现实世界的抽象，现实世界抽象成一个个用例，用例驱动概念设计，并最终进行编码，每一个用例都有明确的执行者，前置条件，可选流程与输出物）。

当我们按照MECE原则拆分到一个可供监控且有意义的颗粒度，如对订单中心推送新订单消息至门店前台系统失败，此业务只是订单履约中的一个节点，当此异常出现时，系统即自动标记异常，不用等待系统定时的比对发现异常。

当然，从另一个角度来说，我们也可以将异常感知的方式区分为这么两种：

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

三、如何处理

当系统识别到异常时，应当如何处理呢，我们一般有两种方式：

1. 系统自动处理

如从外卖平台拉取订单时，数据缺失，系统可以做自动重试机制。

使用系统自动处理机制一般比较慎重，仅使用在可以依靠重新尝试拉取可以解除异常的场景下，一般不做复杂的异常解除逻辑的自动化，如订单长时间未备货，此时如果系统自动备货，可能会造成系统无法反映真实作业情况的问题，具体可以看这篇文章，来理解为什么要慎用系统自动逻辑《1-2年产品经理：教你接盘与重构的姿势》。

2. 人工介入处理

仍以外卖平台拉取订单时数据异常的例子来说，当系统自动重试次数达到上线后，为减轻系统压力，不影响其他正常单据的处理，往往会停止自动重试，此时应允许人工介入处理。在设计人工处理异常数据时，应注意：

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

当然还要注意一点，有一种非常特殊的异常，即系统根据预设的规则对订单进行加工，但是由于规则预设错误，导致实际加工后的订单数据也错误，如在系统中预设规则，购买A商品1份，实际应发货B商品12份，但是客户运营在设置规则时，设置成：买A商品1份，实际应发货B商品120份。

此时系统不会对此单据标记异常，但是确实不符合实际，此时人工介入处理时，应允许人工标记订单异常后再进行数据修正。

仍然是上面的例子，由于预设规则的错误，导致拣货商品数量错误，进而导致拣货商品的单价等都计算错误。此时应只允许修改拣货商品的数量，而不应允许修改拣货商品的单价，拣货商品的单价应由系统进行计算。即规则是：只改异常直接导致错误的字段值，而不改间接导致错误的字段值。

四、如何提醒

上面说到，有一些异常是需要人工介入处理的，那么异常监控相关的提醒方式一般有哪些呢，我给大家简单介绍一下当前我们使用的方式：

五、业务的截停与恢复

当一个业务发生异常，可能导致后续动作无法开展时，需要截停业务。如订单数据缺失，可能造成ERP系统无法正常生成凭证，此时就应该截停通知ERP系统生成凭证的动作，等待异常解除后再恢复此动作。

对于SaaS系统来讲，传递给其他系统的数据应尽量保证正确，如果多个系统中都有此异常数据，那么异常数据的修正就麻烦多了。这就是异常监控功能设计中必须要要考虑的如何尽可能的降低异常影响的范围。

六、数据分析

一个健康的产品，功能体系设计一定是闭环的，当我们识别出异常后，需要对异常情况进行评估分析，以不断提高业务水平。发现一个问题就解决一个问题，在一个项目上发现一个问题，就只处理这个项目上发现的问题，是SaaS产品运营过程中不可取的。

我们一般需要进行数据的分析，达到以下目的：

1. 反应系统运行情况：展示该问题出现的次数，比例和趋势，作为产品的健康度的考核指标，并作为绩效考核指标对相关人员进行考核。
2. 发现现有问题：产品功能设计是否有缺陷，用户操作是否有问题，是否需要产品功能优化，是否需要进行操作人员的培训考核等，进行针对性的改进。

如对门店拣货超时这种异常情况进行分析，我们可以分析各个门店，各个区域的拣货率（拣货成功的订单/所有订单），拣货超时率（拣货超时的订单/所有订单）。

如拣货超时率一直很高，我们就要调研以下拣货超时率高的原因，是订单太多确实没法及时完成所有订单的拣货，还是门店人员不愿意或忘记点击确认拣货呢，如是第一个原因，那可以考虑多人同时拣货或拣货路径规划的功能了，如果是第二个原因，那可以考虑是否优化系统的操作体验。

七、总结

异常监控功能的设计对于新手产品经理来说是有些难度的，因为要回答监控什么，怎么监控的问题，依赖于对业务实现逻辑的清晰理解，也依赖于对运营人员处理问题过程中痛点的准确把握，故建议多咨询开发与一线的运营人员，做好需求调研和方案确认的工作，确保产品设计确实可以解决问题。

八、附录

给大家一个我整理的异常监控管理需求梳理的表格，供大家参考：

本文由 @kathic 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议