作者：京东物流 冯志文
一、业务监控的意义
指标是一个被定义的数值，用来对事实进行量化和抽象。 作为技术人员来说，我们需要共同考虑技术指标和业务指标。
1）技术指标
技术指标定义了服务可用率、性能TP99、调用量等技术指标。这些指标能够帮助开发人员深入了解系统的运行状态，及时发现并解决潜在问题。
虽然技术指标正常是系统稳定性的一个重要参考，但并不能完全保证业务无异常。业务异常可能源于多种非技术因素，如业务流程错误、用户需求变化、外部依赖问题、人为因素（配置错误）等。因此，在监控技术指标的同时，还需要结合业务层面的监控和分析手段，以确保全面了解和掌握系统的运行状态，从而保障业务的稳定性和可靠性。
2）业务指标
业务指标关注的是数据的正确性和完整性。业务指标的重要性不容忽视，它在系统稳定性管理和数据驱动的决策制定中扮演着关键的角色。
1）提前发现线上问题
通过业务指标体系，我们可以揭示系统技术问题或业务数据中的问题，提前发现并解决问题，缩短线上平均修复时长（MTTR）。
2）掌握业务运营规律
通过对业务指标的监控和分析，我们可以更好地理解业务运营的规律和趋势。例如，通过监控订单量、物流配送时间等指标，可以更好地规划时效和调整策略。
3）驱动业务运营
业务监控不仅是被动的监控和反应，还可以积极地驱动业务运营。例如，如果发现某个地区的物流配送时间长于预期，可以与物流供应商合作，优化配送路线或增加配送资源，以提高客户满意度并降低投诉率。
3）技术指标&业务指标关系
技术指标和业务监控的数据正确性通常是相互关联的。
技术指标不可用，则肯定业务指标会不可用。相反如果业务指标不可用有异常，不一定技术指标不可用。 例如，如果一个系统的可用性低于SLA中定义的阈值，那么这可能会影响到业务流程的正常运行，从而导致数据错误或丢失。
1个技术指标可对应1个/N个业务指标，针对返回数据加工为业务指标可能比较简单，有些可能复杂。当然N个技术指标对应1个或者M个业务指标。
二、业务指标体系搭建的基本流程
1）确定业务指标对应的价值
此阶段是搭建业务指标体系的基石，研发需要有业务的思维，对系统的业务逻辑理解越全面，指标搭建就越合理。需要深入思考以下几点？
【有价值】 你的应用&服务接口的核心价值是什么？这个指标可以体现这种价值吗？
【可度量】 这个指标是不是可以判断接口数据的准确性？可以提前发现系统或者业务配置问题。
【可操作】 这个指标是不是一个可操作的指标？如果一个指标变坏，你什么也做不了，那它对你来说相当于不存在
【可理解】 这个指标是不是很容易被你的整个团队理解呢？
指标搭建没有特别高大上的模型和理论依托，但是却有赖于深厚的积累和充分的业务理解。只要能达到反映业务真实现状，方便及时定位异常点就好。这个体系是动态的，可以随着不同阶段的业务需要不断进行更新和调整，也不断在全面和精炼中寻找平衡，避免过高的复杂度带来的冗余。
2）业务指标设计
2.1）业务指标分类
业务指标可以根据其性质和用途被分类为：
1.基础指标：这是最基本的指标，业务实体原子量化属性的且不可再分的概念集合
2.复合指标：指建立在基础指标之上，通过一定运算规则形成的计算指标集合
3.派生指标：指基础指标或复合指标与维度成员、统计属性等相结合产生的指标，例如累计值，同比
2.2）什么样的指标算一个好的指标？
1.明确性：好的指标需要有明确的定义和计算方法，这样才能确保其可被理解和操作。
2.可操作性：指标应能引导行动，即它应能驱动实际的操作或决策。这意味着指标的结果应当是可执行的。
3.可比性：通过比较不同时间段或不同群体的数据，可以更好地理解业务的表现和趋势。
4.简单性：好的指标应该是一个简单的数字，能够快速统计。
5.可监控性：业务指标需要有明显的规律可循，具有监控意义。
3）业务指标监控的方法与工具
在业务指标建设这个过程中，我们更多的是从使用者（用户、一线业务运营） 这个视角去看监控。常用的业务指标监控方法
•同比环比法：通过和过去的自己比较，明确当前指标的水平和变化趋势。
•标准差法：通过比较变化幅度与历史数据标准差，设计预警机制。
•智能化的阈值预警：根据业务指标历史经验来调整不同时间段的阈值。
4）业务指标报警后跟进
收到业务指标的报警后，分析告警原因：是正常逻辑、技术代码问题、上游输入参数问题或业务配置问题。
三、用户(业务)视角关注什么
Promise是一个对外时效承诺，对内控制订单生产节奏。
1）从用户（业务）视角业务图如下，对外提供时效日历，需要监控日历天数的有效性， 日历波次的可用性。
2）从物流（仓库作业业务）视角来看，对内订单控制生产，需要监控订单的生产节奏（生产太快导致爆仓，生产太慢导致仓库作业人员无订单生产）
四、实践落地-迭代完善
1）小步快跑
业务监控刚开始摸索阶段，先干为主（实践中再模式模型抽象），先覆盖P3/P4级事故监控，逐步迭代、改进、完善。
1.1）从无到有
构建一个有效的业务指标是一个循序渐进的过程。下图是一个监控数据同步成功率的业务指标，由于存在入参异常等噪音数据，导致成功率波动较大，起初并不具备监控意义。
1.2）从有到准
经过对异常数据的分析归类，通过结果列列值翻译功能，将与业务无关的异常映射为成功，去除干扰因素后，该指标变得基本稳定，具有监控意义。
去除干扰数据后，该指标变得基本稳定，具有监控意义。
2）模型完善
2.1）下单前-结算日历
日历做业务监控比较早，之前是用的pfinder监控的，效果图如下
2.2）下单后-订单下传率
1）覆盖场景：业务配置数据不准（比如配提前了或者延后了）
2）效果图如下：
3）最终打印的业务监控日志如下：
|xx服务>tid=xxxx>orderId=xxxxxxxx>|transferService|-1|Tue Jan 07 00:00:00 CST 20255）监控配置如下：
2.3）售后-逆向取件日历
对外界面如下：
针对预约日历，监控其有效性（如是否有日期可选、日历长度是否满足、是否有可选的波次等），以帮助业务、技术及时发现系统潜在风险，有异常时快速排查。
监控如下
3）京ME直达一线业务
描述：当门店某个波次的订单量在其预设产能的120%以内时视为正常波动，而超出这个值则需要及时告知仓库/门店 具体运营同学进行调控。
设计：
五、常见误区
1. 指标太多
业务监控的目的是发现问题，而不是指标越多越好
2、指标定义不清楚
事实上指标的定义没有绝对的正确和错误，只要基于实际业务问题，确定好统计口径，团队理解一致，这个指标就是可取的。所以对于一些界定不够清晰，不能被团队一眼理解的指标，最好再追加基本的解释。
案例：大家都知道看似简单的DAU，其实也可以有不同的定义。什么是活跃？最常见的定义是，打开应用即算活跃。有些应用是登录或者停留才算活跃。那么DAU的定义是登陆你的app or 停留时长达到一分钟 or 有特定行为？其实都可以，只要团队一致认可且能反映产品的核心价值。
3、宁少勿滥
在不影响完整性的情况下，能少则少，能用一项指标说明问题绝不用两项。
4、业务监控指标需要快速定位问题
别业务监控报警出来了，但无法快速定位问题，那这业务监控指标的意义就大打折扣了，故设计业务监控指标的时候，一定要思考，我这业务监控指标报警了，我如何快速定位问题，比如业务监控日志需要 打印，订单、以及全链路traceid，仓库，四级地址、错误码等关键信息。一遇到报警查看业务监控日志可快速定位
5、业务监控指标代码 不要影响技术可用率
千万别应用添加业务监控代码，而导致系统技术本身问题。比如业务监控抛异常等，故我是要求团队业务监控代码必须catch异常，不能影响现有代码逻辑
六、未来规划
1.优化现有业务指标： 我们将继续精细化打磨现有的业务指标，确保报警系统能够更加快速、准确地响应，提升整体效率和可靠性。
2.构建外单链路业务指标：我们计划建设和完善外单链路的业务指标体系，以全面监控和分析外部订单链路的运行情况。
