得物技术 NOC—SLA C 端业务监控实践

前言

伴随公司业务快速发展，我们生产环境产品和应用越来越复杂，彼此连接依赖也越来越复杂；何一个应用出异常都有可能影响系统可用性，造成全局影响。通过去年 2021 年 C 端故障全年度来看，从故障发现，响应时间、故障应急有待提升，故 NOC 要优化现有的告警响应质量，制定新的 NOC——SLA 体系化，标准服务等级协议！加速响应，做到事前发现！

一、得物交易 C 端介绍

1、C 端概念

1.1 什么是 C 端

C 端指的是消费者、个人用户 Consumer；顾名思义就是面向个人用户提供服务的产品，是直接服务于用户的，得物 C 端分为两个场景“交易”“社区”两个组成，C 端包含线上交易、社区、算法，涉及到交易下的订单、出价 &库存、营销、商品，社区域前后端、算法交易推荐 &社区推荐为重要依赖。

1）交易角度

• 用户登陆游览商品详情在到支付购买，整个面向用户的交易流程就是交易 C 端业务。

2）社区角度

• 用户登陆登发帖，在到社区游览点赞、互动所产生的社交就是社区 C 端业务。

2、C 端出现问题会怎么样？

2.1 在 2021 年 6 中旬，商品服务异常由于技术问题导致订单连续下跌，影响用户下单购买体验。

• 推荐页面白屏无数据 &包括页面分类；
• 商品侧：点击商品长时间加载或该商品下架不支持销售；
• 出价 &寄存侧：商品无法出价、出价报错；
• 供应链侧：影响部分分拣拍照鉴别，以及查看商品详情页；
• 社区侧：部分社区帖子加载过慢或延时；
• 商家侧：开放平台 dop 也受到了大面积影响；

2.2 在 2021 年第四季度供应链发版中由于技术问题，代码 bug 和 redis 缓存解析异常导致交易订单当天下跌异常，影响了用户下单购买体验

• 出价 &库存：立即购买浮层打开异常；
• 创建订单 &支付订单：无法打开创建；
• 营销：调取优惠核销失败；

总结：

伴随公司业务快速发展，现在我们生产环境产品和应用越来越复杂，彼此连接依赖越来越复杂；一个应用出异常都有可能牵一发而动全身，影响全局。

二、针对 C 端历史问题-为什么要做 SLA

1、告警问题发现

1）在过去 2021 年度全年故障分析中影响 C 端故障占比全年 34.7%，C 段告警发现率只有 42%。

• 在 C 端核心链路上的告警基本上已经全部覆盖，但是在延伸到所有故障类型重大故障上，我们的告警覆盖面仍然需要提升。（监控告警零散，NOC 体系监控告警收口能力弱）在告警质量上没有有效收口。

2）从 2021 年度至今故障分析中 C 端中 NOC 的响应率从 3min-5min-15min 响应，来说所有待加强；

扫描二维码关注公众号，回复： 14189159 查看本文章

2、NOC 响应问题

在经历过去年年底一次较大资损类型 P1 故障中，NOC-在该风险告警预警后，没有第一时间判断是否上升响应延迟，导致活动延迟下线资损扩大，如以下问题：

• 值班同学关注群较多，每日处理消息过多，无法区分优先级，因此在故障发生时，值班同学会出现响应慢或错过消息等情况；
• 故障发生时，值班同学无法准确评估影响面，因此无法准确找到对应负责人等，导致故障错过最佳处理时机。
• NOC 值班同学对于 C 端业务理念不够，无法做出有效判断。

总结：

通过以上故障分析中告警问题发现率以及 NOC 在遇到重大故障判断上出现的响应问题中， 从故障发现开始到故障拉起 NOC 同学每天处理问题没有优先级，关注点散乱被动告警接受缺乏规范，在故障处理中信息分散，缺少抽象聚合，可以从点扩散到面的发现问题，监控系统对于业务的场景监控和 NOC 自身的业务场景理解投入度都有待提高。

三、SLA 整体介绍

因此 NOC—SLA 专项因此成立，统一收口接入 NOC——SLA 体系监控告警，输出 SOP，针对全司业务场景区分 P0P1 优先级，全面故障发现优化，从保障等级、受损类型、业务视角三个方面介绍 NOC-SLA 专项展开。

1、SLA 的划分

1）按照 SLA 保障等级划分

我们结合业务重要级别，故障定级标准将 SLA 保障等级分三级：P0(SLA 3 分钟)、P1(SLA 5 分钟)、P2(SLA 15 分钟)

2）按照受损类型划分

参考我们的业务受损类型，我们将 SLA 保障对象类型分为六项：业务受损，资损，基础设施，数据质量，职场效能，开发测试。说明如下：

3）业务视角划分

3.1 在业务研发视角具体分析业务受损场景如 P0 级别场景；

