业务监控-京东物流Promise实践与探索
京东物流 冯志文约 7 分钟指标是一个被定义的数值，用来对事实进行量化和抽象。作为技术人员来说，我们需要共同考虑技术指标和业务指标。
1）技术指标
技术指标定义了服务可用率、性能TP99、调用量等技术指标。这些指标能够帮助开发人员深入了解系统的运行状态，及时发现并解决潜在问题。
虽然技术指标正常是系统稳定性的一个重要参考，但并不能完全保证业务无异常。业务异常可能源于多种非技术因素，如业务流程错误、用户需求变化、外部依赖问题、人为因素（配置错误）等。因此，在监控技术指标的同时，还需要结合业务层面的监控和分析手段，以确保全面了解和掌握系统的运行状态，从而保障业务的稳定性和可靠性。
2）业务指标
业务指标关注的是数据的正确性和完整性。业务指标的重要性不容忽视，它在系统稳定性管理和数据驱动的决策制定中扮演着关键的角色。
2.1）提前发现线上问题
通过业务指标体系，我们可以揭示系统技术问题或业务数据中的问题，提前发现并解决问题，缩短线上平均修复时长（MTTR）。
2.2）掌握业务运营规律
通过对业务指标的监控和分析，我们可以更好地理解业务运营的规律和趋势。例如，通过监控订单量、物流配送时间等指标，可以更好地规划时效和调整策略。
2.3）驱动业务运营
业务监控不仅是被动的监控和反应，还可以积极地驱动业务运营。例如，如果发现某个地区的物流配送时间长于预期，可以与物流供应商合作，优化配送路线或增加配送资源，以提高客户满意度并降低投诉率。
3）技术指标&业务指标关系
技术指标和业务监控的数据正确性通常是相互关联的。
技术指标不可用，则肯定业务指标会不可用。相反如果业务指标不可用有异常，不一定技术指标不可用。例如，如果一个系统的可用性低于SLA中定义的阈值，那么这可能会影响到业务流程的正常运行，从而导致数据错误或丢失。
1个技术指标可对应1个/N个业务指标，针对返回数据加工为业务指标可能比较简单，有些可能复杂。当然N个技术指标对应1个或者M个业务指标。
1）确定业务指标对应的价值
此阶段是搭建业务指标体系的基石，研发需要有业务的思维，对系统的业务逻辑理解越全面，指标搭建就越合理。需要深入思考以下几点？
4.【可理解】这个指标是不是很容易被你的整个团队理解呢？
指标搭建没有特别高大上的模型和理论依托，但是却有赖于深厚的积累和充分的业务理解。只要能达到反映业务真实现状，方便及时定位异常点就好。这个体系是动态的，可以随着不同阶段的业务需要不断进行更新和调整，也不断在全面和精炼中寻找平衡，避免过高的复杂度带来的冗余。
2）业务指标设计
2.1）业务指标分类
3. 派生指标：指基础指标或复合指标与维度成员、统计属性等相结合产生的指标，例如累计值、同比。
2.2）什么样的指标算一个好的指标？
1. 明确性：好的指标需要有明确的定义和计算方法，这样才能确保其可被理解和操作。
2. 可操作性：指标应能引导行动，即它应能驱动实际的操作或决策。这意味着指标的结果应当是可执行的。
3. 可比性：通过比较不同时间段或不同群体的数据，可以更好地理解业务的表现和趋势。
4. 简单性：好的指标应该是一个简单的数字，能够快速统计。
3）业务指标监控的方法与工具
同比环比法：通过和过去的自己比较，明确当前指标的水平和变化趋势。 标准差法：通过比较变化幅度与历史数据标准差，设计预警机制。 智能化的阈值预警：根据业务指标历史经验来调整不同时间段的阈值。
4）业务指标报警后跟进
收到业务指标的报警后，分析告警原因：是正常逻辑、技术代码问题、上游输入参数问题或业务配置问题。
Promise是一个对外时效承诺，对内控制订单生产节奏。
1）从用户（业务）视角，对外提供时效日历，需要监控日历天数的有效性， 日历波次的可用性。
2）从物流（仓库作业业务）视角来看，对内订单控制生产，需要监控订单的生产节奏（生产太快导致爆仓，生产太慢导致仓库作业人员无订单生产）。
1）小步快跑
业务监控刚开始摸索阶段，先干为主（实践中再模式模型抽象），先覆盖P3/P4级事故监控，逐步迭代、改进、完善。
1.1）从无到有
1.2）从有到准
2）模型完善
2.1）下单前-结算日历
2.2）下单后-订单下传率
1. 覆盖场景：业务配置数据不准（比如配提前了或者延后了）
2. 效果图如下：
|xx服务>tid=xxxx>orderId=xxxxxxxx>|transferService|-1|Tue Jan 07 00:00:00 CST 20252.3）售后-逆向取件日历
针对预约日历，监控其有效性（如是否有日期可选、日历长度是否满足、是否有可选的波次等），以帮助业务、技术及时发现系统潜在风险，有异常时快速排查。