从 0 到 1 构建运维 AI Agent Harness Engineering:异常检测、故障诊断与自动修复实战一、引言钩子你是否经历过凌晨3点被告警电话炸醒,睡眼惺忪地翻几百条日志排查2小时,最后发现只是某个节点磁盘满了?是否在大促期间面对上百个微服务的雪崩告警,完全分不清哪个是根因哪个是次生故障,只能眼睁睁看着MTTR(平均恢复时间)一路飙到几小时,业务损失六位数?是否团队花了上百万招资深SRE,80%的时间却花在处理重复的、低价值的故障上,根本没时间做架构优化?以上几乎是所有云原生时代运维团队的共性痛点:随着微服务、Kubernetes、Serverless等技术的普及,系统架构的复杂度呈指数级上升,传统基于规则的运维体系已经完全跟不上迭代速度。定义问题/阐述背景据Gartner 2024年的调研数据,全球企业运维团队的平均MTTR为47分钟,其中72%的故障是已知场景的重复发生,60%的故障修复时间可以压缩到1分钟以内。而Harness Engineering作为新一代智能软件交付工程体系,已经被Netflix、Uber、Shopify等头部企业用来实现DevOps全链路的自动化,而运维AI Agent作为Harness体系的核心智能模块,正是解决上述运维痛点的最优解。传统AIOps 1.0方案依赖规则引擎和统计机器学习,存在三大硬伤:一是规则维护成本极高,新场景必须手动加规则,复杂度上去之后规则之间还会冲突;二是泛化能力极差,完全覆盖不了未见过的故障场景;三是没有自主决策能力,只能做告警,不能自动诊断修复。而基于大模型的AIOps 2.0 Agent,结合RAG(检索增强生成)、工具调用、记忆机制,能实现从异常检测、根因诊断到自动修复的全链路自治,MTTR可以降低90%以上,运维人力成本可以降低60%。亮明观点/文章目标本文将带你从零开始,基于Harness Engineering生态,构建一个生产可用的运维AI Agent,完整覆盖异常检测、故障诊断、自动修复三大核心能力。读完本文你将掌握:运维AI Agent的核心架构设计与技术选型如何对接Harness SRM(服务可靠性管理)与可观测性体系实现异常智能检测如何基于RAG+大模型实现高准确率的故障根因诊断如何对接Harness CD实现安全的自动故障修复生产落地的常见坑与最佳实践本文所有代码均可直接运行,完整项目已开源在GitHub:harness-ops-agent。二、基础知识/背景铺垫核心概念定义1. Harness EngineeringHarness是全球领先的智能软件交付平台,核心覆盖CI(持续集成)、CD(持续部署)、SRM(服务可靠性管理)、Feature Flag(特性开关)、Cloud Cost(云成本管理)五大模块,其核心设计理念是用工程化的方式实现软件交付全链路的自动化、可观测、可审计。本文的运维AI Agent将完全构建在Harness生态之上,避免重复造轮子。2. 运维AI Agent运维AI Agent是指具备感知、决策、执行、记忆能力的智能运维程序,能够自主完成故障的检测、诊断、修复全流程,核心由四大模块组成:感知层:对接监控、日志、链路、SLO等数据,感知系统运行状态决策层:基于算法和大模型实现异常检测、根因诊断、修复方案生成执行层:对接CD平台、K8s API、工单系统等,执行修复动作记忆层:存储历史故障、运维知识库、执行日志,实现能力迭代3. 三大核心能力定义能力定义核心指标异常检测提前发现系统的异常运行状态,降低漏报、误报率准确率≥95%,召回率≥90%故障诊断基于异常信息定位根因,给出可执行的修复方案根因准确率≥90%自动修复自动执行修复动作,快速恢复业务,同时保证操作安全修复成功率≥95%,无高危误操作相关技术对比我们将传统规则引擎、统计AIOps、大模型运维AI Agent三大方案做核心维度对比:对比维度传统规则引擎统计机器学习AIOps大模型运维AI Agent异常检测准确率70%~80%(误报多)80%~90%90%~98%根因诊断准确率60%~70%(仅覆盖已知场景)70%~80%85%~95%泛化能力极差,新场景必须加规则一般,需要重新训练模型极强,仅需补充少量知识库文档可解释性强,规则可追溯弱,黑盒模型强,大模型会输出完整推理过程开发运维成本极高,规则维护成本随复杂度指数上升中,需要大量标注数据训练模型低,仅需维护知识库和安全规则适用场景小规模、架构稳定的系统中等规模、有大量历史标注数据的系统大规模、云原生、快速迭代的系统运维AI Agent整体架构我们先给出整体架构图,后面的实战将基于这个架构逐步实现:渲染错误:Mermaid 渲染失败: Parsing failed: Lexer error on line 2, column 28: unexpected character: -[- at offset: 45, skipped 5 characters. Lexer error on line 3, column 35: unexpected character: -[- at offset: 85, skipped 1 characters. Lexer error on line 3, column 47: unexpected character: -指- at offset: 97, skipped 5 characters. Lexer error on line 4, column 28: unexpected character: -[- at offset: 144, skipped 1 characters. Lexer error on line 4, column 33: unexpected character: -日- at offset: 149, skipped 5 characters. Lexer error on line 5, column 31: unexpected character: -[- at offset: 199, skipped 1 characters. Lexer error on line 5, column 39: unexpected character: -链- at offset: 207, skipped 5 characters. Lexer error on line 6, column 36: unexpected character: -[- at offset: 262, skipped 1 characters. Lexer error on line 6, column 52: unexpected character: -管- at offset: 278, skipped 3 characters. Lexer error on line 8, column 27: unexpected character: -[- at offset: 323, skipped 5 characters. Lexer error on line 9, column 33: unexpected character: -[- at offset: 361, skipped 1 characters. Lexer error on line 9, column 41: unexpected character: -向- at offset: 369, skipped 6 characters. Lexer error on line 10, column 32: unexpected character: -[- at offset: 417, skipped 1 characters. Lexer error on line 10, column 39: unexpected character: -故- at offset: 424, skipped 4 characters. Lexer error on line 11, column 32: unexpected character: -[- at offset: 470, skipped 1 characters. Lexer error on line 11, column 39: unexpected character: -短- at offset: 477, skipped 7 characters. Lexer error on line 13, column 26: unexpected character: -[- at offset: 521, skipped 5 characters. Lexer error on line 14, column 39: unexpected character: -[- at offset: 565, skipped 8 characters. Lexer error on line 15, column 35: unexpected character: -[- at offset: 620, skipped 8 characters. Lexer error on line 16, column 36: unexpected character: -[- at offset: 676, skipped 8 characters. Lexer error on line 17, column 28: unexpected character: -[- at offset: 724, skipped 7 characters. Lexer error on line 17, column 43: unexpected character: -]- at offset: 739, skipped 1 characters. Lexer error on line 19, column 27: unexpected character: -[- at offset: 780, skipped 5 characters. Lexer error on line 20, column 35: unexpected character: -[- at offset: 820, skipped 1 characters. Lexer error on line 20, column 47: unexpected character: -交- at offset: 832, skipped 5 characters. Lexer error on line 22, column 31: unexpected character: -[- at offset: 938, skipped 6 characters. Lexer error on line 23, column 31: unexpected character: -[- at offset: 988, skipped 5 characters. Lexer error on line 23, column 38: unexpected character: -企- at offset: 995, skipped 8 characters. Parse error on line 3, column 36: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Prometheus' Parse error on line 3, column 53: Expecting token of type ':' but found `in`. Parse error on line 4, column 29: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'ELK' Parse error on line 4, column 39: Expecting token of type ':' but found `in`. Parse error on line 5, column 32: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Jaeger' Parse error on line 5, column 45: Expecting token of type ':' but found `in`. Parse error on line 6, column 37: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Harness' Parse error on line 6, column 45: Expecting token of type ':' but found `SRM`. Parse error on line 6, column 49: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'SLO' Parse error on line 6, column 56: Expecting token of type ':' but found `in`. Parse error on line 9, column 34: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Chroma' Parse error on line 9, column 48: Expecting token of type ':' but found `in`. Parse error on line 10, column 33: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'MySQL' Parse error on line 10, column 44: Expecting token of type ':' but found `in`. Parse error on line 11, column 33: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'R' Parse error on line 11, column 47: Expecting token of type ':' but found `in`. Parse error on line 17, column 35: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Qwen2-7B' Parse error on line 17, column 45: Expecting token of type ':' but found `in`. Parse error on line 20, column 36: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Harness' Parse error on line 20, column 44: Expecting token of type ':' but found `CD`. Parse error on line 20, column 53: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'in' Parse error on line 20, column 65: Expecting token of type ':' but found ` `. Parse error on line 23, column 36: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: ':' Parse error on line 23, column 59: Expecting token of type ':' but found ` `. Parse error on line 33, column 13: Expecting token of type 'ARCH_TITLE' but found ``.运维智能化发展历史我们可以从行业发展的角度看运维AI Agent的必然性:阶段时间核心技术核心能力平均MTTR人力成本占运维总支出比例手工运维时代1990-2005脚本、CLI工具人工排查、人工修复数小时~数天80%+自动化运维时代2005-2015Ansible、Puppet、Jenkins标准化操作自动化数十分钟~数小时50%~70%DevOpsAIOps 1.0时代2015-2023Prometheus、ELK、规则引擎、统计机器学习自动告警、辅助排查数分钟~数十分钟30%~50%AIOps 2.0(Agent时代)2023~至今大语言模型、RAG、多Agent协作、Harness工程化体系自动检测、自动诊断、自动修复数秒~数分钟20%三、核心内容/实战演练前置环境准备我们需要提前准备以下环境:Harness免费账号:注册地址 https://harness.io/,开通SRM和CD模块Kubernetes集群:版本≥1.24,用来部署测试服务和模拟故障可观测性栈:Prometheus + Grafana + ELK + Jaeger,已经对接K8s集群大模型环境:本地部署Qwen2-7B(推荐)或者OpenAI API密钥开发环境:Python 3.10+,安装依赖包:pip install langchain chromadb scikit-learn prometheus-api-client requests步骤一:对接Harness SRM与可观测性体系Harness SRM是用来管理SLO(服务等级目标)的核心模块,我们首先需要把可观测性数据同步到Harness SRM,基于SLO burn rate来触发异常检测,避免无效告警。核心原理SLO burn rate是衡量错误预算消耗速度的核心指标,公式如下:b u r n r a t e = e r r o r b u d g e t c o n s u m e d e r r o r b u d g e t e x p e c t e d burn\ rate = \frac{error\ budget\ consumed}{error\ budget\ expected}burnrate=errorbudgetexpectederrorbudgetconsumed其中:error budget consumed = 实际错误请求数 / 总请求数error budget expected = (1 - SLO目标)* 总请求数当burn rate 1时,说明错误预算消耗速度超过预期,burn rate 10(1小时窗口)时说明发生了严重故障,需要立即处理。对接实现首先我们通过Prometheus API拉取服务的错误率指标,同步到Harness SRM:importpandasaspdimportrequestsimportosfromprometheus_api_clientimportPrometheusConnect# 配置参数PROM_URL="http://your-prometheus:9090"HARNESS_API_KEY=os.environ.get("HARNESS_API_KEY")HARNESS_ACCOUNT_ID=os.environ.get("HARNESS_ACCOUNT_ID")HARNESS_ORG_ID=os.environ.get("HARNESS_ORG_ID")HARNESS_PROJECT_ID=os.environ.get("HARNESS_PROJECT_ID")# 连接Prometheusprom=PrometheusConnect(url=PROM_URL,disable_ssl=True)defsync_slo_met
从 0 到 1 构建运维 AI Agent Harness Engineering:异常检测、故障诊断与自动修复实战
发布时间:2026/5/27 22:35:12
从 0 到 1 构建运维 AI Agent Harness Engineering:异常检测、故障诊断与自动修复实战一、引言钩子你是否经历过凌晨3点被告警电话炸醒,睡眼惺忪地翻几百条日志排查2小时,最后发现只是某个节点磁盘满了?是否在大促期间面对上百个微服务的雪崩告警,完全分不清哪个是根因哪个是次生故障,只能眼睁睁看着MTTR(平均恢复时间)一路飙到几小时,业务损失六位数?是否团队花了上百万招资深SRE,80%的时间却花在处理重复的、低价值的故障上,根本没时间做架构优化?以上几乎是所有云原生时代运维团队的共性痛点:随着微服务、Kubernetes、Serverless等技术的普及,系统架构的复杂度呈指数级上升,传统基于规则的运维体系已经完全跟不上迭代速度。定义问题/阐述背景据Gartner 2024年的调研数据,全球企业运维团队的平均MTTR为47分钟,其中72%的故障是已知场景的重复发生,60%的故障修复时间可以压缩到1分钟以内。而Harness Engineering作为新一代智能软件交付工程体系,已经被Netflix、Uber、Shopify等头部企业用来实现DevOps全链路的自动化,而运维AI Agent作为Harness体系的核心智能模块,正是解决上述运维痛点的最优解。传统AIOps 1.0方案依赖规则引擎和统计机器学习,存在三大硬伤:一是规则维护成本极高,新场景必须手动加规则,复杂度上去之后规则之间还会冲突;二是泛化能力极差,完全覆盖不了未见过的故障场景;三是没有自主决策能力,只能做告警,不能自动诊断修复。而基于大模型的AIOps 2.0 Agent,结合RAG(检索增强生成)、工具调用、记忆机制,能实现从异常检测、根因诊断到自动修复的全链路自治,MTTR可以降低90%以上,运维人力成本可以降低60%。亮明观点/文章目标本文将带你从零开始,基于Harness Engineering生态,构建一个生产可用的运维AI Agent,完整覆盖异常检测、故障诊断、自动修复三大核心能力。读完本文你将掌握:运维AI Agent的核心架构设计与技术选型如何对接Harness SRM(服务可靠性管理)与可观测性体系实现异常智能检测如何基于RAG+大模型实现高准确率的故障根因诊断如何对接Harness CD实现安全的自动故障修复生产落地的常见坑与最佳实践本文所有代码均可直接运行,完整项目已开源在GitHub:harness-ops-agent。二、基础知识/背景铺垫核心概念定义1. Harness EngineeringHarness是全球领先的智能软件交付平台,核心覆盖CI(持续集成)、CD(持续部署)、SRM(服务可靠性管理)、Feature Flag(特性开关)、Cloud Cost(云成本管理)五大模块,其核心设计理念是用工程化的方式实现软件交付全链路的自动化、可观测、可审计。本文的运维AI Agent将完全构建在Harness生态之上,避免重复造轮子。2. 运维AI Agent运维AI Agent是指具备感知、决策、执行、记忆能力的智能运维程序,能够自主完成故障的检测、诊断、修复全流程,核心由四大模块组成:感知层:对接监控、日志、链路、SLO等数据,感知系统运行状态决策层:基于算法和大模型实现异常检测、根因诊断、修复方案生成执行层:对接CD平台、K8s API、工单系统等,执行修复动作记忆层:存储历史故障、运维知识库、执行日志,实现能力迭代3. 三大核心能力定义能力定义核心指标异常检测提前发现系统的异常运行状态,降低漏报、误报率准确率≥95%,召回率≥90%故障诊断基于异常信息定位根因,给出可执行的修复方案根因准确率≥90%自动修复自动执行修复动作,快速恢复业务,同时保证操作安全修复成功率≥95%,无高危误操作相关技术对比我们将传统规则引擎、统计AIOps、大模型运维AI Agent三大方案做核心维度对比:对比维度传统规则引擎统计机器学习AIOps大模型运维AI Agent异常检测准确率70%~80%(误报多)80%~90%90%~98%根因诊断准确率60%~70%(仅覆盖已知场景)70%~80%85%~95%泛化能力极差,新场景必须加规则一般,需要重新训练模型极强,仅需补充少量知识库文档可解释性强,规则可追溯弱,黑盒模型强,大模型会输出完整推理过程开发运维成本极高,规则维护成本随复杂度指数上升中,需要大量标注数据训练模型低,仅需维护知识库和安全规则适用场景小规模、架构稳定的系统中等规模、有大量历史标注数据的系统大规模、云原生、快速迭代的系统运维AI Agent整体架构我们先给出整体架构图,后面的实战将基于这个架构逐步实现:渲染错误:Mermaid 渲染失败: Parsing failed: Lexer error on line 2, column 28: unexpected character: -[- at offset: 45, skipped 5 characters. Lexer error on line 3, column 35: unexpected character: -[- at offset: 85, skipped 1 characters. Lexer error on line 3, column 47: unexpected character: -指- at offset: 97, skipped 5 characters. Lexer error on line 4, column 28: unexpected character: -[- at offset: 144, skipped 1 characters. Lexer error on line 4, column 33: unexpected character: -日- at offset: 149, skipped 5 characters. Lexer error on line 5, column 31: unexpected character: -[- at offset: 199, skipped 1 characters. Lexer error on line 5, column 39: unexpected character: -链- at offset: 207, skipped 5 characters. Lexer error on line 6, column 36: unexpected character: -[- at offset: 262, skipped 1 characters. Lexer error on line 6, column 52: unexpected character: -管- at offset: 278, skipped 3 characters. Lexer error on line 8, column 27: unexpected character: -[- at offset: 323, skipped 5 characters. Lexer error on line 9, column 33: unexpected character: -[- at offset: 361, skipped 1 characters. Lexer error on line 9, column 41: unexpected character: -向- at offset: 369, skipped 6 characters. Lexer error on line 10, column 32: unexpected character: -[- at offset: 417, skipped 1 characters. Lexer error on line 10, column 39: unexpected character: -故- at offset: 424, skipped 4 characters. Lexer error on line 11, column 32: unexpected character: -[- at offset: 470, skipped 1 characters. Lexer error on line 11, column 39: unexpected character: -短- at offset: 477, skipped 7 characters. Lexer error on line 13, column 26: unexpected character: -[- at offset: 521, skipped 5 characters. Lexer error on line 14, column 39: unexpected character: -[- at offset: 565, skipped 8 characters. Lexer error on line 15, column 35: unexpected character: -[- at offset: 620, skipped 8 characters. Lexer error on line 16, column 36: unexpected character: -[- at offset: 676, skipped 8 characters. Lexer error on line 17, column 28: unexpected character: -[- at offset: 724, skipped 7 characters. Lexer error on line 17, column 43: unexpected character: -]- at offset: 739, skipped 1 characters. Lexer error on line 19, column 27: unexpected character: -[- at offset: 780, skipped 5 characters. Lexer error on line 20, column 35: unexpected character: -[- at offset: 820, skipped 1 characters. Lexer error on line 20, column 47: unexpected character: -交- at offset: 832, skipped 5 characters. Lexer error on line 22, column 31: unexpected character: -[- at offset: 938, skipped 6 characters. Lexer error on line 23, column 31: unexpected character: -[- at offset: 988, skipped 5 characters. Lexer error on line 23, column 38: unexpected character: -企- at offset: 995, skipped 8 characters. Parse error on line 3, column 36: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Prometheus' Parse error on line 3, column 53: Expecting token of type ':' but found `in`. Parse error on line 4, column 29: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'ELK' Parse error on line 4, column 39: Expecting token of type ':' but found `in`. Parse error on line 5, column 32: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Jaeger' Parse error on line 5, column 45: Expecting token of type ':' but found `in`. Parse error on line 6, column 37: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Harness' Parse error on line 6, column 45: Expecting token of type ':' but found `SRM`. Parse error on line 6, column 49: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'SLO' Parse error on line 6, column 56: Expecting token of type ':' but found `in`. Parse error on line 9, column 34: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Chroma' Parse error on line 9, column 48: Expecting token of type ':' but found `in`. Parse error on line 10, column 33: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'MySQL' Parse error on line 10, column 44: Expecting token of type ':' but found `in`. Parse error on line 11, column 33: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'R' Parse error on line 11, column 47: Expecting token of type ':' but found `in`. Parse error on line 17, column 35: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Qwen2-7B' Parse error on line 17, column 45: Expecting token of type ':' but found `in`. Parse error on line 20, column 36: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'Harness' Parse error on line 20, column 44: Expecting token of type ':' but found `CD`. Parse error on line 20, column 53: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: 'in' Parse error on line 20, column 65: Expecting token of type ':' but found ` `. Parse error on line 23, column 36: Expecting: one of these possible Token sequences: 1. [NEWLINE] 2. [EOF] but found: ':' Parse error on line 23, column 59: Expecting token of type ':' but found ` `. Parse error on line 33, column 13: Expecting token of type 'ARCH_TITLE' but found ``.运维智能化发展历史我们可以从行业发展的角度看运维AI Agent的必然性:阶段时间核心技术核心能力平均MTTR人力成本占运维总支出比例手工运维时代1990-2005脚本、CLI工具人工排查、人工修复数小时~数天80%+自动化运维时代2005-2015Ansible、Puppet、Jenkins标准化操作自动化数十分钟~数小时50%~70%DevOpsAIOps 1.0时代2015-2023Prometheus、ELK、规则引擎、统计机器学习自动告警、辅助排查数分钟~数十分钟30%~50%AIOps 2.0(Agent时代)2023~至今大语言模型、RAG、多Agent协作、Harness工程化体系自动检测、自动诊断、自动修复数秒~数分钟20%三、核心内容/实战演练前置环境准备我们需要提前准备以下环境:Harness免费账号:注册地址 https://harness.io/,开通SRM和CD模块Kubernetes集群:版本≥1.24,用来部署测试服务和模拟故障可观测性栈:Prometheus + Grafana + ELK + Jaeger,已经对接K8s集群大模型环境:本地部署Qwen2-7B(推荐)或者OpenAI API密钥开发环境:Python 3.10+,安装依赖包:pip install langchain chromadb scikit-learn prometheus-api-client requests步骤一:对接Harness SRM与可观测性体系Harness SRM是用来管理SLO(服务等级目标)的核心模块,我们首先需要把可观测性数据同步到Harness SRM,基于SLO burn rate来触发异常检测,避免无效告警。核心原理SLO burn rate是衡量错误预算消耗速度的核心指标,公式如下:b u r n r a t e = e r r o r b u d g e t c o n s u m e d e r r o r b u d g e t e x p e c t e d burn\ rate = \frac{error\ budget\ consumed}{error\ budget\ expected}burnrate=errorbudgetexpectederrorbudgetconsumed其中:error budget consumed = 实际错误请求数 / 总请求数error budget expected = (1 - SLO目标)* 总请求数当burn rate 1时,说明错误预算消耗速度超过预期,burn rate 10(1小时窗口)时说明发生了严重故障,需要立即处理。对接实现首先我们通过Prometheus API拉取服务的错误率指标,同步到Harness SRM:importpandasaspdimportrequestsimportosfromprometheus_api_clientimportPrometheusConnect# 配置参数PROM_URL="http://your-prometheus:9090"HARNESS_API_KEY=os.environ.get("HARNESS_API_KEY")HARNESS_ACCOUNT_ID=os.environ.get("HARNESS_ACCOUNT_ID")HARNESS_ORG_ID=os.environ.get("HARNESS_ORG_ID")HARNESS_PROJECT_ID=os.environ.get("HARNESS_PROJECT_ID")# 连接Prometheusprom=PrometheusConnect(url=PROM_URL,disable_ssl=True)defsync_slo_met