面向运维 Agent 的 Harness 故障预测与自愈

面向运维 Agent 的 Harness 故障预测与自愈构建下一代自主运维闭环1. 引入与连接从凌晨三点的告警短信说起唤起兴趣与建立关联1.1 引人入胜的开场运维工程师李工的“惊魂夜”深夜11:52深圳科技园一栋写字楼23层的游戏公司灯火通明——新上线的跨平台MMORPG公测第3天日活用户DAU正朝着120万的峰值冲刺运营组还在监控室里攥着实时在线数图表欢呼。但就在运营组隔壁的运维部李工的智能手表突然“嗡、嗡、嗡”连续震动屏幕上跳出3条红色告警短信Harness CI/CD Pipeline #18927游戏服务器扩容脚本Git仓库分支冲突无法完成自动回滚后的热备扩容触发Harness Cloud Cost ManagementCCM监控告警热备集群AWS EC2 Spot实例批量终止触发逻辑误判实例池容量骤降40%Harness Service Reliability ManagementSRMSLO告警游戏登录、交易、对战三大核心服务的错误率Error Budget Burn Rate超过15x阈值预计剩余Error Budget将在37分钟耗尽“糟了凌晨三点刚处理完公测第2天的内存泄漏触发的批量重启怎么又来组合拳”李工立刻从工位上弹起来冲进监控室打开了所有Harness模块和云平台控制台的大屏扩容脚本的Git仓库里开发小王昨晚修改过的动态弹性IP绑定脚本在合并热补丁分支时确实发生了冲突Git日志显示合并请求是在SRM告警前12分钟提交的CCM的批量Spot终止触发逻辑是他上周为了应对公测第1天晚上的非核心服务Spot价格飙升临时写的——但触发条件只加了“Spot实例当前价格超过预留实例的1.5倍”完全忘记加上“游戏核心服务所在的可用区AZ内热备容量70%”这个兜底条件SRM的三大服务监控显示登录服务的错误来自于热备EC2没有正确绑定到跨AZ的ELB负载均衡器交易服务的错误来自于MySQL主从同步延迟超过10秒后扩容出来的新服务器连接到了只读从库执行写入操作对战服务的错误则更严重——剩余的生产服务器内存占用率已经飙升到98%正在发生OOM内存溢出导致服务进程不断被kill时间一分一秒地过去剩余Error Budget从37分钟降到29分钟、18分钟、5分钟……李工手忙脚乱地做了三件事手动回滚了扩容脚本的Git合并请求临时禁用了CCM的批量Spot终止逻辑联系AWS售后申请了一批On-Demand实例紧急补充生产和热备集群修改了对战服务的MySQL连接池配置暂时切断了对战服务与从库的连接手动重启了3台生产服务器中内存占用率最高的一台。就在剩余Error Budget只剩1分钟47秒的时候对战服务的错误率终于降到了阈值以下剩余Error Budget开始缓慢恢复。李工瘫坐在监控室的椅子上喝了一口已经凉透的咖啡看着墙上挂的“构建自主运维实现99.999%可用性”的标语苦笑了一下“自主运维现在连自动告警触发后的手动处理都快赶不上趟了要是有个**能看懂Git合并请求、能分析告警之间的因果关系、能自动修复扩容脚本、能临时调整CCM策略、能快速申请On-Demand实例、能修改MySQL连接池配置的‘智能运维助手’**就好了”1.2 与读者已有知识建立关联你可能已经接触过这些“碎片”如果你是一名互联网企业的运维工程师、SRE工程师、DevOps工程师或者云架构师你可能对李工遇到的场景并不陌生甚至你自己就经历过类似的“惊魂夜”同时你可能也已经接触过李工使用的那些工具中的“碎片”CI/CD工具除了Harness CI/CD之外你可能用过Jenkins、GitLab CI/CD、CircleCI、Travis CI这些CCM云成本管理工具除了Harness CCM之外你可能用过AWS Cost Explorer、Azure Cost Management、GCP Billing、CloudHealth by VMware这些SRM服务可靠性管理/APM应用性能监控/ITSMIT服务管理工具除了Harness SRM之外你可能用过New Relic、Datadog、Dynatrace、Splunk、Prometheus Grafana、PagerDuty、ServiceNow这些自动化运维工具你可能用过Ansible、Terraform、SaltStack、Chef、Puppet这些故障预测与自愈的“雏形”你可能用过Prometheus的Alertmanager触发自动化脚本重启服务用过Jenkins的Pipeline根据SonarQube的代码质量报告自动回滚部署用过AWS的Auto Scaling根据CPU/内存使用率自动扩容/缩容——但这些都是**“单维度、事后触发、规则固定、无法理解上下文”**的“碎片式自动化”远远达不到李工想要的“智能运维助手”的要求。1.3 学习价值与应用场景预览从“碎片式自动化”到“自主运维闭环”那什么是李工想要的“智能运维助手”呢在DevOps和SRE领域我们通常把这种“能感知环境、能理解上下文、能预测故障、能自动决策、能执行修复动作、能验证修复效果、能从修复过程中学习优化”的系统称为**“自主运维闭环系统”Autonomous Operations Loop System而李工想要的“智能运维助手”其实就是这个闭环系统中的“核心大脑执行终端”——也就是我们这篇文章要讲的“面向运维Agent的Harness故障预测与自愈系统”**。读完这篇文章你将能够理解什么是自主运维闭环系统以及它的四个核心阶段感知Perception、决策Decision、执行Execution、学习Learning掌握Harness平台的核心模块以及它们如何与自主运维闭环系统的四个核心阶段对应起来了解什么是运维Agent以及Harness Agent的架构、功能和部署方式学习如何在Harness平台上构建故障预测模型包括数据采集、特征工程、模型训练、模型部署和模型监控学习如何在Harness平台上构建自愈决策引擎包括规则引擎、机器学习引擎和混合引擎的使用学习如何在Harness平台上配置自愈执行流程包括Pipeline的设计、步骤的配置、权限的管理和回滚机制的设置通过一个真实的项目案例从零开始构建一个面向游戏MMORPG核心服务的Harness故障预测与自愈系统了解面向运维Agent的Harness故障预测与自愈系统的最佳实践以及它的行业发展与未来趋势。这个系统的应用场景非常广泛除了李工遇到的游戏MMORPG公测场景之外还可以应用于电商大促场景预测电商网站的流量峰值、服务器的CPU/内存/磁盘使用率、数据库的主从同步延迟、支付网关的错误率等自动触发扩容/缩容、缓存预热、数据库主从切换、支付网关降级等自愈动作金融交易场景预测金融交易系统的并发交易量、服务器的IOPS/吞吐量、数据库的锁等待时间、消息队列的积压量等自动触发服务器扩容、数据库索引优化、消息队列分区扩容、交易服务限流等自愈动作企业办公场景预测企业OA系统、邮件系统、视频会议系统的用户访问量、服务器的资源使用率、网络的带宽占用率等自动触发服务器扩容、网络带宽升级、视频会议系统的MCU多点控制单元扩容等自愈动作工业物联网场景预测工业机器人的故障率、传感器的误差率、生产线的停机时间等自动触发工业机器人的预防性维护、传感器的校准、生产线的备件更换等自愈动作。1.4 学习路径概览跟着知识金字塔一步步攀登为了让你能够从“碎片式自动化”的使用者成长为“自主运维闭环系统”的构建者我们将按照知识金字塔构建者提出的“金字塔式知识结构”来组织这篇文章的内容学习路径如下金字塔层级对应章节核心内容基础层第2章、第3章核心概念的直观理解自主运维闭环、Harness平台、运维Agent连接层第4章概念间的关系网络Harness平台核心模块与自主运维闭环的对应关系、Harness Agent与Harness平台核心模块的交互关系深度层第5章、第6章原理机制与底层逻辑Harness故障预测模型的构建原理、Harness自愈决策引擎的构建原理整合层第7章、第8章、第9章多维视角与系统观真实项目案例、最佳实践、行业发展与未来趋势接下来就让我们跟着这条学习路径一步步攀登知识金字塔构建属于我们自己的“面向运维Agent的Harness故障预测与自愈系统”吧2. 概念地图建立整体认知框架此处因排版限制省略了完整的Mermaid思维导图但在后续章节中会逐步展开所有核心概念的定义、关系和功能。2.1 核心概念与关键术语在开始深入学习之前我们先来明确这篇文章中涉及的核心概念与关键术语避免因概念混淆而影响学习效果2.1.1 自主运维闭环系统Autonomous Operations Loop System自主运维闭环系统是一种基于人工智能AI、机器学习ML、自动化Automation和运维大数据Ops Data的系统它能够在不需要人工干预的情况下自主完成“感知环境→理解上下文→预测故障→自动决策→执行修复动作→验证修复效果→从修复过程中学习优化”的全流程从而实现系统的高可用性High Availability, HA、高可靠性High Reliability, HR、高性能High Performance, HP和低成本Low Cost, LC。自主运维闭环系统通常分为四个核心阶段和五个成熟度等级四个核心阶段感知Perception、决策Decision、执行Execution、学习Learning我们将在第3章详细讲解五个成熟度等级手动运维Level 0、碎片式自动化Level 1、规则驱动的自动化Level 2、预测驱动的自动化Level 3、完全自主运维Level 4我们将在第9章详细讲解。2.1.2 Harness平台Harness是一家成立于2016年的美国SaaS公司它的核心产品是Harness Continuous Delivery as a ServiceCDaaS平台但经过多年的发展Harness平台已经从一个单一的CI/CD工具演变成了一个集成了CI/CD、CCM、SRM、SEISecurity Testing Integration、Feature Flags、Chaos Engineering等多个模块的端到端DevOps/SRE平台我们将在第3章详细讲解Harness平台的核心模块。Harness平台的核心优势在于统一的用户界面UI和应用程序接口API所有模块都在同一个UI和API中不需要在多个工具之间切换AI/ML驱动的自动化Harness平台的所有模块都内置了AI/ML功能能够自动完成很多以前需要人工手动完成的工作多云/混合云/本地部署支持Harness平台支持AWS、Azure、GCP、阿里云、腾讯云等多个公有云也支持VMware、OpenStack等私有云还支持本地部署与现有工具的无缝集成Harness平台能够与Jenkins、GitLab CI/CD、Prometheus、Grafana、New Relic、Datadog、Splunk、PagerDuty、ServiceNow、Ansible、Terraform等1000多种现有工具无缝集成面向运维Agent的架构Harness平台采用了“云平台本地/边缘Agent”的架构能够快速、安全地采集本地/边缘环境的数据执行本地/边缘环境的自动化任务我们将在第3章详细讲解Harness Agent的架构、功能和部署方式。2.1.3 运维AgentOperations Agent运维Agent是一种部署在生产环境、测试环境、开发环境或者边缘环境的轻量级软件程序它的主要功能是数据采集采集服务器、容器、虚拟机、数据库、应用程序、网络设备等的资源使用率、性能指标、日志数据、事件数据等命令执行执行Shell脚本、Python脚本、Ansible Playbook、Terraform Plan/Apply等自动化命令健康检查定期检查服务器、容器、虚拟机、数据库、应用程序等的健康状态与云平台的通信将采集到的数据上传到云平台接收云平台下发的命令和任务。Harness平台提供了两种类型的AgentHarness Delegate这是Harness平台的核心执行Agent它负责执行所有与部署、扩容、缩容、回滚、测试、成本管理等相关的自动化任务也负责采集部分数据我们将在第3章详细讲解Harness DelegateHarness SRM/APM Agent这是Harness平台的监控与数据采集Agent它负责采集应用程序的性能指标、日志数据、事件数据、链路追踪数据等我们将在第3章详细讲解Harness SRM/APM Agent。2.1.4 故障预测Failure Prediction故障预测是指利用运维大数据、AI/ML算法等技术在故障发生之前提前预测出故障可能发生的时间、地点、类型和严重程度从而为故障的预防和自愈争取时间。故障预测通常分为三种类型基于规则的故障预测利用运维专家总结的规则例如“当CPU使用率连续5分钟超过90%时可能会发生OOM故障”来预测故障基于统计的故障预测利用统计学方法例如时间序列分析、异常检测来预测故障基于机器学习的故障预测利用机器学习算法例如监督学习、无监督学习、半监督学习、强化学习来预测故障我们将在第5章详细讲解这三种类型的故障预测以及如何在Harness平台上构建基于机器学习的故障预测模型。2.1.5 自愈Self-Healing自愈是指在故障预测触发之后或者在故障已经发生之后利用自动化工具和决策引擎在不需要人工干预的情况下自动执行修复动作验证修复效果从而恢复系统的正常运行。自愈通常分为两种类型预测性自愈Predictive Self-Healing在故障发生之前根据故障预测的结果自动执行预防性修复动作例如“当预测到CPU使用率可能会在10分钟后超过90%时自动触发服务器扩容”反应性自愈Reactive Self-Healing在故障已经发生之后根据告警的结果自动执行修复动作例如“当检测到服务进程被kill时自动重启服务进程”我们将在第6章详细讲解这两种类型的自愈以及如何在Harness平台上构建自愈决策引擎和自愈执行流程。2.1.6 其他关键术语除了上面提到的核心概念之外我们还需要明确以下几个关键术语Error Budget错误预算这是SRE领域的一个核心概念它是指系统在一段时间内例如一个月、一个季度允许出现的错误的总时间或者总次数例如“系统的可用性目标是99.99%那么一个月的错误预算就是43.2分钟”Error Budget Burn Rate错误预算消耗速率这是指系统当前消耗错误预算的速率例如“错误预算消耗速率是15x意味着系统当前消耗错误预算的速度是预期速度的15倍”SLOService Level Objective服务水平目标这是指系统在一段时间内需要达到的服务水平指标例如“登录服务的错误率0.1%响应时间500ms”SLAService Level Agreement服务水平协议这是指服务提供商与客户之间签订的关于服务水平的法律协议如果服务提供商没有达到SLO可能需要向客户赔偿SLIService Level Indicator服务水平指标这是指用来衡量系统服务水平的具体指标例如登录服务的错误率、响应时间、吞吐量。2.2 概念间的层次与关系为了让你能够更直观地理解这些核心概念之间的层次与关系我们将它们分为三个层次目标层自主运维闭环系统目标是实现系统的高可用性、高可靠性、高性能和低成本支撑层Harness平台支撑层的核心工具提供了CI/CD、CCM、SRM等多个模块、运维Agent支撑层的核心终端负责数据采集和命令执行核心功能层故障预测、自愈核心功能层的两个核心功能共同构成了自主运维闭环系统的“大脑手脚”。2.3 学科定位与边界面向运维Agent的Harness故障预测与自愈系统是一个跨学科的系统它涉及到以下几个学科计算机科学与技术包括操作系统、计算机网络、数据库系统、分布式系统、软件工程等人工智能与机器学习包括异常检测、时间序列分析、监督学习、无监督学习、半监督学习、强化学习等DevOps与SRE包括CI/CD、CCM、SRM、Chaos Engineering、Error Budget等自动化包括Shell脚本、Python脚本、Ansible Playbook、Terraform等大数据包括数据采集、数据清洗、数据存储、数据分析、数据可视化等。这个系统的边界是它是一个辅助工具不是万能的它只能处理一些常见的、可预测的、可自动化修复的故障对于一些罕见的、不可预测的、不可自动化修复的故障还是需要人工干预它需要人工的维护和优化它的故障预测模型和自愈决策引擎需要人工定期维护和优化才能适应系统的变化它需要严格的权限管理它的自愈执行流程需要严格的权限管理避免误操作导致系统的更大故障。3. 基础理解建立直观认识3.1 自主运维闭环系统的四个核心阶段像“人”一样思考和行动为了让你能够更直观地理解自主运维闭环系统我们可以把它比作一个**“经验丰富的SRE工程师”**而自主运维闭环系统的四个核心阶段就对应着这个SRE工程师处理故障的四个步骤3.1.1 感知Perception像人的“眼睛、耳朵、鼻子”一样感知环境感知阶段是自主运维闭环系统的第一个阶段它的主要功能是像人的“眼睛、耳朵、鼻子”一样全方位、全天候、实时地感知系统的环境包括基础设施层服务器、容器、虚拟机、网络设备、存储设备等的资源使用率CPU、内存、磁盘、IOPS、带宽、性能指标、健康状态平台层数据库、缓存、消息队列、负载均衡器、容器编排平台Kubernetes等的资源使用率、性能指标、健康状态、日志数据、事件数据应用层应用程序的性能指标响应时间、吞吐量、错误率、日志数据、事件数据、链路追踪数据、SLO/SLI数据、Error Budget数据业务层用户访问量、交易量、转化率、留存率等业务指标。感知阶段的核心输出是**“运维大数据”**这些数据将被传递到决策阶段用于故障预测和自动决策。3.1.2 决策Decision像人的“大脑”一样理解上下文、预测故障、自动决策决策阶段是自主运维闭环系统的核心阶段它的主要功能是像人的“大脑”一样理解感知阶段传递过来的运维大数据的上下文预测故障可能发生的时间、地点、类型和严重程度然后根据故障预测的结果或者告警的结果自动做出最优的修复决策。决策阶段通常分为三个子阶段上下文理解Context Understanding分析运维大数据之间的因果关系、关联关系和时序关系理解系统当前的状态例如“扩容脚本Git仓库分支冲突→无法完成自动回滚后的热备扩容触发→热备集群容量骤降40%→三大核心服务的错误率超过阈值→剩余Error Budget将在37分钟耗尽”这就是一个因果链故障预测Failure Prediction利用基于规则的方法、基于统计的方法或者基于机器学习的方法预测故障可能发生的时间、地点、类型和严重程度自动决策Automatic Decision Making根据故障预测的结果或者告警的结果结合业务优先级、成本约束、SLO/SLI约束、Error Budget约束等因素自动做出最优的修复决策例如“先手动回滚扩容脚本的Git合并请求还是先临时禁用CCM的批量Spot终止逻辑还是先联系AWS售后申请On-Demand实例”经验丰富的SRE工程师会根据因果链和约束条件做出最优的决策而自动决策引擎也应该具备这样的能力。决策阶段的核心输出是**“修复决策”**这些决策将被传递到执行阶段用于执行修复动作。3.1.3 执行Execution像人的“手脚”一样执行修复动作、验证修复效果执行阶段是自主运维闭环系统的第三个阶段它的主要功能是像人的“手脚”一样根据决策阶段传递过来的修复决策自动执行修复动作然后验证修复效果。执行阶段通常分为两个子阶段修复动作执行Repair Action Execution执行Shell脚本、Python脚本、Ansible Playbook、Terraform Plan/Apply、CI/CD Pipeline等自动化修复动作修复效果验证Repair Effect Verification验证修复动作是否成功执行系统是否恢复到正常运行状态SLO/SLI是否达到要求Error Budget是否停止消耗甚至开始恢复。如果修复效果验证通过那么自主运维闭环系统就会进入学习阶段如果修复效果验证不通过那么自主运维闭环系统就会回到决策阶段重新做出修复决策或者触发人工干预。3.1.4 学习Learning像人的“记忆和学习能力”一样从修复过程中学习优化学习阶段是自主运维闭环系统的第四个阶段也是它与“碎片式自动化”和“规则驱动的自动化”的最大区别。它的主要功能是像人的“记忆和学习能力”一样从修复过程中收集数据分析修复决策的正确性和修复动作的有效性然后优化故障预测模型和自愈决策引擎从而提高自主运维闭环系统的准确性和效率。学习阶段通常分为三个子阶段数据收集Data Collection收集修复过程中的所有数据包括故障预测的结果、告警的结果、修复决策的内容、修复动作的执行过程、修复效果的验证结果、人工干预的内容等数据分析Data Analysis分析修复决策的正确性例如“这个修复决策是否解决了问题是否有更好的修复决策”和修复动作的有效性例如“这个修复动作执行的时间是否太长是否有更高效的修复动作”模型优化Model Optimization根据数据分析的结果优化故障预测模型例如调整模型的参数、添加新的特征、更换新的算法和自愈决策引擎例如添加新的规则、优化现有的规则、更换新的机器学习算法。学习阶段的核心输出是**“优化后的故障预测模型和自愈决策引擎”这些优化后的模型和引擎将被应用到下一次的感知、决策和执行阶段从而形成一个不断迭代、不断优化的闭环**。3.2 Harness平台的核心模块搭建自主运维闭环系统的“积木”Harness平台提供了多个核心模块这些模块就像搭建自主运维闭环系统的“积木”一样我们可以根据自己的需求选择合适的模块搭建出属于我们自己的自主运维闭环系统。接下来我们就来详细讲解Harness平台的几个核心模块以及它们如何与自主运维闭环系统的四个核心阶段对应起来3.2.1 Harness Continuous IntegrationCI应用程序代码的构建、测试和打包Harness CI是Harness平台的持续集成模块它的主要功能是自动完成应用程序代码的构建、测试和打包从而提高应用程序代码的质量和交付速度。Harness CI的核心功能包括多语言支持支持Java、Python、Go、Node.js、Ruby、PHP等100多种编程语言多容器支持支持Docker、Kubernetes等容器技术多测试框架支持支持JUnit、TestNG、PyTest、Go Test、Jest等100多种测试框架AI/ML驱动的测试优化内置了AI/ML功能能够自动识别和运行与代码变更相关的测试用例Test Selection从而缩短测试时间与Git仓库的无缝集成能够与GitHub、GitLab、Bitbucket、Azure DevOps等Git仓库无缝集成自动触发CI Pipeline。Harness CI与自主运维闭环系统的对应关系是它可以作为执行阶段的一部分用于自动回滚应用程序代码的部署。3.2.2 Harness Continuous DeliveryCD应用程序的部署、扩容、缩容和回滚Harness CD是Harness平台的持续交付模块它也是Harness平台的核心模块它的主要功能是自动完成应用程序的部署、扩容、缩容和回滚从而提高应用程序的交付速度和可靠性。Harness CD的核心功能包括多云/混合云/本地部署支持支持AWS、Azure、GCP、阿里云、腾讯云等多个公有云也支持VMware、OpenStack等私有云还支持本地部署多部署策略支持支持蓝绿部署Blue/Green Deployment、金丝雀部署Canary Deployment、滚动部署Rolling Deployment、重建部署Recreate Deployment等多种部署策略AI/ML驱动的部署验证内置了AI/ML功能能够自动验证应用程序的部署效果Deployment Verification从而避免有问题的应用程序代码部署到生产环境自动回滚机制如果部署验证不通过或者应用程序的性能指标、错误率超过阈值能够自动回滚应用程序的部署与现有工具的无缝集成能够与Jenkins、GitLab CI/CD、Ansible、Terraform、Kubernetes等1000多种现有工具无缝集成。Harness CD与自主运维闭环系统的对应关系是它可以作为执行阶段的核心部分用于自动执行应用程序的部署、扩容、缩容和回滚等修复动作。3.2.3 Harness Service Reliability ManagementSRM服务可靠性的监控、测量和管理Harness SRM是Harness平台的服务可靠性管理模块它的主要功能是监控、测量和管理系统的服务可靠性包括SLO/SLI的定义、Error Budget的计算、错误率/响应时间/吞吐量的监控、链路追踪、日志分析、事件管理等。Harness SRM的核心功能包括SLO/SLI的可视化定义提供了可视化的界面用于定义SLO/SLIError Budget的实时计算和监控能够实时计算和监控Error Budget的剩余量和消耗速率多维度的性能监控能够监控基础设施层、平台层、应用层和业务层的性能指标全链路追踪能够追踪应用程序的请求从前端到后端、从一个服务到另一个服务的完整链路AI/ML驱动的异常检测内置了AI/ML功能能够自动检测系统的异常Anomaly Detection与现有监控工具的无缝集成能够与Prometheus、Grafana、New Relic、Datadog、Splunk、Jaeger、Zipkin等1000多种现有监控工具无缝集成。Harness SRM与自主运维闭环系统的对应关系是它可以作为感知阶段的核心部分用于采集系统的性能指标、日志数据、事件数据、链路追踪数据、SLO/SLI数据、Error Budget数据也可以作为决策阶段的一部分用于异常检测和告警触发。3.2.4 Harness Cloud Cost ManagementCCM云成本的监控、优化和管理Harness CCM是Harness平台的云成本管理模块它的主要功能是监控、优化和管理云成本包括云资源的成本分析、成本优化建议、成本预算管理、成本告警等。Harness CCM的核心功能包括多云成本的统一监控和分析能够监控和分析AWS、Azure、GCP、阿里云、腾讯云等多个公有云的成本AI/ML驱动的成本优化建议内置了AI/ML功能能够自动提供云资源的成本优化建议例如“这个EC2实例的CPU使用率只有10%建议改为更小的实例类型这个EC2实例是On-Demand实例建议改为Spot实例或者预留实例”成本预算管理和告警能够设置云资源的成本预算当云资源的成本超过预算时能够自动触发告警与云平台的无缝集成能够与AWS、Azure、GCP、阿里云、腾讯云等多个公有云的计费API无缝集成与Harness CD的无缝集成能够与Harness CD无缝集成在部署应用程序之前能够预测部署后的云成本。Harness CCM与自主运维闭环系统的对应关系是它可以作为感知阶段的一部分用于采集云资源的成本数据也可以作为决策阶段的一部分用于根据成本约束做出最优的修复决策。3.2.5 Harness Security Testing IntegrationSEI应用程序的安全测试Harness SEI是Harness平台的安全测试集成模块它的主要功能是自动完成应用程序的安全测试包括静态应用安全测试SAST、动态应用安全测试DAST、交互式应用安全测试IAST、软件组成分析SCA等。Harness SEI的核心功能包括多安全测试工具支持支持SonarQube、Snyk、OWASP ZAP、Burp Suite等100多种安全测试工具AI/ML驱动的安全漏洞优先级排序内置了AI/ML功能能够自动对安全漏洞进行优先级排序与Harness CI/CD的无缝集成能够与Harness CI/CD无缝集成在CI/CD Pipeline中自动触发安全测试自动阻断有严重安全漏洞的部署如果安全测试发现了严重的安全漏洞能够自动阻断应用程序的部署。Harness SEI与自主运维闭环系统的对应关系是它可以作为感知阶段的一部分用于采集应用程序的安全漏洞数据也可以作为执行阶段的一部分用于自动阻断有严重安全漏洞的部署。3.2.6 Harness Feature FlagsFF应用程序的功能开关管理Harness FF是Harness平台的功能开关管理模块它的主要功能是管理应用程序的功能开关包括功能开关的创建、编辑、删除、启用、禁用、目标用户分组、渐进式发布等。Harness FF的核心功能包括多环境支持支持开发环境、测试环境、预生产环境、生产环境等多个环境目标用户分组能够根据用户的ID、IP地址、地理位置、设备类型等属性将用户分成不同的组渐进式发布能够将功能开关的启用范围从0%逐渐扩大到100%自动回滚功能开关如果功能开关的启用导致应用程序的性能指标、错误率超过阈值能够自动回滚功能开关的启用与Harness SRM的无缝集成能够与Harness SRM无缝集成监控功能开关启用后的应用程序性能。Harness FF与自主运维闭环系统的对应关系是它可以作为执行阶段的一部分用于自动启用/禁用/回滚功能开关从而实现应用程序的降级和容错。3.2.7 Harness Chaos EngineeringCE应用程序的混沌测试Harness CE是Harness平台的混沌测试模块它的主要功能是在生产环境或者预生产环境中主动注入故障例如CPU使用率飙升、内存溢出、磁盘空间不足、网络延迟增加、数据库主从切换、服务进程被kill等测试系统的容错能力和自愈能力从而提前发现系统的薄弱环节优化系统的架构和自愈流程。Harness CE的核心功能包括多故障类型支持支持100多种故障类型的注入渐进式故障注入能够将故障的影响范围从0%逐渐扩大到100%自动停止故障注入如果故障注入导致应用程序的性能指标、错误率超过阈值能够自动停止故障注入与Harness SRM的无缝集成能够与Harness SRM无缝集成监控故障注入后的系统状态混沌实验的可视化定义和管理提供了可视化的界面用于定义和管理混沌实验。Harness CE与自主运维闭环系统的对应关系是它可以作为学习阶段的一部分用于测试系统的容错能力和自愈能力从而优化故障预测模型和自愈决策引擎。3.3 Harness Agent的架构、功能和部署方式自主运维闭环系统的“眼睛、耳朵、鼻子和手脚”Harness平台采用了“云平台本地/边缘Agent”的架构Harness Agent就是这个架构中的**“眼睛、耳朵、鼻子和手脚”它负责数据采集和命令执行。接下来我们就来详细讲解Harness平台提供的两种类型的AgentHarness Delegate和Harness SRM/APM Agent**。3.3.1 Harness Delegate核心执行AgentHarness Delegate是Harness平台的核心执行Agent它是一个轻量级的Java程序可以部署在生产环境、测试环境、开发环境或者边缘环境的服务器、容器、虚拟机或者Kubernetes集群中。3.3.1.1 Harness Delegate的架构Harness Delegate的架构非常简单它主要由三个部分组成Delegate Core这是Harness Delegate的核心部分它负责与Harness云平台的通信通过gRPC协议接收Harness云平台下发的命令和任务然后将这些命令和任务分配给对应的Delegate ExecutorDelegate Executor这是Harness Delegate的执行部分它负责执行具体的命令和任务例如执行Shell脚本、Python脚本、Ansible Playbook、Terraform Plan/Apply、CI/CD Pipeline等Delegate Plugins这是Harness Delegate的插件部分它负责扩展Harness Delegate的功能例如支持更多的云平台、更多的部署策略、更多的自动化工具等。3.3.1.2 Harness Delegate的功能Harness Delegate的主要功能包括与Harness云平台的安全通信通过gRPC协议和TLS加密与Harness云平台进行安全通信执行CI/CD Pipeline执行Harness CI/CD Pipeline的所有步骤执行自动化命令执行Shell脚本、Python脚本、Ansible Playbook、Terraform Plan/Apply等自动化命令采集部分数据采集服务器、容器、虚拟机、Kubernetes集群等的资源使用率、性能指标、健康状态管理自身的生命周期自动更新自身的版本自动重启自身的进程自动报告自身的健康状态。3.3.1.3 Harness Delegate的部署方式Harness Delegate支持多种部署方式我们可以根据自己的环境和需求选择合适的部署方式Docker容器部署这是最简单的部署方式我们只需要在服务器上安装Docker然后运行Harness提供的Docker镜像即可Kubernetes集群部署这是最适合云原生环境的部署方式我们可以使用Harness提供的Helm Chart或者YAML文件将Harness Delegate部署到Kubernetes集群中虚拟机部署这是最适合传统环境的部署方式我们可以在虚拟机上安装Java 11或者Java 17然后下载并运行Harness提供的JAR文件即可本地二进制文件部署这是最适合边缘环境的部署方式我们可以下载Harness提供的本地二进制文件支持Linux、Windows、macOS等操作系统然后运行即可。3.3.1.4 Harness Delegate的权限管理Harness Delegate的权限管理非常重要因为它需要执行很多敏感的操作例如部署应用程序、扩容/缩容服务器、访问数据库等。Harness平台提供了两种权限管理方式Harness平台权限管理我们可以在Harness平台上为每个Delegate分配不同的角色和权限例如只能执行CI Pipeline不能执行CD Pipeline只能访问开发环境不能访问生产环境环境权限管理我们可以在部署Delegate的环境中为Delegate分配不同的角色和权限例如在Kubernetes集群中为Delegate分配Service Account和Cluster Role在AWS中为Delegate分配IAM Role在Azure中为Delegate分配Managed Identity。3.3.2 Harness SRM/APM Agent监控与数据采集AgentHarness SRM/APM Agent是Harness平台的监控与数据采集Agent它可以部署在生产环境、测试环境、开发环境或者边缘环境的应用程序中负责采集应用程序的性能指标、日志数据、事件数据、链路追踪数据等。Harness平台提供了多种语言的SRM/APM Agent我们可以根据自己的应用程序的编程语言选择合适的AgentJava Agent支持Java 8、Java 11、Java 17等版本Python Agent支持Python 3.6、Python 3.7、Python 3.8、Python 3.9、Python 3.10等版本Go Agent支持Go 1.16、Go 1.17、Go 1.18、Go 1.19、Go 1.20等版本Node.js Agent支持Node.js 12、Node.js 14、Node.js 16、Node.js 18等版本Ruby Agent支持Ruby 2.5、Ruby 2.6、Ruby 2.7、Ruby 3.0、Ruby 3.1等版本PHP Agent支持PHP 7.2、PHP 7.3、PHP 7.4、PHP 8.0、PHP 8.1等版本.NET Agent支持.NET Core 3.1、.NET 5、.NET 6、.NET 7等版本。3.3.2.1 Harness SRM/APM Agent的架构Harness SRM/APM Agent的架构也非常简单它主要由三个部分组成Instrumentation Library这是Harness SRM/APM Agent的核心部分它负责在应用程序运行时自动插入代码字节码插入或者源代码插入采集应用程序的性能指标、日志数据、事件数据、链路追踪数据等Data Processor这是Harness SRM/APM Agent的处理部分它负责对采集到的数据进行清洗、聚合、压缩等处理Data Exporter这是Harness SRM/APM Agent的导出部分它负责将处理后的数据上传到Harness云平台的SRM模块通过HTTPS协议和TLS加密。3.3.2.2 Harness SRM/APM Agent的功能Harness SRM/APM Agent的主要功能包括性能指标采集采集应用程序的响应时间、吞吐量、错误率、CPU使用率、内存使用率等性能指标日志数据采集采集应用程序的日志数据并支持日志数据的结构化和查询事件数据采集采集应用程序的事件数据例如应用程序启动、应用程序停止、功能开关启用、功能开关禁用等全链路追踪采集应用程序的请求从前端到后端、从一个服务到另一个服务的完整链路并支持链路数据的查询和分析与Harness云平台的安全通信通过HTTPS协议和TLS加密与Harness云平台的SRM模块进行安全通信自动更新自身的版本能够自动更新自身的版本不需要人工干预。3.3.2.3 Harness SRM/APM Agent的部署方式Harness SRM/APM Agent的部署方式取决于应用程序的编程语言和部署方式我们以Java Agent和Docker容器部署的Java应用程序为例讲解Harness SRM/APM Agent的部署方式下载Harness Java Agent从Harness平台的SRM模块中下载Harness Java Agent的JAR文件配置Harness Java Agent设置Harness Java Agent的配置参数例如Harness云平台的API Key、应用程序的名称、应用程序的环境等修改Dockerfile在Java应用程序的Dockerfile中添加Harness Java Agent的JAR文件并修改Java应用程序的启动命令添加-javaagent参数指向Harness Java Agent的JAR文件构建和部署Docker镜像构建Java应用程序的Docker镜像并部署到Kubernetes集群或者服务器中。3.4 常见误解澄清在学习面向运维Agent的Harness故障预测与自愈系统的过程中很多人会有一些常见的误解接下来我们就来澄清这些误解3.4.1 误解一“自主运维闭环系统会完全取代运维工程师/SRE工程师”这是最常见的误解之一自主运维闭环系统不会完全取代运维工程师/SRE工程师它只会帮助运维工程师/SRE工程师从繁琐的、重复的手动工作中解放出来让他们有更多的时间和精力去做一些更有价值的工作例如系统架构的优化、故障预测模型和自愈决策引擎的优化、混沌实验的设计和执行等。就像李工的例子一样