AIOps赋能微服务：打造高效稳定的运维体系

一直想讲讲我做稳定性相关的经验和总结，稳定性建设到底要怎么讲，其实范围还是比较广泛的，于是我想重点从两方面来讲，一部分从运维体系谈谈我的看法，一部分是从业务层面如何去建设，本篇文章先谈谈第一部分吧。

如今微服务早已得到了普遍应用，尤其是互联网公司随着业务和人员的快速增长，单体应用已经无法满足需要，很多公司都开始对单体应用进行拆分，但微服务拆分本身也是一把双刃剑，也需要遵循一定模式和原则，贸然拆分的话虽然短期看似能解决一些问题，但从长期来看负作用也是非常明显的，主要体现在以下几点：

1、数据管理和一致性

微服务架构中的数据通常分布在不同的服务中，可能会使用不同的数据库或存储系统。确保数据的一致性和完整性变得更加复杂，这时候需要考虑使用分布式事务、事件驱动架构或其他解决方案，还有就是由于微服务拆分的较细，数据存储也非常分散，想要做集中式的数据统计和查询就变得非常困难。

2、性能监控和故障排除

由于微服务架构的复杂性，监控系统的性能并及时排除故障变得更加困难。每个服务都可能成为系统性能问题或故障的潜在源头，因为架构比较复杂，涉及到网络，服务注册，服务通信以及每个服务所依赖的数据库和第三方技术组件等等，这就需要有效的监控和故障排查机制。

3、服务发现和治理

在微服务架构中，服务实例的数量可能很大，并且它们可以动态地启动和停止。因此，需要一种机制来发现和跟踪可用的服务实例，并进行负载均衡和故障恢复。此外，还需要实施服务注册、配置管理和版本控制等治理策略。另外当服务实例出故障的时候，能够做到故障自愈，故障重试和请求自动漂移到其他健康实例上，保证服务的可用性。

4、部署和运维

由于微服务架构中有多个服务需要独立部署和运行，因此部署和运维的复杂性增加了。管理多个服务的版本、依赖关系和配置变得困难，还需要考虑监控、故障排除和日志记录等运维方面的问题。

5、服务间通信

在微服务架构中，各个服务之间需要进行通信。这可能涉及到远程调用、消息传递或使用API网关。处理服务间通信的复杂性需要考虑可靠性、性能和版本兼容性等因素

6、成本控制

基础设施成本增加：微服务架构通常需要更多的基础设施来支持分布式部署。每个微服务都需要独立的服务器、数据库、缓存等资源，这可能导致整体基础设施成本的增加。那么如何节省成本呢？如何在节省成本的同事，又不会影响服务的稳定性？

7、开发和维护成本上升

微服务架构使得系统分解为多个小型服务，每个服务都有自己的代码库、部署和测试流程。这增加了开发团队的复杂性和维护工作量，同时也需要更多的人力资源投入，从而导致开发和维护成本的上升

8、团队组织和沟通

微服务架构常常需要跨多个团队进行开发和维护，这对团队组织和沟通提出了挑战。各个团队之间需要协调开发计划、接口定义、接口变更等事项，以确保整体系统的协调运行。

上面列举了微服务的这么多痛点，那么我们aiops的价值又是什么呢？我们又应该如何做呢？

使用智能监控自助或自动地发现和处理故障，从而提高异常恢复的效率，最终提升用户体验。将异常处理效率提高和用户体验提升后，运维人员的沟通成本将会极大被降低，这样运维人员就有更多时间进行技术投入，能将更多“人肉处理”的异常变成自助或自动处理，从而形成“飞轮效应”。最终达成高效的稳定性保障的目标。

基于已有的数据，通过结构化的信息输出，提升可观测性，补齐关键数据缺失的短板。同时，我们基于完善的信息输出，通过规则（专家经验）和AI算法的配合，提供自助或自动定位的能力，缩短处理时长。

如何来通过智能监控进行降本提效？