• 以【下单流程】业务方向举例：从商详-立即购买浮沉-提交订单-支付订单-收银台；

3.2 以运维基础设施视角分析业务受损场景如 P0 级别；

• 以【下单流程】运维基础设施举例：从用户请求-路由 internet-网关-App-业务中台；

4）SOP 定义

• 对于业务定级逻辑从新定义，自动匹配 SLA 故障场景联动一网打尽快速响应预定级
• 改变原有思路，由以前的“加法”变为“减法”，即减少 NOC 值班同学关注告警群，按照故障来源(监控告警、内部反馈、客服反馈)区分需要关注群信息，P0/P1 告警信息进行统一汇总，承诺之外消息不保障 SLA；
• 对于 SLA 业务场景增加维护人，业务相关负责人；

2、接入流程

2.1SLA 接入规范

• 在告警页完成配置后，发起 SLA 申请，由 NOC 同学在一网打尽中完成审核，通过即保障 SLA，不通过在三天内完成优化，超时直接退回。

四、NOC—C 端接入 NOC-SLA 推进

前期准备

• 在方案实施中，先了解业务场景需求，对焦场景保障等级。
• 明确核心业务指标以及相结合的依赖大盘结构。
• 接入中场景基线是否合理，明确告警规则
• 接入完成、验证历史故障。

1、业务梳理 —需求

交易 C 端包含线上交易、社区、算法，涉及到交易下的订单、出价 &库存、营销、商品，社区域前后端、算法交易推荐 &社区推荐为重要依赖，梳理了 C 端 9 个 P0 场景 17 个 P1 场景 100+的告警规则完善。

1.1 业重要等级划分

举例对于 C 端业务线，下单核心链路在下单核心场景当中区分 P0P1P2 级别优先级

• 以影响订单量为评估是否属于 P0；(商品详情、立即购买、创建订单等场景)
• 以最终引导订单下单的导购链路为 P1；(我的收藏、求购、天天领券等场景)

2、交易 C 端持续稳定性保障

交易 C 端 SLA 落地

在 SLA 专项落地阶段，我们对于 SLA 业务监控场景指标对焦完毕后，在不断的对于 C 断业务场景核心规则+触发条件编排力，对于历史故障是否能做验证反复磨合，对于不同场景不同数据指标，不断对基线计算公式打磨调优到后面开始尝试接入智能基线通过历史波动数据做基础算法模型，以确保能在 P0 场景中快速发现 P1 和 P2 故障。

2.1 C 端 SLA 基线

1）目前整个 C 端的基线配置都是根据业务业务流量历史峰值，不断的反复摸索确认

• 在确认基线前提时候，一定要思考及观察历史业务流量波动比例，在确认做用什么类型基线，在实行 SLA 阶段对于过去监控数据存在节假日波动影响往往高于历史阈值 50%如果在业务高峰时出现业务问题造成不明显下跌往往很难发现问题，需要做到每周对焦，之后我们引入智能基线。
• 取元旦节假日为例流量水平高于基线 50%异常波动比例高达 112%

• 取值范围在工作日波动比例在 20%以内符合预测范围内

2） 智能基线——Prophet 模型

• fbprophet 是 facebook 开源的一个时间序列预测算法
• 可以通过历史监控数据波动指标，运用预测算法来训练一个模型来预测未来指标走势。
• 在 NOC——SLA 中为了确保 SLA 的问题发现率、可用性、准确性，每周 NOC 同学在观察告警是否存在误报观察历史监控数据，尤其节假日交易 C 端告警流量水位普遍高于正常阈值的 50%异常，在每周二下午会偶尔出现低于基线的正常水位 25%，随着得物的业务体量不断增加及活动季节性趋势“618，双十一”不断的挑战基线的可靠性。
• 智能基线可以在较大的运算数据中预测未来预估避免节假日效应给出合理的基线数值，确保可用性及可靠性；

2.2 SLA 监控与告警优化

在监控告警配置方面，我们对于监控聚合维度升级优化，可以根据多场景，多规则不同的业务视角：应用告警-业务告警-基础资源告警整合相关联，通知告警模版更加清晰化，负责异常波动图一目了然。

1） 信息整合

• 场景确认区分上述 P0P1 场景
• 区分业务线类型及所属的业务域
• 确认该场景的规则标题“通俗易懂”：如支付订单同比基线下跌 35%
• 固定 NOC——SLA 维护人 &业务域相关负责人
• 业务的受损类型打标

2）SLA 专项监控 &告警规则——多样性

• 以下的改进了对于“去人化”判断，快速反应、消息触达联动机制迅速。

\

3）NOC—SLA 专有告警逻辑

• 对于 SLA 专项告警数据误报问题

基本描述：VM 数据延迟造成告警读取支付订单数据有误，造成支付告警误报

