AIops离我们遥远吗？

如果在几年前说这个话题，可能会很容易被打脸，打得啪啪响。

DevOps都玩不好还想玩AIOps?

所以我们要推进DevOps的理念，会受到两个方向的阻力，比如运维和开发团队的支持，或者说是上下级同事的支持。

很多同事说，这么高大上的事情可以先放一放，我们手里的业务都忙不完，哪里有时间去折腾这个事情。当然这是一个死循环，越是没有时间，越是没有改进，然后继续按部就班。

自动化运维不等于devops，但是自动化运维做不好，devops一定做不好。而要做自动化，一定要做标准化，标准不是一个文档，或者一纸空文，而是可以落实的流程，流程是一把针，能够有效的把这些标准（线）连接起来。

当然说到AIops的标准，似乎行业里对于它的定义有很多不同的声音，在这方面，对于BAT大厂的思想进行提取和借鉴就是一个不错的行径。我们没法照搬，但是可以做一些取舍和定制。

其实在我们的工作中，很多同学按部就班的处理问题，最终的目标是解决问题。这个问题的来源相对来说是被动的，就好比是一个篮子，需求就是一些小球，篮子里面永远都有填不完小球。我们可以换个思路，为什么会出现这个问题，如果觉得这个问题太弱智，我们先放一下，然后我们分析这个问题的根本原因是什么，对此的输出就是解决方案，最终问题得到解决。

然后回过头来继续看第一个问题，为什么会出现这个问题，如果追根溯源，一定能够找到很多相关的因素或者同类潜在的问题。那么这个发现问题的角度就是一种主动，系统化的方法论了。

而对于分析问题，这个就是解决问题的核心了，很多时候我们都会依赖于人，高手和新手对于同样一个问题的处理思路大大不同，而且同样的输出和日志，在他们眼里的含义和角度也不同，所以分析问题的角度和细节决定了分析问题的质量。在这个阶段其实我们是很依赖于个人的，最终我们需要得到一格解决方案。

而真正的解决问题，其实是在前面思考的前提下来做的实施。

为什么很多时候业务同学反馈说存在代沟或者不便捷的很多方面，一个原因是因为我们前两个步骤做的不够好，我们没有提前发现问题，而是更多等待业务的反馈，业务一旦反馈，那么肯定没有太小的事情。如果发现了问题A,同时我们能够发现问题B,问题C,这样对于业务同学来说，系统的可用性会大大提高。至于发现过多问题导致的业务价值的过渡透明化，这是另外一个极端了。

对于问题分析，最终的一个产出是解决方案，比如业务同学想要一个 结果A,结果你像哆啦A梦般有一揽子的解决方案，对于哪一种解决方案都能够灵活应对，那么我们业务同学对你的信任感会大大提高，在后续的工作中会有更多愉快的合作。

否则基本就会是人海战术。

如果按照行业的一个基本标准来说：AIOps 不依赖于人为指定规则，主张由机器学习算法自动地从海量运维数据（包括事件本身以及运维人员的人工处理日志）中不断地学习，不断地提炼并总结规则。

这对于很多运维人员或者运维开发人员来说，我们需要做的事情就更加专精深了。这势必会是一个全新的方向，同时也是一种全新的思路借鉴。

我翻了下今年关于AIops的一些目标，大体有如下的一些阶段和程度吧。

1）开始尝试应用AI能力，还无较成熟单点应用

2）具备单场景的AI运维能力，可以初步形成供内部使用的学件

3）有由多个单场景AI运维模块串联起来的流程化AI运维能力，可以对外提供可靠的运维AI学件

4）主要运维场景均已实现流程化免干预AI运维能力，可以对外提供可靠的AIOps服务。

5） 有核心中枢AI，可以在成本、质量、效率间从容调整，达到业务不同生命周期

所以要高度的自动化，智能化，有一大堆的事情要做好，要提前安排。

这是一个相对概览的图，可以对标。

很多同学都说我们最好了自动化运维的工作，是不是工作已经走到头了，显然说实话，才是刚刚开始。后续有一大堆的事情需要我们来做。

对于AIops的落地，自己也有了一个初步的思路，后期在工作中会更加强化API接口层的独立性，然后不断的封装，满足业务需求之外，还可以提供更加深度的技术支持。

想想，我们的工作依旧任重道远，我们自身的意识也需要从1.0提升到2.0