原创｜得物技术-木鱼耗子

前言
伴随公司业务快速发展，我们生产环境产品和应用越来越复杂，彼此连接依赖也越来越复杂；何一个应用出异常都有可能影响系统可用性，造成全局影响。通过去年2021年C端故障全年度来看，从故障发现，响应时间、故障应急有待提升，故NOC要优化现有的告警响应质量，制定新的NOC——SLA体系化【】‘’‘’‘拍拍拍拍拍拍拍拍拍拍拍；1. 得物交易C端介绍

1.1 C端概念

什么是C端？

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

从交易角度看：

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

从社区角度看：

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

1.2 C端出现问题会怎么样？

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

• 推荐页面白屏无数据&包括页面分类；

• 商品侧：点击商品长时间加载或该商品下架不支持销售；

• 出价&寄存侧：商品无法出价、出价报错；

• 供应链侧：影响部分分拣拍照鉴别，以及查看商品详情页；

• 社区侧：部分社区帖子加载过慢或延时；

• 商家侧：开放平台dop也受到了大面积影响；

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

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

1.3 小结

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

2. 针对C端历史问题-为什么要做SLA

2.1 告警问题发现

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

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

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

2.2 NOC响应问题

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

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

2.3 小结

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

3. SLA整体介绍

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

3.1 SLA的划分

（1）按照SLA保障等级划分

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

（2) 按照受损类型划分

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

(3) 业务视角划分

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

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

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

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

（4）SOP定义

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

3.2 接入流程

SLA接入规范

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

4. NOC—C端接入NOC-SLA推进

前期准备

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

4.1 业务梳理 —需求

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

业重要等级划分：

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

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

4.2 交易C端持续稳定性保障

交易C端SLA落地

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

4.2.1 C端SLA基线

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

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

• 取元旦节假日为例流量水平高于基线50%异常波动比例高达112%
•  

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

（2） 智能基线——Prophet模型

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

4.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分多钟。

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

4.3.1 业务链路的保鲜

（1）NOC&业务对焦

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

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

定期梳理梳理（交易C端）场景业务指标链路数据正确性，做到场景依赖发现全。

4.3.2 SLA告警优化

（1）故障&冒烟点SLA问题发现率分析优化

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

（2）SLA告警优化

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

4.4 NOC加速应急

SLA应急流程规范优化

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

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

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

5. 落地实践故障发现

5.1 告警及时性

5.2 准确性和有效性

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

5.3 值班提升

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

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

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

6. 总结与展望

在我们经历过多次大额资损类故障中和影响业务可用性严重性故障后，我们回顾总结怎么从应急保障中做到快速响应，事前预警后。由被动变主动，向全员承诺发起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定位和快速恢复能力前进，为得物稳定生产助力！

*文/木鱼耗子

关注得物技术，每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～