基于大模型思维链的SRE智能化服务检查体系构建
子车轻罗 2025/3/16 SREdevops
# 背景
# 需求输入
xx群控服务上线，上线完成后，未进行服务检查，CPU全部打满，业务也不知道，运维介入反推后才发起回滚。暴露出服务变更后，服务检查的必要性和重要性，同时又不能纯依靠人挨个维度逐渐检查，需要有平台能力，上线之后只需告诉他一个结论即可
xx服务，上线约20分钟后，内存打满，导致服务通信行为异常，更换容器规格后服务恢复
xx服务，上线后成功率下降且持续劣化，没有恢复迹象
# 现状分析
当前服务健康度检查作为通用监控手段，主要依赖多维度指标数据进行阈值比对和异常检测。该模式存在以下技术瓶颈：
- 实现成本高：需大量定制化编码支持差异化业务场景
- 扩展性受限：个性化需求需二次开发迭代周期长
- 专家知识转化效率低：SRE领域知识难以系统化沉淀
# 技术突破点
DeepSeek-R1大模型在复杂逻辑推理任务中展现出的卓越性能，为SRE运维智能化提供了新范式。其核心创新在于：
- 思维链（Chain-of-Thought）能力：可模拟人类专家的递进式分析逻辑
- 多模态数据处理：支持结构化指标与非结构化日志的联合分析
- 因果推理能力：超越传统关联性分析，实现根因定位
# 实现思路
# 解决方案架构
构建基于大模型的SRE智能运维系统，实现以下技术闭环：
- 传统流程：专家经验 → 产品设计 → 代码开发 → 产品落地
- 革新流程：专家经验 → 知识建模 → 低代码编排 → 智能决策
# 核心组件设计
- 知识工程层
- 构建SRE领域知识图谱，包含故障模式知识库、监控指标关联网络、服务健康度映射模型、指标基线管理体系
- 故障模式知识库
- 历史故障场景
- 故障特征及影响范围
- 监控指标关联网络
- 建立指标间依赖关系图谱
- 多指标联动决策
- 历史同环比数据对比决策
- 服务健康度映射模型
- 量化指标异常与服务状态的映射关系，抽象出无风险、低风险、中风险、高风险4种等级
- 引入业务特征，根据业务特征微调风险等级
- 指标基线管理体系
- 建立动态安全水位阈值模型
- 支持多维度基线自适应调整
- 故障模式知识库
- 构建SRE领域知识图谱，包含故障模式知识库、监控指标关联网络、服务健康度映射模型、指标基线管理体系
- 推理引擎层
- 基于CoT的逻辑判断
- 基于示例的快速学习及推理强化
- 基于预定义格式的推理结果展示
- 执行编排层
- 前置数据降噪
- 低代码运维流程编排
- 自动化处置策略生成
# 关键技术创新
- 思维链注入机制
- 将SRE诊断流程转化为结构化思维链模板
- 通过Few-shot Learning实现推理模式迁移
- 动态知识更新
- 根据实际清楚持续优化prompt以优化决策准确率
- 检查结论入库，作为历史回溯使用，减少告警噪音
- 分析报告结构化规范
- 结论先行：采用金字塔原理组织内容，核心结论前置，关键发现优先展示，建立清晰的逻辑层级结构
- 分析过程：指标关联逻辑分析，系统行为分析
- 数据支撑：量化指标对比分析
- 历史case验证：同类故障模式匹配，历史案例对比
# 指标计算
- 变更前10分钟均值
- 环比前一天，前一周同时刻数据
# 架构设计
# 服务架构
# 模型设计
实例E-R关系图：主要分为服务检查模板、服务检查任务、检查项模板、检查项
服务检查模板：服务检查通过服务检查模板建立检查任务，模板定义了接入方、回调接口、检查项模板、同步/异步/同步非阻塞的通知方式、检查方式(正相关、泛相关)
检查项模板：定义检查类型是正相关、泛相关检查各自包含的检查项及检查范围
检查项：定义每项检查指标、数据来源、阈值、比对方式
检查任务：定义任务id、任务状态、检查结果、检查详情
接入方可以根据自己变更特点，创建服务检查模板，服务检查模板需要关联检查项模板，检查项模板用来定义使用至少1种检查方式(服务自身、网关F0接口等)，不同的检查方式检查项是不同的(cpu、接口成功率等)，可以自定义至少1种检查项(指标、阈值)。
实体服务检查模板：接入方调用服务检查，首先需要明确自己的场景类型，根据场景选择适合的模板传参，同时根据自己的场景选择检查方式，当前默认两种模板，分别对应正相关与泛相关的场景。
检查项模板：检查项模板和服务检查模板关联，默认生成两种模板。
服务检查任务：发起方发起检查任务，系统创建JobID(根据用户类型+工单id+时间戳生成)，按照对应模板类型继续后续流程，并更新状态(待执行、执行中、执行完成、执行失败)
检查项：每种指标都需要关联数据源、比对类型(计算方式)，根据阈值进行比对。
# 规范设计
# 接入规范
检查目标*：**
正相关：集群(zns形式或ns、服务、集群根据指标数据源来决定)**
泛相关：网关全量F0接口、qa巡检
时间范围**：**
变更开始时间和结束时间
如果没有明确的时间默认为收到调用前10分钟为开始时间，后5分钟为结束时间。
结果返回**：**
- 异步，用户需要给出回调地址
- 返回集群每个检查指标的详细记录，指标检查通过数量和不通过数量。
# 异常判定
| 指标 | 变化类型 | 阈值 | 备注 |
|---|---|---|---|
| 接口入向成功率 | 下跌 | 10% | |
| 接口入向时延 | 上升 | 30% | |
| 接口入向流量 | 下跌 | 30% | |
| CPU使用率 | 上升 | 20% | |
| 内存使用率 | 上升 | 20% |
注：以上指标为一个集群所有pod或所有接口平均值
对比开始时间：变更前1分钟
对比结束时间：变更完成后2分钟(需要关注监控数据的生产速度延迟大小)
判定规则：变更后的时间与变更前30分钟指标的平均值进行对比，检查指标中有一项不通过即为异常。
# 应用场景
- CD(代码上线、配置上线)
- 服务更新编排
- 路由变更
- 服务迁移
# 检查规范
目标：固定为一个完整的集群，如project-onk8s.op.qcvmbj6-docker
变更开始时间：10位时间戳
变更结束时间：10位时间戳
变更人：字符串
回调接口：首次接入提供
app_name：接入方标识，首次接入分配。
检查类型：服务类默认为正相关，首次接入配置
# 常用的统计量
| 统计量 | 描述 | 结论 | 备注 |
|---|---|---|---|
| 平均值 | 将所有数值相加，然后除以数值的数量，得到平均值。 | 适用 | 容器把突增、突降变化降低，阈值不能设置过大 |
| 中位数 | 将所有数值按照大小排序，取出中间位置的数值作为中位数。如果数值的数量为偶数，则取中间两个数值的平均值作为中位数。 | 适用 | |
| 众数 | 数据集中出现次数最多的数值。 | 不适用 | |
| 极差 | 数据集中最大值和最小值之间的差值。 | 适用 | 无论指标突增突降，插值都可反映出变化 |
| 求和 | 将所有数值相加，得到求和值。 | 不适用 | 变更前后数据点数量不对等 |
| 最大值或最小值 | 取出所有数值中的最大值或最小值作为结果。 | 不适用 | 无法解决当前问题 |
| 百分位数 | 将数据点按大小排序后，按照百分比划分为不同的部分 | 适用 | 和中位数类似 |
| 方差 | 每个数据点与平均数之差的平方的平均值。 | 不适用 | |
| 标准差 | 方差的正平方根。 | 不适用 | |
| 相关系数 | 用于描述两个变量之间线性关系的统计量。 | 不适用 | |
| 四分位数 | 将数据点按大小排序后分成四份，第一份的最大值为第一四分位数，第二份的最大值为第二四分位数，第三份的最大值为第三四分位数。 | 不适用 | |
| 正态分布参数 | 包括均值和标准差，用于描述正态分布的形态和特征。 | 不适用 | |
| 比率或百分比 | 将某个数值除以总数值，然后乘以100，得到比率或百分比 | 不适用 |
# 泳道图
# Prompt
# 目标：根据给出的监控数据，按照上下文给出的格式，判断风险的等级(高风险，中风险，低风险，无风险)。
# 要求：根据下面给出的思考过程及判断逻辑，结合监控数据分析风险级别并形成自己的思维链；要优先理解判断逻辑，其次通过分析案例来丰富判断依据；
# 任务分解：
1.提取信息：学习监控数据格式及每个字段代表的含义能够正确提取信息
2.了解指标作用：学习每个指标的说明能够正确理解指标的重要程度以及对风险等级判定的影响
3.判断条件：学习判断条件作为判断依据，重点学习不同指标组合时的关联关系以及可能出现的问题
4.案例学习：根据给出的案例结合(判断条件)深度分析，理论与实践结合，判断条件作为方法论指导，也要结合实际情况来灵活判断。
# 提取信息：
1.提取时间：start_time为服务开始变更的时间，end_time为服务结束变更的时间，monitor_start_time为监控采集的开始时间，monitor_end_time为监控采集的结束时间。
2.提取集群：cluster为本次变更的服务集群，也是本次监控指标的主体
3.提取数据：history_data是一段服务正常表现的数据，称之为变更前的数据，用于参考对比；assessment_data为待评估对比的数据，通常称之为变更后的数据，需要把assessment_data的数据与history_data的数据每一项进行对比，从而得出本次服务变更的风险等级。history_data和assessment_data数据结构相同。
4.提取检查指标，检查指标在history_data和assessment_data中，拥有一个或多个检查指标，以json数组形式展示，data对象中的key是监控指标，value是一个数组，包含一组监控值，每个值间10s。
5.提取唯一id：job_id是本次任务的id
6.提取预算单元：budget_unit是预算单元，相同的预算单元可能存在相似的现象，比如大数据，题库，检索可能在代码上线时因重启经常cpu和内存和时延突增突降但很快会恢复，又比如直播课相关的预算单元，18:00-22:00经常有流量突增，时延增大，又比如用户产品，经常会有成功率维持在一个低水位。
# 了解指标作用：
1.指标说明：成功率是最关键的指标，正常情况是100，成功率**突然** **大幅度**下降直接影响服务质量如突降20或持续劣化，一般为高风险，但某些服务存在长期成功率不高的情况则为低风险，所以需要结合历史数据评估是否是突然大幅度下降。成功率的微小抖动不管流量高低都可忽略影响，成功率较大的抖动在流量低关注度或不关注度的场景可以酌情忽略。成功率下降较低时(参考值:<5)为低风险。
2.指标说明：时延通常单纯的升高为无风险，因为时延可能会抖动，如果时延增大了几倍并且超过了一个较大的值(参考值:1000)就是低风险，如果一直持续没有恢复并且伴随成功率中幅下降(参考值:>6)就是中风险，如果恢复了则无风险，原因可能是服务负载高，也可能是服务有变更，但是，有的服务可能是传输大量数据或执行复杂逻辑常态下就是超过1000的，所以需要结合历史同期数据来对比。
3.指标说明：流量为参考指标，需配合其他指标综合观察，不单独作为判断依据。正常的流量趋势有以下几种：正常的流量潮汐导致的波峰波谷，一般为日级别，今天的同一时段和昨天的同一时段可能相差不大；分钟级的波峰通常是定时任务的流量特征;节假日级别的波峰波谷需结合日期对应其节假日，流量可能升高也可能降低；周级别的波峰波谷通常体现在周末比工作日流量或高或低。高关注度流量值(参考值:>500),正常流量值(参考值:>100),低关注度流量值(参考值:20-80),不关注流量值(参考值:<20)小于20直接判定为无风险；
4.指标说明：cpu使用率数值应低于安全水位(参考值:80)，，对于流量潮汐分明的业务来说这是一个比较安全的水位，**但并非超过安全水位就是高风险**，需要结合历史同期数据和变更前来看是否为常态现象，cpu是可压缩资源和内存不同，某些情况下会超过安全水位甚至跑满，可能得原因有：定时任务导致的周期性的突增突降这种风险较低；流量突增导致的风险较高；训练任务型的业务通常会有相当一段时间数值都处于高位并且流量，时延很低，有周期性的特点
5.指标说明：内存正常数值应低于安全水位(参考值:80)，内存可能会抖动，超过安全水位不能说明一定有风险，需要结合历史数据看是否长期以来就是这样，还要看变更前数据，如过变更前数据也已经超过则表示并非本次变更导致的，所以风险等级应该降低，如大模型训练，大数据，redis等服务重启时会出现内存升高。但如果超过警戒水位(参考值:95)并且持续未恢复则有风险，内存打满会触发系统OOM，无论什么原因都应定义为高风险。
# 判断条件
1.饱和度判断：CPU：指标表现：CPU利用率持续高水位（参考值:80)，关联影响：可能导致时延上升；内存：内存利用率持续高于高水位（参考值:80)，关联影响：内存不足可能导致服务崩溃或响应变慢。前提是历史同期或变更前并非处于高水位才是高风险，否则应降低风险评级
- 注意：cpu和内存下降无风险，资源饱和度主要关注的是增长而非下降。
2.流量判断：当流量值超过一般的值小于20时，可直接判定为无风险。流量突增：指标表现：流量显著超过历史基线，可能伴随资源利用率（如CPU、内存）同步上升，关联影响：若系统未及时扩容，可能导致时延增加或成功率大幅度下降；流量突降：指标表现：流量显著低于历史基线，可能由上游服务故障、网络中断或客户端异常引起。关联影响：可能某条链路中断导致流量未传递，或者下线了某个接口。
3.成功率判断：成功率突降：指标表现：成功率大幅度低于100并且成功率显著低于历史基线，关联影响：CPU突增或内存突增或时延增大或流量突增。同时满足成功率>98和流量平稳则为无风险，不需要看其他指标.
4.时延判断：平均延迟增加：指标表现：时延最后3个数据点相比历史数据上升一倍并且超过一个较大的值(参考值:1000ms)。并且持续未恢复。原因可能由资源竞争（如数据库锁）、慢查询或依赖服务延迟导致。关联影响：cpu突增或内存突增或成功率大幅度下降或流量增长。如果延迟最后3个数据点未显著高于历史数据则即使之前的数据点高于历史数据也是无风险。
5.场景判断：容量不足的表现有资源饱和度增长如cpu突增或内存突增，时延变大，流量突增，成功率突然大幅度降，通常为高风险，如果抖动后恢复则为低风险
6.场景判断：变更有问题的表现有成功率大幅度下降，时延上升，流量受成功率大幅度下降导致增加重试流量，资源饱和度可能有变化但只要不是持续在90以上一般不会有问题，通常为低风险，如果成功率大幅度突降(参考值:20)并且持续劣化未能恢复则为高风险
7.场景判断：下游服务故障的表现有成功率抖动，时延上升，流量轻微上升(一般是流量积压或重试)，以上3个条件都符合通常为中风险，如果成功率大幅度突降(参考值:20)并且持续劣化未能恢复则为高风险，否则为低风险
8.场景判断：周期性任务的表现有每隔固定周期(参考值:5分钟)通常环比前一天同时间会有相同表现，流量，资源饱和度都会持续上涨一段时间后恢复到之前的水位，只要成功率没有下降，通常为无风险
9.场景判断：服务抖动：cpu，内存，时延突增后恢复，流量，成功率没有太大变化，通常为低风险
10.场景判断：业务正常表现：除流量外其他指标均无太大波动，通常为无风险
11.场景判断：服务重启：cpu、内存、成功率、时延、流量数值会有增加或降低，最终与变更前的数值相差不大，通常为无风险
# 案例学习
-----案例1 start-----
输入：'''{"job_id":209423477,"cluster":"polyflow-infer-worker-n.asr.qcvmbj6-docker","end_time":"2025-04-21 16:21:14","start_time":"2025-04-21 16:21:14","budget_unit":"智能中台AIGC-推理","history_data":[{"data":{"cpu":[0.77,0.62,0.98,0.79,0.43,0.65,3.98,13.55,15.99,8.57,6.69],"内存":[24.55,24.55,24.7,24.7,24.7,24.7,27.54,29.98,32.32,32.32,35.4],"mesh时延":[0.25,0.31,0.29,0.09,0.58,0.45,0.49,0.53,0.43,0.75,0.64],"mesh流量":[0.8,1,0.9,0.4,0.7,1,1.6,1.3,1.5,1.9,1.8],"mesh成功率":[87.5,90,88.89,75,85.71,90,68.75,61.54,66.67,68.42,61.11]},"monitor_end_time":"2025-04-21 16:21:14","monitor_start_time":"2025-04-21 16:16:14"},{"data":{"cpu":[9.31,9.5,9.28,9.07,8.75],"内存":[40.86,40.86,40.86,40.86,40.86],},"monitor_end_time":"2025-04-20 16:23:14","monitor_start_time":"2025-04-20 16:21:14"}],"assessment_data":{"data":{"cpu":[6.69,18.4,13.51,6.34,2.4,5,6,5,4,12,13],"内存":[35.4,37.4,35.07,31.58,31.59,33,50,34,40],"mesh时延":[64,162,148,206,500,1200,1500,500,200,100],"mesh流量":[1.8,1.1,0.9,0.9,0.3,5,7,13,2,1],"mesh成功率":[100,100,80,87,61.11,72.73,66.67,66.67]},"monitor_end_time":"2025-04-21 16:23:14","monitor_start_time":"2025-04-21 16:21:14"}}
'''
思考：'''
流量数值有超过三分之二的数据值<20即属于不关注区间，可直接判定为无风险，因此结论是：无风险
'''
输出：无风险
-----案例1 end------
-----案例2 start-----
输入：'''
{"job_id":218065406,"cluster":"gptserver.aiessay.qcvmbj6-docker","end_time":"2025-05-15 15:43:37","start_time":"2025-05-15 15:33:37","budget_unit":"AI快问应用","history_data":[{"data":{"cpu":[15.095,15.214,15.177,15.288,15.264,15.143,14.917,14.79,14.764,14.586,14.468,14.482,14.405,14.484,14.561,14.943,15,15.152,15.329,15.152,15.193,15.155,15.097,14.877,14.941,14.942,14.801,14.733,14.707,14.653,14.52],"内存":[15.447,15.205,15.445,15.48,15.416,15.353,15.388,15.333,15.357,15.442,15.312,15.308,15.319,15.342,15.284,15.321,15.353,15.295,15.189,15.409,15.264,15.351,15.418,15.357,15.313,15.22,15.257,15.338,15.224,15.17,15.315],"mesh时延":[1047,1180,1072,1071,1019,1172,938,1004,971,1043,1005,928,1033,866,1064,962,1038,1108,1063,898,1118,925,1031,1083,1001,1214,1053,964,826,1035,1147],"mesh流量":[284,280.7,280.9,279.2,279.5,286.7,295.6,269,295.9,315.4,305.8,311.6,295.7,306.5,309.5,304.1,304.8,286.7,291,311.5,285.3,286.8,285.2,281.8,273.9,281.6,292.8,276.8,310.9,279.4,285.5],"mesh成功率":[100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100]},"monitor_end_time":"2025-05-15 15:33:37","monitor_start_time":"2025-05-15 15:28:37"},{"data":{"cpu":[12.252,12.296,12.397,12.479,12.576,12.752,13.015,13.022,12.945,12.962,13.098,13.03,12.927],"内存":[13.93,14.056,14.043,14.039,14.012,14.092,14.046,14.06,13.996,14.031,14.04,14.009,14.01],"mesh时延":[844,1043,957,897,1019,959,1002,1104,877,972,1112,940,919],"mesh流量":[265.7,281.1,264.3,277.4,282.4,288.7,288,250.6,281,282.5,286,278.3,300.7],"mesh成功率":[100,100,100,100,100,100,100,100,100,100,100,100,100]},"monitor_end_time":"2025-05-14 15:45:37","monitor_start_time":"2025-05-14 15:43:37"}],"assessment_data":{"data":{"cpu":[11.236,9.964,7.367,7.532,7.938,7.476,6.743,6.33,6.077,5.945,6.092,6.013,6.069],"内存":[14.75,12.949,11.583,11.82,12.095,8.218,6.183,6.243,6.267,6.292,6.313,6.381,6.426],"mesh时延":[596,7916,9733,7433,19289,449,429,489,468,514,424,472,532],"mesh流量":[290.7,296.7,311,318.9,293.6,318,304.2,298.8,296.3,302.3,331.9,305.9,311.9],"mesh成功率":[99.897,99.225,99.26,99.31,95.012,88.182,78.014,87.929,94.123,99.008,99.036,99.15,99.038]},"monitor_end_time":"2025-05-15 15:45:37","monitor_start_time":"2025-05-15 15:43:37"}}
'''
思考：'''
变更后的时延数据先偏离历史均值，超历史基线18倍存在多个超1000ms的异常值，但最后至少3个数据点重新接近历史均值，属于变更后正常恢复的表现，无风险；成功率最终重回变更前或历史均值，无风险；资源饱和度未超过安全水位，无风险；因此结论为无风险
'''
输出：无风险
-----案例2 end-----
-----案例3 start---
输入：'''
{"start_time":"2025-03-31 17:55:00","end_time":"2025-03-31 18:00:00","job_id":177987,"cluster":"tiku-formula.tiku.qcvmbj6-docker","budget_unit":"","history_data":[{"monitor_start_time":"2025-03-31 17:50:00","monitor_end_time":"2025-03-31 17:55:00","data":{"cpu":[5.75,5.78,5.86,5.89,5.79,5.73,5.79,5.94,5.98,6.01,6.2],"mesh成功率":[97.55,98.59,97.64,98.7,97.69,96.22,97.07,98.07,97.91,94.36,97.8],"mesh时延":[0.19,0.19,0.18,0.17,0.18,0.19,0.2,0.18,0.2,0.19,0.2],"mesh流量":[1353.5,1329.1,1359.4,1311.5,1346,1337.1,1322.3,1354.4,1360.9,1456.7,1391],"内存":[8.89,8.9,8.89,8.94,8.91,8.96,8.9,8.89,8.91,8.9,8.93]}},{"monitor_start_time":"2025-03-30 18:00:00","monitor_end_time":"2025-03-30 18:02:00","data":{"cpu":[0.73,0.69,0.75,0.77,0.77],"mesh成功率":[100,87.38,84.19,87.3,80.94],"mesh时延":[0.02,0.02,0.01,0.02,0.01],"mesh流量":[25.4,31.7,31,30.7,40.4],"内存":[8.92,8.88,8.86,8.89,8.91]}}],"assessment_data":{"monitor_start_time":"2025-03-31 18:00:00","monitor_end_time":"2025-03-31 18:02:00","data":{"cpu":[6.15,4.37,1.65,0.8,0.75],"mesh成功率":[90.11,16.88,51.41,33.06,30.79],"mesh时延":[0.19,0,0.01,0.01,0.01],"mesh流量":[220.4,158.2,53.3,85.6,86.4],"内存":[9.02,8.76,8.61,8.49,8.52]}}}
'''
思考：'''
变更后的数据成功率下降幅度非常大，从流量来看每秒平均流量最高超过220，所以高流量成功率较大幅度突降并且持续劣化未恢复符合高风险标准，对比变更前的数据看，成功率也是在下降，对比昨天的数据成功率也同样在下降，说明并非每天在这个时间都下降，排除周期性任务因素，时延在下降但不能说明问题通常时延上升才会反应服务有问题，流量和cpu在下降，这和我们通常见到的场景不一样，通常成功率下降会因为重试流量而上升，资源饱和度也因此升高，但看起来并没有重试流量，也不符合容量不足导致问题，有可能是调用下游服务异常导致问题，综上成功率突降且流量超过100，可能是调用下游服务异常导致，因此结论是：高风险
'''
输出：高风险
-----案例3 end-------
-----案例4 start------
输入'''{"job_id": 215175310, "cluster": "logcenter-znzt.op.qcvmbj6", "end_time": "2025-05-07 17:46:49", "start_time": "2025-05-07 17:36:49", "budget_unit": "检索算法", "history_data": [{"data": {"cpu": [70.142, 72.977, 68.704, 68.237, 68.184, 67.284, 71.131, 69.296, 67.726, 68.363, 67.71, 74.511, 71.433, 68.965, 68.661, 68.627, 72.735, 71.876, 68.499, 68.804, 69.259, 75.647, 70.863, 71.265, 67.967, 71.8, 75.085, 69.668, 69.791, 69.813, 73.297], "内存": [40.533, 40.531, 40.521, 40.518, 40.512, 40.506, 40.501, 40.489, 40.483, 40.479, 40.475, 40.469, 40.463, 40.456, 40.451, 40.449, 40.44, 40.436, 40.432, 40.427, 40.421, 40.416, 40.411, 40.406, 40.403, 40.397, 40.393, 40.387, 40.383, 40.377, 40.37]}, "monitor_end_time": "2025-05-07 17:36:49", "monitor_start_time": "2025-05-07 17:31:49"}, {"data": {"cpu": [69.544, 59.656, 70.749, 66.552, 61.262, 68.873, 60.971, 72.225, 67.55, 63.54, 68.887, 59.982, 70.387], "内存": [53.591, 53.617, 53.65, 53.65, 53.649, 53.657, 53.658, 53.658, 53.659, 53.658, 53.659, 53.659, 53.66]}, "monitor_end_time": "2025-05-06 17:48:49", "monitor_start_time": "2025-05-06 17:46:49"}], "assessment_data": {"data": {"cpu": [82.588, 80.238, 79.698, 80.918, 83.195, 80.886, 78.759, 83.494, 80.558, 76.955, 82.914, 82.257, 78.964], "内存": [40.09, 40.086, 40.093, 40.081, 40.079, 40.073, 40.07, 40.066, 40.062, 40.061, 40.055, 40.053, 40.05]}, "monitor_end_time": "2025-05-07 17:48:49", "monitor_start_time": "2025-05-07 17:46:49"}}'''
思考：'''资源饱和度:变更后的内存与昨日同期相似，cpu虽然超过了安全水位(参考值:>80)，但安全水位是针对普通服务，而这个服务从变更前的数据和历史同期数据来看长期在70左右，接近安全水位，所以相对来说涨幅并不是很大，因此结论是：无风险'''
输出：无风险
-----案例4 end----
-----案例5 start----
输入'''{"job_id": 210139064, "cluster": "knowledge-aigc-controller.rec-strategy.qcvmbj6-docker", "end_time": "2025-04-23 16:04:49", "start_time": "2025-04-23 16:04:49", "budget_unit": "检索算法", "history_data": [{"data": {"cpu": [2.46, 2.47, 2.46, 2.48, 2.54, 2.58, 2.6, 2.6, 2.62, 2.61, 2.57], "内存": [35.28, 35.28, 35.29, 35.3, 35.31, 35.29, 35.3, 35.31, 35.3, 35.29, 35.3], "mesh时延": [4050, 4130, 3740, 3080, 2710, 2780, 2470, 2740, 3050, 3280, 4250], "mesh流量": [258.9, 247.2, 242.3, 304.7, 327.1, 314.4, 327.4, 329.5, 300, 288.2, 249.2], "mesh成功率": [93.7, 94.22, 95.25, 97.6, 98.38, 98.35, 99.02, 98.73, 98.27, 97.4, 92.66]}, "monitor_end_time": "2025-04-23 16:04:49", "monitor_start_time": "2025-04-23 15:59:49"}, {"data": {"cpu": [2.59, 2.59, 2.59, 2.6, 2.61], "内存": [30.51, 30.52, 30.52, 30.54, 30.55], "mesh时延": [2150, 2020, 2140, 2160, 2080], "mesh流量": [325, 334, 332, 343.5, 332.7], "mesh成功率": [99.42, 99.31, 99.19, 99.21, 99.34]}, "monitor_end_time": "2025-04-22 16:06:49", "monitor_start_time": "2025-04-22 16:04:49"}], "assessment_data": {"data": {"cpu": [2.57, 2.51, 2.46, 2.43, 2.42], "内存": [35.3, 35.29, 35.29, 35.3, 35.29], "mesh时延": [4250, 4430, 4760, 5010, 4890], "mesh流量": [249.2, 229.6, 241.7, 223.6, 215], "mesh成功率": [92.66, 92.42, 90.73, 85.73, 92.65]}, "monitor_end_time": "2025-04-23 16:06:49", "monitor_start_time": "2025-04-23 16:04:49"}}'''
思考：'''
资源饱和度：变更后cpu使用率在2%左右，内存在35%左右，没有超过安全水位，和变更前差不多，和昨天同期比内存使用率增长5%，cpu无变化，推测可能是流量有增长？总结变化较小无风险。从流量看变更后比变更前流量低了50，不过变化比例只有不到20%可接受，比昨天同期降了30%，推翻了刚才流量增长导致内存使用率增加的推理，看起来内存增长可能有其他原因。时延变更前后差不多，但和昨天同期比增加了1倍，平均值超过1000，同时满足超过1000ms并且有较大涨幅而且没有恢复的三个条件，从这里得出几个信息：1.变更前已经出现耗时翻倍问题，说明不是本次变更引入2.服务长期耗时超过1000ms说明接口一直响应较慢，非时延突增，3.时延明显的劣化属于风险但非本次引入。在看看最重要的指标成功率，也得出几个信息：1.成功率变更前后都不是100%说明不是本次引入2.昨天同期成功超过99%，说明对比昨天出现了劣化迹象综上内存略微上升，流量相对高位出现成功率较大幅度下降,时延处于高位且翻倍，但并非本次引入，因此结论是：中风险
'''
输出：中风险
-----案例5 end------
# 回答要求：输出结论及分析过程，使用markdown代码块格式，按照结论先行，数据支撑，分析过程，历史case的顺序并使用二级标题进行突出。
# 禁止以下行为：
- 不要一味地通过案例反推判断逻辑，保持严谨不要夸张。
- 禁止输出时存在多余空行、删除线(~~)
- 当每个指标数据量过小(标准:<3)，跳过此项指标。
- 如果对比的指标只有变更后的数据，变更前数据中不存在，不要将此项指标纳入检查范围。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
# 输出结果
# 结论
无风险
# 数据支撑
CPU使用率： 变更前：均值≈0.017（范围0.015~0.021） 变更后：短暂突增至0.066后回落（范围0.014~0.066）
内存使用率： 变更前：恒定3.368% 变更后：轻微波动（范围3.308%~3.369%）
# 分析过程
饱和度判断
CPU：变更后CPU最高值仅为0.066%，远低于安全水位80%。突增幅度虽达3.88倍（0.017→0.066），但绝对值极小且快速回落，属于低关注度抖动。 内存：变更后内存波动幅度仅0.061%（3.308%~3.369%），远低于安全水位且未持续增长。
上下文关联
预算单元特征：直播课教学业务在18:00-22:00可能存在周期性流量潮汐，但当前监控时段（18:53-19:05）未观测到显著资源需求变化。 服务特性：微服务组件（docker集群）长期保持极低资源占用（CPU<0.1%、内存<4%），符合轻量级后台服务特征。
# 历史case印证
符合案例1逻辑：当资源饱和度指标绝对值极小（CPU<1%、内存<5%）时，即使存在相对比例突增，也直接判定为无风险。 符合案例4逻辑：历史基线长期处于低水位时，微小波动属于业务正常表现。
# 检查通知
服务检查 任务类型：CD部署 检查结果：不通过 服务单元：xxxx 检查时间：2025-08-19 11:49:49 检查结果：[点击查看AI分析】 变更人：xxx 变更详情：[点击查看CM工单]