影响描述： P0-SLA-3m 告警规则 “支付订单比例同比基线下跌超 35%”因数据延迟问题出现误报

告警显示波动比例为 40%，但所带监控截图和跳转监控地址均无异常波动。

优化： 原定告警检测时间点位为 12S，发现 12S 仍存在数据齐全度问题，易造成误报，现关闭 12S 的时间检测点位，切换为 20S 检测点（20S 为新增测试点位，并非最终点位） ，预期切换后告警延迟在 25-30 秒左右， 后公式出 NOC—SLA 专有告警逻辑（通过计算公式获取的值与阈值进行大小比较，阈值不需要没有负数，只有正数，上升和下降通过比较符确认，比如环比下降 30，告警会自动处理正负号的逻辑）

• 老的告警逻辑 30 秒评估一次，防止告警噪音查询数据向前推 1 分钟，告警引擎会对告警进行去重、合并、抑制等路程大概 50 秒，整个流程会延迟 2 分多钟

3、SLA 保鲜准确性：保鲜方式 &保鲜对象

• 业务链路的保鲜

1. NOC&业务对焦

• 以月度为单位跟业务方复盘总结对焦 SLA 目前健康状况提高“售后服务”
• 对焦业务迭代是否发生信息变化 （新上营销活动、拍卖项目、可能会对 P0P1 场景定义，业务迭代后有新的变化，需要对原来定义监控、NOC 值班、应急、相应调整）

2. NOC 指标链路数据正确性维护

• 定期梳理梳理（交易 C 端）场景业务指标链路数据正确性，做到场景依赖发现全；
• SLA 告警优化

3. 故障 &冒烟点 SLA 问题发现率分析优化

• 按照故障 &冒烟中是否是 SLA 发现？其它告警发现？用户 &员工反馈等来不断完善提高 SLA 告警问题发现率“不误杀”

4. SLA 告警优化

• 根据每周 SLA 告警质量监控分析告警触发率在哪个时间节点出现突增去分析原因做到告警闭环“有理有据”，增加准确性，减少告警噪音，收敛。 比如：低交易时段，秒杀抢购等活动导致订单突增，出现监控毛刺的波动产生告警以此来做问题记录告警归类。

4、 NOC 加速应急

SLA 应急流程规范优化

1）NOC—SLA 落地后经过审核后，加入 SOS（故障应急系统），出现 SLA 指标下跌后联动 SOS 快速应急一键发送；

2）增加应急小组，包含 NOC 二组/专家组，用于应急中引导加快故障快速恢复；

3）故障自动升级机制，根据故障新版定级为基础判断自动匹配 1min 自动拉群同步现有故障信息概览；

五、落地实践故障发现

1、告警及时性

2、准确性和有效性

• 今年 2 月份社区的穿搭精选服务展示异常故障，因为资源计算新增代码 bug 故障中，我们根据场景关联化，基于基线合理性和 SLA 告警配置的多样性，发现了之前未发现的故障现象，当时线上所有告警无异常。

3、值班提升

1. 在 3/2【冒烟点】购买首页/商详/立即购买 QPS 跌，RT 飙升 阿里云杭州地区(可用区 I )网络设备发生异常，通过 SOS 预定级与 NOC—SLA 联动自动匹配相应故障场景定级自动发出去人化 5 分钟快速响应 ；

2. 用户 &员工反馈建设 TS&NOC 上报标准流程，加强得物 App 用户反馈渠道；

3）减少盯群，收敛群，减少打扰，让 NOC 值班人更专注在有限的重点飞书群；

总结与展望

在我们经历过多次大额资损类故障中和影响业务可用性严重性故障后，我们回顾总结怎么从应急保障中做到快速响应，事前预警后。由被动变主动，向全员承诺发起 NOC-SLA 保障专项，痛定思痛下定决心将告警发现、处理、止血，定下 P0(SLA 3 分钟)、P1(SLA 5 分钟)、P2(SLA 15 分钟)为目标力争上游。同时梳理各业务域应用等级业务链路场景分成级，从告警聚合、联动 SOS 故障快速拉起，目前在交易 C 端落地了 9 大核心 P0 场景 17 个 P1 场景，但是还不够好，要不断“保鲜”才能做到可持续性，准确性，可靠性。

从冒烟发现的角度来说，我们要不断的打磨 NOC—SLA 增强告警延展性，可观测场景不断扩大深挖 P1 以下场景，着力从预防角度来说做到事前发现防止能预见的问题，快速恢复不能预防问题，避免小问题大故障，还有很长的路要走，目前做到 3min-5min-15min 快速响应，朝着业内阿里 1min-5min-10mi 定位和快速恢复能力前进，为得物稳定生产助力！

文/木鱼耗子

关注得物技术，做最潮技术人！