这也是一直在思考的问题，首先提效问题是努力将人工介入的事变成自动化的事，将人工介入变成最后兜底的一环，而不是必要进行的一环，努力将根因分析的成功率不断提高，将报警精准触达率提高，将报警成功率提高，减少误报的机率，将故障解决的流程建设好，从而让有限的人力投入到更重要的业务开发中来。第二个问题是如何降本，监控平台通过分析各组件的容量使用情况，帮助产研团队分析哪些组件是空闲率很高，是否可以进入回收降配。

请看下图，这是我规划的aiops的整体执行路径。

这个图主要体现从数字化运维，智能化运维和智能化运营三个阶段，每个阶段递进，数学化运维主要体现的就是监控系统，发现问题，故障通知报警，而智能化运维体现的就是全链路智能化分析，当出现问题后，能够分析出可能出现的原因，在一定程度上可以进行故障自愈，自动将报警通知给相关人，构建故障知识库体系和反馈机制。而智能化运营则是从运营层面做出智能决策与分析。而我目前实际落地的阶段处在前两个阶段中，正在向第三个阶段做转变。

通过以上分析，我目前阶段实现的aiops架构，如下图所示：

说明：

1、事件中心：

主要基于中间件，服务，流量，容器，服务健康等做相关的事件管理，通过监控相应发生的事件，做关联分析，比如某个容器突然扩容，与哪些指标发生的事件有关，比如某个服务的cpu突然升高，导致的容器发生扩容，通过各事件的监控与关联，发现内在关联，帮助根因分析发现问题和解决问题，还可以观测上线环境变更推测异常根因。

2、日志治理中心

对错误日志进行全面分析，通过对Nginx，网络，服务，中间件的错误日志进行汇总和错误分析，归类错误类型，通过错误定位故障点，通过错误日志找到源代码位置，将各层级的错误日志进行关联分析，帮助根因分析找到错误源头，将通过调用报警中心将异常错误报警相关负责人。

3、体检中心

分析上线体检和健康对比体检，一个是上线前和上线后做体检，确保上线前系统无异常，上线后系统是健康的。健康对比体检是日常巡检，通过巡检帮助研发人员快速找到已经出现的故障和可能会出现的异常波动，提前做好预案。

4、监控中心

实时对数据库，中间件，JVM等进行指标监测，并通过对这些中间件分析，找到使用这些中间件的服务，如果某个中间件出现异常能够探测使用这些中间件的服务是哪些，及时报警通知，并能及时知道影响范围。

5、值班OnCall

接收异常工单，和报警通知信息，当系统接受到异常工单后，可以直接通过OnCall平台找到对应的负责人进行响应，当收到报警通知后，可以通过OnCall平台找到系统对应的负责人进行处理，并通过报警升级走到问题解决。

6、根因分析

基于决策树方法以及AI大模型数据训练对数据进行根因进行预测和分析。

7、报警中心

接入来自事件中心，日志治理中心，体检中心，监控中心的报警数据，并与根因分析进行交互，找到故障的根因，并通过故障收敛，降噪等手段做报警分派和通知。

8、统计中心

可以对组件容量降本统计，通过每天，每周，每月对各服务，以及组件本身进行容量使用统计，通过增长率，同比和环比，可以判断出来某个组件预计在未来什么时间容量会占满，哪个组件使用率是不是很低，是不是可以回收与合并，达到容量预测和降本的目标。

如何来衡量故障定位和报警准确率呢？

出现问题后通过告警发现异常->推送诊断根因->点击诊断链接详情查看详细信息->跟踪反馈处理的效果->确认异常的发现、定位、确认和处理的闭环->最后确定召回率。

通过以上几个环节完成闭环，可以实现MTTR，通过统计召回率可以实现根因分析的准确率，通过故障的确认，处理和完成，来发现各部门处理故障的效率和问题点。

随着AIOps的不断演进和实践，我们正逐步迈向一个更加智能、高效和稳定的运维新时代。通过将人工智能技术与运维实践相结合，我们不仅能够提升故障响应和处理的速度，还能够在成本控制和资源优化方面取得显著成效。展望未来，AIOps将继续深化其在微服务架构中的应用，助力企业构建更加健壮和灵活的系统，以应对不断变化的业务需求和市场挑战。让我们共同期待下一篇文章，我们将深入探讨如何从业务层面出发，进一步强化系统的稳定性和可靠性。