第一个阶段是发现问题，这个阶段是针对单个异常信息的，比如单个的 meric 异常、单个应用进程异常、单个应用日志信息的异常等。但是实际情况下，atv，通常一个部件发生异常，有可能会导致周边依赖的部件会同时异常，而且会同时导致 N 个的指标异常和告警。

比如，DB 一条慢 SQL 超时，DB 会告警、依赖 DB 的应用因为连接阻塞也会告警，RT 告警、QPS 异常告警、Load 告警，JVM 告警等等多个指标异常，而且有可能一整个集群都在告警，收告警的人也很多，DBA、PE、开发、SA 等等，再复杂一点，同一时间点，可能还有线上变更操作，如应用在做发布、DB 在执行 DDL、DML 等等。

这个时候，在一个分布式系统里，我们发现了问题，但是问题根因在哪里，就变得十分重要了，这个确认不了，就没法进行止损和故障消除。而且这个定位过程一般是非常非常痛苦的，越漫长越痛苦，但凡处理过故障的同学都会有深刻的切身体会。之前我们通常只是说要做告警收敛，简单和常见场景下靠人的经验是容易判断的，但是复杂情况下，还是得借助机器学习相关的算法，且系统越庞大、越复杂，靠人和专家会越来越无力。

这个时候就需要一套根因分析 RCA 框架来帮我们做这方面的分析工作，宇辰老师给出的建议是 Monitor Everything，然后根据相关性和决策树方面的算法进行根因分析，这块从分享内容看，在业界也是有比较成熟的分析算法。下面给出我的理解，直接看下图：

推荐阅读：Google 搜索，清华大学裴丹老师的《基于机器学习的智能运维》

解决问题—通过运维体系和场景去执行动作

上面两个部分，我们更加精准的发现和分析了问题，那接下来，我们就该解决问题了，准确的说是 做解决问题的动作，这个动作谁来做呢，当然是 Ops 运维体系发挥作用了，比如：

a、容量不足，要做扩容动作，或者降级或限流动作

b、发现某台或部分机器 CPU 或内存异常，那做下线动作

c、有慢 SQL，那要尽快执行 Kill 动作

d、代码有 bug？赶紧回滚，或者重新发布修改 bug 的代码

e、。。。。。

如果说前面的两个阶段要看算法的效率和准确度是不是高，到了这个阶段，就看解决问题的动作执行是快是慢了，这个取决于啥呢？当然 取决于我们的整个运维和稳定性体系是否高度自动化，是否高度完善。如果高度完善，在第二步分析问题发现根因后，应该可以跟一个运维的预案场景关联，自动触发预案的执行。做的再好一点，可以做到 AI 的预测，提前识别出可能会发生的问题，提前将预案执行完成。如果能做到这个程度，我想也算是很牛 x 的 AIOps 体系了。

当然，在发现问题和分析问题阶段，也会依赖基础的运维体系，比如日志采集、全链路跟踪、CMDB 和应用配置管理的元数据信息等等。

下面一张图完整说明下我对 AIOps 体系的理解：

个人观点和建议

1、AIOps 的发展一定是一个长期演进的过程，AI 是 Ops 的有力补充，进一步降低运维的工作强度和压力，但是 AIOps 一定建设在高度自动化和完善的运维体系之上的，是一个演进的过程，不会是一个跳跃性的过程，产生一个完全颠覆性的 AIOps 模式，将现有的 Ops 体系替代掉。

2、从公司的角度，先集中精力建设好运维自动化体系，效率的问题解决了，再考虑更高层次的建设，就好比先解决温饱问题，再追求小资生活，这一点前两天毕玄大师的文章也表达了这个观点，我是灰常认同的。当然如果人力、精力有富余，做一些前期的预研和投入是没问题的，但不要本末倒置。至于大厂，人家早就投入 N 多年开始研究了，其中百度做的绝对是标杆。

3、从个人角度，机器学习和 AI 的知识和技术还是要花一些个人精力去学习的，凡是会让我们的生活变得更美好的技术必然会有极强的生命力，也必然代表着未来技术发展趋势，AI 就是其中之一。

本文中提到的 AI 和机器学习的部分还是很浅显的，我自己也在学习中，那些复杂的算法和数学公式弄得我始终头晕眼花，目前处于学习，搞不懂，看不去下，放下，然后再拿起，说实话，过程有点痛苦，算法研究类的思维模式跟工程类的思维模式还是有很大不同，继续坚持。

「 Forrest 随想录」原创文章，已经授权 InfoQ 公众号转发传播。